This document is worth 50 points (out of 500 total
on the project).
Scenarios are a method for requirements elicitation where engineers write detailed descriptions of how people interact with the system being developed. In the process of writing down how the system should behave once it is fully implemented, many details need to be resolved, and resolving these questions leads to an improved understanding of the system, and its requirements. Scenarios also make the intended behavior more visible, since they are easy to understand by both stakeholders and engineers. This increased visibility can expose disagreements among customers and engineers concerning the system's behavior, and thereby lead to resolution of the conflict.
The scenarios document should contain a table of contents, and then 5-10 pages of scenarios (do not exceed 10 pages of scenarios). Each scenario should have a title (typically the heading of that section) and then the textual description of the scenario.
Ideally, each scenario should cover a different aspect of the system's functionality, and together the scenarios should encompass the majority of the system's behavior. If you are unable to cover all of your project's functionality in 10 pages, focus on the most important capabilities.
There are many possible ways to write scenarios. See textbook, page 37 for an example of one informal scenario. For this class, your scenarios should be written in prose, and should involve named people (e.g., "Mary", "John", not "User A" or "the user") performing concrete actions with the system. Be as specific as you can (including who your users are, and what relevant characteristics they have), since the process of filling in the details leads to questions whose answers yield an improved understanding of the system.
Scenarios will be graded based on their internal consistency (are the scenarios contradictory), and how well they represent the important functional aspects of the project (do the scenarios address substantive issues, or trivial functionality). Note that length is not necessarily correlated with quality; a long document with redundant scenarios would receive a lower grade than a short, concise document with a well chosen set of scenarios.
Here is an example of a scenario for an HTML authoring tool called DistEdit:
1.2 Opening a Remote HTML Document
Jane, the maintainer of a web page, needs to update its HTML source. There are no other variants to this page, such as translations into other languages. Within DistEdit, she goes to the File ... Open menu option. The FileOpen dialog box appears. Jane clicks on the button labeled "Remote Sites," causing a list of previously defined remote Web sites to appear in the scroll window within the FileOpen dialog box. Additionally, a new button, "New Remote Site" appears.
Jane double-clicks on the name of an existing site, and (after authenticating herself, if necessary) is presented with a listing of the members of the top level directory of that site in the scroll windows. Jane selects an HTML document from those listed, and the dialog box disappears. DistEdit then locks the HTML document, and loads it into the HTML editor.
NOTE
It is common for group members to do some risk reduction activities. Students sometimes experiment with the programming language and with parts of the proposed solution that may pose problems later in the quarter. They will do a 'quick and dirty' coding of some of the functions necessary to their solution. This activity is called a 'proof of concept' and can save time later in the quarter.