Often it is only by making rationale explicit that consistency can be achieved. For example, it is not uncommon in large projects for the same decision tasks to be done by different groups within the design team. Recording rationale makes it easier to identify this fact and to make sure that decisions are mutually consistent. This use of DR is prescriptive, for it seeks to change the way designers think, i.e., making it more consistent. Though this use of DR requires methods that go beyond mere historical description of designer’s rationale, such description may be of value because it exposes designers’ reasoning to critical scrutiny.
Verifying Designs (Supporting Traceability)
This use of DR requires an explicit linking of requirements criteria to the descriptions of artifact features that satisfy these criteria. In the case of software, it also suggests the desirability of linking the criteria to actual features of the implemented software. This requires a schema that makes criteria explicit, as QOC and DRL do, rather than schemas where criteria are embedded in larger arguments, as is the case with IBIS.
One possible use of DR is to support debugging, fixing problems, and extending the functionality of an artifact. This problem is probably more critical with software than with any other type of artifact. DR can be used to spot conceptual errors in design as well as implementation errors, and errors of omission as well as errors of commission.
To maximize learning from the past, we need to be able to compare designers’ expectations about the consequences of their decisions with the actual consequences. This requires more than an understanding of the reasoning behind past decision; it requires evaluation of artifacts in use. One approach to doing this is found in case-based reasoning (CBR) projects by Colander . Especially interesting is the ARCHIE project, which records the experiences of users of artifacts (buildings) and links these experiences to representations of the artifact.