Use Case Number: 1
Use Case Name: Maintain Employee Information
Actor: Administrator.
Description
This use case allows the Administrator to maintain employee information. This
includes adding, changing, and deleting employee information from the system.
Happy Case:
This use case starts when the Administrator wishes to add, change, and/or delete
employee information from the system.
1. The system requests that the Administrator specify the function he/she would like to
perform (either Add an Employee, Update an Employee, or Delete an Employee)
2. Once the Administrator provides the requested information, one of the subflows is
executed.
If the Administrator selected Add an Employee, the Add an Employee subflow is
executed.
If the Administrator selected Update an Employee, the Update an Employee
subflow is executed.
If the Administrator selected Delete an Employee, the Delete an Employee
subflow is executed.
Add an Employee
3. The system requests that the Administrator enter the employee information. This
includes:
name
employee type (hour, salaried, visiting)
mailing address
phone number
hourly rate (for visiting employees)
salary (for salaried employees)
4. Once the Administrator provides the requested information, the system generates
and assigns a unique employee id number to the employee and sets the pay check
delivery method to default of pickup. The employee is added to the system.
5. The system provides the Administrator with the new employee id.
Update an Employee
6. The system requests that the Administrator enter the employee id.
7. The Administrator enters the employee id. The system retrieves and displays the
employee information.
8. The Administrator makes the desired changes to the employee information. This
includes any of the information specified in the Add an Employee sub-flow.
9. Once the Administrator updates the necessary information, the system updates the
employee record with the updated information.
Delete an Employee
10. The system requests that the Administrator specify the employee id.
11. Administrator enters the employee id. The system retrieves and displays the
employee information.
12. The system prompts the Administrator to confirm the deletion of the employee.
13. The Administrator verifies the deletion.
14. The system marks the employee record for deletion. The next time the software is
run, the software will remove the employee from the system.
Alternative:
Employee Not Found
If in the Update an Employee or Delete an Employee sub-flows, an employee
with the specified id number does not exist, the system displays an error message.
The Administrator can then enter a different id number or cancel the operation, at
which point the use case ends.
Delete Cancelled
If in the Delete An Employee sub-flow, the Administrator decides not to delete the
employee, the delete is cancelled and the Happy Case is re-started at the
beginning.
Pre-Conditions
The Administrator must be logged onto the system before this use case begins.
Post-Conditions
If the use case was successful, the employee information is added, updated, or
deleted from the system. Otherwise, the system state is unchanged.
Use Case number: 2
Actor: Account User
Use Case Name: Verify Identity & account
Description: The use case describes how a user logs into his/her account.
Happy Case:
The software requests a user to enter username and password. The user login the account
by entering her/his username password. The system validates the username and password
and logs the user in his/her account.
Alternative Case:
If in the happy case the user enters an invalid username and/or password, the system
displays an error message.
1. The user is unable to access his/her account. Access denied message is displayed.
2. The user account is disabled. Your account has been disabled by administrator. You can
no longer access your account message is displayed.
3. The user can choose to either return to the beginning of the happy case or cancel the
login, or try accessing his/her account at which point the use case ends.
Pre-condition: User should be registered and have an account.
Post-condition: User logged in successfully.
Use Case Number: 3
Actor: Accountant
Use Case Name: Data Entry
Description: The use case describes how the accountant enters transactions, billing
information, payable, receivable etc.
Happy Case: The actor is able to enter transactions, payable, receivable and other billing
information correctly and in the correct place.
Alternative Case: The accountant is not able to enter correct data or in the correct place
or maybe the data cannot be entered altogether. So the accountant may choose to return to
the beginning of the happy case or stop entering data altogether, at which point the use
case ends.
Pre-condition: The user must be logged in his/her account and space should provided for
entering data in the software.
Post-condition: Data entered correctly without error.
Use Case Number: 4
Actor: Accountant
Use Case Name: Report Generation
Description: The use case describes how the accountant generates and prints profit/loss
report.
Happy Case:
1. Once the accountant provides the requested information, the system provides the
accountant with a report satisfying the report criteria.
2. The accountant may then request that the system save the report. At which
time, the system requests the accountant to provide the name and location for
saving the report.
3. Once the accountant provides the requested information, and confirms the
decision to save the report, the system saves the report to the specified name
and location.
4. If the accountant did not elect to save the report, the report is discarded.
5. The report is printed successfully.
Alternative Case:
Requested Information Unavailable
If in the Happy Case, the requested information is unavailable, the system will
display an error message. The accountant can choose to either return to the
beginning of the Happy Case, or cancel the operation, at which point the use case
ends.
Invalid Format or Insufficient Information
If in the Happy Case, the accountant has not specified sufficient information to
create the selected report, the system will prompt the actor for the missing
information. The accountant can either enter the missing information or choose to
cancel the operation, at which point the use case ends.
Pre-condition: The user must be logged in and sufficient and valid data is needed on which
the report should be generated.
Post-condition: Report printed successfully.
Use Case Number: 5
Actor: Administrator
Use Case Name: Online Access
Description: This use case describes the actors access to accounts software online.
Happy Case: The actor is able to access the software online. He/she can see entries or
enter data as well.
Alternative Case: The actor is unable to access the software online.
1. The server maybe is down.
2. The session timed out.
3. Operation Timed out.
4. The network connection failed.
So the actor may choose to return to the beginning of the happy case or stop trying to
access the software online, at which point the use case ends.
Pre-condition: Only administrator is able to access online.
Post-condition: Software accessed online successfully.
Use Case Number: 6
Actor: Administrator & Accountant
Use Case Name: Search by keyword
Description: The use case describes how the actor searches the required information by
entering the keyword.
Happy Case: The actor enters the keyword for the required information for the search.
The system checks the keyword then generates the search.
If the search is successful the actor is able to find the right information.
Alternative Case:
The actor may enter the wrong keyword for required information or is unable to find
anything by entering some keyword. So the actor may choose to return to the beginning of
happy case or stop searching by entering keyword, at which point the use case ends.
Pre-condition: The actor must be logged in to enter some keyword for required
information.
Post-condition: Keyword matched and required data retrieved successfully.
Use Case Number: 7
Actor: Accountant
Use Case Name: Maintain Purchase Information.
Description: This use case allows the accountant to maintain suppliers and purchase
information. This includes adding, changing, and deleting suppliers information and the
purchase information from the system.
Happy Case:
This use case starts when the accoountant wishes to add purchase, update purchase
information change, and/or delete purchase information from the system.
1. The system requests that the accountant specify the function he/she would like
to perform (either Add a purchase, Update purchase information, or Delete
purchase information).
2. Once the accountant provides the requested information, one of the subflows is
executed.
If the accountant selected Add a purcase, the Add a Purchase subflow is
executed.
If the accountant selected Update purchase information, the Update Purchase
Information subflow is executed.
If the accountant selected Delete purchase information, the Delete Purchase
Information subflow is executed.
Add a Purchase:
The system requests that the accountant enter the employee information. This includes:
name of supplier
purchase type
Purchase time & date
mailing address of supplier
phone number of supplier
billing type (check, cash, deposit).
Pending bill information
1. Once the accountant provides the requested information, the system generates
and assigns a unique supplier id number to the supplier and sets the pay check
delivery method to default of pickup. The supplier and purchase is added to
the system.
2. The system provides the accountant with the new purchase no & id.
Update an Employee
1. The system requests that the accountant enter the purchase id.
2. The accountant enters the purchase id. The system retrieves and displays the
purchase information.
3. The accountant makes the desired changes to the purchase information. This
includes any of the information specified in the Add a Purchase sub-flow.
4. Once the accountant updates the necessary information, the system updates the
purchase account with the updated information.
Delete Purchase Information
1. The system requests that the accountant specify the purchase id.
2. Accountant enters the purchase id. The system retrieves and displays the
purchase information.
3. The system prompts the accountant to confirm the deletion of the purchase
information.
4. The accountant verifies the deletion.
5. The system marks the particular purchase information for deletion. The next
time the software is run, it will remove the purchase information from the
system.
Alternative:
Purchase Not Found
If in the Update Purchase Information or Delete Purchase Information sub-
flows, a purchase order with the specified id number does not exist, the system
displays an error message. The accountant can then enter a different purchase id or
cancel the operation, at which point the use case ends.
Delete Cancelled
If in the Delete purchase information sub-flow, the accountant decides not to
delete some purchase information, the delete is cancelled and the Happy Case is re-
started at the beginning.
Pre-Conditions
The accountant must be logged onto the system before this use case begins.
Post-Conditions
If the use case was successful, the purchase information is added, updated, or
deleted from the system. Otherwise, the system state is unchanged.
Use Case Number: 8
Use Case Name: Run Payroll
Actor: Administrator
Description
The use case describes how the payroll is run every last working day of the month.
Happy Case:
The use case begins when its time to run the payroll. The payroll is run
automatically every last working day of the month.
3. The system retrieves all employees who should be paid on the current date.
4. The system calculates the pay using entered attendance, employee information
e.g. salary and all legal deductions.
5. Checks the payment delivery method.
6. The use case ends when all employees receiving pay for the desired date have
been processed.
Alternative:
Deleted Employees
After the payroll for an Employee has been processed, if the employee has been
marked for deletion (see the Maintain Employee use case) then the system will
delete the employee.
Pre-Conditions
The user must be administrator.
Post-Conditions
Payments for each employee eligible to be paid on the current date have been
processed.
Use Case Number: 9
Use Case Name: Maintain student record
Actor: Student
Description: The use case describes how the fee is received from students and how student
information is maintained.
Happy Case: The use case starts by entering information about each student.
Add a student:
1. Enter required information about each student
Student name
Address
Email address
Phone number
Department
Semester
Payment method (installment, check, deposit)
Fee required
2. The system then generates a unique id against each student.
Update student information
1. The system requests that the accountant enter the student id.
2. The accountant enters the employee id. The system retrieves and displays the
student information.
3. The accountant makes the desired changes to the student information. This includes
any of the information specified in the Add a student sub-flow.
4. Once the accountant updates the necessary information, the system updates the
student record with the updated information.
Maintain Fee Information:
1. Receive fee from student by checking his/her attendance.
If fee received late receive fine according to the date.
If attendance is short receive fine by checking attendance percentage.
2. Receive registration fee from new students.
3. receive fee by checking the student information (Add a student subflow).
Delete Student Information
15. The system requests that the accountant specify the student id.
16. Accountant enters the employee id. The system retrieves and displays the employee
information.
17. The system prompts the student to confirm the deletion of the employee.
18. The Accountant verifies the deletion.
19. The system marks the student record for deletion. The next time the software is run,
the software will remove the student from the system.
Alternative:
Student Not Found
If in the Update an Student or Delete an Student sub-flows, a student with the
specified id number does not exist, the system displays an error message. The
Accountant can then enter a different id number or cancel the operation, at which
point the use case ends.
Delete Cancelled
If in the Delete A Student sub-flow, the Accountant decides not to delete the
student, the delete is cancelled and the Happy Case is re-started at the beginning.
Short Attendance
The student may have a short attendance or the Student may have left the university.
Late fee Submission
The student had not submitted the fee not in time.
Pre-condition: The student information should be entered.
Post-condition: Fee received on time.
