Professional Documents
Culture Documents
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.
RevisionHistory
Name
Date
Version
P LAVANYA
29/1/13
1.0
P LAVANYA
04/2/13
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
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.
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.
4.
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
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
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
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.
7. Functional requirements
9
7.1
Admin
End User
Search donor
Request blood
7.2
Use Case
10
Summary
Success End
Name
Address
Phone
DOB
Gender
Height
Weight
Identification marks
Blood Group
Condition
the user
Failed End
Please fill in the required fields Message to the User when any of
Condition
Trigger
This use case is initiated based on the request from the User
DESCRIPTION
Ste
Action
p
1
11
EXTENSIONS
Ste
Branching Action
p
1a
Use Case
Summary
Success End
The details of the User will be displayed to the user along with
Condition
requirements.
Failed End
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
Ste
Branching Action
p
1a
Use Case ID
Use Case
name
Summary
Success End
Condition
Failed End
Condition
Trigger
This use case is initiated based on the details gathered from the
user.
DESCRIPTION
Ste
Action
p
1
13
The End user selects the type of id from the drop down
box
The End User Could see the age of the person who
donated
EXTENSIONS
Ste
Branching Action
p
1a
Use Case ID
Use Case
Search Donors
name
Summary
Success End
Condition
Failed
Condition
14
Trigger
DESCRIPTION
Ste
Action
p
1
The End user selects the particular area and city where
they need the requirements.
EXTENSIONS
Ste
Branching Action
p
1
Use Case ID
Use Case
Request Blood
name
Summary
Success End
Condition
needed.
15
Failed End
Condition
Trigger
This use case is initiated based on the request got from a end
user
DESCRIPTION
Ste
Action
p
1
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
EXTENSIONS
Ste
Branching Action
p
1a
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
18
8.7
AVAILABILITY
8.7.1 Hours of operation
The system will be available on all days 24*7
8.8
RELIABILITY
The mean time between failures for the system will be 1000 hours
8.9
8.10 PORTABILITY
The system will run on windows 95/98/2000/NT/XP/Vista/Windows7
19