PREFACE

Communicating Needs

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 do not think this is a software issue: it seems to affect complex systems of diverse kinds. The solution cannot 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 therefore lacking is 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 15 seconds. Where

gets a glazed look every time; the description

always seems to work (and even arouse interest). Story telling is so obviously sensible that it seems surprising that it has taken so long to become a mainstream engineering activity.

Scenarios and Requirements

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 is doubtful whether such coverage could ever be comprehensive—even if that were 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, for example, running 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 cannot 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, that is, practical knowledge that changes their behaviour;
• sufficient contact with stakeholders, whether through traditional meetings and reviews, or through 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.

Scope: A Wealth of Purposes and Techniques

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 corn flour). 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 structures, 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 to projects and has 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.

Structure of This Book

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

Part I provides an Overview of the nature and use of Scenarios.

Part II looks at how to apply Scenarios through the System Life cycle. It is introduced by an overview of the chapter structure used in this part of the book, and then by two chapters that review what scenarios are and how they are used. Then the chapter authors describe their techniques in their own words, but in a fixed structure, which we hope makes the different approaches easy to compare and contrast. Each chapter includes a Comparisons section to guide the reader to related chapters and to help weave the book into a unified whole. The chapters are supported not only by references to the literature but also by recommendations for further reading.

Part III presents industrial experiences of Scenarios in Action: Case Studies. It begins with an overview of the chapter structure used in this part of the book. Then the chapter authors tell their stories in their own words, but again in a structure that we hope will help you to select the experiences most relevant to your projects. Where appropriate, the text is cross-referenced to the techniques described in other chapters.

Part IV reasons and speculates a little about the future of Scenarios in The Way Ahead. Chapter 22, Putting Scenarios into Practice, reflects on the lessons learnt from the techniques and case studies in Parts II and III—the book itself serving as the basis for some very preliminary research. Part of the Way Ahead lies in the dissemination of what we already know and in the education of tomorrow's engineers; this challenge is discussed in Chapter 23, Teaching Computer Scientists to Make Use.

The Appendices are designed to help make this a practical guide by explaining the terms used and by providing a set of scenario-based engineering templates to get you started, with simple exercises in their use—and providing answers to the exercises.