This final scenario document is worth 50 points (out of 500 total
on the project).
Scenarios are a method for requirements elicitation, analysis, and specification where software engineers write detailed descriptions of how actors (users and other members outside the software product) interact with the system under development. 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 the textbook in chapter 11 for examples. For this class, your scenarios should be written in prose, and should involve actors performing concrete actions with 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
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, the maintainer goes to the File ... Open menu option. The FileOpen dialog box appears. The maintainer 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.
The mainainer double-clicks on the name of an existing site, and (after authentication , if necessary) is presented with a listing of the members of the top level directory of that site in the scroll windows. The maintainer 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.