Use Scenarios: Nice to Have or
Wolfgang Dzida and Regine Freitag
GMD German National Research Center of Information Technology
A prototype enables the designer to demonstrate an understanding of requirements in terms of a designer's language. The usability designer is used to express requirements in terms of "look and feel" attributes in compliance with style guides. These attributes are in response to user requirements, which are expressed in terms of the user's language describing tasks, objectives, user performance, etc. Two types of scenarios which we call context and use scenario may help catch the requirements from the user in a way that is comprehensible to the user. (For the role of scenarios in requirements engineering see the paper of Wolfgang Dzida in this volume.) A prototype is intended to express these requirements in other words. Both languages, scenarios and prototypes, can be used to produce a double representation of requirements. However, double representation requires double effort and may be questioned by managers. This paper argues in favour of double representation for two reasons: 1) according to ISO 8402 a requirements definition is an "expression of the needs and/or their translation into stated requirements for the characteristics of an entity to enable its realization . . ." (par. 2.3); and 2) double representation has often proven its worth in creative processes which the analysis and design process should be.
Winograd and Flores ( 1986) pointed out that we create our world (e.g., our systems) through language. Until recently, the designer's modeling language dominated the requirements definition process. In traditional systems analysis there was a lack of awareness of the user's problem situation. It may be necessary, however, to enter this situation in terms of the user's language, thereby considering a different representation of the design problem as the designer usually does. Domain representation and design representation, both provide a more comprehensive view of the problem, with the user's view focusing tasks, intended results, and complaints and with the designer's view focusing a design proposal for the user's problem setting. The user's view is complementary to the designer,'s view and serves as a rationale for the designer's solutions. Scenarios turned out to be much closer to the user's mother tongue than any professional problem statement language. To bridge the