Scenario (computing)

In computing, a scenario (UK: /sɪˈnɑːrioʊ/, US: /sɪˈnɛərioʊ/; from Italian: that which is pinned to the scenery;[1][2] pronounced [ʃeˈnaːrjo]) is a narrative of foreseeable interactions of user roles (known in the Unified Modeling Language as 'actors') and the technical system, which usually includes computer hardware and software.

A scenario has a goal, which is usually functional. A scenario describes one way that a system is or is envisaged to be used in the context of activity in a defined time-frame. The time-frame for a scenario could be (for example) a single transaction; a business operation; a day or other period; or the whole operational life of a system. Similarly the scope of a scenario could be (for example) a single system or piece of equipment; an equipped team or department; or an entire organization.

Scenarios are frequently used as part of the system development process. They are typically produced by usability or marketing specialists, often working in concert with end users and developers. Scenarios are written in plain language, with minimal technical details, so that stakeholders (designers, usability specialists, programmers, engineers, managers, marketing specialists, etc.) can have a common example which can focus their discussions.

Increasingly, scenarios are used directly to define the wanted behaviour of software: replacing or supplementing traditional functional requirements. Scenarios are often defined in use cases, which document alternative and overlapping ways of reaching a goal.[3]

Types of scenario in system development

Many types of scenario are in use in system development. Alexander and Maiden[4] list the following types:

Negative scenarios or misuse cases may be written to indicate likely threats which should be countered to ensure that systems have sufficient security, safety, and reliability. These help to discover non-functional requirements.[6]

Uses in system development

Scenarios have numerous possible applications in system development. Carroll (1995) lists 10 different "roles of scenarios in the system development lifecycle":[7]

  1. Requirements analysis: scenarios describe the "state-of-the-art" (often called "as-is"); acted scenarios help to discover requirements as analysts "stage a simulated work situation".
  2. User-designer communication: users contribute scenarios important to them, or situations they want to experience or avoid.[7]
  3. Design rationale: rationale can explain design "with respect to particular scenarios of user interaction".[7]
  4. Envisionment: scenarios "can be a medium for working out what a system being designed should look like and do." In this role, scenarios can be "graphical mockups such as storyboards or video-based simulations", and may form early prototypes of the system under design.[7]
  5. Software design: "scenarios can be analyzed to identify the central problem domain objects" needed; the same scenarios can be developed to describe the objects' state, behavior and interactions.[7]
  6. Implementation: software can be built one scenario at a time, helping "to keep developers focused" and "producing code that is more generally useful".[7]
  7. Documentation and Training: "scenarios of interaction that are meaningful to the users" can bridge the gap between the system as built "and the tasks that users want to accomplish using it".[7]
  8. Evaluation and testing: since "a system must be evaluated against the specific user tasks it is intended to support", scenarios are ideal for evaluation.[7]
  9. Abstraction: general rules that apply across different tasks (or systems) can be identified by comparing scenarios.[7]
  10. Team building: "a set of touchstone stories is an important cohesive element in any social system".[7]

Scenarios in differing styles of system development

The choice of scenario representation varies widely with style of development, which is related to the industrial context.

Scenarios in differing project contexts
Project context Example Scenario style Development style
Large military project Fighter aircraft Operational View, Concept of operations Staged life-cycles, thorough documentation (see DoDAF)
Combined Hardware/Software product Car Use case[8] RUP
Business software Mobile phone application User story[5] Agile software development

See also

Bibliography

References

  1. ↑ myetymology Scenario, scenery, σκηνή
  2. ↑ "Greek etymology of skene". myetymology.com. Retrieved 10 April 2015.
  3. ↑ Alexander and Beus-Dukic, 2009. Page 120
  4. 1 2 3 4 5 6 7 Alexander and Maiden, 2004. Chapter 1.
  5. 1 2 Cohn, 2004.
  6. ↑ Alexander and Maiden, 2004. Chapter 7.
  7. 1 2 3 4 5 6 7 8 9 10 Carroll, 1995. Pages 7-8
  8. ↑ Cockburn, 2011.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.