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:
- Scenarios focus design efforts on use first and foremost. What people can do with the old/new system, and the consequences for themselves and for their organizations, is described and analyzed prior to detailing the system functions and features that enable this use.
- Scenarios suspend commitment but support concrete progress. They vividly explain why a system is needed by showing what it is used for, but they also facilitate an analysis of design alternatives for how it is used.
- Scenarios provide a task-oriented design decomposition that can be used from many perspectives, including usability trade-offs, iterative development, and manageable software design object models.
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]:
- What part of the work activity is captured in a scenario (content view)?
- How is it represented in the development environment (form view)?
- For what usage in the design process is it captured (purpose view)?
- How is it developed and evolved (life-cycle view)?
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, or—the most frequent case—they 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 advice—when to embed what kind of scenario technique into traditional methods, based on sound cost-benefit analysis of scenario usage—is 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.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment