Display Array
Use Case ID: Display2.0
{This field contains a document control number and will be tracked by the project. It is used to identify the owning team and the level of the use case. The use case id will be assigned by the project manager and the steering committee.}
Use Case Level: Abstract
{This field describes the scope of the functionality contained in the use case. It is later used to create a use case hierarchy structue. The level will be determined by the development team.}
Scenario:
{This field describes as completely as possible this particular use by providing additional information not contained in the following sub-sections..}
Actor: System User
{This field describes the role of the person or system performing this use.}
Pre-Conditions: That the user has loaded an array from file, or has constructed one him/herself; a valid array must be ready to go.
{This field describes how the system has been used in preparation for running this use case. It lists any previous requirements of the system related to this use case.}
Detailed Description: After the user has entered the necessary data into the orthogonal array, they have the option of putting it up on the screen for display. If they choose to do so, they select "display array" and then they must choose the correct file to load, which OATS will then display on the screen.
{This field provides a detailed description of the use by providing additional information not contained in he following sub-sections. Each sub-section is explained below and should be completed as thoroughly as possible. Please do not repeat information contained within the sub-sections here in this description.}
Trigger:
{This field describes and lists what actions the user performs to initiate the use case and exactly how the system responds. Include any additional uses that would normally be invoked by this particular use.}
The user initiates an action by selecting the option "load array from file" from the menu.
The system responds by bringing up a file selection box, giving the user a choice of what file to load.
Post-conditions: The selected array is displayed on the screen.
{This field describes the state of the system following the successful completion of this use. Any additional affects on other systems or actors may also be described.}
Alternative Courses of Action: none
{This field presents other Scenarios that are related to the main scenario listed above, but that differ in very small ways.}
Extensions:
{This field presents variations to this use case that could "specialize" it.}
Exceptions: File selected is corrupt;
{This field describes all error conditions that can arise during the execution of this use case.}
Concurrent Uses:
{This field lists any other uses that can occur concurrently with the uses listed in this use case.}
Related Use Cases: Load array from file
{This field contains references to use cases describing uses that are usually performed just before or just after the current use.}
External Supporting Information
Requirement Originator:
{This field contains the contact information for the person(s) who originated this particular use of the system. Please include the name, job title or description of work performed, address, telephone number, email address, and connection to this project for all persons listed.}
Rational For Requirement:
{This field contains the rational given by the requirement originator as to why this particular requirement should be included in the system.}
Additional Relevant Requirements:
{This field contains references to any other requirements documents or additional sources. If an industry standard document is related to or originates this requirement, that document will be listed here.}
Decision Support
Frequency:
{How often will this use of the system occur? Usually stated in terms of number of times per application execution, but can be stated in terms of number of times per hour of execution for always available systems. This field is combined with the criticality field to determine the number of tests that will be used to test the functionality. It may also be used in certain design decisions.}
Criticality:
{How necessary is this use to the successful functioning of the program from a user's perspective. Its absence may not cause the system to crash, but it may prevent the user from accomplishing their goal. This field is used to assist in determining the extent to which the use will be tested.}
Risk:
{The project risk associated with providing this use. This is used in project planning. Often riskier uses will be implemented early to provide sufficient recovery time.}
Modification History
Use Case Recorder: Doug Farrington
{This field is automatically filled in with the name of the person who is recording this use case. It can be deleted if incorrect and manually entered.}
Initiation
Date:
{This field is automatically filled in with the exact date and time this use case was initially recorded.}
Last
Modified:
{This
field is automatically filled in with the last modified date and time
and the persons name who made the modification.}