BLOOD DONATION MANAGEMENT SYSTEM

SOFTWARE REQUIREMENTS SPECIFICATION

BY P.LAVANYA (10BCE0366)

E1 SLOT

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

RevisionHistory
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

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.

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

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

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 doctors 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

The User id is auto generated by the system

The end user enters the name, address, phone number,

blood group in the text boxes

11

The End user selects DOB from a calendar display

The height, weight and gender of the User is selected

from a list of values in a drop down combo box

EXTENSIONS

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

The End user selects the type of id from the drop down
box

EXTENSIONS

The end user enters the id in the text box

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

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

The End user selects the type of id from the drop down
box

The end user could see the date of expiry

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

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

The End user selects the particular area and city where
they need the requirements.

EXTENSIONS

The end user could search list of donors

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

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

The End user selects the date and time when the blood is
needed

The end user specify the name of hospital and doctor who
needs

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 its 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 users 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