Mehta Chintan SRS

Software Requirements Specification for Hospital Information System
Page|1
Software Requirements Specification For Hospital Information System Version 1.0

Prepared by Chintan Mehta Lead Software Engineer
Prepared for COMP 5423Software Engineering Instructor: A. Lodgher, Ph.D. Fall 2010
Page|2
Table of Contents
Cover Page..i Table of Contents..ii Introduction .................................................................................................................................................... 6 Existing System ............................................................................................................................................... 6 Statement of Need and Feasibility.................................................................................................................. 6 A Bounded Scope for the System ................................................................................................................... 6 A list of All Stakeholders Interviewed ............................................................................................................. 7 Systems Technical Requirement ..................................................................................................................... 7 Numbered list of requirements and the constraints that apply to each ........................................................ 8 Use Case Diagram 1 ...................................................................................................................................... 10 Use Case Diagram 2 ...................................................................................................................................... 11 Use Case Scenarios ....................................................................................................................................... 12 Use Case A User Login ............................................................................................................................. 12 Use Case B Doctor Check Schedule ......................................................................................................... 13 Use Case C-Doctor Change the Schedule of Patient ................................................................................. 14 Use Case D-Lab Test .................................................................................................................................. 15 Use Case E Prescribe Medicine ............................................................................................................... 16 Use Case F-Keep in Touch ......................................................................................................................... 17 Use Case G-Register with System ............................................................................................................. 18 Use Case H-Appointment .......................................................................................................................... 19 Use Case I-Pay the fees ............................................................................................................................. 20 Use Case J- Logs the patient data ............................................................................................................. 20 Use Case K-Nurse Checks Schedule .......................................................................................................... 21 Use Case L- Allot the room........................................................................................................................ 22 Use Case M-Admin Maintenance ............................................................................................................. 23 Activity Diagrams .......................................................................................................................................... 25 Activity Diagram for the Logging In of all Stakeholders (Use Case A) ....................................................... 25 Activity Diagram for Doctor Check Schedule (Use Case B) ....................................................................... 26 Activity diagram for Doctor Change the Schedule of Patient (Use Case C) .............................................. 28 Activity Diagram for Lab Test (Use Case D) ............................................................................................... 30
Page|3
Activity Diagram for Prescribing Medicine (Use Case E) ........................................................................... 31 Activity Diagram for Keep in Touch (Use Case F) ...................................................................................... 32 Activity Diagram for Patient Registering with System (Use Case G) ......................................................... 33 Activity Diagram for Patient Schedule the Appointment (Use Case H) .................................................... 34 Activity Diagram for Pay the Fees (Use Case I) ......................................................................................... 35 Activity Diagram for Nurse Logs Patient Data (Use Case J) ...................................................................... 36 Activity Diagram for Nurse Check Schedule (Use Case K) ......................................................................... 37 Activity Diagram for Allotting Room to Patient (Use Case L) .................................................................... 38 Activity Diagram for Administrator Maintenance (Use Case M) .............................................................. 39 Swimlane Diagrams ....................................................................................................................................... 40 Swimlane Diagram for Schedule the Appointment .................................................................................. 40 Swimlane Diagram for Login and Registration.......................................................................................... 41 Table of Classes (With Purpose, Attributes and Operations) ....................................................................... 42 A Class Connectivity Diagram, Associations and Dependencies ................................................................... 45 Data Flow Diagram (DFD).............................................................................................................................. 46 Context Level-DFD..................................................................................................................................... 46 DFD Level 1................................................................................................................................................ 47 DFD Level 2................................................................................................................................................ 48 DFD Level 3 Logs In to the system, Display the Respective Menu ............................................................ 49 DFD Level 4 Appointment Booking System............................................................................................... 50 DFD Level 4 Diagnose Diseases & Prescribe Medicine System ................................................................. 51 DFD Level 4 Allot Ward and Bed ............................................................................................................... 52 DFD Level 4 Laboratory and Patient Log System ...................................................................................... 53 A Set of Data and Data object Type being used............................................................................................ 54 1] SecurityUser .......................................................................................................................................... 54 2] Address ................................................................................................................................................. 54 3] PatientType ........................................................................................................................................... 54 4] DoctorType ........................................................................................................................................... 54 5] Patient ................................................................................................................................................... 54 6] Doctor ................................................................................................................................................... 55 6.1] DosageType........................................................................................................................................ 55 7] Prescription ........................................................................................................................................... 55
Page|4
8] Nurse ..................................................................................................................................................... 55 9] Schedule ................................................................................................................................................ 55 10] PatientVisitDetail ................................................................................................................................ 56 11] LabTest ................................................................................................................................................ 56 12] PatientMedicalFinding ........................................................................................................................ 56 13] Ward ................................................................................................................................................... 56 14] Room ................................................................................................................................................... 57 15] Bed ...................................................................................................................................................... 57 State Diagrams .............................................................................................................................................. 57 State Diagram for Prescription Class......................................................................................................... 57 State Diagram for Appointment Class....................................................................................................... 58 Sequence Diagram ........................................................................................................................................ 59 Doctor Prescribes Medicine ...................................................................................................................... 59 Get Patients Data and Diagnose .............................................................................................................. 60 Change Schedule of the Patient ................................................................................................................ 61 Validating all Requirements .......................................................................................................................... 62
Page|5
Page|6
Introduction
Software Requirement Specification is the detailed analysis of what stakeholders wants. It does not show how the system will function. In Software Requirement we break the Requirements into parts so that we can easily understand the part. It is divide and conquer policy. First we dig-out each requirement and make their Use Cases. From the Use Case we go on build Use Case Scenarios. Doing grammatical parse on Use Case Scenarios we build Classes, Properties and Operations. We then build Data objects. From Scenarios and Classes we build State Diagram, Activity Diagrams and Sequence diagrams. We understand the Functionality from user point of view. As a Project Manager I have to first study the actual need and Feasibility of the System.
Existing System
There are numerous locations where Sherman Hospital has opened up its branch. These branches do have good IT infrastructure but they are not interconnected. The Present System is not having modern state-of-art facility.
Statement of Need and Feasibility

Feasibility study is an analysis and viability of Idea, idea to build the Hospital Information system. A feasible business/System is that business or system from which we get benefits, more ease of use, more profits. It is proven from Dr. Halmakas Experience that good Hospital Information System will be beneficial to all hospital stakeholders and organization as a whole. Patient will have ease to get appointments. Doctor will have ease to view patient record. No need keep records in big store room. It will definitely be beneficial to build the hospital information Web Based System. We can have multiple backups at different Location so our data is safe and secure in situation of catastrophe.
A Bounded Scope for the System

The Hospital Information System should be accessible from Website. It wants the User Security. That means the Authenticate must be able to access the system. User must have UserID and Password to Log on to the system. He must be able to access website from mobile phone as well. If the Patient is new to the Hospital then he has to first register. After registration only he could be able to access further pages of website. Doctor should be able to check his schedule, change the Patients Schedule in emergency. Doctor should also be keep in touch with the patient via email, text messages and phone calls which should get recorded in the system. Doctor can have talk with remote patient and that meeting with the patient should be recorded. Doctor should be able to check the Schedule and on drilling down of the date of schedule. Doctor should be able to see the Patient name and time on further drilling down of Schedule. Doctor should be able to see the Demographic data; Patients previous visit Tests, Medical Findings, allergies and Medication given to Patients.
Page|7
Nurse should be able to check schedule and Logs the patient Medical findings. Receptionist manages the Scheduling of the Patient and Patient appointment with Doctor. There is Laboratory which logs the tests data suggested by Doctor. Pharmacist gives the medicine to Patient as prescribed by the Doctor.
A list of All Stakeholders Interviewed

Designation Nurse Doctor Patient Administrator Pharmacist Laboratory What is importance? Nurse gave all the detail about the role she is playing in the hospital Doctor is the heart of hospital and initiates most of the tasks Patient is God of Hospital and his satisfaction is of prime importance Administrator is the person who visualizes overall management of the hospital. Pharmacist is person who gives proper medicine prescribed by the Doctor Take care of all the Test, X-Ray, Echo Cardiograph, Trade-mill tests etc.
Systems Technical Requirement

System will need the Following Technology in order to perform well. 1. 2. 3. 4. 5. 6. 7. There should be Internet connection at the all branches of Hospitals. There should be one high end server at the Head Location. All the Nodes should be having Browser say for example Internet Explorer. System should be up and running 24 hours a day 7 days a week and 365 days. Doctors should have Web Cam in order to view the remote Patient. High end server should be connected with Leased line with IP. Must use VPN as the Hospital is having Mission critical environment
Page|8
Numbered list of requirements and the constraints that apply to each

No
1
Requirement
Doctor, Patient, Nurse, Pharmacist, Nurse, Receptionist should login Register the Patient if he is new to the System
Constraint
What if unauthorized user tries to login and try to hack site? How can we know that the patient registered is who his name is? Can we take photo identity Or from SSN identify his identity. Is giving calendar on the webpage ideal way of seeing schedule? No constraint
Type
Type of Diagram
Functional, Use Case, DFD Flow, Data Functional, Use Case, DFD, Flow, Data Data Objects
1.1
Doctor Could be able to see Schedule in day, month and year fashion
Functional, Use Case, Data Data Objects
On drilling down he can see the detailed schedule tasks and list of patients 3.1.1 On clicking the patient name he can see the patient profile which includes key demographic data including insurance, primary care provider, and pharmacy. Doctor could be able to see any 4 medical alerts, reminders and schedule of the patient for any tests. Doctor can see information on 5 allergies, medication and admissions and appointments at the hospital in the past On further drill down of each of 5.1 those visits he can see the treatment given to the patient If doctor notices that a quick 6 action on his side may be beneficial for the patient then he can change his schedule and patient schedule too. Patient can schedule, approve, 7 disapprove or recommend a change to the doctors request of change of schedule 3.1
Functional, Use Case, Data Data objects Functional, Use Case, Data Data objects
What if nobody is at the specified address and if not having insurance? What if patient doesnt go for test?
Functional, Use Case, Data Data objects
No constraint
What about treatment given to hospital other than Sherman What if patient is not available at his home or on the phone number he has given. No Constraint, apart from Website is down
Functional, Use Case, Data Data objects Functional, Use Case, DFD, Data, Data objects, Flow, Sequence Behavior Functional, Use Case, State, Behavior, Data objects Data
Page|9
No
8
Requirement
Patient can view his/or her medical information on the website Doctor can view the patients medical images like X-ray, CTScan, Echo-Cardiograph etc.
Constraint
No Constraint, apart from Website is down What if Bandwidth is not available to see the videos and emergency is there? What if patient is not available at his home or on the phone number he has given. What if the communication link fails in between the recording? Bandwidth problem? Will we use readymade third party component to fulfill this requirement? From whose instruction the administrator would perform these action is to be decided. Is Receptionist independent on taking the decisions? Is Doctor going to verify the data nurse has entered? Where will Receptionist deposit fee? Is it Cashier or Accountant?
Type
Type of Diagram
Functional, Use Case, Data Data objects Functional, Use Case, Data Data objects
Doctor can get in touch with the patient or any of the associated caretakers via phone, text messages, and email directly from System. 9.1.1 The communication between doctor and patient should be recorded and doctor/other doctor can access it for viewing Patient visit from remote clinics 10 may be recorded based on patient-doctor discretion and videos of those visits may also be available for a doctor to view. Administrator is able to Delete, 11 Update and Add the Doctor/Nurse/Staff if they are leaving the hospital, their detail changes or New staff arrives at the hospital. Receptionist will allocate Room 12 or Bed to the patient in case if patient is hospitalized. Nurse will Log the patient data 13 into the system. Doctor enter his diagnoses log too. Receptionist will collect the fees 14 from the patient. 9.1
Functional, Use Case, DFD, Flow, Data Data objects
Functional, Use Case, Data Data objects Functional, Use Case, DFD Flow, Data , Data objects Functional, Use Case, Data Data objects
15
Doctor enter his diagnoses and Prescribes medicine.
Functional, Use Case, Flow, Sequence, State, Behavior, Data objects Data
P a g e | 10
Use Case Diagram 1

Hospital Information System
Logs in
Doctor Patient Laboratory Nurse Receptionist Pharmacy Administrator
Add, Delete, Edit Staff, Doctor, Patient
Administrator
Logs & Check the patient data like heart rate, blood pressure. Nurse Checks schedule
P a g e | 11
Use Case Diagram 2

Hospital Information System
Check the Schedule via website and Mobile phone and see the details of it and detail of the patient Doctor
Can change the schedule of the patient and his schedule as per the emergency
Prescribe the Laboratory test Pharmacy Prescribe the Medicine
Laboratory Call the Patient via Phone, Text Messages and Email (Keep in touch with patient) & videos of Remote Patients Receptionist
Phone & Viedo calling recording
Email system Schedules or Cancel Reschedules appointment
Take Fee Patient Check the occupancy and allot the bed/Room
P a g e | 12
Use Case Scenarios

Use Case A User Login Doctors, Nurse, Receptionist, Patient, Administrator, Laboratory, and Pharmacist Logs In via Internet PC or Mobile phone having internet facility. Primary Actors : Doctors, Nurse, Receptionist, Patient, Administrator, Laboratory, Goal in Context
the user. Pharmacist : To gain access to the Hospital Information System as per role assigned to : 1 System must be fully configured and appropriate user ID and passwords must be obtained from system administrator. 2 If user is patient then he has to register with the HIS prior to login. : To use the functionality of the system
Preconditions Trigger Scenario:

1. 2. 3. 4. 5. 1. 2. 3. 4. 5.
All stakeholders log on to the Hospital Information System Website. Stakeholders enter his or her user ID. Stakeholders enter passwords (Password length is minimum 6 alphanumeric characters). Save the Login time of particular stakeholder. The system displays all major menus that are authorized to view by that stakeholder.
Exceptions:
Website or Web Server is down. Mobile phone is moving out of the Internet connection zone. Session time out expires. Website maintenance is going on. User ID and Password are incorrect. See Use Case Validate ID and password Channel to Actor: Via PC-based browser and internet connection. Secondary Actors : System Administrator Channels to Secondary Actors: Open issues: 1. What mechanisms protect unauthorized use of the capability by the other employees of HIS? 2. Is Password mechanism for authenticating the user is sufficient? 3. Should we track the User with malicious intention? 3.1 Should we track the IP from where there are many login in short time? Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta Date : 12th October, 2010
P a g e | 13
Use Case Primary Actors Goal in Context Preconditions Trigger Scenario:
Use Case B Doctor Check Schedule : Check the Schedule via website and Mobile phone and See the Detail of his schedule and details of Patient : Doctor : To See at what time he should remain present at the hospital so he could
attend them. : User must be logged in with sufficient privilege. : Doctors decides to take a look at his appointment with his patients.
1. Doctor selects the Schedule Button available to him on the screen. 2. System will give calendar of current month. 3. In calendar the red date, green dates and blue dates will be there. 4. The red date indicates that there is higher number of patients to check. 5. The green date indicates that there is moderate number of patients to check. 6. The blue date indicates that there are no patient yet appointed. 7. The system displays the 3 option Daily, Monthly, Yearly. 8. The Doctor selects the Daily Schedule Option. 9. The system gives the Daily Schedule of the Doctor who is logged in. 10. The Doctor selects the Monthly Schedule option. 11. The system gives the Monthly schedule of the Doctor who is logged in. 12. The doctor selects the Yearly Schedule option. 13. The system gives the Yearly schedule of the Doctor who is logged in. 14. Doctor could view the schedule by date and time. 15. On clicking further on date the Doctor would get the detail schedule, tasks and list of patient. 16. On clicking patient name Doctor can see the profile which includes key demographic data which includes insurance, primary care provider, pharmacy. 17. On clicking alerts, reminders and schedule of patient for any test Doctor would able to see those things. 18. On Pressing the Allergies and Medication button Doctor could be able to see the detail about that particular patient.
Exceptions:
Website or Web Server is down. Session time out expires. Website maintenance is going on. Doctor selects other Menu Item or Link. Channel to Actor : 1. Via PC-based browser and internet connection. 2. Mobile Phone Secondary Actors : System Administrator, Receptionist Channels to Secondary Actors: Open issues: 1. 2. 3. 4.
P a g e | 14
1. Can the Doctor logged in be able to view the schedule of other Doctor? 2. Will mobile phone viewing be enough good (user friendly) for doctor to view his schedule? (Small screen of mobile phone) Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta Date : 12th October, 2010
Use Case C-Doctor Change the Schedule of Patient Use Case : Change the schedule of the patient as per the emergency Primary Actors : Doctor Goal in Context : For the patient who is going to get benefit if s/he is treated earlier then Preconditions Trigger Scenario
doctor could change the schedule. : Use Case Scenario B must be executed : To treat patient in emergency like situation or would it be beneficial for the patient if he is treated earlier.
1. Doctor goes to change schedule button. 2. Press that button. 3. Doctor presses the Enter/Ok button. 4. The Schedule of the patients appears on the screen. 5. There appears the calendar. 6. Doctor selects the calendar date for the patient. 7. Then Presses the Save button. 8. Patient schedule is now gone to Receptionist for further notification to patient. 9. Receptionist Checks whether the changed date is available or not. 10. If date is available then calls the patient or send the schedule change notification to patient. 11. Patient on receiving the notification confirms of Reject the request. 12. If patient rejects the date then the original date is kept.
Exceptions:
Website or Web Server is down. Session time out expires. Website maintenance is going on. Doctor selects other Menu Item or Link. Doctor changes the schedule two or more than two times of same patient. Channel to Actor : 1. Via PC-based browser and internet connection. 1. 2. 3. 4. 5.
Secondary Actors : Receptionist, Patient Channels to Secondary Actors:
P a g e | 15
1. Patient: PC-based Web browser system or Telephone call 2. Receptionist: PC-based Web browser system Open issues: 1. Doctor could take any route.
Priority When Available Iteration Created by Date
: Moderate : First Increment : First : Chintan Mehta : 12th October, 2010
Use Case Primary Actors Goal in Context Preconditions : User must be logged in with sufficient privilege Trigger : Explanation given by the Patient about his/her illness. Scenario :
1. 2. 3. 4. 5. 6. 7. 8. 1. 2. 3. 4. 5. 6. Doctor is on any screen. Press the Go for Laboratory test button. A drop-down box containing patient names appears on the screen. Doctor selects the patient name. Doctor selects the Laboratory test to be done. Patient goes to Lab department. Laboratory checks the test particular patient has been suggested by doctor. Lab does the test of the patient and enters the test data of the patient in the system
Use Case D-Lab Test : Prescribe the Laboratory test : Doctor : To get the Clear picture of patients Diseases.
Exceptions:
Website or Web Server is down. Session time out expires. Website maintenance is going on. Doctor selects other Menu Item or Link. Patient doesnt go to the Laboratory. Lab is closed for the day Channel to Actor : 1. Via PC-based browser and internet connection. Secondary Actors :Patient, Laboratory Channels to Secondary Actors: 1. System Administrator: PC-based Web browser system 2. Laboratory: PC-based Web browser system Open issues:
1. Would hand written paper for lab testing will do in case of emergency cases?
P a g e | 16
Priority When Available Iteration Created by Date
: High : First Increment : First : Chintan Mehta : 12th October, 2010
Use Case Primary Actors Goal in Context Preconditions Trigger Scenario

1. 2. 3. 4. 5. 6. 7. 8. 9. 1. 2. 3. 4. 5.
Use Case E Prescribe Medicine : Prescribe the medicine to the Patient : Doctor : Ultimate goal to give the patient required ailment.
: Doctor must be logged in with sufficient privilege : All data is there now it is time to perform final step.
Doctor diagnoses disease. Save the Diagnoses. Press the Prescribe the medicine button. Patient name combo box appears. The Patient name combo box is populated with those patients whose check-in date is the date selected Doctor prescribes to the patient the drugs and enters into the system. Patient goes to Pharmacy. Pharmacy checks the Medicine to be given on the system. Gives the Prescribed medicine to the Patient.
Exceptions:
Website or Web Server is down. Session time out expires. Website maintenance is going on. Doctor selects other Menu Item or Link. Patient does not turn up to receive prescription. Channel to Actor : 1. Via PC-based browser and internet connection. Secondary Actors : Pharmacy, Laboratory Channels to Secondary Actors: 1. Pharmacy : PC-based Web browser system 2. Laboratory: PC-based Web browser system Open issues : Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta
P a g e | 17
Date
: 12th October, 2010
Use Case Primary Actors Goal in Context Preconditions Trigger Scenario

1. 2. 3. 4.
Use Case F-Keep in Touch : Stay in touch with the Patient via Phone, Email or Messaging And video conference remote Patient via this system. : Doctor : Patients satisfaction is prime importance for the doctor.
: Doctor must be logged in with sufficient privilege : Know that if patient is satisfied with the service and whether patient is feeling well with the medication.
Doctor is on any screen. Press the Keep in touch button. Patient name combo box appears. The Patient name combo box is populated with those patients by decreasing order of check-in date. 5. Doctor selects the patient name. 6. The detail of patient like email address, phone number appears on the screen. 7. Doctor selects the option which he likes. 8. If doctor calls then Conversation with the patient is established and recorded. 9. Recorded Conversation and Video is saved against patients history. 10. If Patient is at remote place then the doctor will ask the patient to video record the conversation 11. If patient says yes then Doctor will record the video conferencing conversation and saves it. 12. Email, Text messages are recorded without patient discretion.
Exceptions:
Website or Web Server is down. Session time out expires. Website maintenance is going on. Doctor selects other Menu Item or Link. Conversation via telephone or mobile ends up in between. Channel to Actor : 1. Via PC-based browser and internet connection. Secondary Actors : Patient, Phone - Video Calling and Recording system, Email System Channels to Secondary Actors: 1. Phone and Video Call and Recording system 2. Patient: PC-based Web browser system or cell phone or LL 3. Email-System: PC-based Web browser system Open issues : Priority : Low 1. 2. 3. 4. 5.
P a g e | 18
When Available Iteration Created by Date
: First Increment : First : Chintan Mehta : 12th October, 2010
Use Case Primary Actors Goal in Context Preconditions

Register
Use Case G-Register with System : Registers with the System. : Patient : To Go for check-up to the hospitals doctor
: Patient must be ready with all the information required by the Hospital to : Patient has fallen sick or wants to have regular check up.
Trigger Scenario:
1. 2. 3. 4. 5. 6. 7. 1. 2. 3. 4. 5.
Patient log on to the Hospital Information System Website. Clicks on New Patient Button. Fills Necessary detail required for registration (Name, SSN, Date of Birth). Submit the Detail System Administrator Verifies the detail Send the Patient Unique UserID and password on his Email. Or Rejects the Registration.
Exceptions:
Website or Web Server is down. Mobile phone is moving out of the Internet connection zone. Session time out expires. Website maintenance is going on. User ID and Password are already there (It should be unique) Channel to Actor : Via PC-based browser and internet connection. Secondary Actors : System Administrator, Patient Channels to Secondary Actors: 1. System Administrator: Via PC-based browser and internet connection. 2. Patient : Via PC-based browser and internet connection. Open issues: 1. The patient may enter Wrong information (There should be proper mechanism to trap this down). Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta
P a g e | 19
Date
: 12th October, 2010
Use Case H-Appointment Use Case Primary Actors Goal in Context Preconditions Trigger Scenario:
1. 2. 3. 4. 5. 6. 7. 8. 1. 2. 3. 4. 5.
: Schedules, Reschedules Request with the doctor via HIS Website. : Patient : To Go for check-up to the hospitals doctor
: Patient must logged in the HIS system or call the Receptionist : Patient has fallen sick and wants to see doctor.
Patient presses the Schedule an Appointment Button or calls via Telephone. Patient Gets Appointment welcome screen. Clicks on New Appointment Button or Reschedule button or Cancel Schedule button Select the department and name of the doctor whom Patient wants to see. Press submit button. Request goes to Receptionist. Receptionist check the Doctors Schedule Receptionist gives or suggests new date to Patient.
Exceptions:
Website or Web Server is down. Mobile phone is moving out of the Internet connection zone. Session time out expires. Website maintenance is going on. Receptionist is not at the counter. Channel to Actor : Via PC-based browser and internet connection or phone. Secondary Actors : Receptionist, Doctor Channels to Secondary Actors: Receptionist: Via PC-based browser and internet connection or phone. Open issues : Patient may fill up wrong information. Here we have assumed that the Patient is not having emergency. Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta Date : 12th October, 2010
P a g e | 20

1. 2. 3. 4. 1. 2. 3. 4.
Use Case I-Pay the fees : Pay the amount after check up is complete : Patient : Pay the amount for Service rendered
: Patient must be checked by doctor. Receptionist must be logged in. : Finally it is time to pay.
Patient goes to Reception counter to pay Fees Receptionist feeds the patient name. System gets insurance detail and based on that calculates the Fee amount. Patient Gives the amount to receptions
Exceptions:
Website or Web Server is down. Mobile phone is moving out of the Internet connection zone. Session time out expires. Website maintenance is going on. Channel to Actor : Via PC-based browser and internet connection Secondary Actors : Receptionist Channels to Secondary Actors: Receptionist : Via PC-based browser and internet connection Open issues: Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta Date : 12th October, 2010
Use Case J- Logs the patient data : Logs the patient data like heart rate, blood pressure : Nurse : To Enter the patient heart rate blood pressure etc data.
: Nurse must be logged in with sufficient privilege. : It is part of the duty to take such test of patient.
1. When patient arrives in the hospital Nurse attends him. 2. She selects the patient name dropdown button in the HIS System
P a g e | 21
3. Nurse takes the test and press the Enter the Log of patient selected from drop down combo. 4. Nurse also asks Patient about the problem s/he is suffering from. 5. And enter the above data in to system. 6. Then she saves the data she entered by pressing save button.
Exceptions:
Website or Web Server is down. Session time out expires. Website maintenance is going on. Nurse selects other Menu Item or Link. Nurse enters the wrong data while asking the patient. Patient tells misleading information to the Nurse Channel to Actor : 1. Via PC-based browser and internet connection. Secondary Actors : Patient Channels to Secondary Actors: 1. Patient Via PC-based browser and internet connection. Open issues: 1. What if Patient is not able to speak or Write? Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta Date : 12th October, 2010 1. 2. 3. 4. 5. 6.
Use Case Primary Actors Goal in Context

attend them.
Use Case K-Nurse Checks Schedule : Check the Schedule via website and Mobile phone : Nurse : To See at what time he should remain present at the hospital so he could
: User must be logged in with sufficient privilege. : Nurse decides to take a look at his appointment with his patients.
Preconditions Trigger Scenario:

1. 2. 3. 4. 5. 6.
Nurse selects the Schedule Button available to him on the screen. System will give calendar. In calendar the red date, green dates and blue dates will be there. The red date indicates that there is higher number of patients to check. The green date indicates that there is moderate number of patients to check. The blue date indicates that there are no patient yet appointed.
P a g e | 22
7. The system displays the 3 option Daily, Monthly, Yearly. 8. The Nurse selects the Daily Schedule Option. 9. The system gives the Daily Schedule of the Nurse who is logged in. 10. The Nurse selects the Monthly Schedule option. 11. The system gives the Monthly schedule of the Nurse who is logged in. 12. The Nurse selects the Yearly Schedule option. 13. The system gives the Yearly schedule of the Nurse who is logged in. 14. Nurse could view the schedule by date and time and the patient name.
Exceptions:
Website or Web Server is down. Session time out expires. Website maintenance is going on. Nurse selects other Menu Item or Link. Channel to Actor : 1. Via PC-based browser and internet connection. 2. Mobile Phone Secondary Actors : Receptionist Channels to Secondary Actors: Open issues: 1. Can the Nurse logged in able to view the schedule of other Nurse? 2. Will mobile phone viewing be enough good (user friendly) for Nurse to view his schedule? (Small screen of mobile phone) Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta Date : 12th October, 2010 1. 2. 3. 4.
Use Case Primary Actors Goal in Context
Use Case L- Allot the room : Check the occupancy and allot the room to inpatient for : Receptionist : To have patient admitted in hospital because doctor wants to keep him
under observation or operation Preconditions : Receptionist must be logged in with sufficient privilege Trigger : To see whether there are any beds occupied
Scenario
1. Receptionist is at any screen of the system. 2. Select the Bed available button. 3. Asks the Patient Preference.
P a g e | 23
4. Allocates the Bed which patient wants.
Exceptions:
Website or Web Server is down. Session time out expires. Website maintenance is going on. There are no Rooms available to admit patient Channel to Actor : 1. Via PC-based browser and internet connection. 1. 2. 3. 4.
Secondary Actors : Patient Channels to Secondary Actors:

1. System Administrator: PC-based Web browser system 2. Patient: Face to Face Conversation Open issues: What if Bed is not available with the patient? Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta Date : 12th October, 2010
Use Case M-Admin Maintenance Use Case Primary Actors Goal in Context Preconditions Trigger Scenario : Add, Delete, Edit all stakeholder : Administrator : To change the Status of Doctor, Nurse, and Receptionist.
: Administrator must be logged in with sufficient privilege : Someone from the staff has left the job or some information about staff has changed or some has joined the organization.
1. Administrator is at any screen of the system. 2. Select the staff name. 3. Press the Add, Delete or Edit button to Add New staff, to discontinue the Staff and to edit the staff detail. 4. Enter the necessary detail. 5. Press ok to perform the action.
Exceptions:
1. Website or Web Server is down. 2. Session time out expires. 3. Website maintenance is going on. Channel to Actor :
P a g e | 24
1. Via PC-based browser and internet connection.
Secondary Actors : System Administrator, Receptionist Channels to Secondary Actors:

1. System Administrator: PC-based Web browser system 2. Receptionist: PC-based Web browser system Open issues: Priority : High When Available : First Increment Iteration : First Created by : Chintan Mehta Date : 12th October, 2010
P a g e | 25
Activity Diagrams
Activity Diagram for the Logging In of all Stakeholders (Use Case A)
Enter Password and UserID
Valid Password & ID
InValid Password or ID
Show the screen as per user role
Prompt For ReEntry
Exit this function
P a g e | 26
Activity Diagram for Doctor Check Schedule (Use Case B)
Doctor selects the Schedule button available to him
Calendar will be shown to Doctor from current date to whole year Calendar having the Red, Blue and Green color show High, None and Moderate numbers of appointments respectively.
Doctor selects the Particular Date to see appointments
Exit the function
A List of Particular Date & Time and Patient name Appointments appears on the screen with calendar on top of it. Drill down button appears before each Date& Time
Exit the function
Clicking date and time gives detail schedule, tasks and list of patient.
Exit the function
P a g e | 27
clicking patient name Doctor can see the profile which includes key demographic data which includes insurance, primary care provider, pharmacy
Exit the function
On clicking alerts, reminders and schedule of patient for any test Doctor would able to see those things.
Exit the function
On Pressing the Allergies and Medication button Doctor could be able to see the detail about that particular patient.
Exit the function
P a g e | 28
Activity diagram for Doctor Change the Schedule of Patient (Use Case C)
Doctor Presses change schedule button.
There appears the calendar on the screen (For selecting the date to change)
Exit the function
Doctor select the date and Press Save button Gone to Receptionist Receptionist Notifies the Doctor through email or message.
Date is Not Available
Date is Available
Exit the function
Calls the patient or send the schedule change notification to patient
Exit the function
P a g e | 29
Patient on receives the notification
Accepts the Date change request
Rejects the date change request
Old date is kept as it is
Exit the function
P a g e | 30
Activity Diagram for Lab Test (Use Case D)
Doctor Presses Lab Test Button
Dropdown box & Test List appears on the screen
Doctor selects the Patient name and Test to be done
Doctor Press Save button
Sends Patient to Lab
Lab is closed
Come next day
Lab is open
Lab does the test and logs the data

Exit the function
Patient goes to doctor
P a g e | 31
Activity Diagram for Prescribing Medicine (Use Case E)
Doctor Selects Prescribe medicine button
Patient Names Dropdown box & List of Drugs appear on the screen
Doctor selects the Patient name and Drugs name on after the other Doctor Press Save button Patient Goes to Pharmacy To get drugs
Pharmacist check patient name and gets the list of drugs
Gives the drugs listed by the Doctor
Exit the function
P a g e | 32
Activity Diagram for Keep in Touch (Use Case F)
Doctor Selects Keep In touch button
Patient Names Dropdown box
Doctor selects the Patient name
Patient Contact details are available
Remote Location : Video Conferencing
Email or Text Messages
System Saves the Talk done with Video conferencing system and Email System against patient name.
Exit the function
P a g e | 33
Activity Diagram for Patient Registering with System (Use Case G)
Patient log on to the Hospital Information System Website
Clicks on New Patient Registration Button
Fills Necessary detail required for registration (Name, SSN, Date of Birth).
Patient Press Save button
Administrator verifies the information
Accepts the Registration
Rejects the Registration Patient goes to doctor
Send the Patient the User name and Password
Patient goes to doctor Exit the function
P a g e | 34
Activity Diagram for Patient Schedule the Appointment (Use Case H)
Patient Schedule the Appointment
Calls the Receptionist
Via Website
Receptionist asks the Time
Patient put the preferred time slots for appointment and Doctor Name
Checks the Doctor Schedules Send Apologies message or ask for other date Not Available
Date is available
Sends the confirmation to patient
Exit the function Gives other date Schedules
P a g e | 35
Activity Diagram for Pay the Fees (Use Case I)
Patient goes to Reception counter to pay Fees
Receptionist Feeds the patient name in the system
System gets insurance detail and based on that calculates the Fee amount
Patient Gives the amount to receptions
Exit the function
P a g e | 36
Activity Diagram for Nurse Logs Patient Data (Use Case J)
When patient arrives in the hospital Nurse attends him
Nurse selects the patient name from dropdown button in the HIS System
Nurse takes the test and press the Enter the Log of patient selected from drop down combo
Enter the above data in to system.
Enter the above data in to system.
P a g e | 37
Activity Diagram for Nurse Check Schedule (Use Case K)
Nurse selects the Schedule button available to him
Calendar will be shown to Nurse from current date to whole year Calendar having the Red, Blue and Green color show High, None and Moderate numbers of appointments respectively.
Doctor selects the Particular Date to see appointments
Exit the function
A List of Particular Date & Time and Patient name Appointments appears on the screen with calendar on top of it. Drill down button appears before each Date& Time
P a g e | 38
Activity Diagram for Allotting Room to Patient (Use Case L)
Receptionist is at any screen of the system.
Select the Bed available button.
Asks the Patient Preference.
Bed is available
Bed is not available
Allot the bed, Enter the Bed and Patient data in to system.
Apologies
P a g e | 39
Activity Diagram for Administrator Maintenance (Use Case M)
Administrator is at any screen of the system.
Select the staff name
Press the Add, Delete or Edit button to Add New staff, to discontinue the Staff and to edit the
Enter Necessary Detail
P a g e | 40
Swimlane Diagrams Swimlane Diagram for Schedule the Appointment

Patient Receptionist Website
Schedule the Appointment
Via Website
Calls the Receptionist
Gives the Time
Put the preferred time slots for appointment and Doctor name
Checks the Doctor Schedules Date is available Not Available Sends the confirmation Send Apologise message or ask for other date
Exit the function
Gives other date
P a g e | 41
Swimlane Diagram for Login and Registration

Patient Website System Administration
Logs on to the site All ready registered
Clicks on First time Fill username and Password
Enters Registration Details
Approve the registration
Valid UserID Password Flashes Incorrect UserID Password message
Valid UserID Password
DisApproves the registration
Moves to User Specific Screen
Send Approval to patient via emai with USERID and Password
P a g e | 42
Table of Classes (With Purpose, Attributes and Operations)

By Performing Grammatical Parse on the Use Cases we are able to identify the Classes its attributes and the operations
No
1
Name of Class
Patient
Purpose
To maintain Patients Profile of Each visit
Attributes
Operations
ViewSchedule PutApptRequest RegistersWithSystem ApproveVisit DisApproveVisit RecommendVisit
Doctor
PatientID PatientName Address SSN Sex BirthDate Allergies Reactions Doctor is DoctorID heart of the DoctorName Hospital and Degree initiates most Area Of of the task Specialisation JoinDate LeavingDate DoctorType
PrescribesMedicine SuggestsTests ChecksPreviousVisitData ChecksHisSchedule ChecksVideoForRemotePati ent ChecksNurseLoggedFinding ChecksPatientSchedule ChangePatientSchedule DrawSalary RecordsRemotePatientVideo SendMessageSMS ViewParticularPrescirption
Prescription
Doctor Prescribes the Medicine
Nurse
Schedule
PrescriptionID MedicineName Dosage DateAndTime Nurse is the NurseID second NurseName person whom JoinDate patient has to LeavingDate meet DoctorID DateAndTime StopDateAndTime Scheduling ScheduleID of Doctor, ScheduleDateAndTi Patient, me Nurse PatientID NurseID
LogsPatientData DrawSalary
StartRecording StopRecording GetSchedule
P a g e | 43
PatientVisitDetail (Appointment)
Stores Patient Visit Details
Receptionist
Attends the Patient first when the Patient visits the clinic Saves the data of every visit
DoctorID VisitID VisitDate PatientID PrescriptionID DoctorID NurseID Insurance IsRemotePatient VisitChargeFees Ward RoomNo IsInPatient VideoRecordPath Diagnoses ReceptionistID
PayTheBill
TakesFees AllotRoomOrBed ChecksDoctorSchedule ChecksPatientApptRequest AllocatesPatientVisitDateTi me
PatientMedicalFind ing
VisitID TestName TestImages TestFinding TestID TestName TestDataType(Image ,Video, Number, Text) UnitOfMeasurement LogInStatus UserName UserId Password Role(Patient,Doctor etc) Login Time Logout Time AdminName Address Sex GetTestDataType CreateNewTesr
LabTests
What are the test done at this hospital
10
User
Allows the user to access the system
LogsIn LogsOut IsAuthenticateUser
11
Admin
Administers the User and take backup
ApprovesPatientRegistration AddDoctor AddNurse
P a g e | 44
and restores.
SSN
AddStaff UpdateDoctor UpdateNurse UpdateStaff DeleteDoctor DeleteNurse DeleteStaff TakeBackup RestoreDatabase
P a g e | 45
A Class Connectivity Diagram, Associations and Dependencies

User
Is Kind Of
Patient
Doctor
Nurse
Receptionist Can have
Admin
Can have Is having
Can have
PatientVisit Goes for PatientMedicalFinding
Schedule
Prescription
LabTest
*All Attributes and Properties of Class are listed on previous page
P a g e | 46
Data Flow Diagram (DFD)

Context Level-DFD
Administrator
Username password Hospital Information System
Add Update Delete
Doctor /Nurse/ Receptionist
P a g e | 47
DFD Level 1
Patient First Time Database
Doctor UserID password Nurse
Processes Hospital Information
Receptionist Laboratory Pharmacy
P a g e | 48
DFD Level 2
Patient First Time Registration Detail Database
Registers With System
Registration Detail
UserID Password Approves The Patient & Emails UserID Password UserID Password Doctor Display Menus Logs In to the system ,Display the Respective Menu
Administrator
Database
UserID Password Display Menus Nurse
Display Menus
UserID Password
Receptionist
Laboratory
Pharmacy
P a g e | 49
DFD Level 3 Logs In to the system, Display the Respective Menu
Patient Appointment Booking System Database
Diagnoses Disease and Prescribes Medicine
Doctor Allot Ward and Bed
Receptionist
Pharmacy
Remote Calling and Recording System
Nurse
Laboratory
Laboratory Test & Patient Log System
P a g e | 50
DFD Level 4 Appointment Booking System

Patient
Time Slot, Date, Doctor Puts the Request for Appointment Database
Time, Date Email
Puts his schedules
Time, Date, DoctorID
Doctor
DoctorID, PatientID, Date & Time of Doctor and Patient
Informs to Patient or Calls him Confirms Appointment email
Available date, time Time, Date Receptionist Check the Doctor and Patient Schedule
P a g e | 51
DFD Level 4 Diagnose Diseases & Prescribe Medicine System
PatientID, Medicine Names Write The Prescription Database
PatientID, Findings
PatientID, Medicine Names
Get The medicine Lsit
Doctor
Diagnose the diseases
PatientID Date, DoctorID Patient Pharmacy Medicine
P a g e | 52
DFD Level 4 Allot Ward and Bed
Patient Database Patient ID Ward And Bed Allots The Room Gets The Ward and Bed Detail Goes To Counter Ward And Bed
Patient ID
Available Ward and Bed Receptionist
Check for the Availability of Ward and Bed
P a g e | 53
DFD Level 4 Laboratory and Patient Log System
Patient Database PatientID
Comes To Doctor
PatientID Saves Test Finding Doctor PatientID Test Names
Types of Test
Saves Patient Log
Does Test
Suggest Laboratory Test
PatientID
PatientID Test Names
Logs Patient Medical Findings
Laboratory Remote Calling and Recording System
Nurse
P a g e | 54
A Set of Data and Data object Type being used

1] SecurityUser
No 1 2 3 Data Attributes UserLoginID UserName UserPassword Type Alphanumeric Character Alphanumeric Data UL000001 Joe Johnson gj0001
2] Address
No 1 2 3 4 5 6 Data Attributes AddressID Street1 Street2 ZIPCode State Country Type Alphanumeric Character Character Character Character Character Data AD000001 YorkTown St Apartment No 67 77056 TEXAS USA
3] PatientType
No 1 2 Data Attributes PatientTypeID PatientTypeName Type Alphanumeric Alphanumeric Data PT000001 InPatient
4] DoctorType
No 1 2 Data Attributes DoctorTypeId DoctorTypeName Type Alphanumeric Alphanumeric Data DT000001 Surgeon
5] Patient
No 1 2 3 4 5 6 Data Attributes PatientID AddressID Type UserLoginID Allergies Reactions Type Alphanumeric Number TypeID Alphanumeric Alphanumeric Alphanumeric Data PA000001 AD000001 DC000001 UL000001 Dusting MetaMorphin
P a g e | 55
6] Doctor
No 1 3 4 5 6 7 8 Data Attributes DoctorID DoctorTypeID Degree AreaOfSpecialisation JoinDate AddressID UserLoginID Type Alphanumeric Alphanumeric Character Character Date Alphanumeric Alphanumeric Data DC000001 DT000001 MD Cardio Vascular 10/12/2008 AD000001 UL000001
6.1] DosageType
No 1 2 Data Attributes DosageTypeID DosageTypeName Type Alphanumeric Alphanumeric Data DOS00001 3 times a day
7] Prescription
No 1 2 3 4 Data Attributes PrescriptionID MedicineName Dosage DosageTypeID Type Alphanumeric Number Number Alphanumeric Data PS000001 Cetrizine Hydrochloride 5 DOS00001
8] Nurse
No 1 2 3 4 Data Attributes NurseID AddressID UserLoginID JoiningDate Type Alphanumeric Number TypeID Date Data NS000001 AD000001 UL000001 12/10/2007
9] Schedule
No 1 2 3 4 5 Data Attributes ScheduleID PatientID DoctorID NurseID ScheduleDateTime Type Alphanumeric Alphanumeric Alphanumeric Alphanumeric Date & Time Data SC000001 PT000001 DC000001 NS000001 10/10/2010 12:45 PM
P a g e | 56
10] PatientVisitDetail
No 1 2 3 4 5 6 7 8 9 10 11 12 13 Data Attributes VisitID VisitDateTime PatientID NurseID DoctorID WardID RoomID BedID PrescriptionID PatientTypeID IsRemoteVisit VideoRecordedPath Diagnoses Type Alphanumeric Date Alphanumeric Alphanumeric Alphanumeric Alphanumeric Alphanumeric Alphanumeric Alphanumeric Alphanumeric Boolean Alphanumeric Alphanumeric Data VS000001 10/12/2010 PA000001 NU000001 DT000001 WA000001 RM000001 BD000001 PR000001 PT000001 YES C:\Video1.mpg Suffering from Ulcerative colitis
11] LabTest
No 1 2 3 4 Data Attributes LabTestID LabTestName LabTestDataType UnitOfMeasurement Type Alphanumeric Alphanumeric Alphanumeric Alphanumeric Data LT000001 Blood Sugar Number Gm/ml
12] PatientMedicalFinding
No 1 2 3 4 Data Attributes VisitID LabTestID TestImages TestFindings Type Alphanumeric Alphanumeric Image Alphanumeric Data VS000001 LT000001 Image of Xray/ Video EchoCardiography X-Ray shows Tuberclosis
13] Ward
No 1 2 Data Attributes WardID WardName Type Alphanumeric Alphanumeric Data WR000001 Cancer Ward
P a g e | 57
14] Room
No 1 2 Data Attributes RoomID RoomName Type Alphanumeric Alphanumeric Data RM000001 General Room
15] Bed
No 1 2 Data Attributes BedID BedDescription Type Alphanumeric Alphanumeric Data BD000001 Good Bed
State Diagrams
State Diagram for Prescription Class
No
Writing Logs In
Medicine Selected
Checking Do IsAvailable
Yes
Yes Checking Reaction
No & More than Once
Refilled
No & First time
Prescribed
P a g e | 58
State Diagram for Appointment Class
Creating Logs In
Waits for further approval
Approving
Want to change or cancel
Disapproving Reschedul ing
Canceling
P a g e | 59
Sequence Diagram
Doctor Prescribes Medicine
Doctor
Pharmacy
Database
ChecksForReaction(PatientID)
GetsReactionList PrescribesMedicine(PatientID)
GetTheMedicineList(PatientID) Get the list
P a g e | 60
Get Patients Data and Diagnose

Doctor Website Database
Enters PatientID GetPatientData Display Information Diagnose diseases Save the Diagnoses
P a g e | 61
Change Schedule of the Patient

Doctor Website Receptionist Database
Change Schedule Appears calendar Select date SavePatientNewSch GetAllChangeRequest ShowAllChange Requests Process It SaveTheProcessedToDatabase NotifyDoctor
P a g e | 62
Validating all Requirements

No
1
Question
Is each requirement consistent with the overall objectives for the system/product?
Answer
Yes
Reason
The overall objective of the system is to take care about Patient, Doctor, Nurse, Pharmacy and Laboratory and it is well achieved. All the requirements gives the overview of system without going into the detail of those requirements The requirement say for example Videos of remote patient is not essential to the objective of the system There are no such requirements which are ambiguous but at the end what are Joes more requirements is still unspecified. All requirements are having the source. All the requirement are crystal clear and do not conflict with each other. Yes each requirement for example video-conferencing need will require more system resource then present condition. We can test the requirements once they are implemented provided they are fully equipped with system resources. The requirement model reflect the behavior of the system to be built but also need extra functionality like Refilling of medicine etc in it to be complete It has been partitioned to accommodate the more detailed information about the
Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this state? Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? Is each requirement bounded and unambiguous?
No
Yes
Yes
Does each requirement have attribution? That is, is a source (generally a specific individual) noted for each requirement? Do any requirements conflict with other requirements? Is each requirement achievable in the technical environment that will house the system or product?
Yes
No
Yes
Is each requirement testable, once implemented?
Yes
Does the requirements model properly reflect the information, function, and behavior of the system to be built?
Yes
10
Has the requirements model been partitioned in a way that exposes progressively more detailed information
Yes
P a g e | 63
No
11
Question
about the system? Have requirements patterns been used to simplify the requirements model?
Answer
Yes
Reason
system For example for login and Appointment we have taken standard way to do it.

Mehta Chintan SRS

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mehta Chintan SRS

Hochgeladen von

Copyright:

Verfügbare Formate

Software Requirements Specification for Hospital Information System

Software Requirements Specification For Hospital Information System Version 1.0

Software Requirements Specification for Hospital Information System

Software Requirements Specification for Hospital Information System

Software Requirements Specification for Hospital Information System

Software Requirements Specification for Hospital Information System

Software Requirements Specification for Hospital Information System

Statement of Need and Feasibility

A Bounded Scope for the System

Software Requirements Specification for Hospital Information System

A list of All Stakeholders Interviewed

Systems Technical Requirement

Software Requirements Specification for Hospital Information System

Numbered list of requirements and the constraints that apply to each

Functional, Use Case, Data Data Objects

Functional, Use Case, Data Data objects

Functional, Use Case, Data Data objects

Software Requirements Specification for Hospital Information System

Functional, Use Case, Data Data objects

Functional, Use Case, Data Data objects

Functional, Use Case, Data Data objects

Functional, Use Case, DFD, Flow, Data Data objects

Doctor enter his diagnoses and Prescribes medicine.

Software Requirements Specification for Hospital Information System

Use Case Diagram 1

Doctor Patient Laboratory Nurse Receptionist Pharmacy Administrator

Add, Delete, Edit Staff, Doctor, Patient

Software Requirements Specification for Hospital Information System

Use Case Diagram 2

Prescribe the Laboratory test Pharmacy Prescribe the Medicine

Phone & Viedo calling recording

Email system Schedules or Cancel Reschedules appointment

Software Requirements Specification for Hospital Information System

Use Case Scenarios

Preconditions Trigger Scenario:

Software Requirements Specification for Hospital Information System

Use Case Primary Actors Goal in Context Preconditions Trigger Scenario:

Software Requirements Specification for Hospital Information System

Secondary Actors : Receptionist, Patient Channels to Secondary Actors:

Software Requirements Specification for Hospital Information System

Priority When Available Iteration Created by Date

: Moderate : First Increment : First : Chintan Mehta : 12th October, 2010

Software Requirements Specification for Hospital Information System

Priority When Available Iteration Created by Date

: High : First Increment : First : Chintan Mehta : 12th October, 2010

Use Case Primary Actors Goal in Context Preconditions Trigger Scenario

Software Requirements Specification for Hospital Information System

: 12th October, 2010

Use Case Primary Actors Goal in Context Preconditions Trigger Scenario

Software Requirements Specification for Hospital Information System

When Available Iteration Created by Date

: First Increment : First : Chintan Mehta : 12th October, 2010

Use Case Primary Actors Goal in Context Preconditions

Software Requirements Specification for Hospital Information System

: 12th October, 2010

Software Requirements Specification for Hospital Information System

Use Case Primary Actors Goal in Context Preconditions Trigger Scenario:

Use Case Primary Actors Goal in Context Preconditions Trigger Scenario:

Software Requirements Specification for Hospital Information System

Use Case Primary Actors Goal in Context

Preconditions Trigger Scenario:

Software Requirements Specification for Hospital Information System