The CREWS scenario framework is described in (Rolland et al. 1998). Readers are referred to that report for a full description of the framework, with detailed examples. The framework considers different scenario approaches from research or industrial practice along four different axes or views, each capturing an aspect of the scenarios:

• The form view deals with the expression mode of a scenario. Are scenarios formally or informally described, in a static, animated or interactive form?—are the kinds of questions that this view deals with. Scenario form can include text, tables, and so on.
• The contents view concerns the kind of knowledge that is expressed in a scenario. Scenarios can, for instance, focus on the description of system functionality or they can describe a broader view in which the functionality is embedded in a larger business process with various stakeholders and resources bound to it.
• The purpose view is used to capture the role that a scenario is aiming to play in the requirements-engineering process. Describing the functionality of a system, exploring design alternatives or explaining drawbacks or inefficiencies of a system are examples of roles that can be assigned to a scenario.
• The life-cycle view considers scenarios as artefacts that evolve in time through operations carried out in the requirements-engineering process. Creation, refinement, or deletion are examples of such operations. The question of persistency versus transience is also addressed.

FIGURE 2.1 The four views of scenarios in the crews framework

These facets and a summary of their meanings are depicted in Figure 2.1.

The framework uses a faceted classification method for classifying reusable components. Each view has a set of facets, which are viewpoints or dimensions for characterising and classifying scenarios. For example, the description facet in the form view helps to classify scenarios according to the medium and the language that they use. Each facet has a metric and is measured by a set of attributes. For instance, the description facet is measured with two attributes, namely medium and notation. Attribute values are defined within a domain such as Integer, Boolean, Enumeration, Set, or Tuple.

In this chapter, the framework is outlined and then used to introduce the scenario approaches described in Part II of this volume.

The framework consists of four views (Form, Contents, Purpose, and Life cycle), each with several facets. Each facet is defined in several attributes, whose types are listed, and illustrated with examples from some popular approaches. The framework uses three example approaches (Rolland et al. 1998) chosen to illustrate the spectrum of scenario usage. Readers are referred to that paper for further details and original references:

• Jacobson's use-case approach (1992) illustrates the use of scenarios in the form of use cases for software engineering, and is now very widespread in the form of UML, as popularised by Alistair Cockburn and others (Cockburn 2001).
• Kyng's prototyping approach (1995) tries to show that mock-ups, prototypes, and scenarios can support all steps of the design process enhancing creative end-user participation. The six artefacts (summaries, work situation descriptions, use scenarios, mock-ups and prototypes, exploration/requirement scenarios, and explanation scenarios) used during Kyng's design process can be viewed as kinds of scenarios.
• Potts' inquiry cycle approach (1994) is representative of scenario-based approaches, involving a detailed requirements analysis model supporting documentation, discussion, and evolution of requirements.

The form view has two facets with relevant attributes. The description facet has two attributes—notation, which is enumerated with the values {formal, semi-formal, informal} and medium, which is enumerated with the values from the set {text, graphics, image, video, software prototype}. The presentation facet also specifies two attributes—animation, which has the Boolean value (equating to Static or Animated) and interactivity, which can have the values {None, hypertext-like, advanced}. For example, Table 2.1 summarises the position of three published scenario approaches according to the Form view by providing values for the Description and Presentation facet attributes.

The contents view has four facets, each with specified attributes. The facets are coverage: (i.e. what sets of things does the scenario cover?), context: (i.e. what level is this scenario at?), argumentation (i.e. does the scenario support different types of argumentation and justification?), and abstraction (i.e. does the scenario describe agents and events at the type or instance levels?). Some of the attributes for each of these facets, for three published scenario approaches, are shown in Table 2.2. The value True value indicates whether each approach supports the facet's attribute, whereas the False value indicates that the approach does not.

The purpose view has only one facet—role—with three attributes defining whether or not the scenario fulfils a descriptive role, an exploratory role, or an explanatory role. For example, Table 2.3 shows how some published scenario approaches differ in the purpose view.

The life-cycle view has two facets and attributes—lifespan (i.e. whether the scenario is transient or persistent in the life cycle). The lifespan facet has one attribute, which is enumerated to 2 values {Transient, Persistent}. The capture facet is more complex and has five facets—capture, integration, refinement, expansion, and deletion—each of which has a Boolean value indicating whether each approach supports the different operations in the software development life cycle. For example, Table 2.4 demonstrates how some published scenario approaches differ by the life-cycle view.

TABLE 2.1 Classification of three approaches according to the form view (from Requirements Engineering Journal, Rolland et al. 1998)

TABLE 2.2 Scenario-based approaches classification according to the contents view (from Requirements Engineering Journal, Rolland et al. 1998)

TABLE 2.3 Scenario-based approaches classification according to the purpose view (from Requirements Engineering Journal, Rolland et al. 1998)

We applied the CREWS classification scheme to review the 14 approaches reported in the second section of this book. Table 2.5 summarises the results of the review. The classification highlights some interesting commonalities and differences between the approaches. Let us examine the approaches facet by facet.

TABLE 2.4 Scenario-based approaches classification according to the life-cycle view (from Requirements Engineering Journal, Rolland et al. 1998)

Most approaches use text and graphics to represent scenarios rather than images and prototypes: for example, the use of scenarios reported by Suzanne Robertson in Chapter 3. This result is surprising given findings that have been reported elsewhere. For example, Weidenhaupt et al. (1998) report a Europe-wide survey of scenario use in software development that revealed that two-thirds of all projects enhanced the use of scenarios with prototypes. The results of our review of the approaches do not necessarily argue that prototypes are not used, but the results do suggest that the reported approaches do not explicitly mandate or depend upon the use of prototypes, although they may encourage it. Another finding is that other scenario representations exist, even if only in the background. For example, Suzanne Robertson also reports the use of scenes that are acted out by stakeholders as an innovative form of scenario, similar to the use of role-played reported elsewhere, for example in (Graham 1998).

A less surprising result is that only one approach, the use of imagined future world scenarios reported by David Bush in Chapter 6, uses formal representation of scenario parameters—the 13 other approaches all use informal and semi-formal scenario representations. David Bush describes how he creates snapshot scenarios of imagined future worlds to evaluate the stability of goals. It is one of the few approaches of non-narrative scenarios—static, rather than sequences of steps—and also one of the few that capture non-functional aspects.

The trend towards the use of simple scenario representations of software tools continues with the presentation facet. None of the approaches explicitly use scenario animations, even in simple form, and few approaches support interactive exploration of the scenarios. Instead, scenarios are used as artefacts that can be changed during systems development, but they tend to be static rather than dynamic artefacts, in spite of exceptions such as the ART-SCENE approach reported in Chapter 9.

The abstraction facet revealed greater variations across the 14 approaches. Some use scenarios to describe instances of agents, objects and their behaviour, while other approaches use scenarios that express type-level constructs. To our surprise, given the informality of most scenario representations, few of the approaches appear to mix instance and type-level representations in the same scenario.

TABLE 2.5 Classification of Scenario Approaches Presented in this Book

The context facet examines what is described in a scenario in each approach—whether it describes the internal system behaviour, the wider organisational environment, or system-level interactions and the context of use that we would characterise as linking internal system behaviour to the wider organisation context. All but two of the approaches describe internal system behaviour and interaction between the system and external agents such as people and other systems, indicating the continuing focus on systems development, and is consistent with the use of scenarios and use cases in the Rational Unified Process (RUP). For example, in Chapter 5, Ellen Gottesdiener holds participative workshops to define system requirements that are mainly for system function, but she also mentions the use of misuse cases to capture non-functional requirements, something covered in more depth in Chapter 7 by Ian Alexander but with more of a focus on safety and security requirements. Likewise, in Chapter 11 David Benyon and Catriona Macaulay apply user stories, conceptual scenarios, concrete scenarios, and use cases to define system interactions. What is more surprising is the focus in most of the approaches on also describing the context and organisational environment in which the systems will be developed. All but two of the reported approaches cover at least one of the contextual aspects. For example, Peter Haumer in Chapter 12 reports the transformation of use cases and goals into analysis and design models to define business processes and system behaviour.

Scenarios in six of the 14 approaches do not support any of the four argumentation and rationale facets, in contrast to Karen Holtzblatt's use of storyboards, use cases, and object models throughout implementation and testing that can effectively describe positions, arguments, issues, and decisions, as reported in Chapter 10. The remaining approaches offer scenarios that describe some but not all of these facets, but without any discernible pattern.

The framework enables us to describe the coverage of each approach using the intentional, functional, and non-functional facets. Scenarios in most approaches are behavioural and functional—again only Holtzblatt's use of scenarios (Chapter 10) goes further by additionally enabling developers to handle the more structural elements of process, work, and organisation. Likewise, most approaches support goal modelling and goal decomposition. In contrast, only the two approaches reported in Chapters 4 and 10 support opportunities, and only the Holtzblatt approach also explicitly supports the expression of actor responsibilities. In Chapter 4, Joy van Helvert and Chris Fowler report the use of ‘a day in the life of’ scenarios mined in a workshop to identify user needs. These are evaluated to create a service specification.

Many of the results reported from the review depend on the role for which the scenarios are being used in each approach. In most approaches, scenarios are persistent and last throughout the life cycle of the system's development. The framework identifies three facets—or roles—for scenarios: descriptive, exploratory, and explanatory. All but one of the 14 approaches use scenarios of descriptions of some current or future system or environmental situation. Not surprisingly, the approaches intended to be used towards the beginning of the life cycle—in particular, during requirements and system specification—support exploratory behaviour with scenarios to discover and surface issues, whereas approaches used in the later implementation and testing stages do not. For example, in Chapter 13, Kent Beck and David West use stories to capture users' requirements, and these stories have different roles—they can be interrogatory, support delegation, composite, collaborative, or fuzzy. Only one approach—misuse cases in Chapter 7—uses scenarios to explain as well as to describe and explore. Likewise, facets that describe operations that developers are expected to undertake with scenarios reveal that most approaches use scenarios to capture, acquire, surface, and discover, and to refine what has been discovered. One exception to this is Andrew Farncombe's treatment (Chapter 15) of the basic life cycles as stories, combining these stories to create tailored life cycles for specific projects.

In this book, we have sought to bring together reports of many of the leading scenario-based approaches currently available to researchers and practitioners. As such, we believe that the 14 approaches are representative of scenario approaches that have been successfully applied in practice or have emerged from research and have significant potential of being successfully applied in the future. The gaps that the classification based on the CREWS framework identifies indicate both potential limits for the applicability of scenario-based approaches and areas for future research and development challenges.

Section 2 reports these 14 approaches in more detail. Read on and enjoy them.