Software Requirements

Specification

for

<Project>

Version <X.X>

Prepared by

Group Name: <place your group name here>

<name> <student #> <e-mail>
<name> <student #> <e-mail>
<name> <student #> <e-mail>
<name> <student #> <e-mail>
<name> <student #> <e-mail>

Instructor: <place your instructor’s name here>

Course: <place your course name here>

Date: <place the date of submission here>

Software Requirements Specification for <Project> Page ii

Contents
CONTENTS........................................................................................................................................................ II

REVISIONS........................................................................................................................................................ II

1 INTRODUCTION........................................................................................................................................ 1
1.1 DOCUMENT PURPOSE.......................................................................................................................... 1
1.2 PRODUCT SCOPE................................................................................................................................ 1
1.3 INTENDED AUDIENCE AND DOCUMENT OVERVIEW...............................................................................1
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS...................................................................................1
1.5 DOCUMENT CONVENTIONS.................................................................................................................. 1
1.6 REFERENCES AND ACKNOWLEDGMENTS..............................................................................................2
2 OVERALL DESCRIPTION........................................................................................................................ 2
2.1 PRODUCT OVERVIEW........................................................................................................................... 2
2.2 PRODUCT FUNCTIONALITY................................................................................................................... 3
2.3 DESIGN AND IMPLEMENTATION CONSTRAINTS......................................................................................3
2.4 ASSUMPTIONS AND DEPENDENCIES..................................................................................................... 3
3 SPECIFIC REQUIREMENTS.................................................................................................................... 4
3.1 EXTERNAL INTERFACE REQUIREMENTS................................................................................................ 4
3.2 FUNCTIONAL REQUIREMENTS............................................................................................................... 4
3.3 USE CASE MODEL............................................................................................................................... 5
4 OTHER NON-FUNCTIONAL REQUIREMENTS....................................................................................6
4.1 PERFORMANCE REQUIREMENTS.......................................................................................................... 6
4.2 SAFETY AND SECURITY REQUIREMENTS.............................................................................................. 6
4.3 SOFTWARE QUALITY ATTRIBUTES........................................................................................................ 6
5 OTHER REQUIREMENTS........................................................................................................................ 7

APPENDIX A – DATA DICTIONARY............................................................................................................... 8

Appendix B - Group Log..................................................................................................................................... 9

Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Type Full Name Information about the revision. This table does 00/00/00
and not need to be filled in whenever a document is
Number touched, only when the version is being
Software Requirements Specification for <Project> Page iii

Version Primary Author(s) Description of Version Date Completed

upgraded.
Software Requirements Specification for <Project> Page 1

1 Introduction
Modern hospitals, such as Al Hayat Hospital in Bahrain, face increasing challenges in providing
efficient and patient-centered care due to the limitations of outdated systems. The healthcare
sector requires solutions that integrate seamlessly with contemporary practices, offering
advanced functionalities such as telemedicine, real-time inventory management, and patient
portals for enhanced interaction and accessibility. This project proposes the development of a
cloud-based, integrated Hospital Management System (HMS) designed to overcome the
deficiencies in Al Hayat Hospital's current system.

1.1 Document Purpose

This SRS document describes the features and attributes of the proposed cloud Hospital
Management System for Al Hayat Hospital which is a functional and non-functional requirements.
The document enables an understanding of what the system is capable of doing as well as the
purpose of the system and the parties engaged.

The HMS described in this document is on operational interoperability, administrative efficiency,

and the quality of the patient and staff experience. Ignotovala functions like a patient portal that
can be easily accessed and utilized by the patients for their convenience, secure telemedicine for
patients, automatic billing system and analytically enhanced service delivery to overcome the
existing operational shortcomings. This SRS states the major functions of the system which
include; patient management, appointment, and billing, telemedicine system, inventory control,
and security measures. In this case, it acts as a reference to the development team in order to
deliver the right solution for a hospital that will meet its requirements, but also the standards set
by the regulatory authorities.

1.2 Product Scope

The specific hospital described in this paper is the Al Hayat Hospital in the Kingdom of Bahrain;
the proposed HMS is a cloud-based software solution aiming at bringing improvements in the
organization’s performances and its relations with its clients, the patients. This system will
manage and link several modules that will range from patient admission, appointment, electronic
medical records, charging, supplies, telemedicine, and archiving modules. The functionalities
specified in the model are to be integrated in a single, easy to operate platform that the hospital
HMS currently lacks – thereby solving the outstanding inefficiencies, lessening the manual labor
required, and facilitating decision making based on data analysis.

The advantages of the system include; Patient satisfaction through appointment booking and
medical record access, efficiency through automated workflows and effective compliance with
regulation. Objectives of the HMS include:

 Improving accessibility: Enabling patient and staff care access through a cloud-based
secure portal for patient and staff virtual interaction.
 Optimizing resources: It has to do with cutting down on many operations costs ,say, in
managing inventories in the hospitals, the staffing levels, and even the bed space
availability.
 Enhancing healthcare delivery: Providing telemedicine care consultations and making sure
that the patient data is available for timely decisions by the physicians.
 Data-driven insights: Enhancing a means for the initiation of next-generation analytics of
hospitals’ performance and entire enhancive appraisal.
Software Requirements Specification for <Project> Page 2

1.3 Intended Audience and Document Overview

This document is intended for a wide range of stakeholders involved in the development,
evaluation, and use of the proposed Hospital Management System (HMS) for Al Hayat Hospital
in Bahrain. The intended audience includes:
1. Developers: To understand the system requirements and specifications for designing and
implementing the HMS.
2. Project Managers: To oversee the project and ensure alignment with the client’s goals
and timelines.
3. Testers: To use the requirements specified in this document as the basis for designing
and executing test cases.
4. Documentation Writers: To create user manuals, training materials, and other supporting
documents.
5. End Users: Including hospital staff (doctors, nurses, administrative personnel) and
patients, to gain insights into how the system will meet their needs.
6. Client (Hospital Management): To evaluate the system's scope, features, and benefits to
ensure it aligns with the hospital’s objectives.
7. Academic Reviewer (Professor): To assess the completeness, clarity, and relevance of
the document as part of the evaluation process.
8. Document Overview
This Software Requirements Specification (SRS) document outlines the technical and functional
requirements for the HMS. It is organized into the following sections:
 Section 1: Introduction: Provides an overview of the project, document purpose, product
scope, and intended audience.
 Section 2: Overall Description: Explains the product’s functionality, system environment,
and user characteristics.
 Section 3: Specific Requirements: Details the functional and non-functional
requirements of the HMS.
 Section 4: Diagrams: Includes data flow and use case diagrams to illustrate system
processes.
 Section 5: Conclusion: Summarizes the key points and highlights the system’s expected
impact.
 References: Lists all the sources referenced throughout the document.
9. Suggested Reading Sequence
Readers are advised to follow this sequence:
1. Client/Professor: Begin with the Introduction (Section 1) for an overview, then review the
Overall Description (Section 2) and Specific Requirements (Section 3) for a detailed
understanding.
2. Developers and Testers: Focus on Specific Requirements (Section 3) and Diagrams
(Section 4) for system design and testing needs.
3. Project Managers: Start with the Introduction (Section 1) and then focus on the Overall
Description (Section 2) to understand project scope and requirements.
4. Documentation Writers: Review the entire document for detailed insights into the
system’s functionality and purpose.
Software Requirements Specification for <Project> Page 3

1.4 Definitions, Acronyms and Abbreviations

This section provides definitions of key terms, acronyms, and abbreviations used throughout this
Software Requirements Specification (SRS) document to ensure clarity and proper interpretation.
Term/Acronym Definition
Application Programming Interface, a set of tools and protocols for building and
API
integrating software applications.
Clinical Decision Support System, a feature within the HMS to assist doctors in
CDSS
making informed decisions based on patient data.
Electronic Health Record, a digital version of a patient’s medical history
EHR
maintained by the hospital.
Graphical User Interface, the visual component of the HMS that allows users to
GUI
interact with the system.
Hospital Management System, the software product being developed for Al Hayat
HMS
Hospital.
Internet of Things, a network of interconnected devices that may integrate with the
IoT
HMS for real-time monitoring and data collection.
Key Performance Indicator, measurable values that indicate the success of system
KPI
implementation.
Near Field Communication, a technology enabling short-range communication,
NFC
possibly used for patient ID and check-in.
OTP One-Time Password, a security feature to authenticate user access to the HMS.
Software Requirements Specification, the document detailing the functional and
SRS
non-functional requirements of the HMS.
User Interface/User Experience, the design elements and overall experience of
UI/UX
interacting with the HMS.

1.5 Document Conventions

The following conventions and standards are followed in writing this Software Requirements
Specification that will minimize confusion and enhance professionalism.

1.5.1 Formatting Conventions

Font Style and Size: The text is written in Arial, 12 for all parts of the document.
Section and Subsection Titles: Titles are bold and numbered in a hierarchical manner (for
instance 1, 1.1, 1.2). All sub-section headings are aligned slightly to the right of the left hand
margin for ease of reading.
Margins: For the general spacing andAlignment, the margins in this document are set to 1” at the
top, bottom and sides.
Line Spacing: To make the text easier to read, margins are left single-spaced, and there are
doublespaces between sections.
Software Requirements Specification for <Project> Page 4
Emphasis: Comments and placeholders, as well as special instructions that are specified during
the preparation of the document, are made in italics.

1.5.2 Naming Conventions

Section Names: The numbering system is applied for every section and every subsection
uniformly in order to provide the convenient navigation.
Acronyms and Abbreviations: All acronyms are explained when used for the first time in the text
and repeated in section 1.4 for convenience.
File Names: Documents related to this project include HMS_<section>_<version>(for example
HMS_SRS_v1.0).

1.5.3 Typographical Conventions

Tables and Figures: Appendices are labeled as Appendix X where X refers to the numerical order
of the appendix across all appendices (e.g. Appendix B).
Code Snippets: If used, it is placed in typographically distinguishable font, most usually
monospace of a couple of typesizes, such as Courier New.
References and Citations: Every source provided conforms to APA style for the articles so that
there will be consistency in the articles and, where necessary, also include in-text citations.

1.6 References and Acknowledgments

This section lists the key references and resources utilized in the development of this Software
Requirements Specification (SRS) document. These references provide foundational knowledge,
standards, and guidance relevant to the system's design and implementation. Additionally,
acknowledgments are provided for contributors and collaborators involved in this project.

1.6.1 References

References
 IEEE Standard 830-1998: IEEE Recommended Practice for Software
Requirements Specifications.
 Bahrain Health Statistics 2023: Ministry of Health, Kingdom of Bahrain. Retrieved
from www.moh.gov.bh.
 Hospital Management Systems Overview: Journal of Health Informatics, Vol. 15,
Issue 3, 2023.
 User Interface Style Guide: International Usability and User Experience Guide,
2022 Edition.
 Database Design Principles: Silberschatz, A., Korth, H. F., & Sudarshan, S.
(2021). Database System Concepts (7th Edition).

1.6.2 Acknowledgments
1. The administrative staff and IT department at Bahrain Specialist Hospital, who provided
insight into the existing Hospital Management System and identified operational
challenges.
2. Project Supervisor and Academic Advisor for their guidance and review throughout the
creation of this SRS document.
Software Requirements Specification for <Project> Page 5
3. Development Team for their collaborative effort in analyzing and proposing an upgraded
solution tailored to the hospital’s needs.

2 Overall Description

2.1 Product Overview

Hospital Management Information System (HMIS) suggested here is proposed as a replacement
for the current suboptimal legacy system at BSH. This system is meant to overcome such as
deficiencies and hurdles accompanying patient record management, appointment bookings,
billing processes, and resource mobilization. Hospital Management Information System
consolidates subsystems that can cover the management of patient data, records, laboratory
results, billing systems, the staff. Such an integrated strategy will improve the management of the
facilities, the quality of the services and accommodate to the Bahrain practices in healthcare.
The HMIS is a new built system that is self contained with deliberate design features to suit
specific needs of the Bahrain Specialist Hospital coupled with compliance to standard protocols
including Health Level Seven International (HL7). It comprises of a web page and an application
to the staff and patients where they get to view real-time information. It also has an elaborate data
security system in addition to medical and/ or financial information of patients.
To medical devices, third party laboratories, and insurance providers, the product will connect
through APIs. It will also include analytical and reporting services that will be of great help to the
hospital’s administration. The setting of this product assures that its framework may be extended
to other related health care facility in Bahrain, therefore it acts as a prototype provision.

System Interaction Diagram

HMIS Central Database

External Systems | & Server
(Insurance, Labs, etc.)

Hospital Modules
Patient Portal | (Billing,
(Mobile/Web) Records,Scheduling,
etc.)

Crucial Parts
All hospital data, including patient information, financial transactions, and medical histories, are
securely stored on a central database and server.
Hospital Modules: Manages essential operations including staff/resource management, billing,
and scheduling.
Software Requirements Specification for <Project> Page 6
Patients can schedule appointments, view their medical data, and check their billing status using
the patient portal.
External Systems Interface: Facilitates seamless data transmission by integrating with outside
labs and insurance companies.

2.2 Product Functionality

The proposed Hospital Management Information System (HMIS) will provide comprehensive
functionalities to address the operational and administrative needs of Bahrain Specialist Hospital.
These functionalities are designed to improve efficiency, enhance patient care, and streamline
workflows. Below is a high-level summary of the system’s major functions:
 Patient Management:
Enables the registration, updating, and retrieval of patient information, including
demographics, medical history, and ongoing treatments. This ensures quick access to
accurate patient data (Tan & Payton, 2019).
 Appointment Scheduling:
Facilitates real-time booking, modification, and cancellation of appointments by patients
and staff. It includes conflict resolution features to avoid overlapping schedules.
 Electronic Medical Records (EMR):
Maintains comprehensive digital records of patients’ medical data, including diagnoses,
treatment plans, laboratory results, and prescriptions, ensuring seamless accessibility for
healthcare providers (HL7 International, 2023).
 Billing and Invoicing:
Automates billing processes, generates accurate invoices, manages payment records, and
integrates with insurance providers for claims processing.
 Laboratory and Pharmacy Integration:
Connects the hospital's laboratory and pharmacy systems, enabling automated test result
uploads and prescription refills.
 Staff and Resource Management:
Tracks and manages staff schedules, shifts, and resource allocation, ensuring optimal
utilization of hospital facilities and personnel.
 Analytics and Reporting:
Generates real-time and periodic reports on hospital performance metrics, patient
demographics, and financial summaries, aiding strategic decision-making (Bahrain
Specialist Hospital, 2023).
 Patient Portal:
Provides a secure interface for patients to access medical records, view test results,
schedule appointments, and make payments online.
 External System Interfacing:
Ensures seamless communication with external systems, such as insurance companies
and third-party laboratories, using secure APIs.

2.3 Design and Implementation Constraints

< The design and implementation of the Hospital Management Information System (HMIS) for
Bahrain Specialist Hospital will be governed by the following constraints and requirements:
 1. Hardware Limitations
Software Requirements Specification for <Project> Page 7
 Server Capacity: The system must run on hospital-grade servers capable of handling
high concurrent loads, including patient records, real-time scheduling, and analytics.
 Memory and Storage: A minimum of 32GB RAM and 1TB SSD is required for servers to
ensure smooth operation, data retrieval, and real-time processing of electronic medical
records.
 User Devices: The system must be compatible with existing hardware such as desktop
computers, tablets, and hospital-grade medical equipment used for data input.
 2. Software and Technology Constraints
 Design Methodology: The project must adhere to the COMET (Concurrent Object
Modeling and Architectural Design Technique) method to ensure a modular and robust
architecture suitable for concurrent operations (Gomaa, 2011).
 Modeling Standards: The system design will utilize UML (Unified Modeling Language)
diagrams, including class diagrams, sequence diagrams, and state diagrams, for
comprehensive documentation and communication (Booch, Rumbaugh, & Jacobson,
2005).
 Technology Stack: The system will be developed using a combination of modern
technologies:
o Frontend: React.js for building responsive and user-friendly interfaces.
o Backend: Node.js for handling server-side logic.
o Database: PostgreSQL for relational data storage, and MongoDB for unstructured
data.
 3. Integration and Interfacing
 The system must seamlessly interface with existing third-party applications, such as
insurance company APIs and external diagnostic labs. This requires the use of FHIR (Fast
Healthcare Interoperability Resources) for data exchange.
 4. Security Considerations
 Data Protection: The system must comply with GDPR and Bahrain Personal Data
Protection Law (PDPL) to secure patient data.
 Encryption Standards: All data in transit and at rest must use AES-256 encryption for
secure handling of sensitive information.
 User Authentication: Multi-factor authentication (MFA) will be implemented for all user
roles.
 5. Parallel Operations
 The new system must coexist with the current system during the transition phase to
ensure uninterrupted hospital operations.
 6. Programming and Maintenance Standards
 All code must adhere to PEP 8 for Python scripts and Airbnb JavaScript Style Guide for
frontend development to maintain readability and consistency.
 The client's IT department will maintain the system, necessitating detailed documentation
and training materials.

2.4 Assumptions and Dependencies

The successful design, development, and implementation of the Hospital Management
Information System (HMIS) for Bahrain Specialist Hospital relies on several assumptions and
dependencies, which are outlined below:
1. Assumptions
2. Infrastructure Readiness:
o The hospital will provide adequate server infrastructure and network bandwidth to
support the HMIS.
o End-user devices such as computers, tablets, and medical instruments are
compatible with the new system.
Software Requirements Specification for <Project> Page 8
3. User Adoption:
o All hospital staff, including doctors, nurses, and administrative personnel, will
actively participate in training sessions and adopt the system as part of their
workflow.
4. Data Accuracy and Availability:
o Existing patient records and hospital data will be accurate, well-organized, and
readily available for migration into the new system.
5. Regulatory Compliance:
o The hospital has the necessary licenses and certifications to comply with
international and Bahraini data protection laws, including PDPL and GDPR.
6. Stable Funding:
o The project will have consistent funding throughout the development and
implementation phases, ensuring no interruptions or delays.
7. Dependencies
1. Third-Party Software Components:
o Integration with third-party systems, such as insurance claim APIs and diagnostic
lab systems, will rely on their continued support and compatibility.
o The system will use the FHIR (Fast Healthcare Interoperability Resources)
standard for exchanging healthcare information with external systems.
2. Development Environment:
o Availability of tools like React.js, Node.js, and PostgreSQL to build and deploy
the system as planned.
o Dependence on cloud services for secure data backups, disaster recovery, and
scalability.
3. Compliance and Certifications:
o Adherence to medical software standards, such as ISO 13485 for medical devices
and software quality, is required.
4. User Feedback:
o Continuous input and feedback from hospital staff are essential for ensuring the
system meets functional and usability requirements.
5. Internet and Power Stability:
o The system's performance depends on stable internet connectivity and
uninterrupted power supply to ensure 24/7 operation of hospital services.
Software Requirements Specification for <Project> Page 9

3 Specific Requirements

3.1 External Interface Requirements

3.1.1 User Interfaces

The Hospital Management Information System (HMIS) for Bahrain Specialist Hospital will provide
an intuitive, user-friendly interface designed to meet the diverse needs of medical and
administrative staff. The interface will be accessible through computers, tablets, and interactive
kiosks, offering seamless navigation for tasks such as patient registration, appointment
scheduling, medical record access, billing, and inventory management.
The system will feature:
 Dashboard Interface: A central dashboard will display key metrics such as patient counts,
doctor availability, and pending tasks. The dashboard will use visually appealing charts,
graphs, and notifications to facilitate decision-making.
 Role-Based Navigation: Depending on their role (doctor, nurse, administrator, or
accountant), users will see tailored menus and features relevant to their tasks.
 Input Methods:
o A touchscreen-based interface for interactive kiosks and tablets, allowing easy
input through on-screen buttons and dropdown menus.
o Mouse and keyboard support for computer-based interactions, with shortcuts for
frequent operations like accessing patient records or scheduling appointments.
 User Interaction Example:
 A receptionist can log in and immediately see a list of patients scheduled for the day.
 Doctors can access a patient’s complete medical history, lab reports, and prescribed
medications from the consultation screen.
 Administrators can manage hospital operations by updating staff schedules, reviewing
revenue reports, and tracking inventory usage in a few clicks.

3.1.2 Hardware Interfaces

The Hospital Management Information System (HMIS) interacts with various hardware
components to ensure smooth operations and data accessibility across the hospital environment.
The primary hardware interfaces include:
1. Desktop and Laptop Computers:
o Serve as primary devices for accessing the HMIS interface in administrative offices,
reception areas, and doctor's cabins.
o The software will be optimized for standard keyboard and mouse input, supporting
high-resolution monitors for detailed data visualization.
2. Tablets and Mobile Devices:
o Allow portability and quick access to patient data, schedules, and medical records
by doctors and nurses in wards.
o The HMIS will support touch-based interaction for intuitive navigation and data
input.
3. Interactive Kiosks:
o Placed at entry points for patient self-service functions like registration,
appointment scheduling, and queue management.
o Equipped with touchscreens and integrated printers for receipts or tokens.
Software Requirements Specification for <Project> Page 10
4. Printers and Scanners:
o Used for printing prescriptions, bills, and medical reports.
o Scanners allow digitization of external documents for integration into electronic
medical records (EMR).
5. Medical Equipment:
o Interfaces with devices like vital sign monitors, imaging machines (e.g., MRI, CT
scans), and laboratory analyzers to capture diagnostic data directly into the
system.
o Communication is facilitated through standard data transfer protocols, allowing
real-time updates to patient records.
6. RFID or Barcode Scanners:
o Used for patient identification via wristbands or document tags, ensuring accurate
tracking of patient data and medications.
7. Networking Devices:
o Includes servers, routers, and switches to manage data exchange between HMIS
terminals and ensure system reliability and scalability.

3.1.3 Software Interfaces

The Hospital Management Information System (HMIS) integrates with several software
components to enhance functionality and enable seamless communication across platforms. A
key interface is the mobile application, which allows users to access the system remotely. The
mobile app provides essential features such as scheduling appointments, viewing medical
records, and receiving notifications about test results or upcoming appointments. Commands from
the mobile app are transmitted securely to the HMIS server via RESTful APIs, ensuring data
integrity and real-time updates.
Additionally, the system integrates with external software for diagnostic equipment, laboratory
management systems, and financial applications. These integrations enable the HMIS to receive
diagnostic data, manage billing, and generate reports efficiently. Interactions are managed using
standardized data exchange formats like HL7 for healthcare data and JSON or XML for API
communications.

3.2 Functional Requirements

The Hospital Management Information System (HMIS) is designed to streamline hospital

operations by offering a comprehensive range of functionalities. These include patient
registration and management, scheduling appointments, generating medical records,
managing doctor schedules, and providing an integrated billing system. The system
enables laboratory and diagnostic test management by connecting with lab equipment to
store and retrieve results efficiently. Additionally, it supports inventory management for
hospital supplies and medicines, tracks staff records, and provides reporting capabilities
for decision-making. All functionalities are accessible via a user-friendly interface,
ensuring a seamless experience for administrators, healthcare providers, and patients .

3.2.1 F1: The system shall …

Software Requirements Specification for <Project> Page 11
 F1: The system shall allow users to register patients, schedule appointments, and maintain
detailed patient records, including demographics, medical history, and current treatments.
 F2: The system shall enable hospital staff to generate, store, and retrieve diagnostic test results
from integrated laboratory equipment.
 F3: The system shall support inventory management, tracking hospital supplies, and
medications to ensure availability and reduce wastage.
 F4: The system shall provide billing functionalities, including automated invoice generation and
payment tracking, to streamline financial operations.
 F5: The system shall generate detailed reports for hospital management, covering staff
performance, patient care metrics, and financial summaries.

3.2.2 <Functional Requirement or Feature #2>

F2: Integration with Laboratory Systems

The system shall interface with laboratory equipment and software to automatically receive and
record diagnostic test results. This integration will reduce manual data entry, minimize errors, and
ensure timely updates to patient records.

3.3 Use Case Model

The use case diagram below illustrates the interactions between the system and its primary
actors, including patients, medical staff, administrators, and external systems.
Software Requirements Specification for <Project> Page 12

3.3.1 Use Case #1 U1 – Patient Admission

 Author: Almidid

 Purpose: The goal of the "Patient Admission" use case is to register a new patient into the
hospital's system, including entering their personal details, medical history, and assigning
them a unique patient ID.

 Requirements Traceability: This use case traces to functional requirements related to

patient data entry, record creation, and initial appointment scheduling.

 Priority: High. This use case is critical as it directly impacts patient data management and
hospital workflow.

 Preconditions:

 The system is up and running.

 The user is authenticated and authorized to admit patients.

 The patient is physically present or has contact with the hospital for registration.
Software Requirements Specification for <Project> Page 13
 Postconditions:

 A new patient record is created in the system.

 The patient is assigned a unique identifier.

 The patient’s information is stored in the database for further medical treatment
and tracking.

 Actors:

 Primary Actor: Hospital staff (nurse or administrative personnel)

 Secondary Actor: Patient (provides personal and medical information)

 Extends:

 None

 Flow of Events:

1. Basic Flow:

o The hospital staff accesses the patient admission module.

o The staff enters the patient's personal details (name, address, contact information,
etc.).

o The medical history of the patient is entered.

o A unique patient ID is generated by the system.

o The staff confirms the details and submits the information to the system.

o The system saves the new patient record and displays a confirmation message.

2. Alternative Flow:

o If any mandatory fields are missing, the system will prompt the staff to complete the
required information.

o If the patient has existing records, the system will retrieve those records and
prompt the staff for confirmation to merge or create a new record.

3. Exceptions:

o If the system encounters a database error, the staff will be notified, and the
process will be halted.

o If a duplicate patient record is detected, the system will alert the staff and ask for
confirmation before creating a new record.

 Includes:
Software Requirements Specification for <Project> Page 14
 U2: Verify Patient Identity (checks for existing records or confirmation of new patient
details).

3.3.2 Use Case #2

 U2 – Receptionist Taking Appointment for Patient

 Author: Gloria Auma
 Purpose: The purpose of this use case is to allow the receptionist to schedule an
appointment for a patient, either new or returning, based on the patient’s preferred time and
the available doctor.
 Requirements Traceability: This use case traces to functional requirements regarding
appointment scheduling, doctor availability, and patient record management.
 Priority: High. Scheduling appointments is essential for hospital operations, and errors in
this process can affect patient care.
 Preconditions:
 The patient must be registered in the system (if a returning patient).
 The receptionist is authenticated and authorized to schedule appointments.
 The available time slots for doctors must be checked and accessible through the system.
 Postconditions:
 A confirmed appointment is scheduled in the system.
Software Requirements Specification for <Project> Page 15
 The patient’s appointment details (doctor, date, time) are saved in the hospital’s
appointment database.
 A confirmation message is sent to the patient (via phone or email, depending on hospital
protocol).
 Actors:
 Primary Actor: Receptionist
 Secondary Actor: Patient (provides preferred appointment time and doctor, if applicable)
 Extends:
 U1: Patient Admission (if a new patient needs to be registered before scheduling an
appointment).
 Flow of Events:
1. Basic Flow:
o The receptionist accesses the appointment scheduling system.
o The receptionist enters the patient’s details (if a new patient) or searches for the
existing patient.
o The system displays available doctors and their free time slots.
o The receptionist asks the patient for their preferred time and doctor.
o The system checks doctor availability and displays available slots.
o The receptionist selects a time slot that suits the patient.
o The system confirms the appointment and updates the database.
o A confirmation message is sent to the patient.
2. Alternative Flow:
o If no appointment slots are available for the selected doctor, the system will prompt
the receptionist to either suggest another doctor or time.
o If the patient has a preference for a specific doctor and no slots are available, the
receptionist may provide alternative times or ask for a different doctor.
3. Exceptions:
o If the system detects any conflict (e.g., double-booking or missing doctor
information), the receptionist is notified and must select another slot.
o If the patient’s record cannot be found (for returning patients), the receptionist must
register the patient (see Use Case U1) before proceeding.
 Includes:
 U1: Patient Admission (if a new patient requires registration).
Software Requirements Specification for <Project> Page 16

4 Other Non-functional Requirements

4.1 Performance Requirements

<If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements as
specific as possible. You may need to state performance requirements for individual functional
requirements or features.
TODO: Provide performance requirements based on the information you collected from the
client/professor. For example, you can say “P1. The secondary heater will be engaged if the
desired temperature is not reached within 10 seconds”>
Software Requirements Specification for <Project> Page 17

4.2 Safety and Security Requirements

<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well
as actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied. Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements.
TODO:
 Provide safety/security requirements based on your interview with the client - again you
may need to be somewhat creative here. At the least, you should have some security for
the mobile connection.

4.3 Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.

TODO: Use subsections (e.g., 4.3.1 Reliability, 4.3.2 Adaptability, etc…) provide requirements
related to the different software quality attributes. Base the information you include in these
subsections on the material you have learned in the class. Make sure, that you do not just write
“This software shall be maintainable…” Indicate how you plan to achieve it, & etc…Do not forget
to include such attributes as the design for change (e.g. adapting for different sensors and
heating/AC units, etc.). Please note that you need to include at least 2 quality attributes. You can
Google for examples that may pertain to your system.>

5 Other Requirements
<This section is Optional. Define any other requirements not covered elsewhere in the SRS. This
might include database requirements, internationalization requirements, legal requirements, reuse
objectives for the project, and so on. Add any new sections that are pertinent to the project.>
Software Requirements Specification for <Project> Page 18

Appendix A – Data Dictionary

<Data dictionary is used to track all the different variables, states and functional requirements that
you described in your document. Make sure to include the complete list of all constants, state
variables (and their possible states), inputs and outputs in a table. In the table, include the
description of these items as well as all related operations and requirements.>
Software Requirements Specification for <Project> Page 19

Appendix B - Group Log

<Please include here all the minutes from your group meetings, your group activities, and any
other relevant information that will assist in determining the effort put forth to produce this
document>