Uploaded by Shalvic Kelly

his srs-complete

advertisement
Running Head: SOSTWARE REQUIREMENTS SPECIFICATION DOCUMENT FOR
HOSPITAL INFORMATION SYSTEM
PROJECT NAME: SOFTWARE REQUIREMENTS SPECIFICATION FOR HOSPITAL
INFORMATION SYSTEM
STUDENT NAME:
COURSE NUMBER:
COURSE NAME: SOFTWARE REQUIREMENTS ENGINEERING
PROFESSOR:
SCHOOL:
DATE: Dec 9th, 2013
2
Executive Summary
This SRS document for the Hospital Information System describes the tasks, functions
and goals of the system’s performance. The development team will refer to this document to
describe the design plan and the project scope as well as the final implementation of the new
proposed HIS. The document also serves as the contract basis between the system team
developing team and the hospital. The following high-level system requirements have been listed
for this document. The system will satisfy the following;

Management of Wards by coordinating and planning management of rooms

Scheduling work by assigning doctors to different patients and nurses to doctors

Managing surgery by organizing and planning work done in the operating rooms by
nurses and surgeons

Waiting list monitoring and management to ensure waiting patients are attended toby
assigning them beds and doctors

Patient care by thoroughly monitoring patients visiting the hospital

Admissions which is done by assigning patients rooms or appropriate wards after
admission
This SRS document also has classified the requirements into non-functional and
functional requirements. Functional requirements are directly related to the proposed HIS
software while the non-functional requirements improve the computer system’s functioning
which does not cover the entire HIS.
3
Abstract
The hospital currently has a paper system and requires a system used to store hospital
records in a database and maintaining the HIS. This proposed software will be used to manage
all operations of the hospital which includes; patient address, names of patients, information on
doctors and other staff information. It will also store calculated billing information.
4
Table of Contents
Executive Summary ........................................................................................................................ 2
Abstract ........................................................................................................................................... 3
Revision History ............................................................................................................................. 7
Project Outline ................................................................................................................................ 8
Introduction ................................................................................................................................. 8
Purpose ........................................................................................................................................ 8
Scope ........................................................................................................................................... 9
Document Overview ................................................................................................................... 9
Overall Descriptions ..................................................................................................................... 10
Perspective of Product ............................................................................................................... 10
System Modules ........................................................................................................................ 10
Implementation and Design Constraints ................................................................................... 11
Dependencies and Assumptions ................................................................................................ 11
User Characteristics................................................................................................................... 11
Requirements Elicitation ............................................................................................................... 12
System Stakeholders ................................................................................................................. 12
Techniques and Tools used ....................................................................................................... 14
Summary experience of elicitation ............................................................................................ 14
Requirements Analysis and Specifications ................................................................................... 16
Use Case Analysis ..................................................................................................................... 16
Specific Requirement Analysis Recommendations ............................................................... 16
Functional Requirements Specifications ................................................................................... 18
The Functional Requirements for Doctors ............................................................................ 18
The Functional Requirements for Receptionists ................................................................... 19
The Functional Requirements for Lab Attendants ................................................................ 20
The Functional Requirements for Administrators of the HIS ............................................... 20
The Functional Requirements for inventory/ stores manager ............................................... 21
5
The Functional Requirements for Payroll Module ................................................................ 21
HIS Functional Description ....................................................................................................... 23
HIS Technical issues ................................................................................................................. 32
Operational Requirements ......................................................................................................... 32
Technical Requirements ............................................................................................................ 32
Non-Functional Requirements .................................................................................................. 33
Security .................................................................................................................................. 33
Availability ............................................................................................................................ 33
Performance ........................................................................................................................... 34
Reliability .............................................................................................................................. 34
Reusability ............................................................................................................................. 34
Safety ..................................................................................................................................... 34
Maintainability....................................................................................................................... 34
Use cases and fully dressed use cases ....................................................................................... 36
Extended use case Diagrams ..................................................................................................... 49
Schedule Appointment .......................................................................................................... 49
Admit patient ......................................................................................................................... 49
Discharge patient ................................................................................................................... 50
Give prescription & suggestion ........................................................................................... 50
View patient record ............................................................................................................... 51
File reports ............................................................................................................................. 51
Manage User .......................................................................................................................... 52
Manage Inventory .................................................................................................................. 52
Issue funds ............................................................................................................................. 53
Handle transaction ................................................................................................................. 53
Sequence Diagrams ................................................................................................................... 55
Schedule Appointment .......................................................................................................... 55
Admit patient ......................................................................................................................... 56
Discharge patient ................................................................................................................... 56
Give prescription ................................................................................................................... 57
File reports ............................................................................................................................. 58
6
Give suggestion ..................................................................................................................... 58
Handle transaction ................................................................................................................. 59
Issue funds ............................................................................................................................. 59
Class diagram ............................................................................................................................ 60
Requirements and Quality............................................................................................................. 61
Quality of Software ................................................................................................................... 61
Stakeholders Quality System Interaction Requirements............................................................... 62
Software Interface ..................................................................................................................... 62
Hardware Interface ................................................................................................................... 63
Communications Interface ........................................................................................................ 63
User Interface ............................................................................................................................ 63
Requirements Verification and Validation ................................................................................... 65
Validation .................................................................................................................................. 66
Validation Report .................................................................................................................. 70
Verification................................................................................................................................ 71
References ..................................................................................................................................... 74
Appendix A ......................................................................... Ошибка! Закладка не определена.
7
Revision History
Name
Date
Reason For Changes
Version
HIS Proposal
11/21/13
User Requirements
Draft
HIS SRS
11/24/13
Initial HIS overview
Draft (V 1.0)
HIS SRS
12/2/13
Requirements Elicitation
Rough Draft 1(V 2.0)
HIS SRS
12/09/13
Requirements Analysis and Specification
Rough Draft 2 (V 3.0)
HIS SRS
12/xx/13
Requirements and Quality
In progress
HIS SRS
12/xx/13
Requirements Verification and Validation
In progress
8
Project Outline
Introduction
The SRS for the proposed HIS is prepared after the successful culmination of the
requirement’s analysis. This document follows the IEEE Recommended Practice for Software
Requirements Specifications (IEEE Std 830-1998). Performance and functions allocated to the
software as elements of the SE process are refined to establish complete detailed description of
functions, description of information, system behavior representation, performance requirements
indication and constraint identified at the design phase among other information associated to
requirements. This is a technical requirements specification of the HIS and it describes the
functionality of the proposed system without necessarily describing how the operations are done.
Purpose
The chief reason of this proposed system is to develop a HIS software that will replace
the current paper system and make hospital operational tasks easier. The automated HIS SRS
will guide the developing team of the proposed system. The HIS purpose can be broken down
into the following key point;

Maintaining details for patients

Automation of hospital operations and management

Report generation and billing

Maintaining two user levels; User level and Administrator level

Providing Precautions, Diet Advice and Prescriptions
9

Maintaining and providing patient tests

Payroll system management
Scope
 This document contains both requirement specification statements for non-functional and
functional requirements
 The HIS will capture patient information and save it for future reference
 Reducing pay for overtime and provide service accuracy
 The paper based system currently in use does not have mechanisms for quick data
retrieval and it is too slow.
Document Overview
This SRS document will exhaustively illustrate and define the overall proposed HIS
project requirements which include non-functional and functional requirements. Following
standard Software Requirements Specification practices the document describes functions of the
product, constraints, specific project requirements and the analysis of the specified requirements.
The analysis in this case will include use case diagrams because the final document is primarily a
developer’s tool that defines the design and modeling structure of the HIS. Additionally the SRS
document defines the characteristics of different users and any related identified project
development constraints.
This SRS addresses the overall objective and goals of the proposed system. It will first
illustrate the functions of the system as well as the interfaces. The sections following the
introductory summary of the system’s functionality will systematically address the larger system
10
software and its components. The phases describe specifications identified for every system
module in all aspects of the design of the system’s components.
Overall Descriptions
Perspective of Product
The proposed HIS is a self-contained management system that will be used to organize
and manage patient information among other hospital activities. This HIS will also provide
procedural patient treatment approach as well as details on room allocation, dates of treatment
and billing.
System Modules
The system consists of the following modules that will be integrated for the installation
and implementation of the final HIS. They include;
 Module for Management of Inpatients
 Module for Reception Management
 Payments Module
 Store Module
 Module for Managing Registration of Patients
 Pharmacy Module
 Module for Financial Accounting
 Module to Manage User Accounts
 Radiology Module
 Module for Outpatient Management
 Module for Channeling Services
 Payroll Module
11
 Maintenance Module
 Dental Module
 Module for Reports Generation
Implementation and Design Constraints

Operating System
The environment for development will be windows 7 professional

Database
The open source and free MS SQL database will be used

Web-based
the HIS will be a web based software application

The GUI will be in English only
Dependencies and Assumptions
 The assumptions are that the hospital will have enough trained staff members to
operate and maintain the new system.
 It is also assumed that by the end of the project’s development there will be 70
installed and tested computers.
User Characteristics
The total appearance for this proposed software product should be user friendly with each
system user being issued a password and username for access.
12
Requirements Elicitation
Elicitation of requirements is done through the feasibility study process. The data
elicitation tools and techniques were designed to sufficiently provide information used to make
decisions on the validity of the HIS project. The results of the information gathering determine
whether or not a project should go on with consideration to other existing systems of
management. The collection of requirement specifications from the hospital HIS users was an
important aspect of the study carried out. The overall procedure used to undertake this task is as
follows;

Identification of information sources for different user levels

Identification of user expectations from the new proposed computerized HIS

Analysis of limitations in the current system
System Stakeholders
The requirements elicitation took three approaches to collect information from the
immediate main stakeholders. The identified stakeholders who were actively and directly
involved for this project include had the following characteristics;
Hospital Staff
 The Receptionist – handles doctors’ schedules and consultations as well as patient
registration enquiries. They are also mandated with managing allocations of time slots
and enquiries on doctor consultation fees. Some of the tasks involved at this user module
include;
o Scheduling appointments for doctors
13
o Finding patient historical information as requested
o Scheduling visits to various doctors for patients
o Answering other patient or visitor enquiries
 The Doctors – they update and have access to every patient’s prescriptions, lab test
results/ reports and general scheduled routine checkup information.
 The Lab Attendants – the main responsibility is updating lab result reports for different
patients.
 Administrators – administrators in the system will have the rights to create new users as
well as inspecting the general system performance in their various capacities. The HR
management administrators are in charge of the payroll system and generating pay slips.
 Inventory Manager – the chief responsibility of the inventory manager is updating
medical store information and keeping record of remaining stocks.
Project Development Team
 Project Leader – Managing overall project development process and assigning tasks to
other team members.
 Team Member – Carrying out different project tasks as assigned by the project leader
including requirements elicitation.
 Quality Assurance Manager – ensuring the proposed system is up to quality standards
expected and requested by the client.
14
Techniques and Tools used

Observation – a group from the project development team was sent to the hospital to
observe the daily operational tasks in each level of employment at the hospital. From
observation we could not get detailed requirements from the expected system users.
However, it was important to have an idea of information flow and how information is
channeled between departments (Leffingwell & Widrig, 2003).

Questionnaires – using this data collection tool gave us more insight on the user
expectations and detailed requirements from different user levels (Leffingwell & Widrig,
2003). This is where all technical and functional requirements were gathered. Specific
question leading to specific requirement specification by different users gave an
abstraction of user expectations.

Interviews – one on one interviews with randomly selected departmental representatives
also helped the development get more detailed information on what the client really
required for the proposed HIS system. This gave the analysis and data collection teams
formulate a complete requirements document (Leffingwell & Widrig, 2003).
Summary experience of elicitation
The process of eliciting requirements is essential for the success of the project. It is very
crucial that stakeholders of the business participate in the requirement elicitation actively. The
procedure was carried out with the help of questionnaires, interviews, observations as well as
informal discussions with the entities involved. These entities are hospital medical and nonmedical staff that includes doctors, administrators, patients and lab attendants. Some of the
15
problems experienced by the project team throughout the requirements elicitation process
included;

Not having access to all required staff members when required. It is important that
active stakeholders should be accessible and cooperate with the team clarify their
actual expectations from the project.

It was a difficult task to plan the face to face interviews with nurses and doctors
who have extremely demanding schedules. The interviews were therefore shorter
than expected and provided a sketchy overview of the overall HIS requirements
for both groups. However some of the hospital staff members like stores,
pharmacy and maintenance managers were available to give insightful
information on their expectations in their modules.

The observation exercise took longer than planned because the team members had
difficulty in following the precise movement of staff members and information
through the daily routines. Sometimes because of the high human traffic, it was
also very difficult to stay focused on the agenda.

The use of questionnaires eventually gave better results in gathering the expected
user requirements from all staff members. Each hospital employee in their
different capacities were allowed to carry home their questionnaires and given a
time limit of 2 days to return the completed form. Even though some of the forms
never made it back enough of them did and they provided a good overview of the
HIS requirements.
16
Requirements Analysis and Specifications
Use Case Analysis
Use Case Analysis is used to identify a project’s main user requirements when the system
is observed as a whole. It is basically a high –level depiction of the proposed system’s
functionality. A Use Case may require different sequential steps that individually lead to an
action. Use Cases show the main roles played by key users of the system as well as identifying
ways the system will be used for example the receptionists scheduling an appointment. The
behavioral characteristics of the HIS are described in a convenient way that documents the
supported system functions. The use case models for the different project’s stakeholders are as
explained below. Identified stakeholders include administrators of the database as well as the
overall system, doctors, inventory/ store attendants, lab technicians and receptionists.
Specific Requirement Analysis Recommendations

The system should allow the receptionist to add and update both in and out patient
details as required.

Doctors accessing the system should clearly view their patients’ medical reports
and history with ease. It should equally be simple to add prescriptions and
recommendations.

The medical store attendants will be facilitated with a mechanism to reorder new
stock and update details about suppliers. They will also keep track of overall
medicine usage.

The HIS should run seamlessly on a windows environment.
17

The HR department is also provided with a module to calculate and generate pay
checks for all hospital employees.

Lab technicians will also be able to update and manage lab test results for all
patients with different test recommendations.

Administrators are given the overall responsibility of ensuring smooth transition
and maintenance of the new system after installation.

The system to operate at an optimum level will require the sufficient and effective
management of passwords, protection from viruses and archiving.
The analysis phase provided the project team with a clear picture of the final product’s
functional requirements as specified by the hospital staff during the elicitation of requirements.
The questionnaires provided the most relevant and detailed information used for the final
analysis. Observation and Interviews only provided an insightful overview but not enough data
for a comprehensive use case analysis. The analysis process underwent a few setbacks like time
constraints due to the questionnaires’ sorting and categorizing exercise that preceded the
thorough analysis.
Analyzing the data from the questionnaires required this exercise to have a clear
understanding of the requirements needed for each user group module to be integrated into the
final HIS. It was however difficult to translate some of the user requirement into system
functional procedures. Therefore most of the specified requirements were summarized or
combined into simple tasks. Some of the functionalities in the system will be added and refined
as the project progresses. Overall the process was a success and an example of some of the use
cases developed is discussed below.
18
Functional Requirements Specifications
The Functional Requirements for Doctors
SRS001 Viewing results from labs – doctors use this activity to analyses and view
patient test results from different departments.
SRS002 Medicine Prescription – the patient records will be appropriately updated when
doctors prescribe medicine to them. The updated records are stored in the central repository
database.
SRS003 Patient checkup data updating – this lets the doctor make any necessary
updates to patient records that carry information about their routine checkup history.
Fig. 1 Doctor’s Use Case Diagram
19
The Functional Requirements for Receptionists
SRS004 Scheduling patient visits – the receptionists will also be updating information
regarding schedules for visiting and full time doctors.
SRS005 Scheduling appointments for doctors – all doctors’ appointments with their
patients will be recorded and kept by the receptionists.
SRS006 Finding enquired patient history – this activity in the system will allow the
receptionist to easily find information about different patients’ histories when enquiries are
made.
SRS007 Patient information enquiries – various patient registration enquiries are the
responsibility of the reception desk.
Fig. 2 Use Case Diagram for the Reception Desk
20
The Functional Requirements for Lab Attendants
SRS008 Test report updates – the generation of reports will be facilitated by manual
entry of updated lab results. All generated reports will include precautions and remarks by the
different respective doctors and related to the particular tests done.
Fig. 3 Lab Technician Use Case Diagram
The Functional Requirements for Administrators of the HIS
SRS009 Assigning user rights – the HIS administrators will be responsible for creating
user accounts and grant each of the system users’ access permission accordingly.
SRS010 Performance inspection – the overall inspection of the system is the sole
responsibility of the identified system administrators.
Fig. 4 System Admin Use Case Diagram
21
The Functional Requirements for inventory/ stores manager
SRS011 Maintaining stock of medicine – the manager or attendant of the inventory
module will keep records about medical usage and acquisition. The acquisition process is divided
into donations and purchases as well as maintaining reorder levels. The records will be updated
when new medicine orders are received or when patients buy prescriptions or have the prescribed
medicine delivered to their premises.
Fig. 5 Use Case Diagram for Store Attendant
The Functional Requirements for Payroll Module
SRS012 Managing Employees’ Pay checks – this involves determining the correct
amount due to each employee every month. The system automatically calculates the net salary
with all necessary subtractions and taxations. The administrators or HR clerks in using this
module monitor the working hours recorded for each employee for the entire month on a daily
basis. Salaries are calculated from the worked hours logged into the system.
SRS013 Generating Pay slips – the pay slips for each employee is generated, printed and
delivered accordingly to each employee as the bank transfers are disbursed.
22
Fig. 6 Use Case Diagram for Payroll module
23
HIS Functional Description
Managing the Reception
This is the first stage of interaction for all the people visiting the hospital for various
reasons. This module comprises of information about doctors, patients, departments and all other
hospital activities. The reception module also facilitates for scheduling appointments and
enquiries.
a) Enquiries related to patients;

Patient discharge details

Details for bed, room or ward allotment

Details for patient payments

Details about patient admission
b) Enquiries related to Doctors;

Schedules for operation

Doctor availability details

Scheduling doctor/patient appointments
Registering Patients
Prior to any treatment, consultations or tests all patients are required to get registered.
This process has several inputs which include demographic and other general patient descriptive
information. A unique patient identification number and a registration number are allocated to all
24
successfully accepted and added patients’ details. However, the system will assign the patient a
new patient registration number for every visit while the patient maintains the same patient ID
throughout their subsequent hospital visits. Receipts can be generated from OPD patient details
collected during the patient’s registration charging on consultation fees where applicable. Details
collected from OPD patients to facilitate successful registration include address, name, telephone
number, sex and age among other details like insurance status (Pfleeger S., & Atlee, 2010). The
consultant to be seen and the department are prerequisite for a patient’s registration record.
Managing Inpatients
This module takes care of all tasks regarding inpatients’ management in the hospital. It
automates daily administrative tasks leading to better caring for patients and comprehensive
patient admissions information and ward/ room allocation. This process depends of among other
factors; prior admission booking, availability of rooms/ beds, estimations and emergencies. This
module is responsible for queries such as;

Collections made in advance

Admission of inpatients

Details for discharging patients

Day to day patient progress

Entries from patient visit to consultant

Daily dosages for prescribed drugs
25

Surgery details for the patients

Bed transfer and allocation details

Suggestion or indication of nearing discharge dates for patients

Summarized notifications for patient discharge

Details of the patient’s consultant
Managing Outpatients
The consultation chamber is the next step after successfully registration of a patient.
Consultants then record the patient’s diagnosis, tests, history of previous visits, next visit and
prescriptions (Prokosch, 1995). The patient’s OPD card has the following details noted by the
attending consultant;

Patient History

Medicine or Prescriptions

Tests or Investigations carried out

Advice to patient or pharmacy

Diagnosis

Complaints by patient

Date for next visit where necessary
26
All the above information is then entered into the system by operators at the OPD station
or by the attending consultant. It facilitates for future analysis and research on a patient’s history
of hospital visits. Prescriptions are also recorded.
Channeling Services
Details regarding all outpatient and inpatient appointments are maintained using this
module.
Payments
Significant Inpatient Payment Features;

Final and provisional hospital bills

Payments collection by Debit or Credit cards, Cash, Cheque or on Credit

Managing partial and full payments

Sending payment requests

Automatically determining available patients’ credit limits

Facilitation of patient billing through another account such as a donor or company
account

Additional ambulance charges at the patient’s discharge if necessary
Significant Outpatient Payment Features

Charges for consultations are picked from the system automatically according to
the prevailing emergency or general charges.
27

Defining Credit and Cash OPD patients.

Recording all payments charged to the patient.

Patient categories are used to determine charges for various services which are
automatically picked from the system.

Dispensations as well as dispensation authority details are recorded.

Time of service provided any patient also is a factor considered in picking
charges.

The patient’s ID number will be used to retrieve their details throughout
subsequent visits.

The department overseeing the investigation of patient details receives a copy of
the information recorded.
Inventory/ Central Store
All hospital’s Medicine, Equipment, Implants, Materials, all Assets and Consumables
Inventory are dealt with in this module. The above information is archived along with other
important details such as suppliers and purchase details. Hospital requisitions are sent from the
various departments to the stores managing department (Prokosch, 1995). The stores attendant
then distributes the required equipment/ items or creates orders for purchases accordingly.
Master tables that contain records of items, stock, equipment, purchases, materials and a list of
suppliers are maintained using this module. The module is designed to ensure constant
28
availability of consumables as well as drugs in a seamless mode at all times. The most significant
features in this module include;

Strictly observing the dates of expiry for the Consumables and Drugs

Maintain purchase and supplier details for all for all items

Generate orders for patient requested purchases

Categorizing items into varied clusters

Defining items such that any user will only view departmental related items

LIFO and/or FIFO can be used to issue requested items

Warning for reorder level to maintain different items accordingly

Maintenance of stocks for several sub stores as well as the central store

Maintaining vendor details for all purchased items

Acknowledgement of returned purchases

The sub stores can also return wrong deliveries to the central store
Radiology Module
Scheduling of radiology services and resources is made possible using this module. The
radiology services under this module include Scanning, X-ray and Ultra sound tests. The system
records all tests and generates reports according to the results for both out-patients and inpatients (Pfleeger S., & Atlee, 2010).
29
Reports Generation Module
A user can use this module to view database population reports like;

Hospital reports

Reports for revenues

Patient reports

Reports for payments

Reports on financials

Payment reports

Doctor related reports

Reports from payroll
Financial Accounting Module
The significant features of this module include;

Cost Centre’s user definition

The billing module transfers all revenue related entries automatically to the accounting
department.

Accounts and Ledger groups defined by users

Printing cheques
30

Generating main reports with associated graphs

Maintaining details of income from all departments
Payroll Module
All employees’ deductions, attendance and details of arranged leave as well as generating
pay checks are managed in this module. The main features include;

Salaries are set on wages or monthly basis

Maintaining the complete employees’ record that has details such as demographic data,
salary amount, name of employee, code, designation, ESI and PF accounts

User defined leave’s

Employee records of attendance

Determining final salary as per specified formula

Salary increment application formula

Records of overtime, time in and time out

Details of employees’ long term and short term loans
Pharmacy Module
This module typically deals with issuing of medicine to in-patients and retailed medicine
to out-patients patients. Functions of this module include managing the billing and inventory of
medicines, prescription of drugs online, sutures and consumables. This module works closely
31
with the inpatient and payments module where patient related drugs requests can be indented
from a variety of sub stores (Pfleeger S., & Atlee, 2010). Significant features include;

Automatically billing inpatients

Complete control of out-patient and in-patient details of issuance or purchases in the
pharmacy

Items reorder level maintenance

Checking for expiry dates before approving issuing of drugs

Distributing requested items in accordance to LIFO or FIFO

Classification of drugs either by appearance or content

Acknowledging returns

Transaction details from each vendor are kept
Dental Module
Services provided at the dentists and their details are dealt with in this module. Progress
and treatment reports related to this module are stored for referencing during a patient’s future
hospital dental visits.
Maintenance Module Features

Maintenance of Hospital Wards

Maintenance of Medicines
32

Maintaining Rooms

Maintaining Departments

Maintenance of Services at the Hospital

Maintenance of Doctors
HIS Technical issues
The system will be developed in a Visual Studio 2012 environment with the inclusion of
MS SQL server 2005 for the relational database.
Operational Requirements
The proposed HIS will be expected to be primarily a tool for the receptionist desk which
will need people with competent or moderate skills in computer operations. This is the chief
source of daily data and information that is disseminated to other departments through the central
repository database system. Other users like doctors will only need the system sporadically and
mostly to look at reports and rarely to enter any information or generate reports themselves. The
new HIS is also projected to seamlessly integrate all hospital operations and computerizing daily
routine tasks. Different users will access and modify information from different modules of the
HIS according to their assigned rights. The system should be available around the clock.
Technical Requirements
This HIS will work on MS Windows 7, XP professional and Windows Vista. It will also
be able to run on generic computers running on Windows but cross platform portability is
encompassed into the design of the system. The proposed system will require a menu driven GUI
with a comprehensive help manual for the users. Issues with system initial usage will be covered
33
in the documentation of the help manual which will also assist in new user training on the job.
The system will also be able to calculate payments for patient billing and employees’ salaries.
Non-Functional Requirements
Security
The proposed HIS provides security in a way that the database contents will not be
universally accessible to anyone. Different users will be able to access only what is related to
their daily operations.
 Identification of Patients – patients are required by the system to use their
assigned PHN to identify themselves.
 Rights of Receptionists – staff at the front desk will be able to insert new patients
and view all HIS information but will not be able to change any further associated
patient information henceforth.
 Database Modification – any modifications done to the database (delete, insert or
update) will be synchronized only by the administrator(s).
 Logon ID – all system users will be issued with an appropriate username and
password for system access.
 Rights of Administrators – the system administrators will be able to modify and
view all information held by the HIS.
Availability
 The system is also expected to be available at all times of the day
34
Performance
 Conformity – the new HIS should be conventional to Microsoft Accessibility
 System Response Time – the response time after checking information about
patients should be 2 seconds or less.
 System Capacity – the system is also expected to support 1000 users at any single
time seamlessly without major crashes or downtime.
 User Interface – the user interface screen is designed to respond in under 5
minutes
Reliability
 The general simplicity of the form generation language vs. the form’s
functionality should speed up the development of forms without limiting
functionality.
Reusability
 The code produced should be independently usable elsewhere to develop other
related modules.
Safety
 The detrimental consequences of ordinary human errors have to be limited since
human beings are error-prone. Users should for example be provided with the
choice to go ahead with deletion of data, undo or cancel the action.
Maintainability
 Errors – all system errors should be logged into the system for future reference.
35
 Back up – data backup capabilities shall be provided by the system as required.
36
Use cases and fully dressed use cases
Use case
Schedule Appointment
Actors
Receptionist
Type
Primary
Description:
when an out-patient comes to receptionist or calls from phone and asks to
receptionist for appointment. Then see the schedule of specific doctor and fix a time for
appointment of patient.
Fully Dressed Use Case
Schedule Appointment
fix checkup time with doctor
User goal
Receptionist
Patient, doctor
Login to system
Allocate appointment slip to patient
1. Login to system
2. View schedule of specific doctor
3. Fix appointment
4. Print out appointment slip.
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
View schedule
Register patient
10
Special Req
Receptionist could search all doctor schedules by their name
or id.
37
Use case
Admit patient
Actors
Receptionist
Type
Primary
Description:
when a patient comes to hospital then the receptionist admit him. Patient
may be in-door or out-door. In case of in-door patient would allocated a bed. In case of out-door
patient the patient would get treatment according to schedule
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
10
Special Req
Fully Dressed Use Case
Admit patient
Admit in-door and out-door patient
User goal
Receptionist
Patient
Login to system
Allocate admit slip to patient
1. Login to system
2. Select admit
3. Select indoor/outdoor
4. Register patient
5. Allocate bad
6. Give admit slip to patient
Register patient
Search bed
Allocate bed
Receptionist could search bed by specific ward.
38
Use case
Discharge patient
Actors
Receptionist
Type
Primary
Description:
when a patient gets treatment in the hospital then he will discharge from
hospital. Receptionist will discharge him. Receptionist will create bill for patient according to his
services that he used in hospital.
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
10
Special Req
Fully Dressed Use Case
Discharge patient
Generate bill for patient
User goal
Receptionist
Patient , accountant
Login to system
Allocate bill patient
1. Login
2. Select discharge
3. Select indoor/outdoor discharge
4. Vie services
5. Generate bill
6. Print out bill
View services
Record services
Bill contains details of all services and next visit date
39
Use case
Give prescription
Actors
Doctor
Type
Primary
Description:
After getting registration patient would get treatment from doctor. Doctor
would give prescription to the patient and record in the patient’s record.
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
10
Extensions
Special Req
Fully Dressed Use Case
Give prescription
Record prescription given to patient
User goal
doctor
Patient, nurse
Login to system
Give prescription slip to patient
1. Login
2. Select prescription
3. Entre patient id
4. Record prescription
5. See massage prompt
Wrong patient id
Doctor could record drug prescription and food prescription
separately
40
Use case
Give suggestion
Actors
Doctor
Type
Primary
Description:
when doctor give treatment to the patient he could suggest suggestion may
be for tests, operations and to admit.
Fully Dressed Use Case
Give suggestion
Suggest tests, operation or to admit in hospital
primary
doctor
patient
Login to system
Give suggestion slip to patient
1. Login
2. Select specific suggestion
3. Enter patient id
4. Record suggestion
5. Print out suggestion slip
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
Wrong patient id
10
Special Req
There are separate suggestion slip for admit,
surgery or to admit in hospital.
41
Use case
view patient record
Actors
Doctor, Nurse
Type
Primary
Description:
when doctor give treatment to patient he could see pervious record of the
patient. He could see the reports of different test of the patient. He could see operations details,
previous prescription etc.
Fully Dressed Use Case
view patient record
Doctor could view treatment history
Primary
Doctor
Patient
Login
Get patient record
Login
Select view record
Select specific record
Enter patient id
View record
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
Wrong patient id
10
Special Req
Doctor has different option to view record.
Ex. Last visit, specific visit
42
Use case
File reports
Actors
Nurse
Type
Primary
Description:
when reports of test are generated these reports would give to the nurse who
records these reports. These reports would become the permanent part of the patient record.
Fully Dressed Use Case
File reports
Record test reports, daily reports and operation
details
primary
Nurse
patient
Login to system
Record report
1. Login
2. Select file report
3. Select specific report
4. File report details
5. Prompt message
1
2
Use case name
Scope
3
4
5
6
7
8
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
Wrong patient id
10
Special Req
Report should be detail, Date of report mention
43
Use case
Manage User
Actors
Admin
Type
Primary
Description:
Admit control system. He could create users, update user and delete users.
Update include different tasks like change user name, change password etc. whenever he create a
user he allocate him a user name and password to user.
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
Fully Dressed Use Case
Manage User
Admin manage accounts of different users of system
primary
Admin
staff
Login to system
Update user accounts
1. Login
2. Select manage accounts
3. Select create/delete/update
4. Enter account id
5. Enter admin password
6. Enter data
7. Prompt message
Wrong patient id , wrong admin password
44
Use case
Manage Inventory
Actors
Medical store attendant
Type
Primary
Description:
Medical store attendant manage inventory. He/She could issue inventory on
request of employee. He/She could see current status of inventory. He/She could also purchase
inventory. He/She can see add item in request list. He/She will see request list when he will
going to the purchase inventory.
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
10
Special Req
Fully Dressed Use Case
Manage Inventory
Manage inflow and out floe of inventory
Primary
Medical store attendant
Employers
Login
Record transaction
1. Login
2. Select issue/purchase/request /add item
3. Enter inventory id
4. Enter quantity
5. Prompt message
Wrong inventory id
Inventory not in stock
After transaction prompt message give last quantity of
inventory item.
45
Use case
Manage schedule
Actors
Shift In-charge
Type
Primary
Description:
shift in-charge handle schedule of staff. He allocates duties according to the
rank of doctor, nurses. Doctors and doctor have to follow this schedule.
1
2
3
4
5
6
7
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
8
Success scenario
9
10
Extensions
Special Req
`Fully Dressed Use Case
schedule duties
Allocate duties of doctors and nurses
User goal
Shift In-charge
Doctor, nurses patient
Login
Assign duties
Print out schedule
1. Login in
2. Select nurse/doctor duties
3. Enter id
4. Enter select indoor/outdoor duty
5. Enter ward id
6. Enter time /date
7. Prompt message
Wrong employee id, wrong ward id
Date and time should mention clearly
46
Use case
view schedule
Actors
doctor/nurses / shift in-charge
Type
Primary
Description:
doctor and nurses can view there are schedule in order to perform their
duties. This schedule is maintained by shift in-charge
Fully Dressed Use Case
view schedule
View schedule of duties
User goal
Nurse /doctor
Doctor, nurses
Login
Get schedule
Login in
Select view schedule
Enter date / week/month
View schedule
1
2
3
4
5
6
7
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
Wrong date
10
Special Req
Employee should different to view schedule.
47
Use case
Manage employee record
Actors
Admin
Type
Primary
Description:
when an employee get hire in the hospital. Then admin will record his all
details. Details include bio data, joining date, rank and thumb impression etc. admin could
update record of the employee.
1
2
3
4
5
6
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
7
8
Post condition
Success scenario
9
10
Extensions
Special Req
Fully Dressed Use Case
Manage employee record
Manage all details of employee
User goal
Admin
Employees
Login
Authority letter from higher management
Record employee information
1. Login in
2. Select hire employee/fire employee/update
employee
3. Enter id (not in first case)
4. Enter date
5. Print out information
Wrong employee id
Print out paper include all information
48
Use case
Handle transaction
Actors
Accountant
Type
Primary
Description:
Accountant would handle all transaction. He could collect bills for patient.
He also gives salary to the employees and gives funds for purchasing for inventory.
1
2
3
4
5
6
7
8
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
9
Extensions
Fully Dressed Use Case
Handle transaction
Handle inflow and outflow of cash
primary
Accountant
Employee / patient
Enter issue slip number /bill number
Collect bill / pay cash
1. Login
2. Select inflow/outflow
3. Select salary/inventory/maintain (outflow case)
4. Enter bill/ issue slip number
5. Verify bill/ fund slip
6. Collect bill / pay cash
Verify issue fund slip
Wrong issue fund/bill number
Cash not available
49
Extended use case Diagrams
Schedule Appointment
view schedule
(from included use cases)
<<extend>>
Schedule Appointment
(from HMS)
Receptionist
(f rom HMS)
Admit patient
<<extend>>
<<include>>
Register patient
Verify appoinment
(from included use cases)
Admit outdoot patient
Admit patient
(from extended use cases)
<<include>>
(from HMS)
(from HMS)
Allotment of bed
Admit indoor patient
(from HMS)
<<extend>>
Receptionist
(f rom HMS)
check doctor reference
(from extended use cases)
(from included use cases)
50
Discharge patient
<<extend>>
Generate bill
view patient services
(from i ncl uded use cases)
(from extended use cases)
<<include>>
Discharge out-patient
(from classes )
Discharge patient
(from HMS)
Receptionist
Discharge in-patient
(f rom HMS)
(from classes )
Give prescription & suggestion
<<extend>>
Give drug food prescription
view patient record
(from classes )
(from HMS)
Give prescription
(from HMS)
Give food prescription
(from classes )
<<include>>
Doctor
Refer to Opreate
suggest test
(f rom HMS)
(from i ncluded use cases)
(from classes )
<<extend>>
suggerst surgery
Give suggestion
(from classes )
<<include>>
(from HMS)
Refer to Admit
suggest admit
(from classes )
(from i ncluded use cases)
51
View patient record
view opreation report
(from classes )
Doctor
(f rom HMS)
view old prescription
view daily report
(from classes )
(from classes )
view patient record
(from HMS)
view test reports
Nurse
(from classes )
(f rom HMS)
view report
(from classes )
File reports
File opreation reports
(from classes )
File reports
File daily reports
(from HMS)
(from classes )
Nurse
(f rom HMS)
File test reports
(from classes )
52
Manage User
create user
(from classes )
suspent user
(from classes )
Manage User
(from HM S)
Admin
delete user
(f rom HMS)
(from classes )
update user
(from classes )
Manage Inventory
check avalibility
<<extend>>
(from extended use cases)
issue inventory
(from classes )
Manage Inventory
(from HMS)
stockeeper
(f rom HMS)
Add inventory
(from classes )
53
Issue funds
check funds avability
(from extended use cases)
Issue inventory fund
<<extend>>
(from cl asses )
Issue fund
Issue salary fund
(from HM S)
(from cl asses )
Treasure officer
(f rom HMS)
Issue maintaince fund
(from cl asses )
Handle transaction
Handla bill
(from classes )
Handle salary transaction
(from classes )
Handle transaction
(from HMS)
Handle funds
(from classes )
Accountant
Handle inventory transaction
(from classes )
<<include>>
(f rom HMS)
Handle maintaince transaction
(from classes )
verify fund
(from i ncl uded use cases)
54
Schedule Appointment
Receptionist
(from HMS)
(f rom HMS)
Admit patient
Discharge patient
(from HMS)
(from HMS)
Doctor
(f rom HMS)
Give prescription
(from HMS)
Nurse
view patient record
(f rom HMS)
(from HMS)
Give suggestion
(from HMS)
File reports
Admin
(from HMS)
(f rom HMS)
Handle transaction
(from HMS)
Accountant
(f rom HMS)
Manage User
(from HMS)
stockeeper
Manage Inventory
(f rom HMS)
(from HMS)
Treasure officer
(f rom HMS)
Issue fund
(from HMS)
55
Sequence Diagrams
Schedule Appointment
: schedule
: Receptionist
view schedule
doctor schedule
enter appoiment
conformation of appoinment
: appoiment
56
Admit patient
: admit
: Receptionist
: patient
: indoorAdmit
req.admit
register
(for indoor admit)
details
(for outdoor admit)
details
admit conform
conform admit
patient id
Discharge patient
: discharge
: Receptionist
: patient
enter pat-id
verify patient
conform patient
Allow discharge
enter discharge detail
conform discharge
: outdoorAdmit
57
Give prescription
: patient
: prescription
: Doctor
req prescription
verify patient
conform patient
Allow prescription
enter prescription
confrom prescription
58
File reports
: Report
: Nurse
enter patient_id
: patient
verift patient
conform patient
allow report
enter report details
confrom report
Give suggestion
: suggestion
: Doctor
: patient
req suggestion
verify patient
conform patient
Allow suggestion
enter suggestion
complete suggestion
59
Handle transaction
: Accountant
: tranction
req tnanc
: Bill
: Funds
(for in tranctions)
verfy patient
conform
(for out tranction)
conform
allow tranction
enter tranction
complete tranction
Issue funds
: Funds
: Treasure officer
req fund
Allow funds
enter fund
complete fund
: staff
verift employer
conform
: patient
60
Class diagram
61
Requirements and Quality
Quality of Software
Quality Management Plans are sets of planned activities that help during the project’s
planning and development phases to ensure quality is achieved. The main purpose of a QMP is
focusing on the activities that will bring customer satisfaction regarding their quality
expectations. The company delivering the service or product defines the Quality Assurance tasks
basing the process upon its set quality standards. In this case, Our Lady of Mercy Hospital will
be dependent on the efficiency and seamless interaction of the new proposed HIS to provide
quality services to its patients.
Therefore the system’s ability to deliver on the specified requirements optimally is
essential for the successful completion of this project. An example is the warning mechanism
incorporated into the stores management module. If there are any malfunctions in this module
then the hospital runs the risk of going out of stock for certain drugs and/ or consumables or
distributing expired products. Slow operation or downtime at the receptionists’ desk can also
create a long queue of angry patient waiting to be checked in. Some patients will often formulate
their own assumptions on the expected quality of service from a single situation like this.
There are several metrics that could be considered during Quality Management Planning
by the project team and they include;
a) Customer Satisfaction – this metric is used to indicate perceived real world quality of
services and products. Service metrics for customer satisfaction may represent the ratio of
complains per unit survey. It uses customer suggestions to plan for future quality
improvements.
62
b) Outcome Metrics – this is the service or product’s end result and it measures the overall
quality. Combined events and factors are the basis of this metric which include; number
of complaints received and service completion time.
c) Promotion and Innovation – the innovation metric encourages working teams to refresh
their service approach. After distinguishing between impractical and practical methods,
they use the promotion metric to measure how well they have sold their idea to the target
public.
d) Cost Indices – these are used to measure the cost of quality for businesses. They indicate
whether sufficient quality control measures are in place or otherwise. Cost indices may
include negative publicity costs from a poorly produced product or service reflecting also
on lost opportunities.
Stakeholders Quality System Interaction Requirements
Software Interface
The new Hospital Information System needs to run on Windows OS and interface with
the SQL database server. Other software interfaces required for the system include browsers like
Internet Explorer or Mozilla Firefox. The use of standard regular OS and browsers as an
interaction platform allows for ease of system operation, access and navigation. The windows
GUI technology is a good tool for encapsulation of object classes in OO programming.
63
Hardware Interface
The HIS is expected to be functioning at an optimal level on desktops running on
windows OS that interface with network printers. The keyboard and mouse will be the supported
devices used for input of data into the system. The computers are required to have at least 80 GB
of Hard disk space, over 1GB of Ram and a Dual-Core processor 2.3GHz. This will facilitate
faster responses from the system. The receptionists will be the busiest system users and the need
to have a good computer with high processing capabilities will help in better data capturing and
retrieval.
Communications Interface
The proposed HIS requires internal communication protocols that will automatically be
mounted on the Windows OS. This will enable the ease of networking the computers used with
the system and thus better peer to peer communication or communication to other network
devices like network printers. There will be no need for a separate installation of the two main
protocols which are;
 TCP/IP and
 HTTP protocols.
 Windows as the primary display
User Interface
User Interfaces facilitate the interaction of the users with the intended system and
entering data into the designated database. Users input information that is saved in the database
and use it to generate various reports.
64
 Different criteria will be used for both the search facility and verification of stock
 The proposed HIS provides an easy to use and straight forward GUI (Graphical
User Interface) for the system users to perform required hospital activities
effectively
 Allowing users to view various generated reports and ensuring the entire system
screens will include a facility for help
65
Requirements Verification and Validation
The process of Validation and Verification of requirements entails reviewing of a
predefined checklist used to evaluate a system’s correctness of its desired attributes. The goal of
verification and validation is the discovery and early resolution of high-risk issues in the
development of software projects. Developing new software products sometimes may require the
testing and documentation of various software parts. This is done to ensure the project is
proceeding as intended.
Fig. 7 Verification and Validation in a simple SDLC
66
Verification deals with establishing the complete correspondence of the proposed
software product and the specified requirements. Validation on the other hand seeks to establish
the worth of the system with regard to its operational requirements. The main informal questions
answered by these two processes are;
Validation – “Are we building the correct product?”
Validation can be defined as the checking of a software product’s design to establish
whether it satisfies the intended functions. This seeks to determine the closeness to real life
application of the product being developed according to the set standards (Torp, 2003).
Validation ensures that predetermined data formats are fully satisfied and the correct criterion for
input is complied to. Only real or true data is allowed for entry and storage into the system
database. The proposed Hospital Information System (HIS) software validation plan has three
main dimensions;
1. Operational Validity – it is the behavioural subjective evaluation of the software
development model.
o Sensitivity of Model: this refers to the degree to which the stability of a model can
be affected by small parameter changes on the data
o Improvement Degree: how robust the results of the model turn out due to the
suggested improvements. A 60 percent performance improvement on a system
may suggest insignificant error impacts
o Model Implementation Ability: the model should have the ability to produce
adoptable practical results
2. Technical Validity – this is the comparison made against rational criteria sets.
67
o Validity of Model: this refers to the degree the system will represent real
situations. To accomplish this following procedure will be implemented.

Vet and make a clear list of assumptions made casually and mathematical
content.

Develop the system’s conceptual model

All elements and boundaries in the system to be clearly defined

Vet the assumptions and the model with both technical experts and content
experts
o Validity of Data: this refers to the level to which used data for decision making
instances represents real situations. This will cover the following;

Identification of sources of the data

Identification of the actual data that will be needed to successfully
complete the validation process

Identification and correcting of aggregated data through the initial analysis

Conducting test to basically determine reasonability of data

Validity of data statement development
o Logical Validity: this refers to the correctness of the translated computer code
from the intended theoretical system model. The success of this process depends
on the following elements.

Using available tools like debuggers, compilers and trace elements in
when developing the software

Scepticism and assuming the system is not correctly done and building
correction testing elements for the model
68

Using content professionals to check the system throughout the
developmental cycle and conducting a comprehensive structured system
walk through with the help of technical specialists.

Developing the system model using the evolutionary approach by building
and testing individual small system modules.
o Validity of Predictability: this is the checking for the system’s conformity through
produced results. This is achieved through the following;

Comparing the existing system’s actual output against the simulation

Comparing the known system performance theories against the simulation
3. Dynamic Validity – this defines the system’s utility over time.
o Process of Updating: this refers to the completeness and accuracy of the periodic
process of updating the parameters in the model
o Maintainability: the simplicity that changes can be made on the model over a
period of time
o Process of Reviewing: this is the ensured checking and reviewing of a system’s
conformity to reality periodically
69
Fig. 8 Validation process Flowchart
70
Validation Report
Documentation of all activities during the validation of any software project may seem
like an overwhelming task but it is important. However this exercise will be reasonably easy if
the recommendations provided in this validation plan are keenly followed. The two activities
associated with validation during software projects are;

Initial Work: this involves summarizing and/or specifying the user requirements,
managing the design phase and the actual project development, making the test
validation plan, precaution documentation and installation preparation. Finally planning
for the maintenance process. Signing and dating all activities and documents is a must.

Testing and Peer Reviewing: this involves the reviewing of documents concerning the
process of validation, installation and testing. All resulting actions and documents from
these processes should also be signed and dated.
This HIS software is intended to handle vital procedures in terms of whom, when, why
and where that are applied for the duration of the operation of the HIS. Traceability of these
events all through the development cycle of the HIS is also very important and should be
included in the validation report. Signing approved requirements should be done before
designing commences (Torp, 2003). Tests should be carried out after the signing of approved
test specifications. Another important aspect is the identification of key persons that are
authorized to sign the approved reports. Other major elements include;
 Testing the product should be carried out by other people who are not directly involved in
the development process.
 The authors of the documents should not be the approving authority.
71
 The acceptance testing of the system should not be carried out by the development team
but rather the system owners.
Verification – “Are we building the product correctly?”
Verification is a complex and broad software engineering discipline that seeks to
guarantee satisfaction of the expected software’s requirements. The verification plan process for
this HIS will follow two key approaches;
 Static Verification – this process also known as analysis is useful in determining
the correctness of project software. It is however common to have false positives
when using this procedure. This process usually checks for the physical bugs that
include;
o Detecting bad coding practices
o Formal verification
o Verification of code conventions
o Calculating metrics in software
 Dynamic Verification – also known as experimentation, this process is used
during a project’s execution to find bugs through dynamic system behavioral
checks. The tests scope are categorized into three expandable families;
o Small Testing – which is a test used for unit testing to check a single class
functions
o Large Testing – this testing is used to check groups of function classes like
integration testing for more than one module, single module testing and
the entire system testing.
72
o Testing for Acceptance - this test is formally used to check for the criteria
for a project software testing. It includes non-functional and functional
testing to determine performance stress levels.
Test cases are verification tools used to determine right software product development
process. They are also used in validating the user requirement specifications.
Traceability Matrix
A TM (Traceability Matrix) is a table used to trace requirements to their verification test
cases and determine if the user specifications have been properly met. Good traceability matrix
tables should be bidirectional in that one should be able to trace a test to user requirements and
vice versa. A TM is also used for Quality Assurance to ensure the clients get the correct product
as requested (Periyasamy, 2013).
Benefits of Traceability Matrix Tables
 Ensure developers only create requested program features
 Making it obvious to the customer that the specified requirements have been fulfilled
 Ease of identifying functionalities that are missing from the final product
 Knowing which test cases to update if requirement change requests are made by users
73
Project Name:
Project
Description:
REQUIREMENTS TRACEABILITY MATRIX
Our Lady of Mercy HIS
Hospital Information System
Payroll
Use Case ID /
Req #
SRS005
SRS001
SRS007
SRS013
Central Store
SRS014
Functional Module
Reception
Scheduling appointments for doctors
Admission of inpatients
Patient information enquiries
Generating Pay slips
Test
Case_ID
TC-1
TC-1.1
TC-1.3
TC-2
TC-3
TC-3.1
Success
Failed
Req Description / Use Case Description
Remarks
Success
Success
Success
Success
Pharmacy
SRS011
Maintain purchase and supplier
details for all for all items
Maintaining stock of medicine
Reports Generation
SRS018
SRS019
Patient reports
Doctor related reports
TC-4
TC-4.1
Success
Success
Payments
Radiology
SRS016
SRS008
Final and provisional hospital bills
Test report updates
TC-5
TC-6
Failed
Success
74
References
Blum, B. I. (1986). Clinical information systems. New York: Springer-Verlag.
IEEE recommended practice for software requirements specifications. (1998). New York, NY:
Institute of Electrical and Electronics Engineers, Retrieved from
http://math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
Leffingwell, D. & Widrig, D. (2003). Managing Software Requirements-A User Case
Approach,2nd Ed. Addison-Wesley.
Periyasamy, J. (2013, April 21). Traceability matrix in software testing Software Testing
Tutorials - Manual and Automation Questions Answers, Retrieved from
http://www.jobsnewstoday.com/2013/04/what-is-traceability-matrix-in-software-testingwhy-it-is-needed.html
Pfleeger S., and Atlee J. (2010), Software Engineering Theory and Practice. New York, Prentice
Hall, pp. 1–44
Prokosch, H. U. (1995). Hospital information systems: design and development characteristics,
impact and future architecture. Amsterdam: Elsevier.
Torp, C. E. (2003). Method of software validation. NT TECHN REPORT , (535), doi: TR 535
Download