Scenarios can be understood in a variety of ways, several of them useful in systems engineering. A scenario can be a sequence of activities, or a more or less richly branched structure of such sequences. Branches can represent alternatives or parallels, or various intermediate options. A scenario can be concrete or abstract; and it can describe either the World or the Machine.
Scenarios can be represented in a rich variety of ways, including text, databases, diagrams, video, animations, cartoons, storyboards, acted scenes, and collaborative workshops. All of these may have applications in systems engineering.
Scenarios can be used throughout the system life-cycle to clarify business processes; to set requirements into context for both stakeholders and systems engineers; to validate user requirements before system specification begins; to guide system specification and design; to provide the basis of acceptance test scripts; and to validate suggested tests.
Scenarios come in a bewildering array of forms, and even engineers who broadly agree on what a scenario can be used for may differ on what exactly a scenario is. In this paper, I will try to avoid controversy and academic detail, and focus on the main issues and benefits of using scenarios.
In some definitions, a scenario is barely different from a description of a static situation; but most scenario engineers have gravitated towards a pragmatic usage where a scenario means some kind of description of a set of activities, most commonly sequential. This has an obvious bearing on the application of scenarios to describe how a system is to behave when interacting with its users.
A useful distinction can be drawn between concrete and abstract scenarios. A concrete scenario involves specific actors, places, and times:
John sets the alarm and locks the door of his chic Clerkenwell warehouse apartment at 8 a.m. on Monday the 2nd October 2000. The alarm detects a possible burglar at 11:15, and signals the HSS call centre at 11:16. Jane, the HSS operator on duty, ...
An abstract scenario describes what happens in generic (class) terms:
The Householder sets the alarm, and locks the door. The alarm detects a possible intruder, and signals the call centre. The operator ...
Both types of scenario have their uses in systems engineering. Some engineers (e.g. Leffingwell) strongly advocate making scenarios as concrete and humorous as possible, to bring them to life and enhance communication between stakeholders and engineers. Conversely, abstract scenarios are closer to traditional requirements.
Assuming, then, that scenarios are sets of activities, the simplest, and usually the first encountered, kind of scenario is a straight sequential path from start to finish, one step (or task, or activity) after another.
Scenarios can however branch; branches can constitute alternative paths, though there is usually one primary, normal, or 'happy day' path that stakeholders would expect. Secondary paths can simply be allowable but less favoured choices, or may be followed only in response to specific undesired events, sometimes called exceptions (Alexander). In some scenarios, several paths may be allowed or be required to be followed at once; different degrees of parallelism may be distinguished, from weak - follow one or more paths, to strong - follow all paths at once.
Finally, the distinction between the World and the Machine is also relevant to scenarios (Jackson). Initially, during business process modelling and requirements elicitation, scenarios should describe the (desired) state of events in the world. Later, during system specification, it may be useful also to construct system-related scenarios describing intended states of events in the machine. The popular term 'use case' implies the existence of a system and a point of view that looks outwards from a system to its 'users', suggesting that the approach is most comfortable during system specification. The older term 'operational scenario' conversely implies the existence of operations in the world, and may thus be more satisfactory for thinking about the domain and people's business requirements.
As in other areas of systems and software engineering, there are perhaps more schools of thought concerning notations and representations of scenarios than on any other topic. Among other representations, engineers have proposed Text, Databases, Diagrams, Video, Animations, Cartoons, Storyboards, Acted Scenes, and Collaborative Workshops as ways of describing scenarios. All of these different representations may well be useful in specific situations and with appropriate groups of people. One key function of scenarios is to help people communicate about the systems they are involved in - whether they have a stake in using systems when they become available, or in developing the systems. Stakeholders are often unfamiliar with the language used by engineers. Scenarios offer a way of bridging the gap and helping to ensure that different groups of people understand each other.
The issue of choice of representation would ideally be a purely pragmatic one - people would select the best for their situation. Some 'methods' are quite ideological about notations, others not at all. Here we look as pragmatically as possible at some of the best-known representations.
The idea of the Use Case (Jacobson) supposes that the world of business is divided into neatly addressable cases where a user interacts with a system. The use case graphical notation is appealingly simple - a manikin connected to an elliptical bubble. Each bubble means a use case, and a list of several of them can be arranged to form a diagram. But even if they are arranged in a vertical list, as they usually are, this does not imply sequence, according to UML. Visually the arrangement is certainly misleading, and in practice it is natural for UML users to put the first step at the top and the next one after it, if the steps are in fact sequential.
The driving force behind the concept was the crisis in software engineering. Jacobson's idea was to use scenarios as candidate chunks for separate implementation, leading to small, easily manageable sub-projects. This is not an ideal organisation when there are very many cases, especially if they overlap.
There has been much debate about whether a use case is simply a synonym for scenario. The question could be answered by obtaining a precise definition of both terms, but in practice both are quite elastic. Both scenarios and use cases can be concrete or abstract. Some engineers appear to insist on having exactly one Actor per use case, though they also appear implicitly to accept that their can be at least two agents, namely a human actor and a system or machine. Some engineers talk about use of a single specific system, but this leaves unanswered the harder question of what level use cases should be applied at - to whole systems, to subsystems, or to interaction with components? For instance, a classic example chosen by use case advocates is interaction with an Automatic Teller Machine; yet this is a small part of a bank's system, which includes a secure network and a database holding customer accounts.
The point is, surely, that scenarios make sense at all levels, and it is helpful to be able to view transactions at different levels of abstraction at different times. It is also helpful to be able to organise scenarios or use cases from different levels into a coherent structure (Alexander, Cockburn). UML notation can be helpful, but currently only goes part of the way towards resolving these issues.
Agent models are useful before collecting scenarios, as they identify actors and machine agents and their conversations or interactions. In this way they help to focus attention on what is in scope and what is not. This includes distinguishing clearly between actors involved with using a system, external agents who may play incidental parts, and other stakeholders who may benefit but who do not themselves use the system.
In principle, each conversation named in an agent model can be analysed into a lower-level scenario; high-level scenarios may traverse the whole agent model, end to end. For large systems, this ability to organise processes at different scales may be especially beneficial.
The use of a goal model encourages thinking about alternative ways of satisfying business goals, and may further help to prevent people from rushing into solution thinking before the problems to be solved are well defined.
Goal or task models can be used to generate a range of diagrams including sequence or swimlanes diagrams, as well as test scripts, and are ideal for animation to validate scenarios with stakeholders. These models may also help stakeholders and developers to find alternate paths and exceptions before they cause problems during development.
Goal models have a well-established place in management consultancy and in human-computer interaction, but remain little used despite academic efforts in systems and requirements engineering.
Flowcharts are a traditional means of representing scenarios at different scales. They became unfashionable in software engineering through being used early on at very low level to represent program structure. However they are still useful, and remain popular in business process modelling. Modern notations such as UML flowcharts have different symbols, but deliver broadly the same results. Flowcharts tend to emphasise sequentiality and decision-making at the expense of describing roles and system involvement.
Many other representations are possibly useful in systems engineering. For instance, storyboards can describe situations, roles, and task sequences quickly and compactly. Simple graphical representations may have advantages, e.g. for multi-national products and for use with children. Storyboards have long been used in planning film shoots, where their immediacy assists in different ways - for instance, with continuity, guidance to actors and producers, and camera setup; and again later with editing. The storyboard scenario thus pays for itself many times over.
Graphical and physical representations such as cartoons, animations, video and acted scenes make it easier for people to envisage a situation, such as the possible uses of a future system. For example, researchers at BT use such means to identify and assess requirements for new products.
Scenarios can assist in all phases of the systems engineering life-cycle. They can clarify system scope; help to identify stakeholders, situations, and needs; organise requirements; guide design and coding; and provide scripts for testing. But throughout the cycle, their main contribution is perhaps simply to improve project communications between all the groups of people involved.
Briefly, here are some of the ways that scenarios can be applied to help engineer better systems.
A process is a set of more or less standardised and repeatable tasks, related in time and by informational and other dependencies. A scenario is a description of a more or less specific instance of some part of such a process. There are many ways of reaching a satisfactory understanding, including ethnographic observation, as well as traditional interviewing and process modelling.
A scenarios workshop can represent a sequence of tasks directly by role-play. A task can be described verbally by a player, or acted out in a variety of ways. The 'execution path' can be symbolised by passing a token such as a juggling ball to the player whose turn it is next. Both singly- and multiply-threaded scenarios can be simulated in this way. Stakeholders see, often for the first time, how their tasks relate to the overall process, and many misconceptions and confusions can be banished in a playful workshop.
A sequence of scenario steps forms an ideal set of placeholders for requirements (both functions and constraints). They put requirements in a context of what came before, and what comes next. The branching paths translate quite naturally into a traditional hierarchical document structure.
Scenarios can be animated e.g. by stepping through a goal model interactively, by showing a sequence of images, or by acting out scenarios in a workshop. This allows users to see what systems would do, if built. They can then correct any mistakes or omissions made by the developers. In effect, this approach allows systems to be 'tested' at very low cost before they are designed.
Numerous 'Scenario-Based Design' approaches have been attempted (Carroll). Two basic situations need to be distinguished: either the project works co-operatively, with developers and stakeholders meeting frequently and solving problems together; or developers are unable to speak directly to system users, in which case scenarios may offer a valuable echo of 'the voice of the customers'. Scenarios show what each small part of a system actually needs to do, which is simply to deliver the results that system users and other stakeholders want. Scenarios are perhaps especially beneficial in large systems projects where sub-subcontractors are unlikely to meet users face to face - at least they can meet in text and graphics.
In a co-operative project, stakeholders can explain the scenarios they envisage directly, and indeed can devise new scenarios (such as exceptions and embellishments) in response to early working versions shown to them by developers. The issue of representation then becomes quite secondary.
Extreme Programming or XP (Beck) is worth mentioning, as it uses scenarios in the form of 'user stories'. These seem to be simple, more or less linear use cases, described informally. Acceptance tests are written straight from the scenarios - and used directly as specifications. Programs are then written and tested directly from the user stories. The technique is accompanied by pair programming and other practices such as 'do the simplest thing that could possibly work'. Some of these seem doubtful in a systems engineering environment, but even anarchists may have good ideas, and XP has certainly livened up the debate on scenario usage.
Any scenario path is a possible test case. If there is any significant number of alternatives and exceptions, there will be a combinatorially large number of possible test cases. This situation is familiar to all test engineers, who know that testing needs to cover all scenario steps at least once, and all major paths. The process of generating test cases can clearly be partly automated but usually needs judgement to select efficient tests (Alexander, Maiden) but is often still handled manually. Test cases need additional structure in the shape of test attributes (for each Step), e.g. Criteria, Result, Tester, Date to enable them to function as practical test scripts.
Scenarios have many uses in systems engineering, e.g. process description, requirements elicitation and verification, system specification, guidance for system design and software coding, construction of test scripts.
Scenarios can be represented in varied and useful ways, provide neutral languages in which stakeholders can describe their needs to developers, and could perhaps with benefit be applied much more often in systems projects.
| Alexander: | Ian Alexander, Migrating Towards Co-operative Requirements Engineering. CCEJ, 1999, 9, (1), pp. 17-22 Scenario Plus User Guide and Reference Manual, http://www.scenarioplus.org.uk, 1999 Ian Alexander, Scenario-Driven Search Finds More Exceptions, Proceedings 11th International Workshop on Database and Expert Systems Applications (DEXA 2000), 4-8 September 2000, Greenwich, London, England. IEEE Computer Society pp 991-994 |
| Beck: | Kent Beck, Extreme Programming Explained: embrace change, Addison-Wesley 1999 |
| Carroll: | John M. Carroll, Scenario-Based Design, envisioning work and technology in System development, John Wiley, 1995. |
| Cockburn: | Alistair Cockburn, Structuring Use Cases with Goals, JOOP, September and November 1997 |
| Graham: | Ian Graham, Requirements Engineering and Rapid Development, an object-oriented approach, Addison-Wesley, 1998. |
| Jackson: | Michael Jackson, Software Requirements & Specifications, a lexicon of practice, principles and prejudices, Addison-Wesley, 1995. |
| Jacobson: | Jacobson, I., et al: Object-Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1992 |
| Leffingwell: | Managing Software Requirements - a unified approach, Dean Leffingwell and Don Widrig, Object Technology Series, Addison-Wesley, 2000 |
| Maiden: | Maiden N.A.M., 1998, SAVRE: Scenarios for Acquiring and Validating Requirements, Journal of Automated Software Engineering 5, 419-446. |
Edited for web 3 October 2000 Home