srs final fari ori
DESCRIPTION
srs documentTRANSCRIPT
Software Requirements Specification
For
Hospital Management System
Version 3.0
Prepared by
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
Software Requirements Specification for Hospital Management SystemPage iii
Revision History
Name Date Reason For Changes Version
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
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.
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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.
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
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
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
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
Software Requirements Specification for Hospital Management SystemPage 60
Class diagram
Software Requirements Specification for Hospital Management SystemPage 60