SOFTWARE REQUIREMENTS

SPECIFICATION
(SRS DOCUMENT)

for

HMS
Version 1.0

By
Team member 1 Registration no
Team Member 2 Registration no

Supervisor/Professor
Name
Contents
1. Introduction ........................................................................................................................................... 4
1.1 Purpose.......................................................................................................................................... 4
1.2 Data Convention ........................................................................................................................... 4
1.3 Intended Audience ........................................................................................................................ 4
1.4 Scope ............................................................................................................................................. 4
1.5 References. .................................................................................................................................... 4
2. Overall description ................................................................................................................................ 5
2.1 Product perspective ....................................................................................................................... 5
2.2 Product features ............................................................................................................................ 5
2.2.1 Registration ................................................................................................................................... 5
2.2.2 Reception Module ......................................................................................................................... 5
2.2.3 Admin ........................................................................................................................................... 5
2.2.4 Pharmacy....................................................................................................................................... 6
2.3 User Classes and Characteristics................................................................................................... 6
2.4 Operating Environment ................................................................................................................. 7
2.5 Design and implementation constraints ........................................................................................ 7
CO-1: The system shall use the open source tools................................................................................... 7
2.6 Assumptions and Dependencies.................................................................................................... 7
3. Specific Requirements .......................................................................................................................... 8
3.1 Use Case Diagram: ........................................................................................................................... 8
3.2 Detailed Use Cases and DFD’s: ........................................................................................................ 9
3.2.1 Schedule Appointment ...................................................................................................................... 9
Level 1 DFD.................................................................................................................................................. 9
3.2.2 View Patient Report ....................................................................................................................... 10
Level 1 DFD................................................................................................................................................ 10
3.2.3 Search Appointment........................................................................................................................ 11
Level 1 DFD................................................................................................................................................ 12
3.2.4 Manage Staff ................................................................................................................................. 14
Level 1 DFD................................................................................................................................................ 14
4. External Interface ................................................................................................................................ 16
4.1 User Interface: ................................................................................................................................. 16
4.2 Hardware Interface:......................................................................................................................... 16
4.3 Software Interface: .......................................................................................................................... 16
5. Non Functional Requirements ............................................................................................................ 16
Performance ............................................................................................................................................ 16
 Usability .................................................................................................................................................. 16
Maintainability ........................................................................................................................................ 17
6. Other Requirements ............................................................................................................................ 17
6.1 Security: .......................................................................................................................................... 17
6.2 Correctness:..................................................................................................................................... 17
1. Introduction
1.1 Purpose

The online healthcare system will be used by hospitals, clinics and other medical centers to
manage every aspect of their patient's management. This software substitutes the tasks which a
hospital staff member would usually perform by allowing patients to schedule their own
appointments, to check the result of their laboratory tests and to permit doctors to manage
appointments and records of patients. The acquisition, management and timely recovery of large
amounts of information constitute a significant part of the operation of every hospital. Typically,
this includes: patient personal information and medical history, staff information, the schedule
of rooms and offices, staff schedules, scheduling of operation theatre and different waiting lists
of facilities. All this information must be effectively managed and cost-effectively in order to
make effective use of institutional resources our healthcare system automates hospital
management to improve efficiency and to prevent errors. The objective is to standardized data,
to consolidate data integrity and reducing data leakage and human errors.

1.2 Data Convention

Dashboard: A dashboard is the panel for any system which contains tools as softwares to
monitor and deploy services.
Dedicated Server: A dedicated server is a single computer in a network reserved for serving
the needs of the network

1.3 Intended Audience

For developers, health care providers, healthcare administration, patients, testing and
documentation authors, this software is very useful.

1.4 Scope
This web based medical system provides patients, system manager/admin and doctors with the
option of scheduling and managing their appointments, managing patient records, managing
medical records from their own homes and offices using the latest technology. Our health care
system is able to do many tasks which are interdependent, including patients and doctors.
There are four user interfaces for our system: the patient interface, the physician's interface and
the admin interface, the staff member interface.
The software has 4 types of users in our system: • Doctor • Administrator • Staff • Patient.

1.5 References.
 Software Engineering: A Practitioner’s Approach, Seventh Edition, 2010 [3]
 Software Engineering, Ninth Edition, Ian Sommerville, 2011 [4]
 Web Based Project Management System, Anne-Mai Adamson, 2010.
 2. Overall description
2.1 Product perspective
Our Health Care software is intended to use in order to improve medical treatments and
make it easy for healthcare workers to store patient history and make appointments online
etc. A wide range of similar products are already available on the market. Most of these
business applications are very general and are intended to cover any possible business.
Though these products still exist, hospitals still spend considerable time and money on
managing patient data and scheduling appointments etc. The reason for this is that hospital
requirements differ greatly from those of other companies. Our health care system is an
online application tailored to the needs of a hospital.

2.2 Product features

Following are the main features of our healthcare system.

2.2.1 Registration

This module allows patient information to be recorded and IPD and OPD patient Inquiries
to be handled. After registration, a unique ID is produced for each patient. This helps to
manage customer relationships and maintains the patient's medical history.

2.2.2 Reception Module

In this module, the patient is asked for the details of admission and discharge, bed count
and the movement of the individual patient inside the hospital. Fixed-cost patient deals
and consulting and scheduling services, Doctoral Advisory Fees as well as time
allotments can also be handles by the system.
 Doctor visit schedule

 Doctor Appointment Scheduling

 Enquiry of Patient

 Find History of Patient Enquired.

2.2.3 Admin

This module provides all main hospital entry details such as consultation details,
specialization of the doctor, consultancy fees and service fees.
 Employee Detail Recording.

 Doctor Type

 Doctor Master

  Referral Doctor

2.2.4 Pharmacy
All medical items are covered in this module. This module supports Item Master, Drugs
receipts, problem handling, material return, retail bill generation, inventory maintenance.
It also helps to meet both IPD and OPD Pharmaceuticals requirements.

2.3 User Classes and Characteristics

In our healthcare system we have three main users i.e. patients, doctors, admin. Following
are the main functionalities and characteristics of them.

1) Patients: Patients shall be able to:

 Edit Personal information
 Create his/her account
 Consult his/her appointments
 Book an appointment
 Cancel an appointment
 Search medicine
 Order new medicine
 View Report

2) Doctors: Doctor shall be able to:

 Create his/her account
 Edit Personal information
 Add new patient
 Add or remove patient medical record
 Manage medicine stock
 Add or remove Lab tests record
 Cancel appointments
 Schedule special appointments
 Edit his/her profile. Meaning s/he will be able to change his/her address, etc.
She/he can also make changes to his/her schedule, for example, set vacations,
days off, etc.
 3) Administrators: Administrator will be able to:
 Activate or deactivate a doctor
 Configure employee catalogs
 Configure departments
 Configure employees in a department
 Create an doctor’s account
 Manage medicine record
 Add, remove or update medicine and lab test

2.4 Operating Environment

OE-1: The System shall operate correctly with the following web browsers: Firefox
versions 28 through 48; Google Chrome (all versions); and Apple Safari versions 8.0
through 11.1.

OE-2: The system shall use MYSQL database for storing and maintaining record of the
health care patients, doctors and their appointments etc

2.5 Design and implementation constraints

CO-1: The system shall use the open source tools.

CO-1: The system should work on any internet browser with GUI whether the underlying
Operating System is Windows.

2.6 Assumptions and Dependencies

Following are the assumptions and dependencies for our software system:

 Usability: It is assumed that all user web pages should be in accordance with
standardized colors and fonts. The users will receive on-the-spot instructions on the step
in the presentation of the Web pages.

 User Request: The database of the system will manage without default a maximum of
50 users.

 Requirements: It is assumed that requirements will not change for the software project
over time
3. Specific Requirements

3.1 Use Case Diagram:

Following is the overall use case diagram of our system.
 3.2 Detailed Use Cases and DFD’s:
3.2.1 Create Appointment

Level 1 DFD

Use Case ID: UC-01

Use Case Name: Create Appointment
Actors: Patient (primary)
Description: In this use case patient shall be able to create his/her medical checkup appointment by clicking the
schedule button
Trigger: User clicks on the “create appointment” button.
Preconditions: PRE-1. User is logged in the system.
Postconditions: POST-1. System books the user appointment
Normal Flow: 1. User logins into the system.
2. User navigates through his/her dashboard.
3. User clicks on the create appointment
4. User fills the form
5. System check availability of the doctor
6. System books the patient appointment if doctor is available.
Alternative Flows: N/A
Exceptions: 5 In step 5 of the normal flow if the doctor is not available in the specific date of the appointment
1. System shall prompt user to book appointment on another day
2. User books the appointment on another day
3. Appointment created successfully.
Business Rules N/A
Assumptions 1. User has internet connection.
2. User has a registered account
Unit Testing 1: Create Appointment
Testing Objective: To ensure that the create appointment functionality is working properly.
Test Case Id: TC_01
Test Case Description: To test the create appointment functionality.
Test Scenario:
No. Test Case/Test Test Data Expected Actual Pass/Fail/Not
Script Result Result Executed/
Suspended
1. Verify create Appointment name: System creates System shows Pass
appointment Regular checkup the user the success
works properly by Appointment date: 06-09- appointment message
clicking on the 21 “appointment
‘create’ button Patient name: John Doe created
and entering Patient medical card no: successfully”
correct data in the 123456
form
2. Verify create Appointment name: retjkd System shows System Pass
appointment checkup the error generates the
works properly by Patient name: message message “ fill
clicking on the Appointment date: the required
‘create’ button Patient medical card no: fields”
and entering no
data in the form or
incorrect data

3.2.2 View Patient Report

Level 1 DFD
Use Case ID: UC-02
Use Case Name: View Patient Report
Actors: Patient (primary)
Description: In this use case patient shall be able to view report of his/her checkup, lab reports etc.
Trigger: User clicks on the “reports” button.
Preconditions: PRE-1. User is logged in the system.
Postconditions: POST-1. System schedules the users appointment
Normal Flow: 1. User logins into the system.
2. User navigates through his/her dashboard.
3. User clicks on the report tab
4. System opens a new window with list of all reports record of the patient
5. User clicks on the report s/he wants to view
6. User views the s/he report.
Alternative Flows: N/A

Exceptions: N/A
Business Rules N/A
Assumptions 1. User has internet connection.
2. User has a registered account

Unit Testing 3: view Patient Report

Testing Objective: To ensure that the view report appointment functionality is working properly.
Test Case Id: TC_03
Test Case Description: To test the view appointment functionality.
Test Scenario:
No. Test Case/Test Test Data Expected Actual Pass/Fail/Not
Script Result Result Executed/
Suspended
1. Verify view report System display Report details Pass
works properly by the details of the displayed
clicking on the report succesfully
‘view ’ button of a
report

3.2.3 Search Appointment

 Level 1 DFD

Use Case ID: UC-03

Use Case Name: Search Appointment
Actors: Doctor (primary)
Description: In this use case doctor shall be able to search his/her appointments record of the patients by date,
name, patient.
Trigger: User clicks on the “search” button.
Preconditions: PRE-1. User is logged in the system.
Postconditions: POST-1. User searched the appointment successfully by name, patient or date.
Normal Flow: 1. User logged in the system.
2. User navigates through his/her dashboard.
3. User clicks on the advance search option
4. User type the appointment name and click search button
5. System displays the appointment details if it is available
Alternative Flows: 4a In step 4 of the normal flow if the user enters the appointment date instead of name
1. System searches the appointment with date and shows data if available

4b In step 4 of the normal flow if the user enters the patient name instead of appointment name, or
date
1. System searches the appointment with date and shows data if available
Exceptions: N/A
Business Rules N/A
Assumptions 1. User has internet connection.
2. User has a registered account

Unit Testing 4: Search Appointment

Testing Objective: To ensure that the search appointment functionality is working properly.
Test Case Id: TC_04
Test Case Description: To test the search appointment functionality.
Test Scenario:
No. Test Case/Test Test Data Expected Actual Pass/Fail/Not
Script Result Result Executed/
Suspended
1. Verify search Appointment name: System searches System shows Pass
appointment by Regular checkup and shows the the
name works by appointment appointment
clicking on the record record
‘search’ button
and entering
correct
appointment name
2. Verify search Appointment name: retjkd System shows System Pass
appointment by checkup the message “ generates the
name works by no result found” message “ no
clicking on the result found”
‘search’ button
and entering
incorrect
appointment name
that doesn’t exist
3. Verify search Patient name: John doe System shows System display Pass
appointment by the list of all the list of
patient name recent appointment
works by clicking appointment of for the john doe
on the ‘search’ john doe
button and
entering correct
data
3. Verify search Patient Name: test demo System shows System Pass
appointment by the message “ generates the
patient name no result found message “ no
works by clicking result found”
on the ‘search’
button and
entering incorrect
appointment name
that doesn’t exist
4. Verify search Date: 06/09/21 System shows System Pass
appointment by the list of displays the list
date works by appointment on of all
clicking on the this date. appointment on
‘search’ button this date
and entering a
date
 3.2.4 Manage Staff

Level 1 DFD

Use Case ID: UC-04

Use Case Name: Manage Staff
Actors: Admin (primary)
Description: Admin shall be able to manage the record of healthcare staff members. S/he can update, add, delete
a record of staff.
Trigger: User clicks on the “manage staff” tab
Preconditions: PRE-1. User is logged in the system.
Postconditions: POST-1. User manages the staff record successfully. System allow him/her to edit, delete. Create
staff member record.
Normal Flow: 1. User logged in the system.
2. User navigates through his/her dashboard.
3. User selects the one of the options delete, add, update record
4. System add, delete, or update the record.
Alternative Flows: N/A
Exceptions: N/A
Business Rules N/A
Assumptions 1. User has internet connection.
2. User has a registered account

Unit Testing 5: Add Staff

Testing Objective: To ensure the Add Staff form is working properly.
Test Case Id: TC_05
Test Case Description: Test the Add Staff functionality.
Test Scenario:

No. Test Case/Test Test Data Expected Actual Pass/Fail/Not

Script Result Result Executed/
Suspended
1. Verify that after Id:1 Success Success Pass
click on the ‘Add First name: John message is message is
Staff’ button adds Last Name: Doe shown shown “Staff
New Staff Department: accounts member added
member with Phone: 99998789 successfully”
correct input data Address: test demo
in the form Gender: Female
Dob: 1997-03-06
2. Verify Add Satff Id: Error Message Empty fields Pass
works after click First name: is shown are highlighted
on the ‘Add Last Name:
Employee’ button Department:
and adding staff Phone:
form with empty Address:
data. Gender:
Dob:

Unit Testing 6: Delete Staff

Testing Objective: To ensure the Delete Staff form is working properly.
Test Case Id: TC_06
Test Case Description: Test the Delete Staff functionality.
Test Scenario:

No. Test Case/Test Test Data Expected Actual Pass/Fail/Not

Script Result Result Executed/
Suspended
1. Verify Delete Page is loaded Page is Pass
Staff works with fresh data. reloaded after
properly after the desire staff
clicking on the data deleted
‘Delete’ icon

Unit Testing 7: Edit Staff

Testing Objective: To ensure that the Edit Staff form is working properly.
Test Case Id: TC_07
Test Case Description: To test the Edit staff functionality.
Test Scenario:
No. Test Case/Test Test Data Expected Actual Pass/Fail/Not
Script Result Result Executed/
Suspended
1. Verify Edit Staff Id:1 Success System Pass
works by clicking First name: John message is generate
on the ‘Update’ Last Name: Doe shown Success
button on Edit Department: HR message
Employee form Phone: 99996868 “Record
with correct input Address: 78j Updated
data. Gender: Female successfully”
Dob: 1997-03-06

4. External Interface
4.1 User Interface:
The system shall be very easy to use as it will provide will provide buttons, search bar, tool
bar menu bar, tabs etc. By clicking the correct buttons, and options from menu user can
manage the records easily.

4.2 Hardware Interface:

 64 bit processor
 Minimum 8GB RAM
 1TB Hard Disk

4.3 Software Interface:

 Database: MySQL
 Browser: Chrome, Opera, Firebox
 Operating System: Windows.

5. Non Functional Requirements

Performance
PER-1: The average response time per every user click shall be less than 4 seconds. And
the maximum average time per every click shall be less than 6 seconds.

Usability
USE-1: The system user interface shall be user friendly. i.e. the minimum amount of time
taken by novice user to learn the system shall be 15 minutes.

Maintainability
Main-1: The system can make new changes on the basis of the requirements, if demanded
after completion of the system. The maintainability of the system can be done by integrating
new modules and offering new solutions for the raised problems.

Reliability

REL 1: The system shall have less than 6 hours downtime per two months
REL 2: Maximum Bugs per 1000 lines should not be greater than 9.

6. Other Requirements
6.1 Security:
 The system requires user authentication. Users should not be able to set up or delete
other users' reservations. In order to implement these constraints, a track of each user's
reservations is necessary.
 Personal data collected at the time of registration for the sake of privacy should not be
disclosed. A user only needs to know if a certain slot is or is not reserved without the
patient's name being revealed.

6.2 Correctness:
The system should be correct for all algorithms; that means, they need to be carried out if
necessary. By testing all possible cases and matching their results to the documentation the
testing phase ensures the correctness of the software.