Software Requirements

Specification

for

<Blood Bank Management

System>

Version 1.0 approved

Prepared by <author>

< Government Postgraduate Islamia College Faisalabad>

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
 <13-12-2019>

Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for <Project> Page iii

Table of Contents

Table of Contents...........................................................................................................................ii
Revision History.............................................................................................................................ii
1. Introduction..............................................................................................................................1
1.1 Purpose...........................................................................................................................................1
1.2 Document Conventions..................................................................................................................1
1.3 Intended Audience and Reading Suggestions.................................................................................1
1.4 Product Scope.................................................................................................................................1
1.5 References.......................................................................................................................................1

2. Overall Description..................................................................................................................2
2.1 Product Perspective........................................................................................................................2
2.2 Product Functions...........................................................................................................................2
2.3 User Classes and Characteristics.....................................................................................................2
2.4 Operating Environment...................................................................................................................2
2.5 Design and Implementation Constraints.........................................................................................2
2.6 User Documentation.......................................................................................................................2
2.7 Assumptions and Dependencies......................................................................................................3

3. External Interface Requirements...........................................................................................3

3.1 User Interfaces................................................................................................................................3
3.2 Hardware Interfaces........................................................................................................................3
3.3 Software Interfaces.........................................................................................................................3
3.4 Communications Interfaces............................................................................................................3

4. System Features.......................................................................................................................4
4.1 System Feature 1............................................................................................................................4
4.2 System Feature 2 (and so on)..........................................................................................................4

5. Other Nonfunctional Requirements.......................................................................................4

5.1 Performance Requirements.............................................................................................................4
5.2 Safety Requirements.......................................................................................................................5
5.3 Security Requirements....................................................................................................................5
5.4 Software Quality Attributes............................................................................................................5
Software Requirements Specification for <Project> Page iv

5.5 Business Rules................................................................................................................................5

6. Other Requirements................................................................................................................5
Appendix A: Glossary...................................................................................................................5
Appendix B: Analysis Models.......................................................................................................5
Appendix C: To Be Determined List...........................................................................................6

Revision History

Name Date Reason For Changes Version

Software Requirements Specification for <Project> Page 1

1. Introduction

The Hospital Management System is designed for any hospital to replace their existing manual
paper-based system. The project Hospital Management system includes registration of patients,
storing their details into the system, and also computerized billing in the pharmacy, and labs. The
purpose of the project entitled as “HOSPITAL MANAGEMENT SYSTEM” is to computerize the
Front Office Management of Hospital to develop software which is user friendly simple, fast, and
cost – effective. The new system is to control the information of patients. Room availability, staff
and operating room schedules and patient invoices. I have designed the given proposed system in
the JSP to automate the process of day to day activities of Hospital like Room activities, Admission
of New Patient, Discharge of Patient, Assign a Doctor, and finally compute the bill etc., All the
control is under the administrator and the other members have the rights to just see the records not
to change any transaction or entry.  These services are to be provided in an efficient, cost effective
manner, with the goal of reducing the time and resources currently required for such tasks.

Problem Introduction:

Lack of Immediate of retrieval:

The information is very difficult to retrieve and find particular information. Like find out the
patient history
Lack of Immediate of Information Storage:
The information generated by various transaction takes time and effort to be stored at right place.
Lack of prompt Updating:
Various changes to information like patient detail are difficult to make as paper work involved.
Error pone manual calculation:
Manual calculation are error prone and take a lot of time this may result in incorrect information
e.g. calculation of patient bill based on various treatments.
Preparation of Accurate Report
This become a difficult task as information is difficult to collect from various regiser.
Software Requirements Specification for <Project> Page 2

1.1 Purpose

Hospital Management System” is developed to computerize the following functions that are
performed by the system:

o Using this hospital management system user can take online Appointments with the doctors.

o Admin can register new patient through this system. 

o Admin can also check Discharge Detail of a patient form discharge report generated by the
system. 

o Discharge of Patient – admin can discharge patient through the system and this information
will display to other users like receptionist and accountant.

o This system is also keep records of Patient’s Disease.

o Admin can also check the report of admitted patient or admitted patient any time. Like total
number of admitted patient in the given time in the hospital.

o Admin can also check the availability of the doctors in the hospital. 

o Administrator can add new doctors in the system and can also check all the doctors list of
the hospital.

1.2 Scope of Hospital Management System:

Being a challenging role, hospital management graduates can enter into this profession from any of
the levels right from middle level management to the top level of the company and hence the scope
gets increased. Also as management in the healthcare sector is highly taken care of after direct
medical services provided to the patients, the professionals have good opportunity to expand their
career with diversification intra and inter institutes.
Because of entrance of private players in the market, who provide quality health care services at
low cost, the experienced and deserving candidates are taken in hands for a particular position. On
the other side with increasing efforts of the government, the rural and urban health care is also
gaining its importance and graduates in this field have more chances of getting employment.

 
Software Requirements Specification for <Project> Page 3

Bills are generated by recording price for each facility provided to Patient on a separatesheet and at
last they all are summed up.3)
 
Diagnosis information to patients is generally recorded on the document, which containsPatient
information. It is destroyed after some time period to decrease the paper load inthe office.4)
 
Immunization records of children are maintained in pre-formatted sheets, which are keptin a file.

Advantages:

1.2.1 1. Easy Access To Patient Data

A well-implemented Hospital Information System means readily available patient data to the care

providers. It is only a matter of few clicks and all the requisite information about a patient, from
various departments in the hospital, can be available on the screen. If the treating doctor needs to
re-check the test reports of a patient, she need not go looking for the IPD file; logging into the HIS
will give her instant access to those reports and timely treatment decisions ensue.
1.2.2 2. Cost Effective

HIS, when implemented well, cuts out on a lot of manual work that are essentially performed in
hospitals, especially the ones where documentation and record keeping is required. It helps in
cutting down manpower because a lot of work gets automated and does not require manual
intervention to store or analyze the information. It also saves much on storage and the related costs.

1.2.3 3. Improved Efficiency

Processes automated using software would mean that the processes will be taken care of
mechanically without any human intervention and this will instantly ensure improved efficiency.
The software will not face human problems like fatigue, miscommunication or lack of focus; it will
perform every task assigned to it with the same accuracy day in and day out.
1.2.4 4. Reduces Scope of Error

Because processes on HIS are automated and a lot of tasks are assigned to the software to perform
with utmost accuracy with minimum human intervention, the scope of error is reduced
dramatically. For instance, while billing an IDP patient for the drugs used with HIS, the bill can
Software Requirements Specification for <Project> Page 4

hardly go wrong because the drug the nurse indents is what is billed for until and unless there is a
shortage in stock or change in drug order after the indent has been sent. Per unit rate of the drug is
saved in the software as part of standard operating procedure of automation. Just selecting the drug
name and the quantity will enable the software to calculate the amount due,accurately.

1.2.5 5. Increased Data Security & Retrieve-ability

Record keeping in hospitals is a mandatory bane with two challenges: keeping the data safe with
only authorized personnel getting access to it and retrieving it in the minimum possible time. Add
to these the perennial problems of space shortage, protection from natural elements and protection
from pest damage etc.

HIS is the perfect solution for these problems. All the data is stored on the server or cloud, keeping
it safe. Since HIS works on logins, data security is becomes a non-issue offering data access based
on the role of the person – Receptionist, doctor, nurse, radiologist etc. Retrieve-ability of data
stored on a server or cloud is only a matter of few clicks and the data will appear on the screen
within seconds.

1.2.6 6. Improved Patient Care

Improved access to patient data and improved work efficiency means better and faster clinical
decisions. In this age of evidence based medicine, the faster the clinician gets the diagnostic reports
and the quicker her orders are implemented the faster is the patient recovery and the better it is on
the patient care index. With automation, all departments in the hospitals are inter-connected and the
faster information access further improves the quality of patient care and the resultant bed turnover
in the hospital.

Functional Requirement of the System:

Functional requirement of the system is the list of actual services which a system will

provide or provided by the user. It is necessary to add in the system. The functional requirement of
Software Requirements Specification for <Project> Page 5

the Hospital Management Systems which contains the following services which is given below

(demands by the client):

o Information about patient is done by writing the user name and password. Whenever the

patient comes up his information is stored freshly. The functions of name and password to

login the system and see own record on the system.

o Doctors detail is generally recorded on the document which contains Doctor id, category,

Name, Father Name, Phone No, and Address. The doctor detail means that we see that how

many doctors are worked in hospital and it also indicates that what doctor is specialize in

what fields.

o Staff detail is generally recorded on the document which contains ID, Department, Name,

Father Name, Address and phone number. The staff detail means how many types of worker

work in hospital. And it also shows how many departments are worked in hospital. And it

also gives information that what person of department are available.

o Doctor’s Schedule is generally recorded on the document which contain ID, category,

Phone, Name, starting time of duty and end time of duty. First of all, we write the

information of doctors link and then select it what doctors are required. And then we write

only id all data are automatically appear of written query and we checks all the records of

doctor and we also checks that what doctor is available in what time and what is the starting

time of doctor and ending time of doctor

o Users Form is generally recorded on the document which contain code, name U-Name, U-

Password, Address, Phone

Non-Functional Requirements 
Software Requirements Specification for <Project> Page 6

There are a lot of software requirements specifications included in the non-functional requirements
of the Hospital Management System, which contains various process, namely Security,
Performance, Maintainability, and Reliability.

Security:

o Patient Identification: The system needs the patient to recognize herself or himself using the
phone.

o Logon ID: Any users who make use of the system need to hold a Logon ID and password.

o Modifications: Any modifications like insert, delete, update, etc. for the database can be
synchronized quickly and executed only by the ward administrator.

o Front Desk Staff Rights: The staff in the front desk can view any data in the Hospital
Management system, add new patients record to the HMS but they don't have any rights
alter any data in it.

o Administrator rights: The administrator can view as well as alter any information in the
Hospital Management System.

Performance: 

o Response Time: The system provides acknowledgment in just one second once the 'patient's
information is checked.

o Capacity: The system needs to support at least 1000 people at once.

o User-Interface: The user interface acknowledges within five seconds.

o Conformity: The system needs to ensure that the guidelines of the Microsoft accessibilities
are followed.

Maintainability: 

o Back-Up: The system offers the efficiency for data back up.

o Errors: The system will track every mistake as well as keep a log of it. 
Software Requirements Specification for <Project> Page 7

Reliability: 

o Availability: The system is available all the time.

Software Quality Attributes

Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness, flexibility,
interoperability, maintainability, portability, reliability, reusability, robustness, testability, and
usability. Write these to be specific, quantitative, and verifiable when possible. At the least, clarify
the relative preferences for various attributes, such as ease of use over ease of learning.

Software Tools:
The software tools which will involve in all development process.

o ORACLEs Software

(Any oracle software is used to develop a software such as ORACLE 6i)

o Form Builder
(To develop a front end of software)
o Operating System WINDOW 7 Ultimate SPI
o Window Installer 3.5

Hardware Specification:
The hardware required to develop this system which are as follow.
o Processor-Intel Atom Processor N2600
(1m cache, 16GHz)
o Hard Drive- 1GB (For Installing)

Deployment:
What kind of environment will be needed to deploy or run this system? It depends on both
hardware and software specification.
Software Tools:
ORACLE’s Software, OS WINDOW 7ultimate SPI, form builder etc.
Hardware Tool:
Software Requirements Specification for <Project> Page 8

Intel Atom Processor N2600, 1m cache and 16GHz,1gb har drive for installing.

Feasibility Study: -

The overall scope of the feasibility study was to provide sufficient information to allow a
decision to be made as to whether the hospital management system project should proceed and so,
its relative priority in the context of the other existing hospital management system.

The feasibility study of this project had undergone through various steps which as describe as
under:

a)   Identify the origin of the information at different level.

b)  Identify the expectation of user from computerized system.

c)   Analyze the drawback of existing system.

Product Description

The system that is going to be developed is Blood Bank Management System (BBMS). This is a
Web-based database application system that is to be used by the blood banks or blood centers as a means to
advertise the nationwide blood donation events to the public and at the same time
allow the public to make online reservation and request for the blood.
The system keeps the record of all the donors, recipients, blood donation programs, rejected
bloods. For internal works and activities intranet is used and for interaction with public internet is used.
This system also has the ability to keep track of the donor's donation records and the blood stock in the
blood bank. This project intends to computerize the blood and donor management system in a blood bank in
order to improve the record management efficiency due to the grown size of
records of data.
Software Requirements Specification for <Project> Page 9

1.3 References

Vikas Kulshreshtha, Sharad Maheshwari. (2011).”Blood Bank Management Information System in

India”, International Journal of Engineering,1,2, 260-263. Rational Unified Process, Best Practices
for Software Development Teams. (2012). Core Workflows Retrieved from
www.ibm.com/developerworks/rational/.../1251_bestpractices Noushin Ashrafi, & Hessam Ashrafi.
(2008). Object Oriented Systems Analysis and Design, Pearson Higher Ed USA. Lions Blood Bank
& Research Foundation. (2012). Retrieved from http://www.lionsbloodbank.net/ Blood Bank India.
(2012). Retrieved from http://www.bloodbankindia.net

2. Overall Description

2.1 Product Perspective

2.2 Product Functions

<Summarize the major functions the product must perform or must let the user perform. Details will be
provided in Section 3, so only a high level summary (such as a bullet list) is needed here. Organize the
functions to make them understandable to any reader of the SRS. A picture of the major groups of related
requirements and how they relate, such as a top level data flow diagram or object class diagram, is often
effective.>

2.3 User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise, security or
privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class.
Certain requirements may pertain only to certain user classes. Distinguish the most important user classes
for this product from those who are less important to satisfy.>
Software Requirements Specification for <Project> Page 10

2.4 Operating Environment

<Describe the environment in which the software will operate, including the hardware platform, operating
system and versions, and any other software components or applications with which it must peacefully
coexist.>

2.5 Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might include:
corporate or regulatory policies; hardware limitations (timing requirements, memory requirements);
interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations;
language requirements; communications protocols; security considerations; design conventions or
programming standards (for example, if the customer’s organization will be responsible for maintaining the
delivered software).>

2.6 User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be
delivered along with the software. Identify any known user documentation delivery formats or standards.>

2.7 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS.
These could include third-party or commercial components that you plan to use, issues around the
development or operating environment, or constraints. The project could be affected if these assumptions
are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors,
such as software components that you intend to reuse from another project, unless they are already
documented elsewhere (for example, in the vision and scope document or the project plan).>
Software Requirements Specification for <Project> Page 11

3. External Interface Requirements

3.1 User Interfaces

<Describe the logical characteristics of each interface between the software product and the users. This
may include sample screen images, any GUI standards or product family style guides that are to be
followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every
screen, keyboard shortcuts, error message display standards, and so on. Define the software components
for which a user interface is needed. Details of the user interface design should be documented in a
separate user interface specification.>

3.2 Hardware Interfaces

Server Side:
Processor 3.6 GHz
RAM 2 GB
Hard Disk 80 GB
Client Side:
Processor 2.40 GHz
RAM 1 GB
Hard Disk 20 GB

3.3 Software Interfaces

• Server Side

Operating System Window Server 2008

Runtime Environment.Net Framework 4.0

Web Server IIS 7.0

Software Requirements Specification for <Project> Page 12

Front End Microsoft Asp.Net 2010 with c#

Back End SQL server 2008

• Client Side

Operating System Windows XP or any compatible OS

Web Browser Internet Explorer 6.0 or any compatible web browser.

3.4 Communications Interfaces

<Describe the requirements associated with any communications functions required by this product,
including e-mail, web browser, network server communications protocols, electronic forms, and so on.
Define any pertinent message formatting. Identify any communication standards that will be used, such as
FTP or HTTP. Specify any communication security or encryption issues, data transfer rates, and
synchronization mechanisms.>