Use a Computer for Recording and for Capturing Additional Task-Specific Information for Structuring Rationale

This principle differentiates the approach from simple recording. While audio or video recording would not necessarily require a computer, this principle demands the recordings to be computerized (at least in the end). But there is more to this principle: the more one knows about the focus task at hand, the more additional information can be recorded on the side. There is often an internal structure associated with a task or a discussion. For example, the table of content of a document under discussion, the agenda of a meeting, or the file structure of a software project provide hooks and opportunities to refer to.

Since we know that the focus task is related to software engineering, and due to focusing on only one task, typical structures can be identified and used. Assume a meeting in which requirements are discussed with a customer. At some point, participants point to a requirement in a DOORS database, at another point they execute and comment a prototype. Time-stamped paths facilitate cross-referencing between DOORS document structures, code execution traces, and oral comments by the participants. What happened at the same time may be related. Analyses built upon the combined recordings will add value beyond simple replay, but will also require substantial up-front implementation work.

Natural language understanding, or any sophisticated form of artificial intelligent, is not the purpose. Time-stamped recordings are used as time-indexed paths through the discussion space. Given structures and paths provide an additional perspective on recorded rationale (e.g., code structure or DOORS-links).

There is a lot of similarity to approaches like domain-oriented design environments [8], but this principle is less general and more specific than DODEs. By stressing path and structures typical for the focus task at hand, the principle helps the user of the approach to narrow down on an issue.