Scenarios In System Development CSC 3380 Lecture 13

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

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).

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.

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

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

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

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