SRS Final Fari Ori

Software Requirements Specification
For
Hospital Management System

Version 3.0
Prepared by
SoftwareRequirementsSpecificationforHospitalManagementSystem
Pageii
TableofContents
RevisionHistory............................................................................................................................iii
1. Introduction..............................................................................................................................4
1.1
1.2
1.3
1.4
1.5
Purpose.......................................................................................................................................4
Scope..........................................................................................................................................4
Definitions,AcronymsandAbbreviations.................................................................................5
References..................................................................................................................................5
Overview....................................................................................................................................5
2.1
2.2
2.3
2.4
2.5
2.6
Productperspective....................................................................................................................6
ProductFunction........................................................................................................................6
UserCharacteristics....................................................................................................................7
Constraints..................................................................................................................................8
AssumptionsandDependencies.................................................................................................8
Requirementssubsets.................................................................................................................8
3.1
3.2
3.3
3.4
3.5
UsecasesofDoctor....................................................................................................................8
UsecasesofPatient..................................................................................................................18
UsecasesofPharmacist...........................................................................................................27
UsecasesofFrontdesk............................................................................................................34
UsecasesofAdmin..................................................................................................................38
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Functionality.............................................................................................................................62
Usability...................................................................................................................................73
Reliability.................................................................................................................................74
Performance.............................................................................................................................74
Supportability...........................................................................................................................74
DesignConstraints...................................................................................................................74
PurchasedComponents............................................................................................................75
Interfaces..................................................................................................................................75
LicensingRequirements...........................................................................................................76
2. OverallDescription..................................................................................................................6
3. UseCases...................................................................................................................................8
4. SpecificRequirements...........................................................................................................62
5. SupportingInformation........................................................................................................76
6.
Diagram
6.1
6.2
classdiagram............................................................................................................................58
statechartdiagram....................................................................................................................59
Pageiii
RevisionHistory
Name
Date
ReasonForChanges
Version
Page4
IEEE Software Requirements

Specification Template
1.
Introduction
This document is for the Hospital Management System (Ali Hospital Gujarkhan). Hospitals
are trying to enhance their management to have a better control over their record. In order to fulfill
these requirements in a more efficient way they need automated system.
1.1
Purpose
The main purpose of developing this document is to provide and clearly defined functional, nonfunctional requirements, constraints and use-cases. It deals with the collection of patients information,
employee management including doctors, administration, pharmacy, billing managers and the front-desk.
Theotherpurposeofthisdocumentistomakethestakeholdersawareofwhatwearemakingfor
them.ThismakesabettercommunicationbetweenthestakeholdersandtheSoftwarecompany/
developers
1.2
Scope
Thepurposeofthisprojectistodevelopsoftwarewhichisuserfriendly,simple,fast,andcost
effective.Itdealswiththecollectionofpatientsinformation,anddigitalprescriptionsystem,desk
system,patientsystem,pharmacysystem,adminsystem.
1.2.1 Modules:
1. Databasemanagementsystem
2. Inventorysystemofpharmacy
3. Webapplication
3.1
3.2
3.3
3.4
Adminpanel
Patients/userspanel
Pharmacistpanel
FrontDeskpanel
Page5
3.5 Doctorinformation
1.3
Definitions,AcronymsandAbbreviations
Terms
WAMP
Windows, Apache, MySQL, PHP
JavaScript
An object-oriented computer programming language commonly used to

create interactive effects within web browsers.
Html
CSS
1.4
Hypertext Markup Language, a standardized system for tagging text files

to achieve font, color, graphic, and hyperlink effects on World Wide Web
pages.
Cascading Style Sheets (CSS) is a style sheet language used for describing
the presentation semantics (the look and formatting) of a document
written in a markup language.
MySQL.
MySQL, the most popular Open Source SQL database management

system, is developed, distributed, and supported by Oracle Corporation.
PHP
PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widelyused open source general-purpose scripting language that is especially
suited for web development and can be embedded into HTML.
DOB
Date of Birth.
References
1.5
Definition
IEEEStd8301998:IEEERecommendedPracticeforSoftwareRequirementsSpecifications.
SRStemplate:http://www.ciitfyp.com/Pages/Student/Resources.aspx
http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
SRSversion1.0
Overview
This SRS is organized in a way that any user of the system can easily understand and use the
hospital management system. This document starts with a brief explanation of the purpose of this
document. Later on, it continues with a problem in a system and then the detailed solution we
proposed for it. Also functional / non-functional requirements, interface requirements, constraints.
Page6
2.
OverallDescription
2.1
Productperspective
Currently, there is a file based system used in the hospitals. In this system hospitals are having
problems in maintaining and organizing the records. So according to the current requirements of
small/medium hospitals, there is need of computer based system to maintain and manage all the
records.
Draw Backs in Existing System:
Time consuming: Need extra manual effort.
Difficult to locate a particular patient or employee data at the time of need.
Danger of losing a file in some cases.
Theproposedsystemprovides patientsinformation,employeemanagementincludingdoctors
andstaff.It enhances the admin to adding, viewing and updating patients, staff,billingandpharmacy
information.
Advantages of Proposed System:
Very fast and accurate.
No need of any extra manual effort.
No fear of data loss.
Just need a little knowledge to operate the system.
Very easy to find the record.
2.2
ProductFunction
2.2.1
Patients Information
This module deals with the management of patient information such as patient ID, first name,
last name, father/husband name, DOB, city, contact number, address, age, bill number, disease.
2.2.2
DoctorInformation
This module deals with the management of doctor information such as doctor ID, first name,
last name, father/husband name, DOB, city, designation, operation, shift, salary, contact number, email
address, address, academic record, specialty
2.2.3 AdminInformation
Page7
This module deals with the management of admin information such as admin ID , first name,
last name, father/husband name, DOB, contact number, address
2.2.4 Pharmacyinformation
This module deals with the management of patients billing and pharmacy inventory system and
the bar-code system for generation of bills.
2.2.5 Frontdeskreceptionist
This module deals with the management of patient appointments, generates tokens and
registration of new patients.
2.3
UserCharacteristics
The main user of the system is the admin and employee but patients are also going to use it.
The following table describes general users characteristics that will affect the functionality of the
software product. Interface of our system is designed in user-friendly manner so that a user with
minimal understanding of computer can use it.
User
User Characteristics
Patient
Want to be checked up, check his/her

Account settings, print test result.
Receptionist
Registers the patients and gives the

command to print their respective
tokens
Provides his services, updates his/her
account settings, check patients
profile.
Maintains pharmacy inventory
Provides bill for the patients
Uses the bar-code scanner.
Doctor
Pharmacist
Admin
Monitors the System for any

Un-expected behavior. Adds /
edits/deletes
the
patients,
receptionists and pharmacists
information.
User Technical Expertise

Basic understanding of Computer.
Basic understanding of Computer


and experience in management.
doctors,
2.4.2 Hardware Limitations

For user should have Pantium4 or above(core, duel core, core i3 etc)
Page8
3.
UseCases
3.1
UsecasesofPatient
Use Case-ID:
SRR 3.2.1
Use CaseName:
Sign up
Actors:
Patient
Description: Patient can select sign up option on web portal.

Trigger: Click on sign up button.
Pre-conditions:
Patient should have to be on web main page.
Post-conditions: Patient should be successfully registered.
Normal Flow:
Alternative
Flows:
Exceptions:
Includes:
Special
Requirements:
Assumptions:
Notes and
Issues:
1.
2.
3.
4.
Patient go to web main page

Select sign up
Enter personal information
Select submit.
No
Patient cannot be registered without personal id card number or have no
access to web main page.
Validate patient information.
Validate the patient information within 1 second.
1. Patients understand English language.

2. Familiar with the websites.
3. Wi-Fi connection available
No
Page9
Use Case-ID:
SRR3.2.2
Use CaseName:
Sign in
Actors:
Patient
Description: Patient can select sign in option on web portal.

Trigger: Click on sign in button.
Pre-conditions:
Patient should have to be on web main page.
Post-conditions: Patient should be successfully login to his/her account.
Normal Flow:
Alternative
Flows:
Exceptions:
1.
2.
3.
4.
Patient go to web main page

Select sign in.
Enter username and password.
Select sign in.
No
Patient cannot be signed in without correct username and password or
has no access to web main page.
Includes: Validate patient username and password.

Special
Requirements:
Assumptions:
Notes and
Issues:
Validate the patient username and password within 1 second.

No
Page10
Use Case-ID:
Use CaseName:
Actors:
SRR 3.2.3
Update profile
Patient
Description: Patient can select update option from profile option.

Trigger: Click on update option.
Pre-conditions:
Patient should have to be logged in to his/her account.
Post-conditions: Patient profile should be successfully updated.
Normal Flow:
Alternative
Flows:
Exceptions:
1.
2.
3.
4.
Patients select profile option.

Select update option.
Changes the unrestricted desired fields.
Select save changes.
No
If patient is not signed in then he/she cannot update his/her profile or
have no access to webpage.
Includes: Validate patient information.

Special
Requirements:
Assumptions:
Notes and
Issues:

No
Page11
Use Case-ID:
SRR 3.2.4
Use CaseView available doctors list
Name:
Actors:
Patient
Description: Patient can view the available doctors list of hospital.
Trigger: Click on available doctors list option.
Pre-conditions: Patient should have to be logged in to his/her account.
Post-conditions: All doctors should be viewed.
1. Patients select available doctors option.
Normal Flow:
2. List of doctors displayed.
Alternative
Flows: No
Exceptions: If patient is not signed in then he/she cannot view available doctors list.
Includes: Validate doctors information.
Special
Validate the doctors information within 1 second.
Requirements:
Assumptions:
Notes and
No
Issues:
Use Case-ID:
SRR 3.2.5
Use CaseSelect doctor
Name:
Actors:
Patient
Description: Patient can select doctor from doctors list.
Trigger: Click on doctor name.
1. Patient should have to be logged in to his/her account.
Pre-conditions:
2. Patient should have searched doctors list.
Post-conditions: Doctor should be selected .
1. Patient have doctors list.
Normal Flow:
2. Select doctor from the list.
Alternative
Flows: No
If patient is not signed in then he/she cannot view available doctors list.
Exceptions:
If doctors list is not displayed then he/she cannot select the doctor.
Includes: Validate doctor information.
Special
Validate the doctor information within 1 second.
Requirements:
Assumptions:
Notes and
No
Issues:
Use Case-ID:
SRR 3.2.6
Page12
Use CaseName:
Actors:
Get appointment online

Patient
Description: Patient can get appointment from the doctor online.

Trigger: Click on get appointment option.
Pre-conditions:
Post-conditions:
Normal Flow:
Alternative
Flows:

2. Patient should have searched doctors list.
3. Patient should have selected doctor
Appointment message send to doctor account.
1.
2.
3.
4.
Select get appointment option.

View appointment time.
Select appointment time.
Send message.
No
Exceptions: If doctor is not selected he/she cannot get appointment.

Includes: Validate doctors information.
Special
Requirements:
Assumptions:
Notes and
Issues:
Use Case-ID:
Validate the doctors information within 1 second.

No
SRR 3.2.7
Page13
Use CaseName:
Actors:
View appointments details

Patient
Description: Patient can see its own appointments details.

Trigger: Click on appointments option.
Pre-conditions:
Postconditions:

2. Patient should have appointments records.
All appointments should be displayed..
1. Select appointments option.

Normal Flow: 2. See appointments details.
Alternative
Flows:
Exceptions:
No
If no appointments is displayed that means patient have no appointments
records or patient is new.
Includes: Validate patient appointments.

Special
Requirements:
Assumptions:
Notes and
Issues:
Use Case-ID:
Validate the patient appointments within 1 second.

No
SRR 3.2.8
Page14
Use CaseName:
Actors:
View prescriptions
Patient
Description: Patient can see its prescriptions record.

Trigger: Click on view prescription option.
Pre-conditions:
Post-conditions:

4. Patient should have prescription records.
All prescription should be displayed..
3. Select view prescription option.

Normal Flow: 4. See all prescription records.
Alternative
Flows:
Exceptions:
No
If no prescription is displayed that means patient have no prescription
records or patient is new.
Includes: Validate patient information

Special
Requirements:
Assumptions:
Notes and
Issues:
Use Case-ID:

No
SRR 3.2.8
Page15
Use CaseName:
Actors:
View bills history

Patient
Description: Patient can see his/her bills record.

Trigger: Click on bills record option.
Pre-conditions:
Post-conditions:

6. Patient should have bills records.
All prescription should be displayed..
5. Select bills history.

Normal Flow: 6. See all bills records.
Alternative
Flows:
Exceptions:
No
If no bill is displayed that means patient have no bill records or patient is
new.

Special
Requirements:
Assumptions:
Notes and
Issues:
Use Case-ID:

No
SRR 3.2.9
Page16
Use CaseName:
Actors:
Sign out
Patient
Description: Patient can exit from his profile

Trigger: Click on sign out option from profile.
Pre-conditions: Patient has to log in to his/her account.
Post-conditions:
Normal Flow:
Alternative
Flows:
Exit from patient profile and Redirected to website main page.

1. Select profile option
2. Select sign out option
3. Redirect to website main page
No
Exceptions: If patient is not logged in then he/she cannot sign out .

Special
Requirements:
Assumptions:
Notes and
Issues:
3.2

No
UsecasesofPharmacist
Use Case-ID:
SRR- 3.3.1
Page17
Use Case-Name:
Login Pharmacy
Actors: Pharmacist
Description:
Pharmacist will login to view the prescriptions of the patients and by

viewing it he has authority to edit, print bills as well as the prescriptions.
Trigger:
1
2
If the he enters the Url of the login page

Signs out.
Pre-conditions:
1
2
Pharmacist is active on the internet.

Pharmacist has an account.
Post-conditions:
1
2
Pharmacist should be logged-in successfully.

If wrong attempt is made, redirect him to sign-in page
Normal Flow:
1
2
3
4
5
6
Pharmacist is present on the sign-in page.

Pharmacist enters his username.
Pharmacist enters his Password.
Clicks/Enters on Sign-in button.
System validates if pharmacist is in Hospital network.
Pharmacist is directed to his account-page.
Alternative
Flow: No Alternative flow.
4a. In step 4 of the normal flow, if pharmacist enters an empty username
1 Tool-tip displayed to enter username.
2 Remains on the same page with clear input fields.
Exceptions:
5a. In step 5 of the normal flow, if doctor username or password is

incorrect
1 Wrong login attempt message is displayed.
2 Redirects him on the sign-in page again.
1 Validate username and password.
Includes:
2 After validating account create a session for the user.
Special Req.: Validate the username and password with in one second
Assumptions:
Notes and
Issues:
Use Case-ID:
1
2
3
Pharmacist understands English language.

Pharmacist understands medical terms.
Pharmacist can operate the computer.
Maximum length of username 11, password 15 containing digits

and characters
SRR- 3.3.3
Page18
Use Case-Name:
Print bill
Actors: Pharmacist
The pharmacist will print the bill of the displayed prescription if the
Description: patient wants to buy the medicines prepared. The bill is prepared using
the bar-code reader/scanner.
Trigger: If the pharmacist clicks on the print bill command.
1
2
3
1
2
3
If the pharmacist has clicked on the prescription from

notifications or by coming on this step by searching his
prescription by patient-ID.
Bill has been prepared by the pharmacist using bar-code reader
Pharmacist login session is not expired.
The bill should be printed.
The pharmacist should see the prescription view again
The pharmacy inventory should be updated
1
2
3
4
Pharmacist is present on the prescription view page.

The bill has been prepared.
Pharmacist clicks on print bill.
The bill is printed.
Pre-conditions:
Post-conditions:
Normal Flow:
Alternative
Flow: No alternative flows
Exceptions:
2a. In step 2 of the normal flow, if pharmacist does not create bills
1 If he clicks on print command.
2 The error prompt will be to calculate bill first.
3a. In step 3 of the normal flow, if pharmacist clicks on print bills
1 If the bill has been fully/partially paid once
2 The error is displayed that the bill has already been printed.
Includes:
1
2
Session active
Create bills
Special
Requirements:
1
2
3
Printing should be easy.

Inventory should be updated correctly.
Prescription should be printed in A-4 size
Assumptions:
1
2
3
4

Pharmacist understands Urdu language.
Notes and
Issues:
1
2
The bill is paid or unpaid

Total bill paid and unpaid should be updated.
Use Case-ID:
Use Case-Name:
SRR- 3.3.4
Print prescriptions
Page19
Actors: Pharmacist
Description: The pharmacist will print the displayed prescription.
Trigger: If the pharmacist clicks on the print prescription command.
1
2
If the pharmacist has clicked on the prescription from

notifications or by coming on this step by searching his
prescription by patient-ID.
Pharmacist login session is not expired
Post-conditions:
1
2
The prescription should be printed.

The pharmacist should see the prescription view again
Normal Flow:
1
2
3

Pharmacist clicks on print prescription.
The prescription is printed.
Pre-conditions:
The pharmacist can print prescription of the patient on some other day,
Alternative if he has lost the prescriptions hard-copy
Flows: Then the pharmacist can perform this action by searching the patient-ID
and print the prescription.
Exceptions: No error chances
Includes: None
Special
Requirements: Prescription should be printed in A-4 size
Assumptions:
1
2
3

He knows medical terms.
He can use the computer.
Notes and
Issues: Only printing prescription money collecting is done manually.
Use Case-ID:
SRR- 3.3.5
Use CaseEdit prescription
Name:
Actors: Pharmacist
Page20
If the patient wants to take less/more amount of medicine then the

Description: prescribed amount. Then the pharmacist will have right to edit the
prescription to solve the bill-prescription mismatch issues.
Trigger: Pharmacist clicks on the edit button.
Pre-conditions:
Post-conditions:
Normal Flow:
1
2
Pharmacist is on the prescription view page

Login session is not expired.
The prescription should be opened in an editing mode provided with

tools such as rubber, pen etc.
1
2
3
4
5

Pharmacist clicks on edit prescription.
The prescription is opened in editing mode.
The prescription is saved, after editing.
Pharmacist is directed to prescription-view page again, from
where he started this use-case.
The pharmacist comes here by searching prescription using
patient-ID instead from notifications.
Alternative
Flows:
4a. In step 4 of the normal flow, if pharmacist presses backspace in

editing mode
1 JavaScript alert will be shown, leave page or not.
Exceptions:
4a. In step 4 of the normal flow, if login-session is expired

1 Pharmacist will be redirected to login-again.
2 After logging in, user will come in editing mode automatically.
Includes: Login Pharmacy

Special
Requirements: During editing the prescription should not be damaged.
Assumptions:
1
2
3
4
Pharmacist knows about paint in computer.

Notes and
Issues: None
Use Case-ID:
Use CaseName:
SRR- 3.3.6
Sign out pharmacy
Actors: Pharmacist
Page21
Description:
The pharmacist will be able to sign-out when it is a break in work or

when the pharmacy/hospital is being closed.
Trigger: Clicks on sign-out link.

Pre-conditions: Pharmacist is signed in.
Post-conditions:
1
2
The pharmacists login-session will be destroyed.

The pharmacist will be redirected to home page.
Normal Flow:
1
2
3
4
Pharmacist is on any logged-in valid page

He/she clicks on the sign-out link.
System will destroy users login-session.
Pharmacist will be redirected to the home page of hospital.
Alternative
Flows: No alternative flows
Exceptions: No exceptions.
Includes: None.
Special
Requirements: User should not be able to go on back-page after signing-out.
Assumptions:
1
2
3

Notes and
Issues: None.
Use Case-ID:
Use Case-Name:
SRR- 3.3.8
Search patients
Actors: Pharmacist
Page22
The pharmacist will have to search patients using their unique-ID or the
Description: name if the patient comes without prescription to print the older
prescription.
Trigger: The pharmacist clicks on the search patient button
1 The pharmacist should be logged-in
Pre-conditions:
2 The pharmacist has to be on his account home-page.
1 The result should be found / not found depending on the valid /
invalid input.
Post-conditions:
2 Patient with its hyper-link should be displayed to go the
prescriptions view page.
1. Pharmacist is present on the home account-page
2. Pharmacist clicks on the search button.
3. System verifies session of login and validates.
Normal Flow:
4. System checks whether the patient is valid or invalid.
5. System creates a dynamic page of the patient information.
6. Pharmacist will see the prescription.
Alternative
Flow: No alternative flows
4a. In step 4 of the normal flow, if patient-ID is not valid
Exceptions:
1 No result found is displayed.
Includes: None.
Special
Requirements:
Assumptions:
Notes and
Issues:
Assumptions:
1
2
1
2
3
3
4
1
2
3
4
No wrong information should be displayed.

The speed should be at most 3 seconds.
Pharmacist knows the structure of patient-ID.
Pharmacist should be aware of data entry
Notes and
Issues: Pharmacist should enter inventory using keyboard and mouse.
3.3
UsecasesofFrontdesk
Use Case-ID:
Use Case-Name:
SRR- 3.4.1
Login front desk
Actors: Front-desk receptionist

Front desk user will login to register patients, manage the appointments
Description: and will be generating a token-ID for the active-patient using a
hardware machine (token-generator)
Page23
Trigger:
1
2
Front desk receptionist clicks on the login button.

Front desk receptionist presses Enter on the login button.
Pre-conditions:
1
2
3
Front desk receptionist is active on the internet.

Front desk receptionist has an account.
Front desk receptionist is on the login page
Post-conditions:
1
2
Front desk receptionist should be logged-in successfully.

Normal Flow:
1
2
3
4
5
6
Front desk receptionist is present on the sign-in page.

Front desk receptionist enters his username.
Front desk receptionist enters his Password.
Clicks/Enters on Sign-in button.
System validates if receptionist is in Hospital network.
Front desk receptionist is directed to his account-page.
Alternative Flow:
None
4a. In step 4 of the normal flow, if pharmacist enters an empty username
1 Tool-tip displayed to enter username.
2 Remains on the same page with clear input fields.
Exceptions: 5a. In step 5 of the normal flow, if doctor username or password is

incorrect
1 Wrong login attempt message is displayed.
2 Redirects him on the sign-in page again.
1 Validate username and password.
2 After validating account create a session for the user.
Special Req: During editing the prescription should not be damaged.
Includes:
Assumptions:
Notes and Issues:
Use Case-ID:
Use Case-Name:
1
2
3
4
Receptionist is well trained

Receptionist understands English language.
Receptionist understands medical terms.
Receptionist can operate the computer.
Maximum length of username 11 containing digits and

characters
Maximum length of Password 15 containing digits, characters,
special characters
SRR- 3.4.2
Sign out front-desk
Description:
The receptionist will be able to sign-out when it is a break in work or

when the hospital is being closed.
Trigger: Clicks on sign-out link.
Page24
Pre-conditions:
1. Receptionist is signed in.

2. Login session is not expired.
Post-conditions:
1
2
The receptionists login-session will be destroyed.

The receptionist will be redirected to home page.
Normal Flow:
1.
2.
3.
4.
Receptionist is on any logged-in valid page

He/she clicks on the sign-out link.
System will destroy users login-session.
Receptionist will be redirected to the home page of hospital.
Alternative
Includes: None.
Special
Requirements: User should not be able to go on back-page after signing-out.
1
2
3
4
Assumptions:

Notes and Issues: None.
Use Case-ID:
SRR-3. 4.3
Use Case-Name:
Schedule appointments
Front desk will generate the tokens of patients to be checked both the
manually coming patients and the ones who got appointed online. Front
Description:
desk receptionist will generate the real token-ID if the patient is
physically present 15 minutes before the appointment.
Trigger: When he clicks on button Appoint.
Pre-conditions:
1
2
The receptionist should be logged-in.

He should have selected the patient already.
Page25
Post-conditions:
1
2
3
The token-ID will also be assigned before printing token number.

The token should be printed after clicking the Appoint button.
The record of patient history is updated.
Normal Flow:
1
2
3
4
Receptionist selects the patient using patient-ID

Asks whether the patient is online or manual patient.
Assigns the token-ID.
The token-ID number and patient information is printed.
If the patient comes for registration then after registration he could be

appointed a token if he wants to be checked up.
Alternative Flows:
2a. In step 2 of the normal flow, if patient is manual one:

1 A new token-ID running on time is assigned to the patient.
2b. In step 2 of the normal flow, if patient is online one:
1 A new token-ID running on time is assigned to the patient.
2 The virtual token-ID is rejected if the online patient does not
come before 15 minutes of the time assigned to him.
patient
Includes: Search
Registration
Special
Requirements:
1
2
Report generated should be easy to understand.

Generated report should be a complete summary of the month.
Assumptions:
1
2
3
4

Notes and Issues:
1
2

Use Case-ID:
SRR- 3.4.4
Use Case-Name:
Register patients

Description:
The receptionist can register the patients who do not use internet or for
those who cannot use computer.
Trigger: If the receptionist clicks on register patient.

Pre-conditions:
1
2
The receptionist should be logged-in.

Receptionist fills the necessary details of the patient in form.
Post-conditions: The patient should be registered.
Page26
1
2
3
4
5
Normal Flow:
Receptionist is logged-in.
Receptionist clicks on the button New-patient.
Fills in the form-details of the patient.
Clicks on Register button
The patient is registered
Alternative
Exceptions:
2a. In step 2 of the normal flow, entries required are empty or wrong.
1 Receptionist clicks back without filling form
2 Prompt message displayed leave page / not.
Includes: None
Special
Requirements:
1
2
Necessary required fields should not be missed in the form

It should not be time consuming.
Assumptions:
1
2
3
4

Notes and Issues:
3.4
Pharmacist should enter inventory using keyboard and mouse.
UsecasesofAdmin
Use Case-ID:
Use Case
Name:
Actors:
SRR- 3.5.1
Login
Admin
Description:
Admin will login to manage the system. When he/she open the admin sign
in page he/she will provide the his/her username and password
Trigger:
Go to the URL of admin and open the sign in page
Preconditions:
Postconditions:
1.
2.
1.
2.
3.
Admin has username and password.

Admin has already registered
Admin should be logged-in successfully.
Home page of admin will be opened.
Page27
Normal
Flow:
Alternative
Flows:
Exceptions:
1.
2.
3.
4.
5.
6.
Admin is present on the sign-in page.

Admin enters his username
Admin enters his Password.
Taps on Sign-in button.
System validates if admin is in Hospital network.
Admin is directed to his account-page.
If admin forgot username and password he/she will get password after
some verification of some personal questions
1.
2.
3.
4.
5.
6.
7.
8.
If admin enters an empty username

Tool-tip displayed to enter username.
Remains on the same page with clear input fields.
If admin enters an empty password
Tool-tip displayed to enter password
If doctor username or password is incorrect
Wrong login attempt message is displayed.
Redirects him on the sign-in page.
Includes:
Validate username and password.
Special
Requirement
s:
Validate the username and password with in one second
Assumptions:
Notes and
Issues:
Use Case-ID:
Use CaseName:
Actors:
Description:
Trigger:
Preconditions:
Postconditions:
Normal
Flow:
1. Doctors understand English language.

2. Can operate the Pc.
1. Maximum size of username 11. That contain numbers and
characters
2. Maximum password size is 15. Contain numbers, characters,
special characters
SRR- 3.5.2
Forgot password
Admin
If admin forgot their password and user name he/she will get by
verification of some personal questions. When admin click on forgot
password link/URL then forgot password panel is open and verify some
questions.
Go to the URL of admin and open forgot password link URL.
1.
2.
1.
2.
3.
1.
2.
3.
4.
Admin has username or password.

Admin has already registered.
Admin should be logged-in successfully.
Home page of admin will be opened.
Admin is present on the sign-in page.
Admin enters his username
Admin enters his Password.
Taps on Sign-in button.
Page28
5. System validates if admin is in Hospital network.

6. Admin is directed to his account-page.
Alternative
Flows:
Exceptions:
Includes:
Special
Requirement
s:
Assumptions:
Notes and
Issues:
If admin forgot username and password he/she will get password after
some verification of some personal questions
1. If admin enters an empty username
2. Tool-tip displayed to enter username.
3. Remains on the same page with clear input fields.
4. If admin enters an empty password
5. Tool-tip displayed to enter password
6. If doctor username or password is incorrect
7. Wrong login attempt message is displayed.
8. Redirects him on the sign-in page.
Validate username and password.
Validate the username and password with in one second
1. Admin understand English language.
2. Can operate the web application
1. Maximum size of username 11. That contain numbers and
characters
2. Maximum password size is 15. Contain numbers, characters,
special characters
Use Case-ID:
SRR- 3.5.3
Use CaseName:
View patients details
Actors:
Admin
Description:
Admin can view the all patients who already registered in the hospital
portal can he can also view all record of patients
Trigger:
Open the link of view details of patients
Preconditions:
1. Admin already logged in.

2. Admin have rights to view the patients details
Postconditions:
1.
2.
3.
4.
Select the patients

Patients list created by their name.
Patients can easily select the desire patients
Profile of patients will be open
Page29
Normal
Flow:
1.
2.
3.
4.
5.
Select the link of All patients

List of all patients will show.
Admin can select their desire patients.
View the patients profile.
Details of patients will show.
Alternative
Flows:
1. Admin can search the patients by his/her name.

2. Cancel the searching of patients
3. Select the search patients from list of patients will be created
Exceptions:
Desired patients not in the list
Includes:
Search patients by his/her name and id.
Special
Requirement
s:
1. Provide the list of all registered patient

2. Search the patients by name and id
Assumptions:
1. Admin have knowledge of patient id.

2. Desired patients in the list
Notes and
Issues:
1. When admin select the list of patients.

2. Pagination of patients will be created
3. If patients are not exists then error message of list empty
crated
Use Case-ID:
SRR- 3.5.4
Use CaseName:
Search patients details
Actors:
Admin
Description:
Admin can search the all patients who already registered in the hospital
portal by their name and id. Admin can view all record of patients
Trigger:
Open the search box to search the patients
Preconditions:

2. Admin have rights to view the patients details
3. Search box is already opened
Postconditions:
1.
2.
3.
4.
Enter the name or id of patients

Patients list created by their name.
Patients can easily select the desire patients
Profile of patients will be open
Page30
1.
2.
3.
4.
5.
1.
2.
3.
Normal
Flow:
Alternative
Flows:
Open search box

Enter the id or name of patients.
View the patients profile.
Details of patients will show.
Select the URL of select patients
List of patients will be created
Select the desire patient
Exceptions:
Enter name and id of patient is incorrect
Includes:
Special
Requirement
s:
Open URL of select all patients by his/her name and id.

Provide the list of all registered patient
Assumptions: Admin have knowledge of patient id.
Notes and
Issues:
Use Case-ID:
Use CaseName:
1. Maximum size of patient username 11 contains number and

characters
2. Maximum id, password size of patient is 15. Contain numbers,
characters, special characters
SRR- 3.5.5
Delete patients details
Actors:
Admin
Description:
Admin can delete the all patients who already registered in the hospital
portal. Admin can delete all record of patients
Trigger:
Open the list of patients and select the desire patients to delete
Preconditions:
Postconditions:
Normal
Flow:
1.
2.
3.
1.
2.
3.
4.
5.
1.
2.
3.
4.
5.
6.
Admin already logged in.

List of patients is shown
Desired patients is selected
Select the desire patients
Click on delete button.
Conformation box will open
Conform the delete patient
Patient will removed from the list
Select the link of all patient or search the patient
Conform the deletion of patient.
Patient will removed from the list
Page31
Alternative
Flows:
1.
2.
3.
4.
Admin can select the multiple user from list to delete.

Click on the delete button
Conformation box open
Admin can conform and deny the conformation to delete the
patient
5. If admin conform to delete patients removed from the patients list.
6. If admin deny to delete the patients, patient will not deleted from
list
Exceptions:
Includes:
Search patients by his/her name and id.
Special
Requirement
s:
1. Provide the list of all registered patient

2. Search the patients by name and id
3. Delete the patient
Assumptions:

2. Admin know about the conformation to delete the patient
Notes and
Issues:
1. Maximum size of patient username 11. That contain numbers and

characters
2. Maximum id, password size of patient is 15. Contain numbers,
characters, and special characters.
Use Case-ID:
SRR- 3.5.6
Use CaseName:
View doctors details
Actors:
Admin
Description:
Admin can view the all doctors who already registered in the hospital
portal. Admin can view all record of patients
Trigger:
Open the link of view details of doctors
Preconditions:

2. Admin have rights to view the doctors details
Postconditions:
1.
2.
3.
4.
Select the patients

Doctors list created by their name.
Doctors can easily select the desire doctors
Profile of doctors will be open
Normal
Flow:
1.
2.
3.
4.
5.
Select the link of all doctors

List of all doctors will show.
Admin can select their desire doctors.
View the doctor profile.
Details of doctor will show.
Page32
1. Admin can search the doctors by his/her name.

2. Select the search doctors link list of doctors will be created
Alternative
Flows:
Exceptions:
Includes:
Special
Requirement
s:
Search doctors by his/her name and id.

1. Provide the list of all registered doctors
2. Search the doctors by name and id
Assumptions: Admin have knowledge of doctor id.
Notes and
Issues:
1. Maximum size of doctor username 11. That contain numbers and

characters
2. Maximum id, password size of doctors is 15. Contain numbers,
Use Case-ID:
SRR- 3.5.7
Use CaseName:
Search doctors details
Actors:
Admin
Description:
Admin can search the all doctors who already registered in the hospital
portal by their name and id. Admin can view all record of doctors
Trigger:
Open the search box to search the doctors
Preconditions:

2. Admin have rights to view the doctors details
Postconditions:
1.
2.
3.
4.
Enter the name or id of doctors

Doctors list created by their name.
Doctors can easily select the desire doctors
Profile of doctors will be open
Normal
Flow:
1.
2.
3.
4.
5.
Open search box

Enter the id or name of doctors.
Admin can select their desire doctors.
View the doctor profile.
Details of doctors will show.
Page33
1. Select the URL of select doctors

2. List of doctors will be created
3. Select the desire doctor
Alternative
Flows:
Exceptions:
Enter name and id of patient is incorrect
Includes:
Special
Requirement
s:
Open URL of select all doctor by his/her name and id.

Provide the list of all registered doctor
Assumptions: Admin have knowledge of doctor id.
Notes and
Issues:
Use Case-ID:
Use CaseName:
1. Maximum size of doctor username 11 contains numbers and

characters
2. Maximum id, password size of doctor is 15. Contain numbers,
SRR- 3.5.8
Delete doctors details
Actors:
Admin
Description:
Admin can delete the all doctor who already registered in the hospital
portal. Admin can delete all record of doctor
Trigger:
Open the list of doctor and select the desire doctor to delete
Preconditions:
Postconditions:
Normal
Flow:
Alternative
Flows:
1.
2.
3.
4.

2. List of doctor is shown
3. Desired doctor is selected
1. Select the desire doctor
2. Click on delete button.
3. Conformation box will open
4. Conform the delete doctor
5. Doctor will removed from the list
1. Select the link of all doctor or search the doctor
2. List of all doctors will show.
3. Admin can select their desire doctor.
5. Confirm the deletion of patient.
6. Doctor will removed from the list
Admin can conform and deny the conformation to delete the
doctor
Page34
5. If admin conform to delete doctor removed from the doctor list.

6. If admin deny to delete the doctor, doctor will not deleted from
list
Exceptions:
Includes:
Special
Requirement
s:
Search doctor by his/her name and id.

1. Provide the list of all registered doctor
2. Search the doctor by name and id
3. Delete the doctor
2. Admin know about the conformation to delete the doctor
Assumptions:
Notes and
Issues:

characters
characters, and special characters.
Use Case-ID:
SRR- 3.5.9
Use CaseName:
Register doctors
Actors:
Admin
Description:
Admin can register the all new doctors When doctors are new comers in
the hospital, hospital will provide the user name and password to them
Trigger:
Open the link of register doctors
Postconditions:
1.
2.
1.
2.
3.
4.
Normal
Flow:
5.
1.
2.
3.
Preconditions:

Register doctors panel from is already opened
Enter the details of doctor
Click on the register button.
Conformation box of registration of doctor will be open
If admin conform the registration doctor details will be saved to
server
Name of the doctor will be add in the list of doctors
Open the register doctor URL
Registration from will be opened
Admin will fill the form with doctor personal information and user
name and password
Alternative
Flows:
Exceptions:
If doctor is already registered than error message will be shown
Page35
Includes:
Special
Requirement
s:
1. Search doctors by his/her name and id.

2. Delete doctors
Name of the doctors will be added to the list of doctors
Assumptions: Admin have knowledge about the filling of registration
Notes and
Issues:

characters
Use Case-ID:
SRR- 3.5.10
Use CaseName:
Register pharmacists
Actors:
Admin
Description:
Admin can register the all new pharmacists When pharmacists are new
comers in the hospital, hospital will provide the user name and password
to them
Trigger:
Open the link of register pharmacists
Postconditions:
1.
2.
1.
2.
3.
4.
Normal
Flow:
5.
1.
2.
3.
Preconditions:

Register pharmacists panel from is already opened
Enter the details of pharmacists
Conformation box of registration of pharmacists will be open
If admin conform the registration pharmacists details will be
saved to server
Name of the pharmacists will be add in the list of pharmacists
Open the register pharmacists URL
Admin will fill the form with pharmacists personal
information and user name and password
Alternative
Flows:
Exceptions:
If pharmacists is already registered than error message will be shown
Page36
1. Search pharmacists by his/her name and id.

2. Delete pharmacists
Includes:
Special
Requirement Name of the pharmacists will be added to the list of pharmacists
s:
Notes and
Issues:
1. Maximum size of username 11 contains numbers and characters

2. Maximum id size, password of pharmacist is 15. Contain numbers,
Use Case-ID:
SRR- 3.5.11
Use CaseName:
View pharmacists
Actors:
Admin
Description:
Admin can view the all pharmacists who already registered in the hospital
portal. Admin can view all record of pharmacists
Trigger:
Open the link of view details of pharmacists
Preconditions:

2. Admin have rights to view the pharmacists details
Postconditions:
1.
2.
3.
4.
Select the patients

Pharmacists list created by their name.
Admin can easily select the desire patients
Profile of pharmacists will be open
1.
2.
3.
4.
5.
1.
2.
3.
Select the link of All pharmacists

Admin can select their desire pharmacists.
View the pharmacist profile.
Details of pharmacists will show.
Admin can search the pharmacists by his/her name.
Cancel the searching of pharmacists
Select the search pharmacists from list of pharmacists will be
created
Normal
Flow:
Alternative
Flows:
Exceptions:
Desired pharmacists not in the list
Includes:
Search pharmacists by his/her name and id.
Page37
Special
Requirement
s:
1. Provide the list of all registered pharmacists

2. Search the pharmacists by name and id
Assumptions:
1. Admin have knowledge of pharmacist id.

2. Desired pharmacists in the list
Notes and
Issues:
Use Case-ID:
Use CaseName:
Actors:
1. When admin select the list of pharmacists.

2. Pagination of pharmacists will be created
3. If pharmacists are not exists then error message of list empty
crated
SRR- 3.5.12
Delete pharmacists
Admin
Description:
Admin can delete the all pharmacists who already registered in the
hospital portal. Admin can delete all record of pharmacists. Open the list
of pharmacists and select the desire pharmacists to delete
Trigger:
When the admin clicks on delete.
Preconditions:

2. List of pharmacists is shown
3. Desired pharmacists is selected
Postconditions:
1. The pharmacists record should be removed

2. If pharmacist is logged in, he should be removed at that time.
Normal
Flow:
Alternative
Flows:
Exceptions:
Includes:
1.
2.
3.
4.
5.
1.
2.
3.
4.
5.
6.
1.
2.
3.
4.
5.
Select the desire pharmacists

Conformation box will open
Conform the delete patient
Pharmacists will removed from the list
Select the link of all pharmacists or search the pharmacists
List of all pharmacists will show.
Admin can select their desire pharmacists.
Confirm the deletion of pharmacists.
Pharmacists will removed from the list
Admin can select the multiple users from list to delete.
Admin can confirm / deny the confirmation to delete them.
Admin confirms to delete pharmacists removed from the list.
Page38
Special Req:
Search pharmacists by his/her name and id.

1. Provide the list of all registered pharmacists
Assumptions:
2. Search the pharmacists by name and id
3. Delete the pharmacists
2. Admin know about the conformation to delete the
pharmacists
Notes and
Issues:
Use Case-ID:
SRR- 3.5.13
Use CaseName:
Register front desk user
Actors:
Admin
Description:
Admin can register the all new front desk When front desk are new
comers in the hospital, hospital will provide the user name and password
to them
Trigger:
Open the link of register front desk
Preconditions:
Postconditions:
Normal Flow:
1.
2.
1.
2.
3.
4.
5.
1.
2.
3.

Register front desk panel from is already opened
Enter the details of front desk
Conformation box of registration of front desk will be open
If admin confirm the registration front desk details will be
saved to server
Name of the front desk will be add in the list of front desk
Open the register front desk URL
Admin will fill the form with front desk personal information
and user name and password
Alternative
Flows:
Exceptions:
Includes:
Special
Requirement
s:
If front desk is already registered than error message will be shown

1. Search front desk by his/her name and id.
2. Delete front desk
Name of the front desk will be added to the list of front desk
Page39
1. Maximum size of front desk name 11. That contain numbers

and characters
2. Maximum id size, password of front desk is 15. Contain
numbers, characters, special characters
Notes and
Issues:
Use Case-ID:
SRR- 3.5.14
Use CaseName:
View front desk user
Actors:
Admin
Description:
Admin can view the all front desk who already registered in the hospital
portal. Admin can view all record of front desk
Trigger:
Open the link of view details of front desk
Preconditions:

2. Admin have rights to view the front desk details
Postconditions:
1.
2.
3.
4.
Select the patients

Front desk list created by their name.
Admin can easily select the desire patients
Profile of front desk will be open
1.
2.
3.
4.
5.
1.
2.
3.
Select the link of All front desk

Admin can select their desire front desk.
View the pharmacist profile.
Details of front desk will show.
Admin can search the front desk by his/her name.
Cancel the searching of front desk
Select the search front desk from list of front desk will be
created
Normal
Flow:
Alternative
Flows:
Exceptions:
Desired front desk not in the list
Includes:
Special
Requirement
s:
Search front desk by his/her name and id.
Assumptions:
1. Provide the list of all registered front desk

2. Search the front desk by name and id
2. Desired front desk in the list
Page40
1. When admin select the list of front desk.

2. Pagination of front desk will be created
3. If front desk are not exists then error message of list empty
crated
Notes and
Issues:
Use Case-ID:
Use CaseName:
SRR- 3.5.15
Delete front desk user
Actors:
Admin
Description:
Admin can delete the all front desk who already registered in the hospital
portal. Admin can delete all record of front desk
Trigger:
When he clicks the buuton
Preconditions:
Open the list of front desk and select the desire front desk to delete
2. List of front desk is shown
3. Desired front desk is selected
Postconditions:
Normal
Flow:
Alternative
Flows:
Exceptions:
1.
2.
3.
4.
5.
6.
Includes:
Special
Requirement
s:
1. Select the desire front desk

3. Conformation box will open
4. Conform the delete patient
5. Front desk will removed from the list
1. Select the link of all front desk or search the front desk
2. List of front desk will be shown.
3. Admin can select their desire front desk.
5. Confirm the deletion of front desk.
6. Front desk will removed from the list
Admin can conform and deny the conformation to delete the front
desk
If admin conform to delete front desk removed from the front desk
list.
If admin deny to delete the front desk, front desk will not deleted
from list
Search front desk by his/her name and id.
Page41
Assumptions:
1. Provide the list of all registered front desk

2. Search the front desk by name and id
3. Delete the front desk
Notes and
Issues:

2. Admin know about the conformation to delete the front desk
Use Case-ID:
SRR- 3.5.16
Use CaseName:
Add medicines of pharmacy
Actors:
Admin
Description:
Admin can add the medicines details in inventory system of hospital

pharmacy
Trigger:
Open the URL inventory system of pharmacy
Preconditions:

2. Inventory module is already open
Postconditions:
1.
2.
3.
4.
5.
Select open inventory system

Select the add inventory link.
Select the medicines to add
Enter the medicines detail(name price and quantity)
Medicine will include in the list
Normal
Flow:
1.
2.
3.
4.
5.
Admin open the inventory system.

Click on the add inventory
Select the medicines to add
Enter the medicines details
If medicines if successfully added message is shown
Alternative
Flows:
Exceptions:
1. If admin not add the details of medicines (name price and quantity)
2. Error message will be shown
Includes:
Delete, edit and view inventory
Special
Requirement
s:
If admin enter the all details of medicines than medicines will be added to
the sock
Page42
1. Admin have knowledge of medicines details.

2. Admin is able to fill the all details of medicines
Assumptions:
Notes and
Issues:
Every medicines have unique name and id with bar code
Use Case-ID:
SRR- 3.5.17
Use CaseName:
View medicines of pharmacy
Actors:
Admin
Description:
Admin can view the inventory of pharmacy. If admin view the medicines
detail he/she will view the medicines name, price, quantity and
description.
Trigger:
Open the link of view medicines detail
Preconditions:
Postconditions:
Normal
Flow:
1.
2.
1.
2.
3.

Inventory system of pharmacy already opened
Select the inventory system link from home page
Medicines will be selected
Details of medicines will be shown
1.
2.
3.
4.
Open the inventory system of pharmacy.

Select view medicines
List of medicines will be created
Select the desire medicines to view and check its detail
Alternative
Flows:
Exceptions:
if medicines stock is empty than its quantity is empty(0)
Includes:
Add and delete medicines from inventory system of pharmacy
Special
Requirement
s:
Assumptions:
Admin have knowledge of pharmacy medicines, know the name quantity

and price of medicines
Page43
1. Every medicines have unique name.

2. Quantity of medicines in grams
Notes and
Issues:
Use Case-ID:
SRR- 3.5.18
Use CaseName:
Delete medicines of pharmacy
Actors:
Admin
Description:
Admin can delete the inventory of pharmacy. If admin view the medicines
detail he/she will able to delete the medicines.
Trigger:
1. Open the link of view medicines detail

2. Select the desire medicines to delete.
Preconditions:

2. Inventory system of pharmacy already opened
3. Admin already marked the medicines to delete
Postconditions:
1. Marked medicines deleted from the list

2. Confirmation box conform the deletion from admin
Normal
Flow:
1.
2.
3.
4.
Alternative
Flows:
1. Search the medicines by their id or name

2. Marked the medicines to delete
3. Conform the deletion
Open the inventory system of pharmacy.

Select view medicines
List of medicines will be created
Marked the desire medicines to delete
Exceptions:
Includes:
Special
Requirement
s:
Assumptions:
Notes and
Issues:
View, add, search medicines
Admin have knowledge about medicines and how to use inventory

system of pharmacy
1. Name of medicines will be unique
2. Quantity of medicines in grams
Page44
Use Case-ID:
SRR- 3.5.19
Use CaseName:
Search medicines of pharmacy
Actors:
Admin
Description:
Admin can search the all medicines in inventory system of pharmacy

including searching of medicines by their id and name
Trigger:
Open the search box to search the medicines from inventory system of
pharmacy
Preconditions:

2. Inventory system of pharmacy is already opened
Postconditions:
1.
2.
3.
4.
Enter the name or id of doctors in search box

Medicine list will be created.
Admin can easily select the desire doctors
details of medicines will be open
Normal Flow:
1.
2.
3.
4.
Open search box from inventory system of pharmacy

Enter the id or name of medicines.
Admin can select their desire medicines.
View the details desire medicines.
Alternative
Flows:
1. Select the URL of view all medicines

2. List of medicines will be created
3. Select the desire medicines from list
Exceptions:
1. Enter name and id of medicines is incorrect

2. Message will be shown
Includes:
Special
Requirement
s:
Open URL of select all doctor by his/her name and id.

Provide the list of all medicines with in one second
Assumptions: Admin have knowledge of medicines.

Notes and
Issues:
Page45
Use Case-ID:
SRR- 3.5.20
Use CaseName:
View bills record of pharmacy
Actors:
Admin
Description:
Admin can view the all bills record of pharmacy.
Trigger:
Open the link of view details of bills record of pharmacy
Preconditions:
Postconditions:
1. Select the bills record then select the bills record of pharmacy
2. List of bills record of patient will be created.
3. Every bill contain total amount with patient name
Normal Flow:
1. Select the link of bills record of patient

2. List of all bills records will show along with patient name.
3. Admin can select their desire bill and its details.
Alternative
Flows:
Exceptions:
Includes:
Special
Requirements Provide the list of all bills with patient name
:
Assumptions:
Notes and
Issues:

2. Admin know the English language
Page46
4.
SpecificRequirements
4.1
Functionality
4.1.1
Patientfunctionalrequirement
4.1.1.1 Sign in
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
2.1
Patientselectthesignin
Patientshallbeabletosignintothesystem
Stakeholder
High
4.1.1.2 Sign out
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
2.2
Patientselectthesignout
Patientshallbeabletosignout.
Stakeholder
2.1
High
4.1.1.3 Sign up
Patientwillbeabletologinandlogoutforuserauthentication.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
2.3
Patientselectthesignup
Patientshallbeabletosignup.
Stakeholder
High
4.1.1.4 Update profile

Patientshouldbeabletoupdatehisprofile.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
2.4
Patientselectupdateprofile
Patientshallbeabletoupdateprofile
Stakeholder
2.1
High
Page47
4.1.1.5 Get his/her own appointment
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
2.5
Patientselectgetappointment
Doctorshallbeabletogettheappointment.
Stakeholder
2.1
High
4.1.1.6 View his/her own appointment
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
2.6
Patientselectviewprescription
Patientshallbeabletoviewprescription.
Stakeholder
2.1
High
4.1.1.7 View doctors list

Patientshallbeabletogetappointmentsbysearchingdoctors.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
2.7
Patientselectviewdoctorslist.
Patientshallbeabletoviewdoctorslist.
Stakeholder
2.1
High
4.1.1.8 View prescriptions
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
2.8
Patientselectviewprescriptions.
Patientshallbeabletoviewprescriptions.
Stakeholder
2.1
High
4.1.1.9 View bills

Patientshallbeabletoviewhisolderprescriptionsandbillspaid/unpaidtomanagehisreallife.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.2
2.9
Patientselectviewbills
Doctorshallbeabletoviewbills
Stakeholder
2.1
High
Pharmacistfunctionalrequirement
Page48
4.1.2.1 Login
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
3.1
Pharmacistsselectthelogin.
Pharmacistsshallbeabletoselectthelogin.
Stakeholder
High
4.1.2.2 Logout
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
3.2
Pharmacistsselectthelogout.
Pharmacistsshallbeabletoselectthelogout.
Stakeholder
3.1
High
4.1.2.3 Print bills
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
3.3
Pharmacistsselecttheprintbills.
Pharmacistsshallbeabletoselectprintbills.
Stakeholder
3.1
High
4.1.2.4 Print prescriptions
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
3.4
Pharmacistsselecttheprintprescription.
Pharmacistsshallbeabletoprintprescription.
Stakeholder
3.1
High
4.1.2.5 Report generation
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
3.5
Pharmacistsselectthereportgeneration.
Pharmacistsshallbeabletoselectthereportgeneration.
Stakeholder
3.1
High
4.1.2.6 View prescriptions
Identifier
Title
Requirement
Source
Rationale
Dependencies
3.6
Pharmacistsselecttheviewprescription.
Pharmacistsshallbeabletoselecttheviewprescription.
Stakeholder
3.1
Page49
Priority
High
4.1.2.7 View Notification
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.3
3.7
Pharmacistsselecttheviewprescription.
Pharmacistsshallbeabletoselecttheviewnotification.
Stakeholder
3.1
High
Frontdeskfunctionalrequirement
4.1.3.1 Login
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1
Frontdeskuserlogin
Frontdeskusershallbeabletologin
Stakeholder
Usefrontdesksystem
High
4.1.3.2 Logout
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.2
Frontdeskuserlogout
FrontdeskusershallbeabletoLogout
Stakeholder
4.1
High
4.1.3.3 Register patients
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.3
Frontdeskuserregisterthepatient
Frontdeskusershallbeabletoregisterthepatient
Stakeholder
4.1
High
4.1.3.4 Schedule appointments
Identifier
Title
4.4
Frontdeskuserschedulethepatientappointment
Page50
Requirement
Source
Rationale
Dependencies
Priority
4.1.4
Frontdeskusershallbeabletoschedulethepatientappointment
Stakeholder
4.3
High
Adminfunctionalrequirement
4.1.4.1 Login
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.1
Adminlogin
Adminshallbeabletologin
Stakeholder
High
4.1.4.2 Logout
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.2
Adminlogout
AdminshallbeabletoLogout
Stakeholder
5.1
High
4.1.4.3 Register doctors
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.3
Adminregisterdoctors
Adminshallbeabletoregisterdoctorsinthesystem
Stakeholder
5.1
High
4.1.4.4 Register front desk receptionist.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.4
Adminregisterfrontdeskreceptionist
Adminshallbeabletoregisterfrontdeskreceptionistinthe
system
Stakeholder
5.1
High
Page51
4.1.4.5 Add pharmacy inventory.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.5
Addpharmacyinventory
Adminshallbeabletoaddpharmacyinventory
Stakeholder
5.1
High
4.1.4.6 Delete pharmacy inventory.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.6
Deletepharmacyinventory
Adminshallbeabletodeletepharmacyinventory
Stakeholder
5.5
High
4.1.4.7 Search pharmacy inventory.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.7
Searchpharmacyinventory
Adminshallbeabletosearchthepharmacyinventory
Stakeholder
5.5
High
4.1.4.8 View pharmacy inventory.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.8
Viewpharmacyinventory
Adminshallbeabletoviewpharmacyinventory
Stakeholder
5.5
High
4.1.4.9 Add store room inventory.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.10
5.9
Addstoreroominventory
Adminshallbeabletoaddstoreroominventory
Stakeholder
5.1
High
Delete store room inventory.
Identifier
Title
Requirement
Source
5.10
Deletestoreroominventory
Adminshallbeabletodeletestoreroominventory
Stakeholder
Page52
Rationale
Dependencies
Priority
5.9
High
4.1.4.11View doctor details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.12
5.3
High
5.15
Deletedoctorsdetails
Adminshallbeabletodeletedoctordetails
Stakeholder
5.3
High
View patient details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.15
5.14
Searchdoctorsdetails
Adminshallbeabletosearchdoctordetails
Stakeholder
Delete doctor details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.14
5.3
High
Search doctor details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.13
5.13
Viewdoctorsdetails
Adminshallbeabletoviewdoctordetails
Stakeholder
5.16
Viewpatientsdetails
Adminshallbeabletoviewpatientsdetails
Stakeholder
5.3
High
Search patient details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
5.17
Searchpatientsdetails
Adminshallbeabletosearchpatientdetails
Stakeholder
5.3
Page53
Priority
4.1.4.16
Delete patient details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.17
5.19
Adminregisterpharmacists
Adminshallbeabletoregisterpharmacistsinthesystem
Stakeholder
5.1
High
5.20
Viewpharmacistsdetails
Adminshallbeabletoviewpharmacistsdetails
Stakeholder
5.19
High
Search pharmacist details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.20
5.3
High
View pharmacist details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.19
5.18
Deletepatientdetails
Adminshallbeabletoviewpatientdetails
Stakeholder
Register pharmacists
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.18
High
5.21
Searchpharmacistsdetails
Adminshallbeabletosearchpharmacistsdetails
Stakeholder
5.19
High
Delete pharmacist details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
5.22
Deletepharmacistsdetails
Adminshallbeabletodeletepharmacistsdetails
Stakeholder
5.19
High
Page54
4.1.4.21
View front desk user details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.22
5.4
High
5.25
Viewfrontdeskdetails
Adminshallbeabletodeletefrontdeskuserdetails
Stakeholder
5.4
High
View bill records of pharmacy
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.2
5.24
Viewreceptionistdetails
Adminshallbeabletosearchfrontdeskuserdetails
Stakeholder
Delete front desk user details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.24
5.4
High
Search front desk user details.
Identifier
Title
Requirement
Source
Rationale
Dependencies
Priority
4.1.4.23
5.23
Viewfrontdeskdetails
Adminshallbeabletoviewfrontdeskuserdetails
Stakeholder
5.26
Viewbillsrecordofpharmacy
Adminshallbeabletoviewbillsrecordofpharmacy
Stakeholder
5.5
High
Usability
The training time of normal user is 45minutes and for expert user less than 30 minutes.
When user logs in to the system the login time is less than 1second. Every event occur in the system
has time less than 1 second.
The graphical user interface of a authentication process is a standard interface having all functionalities
of login and logout function.
There is no restriction on the number of the users to be added to the database.
Page55
4.3
System is compatible to all workstations that fulfill the minimum system requirements and the design of
the system would be such that the response time will be as low as possible.
Reliability
Availability
The system will be available all over the time.
Italsodependsontheinternetavailability.
Mean Time between Failures (MTBF)
Therecoverytimeoffailuresystemwillbe12hours,ifthesystemcrashes.
Maximum Bugs or Defect Rate
5bugsinonethousandlinesofcode
Bugs or Defect Rate

The type of bugs which can occur in our project will not be serious bugs.
Thebugswillbeofminortypethatwouldbeeasytorecoverortrace.
4.4
Performance
4.4.1
Responsetime
Responsetimeforloadingapageis3seconds
4.4.2
Memoryconsumption
100MBwillberequiredtoinstalltheandroidapplicationforthedoctor.
4.4.3
Capacityofvisitors
Thepageloadrequestofclientsusingwebsiteis100usersperday.
5060MBwillberequiredforittobeinrunningform(onRAM)
Page56
4.5
Supportability
ThesystemwillbesupportableonInternetExplorer,Safari,Mozillaandchrome
4.6
DesignConstraints
4.6.1
WebPortal
The system shall be built using standard webpage development Languageshtmlandhtml5,

CSS,JavaScript,PHPandMySQL
Thesewillbeusedintools:
Dreamviewer
WampServer
4.7
PurchasedComponents
Websitedomain
Pc
4.8
Interfaces
4.8.1
UserInterfaces
The proposed application will interface with user in order to manage the tasks/features, which are
mentioned above. The dialogues to be established must be simple and easily understandable.
Step-By-Step interfaces will be provided to user for the process.

Start, Exit, Cancel, Reset, Delete, and Submit buttons will be provided.
It will allow the user to interact with the product using mouse and keyboard.
4.8.2
HardwareInterfaces
Intel Pentium IV 800MHz processor or equivalent
512MB of RAM
Running Windows XP/Vista/Win7/Win8
Pc
Page57
4.8.3
SoftwareInterfaces
The application will interface with the system software and also with the user through a friendly
user interface. The entire system will developed in the DreamweaverCS5andWAMPserver
Using the html, html5, CSS, PHP, MySQL language
Following software will be needed to complete OHMS
Adobe Dreamweaver CS5 for coding and Designing

WAMP server for connectivity with Database
Microsoft Visio for use cases and flow diagrams
Microsoft Office-for Documentation
Microsoft Project for Gantt Chart
Web application
4.8.4
CommunicationsInterfaces
Our for Ali Hospital Gujarkhan is a android and web-based application .So, our system is used for
communication between the server side and User side. And also communication between android application
and web application for transfer of prescription
4.9
LicensingRequirements
4.9.1
Legal,Copyright,andOtherNotices
5.
SupportingInformation
Index
Automated 4
Administration, 4
C
Constraints, 70
Page58
D
Definition, 5
Design 69,70
E
Edit, 9,30
F
Functional Requirements, 6,4
H
Hardware, 38
I
Introduction, 4
L
Login , 9, 69
Logout, 67
P
Purpose, 4
S
Software Interface, 71
U
Use case, 9
User Interface, 69, 71
Page60
Class diagram
Page60

SRS Final Fari Ori

Uploaded by

Document Information

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

SRS Final Fari Ori

Uploaded by

Copyright:

Available Formats

Software Requirements Specification

Hospital Management System

IEEE Software Requirements

Windows, Apache, MySQL, PHP

An object-oriented computer programming language commonly used to

Hypertext Markup Language, a standardized system for tagging text files

MySQL, the most popular Open Source SQL database management

Time consuming: Need extra manual effort.

Difficult to locate a particular patient or employee data at the time of need.

Danger of losing a file in some cases.

Very fast and accurate.

No need of any extra manual effort.

No fear of data loss.

Just need a little knowledge to operate the system.

Very easy to find the record.

Want to be checked up, check his/her

Registers the patients and gives the

Monitors the System for any

User Technical Expertise

Basic understanding of Computer

Basic understanding of Computer

2.4.2 Hardware Limitations

Description: Patient can select sign up option on web portal.

Patient should have to be on web main page.

Post-conditions: Patient should be successfully registered.

Patient go to web main page

Validate the patient information within 1 second.

1. Patients understand English language.

Description: Patient can select sign in option on web portal.

Patient should have to be on web main page.

Post-conditions: Patient should be successfully login to his/her account.

Patient go to web main page

Includes: Validate patient username and password.

Validate the patient username and password within 1 second.

1. Patients understand English language.

Description: Patient can select update option from profile option.

Patient should have to be logged in to his/her account.

Post-conditions: Patient profile should be successfully updated.

Patients select profile option.

Includes: Validate patient information.

Validate the patient information within 1 second.

1. Patients understand English language.

Get appointment online

Description: Patient can get appointment from the doctor online.

1. Patient should have to be logged in to his/her account.

Select get appointment option.

Exceptions: If doctor is not selected he/she cannot get appointment.

Validate the doctors information within 1 second.

1. Patients understand English language.

View appointments details

Description: Patient can see its own appointments details.

1. Patient should have to be logged in to his/her account.

All appointments should be displayed..

1. Select appointments option.

Includes: Validate patient appointments.

Validate the patient appointments within 1 second.

1. Patients understand English language.

Description: Patient can see its prescriptions record.

3. Patient should have to be logged in to his/her account.

All prescription should be displayed..

3. Select view prescription option.

Includes: Validate patient information

Validate the patient information within 1 second.

1. Patients understand English language.