COMSATS Blood Donor

Management System

Project Use Case Description

BS in Software Engineering

Group Members

PSr Registration
Name
.# ID- Sec

SP15-BSE-003,
(i) Ayesha Ali
A

SP15-BSE-071, Salman
(ii)
A Qamar

SP15-BSE-079,
(iii) Sarim Khan
A

Submitted to: Mam Sobia Zaheer

Submission Date: April 4, 2016

Department of Computer Science

COMSATS Institute of Information Technology, Lahore
 COMSATS Blood Donor Management System
Project Use Case Description
Use Case ID: UC01 Use Case Name: Database
Registration
Priority: High
Actor(s): Blood Donor, Blood Receiver, Guest User
Brief The purpose of this use case is to allow users (blood donor, blood
Description: receiver, guest user) to make online registration in COMSATS blood
donor management system.
Pre- 1. The users must fill and submit their online registration form
condition(s): in order to get registered in COMSATS blood donor
management system.
2. Blood donors and blood receivers must also submit their
blood type details along with registration form.
3. Blood donor must be greater than 17 or less than 65 years
of age, in order to get registered as a blood donor in
COMSATS blood donor management system.
4. The user must not have an existing system profile in
COMSATS blood donor management system.
Normal Flow of Events: Alternative Flows:
1. This use case starts when a user 1. If each text field is not correctly
wants to get registered in the and completely filled than the
system. system reloads the online
2. The user first fills the online registration form page.
registration form by correctly and 2. If the user selects the USER TYPE
completely filling each text field as a blood donor or blood receiver
(FIRST NAME, LAST NAME, FATHER than he/she is directed to blood
NAME, DATE OF BIRTH, CNIC type detail submission page.
NUMBER, ADDRESS, CITY, STATE, 3. The user cancels registration by
COUNTRY, EMAIL ADDRESS, ZIP selecting Cancel option during
CODE, USER TYPE, PASSWORD, system confirmation.
and RETYPE PASSWORD) in the
registration form.
3. Alternative Path: If each text field
is not correctly and completely
filled than the system reloads the
online registration form page.
4. The user submits the online
registration form.
5. The system confirms by asking
the user, Are you sure you want
to get registered with this
information?
6. The user confirms by selecting
Yes option.
7. Alternative Path: The user cancels
registration by selecting Cancel
 option.
8. Alternative Path: If the user
selects the USER TYPE as a blood
donor or blood receiver than
he/she is directed to blood type
detail submission page.
9. Uses: Blood Type Detail
Submission
10.The user gets registered in the
database.
11.The system assigns a unique ID to
the registered user.
12.This use case ends.
Exceptions:
1. Users cannot get registered in COMSATS blood donor management system
without submitting online registration form.
2. Blood donors and blood receivers cannot get registered without submitting
their blood type details.
3. If blood donor is less than 17 or greater than 65 years of age, he/she cannot
get registered as a blood donor in COMSATS blood donor management
system.
4. The user cannot get registered in the database twice.
Post-condition(s):
The user (blood donor, blood receiver, guest user) has been registered in COMSATS
blood donor management system.
Use Case Cross References
Extends: None
Includes: Blood Type Detail Submission

Use Case ID: UC02 Use Case Name: Blood Type Detail
Submission
Priority: High
Actor(s): Blood Donor, Blood Receiver
Brief The purpose of this use case is to allow blood donor and blood
Description: receiver to submit their blood type details in COMSATS blood donor
management system.
Pre- 1. During online registration form submission the user must
condition(s): select the USER TYPE as a blood donor or blood receiver
in order to submit blood type details.
2. The users must first fill and submit their online
registration form.
Normal Flow of Events: Alternative Flows:
1. This use case starts when a blood 1. If each text field is not correctly
donor or blood receiver wants to and completely filled than the
get registered in the system. system reloads the blood type
2. The blood donor or blood receiver detail submission page.
fills and submits the online 2. The blood donor or blood receiver
registration form. cancels registration by selecting
 3. The system loads the blood type Cancel option during system
detail submission page. confirmation.
4. The blood donor or blood receiver
first fills the blood type details
form by correctly and completely
filling each text field (BLOOD TYPE
NAME and TYPE Description) in
the form.
5. The blood donor or blood receiver
submits the form.
6. Alternative Path: If each text field
is not correctly and completely
filled than the system reloads the
blood type detail submission
page.
7. The system confirms by asking
the user, Are you sure you want
to get registered with this
information?
8. The blood donor or blood receiver
confirms by selecting Yes option.
9. Alternative Path: The blood donor
or blood receiver cancels
registration by selecting Cancel
option.
10.The blood donor or blood receiver
gets registered in the database.
11.The system assigns a unique
Blood Type ID to the registered
blood donor or blood receiver.
12.This use case ends.
Exceptions:
1. Blood donors and blood receivers cannot submit their blood type details in
COMSATS blood donor management system without filling and submitting
online registration form.
2. If blood donor is less than 17 or greater than 65 years of age, he/she
cannot get registered as a blood donor in COMSATS blood donor
management system.
3. Users cannot submit blood type details if they have not selected USER
TYPE as blood donor or blood receiver.
Post-condition(s):
Blood type details have been submitted.
Use Case Cross References
Extends: None
Includes: None

Use Case ID: UC03 Use Case Name: System Login

Priority: High
Actor(s): Administrator, Blood Donor, Blood Receiver, Guest User
Brief The purpose of this use case is to give access to the user
Description: (administrator, blood donor, blood receiver, guest user) by
checking if he/she is a valid registered user in COMSATS blood
donor management system.
Pre- 1. The user must be registered in COMSATS blood donor
condition(s): management system in order to login the system.
Normal Flow of Events: Alternative Flows:
1. This use case starts when a 1. If each text field is not correctly
registered user (administrator, and completely filled than the
blood donor, blood receiver, guest system reloads the system login
user) wants to access the page.
database. 2. If the user is not already
2. The user opens the system login registered in the system, he/she
page. can select CREATE NEW
3. The user fills correctly and ACCOUNT option.
completely the text fields, Email 3. In case the user has forgotten
Address and Password. his/her PASSWORD then the
4. The user clicks on the SIGN IN system sends his/her PASSWORD
button. information at his/her Email
5. Alternative Path: If each text field address.
is not correctly and completely
filled than the system reloads the
system login page.
6. Alternative Path: If the user is not
already registered in the system,
he/she can select CREATE NEW
ACCOUNT option.
7. Alternative Path: In case the user
has forgotten his/her PASSWORD
then the system sends his/her
PASSWORD information at his/her
Email address.
8. The user gains access to the
system.
9. This use case ends.
Exceptions:
1. If the user does not enter his/her correct Email and Password than he/she will
not be given any access to the system.
Post-condition(s):
The user has been given access to the system.
Use Case Cross References
Extends: None
Includes: Database Registration
Use Case ID: UC04 Use Case Name: Blood Donation
Request
Priority: High
Actor(s): Blood Donor, Administrator
Brief The purpose of this use case is to let the blood donor to send a
Description: blood donation request to the administrator of the system and
allow the administrator to accept or reject this request.
Pre- 1. The user must be registered in the system as a blood donor
condition(s): to make a blood donation request.
2. The blood donor must login the system to gain access to
make a blood donation request.
Normal Flow of Events: Alternative Flows:
1. This use case starts when the 1. If the blood donor cancels the
blood donor wants to donate action by selecting Cancel
blood to the blood donor option in the confirmation
organization. message then the system does
2. The blood donor selects the not sends blood donation request.
Blood Donation Request option 2. If the administrator rejects the
on his/her system profile screen. blood donation request then the
3. The system confirms by asking blood donor cannot donate blood.
the blood donor, Are you sure you
want to make a blood donation
request?
4. The blood donor confirms by
selecting the Yes option.
5. Alternative Path: The blood donor
cancels the action by selecting
Cancel option in the
confirmation message.
6. The system notifies the blood
donor, The Blood Donation
Request has been sent.
7. The blood donation request is
then sent to the administrator
who can accept or reject the
request.
8. If the administrator accepts this
request then the system sends a
Blood Donation Request
Accepted message with blood
donation place and time
information and contact number
of the organization on the blood
donors screen.
9. Alternative Path: If the
 administrator rejects this request
then the system sends a Blood
Donation Request Not Accepted
message on the blood donors
screen.
10.This use case ends.
Exceptions:
The system will not allow the blood donor to make a blood donation request twice
until blood has been donated by the blood donor (for the first request).
Post-condition(s):
The blood donation request was sent and has been accepted by the administrator.

Use Case Cross References

Extends: None
Includes: None

Use Case ID: UC05 Use Case Name: Blood Transfusion

Request
Priority: High
Actor(s): Blood Receiver, Administrator
Brief The purpose of this use case is to let the blood receiver to send a
Description: blood transfusion request to the administrator of the system and
allow the administrator to accept or reject this request.
Pre- 1. The user must be registered in the system as a blood
condition(s): receiver to make a blood transfusion request.
2. The blood receiver must login the system to gain access to
make a blood transfusion request.
Normal Flow of Events: Alternative Flows:
1. This use case starts when the 1. If the blood receiver cancels the
blood receiver wants to transfuse action by selecting Cancel
blood from the blood donor option in the confirmation
organization. message then the system does
2. The blood receiver selects the not sends blood transfusion
Blood Transfusion Request request.
option on his/her system profile 2. If the administrator rejects the
screen. blood transfusion request then the
3. The system confirms by asking blood receiver cannot transfuse
the blood receiver, Are you sure blood.
you want to make a blood
transfusion request?
4. The blood receiver confirms by
selecting the Yes option.
5. Alternative Path: The blood
 receiver cancels the action by
selecting Cancel option in the
confirmation message.
6. The system notifies the blood
receiver, The Blood Transfusion
Request has been sent.
7. The blood transfusion request is
then sent to the administrator
who can accept or reject the
request.
8. If the administrator accepts this
request then the system sends a
Blood Transfusion Request
Accepted message with blood
transfusion place and time
information and contact number
of the organization on the blood
receivers screen.
9. Alternative Path: If the
administrator rejects this request
then the system sends a Blood
Transfusion Request Not
Accepted message on the blood
receivers screen.
10.This use case ends.
Exceptions:
The system will not allow the blood receiver to make a blood transfusion request
twice until blood has been transfused to the blood receiver (for the first request).
Post-condition(s):
The blood transfusion request was sent and has been accepted by the
administrator.
Use Case Cross References
Extends: None
Includes: None

Use Case ID: UC06 Use Case Name: Modify Records

Priority: High
Actor(s): Administrator, Blood Donor, Blood Receiver, Guest User, Database
Manager
Brief System should enable the administrator to modify records of the
Description: database and provide the facility to rest of the users (blood donor,
blood receiver, guest user) to modify their personal contents only
in their profiles.
Pre- 1. The user must be registered in the system as an
condition(s): administrator, blood donor, blood receiver or guest user.
 2. The user must login the database to gain access and modify
records.
3. The administrator can only modify records by first informing
the user (blood donor, blood receiver, guest user).
Normal Flow of Events: Alternative Flows:
1. This use case starts when the 1. If the modification request is
administrator needs to modify the made by an invalid user, system
records in the database according will not allow the administrator to
to the users requirements. do any modification and delete
2. The administrator will access the the requests.
database. Verify the validation of
users.
3. After verification, administrator
will access the records of the valid
users that need to be modified.
4. After doing changes, administrator
will be displayed a dialog box "do
you want save the changes? This
action can't be undone".
5. After clicking on the "Okay"
button, records will be modifed.
6. This action will be notified to the
Database Manager, he/she will
update the system database after
the deletion.
Exceptions:
The user cannot modify information if he/she is not registered in the database.
Post-condition(s):
1. Modifications in the user's records will be done according to the user's
requirements.
2. Administrator will be displayed a message on the screen "Records modified,
changes are saved".
3. Users will be notified about the modification.
4. Database will be updated by the Database Manager.

Use Case Cross References

Extends: None
Includes: None

Use Case ID: UC07 Use Case Name: Add Records

Priority: High
Actor(s): Administrator, Database Manager
Brief This use case enables the administrator to add new records of the
Description: valid users in the database.
Pre- 1. Login the system.
condition(s): 2. Access the users' database.
3. Verify if the records to be entered are of valid users or not.
Normal Flow of Events: Alternative Flows:
1. This use case starts when the 1. If the request is made by an invalid
administrator needs to add new user, administrator will not enter the
records in the database according fields containing data of invalid user.
to the users requirements.
2. The administrator will access the
database. Verify the validation of
users.
3. After verification, administrator
will access the databases of the
particular users to add new
records.
4. After adding new records,
administrator will be displayed a
dialog box "do you want save the
changes? This action can't be
undone".
5. After clicking on the "Okay"
button, records will be added.
6. This action will be notified to the
Database Manager, he/she will
update the system database after
the deletion.
Exceptions:
The administrator cannot add records if he/she is not registered in the database.
Post-condition(s):
1. Records of valid users will be entered by the administrator in the users'
database.
2. Administrator will be displayed a message on the screen "Records added and
saved!".
3. Database will be updated by the Database Manager.
Use Case Cross References
Extends: None
Includes: None

Use Case ID: UC08 Use Case Name: Delete Records

Priority: Low
Actor(s): Administrator, Database Manager
Brief This use case enables the administrator to delete records of the
Description: invalid users in the database.
Pre- 1. Login the system.
condition(s): 2. Access the users' database.
3. Verify if the records to be deleted are of valid users or not.
Normal Flow of Events: Alternative Flows:
1. This use case starts when the 1. If the request is made by an
administrator needs to delete invalid user, administrator will not
records in the database according enter the fields containing data of
to the users requirements. invalid user.
2. The administrator will access the
database. Verify the validation of
users.
3. After verification, administrator
will access the databases of the
particular users to add new
records.
4. After adding new records,
administrator will be displayed a
dialog box "do you want save the
changes? This action can't be
undone".
5. After clicking on the "Okay"
button, records will be added.
6. This action will be notified to the
Database Manager, he/she will
update the system database after
the deletion.

Exceptions:
The administrator cannot delete information if he/she is not registered in the
database.
Post-condition(s):
1. Records of valid users will be entered by the administrator in the users'
database.
2. Administrator will be displayed a message on the screen "Records added and
saved!".
3. Database will be updated by the Database Manager.

Use Case Cross References

Extends: None
Includes: None

Use Case ID: UC09 Use Case Name: Administrators

Request(s)
Priority: High
Actor(s): Administrator
Brief This use case enables the administrator to send Update
Description: Database, Add New Fields or Reset Password Request to the
 Database Manager.
Pre- 1. Login to access the database.
condition(s): 2. Send request to database manager to update database,
add new fields in the system's database or reset
passwords.

Normal Flow of Events: Alternative Flows:

1. This use case starts when the 1. If the response is not being
administrator needs to update received by the administrator
database, add new fields in the from the database manager
system's database and reset system should display a dialog
box on administrator's screen "In
passwords according to his/her
case of no response, contact to
requirements.
the manager here: (link to contact
2. The administrator will login the
the developer will be displayed
system.
3. Administrator will jump to the here)."
2. If the administrator can't send
request page displayed in the
request due to any errors, system
administrator's profile menu.
should display a dialog box on
Request Page will be displayed.
administrator's screen "Contact
4. Administrator will send the
the developer of the product here:
particular request(s) to the
(link to contact the developer will
Database Manager by selecting
be displayed here)."
the particular options displayed on
the page.
5. After clicking on the "Send"
button, request(s) will be sent.
6. The system will transfer the
request to the Database Manager,
he/she fullfil the request and
update the system's database.

Exceptions:
The administrator cannot send request if he/she is not registered in the database.
Post-condition(s):
1. Administrator will be displayed a message on administrators screen
"Request(s) fulfilled!".
2. Database will be updated by the database manager.

Use Case Cross References

Extends: None
Includes: None

UC10: Manage Database

Use Case ID: UC10-01 Use Case Name: Update Database
Priority: Medium
Actor(s): Database Manager
Brief This use case will allow the database manager to update the
Description: contents of database (add new fields/add new features in system)
on administrators request.
Pre- The Database Manager can update contents of database if
condition(s): administrator has sent a request to update database.
Normal Flow of Events: Alternative Flows:
1. This use case starts when the 1. If the database manager notifies
administrator wants to update the the administrator that the desired
contents of database. changes are impossible to make
2. The administrator sends a update then contents of database and
database request to the database system will not be updated.
manager; it is displayed in
database managers notifications.
3. The database manager updates
the contents of database as
desired by admin (add new
fields/add new features in
system).
4. The database manager saves the
changes in the database.
5. The database manager sends a
message to the administrator to
notify him/her that desired
changes in system have been
completed; it is displayed in
administrators notifications.
6. This use case ends.
Exceptions:
1. The database manager cannot update database and system if administrator
has not made any request.
2. If the database manager notifies the administrator that the desired changes
are impossible to make then contents of database and system will not be
updated.
Post-condition(s):
The contents of the database and the system have been updated.
Use Case Cross References
Extends: None
Includes: Administrators Request

UC10: Manage Database

Use Case ID: UC10-02 Use Case Name: Reset Password
Priority: Low
Actor(s): Database Manager
Brief This use case will allow the database manager to reset the
Description: password of the system profile of a user (administrator, blood
donor, blood receiver, guest user) on administrators request.
Pre- 1. The Database Manager can reset the password of the
condition(s): system profile of a user (administrator, blood donor, blood
receiver, guest user) if administrator has sent a request to
reset password.
Normal Flow of Events: Alternative Flows:
1. This use case starts when the 1. If the database manager notifies
administrator wants to reset the the administrator that the desired
password of the system profile of changes are impossible to make
a user (administrator, blood then password cannot be reset in
donor, blood receiver, guest user) the database.
or another user has indirectly
requested the administrator to
reset password.
2. The administrator sends a reset
password request to the database
manager; it is displayed in
database managers notifications.
3. The database manager resets the
password of user system profile in
the database.
4. The database manager saves the
changes in the database.
5. The database manager sends a
message to the administrator to
notify him/her that desired
changes in system have been
completed; it is displayed in
administrators notifications.
6. This use case ends.
Exceptions:
1. The database manager cannot reset the password if administrator has not
made any request.
2. If the database manager notifies the administrator that the desired changes
are impossible to make then password cannot be reset in the database.

Post-condition(s):
The password of the system profile of user (administrator, blood donor, blood
receiver, guest user) has been reset.
Use Case Cross References
Extends: None
Includes: Administrators Request