Book Review: Scenarios, Stories, Use Cases
Through the Systems Development Life-Cycle

Editors: Ian Alexander and Neil Maiden John Wiley, August 2004 ISBN 0470861940 Buy it from Amazon.com (commission paid) Buy it from Amazon.co.uk (commission paid) Other Reviews Requirements Training & Consultancy Also by Ian Alexander:    Writing Better Requirements    Discovering Requirements

Biographies & Author Photographs

Part I: Overview

1. Introduction: Scenarios in System Development Ian Alexander (short online version)
2. Context: Scenario-Based Approaches Neil Maiden & Ian Alexander

Part II: Scenarios through the System Life-Cycle: Techniques

Discovery & Validation

1. Scenarios in Requirements Discovery Suzanne Robertson
2. Scenarios for Innovation (SUNA) Joy Van Helvert & Chris Fowler
3. Running a Use Case/Scenario Workshop Ellen Gottesdiener
4. Alternative World Scenarios to Find Requirement Stability David Bush
5. Negative Scenarios & Misuse Cases Ian Alexander
6. Authoring Use Cases Camille Salinesi
7. Systematic Scenario Walkthroughs Neil Maiden

   Collaborative Approaches

8. Role of Scenarios in Contextual Design Karen Holtzblatt

   Design & Implementation

9. Scenario-Based Design of HCI David Benyon & Catriona Macaulay
10. Use Case-Based Software Development Peter Haumer
11. User Stories in Agile Software Development Kent Beck & David West

    Testing

12. Use Cases, Test Cases Ian Alexander

    Management

13. 'Stories' and Life-Cycle Process Models Andrew Farncombe

Part III: Scenarios in Action: Case Studies

1. Story Use & Reuse in Automotive Systems Thomas Zink & Frank Houdek
2. Use and Misuse Cases in Railway Systems Ian Alexander & Andrew Farncombe
3. Scenarios in Air Traffic Control Perminder Sahota
4. Scenarios & Quality Requirements in Telecommunications Juha Savolainen
5. Scenarios in Rail Rolling Stock with REVEAL Alistair Mavin
6. Evaluating Scenarios by Simulation Pericles Loucopoulos

Part IV: The Way Ahead

1. Putting Scenarios into Practice Ian Alexander & Ramin Tavakoli
2. Teaching Computer Scientists to Make Use Mary Beth Rosson, John Carroll, Con Rodi
3. What Scenarios (Still) Aren't Good For The Editors
4. The Future of Scenarios The Editors

Much of the recent history of large engineering projects - software or systems - has been a tale of waste, error, mismanagement, over-optimism, and lack of proper planning for likely costs and risks. Projects come in late, over budget, and with miserably reduced functionality. Systems sometimes never work; fail on their first period of operational stress; or are permanently unreliable and costly to maintain. We will not name names, as it is fruitless to play the blame game: indeed, engineering systems badly and passing blame are two sides of the same coin. In any case it is all too easy to find examples in news reports of the demise of famous projects.

By the way, we don't think this is a software issue: it seems to affect complex systems of diverse kinds. The solution can't therefore be a matter of finding better software-specific tools and techniques; it must be something that helps master complexity.

People have suggested many possible cures for this disease. Most come down to two things:

• the needs that systems are supposed to fulfil ought to be defined much earlier, and far more carefully;
• people on projects ought to be made aware of, and become skilled in techniques to define needs adequately.

We think that a critical element that is lacking is therefore communication, and in particular skill in techniques for communicating needs. With the other authors of this book, we believe that the scenario is one of the most powerful techniques for discovering and communicating requirements, and often the first choice for organising them.

On a lighter note, scenarios pass the party test, where the requirements engineer has to explain what he or she does for a living to a stranger in fifteen seconds. Where

If you are wondering whether we recommend replacing requirements entirely with scenarios in all circumstances, we can at once tell you that we think that distinctly unwise, for several reasons:

• the main strength of scenarios is in telling the story of functional behaviour; it is possible to cover various non-functional aspects with stories, but it's doubtful if such coverage can ever be comprehensive - even if that was desirable.
• many engineers, organisations and standards bodies are strongly attached to traditional requirement forms (like 'The system shall …'), and if those forms work for those people, they should continue using them - anyway, they may have little choice if they have to comply with standards. People work better with familiar artefacts and work processes, even if these sometimes seem to outsiders to be sub-optimal.
• making a scenario approach work well often requires flair, experimentation, and the courage to take risks: to run active workshops rather than writing up requirements in a back room. The implied style of engineering simply does not suit everybody.
• the needs governing large projects are complex, and require a range of information structures including stakeholder and goal models, business rules, algorithms and formal specifications of behaviour, interface definitions (protocols, data structures, hardware connections), and commercial and physical constraints (like cost, size, and weight), many of which can not be framed as scenarios.

Other vital ingredients of a successful project include:

• realistic and supportive managers, including one who champions the project;
• effective training for engineers, i.e. practical knowledge that changes their behaviour;
• sufficient contact with stakeholders, whether with traditional meetings and reviews, or some form of participatory design or inquiry cycle, to ensure that the project is working from valid requirements;
• sufficient openness within teams to enable people to speak out when absurd plans are placed on the table ("test and debug a million lines of safety-critical air traffic control software in three months");

- but these are not all within our scope: scenarios don't do everything. However, much of the book is in one way or another about helping to ensure sufficient contact with stakeholders, and the book will we hope help to inform engineers in a practical way about using scenarios.

In this book we present a range of scenario techniques from light, sketchy and agile to careful and systematic. There is no single 'right way' to use scenarios; we celebrate diversity in requirements discovery and modelling. There is supposedly a saying among French cooks that the English have only two sauces: brown Windsor soup (salted gravy thickened with flour); and custard (sweetened milk thickened with cornflour). Obviously if such a thing were true, the English diet would be somewhat monotonous. Happily, there are as many ways of using scenarios as there are French sauces - for every palate, season, and occasion; and like sauces, each basic scenario technique has any number of variations.

It would have been possible while editing to impose a uniform style and 'voice' on all the contributed chapters; but while we have arranged for a common chapter structure and cross-references, we have chosen to encourage authors to speak in their own way. This may help readers to see that people - engineers and researchers - come to technical issues from different directions, with their own backgrounds and preconceptions, just as project stakeholders do. No-one on a project has a monopoly on truth; a major strength of scenario approaches is that they allow stakeholders to share and own a description of what they want. Indeed, each step of an operational scenario may be the responsibility of a different player.

Equally there are many kinds of scenario structure, and these may well be applicable in projects of different types. The question of which approach is best for a given type of project is open, and in the final part of this book we sketch some preliminary answers to it.

What all the scenario techniques described here have in common is the motivation to improve industrial practice; a clearly-defined approach which has been applied on projects; and a grounding in theory.

We have taken care to ensure a consistent framework for each contribution. There are no tall claims here for commercial tools; equally, there are no chapters asserting elegant but untried academic hypotheses.

The book is structured as a whole to put across the message that scenarios work, and are good for your projects:

This is a timely book that will serve as an excellent reference point for practitioners and researchers trying to resolve the relationship between use cases and scenarios. Alexander and Maiden have contributed significantly to the burgeoning popularity of scenarios in requirements engineering and, at first, I was slightly surprised that they'd restricted themselves to the role of editors (although they do contribute many of the chapters). In choosing this format, however, they have produced a book with a much wider scope than would otherwise have been possible. Despite the variety in tone and descriptive clarity inevitable in multi-author volumes, this is a book that is jam-packed with goodies. There's something tangible and useful here for everyone with an interest in the direction that modern systems development is heading.

Jacobsen first introduced the Use Case little over 10 years ago. Yet in that time it has both established itself in the main-stream, and been adopted by the radical wings of the development community. Few innovations in system development can have achieved this so quickly so it's perhaps unsurprising that a certain amount of confusion still exists about what Use Cases are and how they're used. Use Cases don't just establish which actors in a system's environment it interacts with, of course. To be useful, they also need to describe the nature of the interaction. To do that, they use scenarios.

Scenario has become a seriously overloaded term. For many (most?) people exposed to UML, scenarios have become closely identified with Use Cases. A side-effect of this is that scenarios have come to mean sequences of events (or even more concretely, sequences of method invocations). Look in most modern dictionaries and something along these lines will be one of the definitions of scenario. However, they will also include the original meaning - an outline for a play. Quite possibly, they will also include a looser form of the sequence of event definition in which scenario can mean some imagined set of circumstances.

This book reclaims all these types of scenario from Use Cases. Of course, many of the chapters are concerned with elaborating the relationship between scenarios and Use Cases and of that between scenarios and requirements. But others describe other applications of scenario, in all their forms, in systems engineering. These range from envisioning changes to systems' business environment to using storyboards for exploring how systems work to the validation of simulations for the Athens Olympics.

This diversity is mostly a good thing. The book represents a timely stock-take of both the state-of-the-practice and the state-of-the-art, with excellent chapters that clearly explain (for example) mechanisms for generating requirements from scenarios, using workshops to generate scenarios, managing scenarios through the life-cycle and how scenarios fit into different project and process types. There are honest appraisals from the editors on what they are good and not so good for and, perhaps as a side-effect, a balanced and informed assessment of the current agile vs. 'traditional' process model debate.

The only down-side of the book's diversity is that the reader (or this reader, at any rate) is sometimes left confused by all the different uses and life-cycle contexts. In particular, it becomes clear that the requirements engineering and human-computer interaction communities have evolved related but subtly different concepts of how and where to use scenarios.

At the core of the book are two sections. The first comprises chapters describing tools, methods and approaches in a variety of domains and process types. Despite the range of approaches described and some convincing arguments for their use in (for example) testing, it is clear that the utility of scenarios is heavily weighted to the early stages of the development process; the ones that in, conventional models at least, result in a requirements specification document.

The second core section is all about case studies to establish the different approaches' credentials and help the reader learn from real practical experience. As with the earlier section, a skew is revealed in that most of the examples are drawn from large systems engineering projects. These are all fascinating but the over-representation of large heavy-duty projects is slightly unfortunate because the earlier section included interesting and entrenched chapters on scenarios in RUP and agile development. It would have been good to learn more about how scenarios help realise the type of project that these approaches are optimised for.

However, these are minor defects that only slightly detract from the book's value. That it works so well overall is a credit to the editors who, in addition to their own specialist contributions, have taken great trouble to pull the different strands together and help the reader understand and classify the different contributions. When the inclusion of a set of really useful resources (scenario templates, for example) is taken into account, the book represents a substantial contribution to the maturation of scenarios in system development.

© Pete Sawyer 2004

Back to Top

An interesting-looking book has just dropped into my hands. Scenarios, Stories, Use Cases Through the Systems Development Life-Cycle, edited by Ian Alexander and Neil Maiden (Wiley, 2004) seems to be filed on the systems development shelves, which is no doubt why it hasn't raised it's head over the User-Centred Design parapet.

And that is exactly where the book should be. Throughout the HCI/UCD community, there are clusters of people saying we need to interact more with the systems engineering and software development people, present at their conferences, convey ideas. Alexander and Maiden are addressing those communities directly through the bookshelves, battling it out with tomes on module testing, PRINCE2 and all the rest, rather than nestling in the UCD bookshelf comfort zone.

The volume kicks off with a great quote from an unexpected quarter: "What's it for?" said President Chirac on being shown the Millenium Dome in Greenwich (London). Which is what any developer ought to be asking when any new system twinkles in the eyes of management.

Chapter contributors - which include Alexander and Maiden themselves, as well as David Benyon of Napier, John Carroll of Penn State, Karen Holtzblatt of InContext, Juha Savolianen of Nokia, Mary Beth Rosson of Penn State, and Joy Van Helvert of Chimera - then go on to address such issues as using scenarios in requirements discovery, and negative scenarios and misuse cases.

There are plenty of cases, such as the use of scenarios in air traffic control, and story use in automotive systems engineering, as well as practical guidance on, for instance, running a use case/scenario workshop.

It's rare to find a good book that emphasises people and their work and that is at the same time aimed squarely at the developer community. With so much so-called requirements work in the real world still stuck at the stage of back-room document drafting based on unwarranted assumptions and collections of - often pointless - functions, this book is a breath of fresh air, providing practical guidance on incorporating techniques and approaches to the development cycle.

Ian Alexander (also co-author of Writing Better Requirements) is one of the few people I've come across that is genuinely interested in bridging the disciplines in this area. He has an interesting and well-written, cross-disciplinary set of book reviews on his website.

© Louise Ferguson 2004

Back to Top

American Society for Quality's Software Quality Professional Magazine

This book is a collection of twenty four articles by various experts in the systems modeling and requirements community and edited by Alexander and Maiden.  The articles focus on techniques for applying scenarios and related techniques to the entire system life-cycle, not just within the context of use cases for requirements analysis.

The articles are organized into four parts:

• Overview – discusses what scenarios are and gives a general overview of how they can be used.  This section is written by the editors.
• Scenarios through the system life-cycle: techniques – focuses on various methods used by practitioners for applying scenarios
• Scenarios in action: case studies – describes specific examples in various industries where scenarios and use cases were applied
• The way ahead – discusses the future of scenarios, education, and some miscellaneous topics.

At first glance the title seems somewhat ambiguous, because a common view is that scenarios are a subset of use cases, especially within the context of the Rational Unified Process.  But the focus on scenarios appears to be deliberate.  The editors and authors are trying to expand our use of story-telling to all areas of the system life-cycle.  As defined in the book, scenarios are a relatively formal type of story-telling; stories are a less formal version of the same thing.  The ultimate goal is to improve communication between all stakeholders, not just between those familiar with arcane terminology or technical methods.  As the editors point out, a key strength of the scenario approach is that it encourages us to look at and agree on the whole problem before diving into details or possible solutions.

Overall the book is oriented towards practical techniques, methods, and examples to improve system development, operations and business processes.  Many articles include example forms, experiences and advice.  Once you have read the overview, you can then scan the introduction to each major part and the specific articles to find topics of interest.  Even in Part II, which focuses on techniques, most articles include actual experience and worked examples.  Although there were a few articles that were too abstract for my purposes, a real-world focus was evident throughout the book.

I found the book refreshing because of its realistic and practical approach to the use of scenarios.  As it points out, “scenarios don’t do everything” but have specific places throughout the life cycle where they work best to foster communication and decision making.  The editors and contributors freely admit there are areas where scenarios and related techniques are not as useful or are inappropriate.  In fact there is a chapter in Part IV titled “What scenarios (still) aren’t good for.” 

I felt the book definitely broadened my understanding of the potential for scenarios and stories to be used more widely in systems and software engineering work.  One immediate benefit is that I’ve found opportunities for using scenarios in the training materials and user documentation I write for software applications that would be more effective than the methods I’m currently using.

I think many practicing system engineering and requirements professionals will find this a useful reference book.  However, many of the articles appear to assume the reader is already familiar with the Rational Unified Process and related terminology.  This is not an introductory text on scenarios.  It seems most accessible to those who are already using use case techniques but perhaps within the narrow context of requirements analysis or systems engineering.  Perhaps there is an opportunity for Alexander and Maiden to further their laudable goals and develop accessible materials for professionals who are not strongly versed in use case related techniques but who are close to the other parts of the system life-cycle and who might strongly benefit from scenario based approaches.

To gain a broader understanding of use cases (and other forms of requirements engineering documentation) as they may apply to our domain, try reading Alexander & Maiden's (2004) Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle.

Back to Top