Exploiting use case descriptions for specification and design

Going beyond requirements, software engineers often employ use case descriptions to help them build initial design models of the proposed system. Despite Jacobson’s claim that “objects naturally fall out of use cases”, finding design-oriented classes in use case descriptions is not always straightforward. Indeed, the initial production of use cases may also prove problematic, and writing guidelines have been suggested as one way of improving the quality of use case descriptions. This paper follows previous work (some of which has been presented at EASE), which compared writing guidelines in order to assess the comprehensibility of resulting descriptions. The work is distinct in that previous work has viewed the description wholly as a document for specification. This meant that descriptions were assessed in terms of issues such as clarity and consistent abstraction. However, for design, other issues come to the fore, notably what useful information can be gleaned from the description, to inform the architecture of the system. Therefore, this paper examines which guidelines produce descriptions that are most useful to inform design. In brief, the results of this study suggest that those guidelines previously reported as most successful in the production of use case specifications (our own CP Rules), do not prove most useful for design. Hence, that designers would benefit from more detailed descriptions, especially concerning internal system events, and that this level of detail is most prevalent in descriptions produced using the CREWS Guidelines. Finally, our findings seem to suggest that it may be beneficial to produce separate use case descriptions, employing different guidelines or structures, for requirements validation and for system specification and design. Key words: use case description, specification, design, experiment