Course Registration System
Use-Case Specification
Maintain Student Information Use Case
Version 2.0
Revision History
Date
|
Version
|
Description
|
Author
|
21/Dec/98 |
Draft |
Draft version |
S. Gamble |
15/Feb/1999 |
Version 1.0 |
Minor corrections based on
review. |
S. Gamble |
19/Feb/1999 |
Version 2.0 |
Modify section on use case
extends. Final cleanup. Add alternative flows. Resolve remaining issues. |
S. Gamble |
|
|
|
|
Table of Contents
- Brief Description
- Flow of Events
- 2.1 Basic Flow - Add Student
- 2.2 Alternative Flows
-
2.2.1 Modify a Student
-
2.2.2 Delete a Student
-
2.2.3 Student Already Exists
-
2.2.4 Student Not Found
- Special Requirements
- Preconditions
- 4.1 Log
In
- Postconditions
- Extension Points
Maintain
Student Information Use Case
- Brief Description
This use case allows the Registrar to maintain student information in the
registration system. This includes adding, modifying, and deleting students from
the system.
The actor for this use case is the Registrar.
2. Flow
of Events
The use case begins when the Registrar selects the "maintain
student" activity from the Main Form.
2.1 Basic
Flow - Add Student
- The Registrar selects "add student."
- The system displays a blank student form.
- The Registrar enters the following information for the
student: name, date of birth, social security number, status, and
graduation date.
- The system validates the data to insure the proper
format and searches for an existing student with the specified name. If
the data is valid the system creates a new student and assigns a unique
system-generated id number.
- Steps 2-4 are repeated for each student added to the
system. When the Registrar is finished adding students to the system the
use case ends.
2.2 Alternative
Flows
2.2.1
Modify
a Student
- The Registrar selects "modify student."
- The system displays a blank student form.
- The Registrar types in the student id number he/she wishes to
modify.
- The system retrieves the student information and displays it on the
screen.
- The Registrar modifies one or more of the student information
fields: name, date of birth, social security number, student id
number, status, and graduation date.
- When changes are complete, the Registrar selects "save."
- The system updates the student information.
- Steps 2-7 are repeated for each student the Registrar wants to
modify. When edits are complete, the use case ends.
2.2.2 Delete
a Student
- The Registrar selects "delete student."
- The system displays a blank student form.
- The Registrar types in the student id number for the student that's
being deleted.
- The system retrieves the student and displays the student
information in the form.
- The Registrar selects "delete."
- The system displays a delete verification dialog confirming the
deletion.
- The Registrar selects "yes."
- The student is deleted from the system.
- Steps 2-8 are repeated for each student deleted from the system.
When the Registrar is finished deleting students to the system the use
case ends.
2.2.3 Student Already
Exists
If in the "Add a Student" sub-flow the system finds an
existing student with the same name an error message is displayed
"Student Already Exists". The Registrar can either change the
name, create a new student with the same name, or cancel the operation at
which point the use case ends.
2.2.4 Student Not Found
If in the "Modify a Student" or "Delete a Student"
sub-flows the student name is not located, the system displays an error
message, "Student Not Found". The Registrar can then type in a
different id number or cancel the operation at which point the use case
ends.
3. Special Requirements
There are no special
requirements associated with this use case.
4. Preconditions
4.1 Log
In
Before this use case begins the Registrar has logged onto the system.
5. Postconditions
There are no
postconditions associated with this use case.
6.
Extension Points
There are no extension points associated with this use case.
|