Management science, software engineering, and human-computer interaction research have traditionally followed a model-based approach, which involves: formally reconstructing the concepts and rationale behind the current system; specifying the desired change at the conceptual level; and implementing the changed concepts to reach the new system while taking the legacy context into account.
With the deeper immersion of IT usage and impact in everyday life, formal models often prove clumsy to develop and difficult to understand. Even when an initial shared understanding exists, the preceding procedure describes but one step in a continuous change process that is hard to trace without strong linkage to reality.
A scenario describes a possible set of events that might reasonably take place. Its purpose is to stimulate and document thinking about current problems, possible occurrences, assumptions relating to these occurrences, action opportunities, and risks. Thus, scenarios must be linked to change goals. Results from cognitive psychology [1] indicate that scenarios offer a middle-ground abstraction between models and reality, providing a universally understood medium for participatory design, and facilitating reuse of design knowledge:
Consistent with these observations, software engineering employs scenarios as intermediate design artifacts in an expanded goal-driven change process, as shown in Figure 1 [3]. This implies four typical views for the classification of scenario-based approaches [4]:
In the European CREWS project, this framework was used to compare research and practice in scenario management [5]. While researchers, focusing on the form view, investigate scenarios as formal mediators between detailed traces and class-level specifications, practitioners rarely use formal scenario representations but complain about a lack of guidance in authoring text scenarios.
From the content perspective, scenarios can address an organizational work context, they can represent the internal interplay of components within the current or future system, orthe most frequent casethey can focus on the interaction between the system and its environment. Interaction, in turn, can be studied in an in-bound direction (what constraints does the environment place on the system?) or in an outbound direction (what impact has the system on its environment?).
The life cycle of scenarios is much more involved than is addressed by current research.
Scenario purpose and impact showed much more variation than expected from the research literature. While researchers discuss the application of scenarios for making abstract models understandable, to reach partial agreement and consistency, practitioners also use scenarios for task decomposition in complex projects, as a linkage between development phases, and as design aids and boundary conditions for object models.
Consequently, the life cycle of scenarios is also much more involved than is addressed by current research. The framework shown in Figure 1 covers a broad variety of possible methodologies. Many software companies follow an informal development cycle that contains general goals and future scenarios, but no models. At the other extreme, formal scenario techniques in strategic management often abstract reality to the values of a few key variables and strategic events. In between, Rational's Unified Modeling Language (UML) has adapted Jacobsen's approach [2], which groups a collection of interaction scenarios (expressed as message trace diagrams or collaboration diagrams) into a use-case for manageability. However, this definition of scenarios is clearly too narrow. For example, practitioners also employ use-cases for managing internal scenarios of technical systems such as in telecommunications.
Many large projects consider scenario selection, structuring, and evolution to be key issues. Multiple views on scenarios (developer, user, and manager views of the same scenario) and the traceability of scenarios across project phases (interplay between scenarios and prototypes, elaboration of scenarios into test cases) still await solid solutions. Finally, methodological advicewhen to embed what kind of scenario technique into traditional methods, based on sound cost-benefit analysis of scenario usageis one of the most crucial topics to be addressed when the vision of scenario-integrated methodologies such as those promoted by UML is to become a reality.
1. Carroll, J.M., Ed. Scenario-based Design: Envisioning Work and Technology in System Development. Wiley, NY, 1995.
2. Jacobsen, I. The use-case construct in object-oriented design. In Carroll, J.M., Ed. Scenario-based Design: Envisioning Work and Technology in System Development. Wiley, NY, 1995.
3. Jarke, M., Bui, X.T., Carroll, J. Scenario managementAn interdisciplinary perspective. Requirements Engineering J. 3, 3 (1998).
4. Rolland, C., Ben Achour, C., Cauvet, C., Ralyte, J., Sutcliffe, A., Maiden, M., Jarke, M., Haumer, P., Pohl, K., Dubois, E., Heymans, P. A proposal for a scenario classification framework. Requirements Engineering Journal 3, 1 (1998), 2347.
5. Weidenhaupt, K., Pohl, K., Jarke, M., Haumer, P. Scenario usage in software development: Current practice. IEEE Software (Mar. 1998), 3445.
This work was supported in part by the European Commission via ESPRIT Long Term Research project 21.903 (CREWS).
©1999 ACM 0002-0782/99/0100 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 1999 ACM, Inc.
No entries found