BLOOD DONATION MANAGEMENT SYSTEM
SOFTWARE REQUIREMENTS SPECIFICATION
BY P.LAVANYA (10BCE0366)
E1 SLOT
1
Contents
1.
Introduction………………………………………………………………………………………………
…………………………………….4
2.
Purpose……………………………………………………………………………………………………
………………………………………4
3.
Scope………………………………………………………………………………………………………
……………………………………….4
4.
References………………………………………………………………………………………………
……………………………………….5
5.
Overall
Description………………………………………………………………………………………………
………………………….6
6.
External interface
requirements……………………………………………………………………………………………
…………8
7.
Functional Requirements...................................................................................... 9
2
8.
Non Functional Requirements............................................................................. 17
8.1
Usability…………………………………………………………………………………………………
………………………………17
8.2 Inactivity
timeouts…………………………………………………………………………………………………
………………17
8.3
Performance……………………………………………………………………………………………
…………………………….17
8.4
Capacity…………………………………………………………………………………………………
………………………………18
8.5
Recovery………………………………………………………………………………………………
………………………………..18
8.6
Availability………………………………………………………………………………………………
……………………………..18
8.7
Reliability………………………………………………………………………………………………
……………………………….18
8.8
Maintainability…………………………………………………………………………………………
……………………………18
8.9
Portability………………………………………………………………………………………………
………………………………18
3
Revision History
Name
Date
Reason For Changes
Version
P LAVANYA
29/1/13
Context Diagram, Non Functional
Requirements Change
1.0
P LAVANYA
04/2/13
Functional requirements Changes, Use
case diagrams
2.0
4
1. Introduction
Blood donations are an integral and essential part of our health care system.
Without blood donations, many of the medical procedures that we take for granted
could not take place. Doctors and surgeons rely on blood donations to carry out a
wide variety of life saving and life-enhancing treatments on a daily basis.
2. Purpose
This document seeks to provide software requirement specifications for Blood
Donation Registering System. Software requirement Specification will provide a
broader understanding of the requirement specification of this system and the
features of this system along with the requirements. This document will guide the
developers in the development process and it will help to reduce the ambiguity of
requirements provided by the end user. This document will help to narrow the gap
between the requirements of the user and the perspective of the developer. Finally
it will lead assists as criteria for a quality final product.
3. Scope
Blood donation managements system supposed to have following features

Register the donors with the system giving their personal details,
contact details, blood group details, and with a certificate from a

certified doctor about their good healthy condition.
The ability to change information about the donors and also the ability

to withdraw from the registered list of donors.
Notifying the donors when there is a patient who needs blood via e-


mail and SMS.
Ability to indicate if a donor is willing to donate blood.
Maintain a data base of all registered blood donors, blood donations




and patients.
Issuing a monthly report on blood donors and donations.
Giving priority when a donor needs blood.
Issuing a certificate.
Ability to access different data-bases and retrieve data.
5
4. References
Appendix A: User Interfaces.
Access a copy of each reference, including title, author, version number, date, and
source or location.
1.
AABB Uniform Donor History Questionnaire
http://www.aabb.org/resources/donation/questionnaires/Documents/dhq/v13/Full-LengthDonorHistoryQuestionnairev1.3.pdf (Accessed on September 28,
2011).
2.
Dodd RY, Notari EP 4th, Stramer SL. Current prevalence and incidence of
infectious disease markers and estimated window-period risk in the American
Red Cross blood donor population. Transfusion 2002; 42:975.
3.
Whittaker S, Carter N, Arnold E, et al. Understanding the meaning of
permanent deferral for blood donors. Transfusion 2008; 48:64.
4.
Orton SL, Virvos VJ, Williams AE. Validation of selected donor-screening
questions: structure, content, and comprehension. Transfusion 2000; 40:1407.
5. Overall Description
5.1
Product Perspective
Blood Donation is considered as one of the most valuable contribution for
medical industry, when a patient loses blood a blood transfusion must be done inorder to save the life of the patient. But in the present though there are so many
donors who are willing to donate blood there is no such mechanism to keep touch
with the donors and to inform them when there is a need. This system allows
solving this problem and it will create a practical and efficient way of
communicating with Donors, Patients and Hospitals
6
Blood Donor registering system is created to facilitate the donors who are willing to
donate blood. This system is intended to function with the help of World Wide Web
(www) and the system will register blood donors and it will maintain a data base
with donor information and donation history, and it will inform the donors via e-mail
and SMS when there is patient who needs blood. All the data of donors will be
stored in a data base, and the system will be able to directly to the blood bank data
base and to other selected data bases of selected hospitals.
5.2
Product functions
The following are the user requirements of the system
5.2.1 The registrar can register the following details of a new patient in the system
5.2.1.1
5.2.1.2
5.2.1.3
5.2.1.4
5.2.1.5
5.2.1.6
5.2.1.7
5.2.1.8
5.2.1.9
Name
Address
Phone
DOB
Gender
Height
Weight
Identification marks
Blood Group
7
5.2.2 The existing users will check for the hospitals and patients who are in need of
blood and once the search is done the result set is return to application.
5.2.3 The admin maintain a record of collected blood and the report contains the
following details of donor.
5.2.3.1
5.2.3.2
5.2.3.3
5.2.3.4
5.2.3.5
5.2.3.6
5.2.3.7
Personal details of reporter
Product name
Blood group
Primary donation
Secondary identifier number
Donation type
Expiry date
5.2.4 The following details are required to search the donors in a particular city for
the emergency of blood and communication takes place through
media/advertisements.
5.2.4.1
5.2.4.2
5.2.4.3
5.2.4.4
5.2.4.5
5.2.4.6
5.2.4.7
5.2.4.8
Blood type
Reason blood required
Time required for blood
Number of units required
Authorizing doctor’s name
Patient id (Full name, UR no, DOB)
Destination and direct contact number
Staff member to collect blood
5.2.5 The end users who are doctors or patients requests for blood by mentioning
the following details.
5.2.5.1
5.2.5.2
5.2.5.3
5.2.5.4
5.2.5.5
5.2.5.6
5.2.5.7
5.2.5.8
5.2.5.9
5.3
Name of the doctor
Name of the patient
Name of the hospital
Address
Contact number
Number of units (amount of blood patient needs)
Blood type
Blood group
Date and time when the blood is needed
User characteristics
When a user is visiting the web site the basic information about the
organization and the information about the system and its components are given. If
8
the user needs further help the user can send a message to the administrator. So
any naive user can interact with the system very easily.
5.4
Constraints
5.4.1 The limited access to the databases of the government hospitals may limit
the scope of the system. The system will only deal with few selected data bases.
5.4.2 The system is not available in Sinhala or Tamil; it is only developed in English
language.
5.4.3 Due to user specified theme the same theme was used throughout the
software.
5.4.4 The user names and passwords cannot be changed due to security
algorithms used in the software development. (E.g.: Advanced Encryption Standard
(AES / Rijndael), Two fish)
6.
External Interface Requirements
6.1 User Interfaces
6.1.1 The system will provide GUI for the users.
6.1.2 The users will be able to access the system using their web browsers
6.2 Software Interfaces
6.3.1 Web based DBMS and the end note software tool database system
aroused as an interfaces in order to capture basic donor information.
6.3 Communications Interfaces
6.4.1The system will use HTTPS protocol for secure transfer of information
between the client and the web server
7. Functional requirements
9
7.1
Use Case Diagram
New User registration
Existing User registration
Blood Collection and details
Admin
End User
Search donor
Request blood
7.2
Use Case Scenario Description
Use Case
New User registration
10
Summary
The System will update the database to hold the following
details for a Patient
Success End

Name

Address

Phone

DOB

Gender

Height

Weight

Identification marks

Blood Group
Registration Successful Confirmation Message is displayed to
Condition
the user
Failed End
Please fill in the required fields Message to the User when any of
Condition
the given fields is blanks or all zeroes
Trigger
This use case is initiated based on the request from the User
DESCRIPTION
Ste
Action
p
1
The End users will register his database under registration
link
2
The User id is auto generated by the system
3
The end user enters the name, address, phone number,
blood group in the text boxes
11
4
The End user selects DOB from a calendar display
5
The height, weight and gender of the User is selected
from a list of values in a drop down combo box
EXTENSIONS
6
The End User Clicks on the Submit Button
Ste
Branching Action
p
1a
The system updates the data into the database.
The system retrieves the User login id and updates it with
the other User details into the database
Use Case
Existing User registration
Summary
Existing User orders blood for their requirements.
Success End
The details of the User will be displayed to the user along with
Condition
requirements.
Failed End
Invalid Id message is displayed to the user
Condition
Trigger
This use case is initiated based on the request from the User
DESCRIPTION
Ste
Action
p
1
The End user will check for the hospital and patients who
are in need of blood
12
2
The End user selects the type of id from the drop down
box
EXTENSIONS
3
The end user enters the id in the text box
4
The End User Clicks on the Submit Button
Ste
Branching Action
p
1a
Database search is done and the result set is returned to
the application
Use Case ID
3
Use Case
Blood Collection and details
name
Summary
The admin maintain a record of collected blood and indicate the
date of expiry.
Success End
The details of the blood available will be displayed to the user
Condition
along with details
Failed End
Causes malfunction in blood transfusion.
Condition
Trigger
This use case is initiated based on the details gathered from the
user.
DESCRIPTION
Ste
Action
p
1
The End user who are doctors or patients Order blood.
13
2
The End user selects the type of id from the drop down
box
3
The end user could see the date of expiry
4
The End User Could see the age of the person who
donated
EXTENSIONS
Ste
Branching Action
p
1a
Database search is done and the result shows whether the
blood is free from HIV positive, etc.
Use Case ID
4
Use Case
Search Donors
name
Summary
To search the donors in particular city in particular area when
there is an emergency for blood.
Success End
The seeker could get the required blood within 30 minutes
Condition
Failed
Could not get the required blood at right time.
Condition
14
Trigger
This use case is initiated based on request made by the end
user.
DESCRIPTION
Ste
Action
p
1
The End user will communicate through media or
advertisement to search donors for urgency purpose
2
The End user selects the particular area and city where
they need the requirements.
EXTENSIONS
3
The end user could search list of donors
4
The End User Could select a particular donor.
Ste
Branching Action
p
1
Database search is done and the result shows whether the
blood donor is available at particular area.
Use Case ID
5
Use Case
Request Blood
name
Summary
The admin maintain a record of collected blood and gives the
availability status for the end user.
Success End
The Blood will be donated to the particular hospital when it is
Condition
needed.
15
Failed End
Could not donate blood units at right time to the hospitals
Condition
Trigger
This use case is initiated based on the request got from a end
user
DESCRIPTION
Ste
Action
p
1
The End user who are doctors or patients requests for
blood and he will register the basic requirements details
such as blood group and the amount he needs
2
The End user selects the date and time when the blood is
needed
3
The end user specify the name of hospital and doctor who
needs
4
The End User Could send the report on requirements of
blood group needed
EXTENSIONS
Ste
Branching Action
p
1a
Database saves the requirements for donating the blood
to the right hospital at right time.
8. Non functional requirements
This system describes in detail of all the non-functional requirements.
8.1
USABILITY
16
8.1.1 The system shall allow the users to access the system from
the Internet using HTML or it’s derivative technologies like XML/CSS.
The system uses a web browser as an interface.
8.1.2 Online help will be available for the system
8.1.3 The end users will be able to able to adapt to the system with a
minimum training of 40 hours
8.1.4 Key board short cuts will be available for all functions of the
system
8.1.5 The users can configure the system to view the pages in the
following regional languages: Hindi, Tamil, Kannada, Telugu, and
English.
8.2
LOGIN REQUIREMENTS
The user can simply login and start providing details.
8.2.1 PASSWORD REQUIREMENTS
8.2.1.1 Passwords must have a minimum length of 8 characters
8.2.1.2 Passwords must meet at least 3 out of the 4 requirements for
quality
8.2.1.3 At least 1 lower case letter
8.2.1.4 At least 1 upper case letter
8.2.1.5 At least 1 number
8.2.1.6 At least 1 special character (? ,*, %)
8.2.1.7 Password should not contain the user’s first name, middle
name, last name, or username.
8.2.1.8 Passwords on sensitive IT systems must be changed, at a
minimum, every 90 days.
8.3
INACTIVITY TIMEOUTS
System should timeout when there is no activity for five minutes.
17
8.4
PEERFORMANCE
8.4.1 RESPONSE TIME
8.4.1.1 The response time will be less than 8 seconds for 95% requests
made
to
the
system
8.5. CAPACITY
8.5.1 THROUGHPUT
The application shall be able to successfully handle 500 requests per
hour
8.5.2 STORAGE
Hard disk space
450 GB – Content
50 B – Transaction Logs
8.6
RECOVERY
8.6.1 RECOVERY TIME SCALES
The response time will be less than 8 seconds for 95% requests made
to the system
8.6.2 BACKUP FREQUENCIES
9.1.4.1A full back up of Blood management system data will be done
on tapes every day
9.1.4.2 The backup is scheduled to run automatically at 10 pm daily.
18
8.7
AVAILABILITY
8.7.1 Hours of operation
The system will be available on all days 24*7
8.8
RELIABILITY
[
8.8.1 Mean Time between Failures
The mean time between failures for the system will be 1000 hours
8.9
MEAN TIME RECOVERY
The Mean Time to Recovery (MTTR) shall not exceed one person day.
8.10 PORTABILITY
The system will run on windows 95/98/2000/NT/XP/Vista/Windows7
19