Software Requirements Specification Template

Software Requirements Specification for HCI Prototype
Page i
Software Requirements
Specification
for
ACME Medical Centre
Table of Contents
Table of Contents ........................................................................................................................... i
1. Introduction..............................................................................................................................1
1.1 Purpose............................................................................................................................................. 1
2. Overall Description..................................................................................................................1
2.1
2.2
2.3
2.4
2.5
2.6
Product Perspective.......................................................................................................................... 1
Product Features .............................................................................................................................. 1
User Classes and Characteristics...................................................................................................... 1
Operating Environment.................................................................................................................... 1
User Documentation ........................................................................................................................ 2
Assumptions and Dependencies....................................................................................................... 2
3. System Features .......................................................................................................................2
3.1 Appointment Booking and Scheduling............................................................................................ 2
3.2 Patient Details Entry and modification ...........................................Error! Bookmark not defined.
3.3 Billing
System……………………………………………………………………………..4
3.4 Reporting
System………………………………………………………………………….5
4. External Interface Requirements ...........................................................................................5
4.1 User Interfaces ................................................................................................................................. 5
4.2 Hardware Interfaces ......................................................................................................................... 5
4.3 Software Interfaces .......................................................................................................................... 6
5. Other Nonfunctional Requirements.......................................................................................6
5.1 Performance Requirements .............................................................................................................. 6
5.2 Safety Requirements ........................................................................................................................ 6
5.3 Security Requirements ..................................................................................................................... 6
Appendix A: Work Flow diagram of system use ........................................................................7
Software Requirements Specification for acme medical centre
Page 1
1. Introduction
1.1 Purpose
This document describes the requirements we have compiled for acme medical centre. The
customer is a single doctor medical centre. They require a software package to replace their
current paper system.
There are a number of details to cover and in discussion with customer we have compiled a list of
their requirements, they want the system to be user friendly and should be flexible and if in the
near future a second doctor would join the organization they the system should be easily updated
with little disruption. In the following sections I will detail the different components that will make up
this system.
2. Overall Description
2.1 Product Perspective
This system is to replace an existing paper system being operated by the customer. The system
will need to store patient details; system will also need to maintain details of billing information etc.
2.2 Product Features
The Main features of this product will all be based on a central repository of data, which will need
to be saved on a data base system. The main functions will be as follows.
1) Appointment booking and scheduling.
2) Patient detail entry/modification/.deletion.
3) Billing System.
4) Report generation.
2.3 User Classes and Characteristics
The system is designed for primary use of the medical centre’s receptionist; she is a competent
computer user with moderate to good computer skills. The doctor also wishes to have access to the
system primarily for display purposes but on occasion for data entry and report generation.
2.4 Operating Environment
The system will need to operate seamlessly on both MS Windows XP professional and also on
Windows vista. The system will run on a generic windows desktop but should be portable to other
environments if needs be.
Software Requirements Specification for acme medical centre
Page 2
2.5 User Documentation
The system is required to have a help menu with a graphical online user manual to assist with any
issues encountered with general use of system. The user manual will also be developed in hard
copy and on the job training will be delivered to assist with any initial usage issues.
2.6 Assumptions and Dependencies
It is assumed that as stated the centre receptionist is computer literate, she along with the doctor
have completed ECDL so it is expected with minimal training that system could go into operational
usage without issue.
3. System Features
The main system features are defined as follows
3.1 Appointment Booking and Scheduling.
3.1.1
Description and Priority
This section of the system will be a high priority feature, It will handle the scheduling
of Patient appointment time
3.1.2
Stimulus/Response Sequences
When a Patient requests an appointment, the receptionist will open the doctor’s
calendar and should be provided with a list of available appointments.
When the appointment is chosen the patents details and a short description of
appointment details are entered doctors’ schedule is then updated.
3.1.3
Functional Requirements
REQ-1:
When receptionist opens doctors’ calendar it should open on the current
day showing available and unavailable timeslots (unavailable/booked slots
should have a short description displayed and when clicked on should open
up to full appointment details). There will need to be a toolbar to allow
add/edit/delete appointment options.
REQ-2: When user chooses menu to add new appointment a new dialog boxes
should appear detailed as follows.
REQ-2-1: A drop down menu of all given days available timeslots, ony one
can be selected.
REQ-2-2: A drop down menu to select patient by surname.
REQ-2-3: A link to Add new patient subsystem will be required.
REQ-2-4: An appointment type from drop down menu (Company Medical,
Insurance Medical, general consultation)
REQ-2-5: A brief synopsis of symptoms.
REQ-3: The calendar view should allow user to open up each specific appointment
entry for editing deletion etc.
REQ-4: The calendar view should allow movement to a weekly view, daily view,
monthly view etc. It should also allow user to move forward/back a week
etc.
Software Requirements Specification for acme medical centre
Page 3
REQ-5:
REQ-6:
The system should be able to handle multiple user access, i.e. when an
appointment is being booked then database should be locked for update
until the appointment is saved.
The system should be able to set a base working hours for doctor
dynamically. i.e. we should not be able to book an appointment at 7:30 pm
if doctors’ surgery completes at 5:00 pm. However we should be able to
change working hours within system.
3.2 Patient Details Entry and modification.
3.2.1
Description and Priority
This section of the system will be a high priority feature, here we will handle the main
data entry for the system.
3.2.2
Stimulus/Response Sequences
When receptionist wishes to enter a new patient to the system she/he should be
provided with a dialog box to enter specific patient details.
3.2.3
Functional Requirements
REQ-1:
A search facility will need to be available to open specific patients’ details.
Search can be carried out on
REQ-1-A-1: Patient Number.
REQ-1-A-2: Patient Surname.
Display should be as follows
REQ-1-B-1: search facility to return a list of patient number, first name,
surname which is expandable into a display of full patient details.
REQ-1-B-2: once expanded view should show all patient information
entered in database (ref REQ-2). There should be an expandable text
display for patient history (REQ-2-21).
REQ-2:
A facility to add a new patient to system is required
REQ-2-1: A field for patient number should be provided, this will be an
auto-generated value and will not be editable.
REQ-2-2: A field for Patient first name will be provided which will be a
string value and will be validated as such).
REQ-2-3: A field for Patient surname will be provided which will be a
string value and will be validated as such).
REQ-2-4: A field for address line 1 will be provided and is a mandatory
field.
REQ-2-5: A field for address line 2 will be provided and is an optional
field.
REQ-2-6: A field for address line 3 will be provided and is an optional
field.
REQ-2-7: A field for Town/City will be provided and is a mandatory field.
REQ-2-8: A field for County will be provided and is a mandatory field,
defaulting to base county of centre.
REQ-2-9: A field for Country will be provided and is a mandatory field,
defaulting to base country of centre.
Software Requirements Specification for acme medical centre
Page 4
REQ-2-10: A field for PPS number is provided with string value,
mandatory field.
REQ-2-11: A drop down menu for medical insurer will be provided with a
list of VHI, QUINN Healthcare, Vivas and other.
REQ-2-12: A other text box will be provided but will be locked for editing
unless other is selected from REQ-2-11.
REQ-2-13: Insurance Policy Number field will be required with string
format and will be optional field.
REQ-2-14: Insurance Plan field will be required with string format and will
be optional field.
REQ-2-15: Patient contact number field will be provided and will be a
numeric string, this will be a mandatory field.
REQ-2-16: Patient contact email address, this will be a mandatory field and
will be validated for correct format.
REQ-2-17: Patient Date of birth field will provide a locked text box with a
calendar icon for correct data selection to prevent selecting erroneous dates
such as 31-13-00 etc.
REQ-2-18: Parent/guardian field provided will be of type string. In REQ2-17 if DOB is below 18 it will be flagged and a parent/guardian field will
be mandatory else optional field.
REQ-2-19: Next of Kin first name, this will be a string field.
REQ-2-20: Next of Kin surname, this will be a string field.
REQ-2-21: Next of Kin Contact Number- string field.
REQ-2-21: Medical history field, this will be a large text box field
provided to detail any ongoing/historical medical history a patient might
have.
REQ-2-22: A flag to be implemented to mark a patient as deceased.
REQ-3:
The system will need to provide a facility to edit patient details.
All patients’ details are editable except for patient number (REQ-2-1).
REQ-4: The system should be able to handle multiple user access, i.e. when a
patient is being added/edited/deleted then database should be locked for
update until the change is saved.
REQ-5: The system should provide a facility to delete patient details.(This will be
required to ensure duplicate/erroneous entries can be removed from
database, however user will have to confirm removal twice as to prevent
removing current patients).
3.3 Billing System.
3.3.1
Description and Priority
This section of the system will be a medium priority feature, here we will handle the
billing system.
3.3.2
Stimulus/Response Sequences
When an appointment is complete then doctor/receptionist can close appointment by
updating appointment notes and appointment fee.
3.3.3
Functional Requirements
Software Requirements Specification for acme medical centre
Page 5
REQ-1: We should maintain a current bill for each patient.
REQ-2: Should be a method for editing current bill.
REQ-3: The system should provide an itemized bill.
REQ-4: The system should be able to handle multiple user access, i.e. when an
billed item is being added/edited/deleted then database should be locked for
update until the change is saved.
3.4 Reporting System.
3.4.1
Description and Priority
This section of the system will be a low priority feature, here we will handle the
Reporting system.
3.4.2
Stimulus/Response Sequences
This section should provide the ability to generate reports on utilization /patient
history and current bill status/individual bill status.
3.4.3
Functional Requirements
REQ-1:
REQ-2:
REQ-3:
REQ-4:
REQ-5
We should be able to present a report on patient history.
We should be able to print out itemized bills.
System should provide system a Utilization bill (i.e. how much of working
hours are take up with appointments).
The presented bills need to be printable.
The system should be able to print out appointment reports required for
work absence, insurance medical certificates etc.
4. External Interface Requirements
4.1 User Interfaces
The user interface should be straight forward and functional. As both doctor and Receptionist are
ECDL trained we will keep layout of interfaces similar to the standard MS office interfaces. Each
screen through out system will provide a help screen facility.
4.2 Hardware Interfaces
The system should be fully functional on windows based desktops and should be able to interface
with printer. Both mouse and keyboard will be supported as input devices.
Software Requirements Specification for acme medical centre
Page 6
4.3 Software Interfaces
The system needs to interface with a SQL Server database, running on windows operating system.
5. Other Nonfunctional Requirements
5.1 Performance Requirements
The system will need to perform reasonably fast , main performance constraints is that down time
should be minimal for upgrades patching etc.
5.2 Safety Requirements
Customer has developed a backup/restore policy for the database back end of this system, where
they will backup they’re database image at the end of the day and take one database back up
image offsite once weekly.
5.3 Security Requirements
The customer has advised that there will be no initial need for any application level security. Each
system will work off the windows security. Customer will shut down systems at the end of the day
to prevent any data security issues.
Software Requirements Specification for acme medical centre
Page 7
Appendix A: Example flow chart of main system operation.
New Appointment
Generation
User opens
Appointment &
scheduling
subsystem
Appointment
&
Scheduling
Subsystem.
Returned list of
available
appointments
User Select required
Appointment.
User Selects Patient name
from list provided.
Database locked for
update and change
applied
Lock released and exit
Appointment booking
subsystem.
Download PDF