CHAPTER 9

SYSTEMATIC SCENARIO WALKTHROUGHS WITH ART-SCENE

Neil Maiden

Centre for HCI Design, City University, London, UK

POSITION IN THE LIFE CYCLE

APPLICABILITY

ART-SCENE can be applied to discover requirements for a wide range of systems. The main application so far has been to specify three air traffic management systems—ART-SCENE'S automatic generation of alternative courses can complement hazard analysis work that underpins the development of safety cases. Given its roots in use case–driven approaches, ART-SCENE can also support the specification of information systems, while its use of web technologies can support distributed requirements engineering processes.

KEY FEATURES

ART-SCENE incorporates innovative software tools for generating scenarios from use case specifications and guiding the walkthrough of these scenarios during walkthroughs with stakeholders.

STRENGTHS

Scenario walkthroughs are a powerful technique for discovering stakeholder and system requirements and defining them more precisely. Scenarios provide an effective communication device for stakeholders in a walkthrough, and the structure of a scenario provides an effective structure for a walkthrough. Likewise, scenario alternative courses are needed to discover the 20% of requirements not associated with the normal and expected behaviour of the future system. Scenarios also provide a powerful technique for reviewing the intended meaning of discovered requirements. In ART-SCENE, automatic scenario generation can provide productivity benefits for scenario walkthroughs while novel web-enabled and PDA-enabled walkthrough tools support distributed scenario walkthroughs and context-specific walkthroughs in the workplace.

WEAKNESSES

ART-SCENE depends on bespoke software tools based on recent research developments; hence there are some set-up costs and concerns currently over the reliability of the more innovative software tools. The current ART-SCENE implementations rely on centralised scenario generation by the ART-SCENE support team, although we are developing new tools to make the entire process self-supporting.

THE ART-SCENE PROCESS AND ENVIRONMENT

ART-SCENE (Analysing Requirements Trade-offs: Scenario Evaluations) is a research-based approach for using scenarios to discover, acquire, and analyse stakeholder requirements during the earlier stages of the software development process. It integrates results from basic and applied research with software engineering best practice practices to deliver a complete approach that development teams can use to produce requirements and system specifications.

The kernel of ART-SCENE is an innovative software environment that delivers two important capabilities to software developers. The first capability is automatic scenario generation. In simple terms, ART-SCENE automatically generates one or more scenarios with different normal course event orderings and alternative courses from a use case specification with different parameter value settings that are produced by a developer. This enables a development team to overcome the scenario generation bottleneck, and generate and revise the scenarios quickly.

The second capability is guided walkthroughs of these generated scenarios. The big idea behind these walkthroughs is very simple—that people are better at identifying errors of commission rather than omission (Baddeley 1990). From this general trend in human cognition for recall to be weaker than recognition, ART-SCENE scenario walkthroughs offer stakeholders recognition cues in the form of generated alternative courses. If the alternative course is relevant to the system being specified but not yet handled in the specification, then a potential omission has been identified, and ART-SCENE guides the developers to acquire and document the relevant requirements.

On top of this capability we have developed layers of process guidance and support: additional software features; guidelines about who should attend scenario workshops; design of a scenario workshop; workshop facilitation processes; and profiles to tailor the generated scenarios to the relevant attendees.

We are now applying the ART-SCENE process as part of the wider RESCUE process (Jones et al. 2004), a user-centric requirements and design process in which stakeholders are encouraged to own the scenarios (Carroll 2002). This can be difficult when the scenarios are generated automatically, albeit from use case specifications that are produced by the development team and other stakeholders. Therefore, to give stakeholders greater ownership of ART-SCENE scenarios, we have implemented new ART-SCENE functions that offer more control over the scenario content and presentation.

ART-SCENE'S RESEARCH PROVENANCE

The ART-SCENE process and environment has been developed from research that has been funded from different sources since 1995. The original scenario generation and walkthrough environment was developed as part of the EU-funded Framework IV CREWS (Cooperative Requirements Engineering With Scenarios) long-term research project. The result—CREWS-SAVRE—was a prototype research tool for automatically generating scenarios and walking through them systematically to discover stakeholder and system requirements (Maiden et al. 1998). The CREWS-SAVRE prototype was a cornerstone of the ART-SCENE environment developed as part of the UK EPSRC-funded SIMP (Systems Integration for Major Projects) project that was completed at the end of 2003. ART-SCENE extended the CREWS-SAVRE prototype with software tools for simulating systems architectural models with scenario inputs (Zhu et al. 2003), and exploring the emergent properties of a system through visual simulation tools. It also led to the development of better use case authoring tools, an innovative web-based scenario walkthrough tool, a version of which has been developed for Personal Digital Assistants (PDAs), so that scenario walkthroughs can be done in the work context, thereby linking contextual inquiry and structured walkthrough techniques for requirements discovery.

ART-SCENE'S development has been strongly influenced by its use in several large-scale applications. During the CREWS project, Marconi Naval Systems (later BAE SYSTEMS) funded SERPS, a bilateral project to specialise CREWS-SAVRE to the naval warfare domain (Maiden and Corrall 2000). In the GOMOSCE project funded by Dstl, ART-SCENE is being extended to generate scenarios to explore complex trade-offs that arise at the beginning of system specification. However, the largest application of ART-SCENE has been in the air traffic management domain. Eurocontrol has funded the adoption and use of ART-SCENE to develop operational requirements for three major air traffic management systems. The first, for the CORA-2 project, is reported partially in (Mavin and Maiden 2003), and partially in Chapter 18 of this book. At the time of writing, ART-SCENE is being applied to discover requirements for DMAN, a NATS-managed Eurocontrol-owned Departure Manager system for major airports, and will soon be used to discover requirements for Eurocontrol's future Multi-Sector Planning system.

THE ART-SCENE APPROACH

ART-SCENE provides a four-layered environment for discovering requirements with scenarios. The four layers, and the relationships between them, are depicted graphically in Figure 9.1.

The innermost layer is how to represent and structure a scenario in ART-SCENE. ART-SCENE'S scenario generation and walkthrough tools manipulate these scenario structures and representations. The features of the walkthrough tool are used during the scenario walkthrough process with stakeholders to discover, acquire, and analyse their requirements. Scenario walkthroughs take place in structured workshops.

THE STRUCTURE AND REPRESENTATION OF AN ART-SCENE SCENARIO

An ART-SCENE scenario is composed of two parts—the normal course event sequence for the scenario, and the alternative courses that have been generated for each normal course event. The normal course event sequence for a simple example scenario—describing how a bus passenger using an information system to catch the right bus at a bus stop—is shown in Figure 9.2. The ART-SCENE environment generates zero, one or many possible alternative courses for each normal course event. Example alternatives for 1 of the normal course start events—the passenger looks at the Countdown display—are also shown in Figure 9.2. Generated alternative courses include what if this event does not occur in the scenario (i.e. the passenger does not look at the display), what if this event occurs earlier in time than expected in the scenario (i.e. looking before the passenger gets to the bus stop), and what if the passenger is unusually young or old.

The ART-SCENE tool maintains all scenarios in a scenarios database that implements and instantiates the scenario meta-model described using UML notation in Figure 9.3. An Event is a point in time when an Action either starts or ends. An Action is a description of some behaviour that involves one or more Agents, and has the attributes Type and Verb. One or more Agents can be involved in an Action. Each Agent has the attributes Name and Type. An Action can also manipulate one or more Objects. Distinguishing between Events that represent the times when an Action starts and ends enables ART-SCENE to represent concurrent Actions in a sequential list.

FIGURE 9.1 The four layers of the art-scene approach, and their interactions

FIGURE 9.2 art-scene's main scenario walkthrough window, showing a simple scenario related to the London Bus Countdown system – a computerised system that provides passengers with information about buses at bus stops

FIGURE 9.3 The art-scene scenario meta-model

For example, if Actions A and B occur concurrently, then this concurrency might be represented in the following sequential list: start-A, start-B, end-A, end-B.

Each normal course event is also associated with one or more alternative courses that are generated by the ART-SCENE tool. Different alternative courses are generated for events that start an action and for events that end an action. Each alternative course is an instantiation of a class of abnormal behaviour or state that can occur. As the section titled ‘The ART-SCENE Approach’ describes in more detail, the association of an alternative course and an alternative class to a normal course event is a parameter of the type and verb of the action linked to that event, the type and name of the agents involved in the action, the class of alternative, and the parameters set at scenario generation time.

The principal advantages of this simple meta-model are its robustness and applicability. The meta-model has remained stable for six years (first reported in Maiden 1998), having been evaluated using the applications outlined in the section titled ‘Position in the Life Cycle; Applicability. Furthermore these applications are diverse, demonstrating how the meta-model can be used to represent scenarios for different types of systems. The meta-model has been instantiated to represent scenarios for applications ranging from air traffic management and warfare scenarios to business processes and simple interactive applications such as bank automatic teller machines. Figure 9.2 demonstrates its application to the Countdown example. The normal course is a sequence of events that start actions of different types, for example, physical actions (the passenger looks at the Countdown display), human–computer interactions (the Countdown display shows the bus information for the relevant route) and cognitive actions (the passenger decides which bus route to use).

THE ART-SCENE SOFTWARE ENVIRONMENT

ART-SCENE scenarios are manipulated within the ART-SCENE software environment, which is composed of three basic components:

• The use case specification component. Use cases are inputs into the scenario generation process—this component enables developers to write and specify use cases, then export them to the use case database;
• The scenario generation component, which generates one or more scenarios from a use case specification in the use case database;
• The scenario presenter component, which presents the generated scenarios to stakeholders during a walkthrough in order to discover, acquire, and describe requirements.

The use case specification and scenario generation components run on a Windows 2000 platform supporting Access 2002 to maintain use cases and scenarios in the environment, and MS-Word extended with tailored macros and supporting Visual Basic applications to edit use case specifications. Three versions of the scenario presenter component have been developed to enable the walkthrough of scenarios maintained on the scenarios database:

1. A web-enabled tool developed using Microsoft Visual InterDev supporting dynamic ASP pages on top of the Microsoft Access database, and running on IE5.0 and above—the version described in this chapter;
2. A web-enabled tool for Personal Digital Assistants (PDAs) built with Microsoft's ASP.NET technology, a presentation layer consisting of a set of ASP.NET web pages, and the business logic realised by a set of components implemented in C# that interact with the database;
3. A tailored MS-Excel tool that enables the developers to download the scenario information into the workbook so that it can be transported to the walkthrough location.

The use case specification component: A development team uses the Use Case Specification component to write and import use cases into the tool. Firstly, it writes use case descriptions using a structured Microsoft Word template, and style and content guidelines from the CREWS-L'ECRITOIRE method (Rolland et al. 1998), enhanced with temporal action-ordering rules. The team then imports the use case into ART-SCENE, either manually or automatically. In the manual approach, the user uses a simple Visual Basic application to copy each use case action into the tool and define its attributes. The automated version uses macros implemented in the Microsoft Word template to import the normal course description of the use case directly into the use case database, setting attributes according to the domain lexicon defined for that project. The user then parameterises these attributes.

The scenario generation component: This component implements a two-step scenario generation algorithm to generate one or more scenarios. In the first step, the algorithm uses the use case specification to generate normal course scenarios from the action ordering rules and generation parameters in the use case specification. Each different possible ordering of normal course events is a different scenario. In the second step, the algorithm generates candidate alternative courses, which are expressed as ‘what-if’ questions for each normal course event, by querying a database that implements a simple model of abnormal behaviour and state in socio-technical systems. The model specifies 54 classes of abnormal behaviour and state using the structure shown in Figure 9.4. Some class hierarchies were derived from definitions of scenario concepts such as events and actions. Others were derived from error taxonomies in the cognitive science, human–computer interaction and safety-critical disciplines, and are reported at length in (Sutcliffe et al. 1998). For example, the algorithm generates alternative courses about events not occurring and actions not completed by instantiating the EC-coded classes in Figure 9.2, and about human agent mistakes, machine failures and interaction failures by instantiating the PE1-coded sub-classes in Figure 9.2.

ART-SCENE generates such domain-independent alternative courses using domain-independent type for each concept in the meta-model shown in Figure 9.3. Each normal course event describes either the start or the end of an action that is typed as cognitive, physical, communication, system-internal or composite, and involves agents of different types, for example human, machine and composite. For each generated normal course event, the algorithm applies 17 domain-independent rules that link the action and agent types involved in the event with the 54 abnormal behaviour and state classes to generate candidate alternative courses that instantiate these classes. For example, if the event starts a cognitive-type action involving a human-type agent, the algorithm generates alternative courses that instantiate the cognitive-error classes that specialise PE1 (e.g. what if the passenger makes a slip?). If the event starts a communication-type action involving two machine-type agents, then the algorithm generates alternative courses that instantiate the PE4 machine-communication classes (e.g. what if communication between the machines is slow?).

FIGURE 9.4 Hierarchical classes of the alternative courses in the original crews-savre database

The tool enables the development team to generate scenarios that fit a specific walkthrough and workshop participants. An ART-SCENE scenario is a dynamic artefact that can be changed and even re-generated at run-time. Therefore, ART-SCENE recommends that the team generates scenarios for the stakeholders who are anticipated to be at a specific walkthrough. This is achieved by setting different generation parameter values for a use case, so that the Scenario Generator generates two different scenarios for the same use case according to the stakeholders present. For example, in the air traffic management domain, air traffic controllers, and maintenance engineers are likely to have different requirements, often triggered during the walkthrough by different events of the same scenario. ART-SCENE can support this variability by generating two scenarios with different alternative courses, one describing abnormal traffic and human behaviours, the other describing abnormal system and communication behaviours and states. It supports this with scenario generation profiles that contain pre-defined parameters for generating different classes of alternative courses that can be reused at the click of a button during scenario generation.

The scenario presenter component: The third component is the Scenario Presenter. This chapter describes the web-enabled version, the main version used for scenario walkthroughs in ART-SCENE. The Scenario Presenter is implemented using Microsoft Visual InterDev, and supports usage with IE browser version 5.0 and above. Guest access to the Scenario Presenter is available from www.soi.city.ac.uk/artscene.

Providing web-enabled scenario walkthrough capabilities offers three advantages to stakeholders,

• Stakeholders often work in distributed environments—web-enabled access to a central server that stores the generated scenarios in a single database can increase stakeholder access to the scenarios and communication between stakeholders;
• Bringing stakeholders together in the same place at the same time is both difficult and expensive—web-enabled access offers possibilities for distributed and asynchronous scenario walkthroughs when linked with video-conferencing facilities;
• Stakeholders can review and even comment on scenarios that have been posted on the server prior to the face-to-face walkthrough, thus allowing the scenario to be revised beforehand in order to make best use of the face-to-face walkthrough time.

The Scenario Presenter satisfies different sets of requirements that we identified in order to improve walkthrough capabilities and features,

• Improved features that overcome limitations with the earlier MS-Excel tailored scenarios. Examples include improved look-and-feel, scrolling to read long alternative course descriptions, and displaying relevant normal and alternative course information in the same window (Mavin and Maiden 2003);
• New features that enable stakeholders to view scenarios from different perspectives. Examples include displaying normal course events that describe the start of actions only (thus removing analysis of concurrent actions), and viewing new requirements in a separate list or embedded in the normal course event sequence for the scenario. To manage these features, each Scenario Presenter user is allocated one of five access levels that correspond to five different scenario walkthrough roles—systems administrator, walkthrough facilitator, requirements engineer, stakeholder, and guest;
• New features that give stakeholders greater ownership and control over the scenarios (Carroll 2002). Examples include features to add, edit and delete scenario normal course events, remove generated alternative courses from view, and incorporate additional alternative courses not generated by the Scenario Generation component.

The most important window during a walkthrough is the scenario window shown in Figure 9.2, which presents a scenario in 4 parts. The left-side menu provides different functions for viewing the scenario and the requirements generated for it. The top-line buttons offer walkthrough functions (e.g. next or previous event) and functions to add, edit or delete events, comments and requirements. The left-hand main section describes the normal course event sequence for the scenario. Each event describes the start or end of an action, thus enabling a scenario to describe concurrent actions in this text-list form. The right-hand main section describes generated alternative courses for each normal course event, presented in the form of ‘what-if’ questions. Different alternative courses are presented for different normal course events.

FIGURE 9.5 Adding requirements and comments in art-scene

Some of the most important features are accessed using the top-line buttons. Each major feature is available either for the selected event in the normal course (accessible above the normal course event sequence) or the selected alternative course (accessible above the alternative course list). The most important features are the add comment [C] and add requirement [R] features shown in Figure 9.5. A user can enter a requirement or comment associated with any normal or alternative course event at any time during a walkthrough. To add a requirement, the Scenario Presenter allows the user to specify the type, description, rationale, and source of the requirement. These attributes are a subset of the VOLERE requirements shell attributes (Robertson and Robertson 1999) that are used to describe requirements in the RESCUE process. We chose the type, description, rationale, and source attributes to be completed during a walkthrough as each attribute can be specified during a walkthrough independently of other (unknown) requirements such as conflicts and customisation satisfaction rating. Likewise, a user can add one or more comments to any event and define its level of importance and whether it requires a change to the scenario.

The left-side menu provides different functions for viewing the scenario and the requirements generated for it. The user can view all of the requirements generated using the scenario, all requirements generated for the selected normal course or requirements generated for a selected alternative course event in list form. Alternatively, the user can view the requirements inserted into the scenario normal course event sequence underneath the associated event. The user can also choose to restrict the amount of information presented on the scenario. Figure 9.6 shows the same Countdown scenario as in Figure 9.2. However, the end-action events are hidden and unwanted alternative courses are deselected using the tick boxes, so that these are not shown during the walkthrough.

FIGURE 9.6 The same Countdown scenario in art-scene, after tailoring it for a scenario walkthrough

All users, from guests to facilitators, are given a unique ID and password that provides them access to the scenarios made available to them at different access levels by the system administrator. At any time the user can produce a report in an MS-Word report structure on the status, requirements and comments for any scenario.

FACILITATING SCENARIO WALKTHROUGHS

The Scenario Presenter provides features that are needed to undertake systematic scenario walkthroughs. In ART-SCENE, we integrate these features with facilitation and process guidelines for conducting a walkthrough (see Figure 9.7). To ensure cost-effective stakeholder involvement, we normally schedule a walkthrough to last for half a day. For most applications, this enables the walkthrough of one scenario and possible variation scenarios (generated from variations in the original use case). During an ART-SCENE walkthrough we recommend that each stakeholder has access to documents containing the use case specification, existing stakeholder requirements, and related background documents such as the Human Activity Models and i* system models recommended in the RESCUE process (Jones and Maiden 2003).

FIGURE 9.7 An art-scene scenario walkthrough, demonstrating the actions of the facilitator, scribe, and stakeholders

A scenario walkthrough with ART-SCENE can be busy, so we recommend that two people who fulfil different roles manage a walkthrough. The first, the facilitator, controls the walkthrough process, and in particular, the communication with and between stakeholders that discover and acquire new requirements, comments and changes to the scenario. The second person, the scribe, controls the use of the Scenario Presenter tool and enters information about the requirements, comments and changes.

The facilitator guides the walkthrough of the scenario using a simple two-stage process. In the first stage, the facilitator leads the walkthrough of the normal course events. In the second stage, the facilitator leads the walkthrough of the alternative courses for each normal course event.

For each normal and alternative course event, the facilitator asks the stakeholders to recognise whether

1. This event might occur;
2. This event is relevant to the future system;
3. Does the future system, as currently specified in the requirement document, handle the event?

If the answer to the first question is NO, then stakeholders can propose changes to the scenarios such as edits to the normal course event sequence or removal of candidate alternative courses.

If the answer to the first question is YES but the answer to the second question is NO, then the walkthrough discovers events that are outside of the scope of the design of the socio-technical system and can be marked, using comments, as such.

If the answer to the first two questions is YES but the answer to the third question is NO, then omissions have been discovered and more new requirements for the socio-technical system can be specified. Furthermore, if the answer to the third question is also YES, then the scribe can use the comment feature to link the event to existing requirements via the requirement ID, thus improving the traceability links between scenario events and system requirements.

THE SCENARIO WORKSHOP ENVIRONMENT

ART-SCENE also recommends a workshop structure (see e.g. Chapter 18, Figure 9.6) for holding scenario walkthroughs. The walkthrough room should be structured according to RAD and JAD guidelines. Stakeholders sit around a U-shaped table with copies of documentation relevant to the scenario to be walked through. The facilitator stands inside this U-shaped table at the focal point of the interaction in the walkthrough. The ART-SCENE scenario is permanently visible using a LCD projector onto the screen. The screen is surrounded by prompts that encourage requirements discovery and creative thinking, and by a simple visual reminder of the process described in the previous section. The scribe sits next to the facilitator and manages information being stored into the Scenario Presenter tool.

WORKED EXAMPLE

In this section, I demonstrate the ART-SCENE environment using the Countdown system already presented. The example describes the generation of a scenario from a use case specified by a developer, and a walkthrough of this scenario to discover requirements.

Firstly, the software developers produce a use case model and description according to the Rational Unified Process and UML. The developers work with other stakeholders to produce the use case description implemented in Microsoft Word shown in Figure 9.8. The template captures important use case attributes as well as the normal course description. The developers then revise the normal course description to produce a more structured use case specification that is the input into other ART-SCENE software components. The template implements macros that check the correctness of simple action descriptions in the normal course description, and parse checked action descriptions to derive the agent, object, and verb table for each action in the normal course. The parsing mechanism is very simple. It relies on prior knowledge of use case agents and objects (entered by the developers in one of the specification tables) and a domain lexicon that restricts the developers in the verbs and agent and object names that can be used in the normal course description.

The developers also add parameter values to the use case specification to constrain scenario generation. These parameters are shown in the scenario generation component in Figure 9.8. The developers can define which classes of abnormal behaviour and state the algorithm will use to generate scenario alternative courses. Likewise, the developers can specify how general or specific the alternative courses should be by defining the levels in each class hierarchy that the alternative courses should be generated from.

FIGURE 9.8 One use case specification for the Countdown example

In this example, the Scenario Generation component uses the use case specification to generate scenarios for the use case. As the specification does not define possible concurrent behaviour between actions, only the scenario with the normal course event sequence shown in Figure 9.2 is generated. The current version of the Scenario Generation component has been designed for maintainability and modifiability rather than performance. Scenario generation rules are maintained in relational database tables, and the algorithm retrieves each rule from the relevant database table when considering each candidate alternative course for each normal course event. On the current ART-SCENE hardware set-up, generating this Countdown scenario takes 40 minutes long for a computer-based process but still much quicker than human scenario development.

During a scenario walkthrough with bus passenger representatives, a facilitator and scribe use the Scenario Presenter component to discover, acquire and describe requirements for the Countdown system. Consider event 1—the passenger looks at the Countdown display—shown in Figure 9.1. The facilitator questions the stakeholders using the 3-question process, leading to the following candidate requirements for Countdown:

• A passenger shall be able to locate the Countdown display without difficulties;
• A passenger shall be able to read the Countdown display before reaching the bus stop;
• The Countdown display will always be available to a passenger.

Later, the facilitator leads the stakeholders to consider possible alternative courses for event-1, again using the three-question process. Table 9.1 identifies some possible requirements that can be discovered or acquired from the scenario. Abnormal event timings lead to requirements about accessibility to bus information before arriving at and at the bus stop. Abnormal characteristics of human actors lead to requirements about the usability and accessibility of the system.

TABLE 9.1 Possible requirements and their sources for the Countdown example

COMPARISONS

Other workshop approaches can also be used to explore and validate scenarios and use cases, as for example some of Ellen Gottesdiener's techniques—see Chapter 5 in this volume.

One objective for ART-SCENE is that it should be compatible with and complementary to commercial uses of scenarios and use cases in the development life cycle. The most immediate comparison, therefore, is with the UML and software environments that support UML-based development. Some of the most sophisticated tools offer model-checking features and support limited model simulation, primarily using UML message sequence charts. Whilst such simulations are useful for exploring model completeness and correctness (e.g. Haumer et al. 1999), they depend on existing UML models for normal courses of use cases. ART-SCENE is different in two important ways. Firstly, it supports requirements discovery earlier in the life cycle, before most UML modelling of the software system starts. Secondly, one of its main advantages is automatic generation of scenario alternative courses to explore requirements completeness prior to UML modelling. As such, we see ART-SCENE as supporting rather than competing with UML-based specification processes that adopt the Rational Unified Process (Jacobson et al. 2000).

Requirements engineering research has seen a focus on scenarios in the last decade. ART-SCENE and its contributing projects, CREWS and SIMP, have been influenced by research developments. This chapter cannot completely review this work; however, comparisons with other leading-edge research in scenarios are worth making. CREWS-SAVRE was developed as part of the CREWS project that also led to other processes and software tools. The CREWS-L'ECRITOIRE approach integrates goal and scenario analyses (Rolland et al. 1998). Goals are decomposed using scenarios that describe future system behaviour that, in turn, can enable the discovery of new goals. Unlike CREWS-SAVRE, the emphasis is on exploring different means of achieving goals rather than exploring possible alternative courses.

CREWS-EVE uses multi-media representations of scenarios (e.g. with video clips) to provide more contextual data about a current system's usage and environment to inform requirements acquisition and traceability (Haumer et al. 1999). It offers strong traceability capabilities but little of the process guidance walking through requirements and discovering requirements. To remedy this, we are currently extending the Scenario Presenter with multi-media scenario capabilities that can inform systematic scenario walkthroughs.

Other work in the SIMP project has used scenarios to explore the likelihood of human error in the use of future socio-technical systems (Sutcliffe and Gregoriades 2002). It relies on computational models of human error from psychology that have been implemented using Bayesian Belief Networks (BBNs). These models are used to predict on the basis of network computations the probability of an alternative course arising and the presentation of complex data using visualisations, rather than rely on human expertise and recognition. As such, they rely heavily on accurate data input and tuning of the network's probabilities to a specific domain, in sharp contrast to ART-SCENE'S approach to aid facilitators and stakeholders during walkthroughs.

KEYWORDS

Use Cases

Scenarios

Requirements Discovery

Systematic Walkthroughs

Scenario Workshops

Integrated Approach

REFERENCES

Baddeley, A.D., Human Memory: Theory and Practice, Lawrence Erlbaum Associates, Hove, UK, 1990.

Carroll, J.M., Scenarios and design cognition, Proceedings of IEEE Joint International Conference on Requirements Engineering, IEEE Computer Society Press, 2002, pp. 3–5.

Haumer, P., Heymans, P., Jarke, M., and Pohl, K., Bridging the gap between past and future in RE: a scenario-based approach, Proceedings of the 4^th IEEE International Symposium on Requirements Engineering, IEEE Computer Society Press, 1999, pp. 66–73.

Jacobson, I., Booch, G., and Rumbaugh, J., The Unified Software Development Process, Addison-Wesley-Longman, 2000.

Jones, S., Maiden, N.A.M., Manning, S., and Greenwood, J., Activity Modelling in the Specification of Operational Requirements: Work in Progress', Proceedings Bridging the Gaps II: Bridging the Gaps Between Software Engineering and Human-Computer Interaction, ICSE2004 Workshop, IEE Press, 2004, 1–8.

Maiden, N.A.M., SAVRE: Scenarios for acquiring and validating requirements, Journal of Automated Software Engineering, 5, 419–446, 1998.

Maiden, N.A.M. and Corrall, D., Scenario-driven systems engineering, Proceedings of IEEE Informatics Division Seminar ‘Scenarios Through the Life Cycle’, London, December 7, 2000.

Mavin, A. and Maiden, N.A.M., Determining socio-technical systems requirements: experiences with generating and walking through scenarios, Proceedings of the 11^th International Conference on Requirements Engineering, IEEE Computer Society Press, 2003, pp. 213–222.

Maiden, N.A.M., Minocha, S., Manning, K., and Ryan, M., CREWS-SAVRE: Scenarios for acquiring and validating requirements, Proceedings of the 3^rd International Conference on Requirements Engineering (ICRE '98), IEEE Computer Society Press, 1998, pp. 148–155.

Robertson, S. and Robertson, J., Mastering the Requirements Process, Addison-Wesley, 1999.

Rolland, C., Souveyet, C., and Ben Achour, C., 1998, Guiding goal modelling using scenarios, IEEE Transactions on Software Engineering, 24(12), 1055–1071.

Sutcliffe, A.G. and Gregoriades, A., Validating functional requirements with scenarios, Proceedings of IEEE Joint International Conference on Requirements Engineering, IEEE Computer Society Press, 2002, pp. 181–188.

Sutcliffe, A.G., Maiden, N.A.M., Minocha, S., and Manuel, D., Supporting scenario-based requirements engineering, IEEE Transactions on Software Engineering, 24(12), 1072–1088, 1998.

Zhu X., Maiden, N.A.M., and Pavan, P., Scenarios: bringing requirements and architectures together, Proceedings SCESM 2003, 2nd International Workshop on Scenarios and State Machines: Models, Algorithms, and Tools, held at ICSE 2003, Portland, Oregon, USA, May 2003.

RECOMMENDED READING

Most information about ART-SCENE is available through the ART-SCENE website at www.soi.city.ac.uk/artscene, and in academic papers available from the author or off the author's website.