Documente Academic
Documente Profesional
Documente Cultură
Revision History
Executive Summary
This document is a Software Requirements Specification (SRS) for the Hospital Patient
Management System (HPMS). It describes the functions, goals and tasks that the system
can perform. Software Team Development Inc. (STD) will use this document to describe
the scope of the project and to plan for the system’s design and eventual implementation.
This document forms the basis for the contract between the hospital and Software Team
Development Inc. (STD).
The document lists the following features as the high-level requirements that the Hospital
Patient Management System will satisfy:
The document also presents a number of requirements that can be classified into two
categories: functional and non-functional requirements. Non-functional requirements can
be used to improve the functioning of the computer system, but not the management of
the hospital as a whole. For these requirements, Software Team Development
recommends that the Hospital management identify a set of experts from their computer
department and their legal department to formally accept the requirements. The primary
areas of concern are performance, security and user-interface. Functional requirements,
on the other hand, are requirements directly related to the hospital management. Software
Team Development Inc. (STD) also recommends that the hospital management identify a
set of experts in the different domains to examine and formally accept these
requirements.
We would be grateful if you accept this document as the beginning of the process for
approving the requirements and launching the design phase of the project. If you have
any questions about this document please contact Chad La Fournie at (403) 210 7545
between 9 a. m. and 4 p.m. on weekdays. Your prompt response will be highly
appreciated.
1. Introduction
1.1 Purpose
The purpose of this document is to describe all the requirements for the Hospital
Patient Management System (HPMS). The intended audience includes all
stakeholders in the potential system. These include, but are not necessarily limited
to, the following: administrative staff, doctors, nurses, surgeons and developers.
Developers should consult this document and its revisions as the only source of
requirements for the project. They should not consider any requirements
statements, written or verbal as valid until they appear in this document or its
revision.
The hospital management and its team members should use this document and its
revisions as the primary means to communicate confirmed requirements to the
development team. The development team expects many face-to-face
conversations that will undoubtedly be about requirements and ideas for
requirements. Please note that only the requirements that appear in this document
or a future revision, however, will be used to define the scope of the system.
1.2 Scope
1.4 References
1.5 Overview
Section 2 of this document provides an overview of the business domain that the
proposed Hospital Patient Management System (HPMS) will support. These
include a general description of the product, user characteristics, general
constraints, and any assumptions for this system. This model demonstrates the
development team's understanding of the business domain and serves to maximize
the team's ability to build a system that truly does support the business.
Section 3 presents the detail requirements, which comprise the domain model.
Picture 1 shows an overview of the Hospital Patient Management System and the
relationships between requirements.
2. General Description
Patient check out. If a patient checks out, the administrative staff shall
delete his PHN from the system and the just evacuated bed is included in
available-beds list.
Report Generation: The system generates reports on the following
information: patients, bed availability and staff schedules after every six
hours. It prints out all the information on who has used which bed, when
and the doctor that is taking care of a given patient as well as expected
medical expenses.
Front-desk staff:
They all have general reception and secretarial duties. Every staff has
some basic computer training. They are responsible for patient’s
check-in or notification of appropriate people (e.g. notify administrator or
nurse when an event occurs).
Administrators:
Nurses:
Doctors:
All doctors have a medical degree. Some have further specialized training
and are computer literate. Doctors will use the HPMS to check their
patient’s list.
3. Specific Requirements
Registration
Consultation
Check Out
Report Generation
SRS031 Database
The system shall use the MySQL Database, which is open
source and free.
SRS032 Operating System
The Development environment shall be Windows 2000.
SRS033 Web-Based
The system shall be a Web-based application.
3.3.1 Security
3.3.3 Maintainability
SRS046 Back Up
The system shall provide the capability to back-up the Data
SRS047 Errors
The system shall keep a log of all the errors.
3.3.4 Reliability
SRS048 Availability
The system shall be available all the time.
APPENDIX
Conclusion
Over the course of completing the exercises summarized in this document (and
as new techniques were explored), we realized that the requirements
development process involves continually finding relations between
requirements, and drilling down to a greater level of detail at each step.
Interviewing
• this was a very easy and systematic method for quickly gathering the top
level of requirements. These can then by used later as a basis of
gathering more detail
Reperatory Grids
• this method helped us to strictly define elements within our system (such
as hospitals, ward and nurses) and their functions
Concept Maps
• the best specification results from a team effort rather than one individual
• helped us to find ambiguous requirements