Professional Documents
Culture Documents
2k19 Co 408 Oose Lab File
2k19 Co 408 Oose Lab File
INDEX
EXP.NO
5
Write the Software Requirement Specification Document
of the case study
18
Design use case diagram of the case study
20
Write use case description of your case study.
29
Draw Class Diagram of your case study.
35
Draw Collaboration diagram of your case study.
37
Draw Activity diagram of your case study.
10 44
Design Test Cases of your case study.
EXPERIMENT – 2
AIM: Draw the Initial Requirements Document (IRD) of the case study i.e.
“Hospital Patient Management System (HPMS)”.
Version 1.0.00
● Collect patient fees & Maintain patients fee record and Generate
list of the patients who haven’t paid the fee for Finance Team
● 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.
● The system generates reports on the following information:
patients, bed availability and staff schedules after every six
hours.
EXPERIMENT – 3
AIM: Write the Software Requirement Specification Document of the case study i.e.
“Hospital Patient Management System (HPMS)”.
2. Overall Description
2.1. Product perspective
2.1.1. System Interfaces
2.1.2. User Interfaces
2.1.3. Hardware Interfaces
2.1.4. Software Interfaces
2.1.5. Communication Interfaces
2.1.6. Memory Constraints
2.1.7. Operations
2.1.8. Site Adaptation Requirements
3. Specific Requirements
3.1. External Interface Requirements
3.1.1. User Interfaces
3.1.2. Hardware Interfaces
3.1.3. Software Interfaces
3.1.4. Communication Interfaces
1. Introduction
1.1 Purpose
The purpose is to describe all the requirements for the Hospital Management System. The
following are some of the stake holders:
• administrative staff
• doctors
• nurses
• surgeons
• developers.
The hospital management and its team members uses this document 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. However only the requirements that appear in this document or a
future revision, will be used to define the scope of the system.
1.2 Scope
The software product is the Hospital Management System. The system will be used to
allocate beds to patients on a priority basis, and to assign doctors to patients in designated
wards as need arises. Doctors will also use the system to keep track of the patients assigned to
them. Nurses who are in direct contact with the patients will use the system to keep track of
available beds, the patients in the different wards, and the types of medication required for
each patient. Doctors must make rounds to pick up patients’ treatment cards in order to know
whether they have cases to treat or not. The intentions of the system are to reduce over-time
pay and increase the number of patients that can be treated accurately. Requirements
statements in this document are both functional and non-functional.
1.4 References
a) Lauesen, S, (2003),Task Descriptions as Functional Requirements, IEEE Computer
Society,Available:http://www.itu.dk/~slauesen/Papers/IEEEtasks.pdf
1.5 Overview
This Software Requirements Specification (SRS) is the requirements work product that
formally specifies Hospital Patient Info Management System (HPIMS). It includes the results
of both business analysis and systems analysis efforts. Various techniques were used to elicit
the requirements and we have identified your needs, analyzed and refined them. The
objective of this document therefore is to formally describe the system’s high level
requirements including functional requirements, non-functional requirements and business
rules and constraints. The sections of the SRS document that lies ahead are: Overall Description,
Specific Requirements and Supporting Information.
2. Overall Description
2.1. Product Perspective
The HPMS is a software developed for registration of patients and generating their
final reports. It is also responsible for ensuring smooth process of consultation for the
patients. It
makes life easy for the people running the hospital as two very big tasks that is
manual
registration and report generation with the help of the software. It also takes care of
database.
(a) Login: to allow the entry of only authorized patients/doctors through valid login ID and
password.
(b) Patient Details: to maintain database of patients.
(c) Report Details: to maintain patient reports.
(d) Bed Details: to make beds available for patient to avail.
(e) Complaint Registration: to register a complaint if any anomaly is found.
• Laptop/Desktop PC
➢ core i5 processor
➢ 4GB RAM
➢ 500GB HDD
Purpose of this pc is to give information when Patients ask information about doctors,
medicine available lab tests etc. To perform such Action, it needs very efficient computer
otherwise due to that reason patients have to wait for a long time to get what they ask for.
• Display Unit (LED/LCD Monitor/TV)
This unit is for display the channel number when the patients come to see their
consultants. It will avoid chaos. And also display Hospital welcome screen, video,
information etc.
• Laser Printer (B/W)
Simply this device is for printing bills and view reports.
• Wi-Fi router
Wi-Fi router is used to for internetwork operations inside of a hospital and simply data
transmission from pc’s to sever.
2.1.7 Operations
None
Registration: When a patient is admitted, the front-desk staff checks to see if the patient is
already registered with the hospital. If he is, his/her Personal Health Number (PHN) is
entered into the computer. Otherwise a new Personal Health Number is given to this patient.
The patient’s information such as date of birth, address and telephone number is also entered
into computer system.
Consultation: The patient goes to consultation-desk to explain his/her condition so that the
consulting nurse can determine what kind of ward and bed should be assigned to him/her.
There are two possible circumstances:
a) If there is a bed then the patient will be sent to the bed to wait for the doctor to come.
b) If there is no bed, the patient is put on a waiting list until a bed becomes available.
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.
The system will be used in the hospital. The administrators, doctors, nurses and front-desk
staff will be the main users. Given the condition that not all the users are computer-literate.
Some users may have to be trained on using the system. The system is also designed to be
user-friendly. It uses a Graphical User Interface (GUI).
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).
Nurses: All nurses have post-secondary education in nursing. Some nurses are computer
literate. Consulting nurses to whom patients give short descriptions of their conditions are
also 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
Doctors: All doctors have a medical degree. Some have further specialized training and are
computer literate. Doctors will use the system to check their patient’s list.
2.4 Constraints
• The system must be delivered by deadline.
• The system must be user-friendly
3. Specific Requirements
This section contains the software requirements in detail along with the various forms to be
developed.
The HPMS will have the following user-friendly and menu-driven interfaces:
(a) Login: to allow the entry of only authorized patients/doctors through valid login ID and
password.
(b) Patient Details: to maintain database of patients.
(c) Report Details: to maintain patient reports.
(d) Bed Details: to make beds available for patient to avail.
(e) Complaint Registration: to register a complaint if any anomaly is found.
• Laptop/Desktop PC
➢ core i5 processor
➢ 4GB RAM
➢ 500GB HDD
Purpose of this pc is to give information when Patients ask information about doctors,
medicine available lab tests etc. To perform such Action, it needs very efficient computer
otherwise due to that reason patients have to wait for a long time to get what they ask for.
• Display Unit (LED/LCD Monitor/TV)
This unit is for display the channel number when the patients come to see their
consultants. It will avoid chaos. And also display Hospital welcome screen, video,
information etc.
• Laser Printer (B/W)
Simply this device is for printing bills and view reports.
• Wi-Fi router
Wi-Fi router is used to for internetwork operations inside of a hospital and simply data
transmission from pc’s to sever.
3.2.2 Consultation
• Assign Ward
The consulting nurse shall use system to assign the patient to an appropriate ward.
• Assign to Waiting List
The consulting nurse shall use system to assign Patient to a waiting list if no bed is
available.
• Surgery case
In a surgery case, the administrative staff shall use system to assign a surgery room,
surgeon and nurses to the patient.
• Generate Report (normal)
The system shall generate the patient’s situation record every two hours for normal
patients.
• Generate Report (Severe)
The system shall generate patient’s situation record every half hour for severe
patients.
• Record procedure
The whole treatment procedure for the patient shall be recorded by the system.
• Inform patient
The system shall automatically inform the patients who are on the bed waiting list of
available beds whenever they become available.
3.2.6 Database
• Patient Mandatory Information
Each patient shall have the following mandatory information: first name, last name,
phone number, personal health number, address, postal code, city, country, patient
identification number.
• Update Patient Information
The system shall allow the user to update any of the patient’s information
• Search for Patient
The system shall allow the user to search for patient’s information by last name or
PHN or patient ID.
• Staff Mandatory Information
Each staff in hospital shall have the following mandatory information: identification
number, first name, last name, phone number, address, postal code, city, country,
employee type, duty schedule.
• ACCESSIBILITY: Administrator and many other users can access the system but
the access level is controlled for each user according to their work scope.
EXPERIMENT – 4
AIM: Design use case diagram of the case study i.e. “Hospital Patient
Management System (HPMS)”.
Theory:
A use case diagram is a representation of a user’s interaction with the system
that shows the relationship between the user and different use cases in which the
user is involved. A use case diagram is used to represent the dynamic behavior
of a system. It encapsulates the system’s functionality by incorporating the use
cases, actors and their relationship. It models the tasks, services and function
required by a system/subsystem of an application. It depicts the high-level
functionality of a system and also tells how the user handles a system.
A use case diagram is typically used to portray the dynamic aspects of a system.
It gathered the system needs, depicted external view of system, recognized the
internal as well as external factors that influenced the system and represented
the interaction between actors.
1) Actors: The users that interact with a system. An actor may be a person,
an organization or an outside system that interacts with application or
system and they appear outside the rectangle.
2) Use Case: It is a list of actions or event steps, typically defining the
interactions between a role/actor and a system, to achieve a goal. These
use cases are represented within rectangle providing functionality.
3) Relationships: It is basically a solid line that describes the relationship
between actors and use case or between the use cases.
EXPERIMENT – 5
AIM: Write use case description of your case study i.e. “Hospital Patient
Management System (HPMS)”.
Introduction: This use case allows the user to access the system.
Actors:
Patient
Doctor
Admin
Precondition: The user must have their login id and password with them.
Postcondition: If the use case is successful, the user is granted access to the
system.
Event Flow:
Basic Flow
1. The user enters his/her login id and password.
2. The user’s login id and password are matched with the system’s database.
3. The user’s credentials match and he is granted access of the system.
Special Requirements:
None
Associated use cases:
All other use cases are executable only after this login use case.
Introduction: This use case allows the user to check the doctor’s available.
Actors:
Patient
Precondition: The user must have their login id and password with them.
Postcondition: If the use case is successful, the user is given the information if the
Doctor is available.
Event Flow:
Basic Flow
The user gets the access to the list of available doctors available in the database.
Special Requirements:
None
Introduction: This use case allows the user to access the list of available
appointments.
Actors:
Patient
Precondition: The user must be logged into the system before the use case begins.
Event Flow:
Basic Flow
The user gets the access to the list of available appointments available in the database.
Special Requirements:
None
Introduction: This use case allows the users to book and appointment for meeting
a doctor.
Actors:
Patient
Precondition: The user must be logged onto the system before the use case begins.
Event Flow:
Basic Flow
The users enter the required details for booking an appointment which is to be maintained. Then
details of registration are updated in the database and maintained by the administrator.
Special Requirements:
The details entered by the users should be in prescribed format (data handling).
Introduction: This use case allows the Patient and the Administrator to manage
appointments.
Actors:
Administrator
Patient
Precondition: The patient and the administrator must be logged onto the system before the use
case begins.
Postcondition: If the use case is successful, details of the appointment can be viewed and updated
by the Patient and the Administrator.
Event Flow:
Basic Flow
The patient/administrator enter their login details. Now they can update their appointment timings.
Special Requirements:
The details entered by the patient/administrator should be in prescribed format (data handling).
Introduction: This use case allows the admin to view all the user’s within the database
Actors:
Administrator
Precondition: The administrator must be logged onto the system before the use case begins.
Postcondition: If the use case is successful, details of all the patients are
successfully viewed by the administrator.
Event Flow:
Basic Flow
The administrator logs into the system and views the records of all the patients.
Special Requirements:
None
Introduction: This use case allows the doctor and the administrator to view
all the appointments for a specific doctor.
Actors:
Administrator
Doctor
Precondition: The doctor and admin must be logged onto the system before the use case begins.
Event Flow:
Basic Flow
The administrator/doctor enters the app and view their appointments.
Special Requirements:
None
Introduction: This use case allows the user to the doctor to file medical reports.
Actors:
Doctor
Precondition: The doctor must be logged onto the system before the use case begins.
Event Flow:
Basic Flow
The administrator/data entry operator enters the required details of patient’s report which is to be
maintained.
Special Requirements:
None
Introduction: This use case allows the doctor to update/delete patient records
Actors:
Doctor
Precondition: The doctor must have their login id and password with them.
Postcondition: If the use case is successful, the patient record is deleted.
Event Flow:
Basic Flow
1. The doctor enters his/her login id and password.
2. The doctor’s login id and password are matched with the system’s database.
3. The doctor’s credentials match and he is granted access of the system.
4. Now as the doctor clicks the delete button, the patient’s record is deleted
Alternative Flow 1: Unauthorized doctor
If the system does not validate the doctor’s login id or password (due to user not being in the system
or user entering wrong credentials), then an error message is flagged and the use case returns to the
beginning of the basic flow.
Alternative Flow 2: User exits
This allows the doctor to exit at any time during the use case. The use case ends.
Special Requirements:
None
EXPERIMENT – 6
AIM: Draw Class Diagram of your case study i.e. “Hospital Patient
Management System (HPMS)”.
Theory:
The class diagram represents a static view of an application. It depicts the types
of objects residing in the system and the relationships between them. A class
consists of its objects, and also it may inherit from other classes. This diagram is
used to visualize, describe, document various different aspects of the system,
and also to construct executable software code.
It comprises of class names, attributes, and functions in a separate compartment
that helps in software development. Since it is a collection of classes, interfaces,
associations, collaborations, and constraints, it is termed as a structural diagram.
The main purpose of class diagrams is to build a static view of an application. It
is the only diagram which is widely used for construction, and also it can be
mapped with object-oriented languages. It is one of the most popular UML
diagrams.
Hospital Management System Class Diagram helps in describing the structure
of a Hospital Management System classes, their attributes, operations (or
methods), and the relationships among objects. The main classes of the Hospital
Management System include Hospitals, Patient, Doctors, Prescription,
Appointments, Medicines.
Class Diagram:
EXPERIMENT – 7
AIM: Draw Sequence diagram of your case study i.e. “Hospital Patient
Management System (HPMS)”.
Theory:
Sequence Diagram:
a) Login:
b) Appointment:
c) Register/Admit Patient:
e) Discharge:
EXPERIMENT – 8
AIM: Draw Collaboration diagram of your case study i.e. “Hospital Patient
Management System (HPMS)”.
Theory:
Following are some of the use cases enlisted below for which the collaboration
diagram is implemented:
Collaboration Diagram:
EXPERIMENT – 9
AIM: Draw Activity diagram of your case study i.e. “Hospital Patient
Management System (HPMS)”.
Theory:
• Control flows: Another name for the connectors that show the flow
between steps in the diagram.
• Start node: Symbolizes the beginning of the activity. The start node is
represented by a black circle.
• End node: Represents the final step in the activity. The end node is
represented by an outlined black circle.
Activity Diagram:
a) Login
b) Booking Appointment
c) Register Patient
d) Ward Allocation
f) Discharge
EXPERIMENT – 10
AIM: Design Test Cases of your case study i.e. “Hospital Patient Management
System (HPMS)”.
Theory:
Test cases are integral part of any testing activity. The creation of test cases and
executing them when the source code is available ensures that a robust, defect
free and high quality system is constructed. Testing is very important and
essential activity that continues throughout the software development life cycle.
• Test case: A test case may execute a particular path of the program or verify
a given requirement of the system. A test case consists of inputs given to the
program and its expected outputs from the program.
• Test suite: A test suite consists of set of test cases. Test suite may consist of
set of successful test cases and set of unsuccessful test cases.
• Test design and procedure: Test design and procedure consists of detailed set
of instruction for setting, designing and interpreting the results for a given
test case.
• Test coverage: Test coverage defines the extent to which the test cases are
covered by a given test for a given use case, class or system.
• Test results: Test results are a repository in which all the results and data
produced during the execution of a program are kept.
Test Cases:
1. LOGIN
4. WARD ALLOCATION
7. DISCHARGE