Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Scenario (computing)
open-in-new
<h2 id="types-of-scenario-in-system-development">Types of scenario in system development</h2> <p>Many types of scenario are in use in system development. Alexander and Maiden<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> list the following types: </p> <ul><li><a href="/facts/Narrative/RIVoxJpV">Story</a>: "a narrated description of a causally connected sequence of events, or of actions taken".<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> : 8–10 Brief <a href="/facts/User_story/UAoH2fI5">User stories</a> are written in the <a href="/facts/Agile_software_development/LDaISBAW">Agile</a> style of software development.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a></li> <li>Situation, <a href="/facts/Scenario_analysis/SHMWDWGv">Alternative World</a>: "a projected future situation or snapshot". This meaning is common in planning, but less usual in software development.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> : 10 </li> <li><a href="/facts/Simulation/Q4QJV1oI">Simulation</a>: use of models to explore and animate 'Stories' or 'Situations', to "give precise answers about whether such a scenario could be realized with any plausible design" or "to evaluate the implications of alternative possible worlds or situations".<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> : 10–11 </li> <li><a href="/facts/Storyboard/mTPt4P3m">Storyboard</a>: a drawing, or a sequence of drawings, used to describe a user interface or to tell a story. This meaning is common in <a href="/facts/Human%E2%80%93computer_interaction/EkmIxGCx">Human–computer interaction</a> to define what a user will see on a screen.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> : 12 </li> <li>Sequence: a list of interactive steps taken by human or machine agents playing system roles. The many forms of scenario written as sequences of steps include Operational Scenarios, Concepts of Operations, and Test Cases.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> : 12–14 </li> <li>Structure: any more elaborately-structured representation of a scenario, including <a href="/facts/Flowchart/BtNXBfUG">Flowcharts</a>, <a href="/facts/Unified_Modelling_Language/3tlNS0tH">UML</a>/ITU 'Sequence Charts', and especially in software development <a href="/facts/Use_case/8pNHjsIr">Use cases</a>.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> : 14–17 </li></ul> <p>Negative scenarios or <a href="/facts/Misuse_case/6UlSazCP">misuse cases</a> may be written to indicate likely threats which should be countered to ensure that systems have sufficient <a href="/facts/Security/B4uxkyxh">security</a>, <a href="/facts/Safety/jyH5HLSg">safety</a>, and <a href="/facts/Reliability_engineering/cd6AS5w3">reliability</a>. These help to discover <a href="/facts/Non-functional_requirements/HQSfMlH2">non-functional requirements</a>.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> </p> <h2 id="uses-in-system-development">Uses in system development</h2> <p>Scenarios have numerous possible applications in system development. Carroll (1995) lists 10 different "roles of scenarios in the system development lifecycle":<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> </p> <ol><li><a href="/facts/Requirements_analysis/fHtWUoMs">Requirements analysis</a>: scenarios describe the "state-of-the-art" (often called "as-is"); acted scenarios help to discover requirements as analysts "stage a simulated work situation".</li> <li><a href="/facts/Requirements_elicitation/uKAWwUWj">User-designer communication</a>: users contribute scenarios important to them, or situations they want to experience or avoid.<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a></li> <li><a href="/facts/Design_rationale/bwUAQBSU">Design rationale</a>: rationale can explain design "with respect to particular scenarios of user interaction".<a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a></li> <li><a href="/facts/Mockup/CdWgWXxR">Envisionment</a>: 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 <a href="/facts/Prototype/q0yPLYdb">prototypes</a> of the system under design.<a class="footnote-ref" id="fnref:15" href="#fn:15"><sup>15</sup></a></li> <li><a href="/facts/Software_design/61rGr5Ej">Software design</a>: "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.<a class="footnote-ref" id="fnref:16" href="#fn:16"><sup>16</sup></a></li> <li><a href="/facts/Implementation/IH1KXgP3">Implementation</a>: software can be built one scenario at a time, helping "to keep developers focused" and "producing code that is more generally useful".<a class="footnote-ref" id="fnref:17" href="#fn:17"><sup>17</sup></a> <p class="note">Further information: <a href="/facts/Use_case/8pNHjsIr">Use case</a> and <a href="/facts/Software_development_process/cIDtuNPN">Software development process</a></p></li> <li><a href="/facts/Software_documentation/cSXDUPPg">Documentation</a> and <a href="/facts/Training/K6REWYIn">Training</a>: "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".<a class="footnote-ref" id="fnref:18" href="#fn:18"><sup>18</sup></a></li> <li><a href="/facts/Software_testing/VoXzG9Tb">Evaluation and testing</a>: since "a system must be evaluated against the specific user tasks it is intended to support", scenarios are ideal for evaluation.<a class="footnote-ref" id="fnref:19" href="#fn:19"><sup>19</sup></a></li> <li><a href="/facts/Abstraction/p7l9eHGd">Abstraction</a>: general rules that apply across different tasks (or systems) can be identified by comparing scenarios.<a class="footnote-ref" id="fnref:20" href="#fn:20"><sup>20</sup></a></li> <li><a href="/facts/Team_building/X8wp5aN0">Team building</a>: "a set of touchstone stories is an important cohesive element in any social system".<a class="footnote-ref" id="fnref:21" href="#fn:21"><sup>21</sup></a></li></ol> <h2 id="in-differing-styles-of-system-development">In differing styles of system development</h2> <p>The choice of scenario representation varies widely with style of development, which is related to the industrial context. </p> Scenarios in differing project contexts<table><tbody><tr><th>Project context</th><th>Example</th><th>Scenario style</th><th>Development style</th></tr><tr><td>Large military project</td><td>Fighter aircraft</td><td><a href="/facts/Operational_View/78zEKNFB">Operational View</a>, <a href="/facts/Concept_of_operations/2NFBSMf1">Concept of operations</a></td><td>Staged life-cycles, thorough documentation (see <a href="/facts/Department_of_Defense_Architecture_Framework/fjB2hV0z">DoDAF</a>)</td></tr><tr><td>Combined Hardware/Software product</td><td>Car</td><td><a href="/facts/Use_case/8pNHjsIr">Use case</a><a class="footnote-ref" id="fnref:22" href="#fn:22"><sup>22</sup></a></td><td><a href="/facts/IBM_Rational_Unified_Process/fzHdkJw0">RUP</a></td></tr><tr><td>Business software</td><td>Mobile phone application</td><td><a href="/facts/User_story/UAoH2fI5">User story</a><a class="footnote-ref" id="fnref:23" href="#fn:23"><sup>23</sup></a></td><td><a href="/facts/Agile_software_development/LDaISBAW">Agile software development</a></td></tr></tbody></table> <h2 id="see-also">See also</h2> <ul><li><a href="/facts/Happy_path/70kUu2hN">Happy path</a></li> <li><a href="/facts/Scenario_testing/59Hgq31c">Scenario testing</a></li> <li><a href="/facts/Strategic_assumptions/9EPRj5cA">Strategic assumptions</a></li> <li><a href="/facts/Computer_supported_brainstorming/BkPzC5Gx">Computer supported brainstorming</a></li></ul> <h2 id="bibliography">Bibliography</h2> <ul><li>Alexander, Ian and Beus-Dukic, Ljerka. <i>Discovering Requirements: How to Specify Products and Services</i>. Wiley, 2009.</li> <li>Alexander, Ian F. and Maiden, Neil. <i>Scenarios, Stories, Use Cases</i>. Wiley, 2004.</li> <li>Carroll, John M. (ed) <i>Making Use: Scenario-based Design of Human-Computer Interactions</i>. MIT Press, 2000.</li> <li>Carroll, John M. (ed) <i>Scenario-Based Design: Envisioning Work and Technology in System Development</i>. Wiley, 1995.</li> <li>Cockburn, Alistair. <i>Writing Effective Use Cases</i>. Addison-Wesley, 2001.</li> <li>Cohn, Mike. <i>User Stories Applied: for Agile Software Development</i>. Addison-Wesley, 2004.</li> <li>Fowler, Martin. <i>UML Distilled</i>. 3rd Edition. Addison-Wesley, 2004.</li></ul> <h2 id="external-links">External links</h2> <ul><li><a href="http://tomeri.org/Stories.html">Notes on Design Practice: Stories and Prototypes as Catalysts for Communication.</a> by Thomas Erickson, in Carroll, 1995.</li></ul> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>etymonline.com <a href="https://www.etymonline.com/search?q=scenario" target="_blank">https://www.etymonline.com/search?q=scenario</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>Alexander and Beus-Dukic, 2009. Page 120 <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>Alexander and Maiden, 2004. Chapter 1. <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>Alexander and Maiden, 2004. Chapter 1. <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Cohn, 2004. <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>Alexander and Maiden, 2004. Chapter 1. <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>Alexander and Maiden, 2004. Chapter 1. <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>Alexander and Maiden, 2004. Chapter 1. <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>Alexander and Maiden, 2004. Chapter 1. <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>Alexander and Maiden, 2004. Chapter 1. <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>Alexander and Maiden, 2004. Chapter 7. <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> <li id="fn:15"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:15" class="footnote-back-ref">↩</a></p></li> <li id="fn:16"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:16" class="footnote-back-ref">↩</a></p></li> <li id="fn:17"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:17" class="footnote-back-ref">↩</a></p></li> <li id="fn:18"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:18" class="footnote-back-ref">↩</a></p></li> <li id="fn:19"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:19" class="footnote-back-ref">↩</a></p></li> <li id="fn:20"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:20" class="footnote-back-ref">↩</a></p></li> <li id="fn:21"><p>Carroll, 1995. Pages 7-8 <a href="#fnref:21" class="footnote-back-ref">↩</a></p></li> <li id="fn:22"><p>Cockburn, 2011. <a href="#fnref:22" class="footnote-back-ref">↩</a></p></li> <li id="fn:23"><p>Cohn, 2004. <a href="#fnref:23" class="footnote-back-ref">↩</a></p></li> </ol>