Webster's 7th New Collegiate Dictionary defines "scenario" as "1a: an outline or synopsis of a play; esp: a plot outline used by actors of the commedia dell'arte, b: the book of an opera, 2a: SCREENPLAY, b: SHOOTING SCRIPT". ((1)) This classical, common English usage focuses on scenario as a list or guideline of events which orders a set of actions. All of Campbell's usages, save perhaps "test cases", fit this pattern. I prefer to focus not on script or stage direction, but on the elements of plot and intent, which are not always made explicit.

In [Reisner86a] I presented two usages of the term "scenario": as a technique for describing how to accomplish a task or activity using a given system, similar to Campbell's "demonstration examples", and as a technique in system design, similar to Campbell's "user tasks for design".

As "demonstration examples", the intent is to supply the user with an appropriate model for system usage - how to use the system naturally to accomplish a task. For Unix, such a "scenario" might develop the ideas of shell scripts and filters, thru examples of common high-level tasks.

As "user tasks for design", I used "scenarios" to describe a user task domain, attempting to identify approachs the user would naturally adopt, and then developing a system or set of tools which would be consonant the user's desires and expectations. For example, one might describe a user's thought process in the course of developing a program, and then describe a style of programming environment which would support that process. ((2))

Both usages focus almost completely on the user's internal model of the system. Specific command usage and behaviour only shows up incidentally. The "scenarios" are not substitutes for traditional tutorials and usage or design documentation. Rather, they provide the higher-level context in which those other documents become useful and meaningful. (The utility of this type of "demonstration example" scenario could be tested fairly easily by the use of different documentation sets in introducing novice and experienced users to a new system, as outlined in [Reisner86a].)

With this emphasis, "user paradigms" might be a better term than "demonstration examples" (if somewhat overused). "User tasks for design" is somewhat cumbersome, and does seems to focus on very specific actions rather than on process and motivation; I would be tempted to retain "scenario", perhaps paired with "problem", "domain", or "design". "Test cases" does not emphasize the hypothesis and theory testing nature of the usage - alternatives? "Evaluation tasks" seems direct and to the point.

Scenarios, in their various usages, clearly provide useful methods for thinking about and describing systems, theories, and user models. A taxonomy may be useful in retaining focus and clarifying purpose of usage in different contexts.

((1)) It would be interesting to compare this to a more recent or slang dictionary definition.

((2)) [Reisner86b] illustrates this in a rudimentary fashion. [Reisner86c] describes a somewhat more successful "design by scenario", though the scenario is not explicitly stated.

------------------------------

[Campbell92] Campbell, R.L. (1992). Will the Real Scenario Please Stand Up? SIGCHI Bulletin, 24(2), 6-8.

[Reisner86a] Reisner, D.A. (1986a). The Use of Scenarios in Programming System Documentation and Design. Internal whitepaper, TeleSoft.

[Reisner86b] Reisner, D.A. (1986b). Basic Tools for Ada Program Development. Internal whitepaper, TeleSoft.

[Reisner86c] Reisner, D.A. (1986c). A Graphics Oriented Interface for Ada Program Development. Unpublished, David Reisner Consulting.

Contact: David Reisner, Synthesis, dar at synthesis.com