1. Scenarios In System Development
CSC 3380
Lecture 13

2. Sources
“Scenarios In System Development” by Klaus Weidenhaupt, Klaus Pohl, Matthias Jarke, and Peter Haumer, IEEE Software, v. 15, n.2, pp

3. Background Scenarios represent UML interaction diagrams:
Descriptions of interactions with the software system from a user’s point of view (system interaction);
Descriptions of the environment in which the software system functions (system context);
Descriptions of the internal interactions of system components invisible to the user (internal system);
Scenarios may be presented in a variety of forms:
Narrative text
Structured text;
Diagrams (message trace or interaction diagram);
Images (screen dumps and forms);
Animations or simulations (story boards).

4. Background continued
While the typical scenario might be 3 to 5 pages long, they may be from one to 200 pages.
Scenarios provide bridges, or communication paths, between many pairs of entities:
Business processes and software development;
Customers/users and developers;
Design and implementation software elements;
Different developers;
Different software phases;
Static and dynamic models of the software system.
Used in almost all object‑oriented software development projects.

5. In order to make good use of scenarios
Develop initial and intermediate scenarios together with users, customers, and domain experts
Develop both low and high fidelity prototypes in parallel with scenarios
Use the two to verify, looking for correctness, completeness, misunderstandings, timing, over-specification, and side effects
Permit scenarios to evolve over time
Link scenarios to system glossaries (data dictionaries)
Use scenarios as the basis for deriving test cases

6. Advantages of using scenarios
Scenarios are more understandable than abstract models – no learning curve & small (120 vs. 27)
Scenarios foster cooperation of stakeholders, give ownership and control
This same interaction teaches developers the language and processes of the problem domain
Scenarios and prototypes are synergistic, can evolve in conjunction with careful management
They provide far greater understanding, and are a convincing way of selling the system to customers and users

7. More advantages of using scenarios
Scenarios foster system architecture oriented to usage not structure - less complex, more realism
Product can be developed incrementally in priority order by considering one usage at a time
Scenarios can aid in focusing on expected system behavior, yet keep track of exceptional behavior
Scenarios provide a framework for negotiation and coordination between different stakeholders
Scenarios linked to the glossary let abstract terms be defined by concrete scenarios useful in training
Scenarios are valuable in examining, building, or validating static system models

8. Management of scenarios
Change control controls evolution and ensures synchronization of prototypes, documentation, and test cases, if we have a traceability mechanism
Scenarios need to be partitioned to provide:
Views at different levels of detail;
Work breakdown;
Different viewpoints.
Scenario review by walkthroughs and inspections
Managers encourage scenario development:
Top‑down decomposition (stepwise refinement)
Black‑box to white‑box transformation
Incremental development of alternate cases/exceptions
Informal to formal scenario notations