BLOOD DONATION

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

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

2

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

3

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

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/v1-3/FullLengthDonorHistoryQuestionnairev1.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 in-order 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

5

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 Name
5.2.1.2 Address
5.2.1.3 Phone
5.2.1.4 DOB
5.2.1.5 Gender
5.2.1.6 Height
5.2.1.7 Weight

6

5.2.1.8 Identification marks
5.2.1.9 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 Personal details of reporter
5.2.3.2 Product name
5.2.3.3 Blood group
5.2.3.4 Primary donation
5.2.3.5 Secondary identifier number
5.2.3.6 Donation type
5.2.3.7 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 Blood type
5.2.4.2 Reason blood required
5.2.4.3 Time required for blood
5.2.4.4 Number of units required
5.2.4.5 Authorizing doctor’s name
5.2.4.6 Patient id (Full name, UR no, DOB)
5.2.4.7 Destination and direct contact number
5.2.4.8 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 Name of the doctor
5.2.5.2 Name of the patient
5.2.5.3 Name of the hospital
5.2.5.4 Address
5.2.5.5 Contact number
7

5.2.5.6 Number of units (amount of blood patient needs)
5.2.5.7 Blood type
5.2.5.8 Blood group
5.2.5.9 Date and time when the blood is needed

5.3

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

8

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
7.1

Use Case Diagram

New User registration

Existing User registration Blood Collection and details Admin

End User
Search donor

Request blood

9

7.2

Use Case Scenario Description

Use Case
Summary

Success End

New User registration
The System will update the database to hold the following details for a Patient


Name



Address



Phone



DOB



Gender



Height



Weight



Identification marks



Blood Group

Registration Successful Confirmation Message is displayed to the user

Condition
Failed End

Please fill in the required fields Message to the User when any of the given

Condition

fields is blanks or all zeroes

Trigger

This use case is initiated based on the request from the User

DESCRIPTION

Step

Action

1

The End users will register his database under registration link

10

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

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

Step

Branching Action

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 requirements.

Condition
Failed End

Invalid Id message is displayed to the user

11

Condition
Trigger

This use case is initiated based on the request from the User

DESCRIPTION

Step

Action

1

The End user will check for the hospital and patients who are in need of blood EXTENSIONS

2

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

3

The end user enters the id in the text box

4

The End User Clicks on the Submit Button

Step

Branching Action

1a

Database search is done and the result set is returned to the application

Use Case ID

3

Use Case name

Blood Collection and details

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 along with details

12

Condition
Failed End

Causes malfunction in blood transfusion.

Condition
Trigger

This use case is initiated based on the details gathered from the user.

DESCRIPTION

Step

Action

1

The End user who are doctors or patients Order blood.

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

Step

Branching Action

1a

Database search is done and the result shows whether the blood is free

EXTENSIONS

from HIV positive, etc.

13

Use Case ID

4

Use Case name

Search Donors

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 Condition

Could not get the required blood at right time.

Trigger

This use case is initiated based on request made by the end user.

DESCRIPTION

Step

Action

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.

Step

Branching Action

14

1

Database search is done and the result shows whether the blood donor is available at particular area.

Use Case ID

5

Use Case name

Request Blood

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 needed.

Condition
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

Step

Action

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

15

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

Step

Branching Action

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

16

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.

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
17

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.

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

18

References: 1. AABB Uniform Donor History Questionnaire http://www.aabb.org/resources/donation/questionnaires/Documents/dhq/v1-3/FullLengthDonorHistoryQuestionnairev1.3.pdf (Accessed on September 28, 2011).