Project Use Case Description Final 4a3d2c

COMSATS Blood Donor Management System Project Use Case Description

BS in Software Engineering

Group PSr .#

Registration ID- Sec

Name

(i)

SP15-BSE-003, A

Ayesha Ali

(ii)

SP15-BSE-071, A

Salman Qamar

(iii)

SP15-BSE-079, A

Sarim Khan

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 Brief The purpose of this use case is to allow s (blood donor, blood Description: receiver, guest ) to make online registration in COMSATS blood donor management system. Pre1. The s must fill and submit their online registration form condition(s): in order to get ed 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 ed as a blood donor in COMSATS blood donor management system. 4. The 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 1. If each text field is not correctly wants to get ed in the and completely filled than the system. system reloads the online 2. The first fills the online registration form page. registration form by correctly and 2. If the selects the 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 cancels registration by COUNTRY, EMAIL ADDRESS, ZIP selecting “Cancel” option during CODE, TYPE, , system confirmation. and RETYPE ) 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 submits the online registration form. 5. The system confirms by asking the , “Are you sure you want to get ed with this information?” 6. The confirms by selecting “Yes” option. 7. Alternative Path: The cancels registration by selecting “Cancel”

option. 8. Alternative Path: If the selects the 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 gets ed in the database. 11.The system assigns a unique ID to the ed . 12.This use case ends. Exceptions: 1. s cannot get ed in COMSATS blood donor management system without submitting online registration form. 2. Blood donors and blood receivers cannot get ed 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 ed as a blood donor in COMSATS blood donor management system. 4. The cannot get ed in the database twice. Post-condition(s): The (blood donor, blood receiver, guest ) has been ed 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. Pre1. During online registration form submission the must condition(s): select the TYPE as a blood donor or blood receiver in order to submit blood type details. 2. The s 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 ed 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 , “Are you sure you want to get ed 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 ed in the database. 11.The system assigns a unique Blood Type ID to the ed 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 ed as a blood donor in COMSATS blood donor management system. 3. s cannot submit blood type details if they have not selected 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

Priority: High Actor(s): , Blood Donor, Blood Receiver, Guest

Brief Description:

The purpose of this use case is to give access to the (, blood donor, blood receiver, guest ) by checking if he/she is a valid ed in COMSATS blood donor management system. Pre1. The must be ed in COMSATS blood donor condition(s): management system in order to the system. Normal Flow of Events: Alternative Flows: 1. This use case starts when a 1. If each text field is not correctly ed (, and completely filled than the blood donor, blood receiver, guest system reloads the system ) wants to access the page. database. 2. If the is not already 2. The opens the system ed in the system, he/she page. can select “CREATE NEW 3. The fills correctly and ” option. completely the text fields, Email 3. In case the has forgotten Address and . his/her then the 4. The clicks on the SIGN IN system sends his/her 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 page. 6. Alternative Path: If the is not already ed in the system, he/she can select “CREATE NEW ” option. 7. Alternative Path: In case the has forgotten his/her then the system sends his/her information at his/her Email address. 8. The gains access to the system. 9. This use case ends. Exceptions: 1. If the does not enter his/her correct Email and than he/she will not be given any access to the system. Post-condition(s): The 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, Brief The purpose of this use case is to let the blood donor to send a Description: blood donation request to the of the system and allow the to accept or reject this request. Pre1. The must be ed in the system as a blood donor condition(s): to make a blood donation request. 2. The blood donor must 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 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 who can accept or reject the request. 8. If the accepts this request then the system sends a “Blood Donation Request Accepted” message with blood donation place and time information and number of the organization on the blood donor’s screen. 9. Alternative Path: If the

rejects this request then the system sends a “Blood Donation Request Not Accepted” message on the blood donor’s 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 . Use Case Cross References Extends: None Includes: None

Use Case ID: UC05

Use Case Name: Blood Transfusion Request

Priority: High Actor(s): Blood Receiver, Brief The purpose of this use case is to let the blood receiver to send a Description: blood transfusion request to the of the system and allow the to accept or reject this request. Pre1. The must be ed in the system as a blood condition(s): receiver to make a blood transfusion request. 2. The blood receiver must 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 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 who can accept or reject the request. 8. If the accepts this request then the system sends a “Blood Transfusion Request Accepted” message with blood transfusion place and time information and number of the organization on the blood receiver’s screen. 9. Alternative Path: If the rejects this request then the system sends a “Blood Transfusion Request Not Accepted” message on the blood receiver’s 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 . Use Case Cross References Extends: None Includes: None

Use Case ID: UC06

Use Case Name: Modify Records

Priority: High Actor(s): , Blood Donor, Blood Receiver, Guest , Database Manager Brief System should enable the to modify records of the Description: database and provide the facility to rest of the s (blood donor, blood receiver, guest ) to modify their personal contents only in their profiles. Pre1. The must be ed in the system as an condition(s): , blood donor, blood receiver or guest .

2. The must the database to gain access and modify records. 3. The can only modify records by first informing the (blood donor, blood receiver, guest ). Normal Flow of Events: Alternative Flows: 1. If the modification request is 1. This use case starts when the made by an invalid , system needs to modify the will not allow the to records in the database according do any modification and delete to the ’s requirements. the requests. 2. The will access the database. the validation of s. 3. After verification, will access the records of the valid s that need to be modified. 4. After doing changes, 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 cannot modify information if he/she is not ed in the database. Post-condition(s): 1. Modifications in the 's records will be done according to the 's requirements. 2. will be displayed a message on the screen "Records modified, changes are saved". 3. s 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): , Database Manager Brief This use case enables the to add new records of the Description: valid s in the database. Pre1. the system.

condition(s):

2. Access the s' database. 3. if the records to be entered are of valid s or not. Normal Flow of Events: Alternative Flows: 1. If the request is made by an invalid 1. This use case starts when the , will not enter the needs to add new fields containing data of invalid . records in the database according to the ’s requirements. 2. The will access the database. the validation of s. 3. After verification, will access the databases of the particular s to add new records. 4. After adding new records, 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 cannot add records if he/she is not ed in the database. Post-condition(s): 1. Records of valid s will be entered by the in the s' database. 2. 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): , Database Manager Brief This use case enables the to delete records of the Description: invalid s in the database. Pre1. the system. 2. Access the s' database. condition(s): 3. if the records to be deleted are of valid s or not.

Normal Flow of Events: 1. This use case starts when the needs to delete records in the database according to the ’s requirements. 2. The will access the database. the validation of s. 3. After verification, will access the databases of the particular s to add new records. 4. After adding new records, 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.

Alternative Flows: 1. If the request is made by an invalid , will not enter the fields containing data of invalid .

Exceptions: The cannot delete information if he/she is not ed in the database. Post-condition(s): 1. Records of valid s will be entered by the in the s' database. 2. 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: ’s Request(s)

Priority: High Actor(s): Brief This use case enables the to send Update Description: Database, Add New Fields or Reset Request to the

Database Manager. Precondition(s):

1. to access the database. 2. Send request to database manager to update database, add new fields in the system's database or reset s.

Normal Flow of Events: 1. This use case starts when the needs to update

database, add new fields in the system's database and reset s according to his/her 2. 3.

4.

5. 6.

requirements. The will the system. will jump to the request page displayed in the 's profile menu. Request Page will be displayed. will send the particular request(s) to the Database Manager by selecting the particular options displayed on the page. After clicking on the "Send" button, request(s) will be sent. The system will transfer the request to the Database Manager, he/she fullfil the request and update the system's database.

Alternative Flows: 1. If the response is not being received by the from the database manager system should display a dialog box on 's screen "In case of no response, to the manager here: (link to the developer will be displayed here)." 2. If the can't send request due to any errors, system should display a dialog box on 's screen " the developer of the product here: (link to the developer will be displayed here)."

Exceptions: The cannot send request if he/she is not ed in the database. Post-condition(s): 1. will be displayed a message on ’s 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 ’s request. PreThe Database Manager can update contents of database if condition(s): 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 wants to update the the that the desired contents of database. changes are impossible to make 2. The sends a update then contents of database and database request to the database system will not be updated. manager; it is displayed in database manager’s notifications. 3. The database manager updates the contents of database as desired by (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 to notify him/her that desired changes in system have been completed; it is displayed in ’s notifications. 6. This use case ends. Exceptions: 1. The database manager cannot update database and system if has not made any request. 2. If the database manager notifies the 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: ’s Request

UC10: Manage Database Use Case ID: UC10-02 Priority: Low

Use Case Name: Reset

Actor(s): Database Manager Brief This use case will allow the database manager to reset the Description: of the system profile of a (, blood donor, blood receiver, guest ) on ’s request. Pre1. The Database Manager can reset the of the condition(s): system profile of a (, blood donor, blood receiver, guest ) if has sent a request to reset . Normal Flow of Events: Alternative Flows: 1. This use case starts when the 1. If the database manager notifies wants to reset the the that the desired of the system profile of changes are impossible to make a (, blood then cannot be reset in donor, blood receiver, guest ) the database. or another has indirectly requested the to reset . 2. The sends a reset request to the database manager; it is displayed in database manager’s notifications. 3. The database manager resets the of system profile in the database. 4. The database manager saves the changes in the database. 5. The database manager sends a message to the to notify him/her that desired changes in system have been completed; it is displayed in ’s notifications. 6. This use case ends. Exceptions: 1. The database manager cannot reset the if has not made any request. 2. If the database manager notifies the that the desired changes are impossible to make then cannot be reset in the database. Post-condition(s): The of the system profile of (, blood donor, blood receiver, guest ) has been reset. Use Case Cross References Extends: None Includes: ’s Request