lOMoARcPSD|39659544

Software Requirement
Specification

For

<Health Care Record System>

Prepared by <Sakchi>

<Lovely Professional University>

<Reg No:-12306084>

<Submitted To:-Manish Kumar

Sharma >
 lOMoARcPSD|39659544

TABLE OF CONTENTS

CHAPTER 1: INTRODUCTION.........................................................................................................................................1
1.0 INTRODUCTION ...................................................................................................................................................2
1.1 PURPOSE .............................................................................................................................................................. 2
1.2 PROJECT SCOPE ....................................................................................................................................................2

1.3 PROBLEM STATEMENT..........................................................................................................................................3

1.4 INTENDED AUDIENCE ...........................................................................................................................................4

1.5 REFERNCES ........................................................................................................................................................... 4

CHAPTER 2: OVERALL DESCRIPTION .............................................................................................................................5

2.0 PROJECT PERSPECTIVE .........................................................................................................................................5
2.1 PROJECT FUNCTION .............................................................................................................................................5
2.2 USER CLASSES AND CHARACTERISTICS ................................................................................................................6

2.3 OPERATING ENVIRONMENT................................................................................................................................7

2.4 DESIGN/IMPLEMENTATION CONSTRAINTS..........................................................................................................7

2.5 ASSUMPTIONS AND DEPENDENCIES....................................................................................................................7

CHAPTER 3: EXTERNAL INTERFACE REQUIREMENTS ...................................................................................................8

3.0 USER INTERFACE ...................................................................................................................................................8
3.1 HARDWARE INTERFACE ........................................................................................................................................8
3.2 SOFTWARE INTERFACE.......................................................................................................................................... 8

3.3 COMMUNICATION INTERFACE..............................................................................................................................8

CHAPTER 4: SYSTEM FEATURES ....................................................................................................................................9

4.0 SYSTEM OVERVIEW ................................................................................................................................................9
4.1 USE CASE SCENARIOS...........................................................................................................................................10
4.2 ACTIVITY DIAGRAM ..............................................................................................................................................12

CHAPTER 5: OTHER NON-FUNCTIONAL REQUIREMENT ............................................................................................13

5.0 PERFORMANCE REQUIREMENT ...........................................................................................................................13
5.1 SAFETY REQUIREMENT ........................................................................................................................................13
5.2 SOFTWARE QUALITY ATTRIBUTES........................................................................................................................13

5.3 PROJECT DOCUMENTATION ................................................................................................................................14

5.4 USER DOCUMENTATION ......................................................................................................................................15

 lOMoARcPSD|39659544

INTRODUCTION

1. Introduction:
The rapid growth in Information & Communication Technology (ICT), and the
power of Internet has strongly impacted the business and service delivery
models of today>s global environment. E-Medix Health Care Record Systems
for campus provides students and staffs the benefits of streamlined operations,
enhanced administration & control, superior patient care and improved
profitability. Hospital Management Systems are in high demand to handle
increasing population needs and also aids the practicing doctors and hospital
service and support staff with timely service and precision. There are varied
metrics available to assess the performance of services like hospital industry,
and the successful implementation and usage of Hospital information system
forms a crucial role. The E-Medix system in campus will provide
comprehensive, effective and efficient solution for carrying out management of
hospitals and clinics fulfilling the needs and requirements of all stakeholders
such as doctors, patients and staffs.
1. Purpose:
An E-Medix System is a software designed to manage all the areas of university
hospital such as medical, administrative and the corresponding processing of
services.
2. Project Scope:
This software system will be a Health Care Record System for a university
campus clinic system. This system will be designed to maximize the clinic?s
productivity by
providing tools to assist in automating the patient?s data and appointment
process, which would otherwise have to be performed manually. By
 lOMoARcPSD|39659544

maximizing the clinic?s work efficiency the system will meet the clinic?s needs
while remaining easy to understand and use.
More specifically, this system will be designed to allow a patient (i.e staffs and
students) register from any location remotely. After registration, the patient is
expected to book an appointment in the clinic in order to carry out some test
which will be used by the nurse to complete the patient?s registration. The
software will facilitate communication between patients, and admin.
Daily functions like staff and student registration, booking appointments,
medical emergencies within the campus can be easily performed with higher
accuracy after the installation of the E-Medix software. The modules of the
software are intended to be user-friendly and easy to access.
1.3 Problem Statement:
The Healthcare Centre deals with the life and health of a patient which is very
important. A standard Healthcare Centre must have well-trained doctors,
nurses, pharmacists, high quality equipment and also a good record system. The
conventional system which is the existing system includes the use of paper
work which has quite a lot of disadvantages over the advantages due to the
issues it comes with which then led to the implementation of this new system
and these problems include:
i. Difficulty in retrieving and finding patients information: In the
conventional system, the user has to go through a lot of registers in other
to find patients information which results to wastage of time.
ii. Difficulty in updating patients? information: Due to the paper work
involved in the conventional way, it is very difficult to make changes.
iii. Inaccurate reports and case note: in the conventional way, Doctors write
case notes in papers and this can be easily misinterpreted by the nurse or
pharmacy when prescription is to be made.
 lOMoARcPSD|39659544

With all these, it is important to introduce this automated and efficient health
Care Record management software as it helps to prevent or completely eradicate
the above problems and also ensure that its administration runs smoothly.
1.4 Intended Audience
The intended audience of this document is the student/staff and specific
employees of the student clinic like the doctor on or off duty, the
nurses/pharmacist, and the admin of the system. The SRC document is used in
any case regarding the requirement of the project and the solution that have
been taken. The document will also provide the necessary information needed
and also guild and give a clear idea of the building of the system.

INTENDED AUDIENCE TYPE DESCRIPTION

The student and staff Primary end-user of the
system
The Doctor End-user of the system
The Nurses End-user of the system
The Admin Administrator user of the
system
The Laboratory End-user of the system
The Pharmacist End-user of the system
Uses system to book appointments
and request emergency service
Have access to registered student
information and uses the System to
access to prescribe to patient, can
write the diagnosis of the student
and send it to the student portal
Have access to registered student
information and uses the system to
manage patient?s vital signs
Manage Users of E-health system
Have access to registered patient
and uses the system to conduct lab
test and write the lab report to the
database.
Have access to registered patient
and uses the system to view
prescribed drugs given to the
patient. .

1.5 References
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software
Requirements Specifications. IEEE Computer Society, 1998.
 lOMoARcPSD|39659544

OVERALL DESCRIPTION
1. Product Perspective
Many hospitals follow manual procedures to keep track of its day to day
activities. When scenarios such as patient information handling, employee
handling, stock handling, financial analysis and report generation is taken into
consideration there exists many issues with regard to efficiency, security,
accuracy and reliability. Due to improperly managed details hospitals faces
quite a lot of difficulties in accessing past data as well as managing present
data. The manual file systems which are being used at present require storage
facilities which are also another overhead.
The fully functional automated hospital management system which will be
developed through this project will eliminate the disadvantages caused by the
manual system by improving the reliability, efficiency and performance. The
usage of a database to store patient, employee, stock details etc. will
accommodate easy access, retrieval, search and manipulation of data. The
access limitations provided through access privilege levels will enhance the
security of the system. The system will facilitate concurrent access and
convenient management of activities of the hospitals.
1. Product Function
Consultation Management
• Recording patient details
• Accepting appointments according to doctor schedule
• Adding patient report with medical prescription
Patient Management
• Patient details
• Patient?s medical history
 lOMoARcPSD|39659544

• Progress report
• Medicine?s details
Emergency Treatment
• Emergency patient Details
Pharmacy Stock Management
• Drug stock management
• Expiry notification
• Searching
Lab Management
• Record sample collection details
• Lab resources management
• Lab report conclusion generation
• Lab equipment stock management
2. User classes and Characteristics
Admin
Admin has the full access to the system which means he is able to manage any
activity with regard to the system. He is the highest privileged user who can
access to the system.
Key functions
✓ Manage employees and patient
✓ Allocate resources
✓ Administer the charges
✓ Manage ambulances
✓ Manage doctors
Clinic Staffs
 lOMoARcPSD|39659544

The clinic staffs interact with the systems most often to supply service to the
patients.
Key functions
✓ Keep track of patient details
✓ Keep track of test details
✓ Make ambulance reservations
✓ Keep track of progress of patients
✓ Manage inventory
3. Operating Environment
Software Requirements
● Windows 7 or above operating system
● Flutter 3.0.0
●Firebase Server
Hardware Requirements
● Core i5 processor
● 4GB Ram
● 20GB of hard disk space in the developing computer
● 1TB cloud database
4. Design/Implementation Constraints
● System is wirelessly networked with an encryption
● System is only accessible to student and staffs of Elizade University only.
● Database is password protected.
● Each user should have individual ID and password.
● Only the administrator can access the whole system.
5. Assumptions and Dependencies
● Each user must have a valid user id and password
● Server must be running for the system to function
 lOMoARcPSD|39659544

● Users must log in to the system to access any record.

● Only the Administrator can delete records.

CHAPTER THREE – EXTERNAL INTERFACE REQUIREMENTS

1. User Interfaces
The user interface is designed in an interactive and user friendly manner which
makes it easier for the user to understand and relate with the application.
1. Hardware Interfaces
The user interface will use android/ IOS operating system and the purpose is to
display the user interface and process information.
2. Software Interfaces
Developing end: Flutter, Visual studio Code, Firebase, Lucid
Client end: Android or IOS
3. Communication Protocols and Interfaces
WIFI module - It is a computer hardware component that allows a computer to
connect to a network.
 lOMoARcPSD|39659544

SYSTEM FEATURES
4.0 System Overview

Fig 4.1 System Environment

 lOMoARcPSD|39659544

4.1 Use Case Scenarios

Name Add Patient Entry

Description This function gets details of a patient and add record to the patient file
and generate a patient registration number
Actors Nurse, Patient
Pre-conditions The operator should login with user account
Main flow of events
1. User selects <add patient entry <at home page
2. Patient entry form displayed
3. User enter data to required fields
4. User selects <Add entry= button
5. <Successfully record added= message displayed.
6. System generates a patient Id and display.

Extensions If necessary fields left by user, it prompt user to enter all required
fields.
Post conditions Patient record added to patient file.

Name Add Prescription entry

Description This function records patient?s prescription details
Actors Pharmacist
Pre-conditions Doctor?s prescription bar must be issued.
Main flow of events 1. User selects <Prescription form= from patient module
2. System prompts to enter patient?s registration number
3. Prescription form displayed with relevant patient details.
4. User navigates to >medicine? field and enter medicine details.
5. User selects Add button and add prescription details.

Name Add Patient Report

Description This function adds patient?s diagnosis report to the system.
Actors Doctor
Pre-conditions Patient must register to the system
Main flow of events 1. User selects patient diagnosis card
2. System prompts patient Id
3. User enters patient Id
4. System display patient details in the form
5. User enter diagnosis details and date
6. User selects add diagnosis record.
 lOMoARcPSD|39659544

Post conditions The diagnosis report should add to the patient report history.

Name Generate lab report

Description This function generates the report of a particular test and saves
the report
Actors Laboratory Personnel
Pre-conditions User should login
Relevant lab test results should be available
Main flow of events 1) user selects lab report form from lab tests module
2) system prompts patient id
3) user enter patient id
4) system display patient details
5) system prompts to selects lab test category
6) user selects category by navigating to relevant tab and enter
test results
7) user selects add lab test record
8) system display successfully added message
9) user selects save report
10) system saves the report

Name Book Appointment

Description This function manages the booking of
appointment
Actors Patient, Nurse, Doctor
Pre-conditions User should login to the system
Main flow of events 1. The patient user views the available time
2. The patient user picks a time and clicks on
>book appointment?
3. The nurse user accepts or rejects patient
appointment.
 lOMoARcPSD|39659544

4.2 Activity Diagram

Fig 4.2: Activity Diagram

 lOMoARcPSD|39659544

OTHER NON-FUNCTIONAL REQUIREMENT

1. Performance Requirements
• Response time- the system is expected to have a high response time when
the user of the system accesses different functions in the system.
• Capacity-The system is expected to store all records of the registered user in
its database.
• User interface- User interfaces are expected to have a high response time to
be able to meet deadlines.
• Conformity –The system must conform to the Microsoft accessibility
2. Safety Requirements
All the administrative and data entry operators have unique logins, so the
system can understand who is logging in to system and makes sure no intruder
is allowed except system administrative. Therefore nobody can change record
and valuable data.
2. Software Quality Attributes
▪ AVAILABILITY: The system shall be available all the time.
▪ CORRECTNESS: Bug-free software which fulfills the correct requirements
of the client.
▪ MAINTAINABILITY: The ability to maintain, modify information and fix
problems of the system
▪ USABILITY: software can be used again and again without distortion.
▪ ACCESSIBILITY: Administrator and many other users can access the
system but the access level is controlled for each user according to their
work scope.
▪ ACCURACY: The reliability on the information/output. Can depend-on/be
sure of the outcome.
 lOMoARcPSD|39659544
▪ STABILITY: The system output won?t change time to time. Same output
will be given always for a given input.
5.3 Project Documentation
Software Life Cycle Documentation
Phase
Requirement Gathering, ▪ Project charter
Analysis and Specification ▪ Project proposal
▪ Software Requirement
and Specification
(SRS) which includes
▪ Entity relational
diagram
▪ Data flow diagrams
▪ Use case diagrams
▪ Use case scenarios
Software Design ● Software Design
Description (SDD)
Implementation ● Technical Documentation
Software Testing ● Software Test
Documentation (STD)
Intended Activities
Includes the customer
expected software features,
constraints, interfaces and
other attributes. Moreover, the
objectives and the benefits
gained through the system are
clearly specified
Describes the logical basis of
design decisions taken and
how it will pave way in
acquiring the requirements of
the customer through the
software
Contains information
regarding the implementations
of the system using the
programming concepts
Includes information
regrading testing procedures
to validate and verify the
software results. Main types of
 lOMoARcPSD|39659544

testing techniques are unit

testing, integration testing,
system testing and acceptance
testing
Maintenance ● User Documentation Includes manuals for the end
users according to their
position of access levels

5.4 User Documentation

As a part of the system itself, user documentation is provided to the customers
which gives an overview of the system. It will include the full description about
the product and complete orderly followed steps to install the software. The
users will get the opportunity to use the system without having any trouble. The
user manual will include the email addresses to contact us in need. Tasks are
listed alphabetically or logically grouped often using cross referenced indexes
which helps the users to know exactly what sort of information they are looking
for.