srs final fari ori

68
Software Requirements Specification For Hospital Management System Version 3.0 Prepared by

Upload: waqas

Post on 16-Jan-2016

249 views

Category:

Documents


0 download

DESCRIPTION

srs document

TRANSCRIPT

Page 1: SRS Final Fari Ori

Software Requirements Specification

For

Hospital Management System

Version 3.0

Prepared by

Page 2: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage ii

Table of Contents

Revision History......................................................................................................................... iii1. Introduction.......................................................................................................................... 4

1.1 Purpose..................................................................................................................................41.2 Scope.....................................................................................................................................41.3 Definitions, Acronyms and Abbreviations...............................................................................51.4 References..............................................................................................................................51.5 Overview................................................................................................................................5

2. Overall Description.............................................................................................................. 62.1 Product perspective................................................................................................................62.2 Product Function....................................................................................................................62.3 User Characteristics................................................................................................................72.4 Constraints.............................................................................................................................82.5 Assumptions and Dependencies..............................................................................................82.6 Requirements subsets.............................................................................................................8

3. Use Cases.............................................................................................................................. 83.1 Use cases of Doctor................................................................................................................83.2 Use cases of Patient..............................................................................................................183.3 Use cases of Pharmacist........................................................................................................273.4 Use cases of Front-desk........................................................................................................343.5 Use cases of Admin..............................................................................................................38

4. Specific Requirements........................................................................................................ 624.1 Functionality........................................................................................................................624.2 Usability...............................................................................................................................734.3 Reliability............................................................................................................................744.4 Performance.........................................................................................................................744.5 Supportability.......................................................................................................................744.6 Design Constraints...............................................................................................................744.7 Purchased Components.........................................................................................................754.8 Interfaces..............................................................................................................................754.9 Licensing Requirements.......................................................................................................76

5. Supporting Information..................................................................................................... 76

6. Diagram

6.1 class diagram........................................................................................................................586.2 state chart diagram................................................................................................................59

Page 3: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage iii

Revision History

Name Date Reason For Changes Version

Page 4: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 4

IEEE Software RequirementsSpecification 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, non-functional requirements, constraints and use-cases. It deals with the collection of patient’s information, employee management including doctors, administration, pharmacy, billing managers and the front-desk.

The other purpose of this document is to make the stakeholders aware of what we are making for them. This makes a better communication between the stakeholders and the Software company / developers

1.2 Scope

The purpose of this project is to develop software which is user friendly, simple, fast, and cost effective. It deals with the collection of patient’s information, and digital prescription system, desk system, patient system, pharmacy system, admin system.

1.2.1 Modules:

.

1. Database management system

2. Inventory system of pharmacy

3. Web application

3.1 Admin panel3.2 Patients/users’ panel3.3 Pharmacist panel3.4 Front Desk panel3.5 Doctor information

Page 5: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 5

1.3 Definitions, Acronyms and Abbreviations

Terms Definition

WAMP Windows, Apache, MySQL, PHP

JavaScript An object-oriented computer programming language commonly used to create interactive effects within web browsers.

HtmlHypertext Markup Language, a standardized system for tagging text files to achieve font, color, graphic, and hyperlink effects on World Wide Web pages.

CSSCascading 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 widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.

DOB Date of Birth.

1.4 References

IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications. SRS template: http://www.ciitfyp.com/Pages/Student/Resources.aspx http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf SRS version 1.0

1.5 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.

Page 6: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 6

2. Overall Description

2.1 Product perspective

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.

The proposed system provides patient’s information, employee management including doctors and staff. It enhances the admin to adding, viewing and updating patients, staff, billing and pharmacy 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 Product Function

2.2.1 Patient’s 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 Doctor Information

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 Admin Information

Page 7: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 7

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 Pharmacy information

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 Front desk receptionist

This module deals with the management of patient appointments, generates tokens and registration of new patients.

2.3 User Characteristics

The main user of the system is the admin and employee but patients are also going to use it. The following table describes general user’s 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 User Technical Expertise

Patient Want to be checked up, check his/herAccount settings, print test result.

Basic understanding of Computer.

Receptionist Registers the patients and gives the command to print their respective tokens

Doctor Provides his services, updates his/her account settings, check patient’sprofile.

Basic understanding of Computer

Pharmacist Maintains pharmacy inventoryProvides bill for the patientsUses the bar-code scanner.

Basic understanding of Computer

Admin Monitors the System for anyUn-expected behavior. Adds / edits/deletes the patient’s, doctor’s, receptionist’s and pharmacist’sinformation.

Basic understanding of Computer and experience in management.

2.4.2 Hardware LimitationsFor user should have Pantium4 or above(core, duel core, core i3 etc)

Page 8: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 8

3. Use Cases

3.1 Use cases of Patient

Use Case-ID: SRR 3.2.1

Use Case-Name: 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:

1. Patient go to web main page 2. Select sign up 3. Enter personal information 4. Select submit.

Alternative Flows: No

Exceptions: Patient cannot be registered without personal id card number or have no access to web main page.

Includes:Validate patient information.

Special Requirements: Validate the patient information within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Page 9: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 9

Use Case-ID: SRR3.2.2

Use Case-Name: 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:

1. Patient go to web main page 2. Select sign in. 3. Enter username and password.4. Select sign in.

Alternative Flows: No

Exceptions: 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: Validate the patient username and password within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Page 10: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 10

Use Case-ID: SRR 3.2.3

Use Case-Name: Update profile

Actors: 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:

1. Patients select profile option.2. Select update option.3. Changes the unrestricted desired fields.4. Select save changes.

Alternative Flows: No

Exceptions: 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: Validate the patient information within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Page 11: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 11

Use Case-ID: SRR 3.2.4Use Case-

Name: View available doctors list

Actors: PatientDescription: 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.

Normal Flow: 1. Patients select available doctors option.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 Requirements: Validate the doctors information within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Use Case-ID: SRR 3.2.5Use Case-

Name: Select doctor

Actors: PatientDescription: Patient can select doctor from doctors list.

Trigger: Click on doctor name.

Pre-conditions: 1. Patient should have to be logged in to his/her account.2. Patient should have searched doctors list.

Post-conditions: Doctor should be selected .

Normal Flow: 1. Patient have doctors list.2. Select doctor from the list.

Alternative Flows: No

Exceptions: If patient is not signed in then he/she cannot view available doctors list.If doctors list is not displayed then he/she cannot select the doctor.

Includes: Validate doctor information.Special

Requirements: Validate the doctor information within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Use Case-ID: SRR 3.2.6

Page 12: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 12

Use Case-Name: Get appointment online

Actors: Patient

Description: Patient can get appointment from the doctor online.

Trigger: Click on get appointment option.

Pre-conditions:1. Patient should have to be logged in to his/her account.2. Patient should have searched doctors list.3. Patient should have selected doctor

Post-conditions: Appointment message send to doctor account.

Normal Flow:

1. Select get appointment option.2. View appointment time.3. Select appointment time.4. Send message.

Alternative Flows: No

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

Includes: Validate doctors information.

Special Requirements: Validate the doctors information within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Use Case-ID: SRR 3.2.7

Page 13: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 13

Use Case-Name: View appointments details

Actors: Patient

Description: Patient can see its own appointments details.

Trigger: Click on appointments option.

Pre-conditions:1. Patient should have to be logged in to his/her account.2. Patient should have appointments records.

Post-conditions: All appointments should be displayed..

Normal Flow:1. Select appointments option.2. See appointments details.

Alternative Flows: No

Exceptions: If no appointments is displayed that means patient have no appointments records or patient is new.

Includes: Validate patient appointments.

Special Requirements: Validate the patient appointments within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Use Case-ID: SRR 3.2.8

Page 14: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 14

Use Case-Name: View prescriptions

Actors: Patient

Description: Patient can see its prescriptions record.

Trigger: Click on view prescription option.

Pre-conditions:3. Patient should have to be logged in to his/her account.4. Patient should have prescription records.

Post-conditions: All prescription should be displayed..

Normal Flow:3. Select view prescription option.4. See all prescription records.

Alternative Flows: No

Exceptions: If no prescription is displayed that means patient have no prescription records or patient is new.

Includes: Validate patient information

Special Requirements: Validate the patient information within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Use Case-ID: SRR 3.2.8

Page 15: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 15

Use Case-Name: View bills history

Actors: Patient

Description: Patient can see his/her bills record.

Trigger: Click on bills record option.

Pre-conditions:5. Patient should have to be logged in to his/her account.6. Patient should have bills records.

Post-conditions: All prescription should be displayed..

Normal Flow:5. Select bills history.6. See all bills records.

Alternative Flows: No

Exceptions: If no bill is displayed that means patient have no bill records or patient is new.

Includes: Validate patient information

Special Requirements: Validate the patient information within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

Use Case-ID: SRR 3.2.9

Page 16: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 16

Use Case-Name: Sign out

Actors: 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: Exit from patient profile and Redirected to website main page.

Normal Flow:1. Select profile option2. Select sign out option 3. Redirect to website main page

Alternative Flows: No

Exceptions: If patient is not logged in then he/she cannot sign out .

Includes: Validate patient information

Special Requirements: Validate the patient information within 1 second.

Assumptions: 1. Patients understand English language. 2. Familiar with the websites. 3. Wi-Fi connection available

Notes and Issues: No

3.2 Use cases of Pharmacist

Use Case-ID: SRR- 3.3.1

Page 17: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 17

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 If the he enters the Url of the login page2 Signs out.

Pre-conditions: 1 Pharmacist is active on the internet.2 Pharmacist has an account.

Post-conditions: 1 Pharmacist should be logged-in successfully.2 If wrong attempt is made, redirect him to sign-in page

Normal Flow:

1 Pharmacist is present on the sign-in page.2 Pharmacist enters his username.3 Pharmacist enters his Password.4 Clicks/Enters on Sign-in button.5 System validates if pharmacist is in Hospital network.6 Pharmacist is directed to his account-page.

Alternative Flow: No Alternative flow.

Exceptions:

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.

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.

Includes: 1 Validate username and password.2 After validating account create a session for the user.

Special Req.: Validate the username and password with in one second

Assumptions:1 Pharmacist understands English language.2 Pharmacist understands medical terms.3 Pharmacist can operate the computer.

Notes and Issues:

1 Maximum length of username 11, password 15 containing digits and characters

Page 18: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 18

Use Case-ID: SRR- 3.3.3

Use Case-Name: Print bill

Actors: Pharmacist

Description:The pharmacist will print the bill of the displayed prescription if the 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.

Pre-conditions:

1 If the pharmacist has clicked on the prescription from notifications or by coming on this step by searching his prescription by patient-ID.

2 Bill has been prepared by the pharmacist using bar-code reader3 Pharmacist login session is not expired.

Post-conditions:1 The bill should be printed.2 The pharmacist should see the prescription view again3 The pharmacy inventory should be updated

Normal Flow:

1 Pharmacist is present on the prescription view page.2 The bill has been prepared.3 Pharmacist clicks on print bill.4 The bill is printed.

Alternative Flow: No alternative flows

Exceptions:

2a. In step 2 of the normal flow, if pharmacist does not create bills1 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 bills1 If the bill has been fully/partially paid once2 The error is displayed that the bill has already been printed.

Includes: 1 Session active2 Create bills

Special Requirements:

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

Assumptions:

1 Pharmacist understands English language.2 Pharmacist understands Urdu language.3 Pharmacist understands medical terms.4 Pharmacist can operate the computer.

Notes and Issues:

1 The bill is paid or unpaid2 Total bill paid and unpaid should be updated.

Use Case-ID: SRR- 3.3.4

Page 19: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 19

Use Case-Name: Print prescriptions

Actors: Pharmacist

Description: The pharmacist will print the displayed prescription.

Trigger: If the pharmacist clicks on the print prescription command.

Pre-conditions:

1 If the pharmacist has clicked on the prescription from notifications or by coming on this step by searching his prescription by patient-ID.

2 Pharmacist login session is not expired

Post-conditions: 1 The prescription should be printed.2 The pharmacist should see the prescription view again

Normal Flow:1 Pharmacist is present on the prescription view page.2 Pharmacist clicks on print prescription.3 The prescription is printed.

Alternative Flows:

The pharmacist can print prescription of the patient on some other day, if he has lost the prescriptions hard-copyThen 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 Pharmacist understands English language.2 He knows medical terms.3 He can use the computer.

Notes and Issues: Only printing prescription money collecting is done manually.

Use Case-ID: SRR- 3.3.5Use Case-

Name: Edit prescription

Page 20: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 20

Actors: Pharmacist

Description:If the patient wants to take less/more amount of medicine then the 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: 1 Pharmacist is on the prescription view page2 Login session is not expired.

Post-conditions: The prescription should be opened in an editing mode provided with tools such as rubber, pen etc.

Normal Flow:

1 Pharmacist is present on the prescription view page.2 Pharmacist clicks on edit prescription.3 The prescription is opened in editing mode.4 The prescription is saved, after editing.5 Pharmacist is directed to prescription-view page again, from

where he started this use-case.

Alternative Flows:

The pharmacist comes here by searching prescription using patient-ID instead from notifications.

Exceptions:

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.

4a. In step 4 of the normal flow, if login-session is expired1 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 Pharmacist knows about paint in computer.2 Pharmacist understands English language.3 Pharmacist understands medical terms.4 Pharmacist can operate the computer.

Notes and Issues: None

Use Case-ID: SRR- 3.3.6

Use Case-Name: Sign out pharmacy

Page 21: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 21

Actors: Pharmacist

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 The pharmacist’s login-session will be destroyed.2 The pharmacist will be redirected to home page.

Normal Flow:

1 Pharmacist is on any logged-in valid page2 He/she clicks on the sign-out link.3 System will destroy user’s login-session.4 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 Pharmacist understands English language.2 He knows medical terms.3 He can use the computer.

Notes and Issues: None.

Use Case-ID: SRR- 3.3.8

Page 22: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 22

Use Case-Name: Search patients

Actors: Pharmacist

Description:The pharmacist will have to search patients using their unique-ID or the name if the patient comes without prescription to print the older prescription.

Trigger: The pharmacist clicks on the search patient button

Pre-conditions: 1 The pharmacist should be logged-in2 The pharmacist has to be on his account home-page.

Post-conditions:

1 The result should be found / not found depending on the valid / invalid input.

2 Patient with its hyper-link should be displayed to go the prescriptions view page.

Normal Flow:

1. Pharmacist is present on the home account-page2. Pharmacist clicks on the search button.3. System verifies session of login and validates.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

Exceptions: 4a. In step 4 of the normal flow, if patient-ID is not valid1 No result found is displayed.

Includes: None.

Special Requirements:

1 No wrong information should be displayed.2 The speed should be at most 3 seconds.

Assumptions:1 Pharmacist understands English language.2 Pharmacist knows the structure of patient-ID.3 Pharmacist can operate the computer.

Notes and Issues:

3 The bill is paid or unpaid4 Total bill paid and unpaid should be updated.

Assumptions:

1 Pharmacist understands English language.2 Pharmacist should be aware of data entry3 He knows medical terms.4 He can use the computer.

Notes and Issues: Pharmacist should enter inventory using keyboard and mouse.

3.3 Use cases of Front-desk

Use Case-ID: SRR- 3.4.1

Use Case-Name: Login front desk

Actors: Front-desk receptionist

Page 23: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 23

Description:Front desk user will login to register patients, manage the appointments and will be generating a token-ID for the active-patient using a hardware machine (token-generator)

Trigger: 1 Front desk receptionist clicks on the login button.2 Front desk receptionist presses “Enter” on the login button.

Pre-conditions:1 Front desk receptionist is active on the internet.2 Front desk receptionist has an account.3 Front desk receptionist is on the login page

Post-conditions: 1 Front desk receptionist should be logged-in successfully.2 If wrong attempt is made, redirect him to sign-in page

Normal Flow:

1 Front desk receptionist is present on the sign-in page.2 Front desk receptionist enters his username.3 Front desk receptionist enters his Password.4 Clicks/Enters on Sign-in button.5 System validates if receptionist is in Hospital network.6 Front desk receptionist is directed to his account-page.

Alternative Flow: None

Exceptions:

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.

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.

Includes: 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.

Assumptions:

1 Receptionist is well trained 2 Receptionist understands English language.3 Receptionist understands medical terms.4 Receptionist can operate the computer.

Notes and Issues:

1 Maximum length of username 11 containing digits and characters

2 Maximum length of Password 15 containing digits, characters, special characters

Use Case-ID: SRR- 3.4.2

Use Case-Name: Sign out front-desk

Actors: Front-desk receptionist

Page 24: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 24

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.

Pre-conditions: 1. Receptionist is signed in.2. Login session is not expired.

Post-conditions: 1 The receptionist’s login-session will be destroyed.2 The receptionist will be redirected to home page.

Normal Flow:

1. Receptionist is on any logged-in valid page2. He/she clicks on the sign-out link.3. System will destroy user’s login-session.4. Receptionist 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 Receptionist is well trained 2 Receptionist understands English language.3 Receptionist understands medical terms.4 Receptionist can operate the computer.

Notes and Issues: None.

Use Case-ID: SRR-3. 4.3Use Case-Name: Schedule appointments

Actors: Front-desk receptionist

Page 25: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 25

Description:

Front desk will generate the tokens of patients to be checked both the manually coming patients and the ones who got appointed online. Front 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 The receptionist should be logged-in.2 He should have selected the patient already.

Post-conditions:

1 The token-ID will also be assigned before printing token number.

2 The token should be printed after clicking the Appoint button.3 The record of patient history is updated.

Normal Flow:

1 Receptionist selects the patient using patient-ID2 Asks whether the patient is online or manual patient.3 Assigns the token-ID.4 The token-ID number and patient information is printed.

Alternative Flows:

If the patient comes for registration then after registration he could be appointed a token if he wants to be checked up.

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.

Exceptions: No exceptions.

Includes: Search patientRegistration

Special Requirements:

1 Report generated should be easy to understand.2 Generated report should be a complete summary of the month.

Assumptions:

1 Receptionist is well trained 2 Receptionist understands English language.3 Receptionist understands medical terms.4 Receptionist can operate the computer.

Notes and Issues: 1 The bill is paid or unpaid2 Total bill paid and unpaid should be updated.

Use Case-ID: SRR- 3.4.4

Use Case-Name: Register patients

Actors: Front-desk receptionist

Page 26: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 26

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 The receptionist should be logged-in.2 Receptionist fills the necessary details of the patient in form.

Post-conditions: The patient should be registered.

Normal Flow:

1 Receptionist is logged-in.2 Receptionist clicks on the button New-patient.3 Fills in the form-details of the patient.4 Clicks on Register button5 The patient is registered

Alternative Flows: No alternative flows

Exceptions:2a. In step 2 of the normal flow, entries required are empty or wrong.

1 Receptionist clicks back without filling form2 Prompt message displayed “leave page / not”.

Includes: None

Special Requirements:

1 Necessary required fields should not be missed in the form2 It should not be time consuming.

Assumptions:

1 Receptionist is well trained 2 Receptionist understands English language.3 Receptionist understands medical terms.4 Receptionist can operate the computer.

Notes and Issues: Pharmacist should enter inventory using keyboard and mouse.

3.4 Use cases of Admin

Use Case-ID: SRR- 3.5.1

Use Case Name: Login

Actors: 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

Page 27: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 27

Trigger: Go to the URL of admin and open the sign in page

Pre-conditions:

1. Admin has username and password.2. Admin has already registered

Post-conditions:

1. Admin should be logged-in successfully.2. Home page of admin will be opened.3. If wrong attempt is made, redirect him to sign-in page

Normal Flow:

1. Admin is present on the sign-in page.2. Admin enters his username3. Admin enters his Password.4. Taps on Sign-in button.5. System validates if admin is in Hospital network.6. Admin is directed to his account-page.

Alternative Flows:

If admin forgot username and password he/she will get password after some verification of some personal questions

Exceptions:

1. If admin enters an empty username2. Tool-tip displayed to enter username.3. Remains on the same page with clear input fields.4. If admin enters an empty password5. Tool-tip displayed to enter password6. If doctor username or password is incorrect7. Wrong login attempt message is displayed.8. Redirects him on the sign-in page.

Includes: Validate username and password.

Special Requirements:

Validate the username and password with in one second

Assumptions: 1. Doctors understand English language. 2. Can operate the Pc.

Notes and Issues:

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.2

Use Case-Name: Forgot password

Actors: Admin

Description:

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.

Trigger: Go to the URL of admin and open forgot password link URL.

Pre- 1. Admin has username or password.

Page 28: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 28

conditions: 2. Admin has already registered.

Post-conditions:

1. Admin should be logged-in successfully.2. Home page of admin will be opened.3. If wrong attempt is made, redirect him to sign-in page

Normal Flow:

1. Admin is present on the sign-in page.2. Admin enters his username3. Admin enters his Password.4. Taps on Sign-in button.5. System validates if admin is in Hospital network.6. Admin is directed to his account-page.

Alternative Flows:

If admin forgot username and password he/she will get password after some verification of some personal questions

Exceptions:

1. If admin enters an empty username2. Tool-tip displayed to enter username.3. Remains on the same page with clear input fields.4. If admin enters an empty password5. Tool-tip displayed to enter password6. If doctor username or password is incorrect7. Wrong login attempt message is displayed.8. Redirects him on the sign-in page.

Includes: Validate username and password.

Special Requirements:

Validate the username and password with in one second

Assumptions: 1. Admin understand English language. 2. Can operate the web application

Notes and Issues:

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 Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. Admin have rights to view the patients details

Page 29: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 29

Post-conditions:

1. Select the patients 2. Patients list created by their name.3. Patients can easily select the desire patients 4. Profile of patients will be open

Normal Flow:

1. Select the link of All patients2. List of all patients will show.3. Admin can select their desire patients.4. View the patient’s profile.5. Details of patients will show.

Alternative Flows:

1. Admin can search the patients by his/her name.2. Cancel the searching of patients3. 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 Requirements:

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 created3. If patients are not exists then error message of list empty

crated

Use Case-ID: SRR- 3.5.4

Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. Admin have rights to view the patients details 3. Search box is already opened

Page 30: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 30

Post-conditions:

1. Enter the name or id of patients2. Patients list created by their name.3. Patients can easily select the desire patients 4. Profile of patients will be open

Normal Flow:

1. Open search box2. Enter the id or name of patients.3. Admin can select their desire patients.4. View the patient’s profile.5. Details of patients will show.

Alternative Flows:

1. Select the URL of select patients2. List of patients will be created3. Select the desire patient

Exceptions: Enter name and id of patient is incorrect

Includes: Open URL of select all patients by his/her name and id.Special Requirements:

Provide the list of all registered patient

Assumptions: Admin have knowledge of patient id.

Notes and Issues:

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

Use Case-ID: SRR- 3.5.5Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. List of patients is shown3. Desired patients is selected

Post-conditions:

1. Select the desire patients 2. Click on delete button.3. Conformation box will open4. Conform the delete patient

Page 31: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 31

5. Patient will removed from the list

Normal Flow:

1. Select the link of all patient or search the patient2. List of all patients will show.3. Admin can select their desire patients.4. Click on delete button.5. Conform the deletion of patient.6. Patient will removed from the list

Alternative Flows:

1. Admin can select the multiple user from list to delete.2. Click on the delete button 3. Conformation box open4. Admin can conform and deny the conformation to delete the

patient5. 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 Requirements:

1. Provide the list of all registered patient 2. Search the patients by name and id3. Delete the patient

Assumptions: 1. Admin have knowledge of patient id.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 Case-Name: 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”

Pre-conditions:

1. Admin already logged in.2. Admin have rights to view the doctors details

Page 32: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 32

Post-conditions:

1. Select the patients 2. Doctors list created by their name.3. Doctors can easily select the desire doctors 4. Profile of doctors will be open

Normal Flow:

1. Select the link of all doctors2. List of all doctors will show.3. Admin can select their desire doctors.4. View the doctor profile.5. Details of doctor will show.

Alternative Flows:

1. Admin can search the doctors by his/her name.2. Select the search doctors link list of doctors will be created

Exceptions:

Includes: Search doctors by his/her name and id.Special Requirements:

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, characters, special characters

Use Case-ID: SRR- 3.5.7

Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. Admin have rights to view the doctors details 3. Search box is already opened

Page 33: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 33

Post-conditions:

1. Enter the name or id of doctors2. Doctors list created by their name.3. Doctors can easily select the desire doctors 4. Profile of doctors will be open

Normal Flow:

1. Open search box2. Enter the id or name of doctors.3. Admin can select their desire doctors.4. View the doctor profile.5. Details of doctors will show.

Alternative Flows:

1. Select the URL of select doctors2. List of doctors will be created3. Select the desire doctor

Exceptions: Enter name and id of patient is incorrect

Includes: Open URL of select all doctor by his/her name and id.Special Requirements:

Provide the list of all registered doctor

Assumptions: Admin have knowledge of doctor id.

Notes and Issues:

1. Maximum size of doctor username 11 contains numbers and characters

2. Maximum id, password size of doctor is 15. Contain numbers, characters, special characters

Use Case-ID: SRR- 3.5.8Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. List of doctor is shown3. Desired doctor is selected

Post-conditions:

1. Select the desire doctor 2. Click on delete button.3. Conformation box will open4. Conform the delete doctor

Page 34: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 34

5. Doctor will removed from the list

Normal Flow:

1. Select the link of all doctor or search the doctor2. List of all doctors will show.3. Admin can select their desire doctor.4. Click on delete button.5. Confirm the deletion of patient.6. Doctor will removed from the list

Alternative Flows:

1. Admin can select the multiple user from list to delete.2. Click on the delete button 3. Conformation box open4. Admin can conform and deny the conformation to delete the

doctor5. 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: Search doctor by his/her name and id.Special Requirements:

1. Provide the list of all registered doctor 2. Search the doctor by name and id3. Delete the doctor

Assumptions: 1. Admin have knowledge of patient id.2. Admin know about the conformation to delete the doctor

Notes and Issues:

1. Maximum size of doctor username 11 contains numbers and characters

2. Maximum id, password size of doctor is 15. Contain numbers, characters, and special characters.

Use Case-ID: SRR- 3.5.9

Use Case-Name: 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”

Pre-conditions:

1. Admin already logged in.2. Register doctors panel from is already opened

Page 35: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 35

Post-conditions:

1. Enter the details of doctor 2. Click on the register button.3. Conformation box of registration of doctor will be open4. If admin conform the registration doctor details will be saved to

server5. Name of the doctor will be add in the list of doctors

Normal Flow:

1. Open the register doctor URL2. Registration from will be opened3. 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

Includes: 1. Search doctors by his/her name and id.2. Delete doctors

Special Requirements:

Name of the doctors will be added to the list of doctors

Assumptions: Admin have knowledge about the filling of registration

Notes and Issues:

1. Maximum size of doctor username 11 contains numbers and characters

2. Maximum id, password size of doctor is 15. Contain numbers, characters, special characters

Use Case-ID: SRR- 3.5.10

Use Case-Name: 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”

Pre-conditions:

1. Admin already logged in.2. Register pharmacists panel from is already opened

Page 36: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 36

Post-conditions:

1. Enter the details of pharmacists 2. Click on the register button.3. Conformation box of registration of pharmacists will be

open4. If admin conform the registration pharmacists details will be

saved to server5. Name of the pharmacists will be add in the list of

pharmacists

Normal Flow:

1. Open the register pharmacists URL2. Registration from will be opened3. 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

Includes: 1. Search pharmacists by his/her name and id.2. Delete pharmacists

Special Requirements:

Name of the pharmacists will be added to the list of pharmacists

Assumptions: Admin have knowledge about the filling of registration

Notes and Issues:

1. Maximum size of username 11 contains numbers and characters2. Maximum id size, password of pharmacist is 15. Contain numbers,

characters, special characters

Use Case-ID: SRR- 3.5.11

Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. Admin have rights to view the pharmacists details

Page 37: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 37

Post-conditions:

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

Normal Flow:

1. Select the link of All pharmacists2. List of all patients will show.3. Admin can select their desire pharmacists.4. View the pharmacist profile.5. Details of pharmacists will show.

Alternative Flows:

1. Admin can search the pharmacists by his/her name.2. Cancel the searching of pharmacists3. Select the search pharmacists from list of pharmacists will be

created

Exceptions: Desired pharmacists not in the list

Includes: Search pharmacists by his/her name and id.Special Requirements:

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:

1. When admin select the list of pharmacists.2. Pagination of pharmacists will be created3. If pharmacists are not exists then error message of list empty

crated

Use Case-ID: SRR- 3.5.12Use Case-Name: Delete pharmacists

Actors: 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.

Pre-conditions:

1. Admin already logged in.2. List of pharmacists is shown3. Desired pharmacists is selected

Page 38: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 38

Post-conditions:

1. The pharmacists record should be removed2. If pharmacist is logged in, he should be removed at that

time.

Normal Flow:

1. Select the desire pharmacists 2. Click on delete button.3. Conformation box will open4. Conform the delete patient5. Pharmacists will removed from the list

Alternative Flows:

1. Select the link of all pharmacists or search the pharmacists2. List of all pharmacists will show.3. Admin can select their desire pharmacists.4. Click on delete button.5. Confirm the deletion of pharmacists.6. Pharmacists will removed from the list

Exceptions:

1. Admin can select the multiple users from list to delete.2. Click on the delete button 3. Conformation box open4. Admin can confirm / deny the confirmation to delete them.5. Admin confirms to delete pharmacists removed from the list.

Includes:

Special Req: Search pharmacists by his/her name and id.

Assumptions:1. Provide the list of all registered pharmacists 2. Search the pharmacists by name and id3. Delete the pharmacists

Notes and Issues:

1. Admin have knowledge of pharmacist id.2. Admin know about the conformation to delete the

pharmacists

Use Case-ID: SRR- 3.5.13

Use Case-Name: 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”

Pre-conditions:

1. Admin already logged in.2. Register front desk panel from is already opened

Page 39: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 39

Post-conditions:

1. Enter the details of front desk 2. Click on the register button.3. Conformation box of registration of front desk will be open4. If admin confirm the registration front desk details will be

saved to server5. Name of the front desk will be add in the list of front desk

Normal Flow:

1. Open the register front desk URL2. Registration from will be opened3. Admin will fill the form with front desk personal information

and user name and password

Alternative Flows:

Exceptions: If front desk is already registered than error message will be shown

Includes: 1. Search front desk by his/her name and id.2. Delete front desk

Special Requirements:

Name of the front desk will be added to the list of front desk

Assumptions: Admin have knowledge about the filling of registration

Notes and Issues:

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

Use Case-ID: SRR- 3.5.14

Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. Admin have rights to view the front desk details

Page 40: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 40

Post-conditions:

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

Normal Flow:

1. Select the link of All front desk2. List of all patients will show.3. Admin can select their desire front desk.4. View the pharmacist profile.5. Details of front desk will show.

Alternative Flows:

1. Admin can search the front desk by his/her name.2. Cancel the searching of front desk3. Select the search front desk from list of front desk will be

created

Exceptions: Desired front desk not in the list

Includes: Search front desk by his/her name and id.Special Requirements:

1. Provide the list of all registered front desk 2. Search the front desk by name and id

Assumptions: 1. Admin have knowledge of pharmacist id.2. Desired front desk in the list

Notes and Issues:

1. When admin select the list of front desk.2. Pagination of front desk will be created3. If front desk are not exists then error message of list empty

crated

Use Case-ID: SRR- 3.5.15Use Case-Name: 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

Pre-conditions: Open the list of front desk and select the desire front desk to delete

Post-conditions:

1. Admin already logged in.2. List of front desk is shown3. Desired front desk is selected

Page 41: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 41

Normal Flow:

1. Select the desire front desk 2. Click on delete button.3. Conformation box will open4. Conform the delete patient5. Front desk will removed from the list

Alternative Flows:

1. Select the link of all front desk or search the front desk2. List of front desk will be shown.3. Admin can select their desire front desk.4. Click on delete button.5. Confirm the deletion of front desk.6. Front desk will removed from the list

Exceptions:

1. Admin can select the multiple user from list to delete.2. Click on the delete button 3. Conformation box open4. Admin can conform and deny the conformation to delete the front

desk5. If admin conform to delete front desk removed from the front desk

list.6. If admin deny to delete the front desk, front desk will not deleted

from listIncludes: Special Requirements:

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 id3. Delete the front desk

Notes and Issues:

1. Admin have knowledge of pharmacist id.2. Admin know about the conformation to delete the front desk

Use Case-ID: SRR- 3.5.16

Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. Inventory module is already open

Page 42: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 42

Post-conditions:

1. Select “open inventory system” 2. Select the “add inventory link”.3. Select the medicines to add4. Enter the medicines detail(name price and quantity)5. Medicine will include in the list

Normal Flow:

1. Admin open the inventory system.2. Click on the add inventory3. Select the medicines to add4. Enter the medicines details5. 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 Requirements:

If admin enter the all details of medicines than medicines will be added to the sock

Assumptions: 1. Admin have knowledge of medicines details.2. Admin is able to fill the all details of medicines

Notes and Issues: Every medicines have unique name and id with bar code

Use Case-ID: SRR- 3.5.17

Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. Inventory system of pharmacy already opened

Post-conditions:

1. Select the inventory system link from home page 2. Medicines will be selected

Page 43: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 43

3. Details of medicines will be shown

Normal Flow:

1. Open the inventory system of pharmacy.2. Select view medicines3. List of medicines will be created4. 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 Requirements:

Assumptions: Admin have knowledge of pharmacy medicines, know the name quantity and price of medicines

Notes and Issues:

1. Every medicines have unique name.2. Quantity of medicines in grams

Use Case-ID: SRR- 3.5.18

Use Case-Name: 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 detail2. Select the desire medicines to delete.

Pre-conditions:

1. Admin already logged in.2. Inventory system of pharmacy already opened 3. Admin already marked the medicines to delete

Page 44: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 44

Post-conditions:

1. Marked medicines deleted from the list2. Confirmation box conform the deletion from admin

Normal Flow:

1. Open the inventory system of pharmacy.2. Select view medicines3. List of medicines will be created4. Marked the desire medicines to delete

Alternative Flows:

1. Search the medicines by their id or name2. Marked the medicines to delete3. Conform the deletion

Exceptions:

Includes: View, add, search medicines

Special Requirements:

Assumptions:

Admin have knowledge about medicines and how to use inventory system of pharmacy

Notes and Issues:

1. Name of medicines will be unique 2. Quantity of medicines in grams

Use Case-ID: SRR- 3.5.19

Use Case-Name: 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

Pre-conditions:

1. Admin already logged in.2. Inventory system of pharmacy is already opened3. Search box is already opened

Page 45: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 45

Post-conditions:

1. Enter the name or id of doctors in search box2. Medicine list will be created.3. Admin can easily select the desire doctors 4. details of medicines will be open

Normal Flow:

1. Open search box from inventory system of pharmacy 2. Enter the id or name of medicines.3. Admin can select their desire medicines.4. View the details desire medicines.

Alternative Flows:

1. Select the URL of view all medicines2. List of medicines will be created3. Select the desire medicines from list

Exceptions: 1. Enter name and id of medicines is incorrect2. Message will be shown

Includes: Open URL of select all doctor by his/her name and id.

Special Requirements:

Provide the list of all medicines with in one second

Assumptions: Admin have knowledge of medicines.

Notes and Issues:

Use Case-ID: SRR- 3.5.20

Use Case-Name: 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

Pre-conditions: Admin already logged in.

Page 46: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 46

Post-conditions:

1. Select the bills record then select the bills record of pharmacy2. 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 patient2. 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: 1. Admin have knowledge of patient id.2. Admin know the English language

Notes and Issues:

4. Specific Requirements

4.1 Functionality

4.1.1 Patient functional requirement

4.1.1.1 Sign in

Identifier 2.1Title Patient select the sign in Requirement Patient shall be able to sign in to the system Source Stakeholder Rationale DependenciesPriority High

4.1.1.2 Sign out

Page 47: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 47

Identifier 2.2Title Patient select the sign out Requirement Patient shall be able to sign out.Source Stakeholder Rationale Dependencies 2.1Priority High

4.1.1.3 Sign upPatient will be able to login and logout for user authentication.

Identifier 2.3Title Patient select the sign upRequirement Patient shall be able to sign up.Source Stakeholder Rationale DependenciesPriority High

4.1.1.4 Update profilePatient should be able to update his profile.Identifier 2.4Title Patient select update profileRequirement Patient shall be able to update profileSource Stakeholder Rationale Dependencies 2.1Priority High

4.1.1.5 Get his/her own appointment

Identifier 2.5Title Patient select get appointment Requirement Doctor shall be able to get the appointment.Source Stakeholder Rationale Dependencies 2.1Priority High

4.1.1.6 View his/her own appointment

Identifier 2.6Title Patient select view prescription Requirement Patient shall be able to view prescription.Source Stakeholder Rationale Dependencies 2.1Priority High

4.1.1.7 View doctors listPatient shall be able to get appointments by searching doctors.Identifier 2.7

Page 48: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 48

Title Patient select view doctors list.Requirement Patient shall be able to view doctors list.Source Stakeholder Rationale Dependencies 2.1Priority High

4.1.1.8 View prescriptions

Identifier 2.8Title Patient select view prescriptions.Requirement Patient shall be able to view prescriptions.Source Stakeholder Rationale Dependencies 2.1Priority High

4.1.1.9 View billsPatient shall be able to view his older prescriptions and bills paid / unpaid to manage his real life.Identifier 2.9Title Patient select view bills Requirement Doctor shall be able to view billsSource Stakeholder Rationale Dependencies 2.1Priority High

4.1.2 Pharmacist functional requirement

4.1.2.1 Login

Identifier 3.1Title Pharmacists select the login.Requirement Pharmacists shall be able to select the login.Source Stakeholder Rationale DependenciesPriority High

4.1.2.2 Logout

Identifier 3.2Title Pharmacists select the logout.Requirement Pharmacists shall be able to select the logout.Source Stakeholder Rationale Dependencies 3.1Priority High

4.1.2.3 Print bills

Identifier 3.3Title Pharmacists select the print bills.

Page 49: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 49

Requirement Pharmacists shall be able to select print bills.Source Stakeholder Rationale Dependencies 3.1Priority High

4.1.2.4 Print prescriptions

Identifier 3.4Title Pharmacists select the print prescription. Requirement Pharmacists shall be able to print prescription.Source Stakeholder Rationale Dependencies 3.1Priority High

4.1.2.5 Report generation

Identifier 3.5Title Pharmacists select the report generation.Requirement Pharmacists shall be able to select the report generation.Source Stakeholder Rationale Dependencies 3.1Priority High

4.1.2.6 View prescriptions

Identifier 3.6Title Pharmacists select the view prescription.Requirement Pharmacists shall be able to select the view prescription.Source Stakeholder Rationale Dependencies 3.1Priority High

4.1.2.7 View Notification

Identifier 3.7Title Pharmacists select the view prescription. Requirement Pharmacists shall be able to select the view notification.Source Stakeholder Rationale Dependencies 3.1Priority High

4.1.3 Front desk functional requirement

4.1.3.1 Login

Identifier 4.1

Page 50: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 50

Title Front desk user login Requirement Front desk user shall be able to login Source Stakeholder Rationale Use front desk systemDependenciesPriority High

4.1.3.2 Logout

Identifier 4.2Title Front desk user logout Requirement Front desk user shall be able to Logout Source Stakeholder Rationale Dependencies 4.1Priority High

4.1.3.3 Register patients

Identifier 4.3Title Front desk user register the patient Requirement Front desk user shall be able to register the patientSource Stakeholder Rationale Dependencies 4.1Priority High

4.1.3.4 Schedule appointments

Identifier 4.4Title Front desk user schedule the patient appointment Requirement Front desk user shall be able to schedule the patient appointmentSource Stakeholder Rationale Dependencies 4.3Priority High

4.1.4 Admin functional requirement

4.1.4.1 Login

Identifier 5.1Title Admin login Requirement Admin shall be able to login Source Stakeholder Rationale DependenciesPriority High

Page 51: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 51

4.1.4.2 Logout

Identifier 5.2Title Admin logout Requirement Admin shall be able to Logout Source Stakeholder Rationale Dependencies 5.1Priority High

4.1.4.3 Register doctors

Identifier 5.3Title Admin register doctors Requirement Admin shall be able to register doctors in the system Source Stakeholder Rationale Dependencies 5.1Priority High

4.1.4.4 Register front desk receptionist.

Identifier 5.4Title Admin register front desk receptionist Requirement Admin shall be able to register front desk receptionist in the

system Source Stakeholder Rationale Dependencies 5.1Priority High

4.1.4.5 Add pharmacy inventory.

Identifier 5.5Title Add pharmacy inventoryRequirement Admin shall be able to add pharmacy inventory Source Stakeholder Rationale Dependencies 5.1Priority High

4.1.4.6 Delete pharmacy inventory.

Identifier 5.6Title Delete pharmacy inventory Requirement Admin shall be able to delete pharmacy inventorySource Stakeholder Rationale Dependencies 5.5Priority High

4.1.4.7 Search pharmacy inventory.

Identifier 5.7

Page 52: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 52

Title Search pharmacy inventoryRequirement Admin shall be able to search the pharmacy inventorySource Stakeholder Rationale Dependencies 5.5Priority High

4.1.4.8 View pharmacy inventory.

Identifier 5.8Title View pharmacy inventory Requirement Admin shall be able to view pharmacy inventorySource Stakeholder Rationale Dependencies 5.5Priority High

4.1.4.9 Add store room inventory.

Identifier 5.9Title Add storeroom inventoryRequirement Admin shall be able to add storeroom inventory Source Stakeholder Rationale Dependencies 5.1Priority High

4.1.4.10 Delete store room inventory.

Identifier 5.10Title Delete storeroom inventory Requirement Admin shall be able to delete storeroom inventorySource Stakeholder Rationale Dependencies 5.9Priority High

4.1.4.11 View doctor details.

Identifier 5.13Title View doctors details Requirement Admin shall be able to view doctor detailsSource Stakeholder Rationale Dependencies 5.3Priority High

4.1.4.12 Search doctor details.

Identifier 5.14Title Search doctors details Requirement Admin shall be able to search doctor details

Page 53: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 53

Source Stakeholder Rationale Dependencies 5.3Priority High

4.1.4.13 Delete doctor details.

Identifier 5.15Title Delete doctors details Requirement Admin shall be able to delete doctor detailsSource Stakeholder Rationale Dependencies 5.3Priority High

4.1.4.14 View patient details.

Identifier 5.16Title View patients details Requirement Admin shall be able to view patients detailsSource Stakeholder Rationale Dependencies 5.3Priority High

4.1.4.15 Search patient details.

Identifier 5.17Title Search patients details Requirement Admin shall be able to search patient detailsSource Stakeholder Rationale Dependencies 5.3Priority High

4.1.4.16 Delete patient details.

Identifier 5.18Title Delete patient details Requirement Admin shall be able to view patient detailsSource Stakeholder Rationale Dependencies 5.3Priority High

4.1.4.17 Register pharmacists

Identifier 5.19Title Admin register pharmacists Requirement Admin shall be able to register pharmacists in the system Source Stakeholder Rationale Dependencies 5.1Priority High

Page 54: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 54

4.1.4.18 View pharmacist details.

Identifier 5.20Title View pharmacists details Requirement Admin shall be able to view pharmacists detailsSource Stakeholder Rationale Dependencies 5.19Priority High

4.1.4.19 Search pharmacist details.

Identifier 5.21Title Search pharmacists details Requirement Admin shall be able to search pharmacists detailsSource Stakeholder Rationale Dependencies 5.19Priority High

4.1.4.20 Delete pharmacist details.

Identifier 5.22Title Delete pharmacists details Requirement Admin shall be able to delete pharmacists detailsSource Stakeholder Rationale Dependencies 5.19Priority High

4.1.4.21 View front desk user details.

Identifier 5.23Title View front desk details Requirement Admin shall be able to view front desk user detailsSource Stakeholder Rationale Dependencies 5.4Priority High

4.1.4.22 Search front desk user details.

Identifier 5.24Title View receptionist details Requirement Admin shall be able to search front desk user detailsSource Stakeholder Rationale Dependencies 5.4Priority High

4.1.4.23 Delete front desk user details.

Identifier 5.25Title View front desk details

Page 55: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 55

Requirement Admin shall be able to delete front desk user detailsSource Stakeholder Rationale Dependencies 5.4Priority High

4.1.4.24 View bill records of pharmacy

Identifier 5.26Title View bills record of pharmacy Requirement Admin shall be able to view bills record of pharmacy Source Stakeholder Rationale Dependencies 5.5Priority High

4.2 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.

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.

4.3 Reliability

• Availability

The system will be available all over the time.

It also depends on the internet availability.

• Mean Time between Failures (MTBF)

The recovery time of failure system will be 1-2 hours, if the system crashes.

Page 56: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 56

• Maximum Bugs or Defect Rate

5 bugs in one thousand lines of code

• Bugs or Defect Rate

The type of bugs which can occur in our project will not be serious bugs.

The bugs will be of minor type that would be easy to recover or trace.

4.4 Performance

4.4.1 Response time

Response time for loading a page is 3 seconds

4.4.2 Memory consumption

100 MB will be required to install the android application for the doctor.

4.4.3 Capacity of visitors

The page load request of clients using website is 100 users per day.

50-60 MB will be required for it to be in running form (on RAM)

4.5 Supportability

The system will be supportable on Internet Explorer, Safari, Mozilla and chrome

4.6 Design Constraints

4.6.1 Web Portal

The system shall be built using standard webpage development Languages html and html5, CSS, JavaScript, PHP and MySQL

These will be used in tools: Dream viewer Wamp Server

4.7 Purchased Components

Website domain Pc

Page 57: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 57

4.8 Interfaces

4.8.1 User Interfaces

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 Hardware Interfaces

Intel Pentium IV 800MHz processor or equivalent 512MB of RAM Running Windows XP/Vista/Win7/Win8 Pc

4.8.3 Software Interfaces

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 Dreamweaver CS5 and WAMP server

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

Page 58: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 58

4.8.4 Communications Interfaces

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 Licensing Requirements

4.9.1 Legal, Copyright, and Other Notices

5. Supporting Information

• Index

Page 59: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 59

Automated 4Administration, 4CConstraints, 70DDefinition, 5Design 69,70EEdit, 9,30FFunctional Requirements, 6,4HHardware, 38IIntroduction, 4LLogin , 9, 69Logout, 67PPurpose, 4SSoftware Interface, 71UUse case, 9User Interface, 69, 71

Page 60: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 60

Class diagram

Page 61: SRS Final Fari Ori

Software Requirements Specification for Hospital Management SystemPage 60