How Abstract should Scenarios be? Or how vivid with ‘real’ detail? Two opposite schools of thought exist: that use cases and the scenarios they contain should be as vivid as possible; and that they should be simple, systematic, and generally applicable – i.e. without the character of being examples, specific instances in time and place and person. Many related types of abstraction are involved when we make scenarios.

Firstly, there is a large group of types of generalisation. These include generalising away from persons (Harry Rogers) and named organisations (The Bank of New Jersey) to classes of actor (the Customer, the Bank). We also generalise away from times and places (at 9:15 am on Tuesday outside the Main Street branch) to abstract situations (anytime, any teller machine). These together serve to discard the vivid and particular verbal description in favour of something clean, short, simple, and reusable. But equally, they create scenarios devoid of many possible clues as to feelings, intentions, and styles of approach that might possibly be important: after all, we are trying to capture people’s wishes as requirements, so ignoring much of what they say they want is not necessarily a good idea. Abstraction by generalisation risks ‘throwing out the baby with the bathwater’.

Secondly, there are all the types of abstraction implicit in verbalising – and usually also textualising – a description of a real situation or lived episode. In goes a place and time and sunshine and reflections in the glass of the shopping street windows and paving stones and people in the street and trees and a teller machine in the wall of the bank; and out comes … a list of words.

Abstraction to text throws away essentially all the dimensions of sensory experience – sight, sound, touch, smell, taste, acceleration, …; all subjective impressions like surprise, fear, pleasure, complexity, boredom; and all dimensions of space. Even time is reduced to a symbolic indication of sequence, by some device such as numbering or listing. Without becoming too philosophical, we seem to be discarding a dozen dimensions here, replacing them all with a stream of symbols encoded in compressed form with the strange metaphors of natural language. (Think, for example, what images are being referred to when we say ‘interrogate the user’, ‘enter a PIN number’, ‘capture a requirement’ – these are images of violent questioning, going into a house, grabbing a hostage). Text has many virtues, among them familiarity, being a shared medium, expressiveness, flexibility, and brevity; but it is both imprecise and skimpy on detail.

Obviously, abstraction at some stage is essential for making systems which must model some aspects of the world. It seems reasonable that some part of that abstraction should be present in the requirements, with the rest of the abstraction journey coming between the requirements and the final design of the system. But how much abstraction is actually necessary in a specification? Is the right information thrown away at this early stage? How can we know which aspects of experience (if not of reality) are unimportant for a design before the design work has even begun? These are serious and to some extent unanswerable questions, at least in the general case. Each project can, and probably should, decide how abstract its scenarios should be.

If that’s so, it’s rather disturbing that non-verbal means of communicating scenarios – film, tape recordings, photographs, diagrams, sketches, acted scenes, storyboards, … are used so rarely. Similarly, not-totally-generalised text – ethnographic observations, personal reports, actual quotations, tape transcripts, … are also used remarkably rarely. In fact, if vividly ‘real’ scenarios are ever appropriate, it seems that they are not being used on many projects that would benefit from them.

In conclusion, then, as far as scenarios are concerned, vivid concreteness – as opposed to pale abstraction – can be thought of as consisting of two main axes. Good scenarios are not too verbalised, and not too generalised. We can visualise this on a diagram in the style of a Boston matrix.

Wieringa, Roel J. Requirements engineering: frameworks for under- standing. Wiley, New York, 1996

© Ian Alexander 2001

Other Articles