CHAPTER 25
THE FUTURE OF SCENARIOS
Ian Alexander1 and Neil Maiden2
1Scenario Plus, London, UK
2Centre for HCI Design, City University, London, UK
INTRODUCTION: HORSES FOR COURSES
The previous chapter, What Scenarios (Still) Aren't Good For, toured some of the issues that beset scenarios, and suggested some elements of an agenda for research into scenario applications in system development.
Today we have an idea of how useful scenarios can be, but we certainly do not have a complete picture of how all the different possible scenario techniques might fit together with each other and with other specification techniques. The key questions that we have tried to address in this book are what scenario approaches there are, and what they are good for. A racing man might say ‘there's a horse for every course’; the trick, naturally, is knowing which one it is before you place your bet.
The question that arises for researchers is of course how one would know, and hence what guidance one could give to a project trying to select the best techniques for its circumstances. This brief chapter peers over the horizon at what a future version of this book might contain.
TOWARDS A FRAMEWORK
Researchers would like to have a comprehensive framework encompassing all scenario techniques, all domains, and all contexts of use—describing access to stakeholders, issues of how fixed or flexible scenarios should be to permit innovation, and so on. Clearly, this is a huge challenge, and it has many dimensions, some of which are mentioned below.
REPRESENTATION
Scenarios are today mainly represented as more or less highly structured text. They are also sometimes represented as storyboards, sequence diagrams and flowcharts, and less often as films, acted scenes, tape recordings, sequences of maps, and other audiovisual forms.
There is a broad scope of possible investigations that could help show how we should be using scenarios in different circumstances. How should we tailor our choice of representation according to domain? to stakeholders? to project type? We simply don't know, and we'd like to.
A wider issue revolves around incompatibility of models of different aspects of a wanted system: if you draw a flowchart to define a scenario of interaction, a state-chart to define the corresponding internal system states, a message sequence diagram to define the timing and nature of messages between software objects, and a class diagram to define the relationships of those objects, how do you check that the definitions represented in these diverse ways are consistent, or even use them together to generate code? As a footnote to those questions, if scenarios are to be represented more analytically to suit such development purposes, can they remain useful for communication with stakeholders?
PROCESS
There are several mutually incompatible scenario-based system development processes described in this book, and several other techniques that might fit into a range of different business processes. We do not today know how scenarios can best support processes of innovation, of negotiation, of validation, or of management of product families. For that matter, how well do they support business processes themselves, and all the modelling, improvement, and re-engineering activities beloved of business analysts and process improvement people?
We have a hunch—supported by preliminary findings and experiences—that scenarios might be very useful in all these areas.
For instance, scenarios might be used to index features or requirements for reuse across a product line. They permit a suitable end-to-end description of problems, and they have the potential to remain stable while technologies come and go. We hope that the reuse of requirements will soon advance well beyond the rudimentary steps that have been taken so far.
As another example, it's already clear that a scenario-directed search for exceptions is easier to conduct and more effective than a relatively undifferentiated analysis based on requirements (Alexander 2000). The same seems to apply in more specialised areas such as safety, where Functional Hazard Analysis, pioneered by Karen Allenby and Tim Kelly, promises to extend the power of traditional Failure Modes and Effects Analysis (FMEA) and similar techniques (Allenby and Kelly 2001).
Similarly, scenario modelling in the form of misuse case analysis may be a useful addition to the tool chest of facilitators of trade-off and negotiation workshops (see Ian Alexander's description of this technique and a case study of its application in Chapters 7 and 18). The technique may also be helpful in identifying threat-handling business processes, such as security checks to combat money-laundering and fraud, controls on credit, and monitoring of transactions (Regev, Alexander and Wegmann 2004). But there is very little evidence for this as yet.
There are probably many other ways in which scenarios may turn out to be useful in business and system development process work.
DOMAIN KNOWLEDGE
Numerous ‘different’ disciplines today work on modelling business domains: operational analysis, business process modelling, business analysis, requirements engineering, contextual design, knowledge management—to name just a few. All of these must (if they are doing anything useful at all) be constructing more or less standardised scenarios describing what people (need to) do in different domains.
How can these diverse and conflicting approaches be unified, if at all? How should scenarios best be applied in different domains? How far can techniques be generalised? We do not know. In this book, we have asked chapter authors to try to say how domain-specific or generally applicable they believe their techniques to be, and why. They have all been admirably frank in their replies, but there is clearly still much to learn.
COTS
It is no secret that Commercial-Off-The-Shelf (COTS) software and hardware products are steadily encroaching on the preserves of custom development. Today, no one in their right mind would develop their own database or network protocol, yet it is only in the last decade that these things have become universally accepted (and cheap) commodities.
COTS products solve some problems (like record indexing and sharing, transaction handling, file transfer) essentially perfectly; but they raise many more. Developers are familiar with the practical issues of wrestling with imperfect documentation, software bugs, and arrogant manufacturers. The challenges for requirements and specification are just as acute. For instance, it seems pointless to write requirements that you know will be handled by COTS products (‘The spreadsheet shall be able to multiply two 32-bit floating point numbers’), but equally it could be disastrous not to specify what facilities you need. Can scenarios be used conveniently to describe overall behaviour without going into too much detail on the obvious, while giving enough detail on the problematic parts and interfaces to guide design and testing? How should COTS-integration projects be specified? One of the few pieces of published work on the subject (Gregor, Hutson and Oresky 2002) describes using Storyboards to define requirements for COTS integration. Its focus on the user interface is natural and helpful but is clearly useful mostly for software products, and leaves many interesting questions unanswered.
DISSEMINATION
We are very glad to be able to include an account written specially for this volume (Chapter 23) by Mary Beth Rosson and John Carroll on teaching students how to use scenarios well. But there are wider issues such as of the dissemination of scenario knowledge gathered by researchers, of training and certification in scenario usage and in special skills such as facilitation (see Ellen Gottesdiener's description of her Use Case workshop technique in Chapter 5).
The UML with its Use Cases, sequence charts, and activity diagrams (to name just one example—and three different scenario notations) has a strong industrial bias, and probably a software bias too. We have worked hard to give this book some sort of balance between research and industry, between large and small applications, between domains, and between hardware and software. Needless to say, this was only partially possible. There is a clear need for practitioners who know the field in a cross-disciplinary way. Few such people exist today, for several reasons: the current ‘heads-down, no books, no courses, no conferences’ attitude in industry, and the equivalent pressure on academics to secure reliable sources of funding rather than risking cross-disciplinary approaches, leaves no vehicle for dissemination of good practice. Scenarios are taught as part of software engineering or as part of human–machine interaction studies. They are used in process modelling and rapid/agile development methods in industry. But they are rarely seen as something bigger, understood as something more than the preserve of technicians, and applied consistently in problem solving at all levels. It will take far more than technical research programmes, no matter how elegant, to make scenarios as well understood and as widely applied as they ought to be.
SUMMARY
Any reader who imagined that this book, long as it is, might contain definitive answers and rules for scenario usage will have been sadly disappointed. We hope we have succeeded in painting a picture of the current state of the art of scenario-based engineering and system development. But many exciting challenges remain, both for academic researchers and for adventurous industrial practitioners. Perhaps this book, and these concluding chapters, may help to guide and stimulate some readers to investigate further. There is much to be done, and any well-planned and practical investigations or trials are almost bound to be interesting and useful.
REFERENCES
Alexander, I., Scenario-driven search finds more exceptions, Requirements Engineering Process Workshop (REP 2000), Greenwich; Proceedings of the 11th International Workshop on Database and Expert System Applications, IEEE, September 4–8, 2000, pp. 991–994.
Allenby, K. and Kelly, T., Deriving safety requirements using scenarios, Proceedings of the 5th International Symposium on Requirements Engineering, Toronto, Canada, August 27–31, 2001, pp. 228–235.
Gregor, S., Hutson, J., and Oresky, C., Storyboard process to assist in requirements verification and adaptation to capabilities inherent in COTS, in J. Dean and A. Gravel (Eds.), COTS-Based Software Systems, Lecture Notes in Computer Science, Springer; Proceedings of the First International Conference, ICCBSS 2002, Orlando, FL, February 4–6, 2002.
Regev, G., Alexander, I., and Wegmann, A., Modelling the regulative role of business processes with use and misuse cases, Business Process Management Journal, 2005; to appear.