Download Spin Assessment Trainer – Use Case Models | SIE 554A and more Study Guides, Projects, Research Engineering in PDF only on Docsity!
SpAT
Spin Assessment Trainer
Product Document 6: Use Case Models
Initially Drafted: 09/18/ Intermediate Due Date: 09/25/ Completion Date: 12/05/
By:
Victor Foulk
Emily Simpson
Ted Frisiras
Kenneth Dang
With:
Tricia White
(SIE 410 Assistant)
Revisions LN Date Description Team Member 1.) 09/21/2006 Doc 6 Created VF, ES, TF 2.) 09/30/2006 New Doc 6 Template Created in EA VF 3.) 11/20/2006 New Use Cases Added with Requirements VF,TF 4.) 12/05/2006 Final Output Review for Submission VF,ES
1. Introduction
This document contains the use case model for the Spin Assessment Trainer product. The use case model consists of the use case diagram and the specification of each use case contained therein. At this level of design the system usage is not yet architecture specific although certain fundamental assumptions have been made and are reflected in the use case design. Such assumptions include the fact that this is a software product, and that BICS will be managing user profile creation and deletion external to the system.
1.1. Purpose of this Document
The purpose of this document is to define the use cases for the Spin Assessment Trainer from the system user perspective. These use cases define the scope of system functionality and how the user interacts with the system within this scope. In defining the system use cases, certain requirements imposed upon the system may be derived. These requirements are included within the use case specification, as are the necessary pre- and post-conditions for each use case.
1.2. Scope of the Model
The scope of this use case model is limited to the operation of the system as a completed, developed product. This model does not currently specify independent use cases for purposes of testing. This omission is due to the expectation that such testing during development will follow the same usage patterns as those described by normal user interaction use cases.
1.3. Assumptions
Although this use case model does not currently subscribe to a particular architecture, it is assumed that the system is being developed within the contexts of one of the proposed system architectures from product document 5. This assumption implies that the system will be accessed via a personal computer due to customer requirements. Thus, any terminology specific to the user's interaction via the computer should not be considered as specifying a particular design architecture.
2. Use Cases
2.1. Model Overview
Use Case Model Overview uc Use Case Model Ov erv iew Actors are the users of the system being modeled. Each Actor will have a well-defined role, and in the context of that role have useful interactions with the system. A person may perform the role of more than one Actor, although they will only assume one role during one use case interaction. An Actor role may be performed by a non-human system, such as another computer program. These packages contain use cases which define how an Actor will interact with the proposed system. Each interaction may be specified using scenarios, sequence diagrams, communication diagrams and other dynamic diagrams or textual descriptions which together how the system when viewed as a "black-box" interacts with a user. Use Case Model
- Administrator
- Player
- Tester
- User
- BICSSubscriptionManager
- Start SpAT
- Create New Profile
- Delete Profile
- Login
- Logout
- Perform Training Session
- Display Pitch
- View Pitch Type
- View Performance History
- Add a Pitch
- Delete a Pitch Figure 1: Use Case Model Overview
2.2. Use Case Model
Product Use Case Model uc Product Use Case Model SpAT - Product User (^) Start SpAT Login Logout Perform Training Session View Pitch Type Display Pitch View Performance History Create New Profile Player (^) Tester BICSSubscriptionManager Delete Profile Administrator Add a Pitch Delete a Pitch «extend» «extend»
2.1.7. Create New Profile Element Version: 1. This use case results in the addition of a profile to the system.Added Value: The user obtains a profile that stores usage history and grants them access to use the system. Requirements derived from this use case: Requirement ID: Description: Last Update: FR4-1 Deleted 9/24/ FR4-2 The system shall prevent profiles with duplicate usernames from being stored. [alternate flow username exists] 9/24/ FR4-3 The system shall provide the BICS Subscription Manager Service a means of adding and deleting profiles [basic path step 1]. 12/5/ Pre-condition: Initial State Status: Approved The system is ready and capable of receiving a request from the BICS Subscription Manager process. Post-condition: Final State Status: Approved A status code has been returned to the BICS Subscription Manager process. Flow: Basic Path Create New Profile
- This use case begins when the BICS Subscription Manager Service requests to add a profile to the system.2. The system receives information from manager process including the name, the type of game (i.e. baseball, softball, etc.), a username, and a password for the user.3. The system verifies that the provided username is unique.4. The system stores a profile with the supplied information.5. The system returns a success message to the manager process.6. End Use Case. Flow: Alternate Create New Profile - Cancel Unattached Alternate Flow - This alternate flow may be triggered by the user at any time during the Create New Profile use case if the user selects the cancel option.a. The system displays the initial view.b. End Use Case. Flow: Alternate Create New Profile - Username Exists
- (o3.) The system detects that the provides username matches a username associated with an existing profile.4. (o4.) The system displays and error message to the user.5. (o5.) Return to step 2 of the Basic Path. 2.1.8. Delete Profile
Element Version: 1. This use case results in the deletion of a profile from the system.Added Value: The system no longer has invalid user information, access to deleted users can now be denied. Requirements derived from this use case: Requirement ID: Description: Last Update: FR9-1 The system shall provide the BICS Subscription Manager and interface through which to delete users from the system [basic path step 1] 12/5/ Pre-condition: Initial State Status: Approved The system is ready and capable of receiving an request from the BICS Subscription Manager process. Post-condition: Final State Status: Approved A status code has been returned to the BICS Subscription Manager process. Flow: Basic Path Delete Profile
- This use case begins when the BICS Subscription Manager Service requests to delete a profile from the system.2. The system receives the username of the selected user.3. The system verifies that the provided username exists.4. The system deletes the selected user profile.5. The system returns a success message to the manager process.6. End Use Case. Flow: Alternate Delete Profile - No Such User
- (o3.) The system detects that the provides username does not match a username associated with an existing profile.4. (o4.) The system returns an error message to the manager process.5. (o5.) End Use Case 2.1.9. Login Element Version: 1. This use case results in the system verifying the user's authorization to use the system.Added Value: the user will gain access to the system or be informed that they are not authorized to use the system. Requirements derived from this use case: Requirement ID: Description: Last Update: FR2-1 The system shall accept text input from the user. [basic path step 3] 9/24/ FR2-2 The system shall maintain a variable indicating the session is authorized until the user logs out or the system is closed. [basic path step 4] 9/24/
Post-condition: Logged Out Status: Approved The user's session is terminated and the user must log in again to perform other system tasks other than create profile. Post-condition: Final State Status: Approved The system is running and displaying the initial view. Flow: Basic Path Logout
- This use case begins when the user selects the logout option.2. The system sets an authorized variable to false.3. The system displays the initial view.4. End Use Case. 2.1.11. Perform Training Session Element Version: 1. This use case results in the performance of multiple iterations of the display ball, enter deflection, correct/incorrect response display, store result in profile sequence.Added Value: The user is able to practice viewing random ball types and predicting the resultant deflection. Requirements derived from this use case: Requirement ID: Description: Last Update: FR5-1 The system shall accept user input specifying the number of pitches to display during a training session. [basic path step 3] 9/24/ FR5-2 The system shall accept user input specifying the duration of pitches to be displayed during a training session. [basic path step 3] 9/24/ FR5-3 The system shall accept user predictions about spin induced deflection using a mouse. [basic path step 5.2] 9/24/ FR5-4 The system shall provide positive or negative feedback to player. [basic path step 5.5] 9/24/ FR5-5 The system shall store user profile data consisting of a name, type of game, username and password in a persistent profile. [basic path step 5.6] 9/24/ Pre-condition: Start View Status: Approved The system is running and displaying the main menu view. Pre-condition: Logged In
Status: Approved Post-condition: History Updated Status: Approved The system has updated the user's profile history with the results of each completed iteration. Post-condition: Final View Status: Approved The system is running and displaying the main menu view. Flow: Basic Path Perform Training Session
- This use case begins when the user selects the Perform Training Session option from the main menu view.2. The system requests the number of iterations to display and the viewing duration for each ball displayed.3. The user enters a number of iterations and a viewing duration from the options available.4. The system generates a random sequence of pitch types images to display.5. For each pitch type in random sequence:5.1 Include(Display Pitch) 5.2. The system requests the direction of deflection from the user.5.3. The user enters a direction.5.4. The system compares the user input to the expected value.5.5. The system displays a message to the user indicating that the input value was correct or incorrect.5.6. The system records the results from the current iteration to the user's profile history.6. The system displays the main menu view.7. End Use Case. Flow: Alternate Perform Training Session - Cancel/Quit Unattached Alternate Flow - This alternate flow may be triggered by the user at any point in the Perform Training Session use case by selecting the cancel or quit option.a. The system displays the main menu view.b. End Use Case. 2.1.12. Display Pitch Element Version: 1. This use case results in the display of a single pitch type to the user.Added Value: The user sees the pitch type for a period of time. Requirements derived from this use case: Requirement ID: Description: Last Update: FR6-1 The system shall display video images of various pitches on a display. [basic path step 3]. 9/24/ Pre-condition: Start State Status: Approved The system is running and in a state consistent with the pre-conditions of the use case that is including this use case. Pre-condition: Logged In. Status: Approved
would experience.6. The system displays the main menu view.7. End Use Case. Flow: Alternate View Pitch Type - Cancel
- (o3.) The user selects the cancel option.4. (o4.) The system displays the main menu view.5. (o5.) End Use Case. 2.1.14. View Performance History Element Version: 1. This use case results in the display statistical information calculated from the user's profile history.Added Value: The user will be able to see how their performance has changed over time. Requirements derived from this use case: Requirement ID: Description: Last Update: FR8-1 The system shall be able to calculate % correct statistics from a profile history. [basic path step 2] 9/24/ Pre-condition: Start State Status: Approved The system is running and displaying the main menu view. Pre-condition: Logged In Status: Approved The user is logged in. Post-condition: Displayed History Status: Approved The system has displayed the user's performance history. Flow: Basic Path View Performance History
- This use case begins when the user selects the view performance history option from the main menu view.2. The system displays a view with a return to main menu option and the information from the history portion of the user's profile categorized by view duration, then by ball type. Specific data displayed will include % correct for each session within each category.3. End Use Case. 2.1.15. Add a Pitch Element Version: 1. This use case results in the addition of a pitch (media file) to the system.Added Value: The system offers a greater variety of options to the user. Pre-condition: Initial Condition Status: Approved The pitch to be added does not already exist in the system. Post-condition: Final Condition Status: Approved
A new pitch has been added to the system. Flow: Basic Path Add a Pitch
- This use case begins when the Administrator has a pitch to add to the system.2. The Administrator adds the media file to the media file directory.3. End Use Case. 2.1.16. Delete a Pitch Element Version: 1. This use case results in the removal of a pitch from the system.Added Value: Old or outdated media files can be removed from the system. Pre-condition: Intial State Status: Approved A pitch media file to be removed exists in the media file directory. Post-condition: Final State Status: Approved The pitch media file has been deleted from the system. Flow: Basic Path Delete a Pitch
- This use case begins when the Administrator has a pitch to delete from the system.2. The Administrator deletes the media file from the media file directory.3. End Use Case.
