Load Array from File
Use Case ID: Array2.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: Functional
{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: The user needs to access an array in a file, to edit it, to print it, to save it, to do many things with it, and they all require this use case.
{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: User knows there is a viable file to load. User selected either "Display array", "Edit Array", "Map Array to Problem", "Print Array", or "Save Array"
{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 choosing one of the options listed above, the user selects the appropriate file of their choosing
{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 either "Display array", "Edit Array", "Map Array to Problem", "Print Array", or "Save Array"
The system responds by bringing up a file selection box, enabling the user to select the desired file
Post-conditions: Array is loaded into the system and is ready to be used in whatever way the user wants
{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: corrupt file; file not there
{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: edit, save, print, map array to problem, display array use cases
{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: 10 times an execution
{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: essential, wouldn't work without it
{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: not risky
{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: Sunday, April 1, 2001{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.}