Software Requirements Specification for Hospital Management System

Software Requirements Specification

Table of Contents
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, an A!!re"iations
1.# References
1.$ %"er"iew
2. General Description
2.1 Prouct Perspecti"e
2.2 Prouct &unctions
2.3 'ser ()aracteristics
2.# *eneral ()aracteristics
3. Specific Requirements
3.1 &unctional Requirements
3.2 Performance Requirements
3.3 +on,&unctional Requirements
3.# Design (onstraints
Appendi
A. 1 Hospital Management Process Diagram
Page 1 of - SRS "2.1
./0-/201#
Software Requirements Specification for Hospital Management System
1. Introduction
1.1 !urpose
"asic Description of !roblem
1)e Aministrator an staff of a )ospital )a"e !een e2periencing ma3or )eaac)es in
organising an managing patients, !es, an nurses. 1)ere )a"e !een reports of
missing patient information, lac4 of security an pri"acy on patient meical )istory,
an confusion in !e allocations. +urses )a"e complaine a!out mista4es in nurse
allocation to patients, an !e management for waiting patients. 1)e manual systems
can not )anle current emans on )ospital staff.
1.2 Scope
1)e purpose of t)is specification is to ocument requirements for a system to manage
t)e )ospital. 1)e specification ientifies w)at suc) a system is require to o. 1)e
specification is written in a format conforming to t)e 5666 Stanar .30,1-.#.
Su!3ect to appro"al, t)e specification will complete t)e Requirements p)ase an will
!e followe !y etaile esign, implementation, an testing.
1)e prouct will !e la!elle t)e Hospital Management System (HMS). 1)e Hospital
Management System will manage a waiting list of patients requiring ifferent
treatment. 1)e a"aila!ility of !es will !e etermine an if !es are a"aila!le t)e
ne2t appropriate patient on t)e list will !e notifie. +urses will !e allocate to wars
epening on war si7es, w)at type of nursing is neee, operating sc)eules, etc.
1)e current manual met)o of managing patients, nurses, an !es is time consuming
an error prone. 5t is also ifficult to manage t)e large paper flow in"ol"e in t)is
process. 1)e Hospital Management System will allow )ospital aministrati"e staff to
access rele"ant information efficiently an effecti"ely.
1)e goal of HMS is to manage nurses, patients, !es, an patient meical information
in an efficient cost,effecti"e manner.
All of t)ese su!,systems 8managing nurses, !es, patient meical information9 nee to
!e esigne an implemente so t)at HMS can run effecti"ely.

1.3 Definitions# Acron$ms# and Abbre%iations
&'S Hospital Management System
G(I *rap)ical 'ser 5nterface
!&ID Patient Hospital 5entification +um!er
Page 2 of - SRS "2.1
./0-/201#
Software Requirements Specification for Hospital Management System
1.) References
1. Austin, (.:. 81-.39. Information Systems for Hospital Administration. Healt)
Aministration Press.
2. Dean, R. 81--;9. The Healthcare Information Systems Directory <online=.
)ttp>//www.)ealt),infosys,ir.com/
3. Rowlan, H.S. 81-.#9. Hospital Administration Handbook. Aspen Pu!lis)ing.
#. Rowlan, H.S., Rowlan, ?.@. 81--29. Manual of Hospital Administration. Aspen
Pu!lis)ing.
1.* +%er%iew
1)is specification inclues a !rief prouct perspecti"e an a summary of t)e functions
t)e software will pro"ie. 'ser c)aracteristics are iscusse an any general
constraints or assumptions an epenencies are liste.
Requirement statements are categori7e as eit)er functional requirements,
performance requirements, non,functional requirements, or esign constraints.
&unctional requirements are furt)er categori7e in terms of patient management,
nurse management, or !e management. +on,functional requirements are furt)er
categori7e in terms of security, maintaina!ility, an scala!ility.
An appeni2 of aitional information is pro"ie. A process iagram is inclue.
2. General Description
2.1 !roduct !erspecti%e
1)e HMS is esigne to )elp t)e )ospital aministrator to )anle patient, nurse an
!e information. 1)e current esign goal is to !uil an internal system to ac)ie"e t)e
functionality outline in t)is specification.
2.2 !roduct ,unctions
1)e HMS will allow t)e user to manage information a!out patients, nurses, an !es.
Patient management will inclue t)e c)ec4ing,in an c)ec4ing,out of patients to an
from t)e )ospital. 1)e HMS will also support t)e automatic !ac4up an protection of
ata.
Page 3 of - SRS "2.1
./0-/201#
Software Requirements Specification for Hospital Management System
2.3 (ser C-aracteristics
1)ere are t)ree ifferent types of users for t)e HMS system>
1ype 1. 1)e Hospital Aministrator 8&ran4 Moisiais9, w)o is most familiar
wit) t)e pro!lem omain. He )ols a M.D. wit) some 4nowlege of
!asic computer operations an applications suc) as Microsoft Aor,
62cel, an PowerPoint. He )as some eucation in computer science,
w)ic) allows )im to aapt to new systems quic4ly. 1)e Hospital
Aministrator is t)e only person w)o will )a"e t)e aut)ority to c)ange
information store in t)e ata!ase. 5n aition, t)e Hospital
Aministrator is t)e ma3or sta4e)oler in t)is pro3ect. 1)e Hospital
Aministrator s)oul t)erefore always !e consulte for comments on
requirements issues.
1ype 2. Aministrati"e (ler4s, w)o )anle ata entry for t)e HMS system.
1)ey )a"e ata entry training from college. Aministrati"e (ler4s are
familiar wit) !asic computer operations.
1ype 3. +urses, w)o are in c)arge of )ospital wars. %f t)e t)ree user types
nurses )a"e t)e least computer 4nowlege. 1)ere is a requirement for
nurses to perform some ata entry. +urses will nee to ma4e regular
sc)euling c)anges, an so t)e interface s)oul !e easy to use.
?ase on t)e a!o"e categori7ations, in orer to meet userBs nees t)e following
precautions s)oul !e ta4en>
t)e interface s)oul !e esigne wit) t)e computer no"ice in min
ata entry mas4s s)oul recogni7e an correct improperly entere ata
for eleting or re"ising a recor t)e system s)oul as4 t)e users for
confirmation
report generation s)oul occur in a timely fas)ion
i"erse computer eucation le"els s)oul !e consiere
online )elp is important
t)e esign s)oul not assume users will perform t)eir 3o!s as e2pecte
error messages s)oul !e use
system esign s)oul follow t)e manual process as closely as possi!le
t)e interface s)oul !e easy to unerstan
users s)oul !e consulte t)roug)out esign
2.) General Constraints
1)e following constraints will limit t)e e"eloperBs options for esigning t)e system>
t)e !uget for t)is pro3ect is 1 million ollars
Page # of - SRS "2.1
./0-/201#
Software Requirements Specification for Hospital Management System
implementation is require !y t)e en of wee4 11, semester 2, 2002.
3. Specific Requirements
3.1 ,unctional Requirements
R l. !atient 'ana.ement Subs$stem
1)e patient management su!system requirements are concerne wit) t)e management
of patient information. 1)ey specify )ow patient information can !e manage an
manipulate.
R 1.1 1)e HMS s)all allow t)e user type 1 an 2 to upate patient personal
information 8name, aress, tel, email, closest relati"e, ate of !irt),
C9.
R 1.2 1)e HMS s)all store all patient illness )istory information 8past
illnesses, test results, allergies, C9.
R 1.3 1)e HMS s)all allow t)e user type 1 an 2 to a new patients into t)e
system.
R 1.3.1 1)e HMS s)all assign a unique 5D to new patients.
R l .) 1)e HMS s)all allow all user types to retrie"e patient personal
information !y patient 5D or patient last name, first name, or Meicare
num!er.
R l.).1 1)e HMS s)all allow all user types to retrie"e patient personal
information.
R l.).2 1)e HMS s)all allow user type 1 an 3 8only if nurse assigne
to t)e particular patient9 to retrie"e patient illness )istory information.
R 1.* 1)e HMS s)all manage t)e patient c)ec4,in process.
R l.*.1 1)e HMS s)all upate t)e patient status to in,patient.
R l.*.2 1)e HMS s)all recor !e, nurse, an octor information
associate wit) t)e patient.
R 1.*.3 1)e HMS s)all allow t)e user type 1 or 2 to c)ange !e, nurse,
an octor information associate wit) t)e patient.
R l./ 1)e HMS s)all allow t)e user type 1 an 3 8only if nurse assigne to t)e
particular patient9 to upate patient treatment information.
R 1.0 1)e HMS s)all manage t)e patient c)ec4,out process.
Page $ of - SRS "2.1
./0-/201#
Software Requirements Specification for Hospital Management System
R 1.0.1 1)e HMS s)all upate t)e patient status to out,patient.
R l .0.2 1)e HMS s)all calculate t)e !ill ue w)en t)e patient c)ec4s
out.
R 1.1 1)e HMS s)all manage patients on a waiting list.
R l.1.1 1)e HMS s)all allow t)e user type 1 or 2 to a patients to a
waiting list.
R l.1.2 1)e HMS s)all allow t)e user type 1 or 2 to remo"e patients
from a waiting list.
R 1.1.3 1)e HMS s)all allow t)e user type 1 or 2 to c)ec4,in a patient
on a waiting list.
R l.1.) 1)e HMS s)all allow t)e user type 1 or 2 to retrie"e waiting
patient information !y illness category, illness seriousness, start
waiting ate, patient last name, first name, 5D, or Meicare num!er.
R 1.2 1)e HMS s)all allow all user types to generate reports on patients.
R l.2.1 1)e HMS s)all allow all t)e user types to generate reports on
selecte patients.
R 1.2.2 1)e HMS s)all allow all user types to generate reports of in,
patients !y war, illness category, or c)ec4,in ate.
R l.2.3 1)e HMS s)all allow all user types to generate reports of on,
waiting patients !y illness seriousness, illness category, or waiting
time.
R2. 3urse 'ana.ement Subs$stem
1)e nurse management su!system requirements are concerne wit) t)e management
of nurse information. 1)ey specify )ow nurse information can !e manage an
manipulate.
R 2.1 1)e HMS s)all allow t)e user type 1 or 2 to a new nurses to t)e
system.
R 2.2 1)e HMS s)all allow t)e user type 1 or 2 to remo"e nurses from t)e
system.
R 2.3 1)e HMS s)all allow t)e user type 1 or 2 to upate nurse information.
Page ; of - SRS "2.1
./0-/201#
Software Requirements Specification for Hospital Management System
R 2.3.1 1)e HMS s)all allow t)e user type 1 or 2 to upate nurse personal
information 8name, aress, tel, email, ate of !irt), C9.
R 2.3.2 1)e HMS s)all allow t)e user type 1 or 2 to upate nurse
specialty information 8area of e2pertise, e2perience9.
R 2.) 1)e HMS s)all allow all user types to retrie"e nurse information !y nurse
num!er or last name, first name, or ta2 file num!er.
R 2.).1 1)e HMS s)all allow all user types to retrie"e a"aila!le nurse
information.
R2.).2 1)e HMS s)all allow all user types to retrie"e nurse
information !y specialty.
R2.).3 1)e HMS s)all allow all user types to retrie"e nurse personal
information.
R 2.* 1)e HMS s)all upate nurse a"aila!le information w)en a nurse is
assigne to a c)ec4e,in patient.
R 2./ 1)e HMS s)all allow user all users to generate reports on nurses !y
specialty, a"aila!le status, or e2perience.
R3. "ed 'ana.ement Subs$stem
1)e !e management su!system requirements are concerne wit) t)e management of
!e information in t)e )ospital. 1)ey specify )ow !e information can !e manage
an manipulate.
R 3.1 1)e HMS s)all allow all users to a new !es to a war.
R 3.2 1)e HMS s)all allow all users to remo"e !es from a war.
R 3.3 1)e HMS s)all upate a"aila!ility status w)en a patient c)ec4s in or
c)ec4s out.
R 3.) 1)e HMS s)all allow all users to retrie"e a"aila!le !e information !y
!e num!er.
R 3.* 1)e HMS s)all allow all users to generate reports a!out !es.
R 3.*.1 1)e HMS s)all allow all users to generate reports a!out !es
!y war or a"aila!ility status.
R3.*.2 1)e HMS s)all allow all users to generate !e usage statistic
reports s)owing !e usage rates in one year !y war.
Page D of - SRS "2.1
./0-/201#
Software Requirements Specification for Hospital Management System
R). +t-er Requirements
R ).1 1)e HMS s)all !ac4up patient, nurse, an !e ata e"ery 2# )ours
automatically.
3.2 !erformance Requirements
R * 1)e HMS s)all respon to userBs retrie"ing information quic4ly. 1)e waiting time
for any retrie"e operation must !e uner 2 secons.
3.2 3on4functional Requirements
R /. Security.
1)e security requirements are concerne wit) security an pri"acy issues. All patient
meical information is require !y law to !e 4ept pri"ate. %nly after t)e patient signs
a written consent form 8on !eing amitte to )ospital9 can anyone 8e"en t)e patientBs
octor, nurse, an t)e )ospital aministrator9 "iew t)e meical etails a!out any
particular patient. 5n t)e case of an emergency, t)e allocate octor, nurse, an t)e
)ospital aministrator are immeiately gi"en user 3 status, an written consent is
soug)t from t)e patient afterwars.
R /.1 1)e HMS s)all support ifferent user access pri"ileges.
R /.1.1 'ser type 2 s)all )a"e security pri"ilege le"el 1. 1)ey can only
rea patient current illness information. 1)ey canEt access patient
illness )istory information.
R /.1.2 'ser type 3 s)all )a"e security pri"ilege le"el 2. 1)ey can rea
an write patient current illness information. 1)ey can only access
patient illness )istory information if t)ey )a"e !een assigne to t)e
particular patient.
R /.1.3 'ser type 1 s)all )a"e security pri"ilege le"el 3. 1)ey can rea
an write patient current illness information. 1)ey can also rea patient
)istory information.
R /.2 1)e HMS s)all protect patient illness )istory information.
R0. 'aintainabilit$
1)e maintaina!ility requirements are concerne wit) t)e maintenance issues of t)e
system.
R 0.1 1)e repair time of HMS s)all !e uner a )alf )our.
Page . of - SRS "2.1
./0-/201#
Software Requirements Specification for Hospital Management System
R 0.2 System own time for maintenance s)oul !e less t)an ; )ours per
quarter of a year.
R1. Scalabilit$
1)e scala!ility requirements are concerne wit) t)e scala!le issues of t)e system.
R 1.1 1)e HMS s)all !e a!le to scale up to support more wor4stations. System
performance s)all not egrae if up to twenty percent 820F9 more
wor4stations are ae.
3.) Desi.n Constraints
R 2. 1)e HMS s)all use a grap)ical user interface.
R 15. 1)e HMS must run in t)e 3r year computing la!s.
R 11. 1)e HMS must !e written in :a"a.
Appendi6
A.1 &ospital 'ana.ement !rocess Dia.ram
Page - of - SRS "2.1
./0-/201#