Final SRS document - Lecture notes 1 PDF

Preview

Summary

Table of Contents...........................................................................................................................Table of Contents Table of Contents........................................................................................................................... I...

Description

Page 1 of 24

Table of Contents Table of Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 1.2 1.3 1.4

Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Document Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Product Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 .Ov e r a l lDe s c r i pt i on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 2.2 2.3 2.4 2.5

Product Perspective. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 User Classes and Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Operating Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Design and Implementation Constraints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Assumptions and Dependencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 .Sy s t e mf e a t ur e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 . 1 Pa t i e n tRe g i s t r a t i o n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 . 2 Pa t i e n tAd mi s s i on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3 . 3 Pa t i e n tDi s c h a r g e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 . 4 Ap p o i nt me n t sSc h e d u l e i n g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3 . 5 Re p o r tGe n e r a t i on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 .Da t aRe qui r e me nt s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 4 . 1 Lo g i c a lDa t aMo de l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 0 4 . 2 Da t aDi c t i o n a r y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 4 . 3 Re p o r t s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2

5 .Ex t e r na lI nt e r f a c eRe qui r e me nt s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 5 . 1 5 . 2 5 . 3 5 . 4

Us e rI nt e r f a c e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 Ha r d wa r eI n t e r f a c e s : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 So f t wa r eI n t e r f a c e s : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 6 Co mmu n i c a t i o n sI n t e r f a c e s : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 7

6. Quality Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 7 6.1 6.2 6.3 6.4 6 . 5 6 . 6

Usability:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Performance:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Security:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 9 Reliability:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 I n s t a l la b i l i t y : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 I nt e gr i t y : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1

7. Internationalization and Localization Requirement:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1 Appendix A:. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2

Page 2 of 24

1. Introduction: This is a Software Requirements Specification (SRS) for the Hospital Management System. It elaborates the functions, goals and tasks that the system can perform. This document used to describe the scope of the project, system features and to plan for the system’s design and implementation. Additionally, it gives idea of characteristics of each user interface that the system needs. Moreover, it also illustrates how our system provides security, modifiability, reliability and other quality attributes.

1.1Purpose The proposed product is automated Hospital Management System (HMS) of Version 1.1. This Software Requirements Specification document explains the whole (HMS) system which consists of several modules. This document is helpful for intended software engineers, system testers and software designers in developing, testing, and producing the ( HMS) and for the project. Any reader who would read this document is recommended to read the sections sequentially, and to reference the appendices which contain acronyms and abbreviations as one progresses so that he can understand jargon, specialized terms and definitions.

1.2Document Conventions This document will use IEEE format. For clarity, acronyms and technical jargon will be annotated and included in the glossary. The format for headings is as followed: Major headings are in bold 18pt font and underlined whereas concurrent headings in bold 14 pt font as well as underlined. All the specialized terms and abbreviations are italicized and bold. Sections are in the format of x.y , where x and y are real, positive integers. Individual functional requirements in specified section is written with a short text code followed by a sequence number. The simple content-text is in 12 pt font.

Page 3 of 24

1.3Product Scope The proposed software product is the Hospital Management System (HMS).The project maintains two level of users: Administrator Level-Doctors and User Level-Data Entry Operator (receptionist). The system will be used to get the information from the patients and then storing that data for future usage. The current system in use is a paper-based system. It is too slow and cannot provide updated lists of patients within a reasonable timeframe. The objectives of this system is to increase the number of patients that can be treated accurately and to reduce overtime pay which we give to employees for maintaining registers of patients’ records. Doctors will also use the system to keep track of the patients assigned to them. Nurses who take care of patients will use the system to keep track of available beds and update health condition of each patient present in different wards on daily basis, and the types of medication required for each patient. The receptionist register the patient and schedule patient’s admission by searching for available room or bed. Requirements statements in this document are both functional and nonfunctional.

1.4References Software Requirements Specification for Soft Right Hospital Management System Version 1.1 Consolidated by M. Slater under the Supervision of Dr. S. Acharya [1] http://groups.umd.umich.edu/cis/course.des/cis375/active/class7/EM-SRSReviewSoftRightHospitalManagementSystemSRS.pdf Developer Best Practices Karl Wiegers, Joy Beatty-Software Requirements-Microsoft Press (2013) [2]

2 .Ov e r a l lDe s c r i pt i o n 2.1Product Perspective A hospital management System is a computer based system that facilitates managing the functionality of the hospital. This software will make the whole system automated. It doesn’t

Page 4 of 24 require any paper work. It encapsulates all the information related to patients, doctors, staff and admin details in one software. This software is an entirely new product which addresses the needs of ABC Hospital. This system is independent and self-contained which is designed for the internal working of hospital. It doesn’t interact with any external system.

Figure 2.1.1 Context Diagram for Hospital Management System.

2.2User Classes and Characteristics The main user classes that will be used in hospital encompass Admin, doctors, nurses and receptionist. The system is developed in such a way that each user can easily interact with it. So it uses a Graphical User Interface (GUI) and it is designed to be user-friendly by its appearance as well as functions.

Page 5 of 24 2 . 2 . 1

Admi n

Admin has a full access to the system so he is able to manage any activity regarding with this system. He is the highest privileged user who can access the system. He has high level computer training and is responsible for all of the scheduling and updating day/night employee shifts, assigning doctors and nurses to patients. He is also able to manage doctors and patients detail, generate reports and deals with salaries.

2 . 2 . 2

Re c e pt i o ni s t

They all have general secretarial duties to interact with the system in order to provide services to their patients. Every staff has some basic computer training. They are responsible for patient’s check-in or notification of appropriate people (e.g. notify admin or nurse when an event occurs), scheduling appointment and admission, keep track of patient’s details and maintain bill details. 2 . 2 . 3

Nur s e s :

All nurses should have post-secondary education in nursing. Some of them are computer literate. Patients give short descriptions to them about their conditions. They are responsible for assigning patients to appropriate wards if the beds are available, otherwise putting patients on the waiting list. Nurses in wards will use the system to check their patient list. 2 . 2 . 4

Do c t or s

All doctors should have a medical degree. Some have further specialized training and are computer literate. Doctors will use the system to check their patient’s list. They are also responsible for admitting and discharging their patients.

2.3Operating Environment OE-1: Software requirements of the system are as follows:

Page 6 of 24 OE-1.1: This Software runs on windows 7 or above operating system compatible for 32bit/x86 and 64-bit/x64 PC architectures. OE-1.2: This system uses MySQL database, which is free and open source (FOS). OE-2: Hardware requirements of the system are as follows: OE-2.1: Corei5 processor is used for the development of the software. OE-2.2: RAM-size – 4GB OE-2.3: Hard Disk Space – 20 GB in terminal machines and 1TB in server machine. It is desktop based software with a user friendly interface. So by satisfying these requirements this system will be able to run all the hospital activities much faster, more effectively and efficiently.

2.4Design and Implementation Constraints Following are the design and implementation constraints that must be implemented. CO-1: Database should be protected with password. CO-2: System should use less RAM and processing power. CO-3: Every user should have unique ID and password. CO-4: Only admin can access the whole system. CO-5: The system must be user friendly. CO-6: The patient record of all hospital in domain should have the same standard of data format CO-7: Software should be design in such a way that should have the ability to incorporate changes.

2.5Assumptions and Dependencies AS-1: It is assumed that well-suited computers will be available before the system is installed and tested. AS-2: It is assumed that the Hospital will have enough trained staff to take care of the system. AS-3: Each user should have valid user id and password. AS-4: User must login to the system to access any record.

Page 7 of 24 AS-5: System with suitable user interface will allow the employees to deal with every query of patients in well and organized manner. AS-6: The system will have high availability. It means we have networks of computer for handling information and if one computer fails the whole system doesn’t halt rather it divides the work load of failed system among active computers. In this ways, this system ensures 24/7 availability to patients. AS-7: As the system saves the verified medical data for patients so, it will produce 100% secure and accurate data. DE-1: Server (the system in which centralized database is running) must be running for the system to perform function.

3 .Sy s t e mf e a t ur e s 3. 1Pa t i e ntRe gi s t r a t i on 3 . 1 . 1

De s c r i pt i o n

The PRS system shall allow user to register a patient in database to maintain the records of patient’s information and previous health record. It shall include also include search, edit, and print report features. The receptionist must fill out the form and finalize all information. Once sent, the database will refresh with the newly entered information. This feature has high priority. 3 . 1 . 2

Func t i o na lr e qui r e me nt s

R-PRS-1:

The PRS system shall have a User Interface to collect, edit and print patient data

R-PRS-2:

The PRS User Interface shall have data fields for the following patient information: Patient ID First Name, Last Name, Age, Gender, Date of Birth, Phone, Address , Symptoms details, Referring Doctor’s Name and registration date.

R-PRS-3:

The PRS User Interface shall have a search feature which shall allow patient search by last name + first name and by Patient ID.

R-PRS-4:

The PRS User Interface shall have an Edit option to change patient information (excluding SSN).

Page 8 of 24 R-PRS-5:

The PRS User Interface shall have a Print function to print selected patient reports.

3 . 2Pa t i e ntAdmi s s i o n 3 . 2 . 1

De s c r i pt i o n

This PAS shall allow users to admit a patient into the care of a health professional collecting information about said patient. It shall record the patient’s symptoms and assign them a room and doctor based on their condition. It shall include also include search, edit, and print report features. The doctor must fill out the form and finalize all information. Once sent, the database will refresh with the newly entered information. This feature has medium priority. 3 . 2 . 2

Func t i o na lRe qui r e me nt s

R-PAS-1:

The PAS shall have a User Interface to collect, edit and print patient data

R-PAS-2:

The PAS User Interface shall have data fields f...