You are on page 1of 31

Software Requirements

Specification
for
Clinic Patient Record System
(CPRS)
Version 1.0

Prepared by

Muhammad Hafizul Hazmi Wahab 184611


Mohamad Syahmi Said 184334
Tan Kim Seang 182938

Lecturer: YBhg. Prof. Dr. Rusli bin Hj. Abdullah

Course: SSE3001
Introduction to Software Engineering

Date: 16 May 2017


Software Requirement Specification for
<Clinic Patient Record System> Page |1

Contents
1.0 INTRODUCTION ................................................................................................................................. 3
1.1 PURPOSE ................................................................................................................................................ 3
1.2 DOCUMENT CONVENTION ......................................................................................................................... 3
1.3 INTENDED AUDIENCE AND READING SUGGESTIONS ......................................................................................... 3
1.4 PRODUCT SCOPE ...................................................................................................................................... 4
2.0 OVERALL DESCRIPTION ..................................................................................................................... 5
2.1 PRODUCT PERSPECTIVE ............................................................................................................................. 5
2.2 PRODUCT FUNCTIONS ............................................................................................................................... 5
2.3 USER CLASSES & CHARACTERISTICS ............................................................................................................. 5
2.4 OPERATING ENVIRONMENT ........................................................................................................................ 6
2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS ............................................................................................... 6
2.6 USER DOCUMENTATION ............................................................................................................................ 7
2.7 ASSUMPTIONS AND DEPENDENCIES ............................................................................................................. 7
3.0 EXTERNAL INTERFACE REQUIREMENTS ............................................................................................. 8
3.1 USER INTERFACES..................................................................................................................................... 8
3.1.1 Log in Page [Management Staff & Non-Management Staff] ......................................................... 8
3.1.2 Menu [Receptionist vs Doctor vs Administrator] ............................................................................ 9
3.1.3 Add Staff [Administrator] .............................................................................................................. 10
3.1.4 Delete Staff [Administrator] .......................................................................................................... 10
3.1.5 View Staff ...................................................................................................................................... 11
3.1.6 View Appointment [Doctor] .......................................................................................................... 11
3.1.7 View Inventory [Doctor] ................................................................................................................ 12
3.1.8 Create Schedule [Receptionist] ..................................................................................................... 12
3.1.9 Create Appointment [Receptionist] .............................................................................................. 13
3.1.10 Update Patient Appointment [Receptionist] ............................................................................ 14
3.1.11 Add Patient [Receptionist] ........................................................................................................ 14
3.1.12 View Patient [Receptionist] ...................................................................................................... 15
3.1.13 Create Treatment Record [Receptionist] .................................................................................. 15
3.1.14 Search Individual Patient Record [Receptionist] ....................................................................... 16
3.1.15 Search Individual Patient Appointment [Receptionist] ............................................................. 17
3.1.16 View Inventory [Receptionist] ................................................................................................... 18
3.1.17 Add Inventory [Receptionist] .................................................................................................... 18
3.1.18 Update Inventory [Receptionist] ............................................................................................... 19
3.1.19 Contact Us [Receptionist / Doctor / Administrator] ................................................................. 19
3.2 HARDWARE INTERFACES .......................................................................................................................... 20
3.3 SOFTWARE INTERFACES ........................................................................................................................... 20
3.4 COMMUNICATIONS INTERFACES ................................................................................................................ 20
4.0 SYSTEM FEATURES .......................................................................................................................... 21
4.1 SYSTEM LOGIN & REGISTRATION ............................................................................................................... 21
4.1.1 Description & Priority .................................................................................................................... 21
4.1.2 Stimulus/Response Sequences ...................................................................................................... 21
4.1.3 Functional Requirements .............................................................................................................. 22
4.2 APPOINTMENTS BOOKING & MANAGEMENT .............................................................................................. 22
4.2.1 Description & Priority .................................................................................................................... 22
4.2.2 Stimulus/Response Sequences ...................................................................................................... 22
4.2.3 Functional Requirements .............................................................................................................. 23
4.3 PATIENTS TREATMENT RECORD CREATION & PROFILE .................................................................................. 23
4.3.1 Description & Priority .................................................................................................................... 23
4.3.2 Stimulus/Response Sequences ...................................................................................................... 24
4.3.3 Functional Requirements .............................................................................................................. 24
Software Requirement Specification for
<Clinic Patient Record System> Page |2

4.4 INVENTORY MANAGEMENT ...................................................................................................................... 24


4.4.1 Description & Priority .................................................................................................................... 24
4.4.2 Stimulus/Response Sequences ...................................................................................................... 25
4.4.3 Functional Requirements .............................................................................................................. 25
5.0 OTHER NON-FUNCTIONAL REQUIREMENTS ..................................................................................... 26
5.1 PERFORMANCE REQUIREMENTS ................................................................................................................ 26
5.2 SAFETY REQUIREMENTS ........................................................................................................................... 26
5.3 SECURITY REQUIREMENTS ........................................................................................................................ 26
5.4 SOFTWARE QUALITY ATTRIBUTE................................................................................................................ 26
5.5 BUSINESS RULES .................................................................................................................................... 27
6.0 OTHER REQUIREMENTS.......................................................................................................................... 28
APPENDIX A: GLOSSARY .............................................................................................................................. 28
APPENDIX B: WEB APPLICATION ARCHITECTURE ......................................................................................... 29

APPENDIX C: TO BE DETERMINE LIST........................................................... 27

Revision History
Name Date Reason for changes Version
Software Requirement Specification for
<Clinic Patient Record System> Page |3

1.0 Introduction
1.1 Purpose

This document is the software requirement specification (v1.0) for Clinic Patient
Record System (CPRS). The main objective of this system is to replace the existing
system in small-sized clinics, particularly in rural areas, that still relies on paper-based
database. The traditional paper-based database has many downsides, such as slow
records lookup, loss of records and tiresome filing and records procedure. Thus, CPRS
is proposed in order to help these small-sized clinics in terms of storing and managing
patients records and appointments.

1.2 Document Convention

This document uses Calibri and Calibri Light font throughout the entire
document. Topic headlines use Calibri, bold, size 18 font. Subtopic headlines use Calibri,
bold, size 15 font. Smaller subtopic headlines use Calibri, bold, size 13 font. The content
of each sections are documented using Calibri Light with size 13 font. The 2.54cm
margin is maintained throughout this document. Lastly, the spacing used is set to 1.0
with extra spacing added before and after the header.

1.3 Intended Audience and Reading Suggestions

This document is primarily intended for our lecturer of Introduction of Software


Engineering Course (SSE3001). It is, however, also open to other lecturers of Faculty of
Computer Science & Information Technologies, the stakeholders of CPRS and third
parties who may have an interest in CPRS.

The remainder of this document provides the system description and a technical
outline for the requirements of this system. In section two, the high-level descriptions of
the system functionalities and implementation details are explained and illustrated. In
section three, the external interface requirements for various interfaces are discussed. In
section four, the primary features of CPRS are described. In section five, the description of
non-functional requirements in CPRS are listed and documented. Finally, other relevant
requirements are stated in section six.

This document is meant to be read in sequence.


Software Requirement Specification for
<Clinic Patient Record System> Page |4

1.4 Product Scope

CPRS is a web-based system that is designed to record patients and staffs


information, recording completed treatments, as well as handling clinic appointments.

The administrator (clinic owner) is able to register staff into the system, which
are categorized to administrator, receptionist, and doctor.

Receptionists are able to register patients, create doctors schedules, create


appointments, register treatment records, register new item into inventory, and update
item quantity. They can also search for patients profile, treatments, as well as their
past and future appointments.

Doctors will only be able to view their own upcoming appointments and the
clinics inventory.

This system is meant to ease the staffs workload in retrieving and keeping track
of patients records, appointments, and the clinics inventory.

1.5 References

REBox Requirement Engineering Box Weigers Template. Retrieved from


http://isg.inesc-
id.pt/REBox/WiegersTemplate@17.aspx?page=4ExternalInterfaceRequirement
s on 13 May 2017.
IEEE Software Requirement Specification Template. Retrieved from
https://web.cs.dal.ca/~hawkey/3130/srs_template-ieee.doc on 13 May 2017.
Mochal, T. (2008). 10 techniques for gathering requirements. Retrieved from
http://www.techrepublic.com/blog/10-things/10-techniques-for-gathering-
requirements/ on 13 May 2017
Rouse, M. (n.d). Java Database Connectivity. Retrieved from
http://www.theserverside.com/definition/Java-Database-Connectivity-JDBC on
13 May 2017.
Software Requirement Specification for
<Clinic Patient Record System> Page |5

2.0 Overall Description


2.1 Product Perspective

This system consists of a back-end and a front-end perspective. In front-end,


staffs can interact directly with active server pages (.jsp) using the interfaces provided
through a web browser (e.g. Google Chrome & Microsoft Edge).

In back-end, our system consists of Database Server, Application Server and Web
Server. The combination of front-end and back-end perspectives will enable
management staffs to key-in data at the front-end, data processing at the back-end and
lastly the output of the process will be available to view on at the front-end. The outputs
are then will be by staffs to facilitate their daily clinical interactions.

2.2 Product Functions

1. Administrator can add, delete and view staff, which are divided into
administrator, receptionist and doctor usertype.
2. Doctor can view their upcoming appointments.
3. Doctor and receptionist and view the clinics inventory.
4. Receptionist can register new patient into the database.
5. Receptionist can search patients profiles, treatments, and past and future
appointments based on patient IC.
6. Receptionist can add, update, and delete doctors schedule.
7. Receptionist can register new appointment for a patient based on doctors
availability, which in turn is based on doctors schedule.
8. Receptionist can modify appointment status from UPCOMING to WAITING,
COMPLETED and CANCELLED.
9. Receptionist can register new item into the inventory.
10. Receptionist can update the item quantity in inventory.

2.3 User Classes & Characteristics

The primary user of CPRS will be the receptionists, who are tasked with recording
patients information, adding treatment records, and handling appointments in the
clinic. The secondary user of the system are the doctors, who are tasked with treating
and prescribing medicines to the patients. The clinic owner would be the default
administrator tasked with adding and removing users from the system. Some of the
users may not be as tech-savvy and require training to use CPRS effectively.

In the back-end of CPRS would be our team of Software Engineers and Database
Administrator, who are tasked with maintaining and developing new features for CPRS.
Any future changes to the software requirements will be conducted by us.
Software Requirement Specification for
<Clinic Patient Record System> Page |6

2.4 Operating Environment

CPRS is designed as a web-based application that can be accessed through web


browsers (e.g. Google Chrome & Microsoft Edge). Its GUI is able to adapt to clients
screen resolution, though it is best used with modern resolutions (e.g. XGA, HD 720,
fHD and above). The clients underlying OS should have no impact on the access to the
system given that the system is accessed via web browsers.

We confirmed the system is fully functional when it is accessed via Google


Chrome or Microsoft Edge. Browsers such as Mozilla Firefox that do not support newer
HTML5 form input (e.g. datetime-local) is not supported. Thus, it is advised that the
stakeholders access CPRS through the web browsers listed above.

The web application is run on a localhost web server for testing purposes. On
deployment, we will run the web application on Apache Web Server.

2.5 Design and Implementation Constraints

Design:
Declarative Language/Style Sheet Language: HTML, CSS
Programming Language: JavaScript, Java
Database Server: Oracle Database
Servlet: JSP
Application Server (contains servlet container): Orion Application Server or
Tomcat Apache Server
Web Application: Localhost Web Server for prototyping, Apache Web Server
for deployment

Constraints:
The system must have password authentication. The password is known only
by the administrator and the account owner.
Non-administrator staff should not be able to access administrator menu.
Receptionists must add a doctors schedule into the database first before his
time slot will open up for appointments.
Receptionists can only add appointments if there is available slots.
Doctors must only be able to view their own upcoming appointments and must
not be able to modify them.
On deployment, the web server will be running on LAN.
The web server is to be configured to only cater to devices connected within
the clinics LAN.
Desktop PCs and Laptop PCs that are accessing the system must be using
Google Chrome or Microsoft Edge as browsers and must be connected to the
LAN via Ethernet or Wi-Fi technologies.
Software Requirement Specification for
<Clinic Patient Record System> Page |7

2.6 User Documentation

Customer Support:
We provide an email address that can be used to contact our developer team.

2.7 Assumptions and Dependencies

We assume that the stakeholders have access to Desktop PCs or Laptop PCs.
We assume that the stakeholders have a functional LAN for the web server.
We assume the stakeholders know how to install and use Google Chrome and
Microsoft Edge as their default browser to access CPRS.
We depend on the JDBC API to access Oracle Database.
We depend on the correct implementation of SQL statements in the servlet
pages to deliver the systems functionality.
We depend on Oracle Database and Apache Web Server to be running at 100%
availability with minimal downtime during the workdays.

Software Requirement Specification for
<Clinic Patient Record System> Page |8

3.0 External Interface Requirements


3.1 User Interfaces
3.1.1 Log in Page [Management Staff & Non-Management Staff]
We use login page as a page for the stakeholders to key in their credentials
to access CPRS.

Figure 1 CPRSs login page loaded on Google


Chrome
Software Requirement Specification for
<Clinic Patient Record System> Page |9

3.1.2 Menu [Receptionist vs Doctor vs Administrator]


Different hamburger menu is shown based on the logged in usertype.

Figure 2: Staff, Doctor and Administrator menus


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 10

3.1.3 Add Staff [Administrator]


Only the administrator can register new staff into the system.

Figure 3: Register new staff page

3.1.4 Delete Staff [Administrator]


The administrator can also delete unneeded staff account from the system.

Figure 4: Delete staff page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 11

3.1.5 View Staff


Admins can view all the users registered to the system.

Figure 5: View Staff page

3.1.6 View Appointment [Doctor]


Doctors can view their own upcoming appointments with patients

Figure 6: View Appointment page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 12

3.1.7 View Inventory [Doctor]


Doctors can also view the inventory and check on the prescription stock.

Figure 7: View Inventory page

3.1.8 Create Schedule [Receptionist]


Receptionists can confirm schedules for doctors.
The eligible appointment times are based on this schedule page.

Figure 8: Create Schedule page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 13

3.1.9 Create Appointment [Receptionist]


Receptionists can create appointment for patients.
Maximum appointments per hour is 3 and is colour-coded.
Green : 3 slots available
Yellow : 2 slots available
Orange : 1 slot available
Red : No slot available
Grey = The doctor is not on shift on that day and time.

Figure 9: Create appointment page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 14

3.1.10 Update Patient Appointment [Receptionist]


Receptionist can change appointment status from UPCOMING to WAITING,
COMPLETED or CANCELLED.

Figure 10: Update patient appointment page

3.1.11 Add Patient [Receptionist]


Receptionist can register new patient into the system.

Figure 11: Patient registration page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 15

3.1.12 View Patient [Receptionist]


Receptionist can register new patient into the system.

Figure 12: View Patient page

3.1.13 Create Treatment Record [Receptionist]


Receptionist can create treatment record after treatments are completed.

Figure 13: Create Treatment Record page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 16

3.1.14 Search Individual Patient Record [Receptionist]


Receptionist can search for individual patient record to see the patients
profile and their treatment history.

Figure 14.1: Search Individual Patient Record page

Figure 14.2: Search patient treatment record


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 17

3.1.15 Search Individual Patient Appointment [Receptionist]


Receptionists can search for patient appointments via patient ID.

Figure 15.1: Search Individual Patient Appointment page

Figure 15.2: Search Individual Patient Appointment page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 18

3.1.16 View Inventory [Receptionist]


Receptionist can view all items in the clinic inventory.

Figure 16: View inventory page

3.1.17 Add Inventory [Receptionist]


Receptionists can register new items to the clinics inventory list.

Figure 15: Add inventory page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 19

3.1.18 Update Inventory [Receptionist]


Receptionist can update the quantity of item in the inventory.

Figure 18: Update inventory page

3.1.19 Contact Us [Receptionist / Doctor / Administrator]


The Contact Us page provides the staffs with a mean to contact the system
admin if they encountered any technical problem or glitch.

Figure 20: Contact Us page


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 20

3.2 Hardware Interfaces

CPRS is a web-based application and thus only requires the bare minimum of any
devices that are able to run the aforementioned web browsers.
The device must be located in the same LAN as the web server.

3.3 Software Interfaces

Oracle Database Server


Server that stores the data of the patients, staffs and the patients health
records.
Respond to queries from servlet (.jsp) pages.
Servlet
JSP Servlet is used throughout CPRS.
JSP required compatible web server with a servlet container to run on.
PCs & Laptops Running OS
Both Mac OS X and Windows NT is recommended, other Linux Distros
may also access the web application using web browsers.
Web application are normally cross-platforms so this requirements are
not emphasized.
Web Browsers
Google Chrome and Microsoft Edge is recommended
The use of Mozilla Firefox is highly discouraged due to the lack of support
for certain HTML5 elements.

3.4 Communications Interfaces

For testing purposes, the localhost:8080 are used, 8080 is the application port
number. On deployment, the port number will be changed to 80, which is the
default port number for HTTP applications.
Uses JDBC API on the servlet to connect to the Database Server to create, modify,
delete and retrieve data.
Uses common modern network interface cards or network interface controller
that has TCP/IP chips and uses common Ethernet technologies like IEEE 802
family.
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 21

4.0 System Features


4.1 System Login & Registration

4.1.1 Description & Priority


Prior to using CPRS, the stakeholder must have their own username and
password. Stakeholders without their own login credentials have to contact the
administrator first in order to register an account in the system.

Upon registering the correct input, the user will be redirected to different
menus depending on their usertype (receptionist or doctor or administrator).

On a scale of 1 to 9, this feature is scaled on 9. Any failure in system login and


registration will render the system inoperable.

4.1.2 Stimulus/Response Sequences

Figure 21 Use-case for System Login & Registration

Actors Receptionist, Doctor, Administrator & CPRS


Description An administrator may registers, delete and view staff in CPRS. A
receptionist can register patient. All staffs can login into the system
to access other functionality based on their usertype.
Data Staffs information, patients information, staffs login credentials
(username & password).
Stimulus Registration of new patients or staff.
Staff login into the system.
Response Confirmation that CPRS has been updated with the input data.
Comments The staff must have appropriate credentials to access CPRS
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 22

4.1.3 Functional Requirements


REQ-1: System should be inaccessible by anyone other than the system
stakeholders, which are the clinic staffs.
REQ-2: The administrator must be able to register and delete staffs
REQ-3: The administrator must be able to view the current list of staffs
registered into CPRS
REQ-4: Receptionist must be able to register patient into the system.
REQ-5: Staffs must be able to login into the system with minimal server down
time during workdays.

4.2 Appointments Booking & Management

4.2.1 Description & Priority


CPRS development goals are always to ease the current traditional
implementation of records management and appointments managements system
of small Clinics.

Therefore, appointment booking is crucial feature of the system. This is not


only because to keep track of appointments history and view upcoming
appointments but also a must in creation of records.

Without this feature, patient health records cannot be created due to the
data dependencies. As conclusion, on a scale of 1 to 9, this feature is scaled on 9.

4.2.2 Stimulus/Response Sequences

Figure 22 Use-case for Schedule & Appointment Management


Software Requirement Specification for
<Clinic Patient Record System> P a g e | 23

Actors Receptionist, Doctor & CPRS


Description Receptionists must be able to create, delete and update a doctors
schedule. Based on the schedule, they must be able to book, delete
or update an appointment. They must also be able to view all
appointments. For doctors, they can only view their own upcoming
appointments without being able to do any modification.
Data Staffs id, patients id and information of the appointments (e.g.
dates, status, type, description)
Stimulus Patient book an appointment with the clinic.
Doctor viewing their upcoming appointments.
Response Confirmation that CPRS has been updated with the input data.
CPRS is able to view the appointments details appropriately.
Comments The receptionist must add patient into the CPRS first to create
appointment for them
Receptionist must update the appointment status manually if there
is any changes (e.g. cancellation).

4.2.3 Functional Requirements

REQ-6: The receptionist must be able to book an appointment using the


CPRS when it is needed.
REQ-7: The receptionist must be able to update the appointment status
through CPRSs interface when the appointment is completed, cancelled and
postponed.
REQ-8: The receptionist must be able to view all appointments created in
the CPRS to book new appointment accordingly to avoid appointment
collision.
REQ-9: Doctors must be able to view their UPCOMING appointments with
the patients when it is required.

4.3 Patients Treatment Record Creation & Profile

4.3.1 Description & Priority


Receptionists must be able to add treatment records into CPRS once a
treatment is completed. These records cannot be deleted by either management
staff or non-management staff.

In addition, the records are used to review the patients treatment records
history and consequently can be used as reference in providing better plan in
treating the patients. On a scale of 1-9 this features is also scaled at 9.
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 24

4.3.2 Stimulus/Response Sequences

Create Treament Record

View Patient's Treament History & Profile

Receptionists Clinic Patient Record System


Use Case for System Feature
3: Patient s Treatment &
Profile
Figure 23 Use-case for Patients Treatment & Profile

Actors Receptionist & CPRS


Description Receptionists may create new treatment record. They can also
search and view patients records based on patient ID.
Data Staffs information, patients information, and the details of the
treatment records (e.g. prescription given)
Stimulus Receptionists create new patients treatment record.
Receptionists search and view the patients treatment record.
Response Confirmation that CPRS has been updated with the input data.
CPRS are able to view the healths records appropriately.
Comments The management staff must create patients treatment record once
a treatment is completed.

4.3.3 Functional Requirements

REQ-10: The receptionist must be able to create and add patients health,
vaccine and prescription records after an appointment is completed.
REQ-11: The receptionist must be able to search and view patients
treatment records after its added into CPRS.

4.4 Inventory Management

4.4.1 Description & Priority


Receptionists must be able to add new items into the clinics inventory. They
can also update its quantity if needed. Both doctors and receptionist must be able
to view the inventory

Clinic inventory is crucial to ensure there is sufficient prescription at all time


and to ensure that there is no theft or misuse of authority from the clinics inventory.
On a scale of 1-9 this features is also scaled at 9.
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 25

4.4.2 Stimulus/Response Sequences

Figure 24 Use-case for Inventory Management

Actors Receptionist, Doctor & CPRS


Description Receptionist can add new item and update the quantity of existing
item in clinics inventory. Both doctor and receptionist can view all
items in clinics inventory.
Data Staffs information, inventory information.
Stimulus Receptionist registers new item into the inventory.
Receptionist updates the quantity of item in inventory.
Doctor or receptionist view the inventory.
Response Confirmation that CPRS has been updated with the input data.
Return list of item in inventory to be viewed.
Comments The receptionist must input the correct quantity when updating
inventory
4.4.3 Functional Requirements

REQ-12: The receptionist must be able to add new item into inventory
REQ-13: The receptionist must be able to update quantity of item in
inventory
REQ-14: Both doctor and receptionist must be able to view inventory
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 26

5.0 Other Non-Functional Requirements


5.1 Performance Requirements
The web application must be loaded in less than five seconds in the browser used
by the stakeholders (e.g. Google Chrome & Microsoft Edge).
The web application should not be using too much resource that can cause the
browser to allocate more RAM from the devices.
Any operations done in the CPRS must redirected to response page whether its
error page or successful operation page in less than five seconds of operation.

5.2 Safety Requirements


The patients treatments records must not be able to be deleted from the system
by the staffs.
The records should be permanently stored in the database unless in cases of
emergency.
The only way of registering new staff is to contact the clinics administrator.

5.3 Security Requirements


Outsiders other than the stakeholders and developers team must not access the
CPRS.
Each usertype must only be able to access their own menu.
The staffs can only access CPRS when they have a pair of credentials composed
of STAFF_USERNAME & STAFF_PASS (Staffs Password) which is created by the
administrator.
Login form must use the method = post implementation to avoid form input
data to be viewed on the browsers address bar.

5.4 Software Quality Attribute


Usability: CPRS must provide interfaces that are tailored to ease the workloads
of a Clinic to manage their patients record systems.
Simplicity: CPRS must provide easy-to-use and straightforward UI to be used by
the stakeholders.
Efficiency: CPRS must provide efficient appointment and patient records
management compared to the traditional system.
Transparency: CPRS must provide different functional menu with transparency
to the management staffs and non-management staffs.
Precision: CPRS must precisely invoke every operations from every functions
used by the stakeholders.
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 27

5.5 Business Rules

The stakeholders must have Desktop PCs or Laptop PCs.


The PCs must have a working NIC operating on its hardware.
Web Browser uses must be Microsoft Edge or Google Chrome.
The system defects are accountable if it is stated in the Requirements list.
The management staffs must register the stakeholders before accessing the
CPRS.
The misuse of CPRS such as collecting patients personal data is considered as
privacys invasion and unethical.
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 28

6.0 Other Requirements


Appendix A: Glossary

CPRS : Abbreviation for Clinic Patient Record System


Java Server Pages (JSP) : Technology that helps Software
Developers create dynamically generated web pages based on HTML, XML, or
other document types.
Hypertext Mark-up Language (HTML) : Mark-up language for creating web pages
and web applications.
Cascading Style Sheets (CSS): A style sheet language used for describing the
presentation of a document written in a mark-up language.
JavaScript: a high-level, dynamic, un-typed, and interpreted programming
language.
Oracle Database: An object-relational database management system produced
and marketed by Oracle Corporation.
Java: A general-purpose computer programming language that can be used in
JSP.
IEEE 802 family: A family of IEEE standards dealing with LAN and MAN.
TCP/IP: Conceptual model and set of communication protocols used on the
Internet and computer networks.
Servlet: A program that extends the capabilities of a server.
Web Server: A computer system that processes requests via HTTP application
protocol.
JDBC API: Java Database Connectivity is an application-programming interface
(API) for the programming language of Java, which defines how a client may
access a database.
Application Server: An application server is a software framework that provides
both facilities to create web applications and a server to run them.
Localhost Web Server: Localhost is a hostname that means this computer. Used
to access network services that are running on the host via its loopback network
interface using the loopback address block of 127.0.0.0/8 127.255.255.254/8)
NIC: Network Interface Controller/Card is a computer hardware component that
connects a computer to network.
Ethernet: A family of computer networking technologies commonly used in LAN,
MAN and WAN.
SQL Statement: Structured Query Language Statement thats used to perform
operations regarding Database Server.
HTML5: Improved version of HTML.
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 29

Appendix B: Web Application Architecture

Based from our understanding of how web application works. This diagram
illustrated the web application general architecture. The browser is at the front-end
and localhost web server, Orion application server and oracle database server is at
the back-end.

The browser sends a request to the web server.


Then the web server decides what to do with the request.
If it is static resources like images, CSS files and web pages. It will read
from disk and return directly to the browser.
Else, if the requests is for dynamic resources from CPRS it will forwarded
the request to the Orion Application Server.
Orion Application Server will then passes the request to the correct Web
Application; in this case Clinic Patient Record System.
Then the web application constructs responses from Oracle Database Server and
lastly the response is passed back to the browser.
The browser will display the resources requested.
Software Requirement Specification for
<Clinic Patient Record System> P a g e | 30

Appendix C: To Be Determined List


This To Be Determined (TBD) list serves to collect all currently outstanding decisions,
choices, and unresolved requirements including questions the development team may
need to ask.
Better implementation of staff classification instead of management staff and
non-management staff to a little bit specific.
The conditions of hardware requirements like network devices used in later real
world CPRS deployment.
The plan of CPRSs usages in the hospital to support the scalability of increasing
patients and staffs.
Better implementation of System Feature II: Appointments Booking &
Management.

You might also like