Software Req Spec (SRS) Try

Assosa University
College of Computing and Informatics

Department of Computer Science
<Insert Name of the Project>
A Project Proposal Submitted to the Department of Computer Science of

Assosa University in Partial Fulfillment of Requirements for the Course of
Software Engineering
Prepared By:
Name of the Student, Name of Student, Name of Student, …….
Advisor Name: ……………
<Submission Date>
Software Requirements
Specification
for
<Insert Name of the Project>
Version 1.0 approved
Prepared by <author1, author2, author3, …. >
<organization>
<date created>
i
Acknowledgement
Acknowledge organizations or people who cooperate and help you in providing information during the
preparation of this SRS document.
Contents
ACKNOWLEDGEMENT....................................................................................................... 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....................................................2
1.5 REFERENCES............................................................................................................2
2 OVERALL DESCRIPTION...........................................................................................3
2.1 PRODUCT PERSPECTIVE...........................................................................................3
2.2 PRODUCT FUNCTIONS..............................................................................................3
2.3 USER CLASSES AND CHARACTERISTICS..................................................................3
2.4 OPERATING ENVIRONMENT.....................................................................................4
2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS.......................................................4
2.6 USER DOCUMENTATION..........................................................................................4
2.7 ASSUMPTIONS AND DEPENDENCIES........................................................................4
3 SPECIFIC REQUIREMENTS.......................................................................................6
3.1 EXTERNAL INTERFACE REQUIREMENTS..................................................................6
3.1.1 User Interfaces.........................................................................................6
3.1.2 Hardware Interfaces................................................................................6
3.1.3 Software Interfaces...................................................................................7
3.1.4 Communication Interfaces.......................................................................7
3.2 FUNCTIONAL REQUIREMENTS.................................................................................8
3.3 SYSTEM USE CASE MODELING...............................................................................8
3.3.1 Actors and Use Cases...............................................................................8
3.3.2 Use Case Diagram...................................................................................8
3.3.3 System Use Case Documentation.............................................................9
4 NON-FUNCTIONAL REQUIREMENTS...................................................................10
4.1 PERFORMANCE REQUIREMENTS............................................................................10
4.2 SAFETY AND SECURITY REQUIREMENTS...............................................................10
4.3 SOFTWARE QUALITY ATTRIBUTES........................................................................11
4.3.1 Reliability...............................................................................................11
4.3.2 Robustness..............................................................................................11
4.3.3 Availability.............................................................................................11
4.3.4 Maintainability.......................................................................................11
4.3.5 Portability...............................................................................................11
Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Type Full Name Information about the revision. This table does not need 00/00/00
and Number to be filled in whenever a document is touched, only
when the version is being upgraded.
ii
1 Introduction
Our project Clinic Management system for ASU includes registration of patients, storing
their disease details into the system. My software has the facility to give a unique
id for every patient and stores the details of every patient. The Hospital
Management System can be used by entering respective username and password. It
is accessible either by an administrator, a Doctor or A patient . Only the respective person
can add data in the database. The data can be retrieved easily. The interface is very
user-friendly. The data are well protected and data processing is very fast, accurate
and relevant
1.1 Document Purpose
This document is to describe all the software requirement specification (SRS) for the Clinic-
Management-System (CMS). The system aims to help the patients to take appointment
paper-based system and track their records through it. Polyclinic has been facing problems
due to its paper-based appointment system. With the increase in the number of patients
visiting the University clinic, it has become difficult to manage the appointment system
manually, and Recording Patient data manually also became troublesome to the employees.
The purpose of this project is to solve these complications by creating custom-built database
software to manage the Management System. it makes easy to set date and time for the
treatment of the patient to the relevant doctor. Doctor enters medical prescription and
receptionist takes the print. It also helps to maintain doctor’s consultation fee, Laboratories
and Testing charges automatically and maintaining the employee salary and its expenses.
1.2 Product Scope
The system has been facing problems due to its paper-based appointment system. With the
increase in the number of patients visiting, it has become difficult to manage the appointment
system manually. Recording of appointments and creating registers by pen and paper has
become a tedious task. And also its difficult to manage huge number of patient database.
Daily functions like patient registration, managing admission and overall management of
various departments can be easily performed with higher accuracy after the installation of
hospital software. The modules of hospital management software are user-friendly and easy
to access.
1.3 Intended Audience and Document Overview
Developers: in order to be sure they are developing the right project that fulfills requirements
provided in this document.
1
Testers: in order to have an exact list of the features and functions that has to respond
according to requirements and provided diagrams.
Users: in order to get familiar with the idea of the project and suggest other features that
would make it even more functional.
Documentation writers: to know what features and in what way they have to explain. What
security technologies are required, how the system will response in each user’s action etc.
Admin, Receptionist, Doctors and patients: in order to know exactly what they have to
expect from the system, right inputs and outputs and response in error situations.
1.4 Definitions, Acronyms and Abbreviations
The following are the definitions of the \abbreviations we used in this documentation
 CMS – Clinic Management System

 GUI – Graphical user interface
 MySQL – a query language
1.5 References
 https://www.researchgate.net/
 https://iopscience.iop.org/
2 Overall Description
2.1 Product Perspective
Product perspective is essentially the relationship of the product to the other products,
defining if the product is independent or is part of a larger product (dependent), and what the
principal interfaces of the product are.
2
This software is totally independent system that manages activities of the CMS as taking
appointments, generating patient reports, personnel management and administrative issues.
This CMS is a self- contained system that manages activities of the hospital as Appointment
scheduling, personnel management, and administrative issues. Various stakeholders are
involved in the CMS.
In this project all the records are stored in single database. Different users have different
permission to access this web application. Each user has unique id. If any data is lost user is
having option to recovery. User’s don’t have right to alter records after particular time period
and also it is not having option to alter other patient records.
.
2.2 Product Functions
The following are some of the CMS functions :

 Authentication for different users.
 Real-time validation of all fields and database to prevent errors.
 History of patients recorded in database.
 Built in backup and restore facilities.
 LAN compatible.
 Compatible with any platform.
2.3 User Classes and Characteristics
The admin, doctors, receptionists and patients will be the main users. The system is also
designed to be user-friendly.
 Admin
 Receptionist
 Doctors
 Patients
Admin: Admin should have prior knowledge of the system. Admin is able to control the
whole system. He/she can add, delete, update and modify user accounts from the system.
Receptionists: in order to add or delete the details of the patients come for the treatment and
accordingly provides identity to them.
Doctors: Doctor should fairly know about the usage of the system. Doctors are able to see
the respective appointments taken, Should also be able to search patient data, edit patient
data, add patient data, also can view patient’s details and records.
Patients: Patients can view their own records and doctors details and timings. And also can
make appointments.
3
2.4 Operating Environment
This proposed software (CMS) will be used in Windows platform in the version of Windows
7.MySQL will be used for the database to hold the patients, doctors and other employees’
details.
o Operating system: Windows platform, linux, Mac OS
o Processor: Pentium 4
o Processor speed: 2.5 GHz
o RAM: 512MB
o Hard disk drive: 500GB
2.5 Design and Implementation Constraints
Design and implementation constraints for a digital clinic management system may
include:
1. Security: The system must be designed to ensure patient data confidentiality, integrity,
and availability. It should have robust security measures in place to prevent unauthorized
access or data breaches.
2. Scalability: The system must be scalable to accommodate the growing number of

patients and healthcare providers. It should be able to handle a large volume of data and
users without compromising its performance.
3. Interoperability: The system must be able to integrate with other healthcare systems
such as electronic health records (EHRs), lab systems, and billing systems. It should also
support industry-standard protocols to enable seamless data exchange between different
systems.
4. Usability: The system must be user-friendly and easy to navigate for both healthcare
providers and patients. It should have an intuitive interface that requires minimal training
to use.
5. Accessibility: The system must be accessible from any device and location, including
smartphones, tablets, and desktops. It should also comply with accessibility standards to
cater to patients with disabilities.
7. Cost: The system must be cost-effective and provide value for money. It should have a
reasonable pricing model that aligns with the needs of healthcare providers and patients.
 A person who has no knowledge of computers will find it difficult to understand the
system. But with a little knowledge it will be very easy to handle the project.
4
2.6 User Documentation
User Manuals will be provided that will be providing document with screen shots.
If the user has more queries regarding this software then he/she can contact with the
administrator.
2.7 Assumptions and Dependencies
 Availability of reliable internet connectivity: The system assumes that healthcare

providers and patients have access to a stable internet connection to access the system.
 Availability of necessary hardware: The system assumes that healthcare providers have
the necessary hardware, such as computers, tablets, or smartphones, to access the system.
 Availability of trained personnel: The system assumes that healthcare providers have the
necessary training to use the system effectively.
 Integration with existing systems: The system may depend on the integration with
existing healthcare systems, such as EHRs, lab systems, and billing systems.
The code should be free with compilation errors/syntax errors.

The product must have an interface which is simple enough to understand.
3 Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces

The user interface is designed in PHP. The developer will have to study the designing of the
product. The use of the controls and the component from the Add items feature of the PHP.
The user of the product will get very user friendly web page which will be very easy to work
with.
5
The user interface for the software shall be compatible to any browser such as Internet
Explorer, Google chrome, or Mozilla Firefox.
3.1.2 Hardware Interfaces

 Computers: The software may require interaction with desktop or laptop computers to
input and access patient data, manage appointments, and generate reports.
 Tablets and smartphones: The software may need to interact with mobile devices to
access patient data, manage appointments, and communicate with patients.
3.1.3 Software Interfaces

 Web server software, Apache
 Server side scripting tools: PHP
 Database tools: My SQL
 Compatible operating system: Linux, Windows
 Client side software.
 Web browser supporting JavaScript, refer Browser Compatibility 2.3.1
 Android environment
3.1.4 Communication Interfaces

The communication Interfaces of the CMS include:
TCP/IP (Transmission Control Protocol/Internet Protocol): A standard for transmitting data
over networks.
HTTPS (Hypertext Transfer Protocol Secure): A secure version of HTTP that uses
encryption to protect data in transit.
Data transfer rates and synchronization mechanisms will depend on the specific needs of the
clinic management software and the infrastructure in place. These factors may be determined
by the size of the clinic, the number of users accessing the system, and the types of data
being transferred.
3.2 Functional Requirements
 FR1: The system shall allow Patients to Log in, schedule appointments, view reports,
search records. .
 FR2: The system shall allow Doctors to view and update patient information,
including to make appointments, delete patient data, search patient data.
 FR3: The system shall allow Admins to log in, add accounts, delete accounts, edit
account details, change passwords.
 FR4: The system shall allow Receptionists to add and delete data of new or existing
patient records.
6
3.3 System Use Case Modeling
3.3.1 Actors and Use Cases
Actor Use Case

Log In
View Reports
Patients Search records
Make Appointments
Log Out
Log in
Add Patient data
Delete Patient data
Doctors Edit Patient data
Search Patient data
Make Appointments
Log Out
Log in
Add account
Administrator Remove Account
Edit Account Data
Logout
Log in
Add patient Details
Receptionist Remove Patient details
Edit patient Details
Log out
3.3.2 Use Case Diagram

The use case diagram is as follows
7
3.3.3 System Use Case Documentation
Use cases 01:
8
Use cases UC-1 Description
Use case name Register Account
ID UC-1
Description User registers an account
Primary Actor Admin
Secondary Actor Patient, Doctor
Pre-Condition There are no preconditions associated with this

use case.
Main Flow The use case begins when the actor types
his/her name and password on the login
form.
Basic Flow - Login
1.The system validates the actor’s password
and logs him/her into the system.
2.The system displays the Main Form
and the use case ends.
Alternative Flows
1.Invalid Name / Password
If in the basic flow the system cannot
find the name or the password is
invalid, an error message is displayed.
The actor can type in a new name or
password or choose to cancel the
operation, at which point the use case
ends.
Post-Condition The user’s details are stored in the database.
Alternate flow The data the User inserted Does not meet the
requirements, so the system can not continue.
9
Exception flow System show error unrelated to the user input.
Use cases 02:
Use case name Login
ID UC-2
Description User tries to sign into system
Primary Actor Doctor, Patient, receptionist
Secondary Actor Admin
Pre-Condition User has already had an account in the database

of
Clinic Management System
Main Flow 1. The use case starts when the user clicks the
“Login” tab on the navigation bar
2. The system displays the login page that
allow users to fill in their username/email
address and password
3. The user keys in the details and clicks “Sign
In” button
4. The system checks the details in the
database
5. The system displays the Home page.
Post-Condition The user has access to the system
Alternate flow The user inputs an unrecognized data to the

system and the system shows error
Exception flow System shows Error unrelated to the user actions

and crashes.
10
Use cases 03:
Use case name Make Appointment
ID UC-03
Description Patient and Doctor make Appointment
Primary Actor Doctor, patient
Pre-Condition Patient has logged in
Main Flow 1.The use case starts when the Customer clicks
the “Make Appointments”
2.The system displays the detail
page with all kinds of available Doctors/ patients
3. The system displays a list of Doctor/ patient
that matched
the name of Doctor/patient input by the user
Alternate flow The user books Appointment with a patient/

doctor that has already been booked for another
appointment and system returns to reselect the
correct user.

and crashes.
Use cases 04:
Use case name Add Data
11
ID UC-4
Description User tries to Add new data into the system
Primary Actor Doctor, Admin, receptionist
Secondary Actor Patient
Pre-Condition The user must be logged into the system..
“Add new Data ” tab on the navigation bar
2. The system displays the Add data page that
allow users to insert the desired data.
3. The user keys in the details and clicks “Save”
button.
database
5. The system Saves the system inserted.
Post-Condition The user has Inserted the desired data.
Alternate flow The user tries to insert an invalid data list into the
system that doesn’t meet the requirements.

and crashes.
Use cases 05:
Use case name Search data
ID UC-5
Description User tries to search data from the system
12
Primary Actor Doctor, Patient, receptionist
Pre-Condition There must be a patient data recorded on the

system.
“Search ” tab on the navigation bar
2. The system displays the search page that
allow users to write what/ who they are searching
for.
3. The user writes in the details and clicks
“search” button.
database
5. The system displays the data requested.
Post-Condition The user has access the desired data/ information
Alternate flow The user tries to search a data in that is not found
in the system and the system shows a “Data not
found message”.

and crashes.
Use cases 06:
Use case name Delete Data
ID UC-6
Description User tries to Delete a data from the system
13

system.
“Delete data” tab on the navigation bar
allow users to write what/ who they want to
delete.
3. The user writes in the details and clicks
“delete” button.
database
5. The system deletes the data requested.
Post-Condition The user has removed, deleted desired data/

information
Alternate flow The user tries to delete a data in that is not found
in the system and the system shows a “Data not
found message”.

and crashes.
Use cases 07:
Use case name Edit Data
ID UC-7
Description User tries to Edit an existing data from the

system
14

system.
“Edit Data ” tab on the navigation bar
allow users to write what/ who they are searching
for.
3. The user keys in the details and clicks “search”
button.
database.
5. The system displays the data requested with
and editing form.
6.The user makes the desired modifications to the
data and press save button.
7. The data inserted is saved on the system.
Post-Condition The user has Edited the desired data.
Alternate flow The user tries to search and edit a data in that is
not found in the system and the system shows a
“Data not found message”.

and crashes.
Use cases 08:
Use case name Logout from the system
ID UC-08
Description User tries to logout from the system
15
Primary Actor Patient, Doctor, Receptionist
Secondary Actor Administrator
Pre-Condition Customer has logged in
“Logout” tab on the navigation bar
2. The system returns to the sign in page
The User has logged out

Post-Condition
Alternate flow The user doesn’t follow the required steps.
Exception flow System shows Error unrelated to the user

actions and crashes.
4 Non-Functional Requirements
4.1 Performance Requirements

CMS manages facilities required by the casual users quickly and easily. It offers to take patient data
management through online.
 Capacity: The System must support 1000 people at a time
 User-interface: The user-interface screen shall respond within 5 seconds.
 Conformity : The systems must conform to the Microsoft Accessibility guidelines
.
16
4.2 Safety and Security Requirements
In case the user forgets or loses Password, the repair functionality helps by choosing “forgot
password” option in the main login window. To avoid this kind of situations, backups can be
done regularly.
While typing the password, if the caps lock is on it must be notified.
If the system is kept idle for 10 min the session will expire.
This system is provided with authentication without which no user can pass. So only the
legitimate users are allowed to use the application. If the legitimate user’s share the
authentication information then the system is open to outsiders.
4.3 Software Quality Attributes
4.3.1 Reliability
The software should be dependable and consistent, with minimal errors or crashes.
It’s Good validations of user inputs will be done to avoid incorrect storage of records.
4.3.2 Robustness
If a user enters invalid data or if there is a network outage the system will be able to handle these
situations gracefully and recover without losing any important information.
4.3.3 Availability
The software should be available for use at all times, with minimal downtime for maintenance or
upgrades. This can be measured by calculating the percentage of uptime over a given period of time.
4.3.4 Maintainability
The software will be easy to maintain, with minimal downtime required for updates or fixes. This will
be easier with backed up data.
Backup: The system shall provide the capability to back-up the Data.
The system shall keep a log of all the errors.
During the maintenance stage, SRS document can be referred for any validations.
4.3.5 Portability
This system can be installed in any personal computers supporting windows operating system
platform.
This can be measured by the number of platforms on which the software can run and the ease of
installation on different systems.
17

Software Req Spec (SRS) Try

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Req Spec (SRS) Try

Uploaded by

Copyright:

Available Formats

Assosa University

College of Computing and Informatics

<Insert Name of the Project>

A Project Proposal Submitted to the Department of Computer Science of

Advisor Name: ……………

<Insert Name of the Project>

Version 1.0 approved

Prepared by <author1, author2, author3, …. >

1.1 Document Purpose

1.2 Product Scope

1.3 Intended Audience and Document Overview

1.4 Definitions, Acronyms and Abbreviations

 CMS – Clinic Management System

2.1 Product Perspective

2.2 Product Functions

The following are some of the CMS functions :

2.3 User Classes and Characteristics

2.5 Design and Implementation Constraints

2. Scalability: The system must be scalable to accommodate the growing number of

2.7 Assumptions and Dependencies

 Availability of reliable internet connectivity: The system assumes that healthcare

The code should be free with compilation errors/syntax errors.

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

3.2 Functional Requirements

3.3.1 Actors and Use Cases

Actor Use Case

3.3.2 Use Case Diagram

Use case name Register Account

Description User registers an account

Primary Actor Admin

Secondary Actor Patient, Doctor

Pre-Condition There are no preconditions associated with this

Post-Condition The user’s details are stored in the database.

Use cases 02:

Use cases UC-2 Description

Use case name Login

Description User tries to sign into system

Primary Actor Doctor, Patient, receptionist

Secondary Actor Admin

Pre-Condition User has already had an account in the database

Post-Condition The user has access to the system

Alternate flow The user inputs an unrecognized data to the

Exception flow System shows Error unrelated to the user actions

Use cases UC-03 Description

Use case name Make Appointment

Description Patient and Doctor make Appointment

Primary Actor Doctor, patient

Secondary Actor Admin

Pre-Condition Patient has logged in

Alternate flow The user books Appointment with a patient/

Exception flow System shows Error unrelated to the user actions

Use cases 04:

Use cases UC-4 Description

Use case name Add Data

Description User tries to Add new data into the system

Primary Actor Doctor, Admin, receptionist

Secondary Actor Patient

Pre-Condition The user must be logged into the system..

Post-Condition The user has Inserted the desired data.