Software Requirements Specification

For

Blood Bank Management System

Under the guidance of Submitted by

AGATH MARTIN Sir (03) Abhishek K Roy

JABIR K V T Sir (10) Harsh
(14) Md. Shadan
(34) Shivani Tanya
(38) Uma S Singh

Batch: IT 2019-23

1
 TABLE OF CONTENTS:
1. Introduction
1.1 Purpose..............……………........……………………............................……………..3
1.2 Document Convention................…………………………............................……4
1.3 Intended Audience…………………………………………………………………….4
1.4 Definitions – Acronyms...........................................……....................………….4
1.5 Product Scope…………………………………………………...................………….5

2. Overall Description
2.1 Product Perspective…………………………………………............................…..6
2.2 Product Functions……………………………………………............................….7
2.3 User Characteristics………………………………………............................…….7
2.4 User Classes……………………………………………………...........................……10
2.5 Constraints………………………….......................................................................10
2.6 Assumptions and Dependencies……………………….............................….11

3. Specific Requirements
3.1 Functional Requirements………………………………...............................…12
3.2 Non-Functional Requirements…………………………...........................….13
3.3 Logical Database Requirements………………………...........................….14

4. Other Requirements
4.1 Safety………………………………………………………………………………….....15
4.2 Security……………………………………………………………………………...….15
4.3 Software Quality………………………………………….....................………….16

5. Performance Requirements
5.1 Hardware Constraints……………………………………………………………18
5.2 Software Constraints……………………………………………………........….18
5.3 Design Constraints……………………………………………….............……….18

6. Conclusion………………………………………………………..........................………19

2
1. Introduction
● In this we will discuss and analyse the developing process of the Blood bank
management system including software requirement specification (SRS).
● The functional and non-functional requirements are included in the SRS part to
provide complete description and overview of system requirements before the
developing process is carried out.
● Blood donation are entered and maintained in this project. Blood stock reports
and blood reports are managed in this project.
● The project blood bank management system is known to be a pilot project that
is designed for the blood bank to gather blood from various sources and
distribute it to the needy people who have high requirements for it.
● The Software is designed to handle the daily transaction of the blood bank and
search the details when required.
● It also helps to register the details of donors, blood collection details as well as
blood issued reports.
● The software Application is designed in such a manner that it can suit the needs
of all the blood bank requirements in the course of future.
● It will help us to find the Blood group with its most efficient time to take care
of the blood and it is more easy to hand over the blood to the hospital to help
people to get blood on time.
● This all thing has been stored and been seen in this blood bank management
system to help more people trying best to do so.

1.1 Purpose
The purpose of this document is to give a detailed description of the
requirements for the “Blood Bank Management System(BBMS)” project. It will
illustrate the purpose and complete declaration for the development of the
system. The purpose of this project is to provide a friendly environment to
maintain the details of the books and library members. The main purpose of this
project is to maintain an easy circulation system using computers to provide
different reports. The document gives the detailed description of the both
functional and non-functional requirements of the project. It will also explain
system constraints, interface and interactions with other external applications.

3
 This document is primarily intended to be proposed to a customer for its
approval and a reference for developing the first version of the system for the
development team.

1.2 Document Convention

1.ER: Entity relationship.
2.This document will use IEEE format. The format for headings is as followed:
Major headings are in bold 26pt font, and concurrent headings in 26pt font.

1.3 Intended Audience

Anybody can use this blood bank management system to donate as well as who
need blood.
e.g.,Public, Hospitals, Blood Banks, etc.

1.4 Definition and Acronyms

4
 1.5 Product Scope
This application is built such a way that it suits for all type of blood bank in
future. So every effort is taken to implement this project in this blood bank, on
successful implementation in this blood bank, we can target other blood banks in
the city. Main modules of the project:

This project have the following modules:

To manage all the requirements of the blood bank-
1. Blood donor details.
2. Donor details.
3. Recipient details.
4. Blood collection details.
5. Blood issued details.
6. Stock details.
7.Camp details.
8. Reports

To manage employees in the blood bank it had the following modules-

1. Employee details.
2. Employee attendance details.
3. Employee salary generation.
4. Employee salary payment.
5. Report.

5
 2. Overall Descriptions
This section will give an overview of the entire system. System will be
explained in its context to show how the system will work and introduce the
basic functionality of it. It will describe all the stakeholders who will access to
the system and what functionality is available for each type. The constraints
and assumptions for the system will be explained.

2.1 Product Perspective

This system includes both offline and online components. The collection of
blood will be manual through Blood Donation Camp. The donor can either
register on the Blood Bank website on his own or can visit the Blood Donation
Camp and the responsible authority at the camp can do the registration for the
donor. An online database is maintained with all the information about the
donors. Once the blood is collected it stored in a bank. An online Blood
Inventory Database is maintained as well for the Blood Units collected. From
here a small sample of the blood units are sent to the Testing Unit. Here the
blood samples are tested to determine whether they are fit to be used or not. A
report is made by the lab technician and is sent back to the Blood Bank. Based
on the reports received the Blood Bank Inventory is updated-some blood
samples might need to be discarded as they are not fit for use. Hospitals place
orders from this Blood Bank. A record of the order and payment is maintained
by both parties. Once the order is placed the Blood Bank Manager send the
receipt. Once the hospital makes the payment the order is delivered by the Blood
Bank staff. A complete database of all the staff working in the Blood Donation
Camp as well as the Blood Bank is maintained.

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 donate blood. The system also consists of
some local system hardware devices as well. A printer and 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.

6
 2.2 Product functions
According to this project, a Donors can create an account at home or register
themselves at the spot of blood camp before donating blood. The Hospital
Manger has to register the Hospital which act as an acceptor here. The details of
the blood inventory i.e., the availability of a particular type of blood is regularly
updated and maintained by the Inventory Manager. It is a confidential data so the
access is only with the administrators. The registered hospital can place an
online order. The order is processed by the Inventory Manager who can check
the database of the blood units. If the required blood type and the amount is
available, it notifies the corresponding hospitals. When the Hospital Manager
confirms the Order, the details are being sent to it.

Login Interface:
User should enter the valid username and password to get access to its
profile.
Donor Profile:
User will be able to see its Account Number, The receipts of the blood
donated to the bank, Donation to the Bank, Need of the Blood to the Bank
and Request for Blood.
Blood Stock Management:
It will show the Blood Detailed of the specific bottle with its Full Donor
Detail or Account No. if he/she is registered to the Bank.
Report:
It will be available on the Admin’s Profile and will show the Availability
of the Blood Groups with its no. of available bottle as per admin’s choice
to view the report as Month, Day, or Year.

2.3 User Characteristics

There are mainly seven people interacting with each other in this system: Donor,
Receptionist, Hospital Manager, Blood Camp Doctor, Inventory Manager,
Delivery Boy. The Donors register through the website or at the spot of blood
donation. The Receptionist assists them and maintain the details of the Donors.
The Receptionist updates the donor database. The Blood Camp Doctor who
collects the blood units from the donors with proper procedure. After the

7
 collection and packaging of the blood, the Doctor sends the samples to the Lab
Technician for Blood testing and the rest of the blood units to the blood
inventory. The Lab Technician carries out test on each blood sample.
He sends the blood report to the Inventory Manager. The Inventory Manager
carefully studies the report. According to which he/she discards the unfit blood
and store the healthy blood in the respective places. Then he/she updates the
required changes in the blood inventory database. He/she keeps a track of the
date of the blood was newly stored in the inventory and its expiry date. The
Hospital Manager places an order for the blood units as per the Hospital’s
requirement. The Inventory Manger go throughs the order. After confirmation,
he requests the hospital manager to do the payment. When the order is confirmed
and the payment is done, the Delivery Boy delivers the blood units very carefully
at the Hospital. The Hospital Manager checks and maintains the details.

Main USERS:
1. Admin:
This module focuses on the both donors & acceptors. Each member in a donor & acceptor is given a user id
and password, which identifies them uniquely. The member is given a login form where they enter the login
details, user id and password. The options given are -
• Maintain donor details
• Maintain referral once
• Update donor details
• View Experiences
• Logout/Change Password

Whenever a user wants to change their password they can select the change password option. The system
displays the form, which asks them for their old password and new password. The system then compares the
old password with the existing password in the database to verify.

2. Donor:
Each member in a Donor is given a user id and password, which identifies them uniquely. The member is
given a login form where they enter the login details user id and password. The options given to each
member in a staff are -

8
 • Change password
• Find a Blood group

• Why donate blood

• Who needs blood
• Find a Donor
• Refer a friend
• Logout

3. Acceptor:
• In this you can store the information about Acceptors.
• Change password
• Find a blood group.
• Who needs blood
• Logout

9
2.4 User Classes
System Owner: The Blood Bank
System Users:
Administrators: Has full privilege on the system's functions
Public: Can view the blood donation events and donate or can make
requests for donation (Donor and Recipients fall under this category).

2.5 Constraints
GUI will be only on English. The Donor and the acceptor are constrained to
create an account first to avail the services. The internet connection is also a
constraint for this web application. The web application is also constrained by
the database capacity so it works well with a smaller number of donors and
hospitals. The access to manage the databases are different for different people.
The worker is given the access to maintain the database of the registered donors
and hospitals. The inventory manager is allowed access to update the inventory

10
 details and payment of the order placed by the hospitals. The program might be
written in PHP language. The both kind of donors who has the internet
connection and who hasn’t the internet connection can contribute to the donation
through the 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
certificates & providing donation details to the system, the doctor will
connect directly with the system administrator.

2.6 Assumptions and Dependencies

It is assumed that the users have enough resources to run the web application i.e.
a mobile phone or a computer that supports the required functions. It is assumed
that the online payments carried out are looked by the respective bank
administrators. The web application depends on the application such as MySql
for creating and managing the database. The front end is designed with the help
of HTML, CSS, JavaScript, PHP, etc. Every donor has a mobile phone. 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 be done 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 an 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.

11
 3. Specific Requirements

3.1 Functional Requirements

1. Access Website: User should be able to access web-application through either
an application browser or similar service on the mobile phone or computer.
There should not be any limitation to access web application.

2. User Registration: Given that user has accessed web-application, then the user
should be able to register through the web application. The donor user must
provide first name, gender, blood group, location, contact , username and
password.

3. New Releases: When a new/update version of the web-application is released,

the appearance will be automatically appears when the user access the web-
application.

4. User log-in: Given that the user has registered, then the user should be able to
login to the web-application. The login information will be stored on the
database for future use.

5. Search result in a list view: Search result can be viewed in a list. Each element
in the list represents a specific donor. Each element should include first name,
gender, blood group, location, contact according to the user position. There
should be maximum of ten result display.

6. Request Blood: User(Hospital) should be able to request for blood at

emergency situation, user need to define blood group, location, required date,
contact. The order requested will be sent to blood bank and then to the Inventory
to check the availability. If available, the requested blood will be sent to the
requested donor(Hospital).

7. View Request: The Blood Bank should be able to view received request and
then respond to them and can search requests by selecting two options select
blood group and provision.

8. Search Blood Bank Stock: Receiving the order from Hospital , the blood stock

12
 in the Blood Bank Inventory will be searched to match the requested order. Thus
matched blood units will be sent to the Hospital.

9. View Order Details: The Hospital, Blood Bank should be able to view the
OrderId, time of the order placed, name of the hospital, location and the address
of the hospital. In addition to this an additional feature of tracking the delivery
person which includes his location and the checkpoints passed.

10. View Delivery Status: The Hospital, Blood Bank should be able to view the
status of the delivery time. If the delivery seems to be delayed then the hospital
manager must to able to call the delivery person to get the update on the
delivery.

3.2 Non-functional Requirements

1. Availability : The system including the offline and online components should
be available 24/7.

2. Reliability: If there is extensive damage to a wide portion of the database due

to catastrophic failure, such as a disk crash, the recovery method restores a past
copy of the database that was backed up to archival storage (typically tape) and
reconstructs a more current state by reapplying or redoing the operations of
committed transactions from the backed up log, up to the time of failure.

3. Security: Security systems need database storage just like many other
applications. However, the special requirements of the security market mean that
vendors must choose their database partner carefully.

4. Correctness: The Blood Unit sent by the Blood Bank should be matched with
the requested Blood Unit by the Hospital, which should reach the correct
destination(Requested Hospital).

5. Maintainability: The Blood Inventory Manager should maintain correct

records of the Blood Inventory Stock.

6. Usability: The cost of the Blood Units are standardized.

13
 7. Extensibility: Requirements for website extensibility in case there is a need to
add new functional requirements.

3.3 Logical Database Design

1. Donor Database: The receptionist at the Blood Donation Camp will maintain
the donor database which will contain all the information of the donors.

2. Staff Database: This database will contain all the information of the staff
involved in every unit of the database. The doctors, nurses, lab technicians,
people maintaining the online website etc. are staff whose information is to be
maintained.

3. Blood Inventory Database: This database has all the inventory of the blood
units collected. In certain cases when a blood unit is to be deleted or added the
updation is done in this database.

4. Order Database: The Blood Bank Manager has access to this database where
he can view all the orders which are placed. This database contains all previous
and current orders which are placed by the hospitals.

14
 4. Other Requirements

4.1 Safety
1. The database may get crashed at any certain time due to virus or operating
system failure. Therefore, it is required to take the database backup so that the
database is not lost. Proper UPS/inverter facility should be there in case of power
supply failure.
2. In case of a hardware failure or database corruption, a replacement page will
be shown and backups of the database should be retrieved from the application
data folder and saved by the administrator.

4.2 Security
1. System will use a secured database.
2. The system uses SSL (secured socket layer) in all transactions that include any
confidential customer information.
3. Normal users can just read information but they cannot edit or modify.
4. System will have different types of users and every user has access
constraints.
5.Proper user authentication should be provided. No one should be able to hack
users' password.
6. There should be separate accounts for admin and members such that no
member can access the database and only admin has the rights to update the
database.
7. The system must automatically log out all customers after a period of
inactivity.

15
 4.3 Software Quality
Blood Bank Management System software has many quality attributes that are
given below:

1. Adaptability: This software is adaptable by any organization.

2. Availability: The system should be available at all times, meaning 24 x 7
availability. The availability of the software is easy and for everyone.
3. Correctness: The results of the function are pure and accurate.
4. Flexibility: The operation may be flexible and reports can be presented in
many ways.
5. Maintainability: After the deployment of the project if any error occurs then
it can be easily maintained by the software developer.
6. Portability: The software can be deployed at any machine.
7. Reliability: The system is reliable in its operations and for securing the
sensitive details.
8. Reusability: The data and record that are saved in the database can be reused
if needed.
9. Robustness: If there is any error in any window or module then it does not
affect the remaining part of the software.
10. Testability: The software will be tested at every stage like -
❏ Alpha Testing
❏ Beta Testing
❏ Acceptance Testing

11. Usability: Performing any operation and understanding the functioning of

software is very easy.
12. Productivity: This software will produce every desired result with accuracy.
12. Timelines: The time limit is very important as it will save much time and
provide fast accessing.
13. Cost effective: This software is less in cost and bearable by any organization.

16
 5. Performance Requirements
The proposed system that we are going to develop will be used as the Chief
performance system within the different libraries which interacts with the
hospital staff and students. Therefore, it is expected that the database would
perform functionally all the requirements that are specified by the hospital
management.

1. The performance of the system should be fast, accurate and easy.

2. The development of the software will be based on the object oriented model.

3. The performance of the functions and every module must be well.

4. At every step the output of the one phase is the input of the other phase and it
will be reliable and accurate.

5. The risk factor must be taken at initial step for better performance of the
software.

6. For individual function the performance will be well.

7. Blood bank management shall handle expected and unexpected errors in

ways that prevent loss in information and long downtime period in order to.

8. Thus it should have inbuilt error testing to identify invalid

username/password.

9. The system should be able to handle large amount of data. Thus it should
accommodate high number of books and users without any fault. The system
must be simple, accurate and fast to be most efficient.

17
 5.1 Hardware Constraints
The storage system used should be of top quality to deal with large data to store
and should have proper backup facility in case the server crashes. The data can
be used in life and death situations, thus need to be protected.

5.2 Software Constraints

The website will be directly linked to the backend to reduce the delay in
processes, as our topmost priority is to make our system fast, accurate and easy
to use. The time during retrieving and submitting the data should be very low.

5.3 Design Constraints

Simple commands and less animation should be there to make the system easy to
use and fast. Our aim is to reduce the time taken in retrieving and submitting
data to the system.

18
 6. Conclusion
Our project is only a humble venture to satisfy the needs of a realistic Blood
Bank. The objective of software planning is to provide a framework that enables
the working of Blood Bank. We are grateful that we got the opportunity to
understand how software are designed in the real world. We got to design a
small software through which we learnt a lot. This project shed light on how this
subject is useful in practical terms. The purpose of this theory subject was
justified.

19