CHAPTER 22

PUTTING SCENARIOS INTO PRACTICE

Ian Alexander¹ and Ramin Tavakoli Kolagari²

¹Scenario Plus, London, UK

²DaimlerChryslerResearch & Technology, Ulm, Germany

WHICH KIND OF SCENARIO, WHEN?

As the contributions from our chapter authors show in Parts 2 and 3 of this book, scenarios can be represented in many forms and can be applied to essentially any programme and project life-cycle activity (Figure 22.1). Engineers from different disciplines see scenarios differently, and they work in domains as varied as telecommunications, software, aerospace, human–computer interaction, transportation, and civil engineering.

But development engineers are neither the only group who may write scenarios, requirements, and specifications, nor the only group who may read them. Stakeholders (see discussion in Chapter 1) can include test engineers, trainers, skilled, and unskilled operators—including mass-market consumers and the general public, system maintainers, and almost anyone involved in procuring systems. Scenarios can help these people to define and to see what results their systems should deliver, and hence also how to test, operate, and maintain these systems, and to train people in their use. To say the least, this is a tremendously wide scope (Figure 22.1).

FIGURE 22.1 Some applications of scenarios in system development

WHICH SCENARIO TECHNIQUE, WHEN? CONCLUSIONS FROM PART 2

Is it possible to give any meaningful guidance about which kind of scenario is appropriate across such a wide range of circumstances? Questions of applicability are shades of grey—hard and fast rules are unlikely to be correct. But perhaps humour can come to our aid here. I well remember the reaction of an experienced system development team in a requirements course I was teaching, when after a presentation of alternative elicitation methods I asked what would be the most suitable way of explaining requirements to their managers. “With puppets” was the unanimous reply.

In Part 2 of this book, various scenario techniques were presented. Let us briefly recapitulate the messages of the chapters in Part 2.

Chapter 3: Suzanne Robertson emphasises the human aspect to requirements engineering. Scenarios help people to come up with creative and inventive ideas for systems; they help with requirements discovery.

Chapter 4: Joy van Helvert and Chris Fowler describe their method of analysing user needs. They study ‘a day in the life of’ scenarios, which are mined in a workshop to identify user needs. These are organised into a needs hierarchy. This is evaluated in a further workshop. The output is a high-level service specification.

Chapter 5: Ellen Gottesdiener describes a range of workshops, guided with skilled facilitation, in which participants are vigorously engaged to shape scenarios and requirements rapidly, and to sketch out the design of wanted systems. Workshop retrospectives are held to review both deliverable artefacts and process.

Chapter 6: David Bush describes the use of imagined future worlds (the oil industry's meaning for ‘scenario’) to evaluate the stability of goals. Essentially, if a goal is required in all imagined worlds, then it has a good chance of remaining stable for many years to come, and is therefore a good candidate for implementation in one or more systems.

Chapter 7: Ian Alexander describes negative scenarios and misuse cases, and shows how these can help to elicit and document requirements, in particular to handle exceptions that might otherwise be missed. Descriptions of threats from misuse cases help to justify the existence of requirements for security and other qualities, which in turn can lead to requirements for additional system functions.

Chapter 8: Camille Salinesi presents a set of guidelines developed in the CREWS project. The guidelines cover goals and attributes of scenarios, including the recommended style for writing scenario steps, and the contents of use cases.

Chapter 9: Neil Maiden describes how to use the CREWS-SAVRE tool and approach to carry out systematic scenario walkthroughs based (critically) on well-crafted use cases. Walkthroughs can exploit both generic and domain-specific questions based on known classes of exception.

Chapter 10: Karen Holtzblatt describes her Contextual Design method, which is a proven way of developing systems participatively from vision and storyboards through to user interface design, full use case specification and object modelling, and including continued inquiry throughout implementation and testing.

Chapter 11: David Benyon and Catriona Macaulay describe how they use four kinds of scenario, namely user stories, conceptual scenarios, concrete scenarios, and use cases, to design system interactions.

Chapter 12: Peter Haumer describes how scenarios are used in the Rational Unified Process. He takes the story from use cases and goals through various Unified Modeling Language analysis and design models, showing how it deals with both business and system analysis.

Chapter 13: Kent Beck and David West describe the place of user stories in agile approaches. These stories are strongly focused on the user's point of view and person-to-person communication: artefacts are secondary to the essential process. Stories can be categorised as interrogatory, delegation, composite, collaborative, or fuzzy.

Chapter 14: Ian Alexander describes the intimate relationship of use cases and test cases, showing that these are different kinds of scenario, and that test cases can logically and in practice be generated from use cases according to some simple rules.

Chapter 15: Andrew Farncombe looks at the stories behind the development life cycles chosen for individual projects. He shows that while there are only a few basic stories, these can be combined to form many individual life cycles suitable for different kinds of projects.

The authors have indicated how they believe their scenario techniques apply to a basic life cycle. That life cycle (as Farncombe persuasively argues) is of course a fiction, a helpful but over-simplified linear scenario in a world of iterative projects. Indeed, a key message of this book is that development is often better when it is story-driven, which means that stakeholders participate throughout—which means in turn that iteration is inevitable and desirable. Figure 22.2 gathers up these suggested applicabilities into a synoptic linear view.

FIGURE 22.2 Scenario techniques (from Part 2) across the life cycle, by phase

*Contextual design has an extra phase here. Work practice redesign, using visioning and storyboarding

Farncombe's chapter on management, which discusses all phases of the life cycle, naturally applies across the board; but equally, it is not a technique for any particular phase of development. Rather, it is a way of thinking that is applicable to project planning, and to the setting-up of intelligent company rules governing the planning of projects. These activities take place outside the frame of reference of Figure 22.2.

The remaining techniques are sorted in Figure 22.2 to indicate that there are broadly two groups of techniques: those that mainly apply in the early requirements phases, and those that apply more or less throughout the development life cycle. In other words, the matrix consists mainly of a column on the left for the ‘early’ techniques, and a row at the bottom for the ‘throughout’ techniques; most of the rest of the matrix is unpopulated.

The traditional view of scenarios—as something useful in getting a general overview of a domain and of the way a system will be used—suggests that scenarios should mainly be used early in the life cycle. However, several of the ‘early’ techniques here are quite new and radical, involving workshops, storytelling, and automated walkthroughs amongst other things.

The ‘throughout’ techniques correspond broadly to more participative methods, along with an increased emphasis on iteration. These techniques include both documentation-intensive methods like the RUP (described by Peter Haumer), and agile methods like XP (described by Kent Beck and David West). So, again, the early/throughout split does not correspond to traditional versus modern. As discussed below (see Figure 22.4) it may relate to size of project—rapid iteration and agility are mainly for smaller projects, just as the movements of ants are more rapid than those of elephants.

Some trends are apparent from these chapters, as summarised in these notes and in Figure 22.2.

• Requirements discovery and validation are the places where engineers instinctively feel that scenarios belong, so it is not surprising that several techniques apply especially to these activities.
• Scenarios can be applied right across the life cycle, but while it is possible to find examples of both theoretical approaches and practical projects applying scenarios in any life-cycle phase, their explicit use in the later phases is rare, and few conventional projects seem to use scenarios continuously. Explicitly iterative methods including inquiry cycles, contextual design and agile methods are more consistent and continuous in their scenario usage. Earlier participative methods (not illustrated here) such as RAD and DSDM (e.g. RAD Advisor 2003, DSDM 2003) also often made good if informal use of scenario thinking.

WHO, AND WHY?

The kinds of scenario that may be useful vary with life-cycle activity, and consequently also with the roles of the people creating and reading the scenarios (Figure 22.3).

Figure 22.3 tries to suggest, for a typical domain, that there is more or less a simple gradient from representations like stories and acted-out scenes that non-specialists can readily understand, through to analytic diagrams that have meaning mainly for engineers. But any such naïve view is at best both right and wrong. Seemingly simple representations like stories and role-play in workshops are certainly valuable among engineers, while complex representations like simulations are extremely valuable among business managers and other non-technical stakeholders when they provide or illustrate results that could not be obtained any other way.

FIGURE 22.3 Scenario types for different people and purposes

Therefore, we should be cautious about assuming that a sophisticated-looking technique would be too difficult for a particular group of stakeholders. As long as the information is presented in a clear and appropriate way, it doesn't matter how elaborate the mechanism is behind the scenes. For example, stakeholders do not have to understand that a Markov simulation was run so many times to give a result; it is sufficient to show the results clearly, in the language of the domain—everyone understands the meaning of a two-hour wait for a hamburger, as Peri Loucopoulos argues in Chapter 21, even if they have never heard of queuing theory.

Note also that more technology to present scenario results better is not necessarily the answer. It might be appropriate to make an animation as a front end for a simulation model; or it might be enough just to explain the results and to answer questions in a workshop session.

Scenarios are used by people in many different professional disciplines; and unlike almost all other techniques, they are suitable for people who are not systems developers. This does not imply that scenarios by themselves are sufficient for good systems or software engineering, even in those life-cycle activities where they are most useful—indeed, none of our authors suggest this. Some of the presented approaches are scenario-based or scenario-centred, but that always leaves room for a ‘mix and match’ development style in which scenario use is combined with other techniques such as the use of templates, brain-storming, reviews, prototyping, simulation, and analysis to suit the needs of the project.

Such embedding of scenarios in other engineering methods is reasonable, as the discovered knowledge can be passed on to later phases of the development process, for example in short informal scenario-sketches.

SCENARIOS EVERYWHERE?

The scenario representations that seem to be most generally useful are the unspecialised kinds, namely stories and sequences of events. Perhaps with hindsight this seems predictable: specialised creatures like anteaters and orchids live in precisely defined habitats, whereas generalists like rats, cockroaches, and man live nearly anywhere. Story is arguably the most natural form of a scenario: everyone understands without training or explanation what a story is and what it means. Sequence is also essentially universal, at least to engineers and probably more widely than that: everyone knows that a numbered list of instructions means start at step 1 and continue to the end.

The only other form of scenario that can make a plausible claim to being universal is the use case, and it is the new kid on the block—story has been around for hundreds of thousands of years, sequence since the invention of counting, and the use case for only a dozen years or so. Jacobson himself claims,

(Jacobson 2003), but as we will argue below (in ‘Diversity of Scale’), this is something of an exaggeration: use cases as currently applied cover neither the largest and most complex system developments, nor the smallest and most agile software projects. The use case is however certainly fashionable, which brings both costs and benefits.

On the plus side, the fame of the use case has brought scenario thinking into many areas of engineering where it was sorely needed, and it has helped to encourage cooperative development in some very traditional domains.

Against that, there is a marked bandwagon effect, illustrated by the fact that people are inventing hybrid terms like fully dressed use case, precise use case, executable use case (and indeed abuse case, misuse case). Some of these will find niches for themselves while others will fade away. The danger is that what began as a powerful general medium for sharing requirements will be hijacked by the technically minded, and converted into yet more complicated and specialised technical notations, accessible only to a few.

That over-emphasis in turn will lead—indeed, is already leading—to a backlash, with people arguing that scenarios and episode-based descriptions of behaviour are inadequate, or worse, inappropriate on their projects.

We believe that scenarios are essential but not sufficient—there is much more to a good specification and to a successful project than simply writing scenarios. Scenarios are essential, as it is hard to see how any project that does not have a clear story of what it is trying to do can succeed.

It is also a happy accident that the term use case recalls the idea of case-based reasoning, or Casuistry to give it its proper if now pejorative name. The failure of the rule-based approach to Artificial Intelligence in the 1980s demonstrated that human beings are not very good at reasoning with explicit rules (Graubard 1988, Dreyfus 1992). Tacit knowledge (Polanyi 1966), for instance of tasks requiring skill, is better handled by giving examples of concrete cases—scenario instances—that people can see are relevant to their work, and that they can reason about accurately and without effort. Casuistry got itself a bad name for the same reason that Sophistry did: you can invent cases and scenarios to support any claim, if you have enough money and a clever enough lawyer. But, genuine descriptions by stakeholders of the results and behaviour that they want are poles apart from casuistry. Such scenarios are simple, direct, practical, and concrete statements of need, and they have a good chance of being far more down-to-earth than long lists of so-called requirements framed as ‘shall’ statements.

Scenarios are not everything: they do not, contrary to some extreme claims, replace system models, and they plainly do not cover all ‘non-functional’ requirements and constraints. Scenarios make sense when used together with data models, behaviour and timing models, simulations, prototypes, quality and configuration plans, and a host of other project documents (or ‘artifacts’).

We believe that there are already good notations—not least in UML—for describing system behaviour in analytic detail, just as there is a place for simulation and animation of computer models to explore and illustrate scenarios. The use case is a powerful tool but it should not be made to do everything. So a key theme of this book is the value of diversity: different problems do often demand different solutions.

HOW DOES PROJECT SCALE AFFECT SCENARIO USAGE?

A crucial aspect of project diversity is scale, closely linked to complexity. Barry Boehm has argued that much present confusion is caused by people from different backgrounds failing to see where other people are coming from. Most software projects (60% of them) are quite small and can be completed by a team of no more than 10 programmers in a year or so (Boehm 2003, quoting Highsmith 2002). A similar statement could be made about systems that are not mainly software. But, and this is Boehm's point, those small projects only produce 17% of the world's software output. Eighty-three percent of the world's software is developed by the few very large projects that require teams of thousands of engineers (Figure 22.4). Smaller projects enthusiastically report success after success with XP and other agile methods; larger projects respond with scepticism—they have to have more sharply defined procedures and interfaces. Both are justified in their own contexts: what is not justified is over-generalisation. In short, most projects could benefit from more agility, but most software cannot.

Small projects can and probably should adopt a participative life cycle—possibly an agile one, and the requirements can be allowed to evolve as the project proceeds. Early product releases can be explored and tested as prototypes, and new requirements can be captured in scenarios. Chapter 13 on User Stories by Kent Beck and David West illustrates this kind of approach admirably.

Very large projects can certainly make use of stakeholder participation, but their interfaces and contractual structures cannot change radically from day to day. That world is described by Andrew Farncombe in Chapter 15 on Stories and Life-Cycle Process Models. Such projects must have agreed requirements and interfaces between subsystems, kept under efficient configuration control. Scenarios can illustrate the required end-to-end behaviour of the whole system, to explain to sub-sub-subsystem makers how their component fits in and how it will be used. Participation tends to take forms such as ‘Integrated Project Teams’, containing a carefully planned assemblage of representatives of different stakeholder roles. For example, a military logistics project would typically include a skilled mechanic and a transport specialist to take ownership of key requirements within the development team. Chapter 20 on Scenarios in Rail Rolling Stock by Alistair Mavin perfectly encapsulates the careful use of stories to justify and explain requirements in a ‘system of systems’ setting—a Passenger Emergency Alarm is of course a small system inside some much larger ones.

FIGURE 22.4 Dominant concerns related to scales of projects

Medium-scale projects may be able to benefit from an intermediate approach, applying scenarios in a disciplined sequence of steps to gain some of the benefits of iteration and the advantages of careful modelling. Peter Haumer shows how use cases serve these purposes in the Rational Unified Process, in chapter 12, Use Case–Based Software Development.

We hope that with such an understanding of the inevitable diversity of projects, engineers and project managers (as well as researchers and industry gurus) will come to accept that scenarios are useful throughout every project, but in ways that depend on the size and type of project, and alongside a wealth of other techniques in different project phases.

INTO PRACTICE: CONCLUSIONS FROM THE PART 3 CASE STUDIES

Let us now briefly summarise the messages of the case study chapters in Part 3.

Chapter 16: Thomas Zink and Frank Houdek describe the benefits of introducing scenarios into automotive software development. They found that scenarios were good in product feature negotiation, for providing requirement rationales, and for giving the user perspective on product subsystem features.

Chapter 17: Ian Alexander and Andrew Farncombe describe two examples of scenario usage from the railway domain.

• One is a straight use of scenarios (in the form of use cases) to capture the context of a system and hence to discover requirements that would have been missed, notably for a whole-line simulator.
• The other applied misuse cases to document design trade-offs for a seemingly trivial problem that turned out to be more complex than expected, but which was resolved quite readily given the appropriate presentation of facts to the appropriate collection of stakeholders in a workshop.

Chapter 18: Perminder Sahota describes a use of CREWS-SAVRE to manage scenario walkthroughs in air traffic control. The tool was extended to handle domain-specific scenarios. These helped to elicit and to validate the requirements.

Chapter 19: Juha Savolainen describes how scenarios and quality requirements are used in telecommunications to elicit and document functional requirements, to locate problem areas in the software architecture, and to validate the architecture.

Chapter 20: Alistair Mavin describes the use of scenarios in a railway project with the REVEAL method. A scenario was written for each goal or event. Train-level scenarios were used to derive subsystem requirements. Scenarios also formed key elements in satisfaction arguments.

Chapter 21: Peri Loucopoulos shows how simulation can explore the concrete meaning of proposed requirements. In the case of the 2004 Olympic Games at Athens, modelling of venues' ability to handle the expected crowds showed that innocent-sounding assumptions can have serious consequences. Feeding these back to stakeholders can rapidly improve the consistency and realism of specifications.

FIGURE 22.5 Scenario usage by phase and technique in the case studies (in Part 3)

Chapter 23: Mary Beth Rosson and John Carroll present their view, based on many years of experience, of how students can be taught to use scenarios in usability engineering.

Figure 22.5 collects up how the case studies and experiences described in Part 3 made use of scenarios; as in Figure 22.2, the case study rows are sorted by the phases to which they apply. It isn't possible to conclude anything statistically from such a small sample—essentially one in each domain—though the Strengths and Weaknesses discussions in each chapter provide qualitative guidance. But this book does demonstrate that there is a rich variety of ways in which people use scenarios on their projects.

This is clearly a diverse picture, not least in the range of topics addressed. However, it is worth observing that scenarios seem in practice (at least in this small sample) to be applied mainly on the left-hand-side of the table (and the V-model). That is to say, the experience of the authors of this book suggests that industrial practice mostly makes relatively conservative use of scenarios. It seems, incidentally, to be hard to find instances both of very large projects and of very agile ones. Late life-cycle phases such as testing, operations, and maintenance are not represented in our sample. This may be no big surprise, but it does suggest that there is scope for encouraging people to use scenarios more adventurously to guide testing, maintenance and operations procedures, training, and so on.

DO SCENARIOS REPLACE REQUIREMENTS?

A vexed question is whether projects need both scenarios and requirements, or whether scenarios can serve as specifications on their own. As for most such questions, there is probably no single right answer.

Small projects with a team of less than a dozen people and a client who is closely and personally involved in the development can get by with very little in the way of written specifications. A robust architecture and an agreed but evolving set of scenarios may be sufficient (and test cases can be written from the scenarios). An agile approach might be appropriate. This might be the situation in a small custom financial software project.

Large projects involving contracts let to suppliers and development subcontractors inevitably demand much greater stability in their specifications. This generally means written requirements with contractual force. In such projects, scenarios are needed to give the big picture, to generate, explain and justify the requirements, and to guide acceptance testing. A formally defined process for the life cycle is necessary—changes to contracts are costly, so planning is essential (see Chapter 15, Stories and Life-Cycle Process Models by Andrew Farncombe). This situation is typical of mass-market product developments in the automotive, telecommunications and consumer electronics industries, and also in bespoke developments in the defence and aerospace industries. In such a context, it is easy to understand why Raymond Jorgensen thinks ‘Use Case Requirements’ an ‘Oxymoron’¹ (Jorgensen 2001).

Systems engineers like Jorgensen see the place of scenarios as being in early scene-setting documents such as the ‘Operational Concept’, which applies to a large system (say, a warship) as a whole. Scenarios illustrate how systems will be used operationally; they are valuable for checking that the system does the right thing (in end-to-end operational trials). Requirements, on the other hand, apply to systems, subsystems, and sub-subsystems all the way down to individual components. They are valuable both for driving design, and for verifying that the system complies with each wanted thing, that is, each requirement. From this world-viewpoint, it is indeed oxymoronic to combine Use Cases and Requirements:

From the point of view of agile methods on manageably sized projects, on the other hand, the merging of scenario and requirement looks perfectly reasonable. Kent Beck writes:

Beck implies that a set of stories describes system behaviour sufficiently for design and coding—no more detailed specifications are needed. What is more, concepts such as release planning and incremental development are subsumed into the choice of stories for each iteration; iterations are stated to be rapid, for example, taking ‘three weeks’. (See Chapter 13 for a description, by Kent Beck and David West, of User Stories in Agile Software Development.)

Between the positions of Jorgensen and Beck, Alistair Cockburn writes:

In other words, the functional requirements are all expressed in use cases. They are relatively formally defined, but scenarios and requirements are not separate documents (See Chapter 12 for an account of Use Case-Based Software Development, by Peter Haumer).

A resolution to this argument can be sketched in terms of the concepts depicted in Figure 22.4, which illustrates the few large projects/many small projects divide. Figure 22.6 suggests that the largest projects (a la Jorgensen) may prefer separate scenarios and requirements, applying scenarios mainly ‘up front’ to give an overall picture and help discover requirements. Medium-sized projects may prefer use cases (a la Cockburn) to organise their requirements. Smaller, more agile projects may find informal user stories (a la Beck) sufficient documentation for their purposes—indeed, they would be encumbered by more formal documentation and control processes. Project size, iteration time, formality of life cycle, and organisation of documents all correlate with the divisions suggested by the graph. Who was right? Everybody, but we need to be careful not to over-generalise from our experience.

FIGURE 22.6 Scenario structures related to scales of projects

GETTING STARTED

How, given this diversity, should you get started with scenarios? It's hard to give much guidance when projects and stakeholders vary so widely, but here are some general suggestions.

• Create the right life-cycle approach for your project (see Chapter 15, Stories and Life-Cycle Process Models, by Andrew Farncombe). Decide how much iteration you need, based on how many stakeholders there are, how well-defined the requirements are, and how risky the project is given its size, cost, timescale, technological innovation, experience of staff, and other factors. Iteration becomes essential when risk is high, when requirements are poorly understood, and when there are many stakeholders. (If you think that means most projects, we won't disagree with you.) If you need plenty of iteration, then a scenario approach like Contextual Inquiry or an agile method may be appropriate. If you need less iteration, then a more conventional approach may be suitable.
• Choose scenario techniques to fit your project. If you are trying out a scenario technique for the first time in a project, it should be a well-established technique described in the literature and already in use in similar projects and situations (in other organisations, at least). Since scenarios are very “soft” you might expect that there are no rules to be followed—but this is not the case. Skill and experience are needed.
• Try out new approaches in a small way, when their success is not critical.
• Play with the approaches to see what they do well in your own situation, and where they start to struggle. Play is the best way of learning a skill; it isn't an accident that we humans have a ridiculously lengthened infantile-play stage of 20 years or so. That is either an unbelievable luxury or clear evidence that play is extremely important². Perhaps there is another general principle here: that every technique has a comfort zone (or a tennis racket's sweet spot) where it works effortlessly. This comes with the implied warning that if a technique is proving difficult, it is probably the wrong one for your situation.
• Have the courage of your convictions. If a combination of techniques works well for your project, then however unorthodox or naïve it may seem, it is right for your situation. There isn't and can't be any higher authority than a team of skilled practitioners doing a job effectively. Researchers can theorise, study, observe, and possibly even predict, but it's the practical outworking of knowledge and skill that gets projects done.

That does not mean that once you have managed to get one scenario technique to work on one project, you know everything about the subject. We're all just learning too. Practice makes perfect only if you observe the effects of what you are doing, reflect on it, and work out how to improve on your local ‘state of the art’. In that inquiry cycle, discussion, experienced colleagues, and other people's suggestions in the form of books and articles can contribute.

Where this is leading is that systems engineering with scenarios is a set of practical skills that need to be learnt (see Chapter 23, Teaching Computer Scientists to Make Use). These skills are collaborative, so learning them requires practice on projects and in teams, with a variety of stakeholders. We hope that this book helps to get you thinking about scenarios, and that it may encourage you to try out and benefit from the wealth of new approaches that it describes.

KEYWORDS

Scenario Technique

Story

User Story

Use Case

Life cycle

System

Software

Project

Stakeholder Participation

Manuals

Training

REFERENCES

Beck, K., Extreme Programming Explained, Embrace Change, Addison-Wesley, 2000.

Boehm, B. and Beck, K., Agility through discipline: a debate, IEEE Computer, 36(6) 44–46, 2003.

Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2001.

Dreyfus, H., What Computers Still Can't Do: A Critique of Artificial Reason, MIT Press, 1992.

DSDM, the Dynamic Systems Development Method consortium website, 1997–2003, http://www.dsdm.org

Graubard, S., The Artificial Intelligence Debate: False Starts, Real Foundations, MIT Press, 1988.

Highsmith, J., Agile Software Development Ecosystems, Addison-Wesley, 2003, p. 358.

Jacobson, I., Use cases and aspects - working seamlessly together, Journal of Object Technology, 2(2), 7–28, 2003, http://www.jot.fm/issues/issue_2003_07/columnl

Jorgensen, R., The Oxymoron of Use Case Requirements, INCOSE Insight, July 2001, pp. 21–22. Available from http://www.incose.org

Polanyi, M., The Tacit Dimension, Peter Smith, Gloucester, MA, 1983; first published by Doubleday, 1966.

RAD Advisor, Rapid Application Development, 2003, http://www.rad-advisor.com

¹ A juxtaposition of seemingly incompatible elements, as in ‘wise fool’.

² Zoologists call the retention of early-stage features into adulthood ‘neoteny’. For example, newts keep their tails and gills, whereas frogs only have these features at the tadpole larva stage. The change clearly had value in fitting newts for an all-aquatic lifestyle. Humans seem to be adapted by neotenous playfulness to a learning lifestyle.