Software Requirement Specification Document
2010cs048 Page 1
Software Requirement Specification Document
UPAKARA –WEB BASED BLOOD DONATION SYSTEM
N.P.Sameera Sandaruwan Manorathna
SCS 1007 - Software Engineering Index Number - 10000488
2010/cs/048
1st year – Assignment 1
Software Requirement Specification Document
2010cs048 Page 2
Table of contents
Table of Contents 7
1. Introduction 8
1.1 Purpose 8
1.2 Scoop 8
1.3 Definitions, acronyms & Abbreviations 8
1.4 References 9
1.5 Document Overview 9
2. General characteristics 10
2.1 Introduction 10
2.2 Product perspective 10
2.3 Product functions 10
2.4 User characteristics 12
2.5 General constraints 12
2.6 Assumptions & dependencies
3. Specific requirements 13
3.1 Functional requirements 13
3.2 External interface requirements 24
3.3 Performance requirements 24
3.4 Design constraints 25
3.5 Attributes 25
3.6 Other Requirements 26
Appendix a: Use case diagram 27
Appendix b: Class diagrams 28
Appendix c: User interface diagrams 29
13
Software Requirement Specification Document
2010cs048 Page 3
1. Introduction
1.1 Purpose
Upakara – the web based blood donation system is mainly uses for helping the patient
who need blood. So this SRS document consists of a simple explanation about the system and its
features. The document mainly focuses on providing sufficient design information to the blood
bank authorities. And also it will satisfy the functional, design, performance requirements of the
system in briefly.
1.2 Scope
The main intend of this SRS is to provide a simple description to the blood bank
authorities & system users, about the behavior of the system. And the entire package is
consisting of below parts.
System software – The system will contains a database in order to store all details about
the donors as well as doctors.
Software documentation – A complete document about the software will be given to the
blood bank administration in order to future maintenance of the system.
Operation Manual – A user manual is provided to the system administrator with some
simple explanations about the system and its features.
User Manual – When the donor submits his/her details through internet a simple guidance
is also given to the donor.
1.3 Definitions, Acronyms & Abbreviations
Upakara - The name of the web based blood donation system
WBBDS - Web based blood donation system
Database - Consist of all information related to donors & doctors
HC Certificate – Health Condition Certificate
Login – The process which is related to logging into the system
Password – A set of characters which can be used to correctly identify the exact person
who is log into the system
Software Requirement Specification Document
2010cs048 Page 4
Id number – Identity card number
Replied donor – The donor who will reply to the system to indicate that he/she will attend
to the donation.
MB – Mega byte (Unit of memory storage in computer)
SRD – System requirement definition
SRS – System requirement specification
www.slbloodbank.com – the official website of Sri Lankan blood bank
1.4 References
Appendix A: Use case diagram
Appendix B: Class diagrams
Appendix C: User Interface Diagrams
1.5 Document Overview
The document has 3 major sections.
1. Introduction – Overview of the whole SRS document
2. General characteristics – A description about the features of the system.
Introduction
Product perspective
Product functions
User characteristics
General constraints
Assumptions & dependencies
3. Specific requirements – A description of specific requirements of the system.
Functional requirements
External interface requirements
Performance requirements
Design constraints
Non-functional requirements
Attributes
Software Requirement Specification Document
2010cs048 Page 5
2. General characteristics
2.1 introduction
Through this section a description is given about the characteristics about the
entire system.
2.2 Product perspective
WBBDS is mainly towards persons who are willing to donate blood to the
patients. Through this system it will be easier to find a donor for exact blood type and easy to
build the connection between donor & the blood bank authorities. The main intend of building
this software is to formal the procedure of blood donation & motivate donors in order to donation
blood.
The system also consists of some local system hardware devices as well. A printer & SMS
indicator are the main devices among the other devices.
The entire software product includes the all relevant features to create a better connection
between the blood donor & blood bank authorities.
2.3 Product functions
Class of use cases Use cases Description
Use cases related to system
authorization of system
administrator
Login of admin
Change password of
the admin
Log admin into the system
Change login password of the admin of
the system
Use cases related to
registration of a donor
Register the donor by
himself
Register the donor by
system admin
Store personal, contact, medical details of
donors
Store personal, contact, medical details of
donors
Use cases related to system
authorization of the donor
Login of donor
Change password of
the donor
Log donor into the system
Change login password of the donor of the
system
Software Requirement Specification Document
2010cs048 Page 6
Use cases related to change
the registration details of
donors
change personal,
contact details by the
donor himself
change personal,
contact details by
system admin
Change personal & contact details of
donors
Change personal & contact details of
donors
Use cases related to
withdraw names from the
donor list
Withdraw reg. details
by the donor
Withdraw reg. details
by the admin
Delete all details of a exact donors by
themselves
Delete all details of a exact donors by the
system admin
Use cases related to inform
blood donation details
Send blood donation
details to the relevant
donors
Inform the requirement of the blood group
to donors who has same blood group
Use cases related to replace
the older HC certificates
Replace donors’ HC
certificates
Override the health condition report
details
Use cases related to inform
blood testing to the donor
Send blood testing
details
Inform disease details to relevant donors
Inform donor details who has diseases, to
relevant doctors
Use case related to access
the database
Search relevant
details from the
database
Search & display relevant details from the
database
Use cases related to print
statements
Print the list of newly
registered donors,
donation details &
list of removed
names as statements
Print the list of newly registered donors,
donation details, list of removed names of
--Table -1--
Software Requirement Specification Document
2010cs048 Page 7
2.4 User characteristics
In here the system admin & the donor are the system users. According to my
assumptions the donor who will register to the system from the website can
understand easy questions which are in English language & he/she has the ability
to realize small instructions & fill the application without any errors & a small
knowledge of computers to upload the health condition certificate to the system.
User is very generous to attend to the donation with such a small announcement.
(e-mails & SMS messages)
2.5 General constraints
The program will be written in PHP language.
The system will mainly running on the official website of the blood bank
(www.slbloodbank.com).
The both kind of donors who has the internet connection & who hasn’t the
internet connection can contribute to the donation through the WBBD system.
The donor who uses internet connection will be guided through small & clear
descriptions.
Every donor may get a user name & a password in order to log into the system.
After the registration of a donor the program will authenticate the accuracy of the
donor’s mobile number through counting the number of characters in the entered
mobile number
System uses the donor registration number & the identity card number to identify
each donor separately.
Inside the system the administrator has more advance functions than the donor.
The hospital doctor is not a user of the system. But the doctor connects to the
system in a different manner. The doctor mainly has the connection with the
system admin. In donor registration, submission of HC certificates & providing
donation details to the system the doctor will connect directly with the system
administrator.
Software Requirement Specification Document
2010cs048 Page 8
2.6 Assumptions & dependencies
Every donor has a mobile phone.
The system doesn’t keep the details of the gathering stock of blood.
The system database will be accessible in real time.
The donor doesn’t submit any fake reports to the system.
Donors who want to contribute to a donation will definitely reply to the request of
system.
The installation of the system to the website server hasn’t considered as a process
inside the system. That process will do by the authorities who are controlling the
website. Therefore in here the installation process is considered as a process
which is in outside of the scope.
A doctor or a patient can request for a exact blood group. But the request comes
through blood bank authorities to the system admin. Therefore doctor, patient are
not direct users of the system.
3. Specific requirements
3.1 functional requirements
Use case diagrams are used to describe functional requirements of the system. The
diagrams are drawn below.
If there is a network failure while a user is working in the system, all login details
regarding on user name & password of the user will be removed from the system.
User case related to system authorization
Use case 1: Login of admin.
Primary actor: System administrator.
Pre Condition: Internet connection should be available.
Main scenario:
Software Requirement Specification Document
2010cs048 Page 9
1. Log into the official blood bank website.
2. Admin initiates the command to starts the application “Upakara - WBBDS”
3. System is shown the all features of the system.
4. Click the “Login of administrator” command button.
5. The system asking for the user name & the password.
6. Admin provides the username & the password.
7. System does authentication.
8. Main application relevant to admin is displayed.
Alternative scenario:
7(a). Authorization fails.
7(a) 1. A message is given to the admin that the provided password is wrong.
7(a) 2. Allow the admin to re-enter the password. 3 chances will be given.
Use case 2: Change the login password of admin.
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Admin logged in.
Main scenario:
1. Admin selects the command to change the password.
2. The system is asked to type the current password, new password & again the new
password to confirm it.
3. Admin provides the current password, new password & confirm new password.
4. System does authentication.
5. New password is stored in the system.
Alternative scenario:
4(a). Authorization fails.
4(a) 1. A message is shown to the admin that the provided current password is wrong.
4(a) 2. Allow the admin to re-enter the current password. 3 chances will be given.
4(b). New password doesn’t match with the confirm new password.
4(b) 1. A message is shown to the admin that the provided new password doesn’t match
with the current new password.
Software Requirement Specification Document
2010cs048 Page 10
4(b) 2. Allow the admin to re-enter the new password & confirm new password.
User case related to registration of a donor
Use case 3: Register the donor by himself.
Primary actor: Donor.
Pre Condition: Internet connection should be available.
Main scenario:
1. Log into the official blood bank website.
2. Admin initiates the command to starts the application “Upakara - WBBDS”
3. System is shown the all features of the system.
4. Donor initiates the register of a donor command.
5. A small questionnaire is given to the donor, which is related to personal & contact
details.
6. The donor answers the questionnaire & goes to the next page.
7. The system does authentication.
8. The system asks the donor to submit the health condition report & the evidence report of
blood group.
9. The donor submits those reports to the system & finishes the registration.
10. The system does authentication.
11. The registration details are sending to blood bank authorities through an e-mail.
12. Authorities approve details & reports. Send the approval to the system admin.
13. Store registration details in the system database. Alert the donor by sending e-mails &
SMS messages to the donor about the registration. Send the user name & the password to
the donor in order to log into the system.
Alternative scenario:
7(a). Donor doesn’t provide the answers to some main questions completely.
7(a) 1. A message is shown to the donor that he/she hasn’t answered properly.
7(a) 2. Highlight those questions. Allow 3 chances the donor to re-answer those
remaining questions.
7(b). Donor has entered an invalid mobile phone number.
7(b) 1. An error message is shown to the donor that the mobile number contains invalid
number of characters.
Software Requirement Specification Document
2010cs048 Page 11
10(a). Donor doesn’t submit the required reports.
10(a) 1. A message is shown to the donor that he/she hasn’t submitted the required
reports.
10(a) 2. Allow 3 chances to the donor to submit the required reports again.
12(a). Authorities don’t approve the registration details of the donor.
12(a) 1. Details will not store in the database.
12(a) 2. Send a message to that person about the rejection of the application. Ask him to
register again.
Use case 4: Register the donor by system admin.
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Administrator logged in.
Main scenario:
1. Admin select the donor registration command.
2. A small questionnaire is given to the admin which is related to personal & contact details
of the donor.
3. Type all details of a donor which is approved by the hospital authorities & goes to next
page.
4. System does authentication.
5. The system asks the admin to submit the health condition report & the evidence report of
blood group.
6. Admin submits the relevant reports which are approved by the hospital authorities &
finishes the registration.
7. System does authentication.
8. Store registration details in the system database. Alert the donor by sending e-mails &
SMS messages to the donor about the registration. Send the user name & the password to
the donor in order to log into the system.
Alternative scenario:
4(a). Admin doesn’t provide the answers to some main questions completely.
4(a) 1. A message is shown to the admin that he hasn’t answered properly to questions.
Software Requirement Specification Document
2010cs048 Page 12
4(a) 2. Highlight those questions. Allow admin to re-answer those questions.
4(b). Admin has entered an invalid mobile phone number.
4(b) 1. An error message is shown to the admin that the mobile number contains invalid
number of characters.
7(a). Admin doesn’t submit the required reports.
7(a) 1. A message is shown to the admin that he hasn’t submitted the required reports.
7(a) 2. Allow admin to submit the required reports again.
Use case 5: Login of the donor.
Primary actor: Donor.
Pre Condition: Internet connection should be available.
Main scenario:
1. Log into the official blood bank website.
2. Admin initiates the command to starts the application “Upakara - WBBDS”
3. System is shown the all features of the system.
4. Selects the “Login of a donor” command.
5. The system asking for the user name & the password.
6. Donor provides the username & the password.
7. System does authentication.
8. Relevant application relevant to a donor is displayed.
Alternative scenario:
7(a). Authorization fails.
7(a) 1. A message is given to the user that the provided password is wrong.
7(a) 2. Allow the admin to re-enter the password. 3 chances will be given.
Use case 6: Change the login password of the donor.
Primary actor: Donor.
Pre Condition: Internet connection should be available. Donor logged in.
Main scenario:
Software Requirement Specification Document
2010cs048 Page 13
1. Donor selects the command to change the password.
2. The system is asked to type the current password, new password & again the new
password to confirm it.
3. Donor provides the current password, new password & confirm new password.
4. System does authentication.
5. New password is stored in the system.
Alternative scenario:
4(a). Authorization fails.
4(a) 1. A message is given to the donor that the provided current password is wrong.
4(a) 2. Allow the donor to re-enter the current password. 5 chances will be given.
4(b). New password doesn’t match with the confirm new password.
4(b) 1. Allow the donor to re-enter the new password & confirm new password.
Use cases related to change the registration details of donors.
Use case 7: Change personal, contact details by the donor himself.
Primary actor: Donor.
Pre Condition: Internet connection should be available. Donor logged in.
Main scenario:
1. Donor initiates the command to edit profile details.
2. The system provides the filled application of the exact donor.
3. Donor changes personal & contact details & finishes.
4. System does authentication.
5. New details will replace the past details & store in the system.
Alternative scenario:
4(a). Donor doesn’t provide the answers to some main questions completely.
4(a) 1. A message is shown to the donor that he hasn’t answered properly to questions.
4(a) 2. Highlight those questions. Allow the donor to re-answer those questions.
4(b). Donor has entered an invalid mobile phone number.
4(b) 1. An error message is shown to the donor that the mobile number contains invalid
number of characters.
Software Requirement Specification Document
2010cs048 Page 14
Use case 8: Change personal, contact details by system admin.
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Admin logged in.
Main scenario:
1. System administrator initiates the command to edit profile details of donors.
2. System asks admin to enter the donor’s registration number & the identity card number.
3. Admin provides the registration number & the identity card number of the donor.
4. System does authentication.
5. The system provides the filled application of the exact donor.
6. Admin changes personal & contact details & finishes.
7. System does authentication.
8. New details will replace the past details & store in the system.
Alternative scenario:
4(a). Authorization fails.
4(a) 1. A message is given to the admin that the registration number doesn’t match with
the id number.
4(a) 2. Allow the admin to re-enter the registration number & the identity number. 3
chances will be given.
7(a). Admin doesn’t provide the answers to some main questions completely.
7(a) 1. A message is shown to the admin that he hasn’t answered properly to questions.
7(a) 2. Highlight those questions. Allow the admin to re-answer those questions.
7(b). Admin has entered an invalid mobile phone number.
7(b) 1. An error message is shown to the admin that the mobile number contains invalid
number of characters.
User case related to withdraw names from the donor list.
Use case 9: Withdraw reg. details by the donor.
Primary actor: Donor.
Software Requirement Specification Document
2010cs048 Page 15
Pre Condition: Internet connection should be available. Donor logged in.
Main scenario:
1. Donor selects the command to withdraw details from the system.
2. System is shown a message to the donor in order to confirm the decision.
3. Donor confirms the decision.
4. Donor will logged out from the system.
5. Donor will get a thank you note from the system to their mobile phones.
Use case 10: Withdraw reg. details by the admin.
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Admin logged in.
Main scenario:
1. Admin initiates the command to edit donor details.
2. System is shown the sub commands of the edit donor list command.
3. Admin selects the command to remove donor from the system.
4. System asks the registration number & the identity card number of the donor.
5. Admin submits the registration number & the identity card number of the donor.
6. System does authentication.
7. System is shown all details of the donor & system asks to confirm the decision.
8. Admin confirms the decision.
9. All details of that donor are removed from the database.
10. Donor will get a thank you note from the system to their mobile phones.
Alternative scenario:
6(a). Authorization fails.
6(a) 1. A message is given to the admin that the registration number doesn’t match with
the id number.
6(a) 2. Allow the admin to re-enter the registration number & the identity number. 3
chances will be given.
Software Requirement Specification Document
2010cs048 Page 16
User case related to inform blood donation details.
Use case 11: Send blood donation details to the relevant donors.
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Admin logged in.
Main scenario:
1. Blood bank authorities request for a blood group.
2. Admin selects the command to search donors for exact blood type.
3. System asks to insert the blood group.
4. Admin inserts the needed blood group details.
5. System searches the latest donation details of relevant blood donors. Select donors for the
donation.
6. System is shown the details of donors’ who can donate blood to that blood group.
7. System alerts all donors who can donate blood to that needed blood group, about the
requirement & a complete detail about the donation according to the blood bank
authorities.
8. Donors who are willing to attend to the donation will reply to the system.
Alternative scenario:
5(a). The donor has contributed to a donation within last 5 months.
5(a) 1. Ignore the names of that kind of donors from the chosen list.
5(b). There are no donors in the system who can donate blood to that blood group.
5(a) 1. System is shown a message that no matching donors for the donation.
Use cases related to replace the older HC certificates.
Use case 12: Replace donors HC certificates.
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Admin logged in.
Main scenario:
1. Consider the submission date of the health condition report of those replied donors.
2. The submission date of the HC certificate of those replies donors is older than 5 month.
3. System is shown the names of that kind of donors to the admin.
Software Requirement Specification Document
2010cs048 Page 17
4. The system admin send the donors’ names to the blood bank authorities.
5. Blood bank authorities will get new HC certificates from required donors at the donation
day & send those details to the system admin.
6. Admin initiates the command to edit donors’ profile details.
7. The system is shown the sub directories of that command.
8. Admin initiates the command to replace HC certificates of donors.
9. System is shown the list of relevant replied donors for that latest donation.
10. Admin submits the reports with respect to the each relevant donor’s registration number
& select finish command.
11. System is shown the names of donors with latest submissions of medical reports & asks
for the confirmation.
12. Admin confirms the report details.
13. New reports will replace the past reports & store in the database.
Use cases related to inform blood testing to the donor.
Use case 13: Send blood testing details.
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Admin logged in.
Main scenario:
1. Blood bank authorities send blood testing details of donors, to the system admin who is
found to be having diseases.
2. Admin store those details with respect to each donor.
3. The admin alerts the relevant donors about disease & sends them the blood testing details
through e-mails & SMS messages.
4. Relevant doctors’ details are also provided by the system administrator to the donor
through SMS messages.
5. The names of that kind of donors will remove from the donors list.
Use case related to search access the database.
Use case 14: Search relevant details from the database.
Software Requirement Specification Document
2010cs048 Page 18
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Admin logged in.
Main scenario:
1. Admin initiates the command to search details from the database.
2. System asks the admin to initiate the database id of relevant sections that he wants to
access.
3. Admin provides the relevant database ID for the section.
4. System displays the relevant details from the database.
Alternative scenario:
4(a). There are no details for the initialized section.
4(a) 1. System is shown a message indicating that there are no any details in that
section.
Use cases related to print statements.
Use case 15: Print the list of newly registered donors, donation details & list of removed names
as statements.
Primary actor: System administrator.
Pre Condition: Internet connection should be available. Admin logged in.
Main scenario:
1. Admin select the command to print statements.
2. The system is shown a window with relevant commands.
3. The admin selects the details that he wants to print.
List of newly registered donors
Blood donation details of donors
Removed names of donors
4. The system asks for the duration
5. The admin provides the duration & finishes.
6. The system prints relevant statements.
Alternative scenario:
5(a). There are no any statements for that exact duration.
Software Requirement Specification Document
2010cs048 Page 19
5(a) 1. System is shown a message indicating that there are no any statements for that
exact duration.
3.2 external interface requirements
The system is basically running on the official website of the govt. blood bank. Mainly
there are 2 actors in the system. The system provides some advance features to the system admin
than the donor. If the system admin logs in, the system interface provides some main command
buttons to the admin.
Change login password.
Edit donor profile details.
Search Donors for a exact blood group & send messages
Print statements.
Update the database
Send blood testing Details.
Search details from the database.
If the donor logs in, the system will provide another different interface with different
commands.
Change login password
Edit personal, contact details.
Details related to contributions to donation.
Future blood donation details.
Withdraw name from the system.
3.3 performance requirements
Should run on 500 GHz, 64MB machine.
Should have a proper internet connection.
The response time for occurs a change will be no more than 4 seconds.
The response time for access the database will be no more than 5 seconds.
Software Requirement Specification Document
2010cs048 Page 20
3.4 design constraints
Data should not become corrupted in case of network failure, system crash or
power failure.
Security – The system is consisting of the features to keep the privacy of every
donor. Any donor cannot see any detail of any other donor.
3.5 Attributes
The system will posses some quality attributes to the users.
Robustness
The entire system includes every function which is always help to the system to work
correctly & strongly in all conditions.
Reliability
The system has the ability to work all the time without failures apart from
network failure. The donor can have the faith on the system. The authorities will keep
the privacy of all donors in a proper manner.
When doctors found any disease in the testing stage after providing relevant
details to the donor the system keeps the secretively of the donor.
Portability
As mentioned earlier the system is working on the official website of the blood
bank. Therefore if a donor uses different operating system (Linux, Windows) or
different web browser, after logging into the system, the system will show the all
features in it.
Modularity
The system mainly consists of many parts. SMS indicating part is the largest part
of all. In that section the system interact with the indicating device. Ultimately however
the system manages to combine all parts of the system & work as a large system.
Interoperability
In here the system Upakara will run on the blood bank website. Therefore
the system includes the ability to work with the other applications which are
also run on the same website.
Software Requirement Specification Document
2010cs048 Page 21
3.6 OTHER requirements
Security – This system doesn’t have a tight security system. Because people
who log into the system are volunteers who like to donate blood for innocent
patients. But the system consists of some security features.
o Any donor cannot see any detail of any other donor.
o If a donor doesn’t manage to provide his user name & the password in 3
times the user automatically will log out from the website.
Software Requirement Specification Document
2010cs048 Page 22
Inform Blood
Testing Details
System Administrator
Withdraw Donors
from the List
Change Reg.
Details of Donors
Donor Registration
System
Authorization
Print Statements
Replace HC
Certificates
Inform Blood
Donation Details
Blood Donor
Acess the Database
Appendix a: Use case diagram
- Figure -1
Software Requirement Specification Document
2010cs048 Page 23
*
*
+Login()
+Change_Password()
+Donor_ Registration()
+Chage_Reg_Details()
+Withdraw_Donor()
-User_Name
-Password
-Database_ID
User
+Future_Donation_Details()
+Donation_Contribution_Details()
+Edit_Profile()
-Reg_Number
-Blood_Group
-ID_Number
-Mobile_Phone_Number
-E-mail_Address
-Database_ID
Donor
+Print_Reports()
+Search_Donors()
+Replace_HC_Certificates()
+Inform_Blood_Testing_Details()
+Search_Database_Details()
-Database_ID
System_Administrator
+Print_Report()
+Display_Report()
-Report_Name
-Report_Duration
Report
+Clarify_Alert()
+Display_Alert_Details()
-Alert_Type
Alert
*
*
+Send_SMS_&_Save()
+Read_SMS_&_Save()
-Mobile_Phone_Number
-Database_ID
SMS_Alert
+Acess_Database()
+Store_Details()
+Remove_Details()
-Database_ID
Database_Acess
*
*
*
*
+Future_Donation_Details()
+Search_Blood_Donors()
+Send_Donation_Request()
-Blood_Group
-Donation_Date
-Donation_Venue
-Donation_Starting_Time
-Database_ID
Donation
+Send_BloodTesting_Details()
-Donor_Reg_Number
-Donor_ID_Number
-Database_ID
Test_Detail
* *
*
*
*
*
+Send_Email_&_Save()
+Read_Email_&_Save()
-Email_Address
-Database_ID
Email_Alert
Appendix b: class diagram
- Figure -2
Software Requirement Specification Document
2010cs048 Page 24
Some major sections in the system interface is given below.
Upakara – The Web Based Blood Donation SystemUpakara – The Web Based Blood Donation System
File HelpToolsBookmarksHistoryViewEdit
Upakara
Sub Features
Register a new Donor
Remove a Donor
Edit Donor Details
Search Details of a Donor
Main Features
Search Donors & send messages
Edit Donor Profile Details
Change Password
Print Statements
Admin has Logged in
Update the Database
Send Blood Testing Setails
Edit Donor Profile Details
Replace HC Cretificates
Log Out
Search from the Database
Upakara – The Web Based Blood Donation SystemUpakara – The Web Based Blood Donation System
File HelpToolsBookmarksHistoryViewEdit
Upakara
Main Features
Change Password
Edit Personal, Contact Details
Donation Contribution Details
Future Blood Donation Details
A Donor has Logged in
N.P.S.S.Manorathna
Reg Date – 2011.05.29
T.P No – 071 2112684
User Name – 2010cs048Change Password
OK
Current Password
Confirm New Password
New Password
Appendix c: user interface diagrams
- Figure 3- The user interface for the administrator
of the system
- Figure 4- The user interface for a donor of the system
of the system
Software Requirement Specification Document
2010cs048 Page 25
Upakara – The Web Based Blood Donation SystemUpakara – The Web Based Blood Donation System
File HelpToolsBookmarksHistoryViewEdit
Upakara
Registration of a Donor
E-mail Address
Mobile Phone Number
Gender
AgeDate of Birth
National Identity Number
Blood Group
Province
Address
Name in full
V
O+
Male
Western
1990 23November 21
Registration of a Donor
Next Page
Upakara – The Web Based Blood Donation SystemUpakara – The Web Based Blood Donation System
Registration of a Donor
Brows..
Brows..
Submit the health condition cretificate
A acceptance of a authorized doctor is needed
Submit the evidence report of blood group
Finish Submission
File HelpToolsBookmarksHistoryViewEdit
Upakara
Registration of a Donor
- Figure 5 - User interface related to Registration of a new donor - page1
of the system
- Figure 6- The user interface related to Registration of a new donor – page 2
of the system