requirement specification version 1...2 revision history name date reason for changes version 1.0...
TRANSCRIPT
Requirement Specification Version 4.0
HEALTH MANAGEMENT SOLUTION
INA BOESECKE, ABDUL-RASHEED OTTUN, SHASWATA SAHA, EMENIKE
HILARY SOMTOCHUKWU
2018
1
Table of Contents
Revision History.......................................................................................................................... 2
1. Introduction.......................................................................................................................... 3
1.1. Purpose........................................................................................................................ 3
1.2. Scope/ System context ................................................................................................ 3
1.3. Definitions, Acronyms, and Abbreviations .................................................................. 4
1.4. References................................................................................................................... 6
1.5. Overview of Document ................................................................................................ 7
2. Overall Description .............................................................................................................. 7
2.1. Product Perspective ........................................................................................................ 7
2.2. Product Functions ........................................................................................................ 9
2.3. User Classes and Characteristics ..............................................................................11
2.4. Constraints ..................................................................................................................13
2.5. Assumptions and Dependencies ................................................................................14
3. Specific Requirements .......................................................................................................14
3.1. Functional Requirements............................................................................................15
3.1.1. Functional requirements for the patient: .................................................................15
3.1.2. Functional requirements for the front-desk/receptionist: ........................................17
3.1.3. Functional requirements for the Doctor/Nurse: ......................................................20
3.2. Non-Functional Requirements....................................................................................20
3.3. Prioritization of the Requirements ..............................................................................23
4. Use Cases ..........................................................................................................................25
5. Description of the Patient Module ......................................................................................29
5.1. Interactions with the patient module ..............................................................................30
5.2. Objects of the Patient Module ........................................................................................30
Appointment............................................................................................................................30
Personal Data...........................................................................................................................31
Account ...................................................................................................................................31
Patient.....................................................................................................................................32
Appendix ....................................................................................................................................33
2
Revision History
Name Date Reason for Changes
Version 1.0 13.10.2018 Initial Version
Version 1.1 23.10.2018 Change request of Raimundas Mateevici’s at 27.10.18
Version 2.0 12.11.2018 In this version we added the non-functional requirements
as well as the Use Case Scenarios. In addition to that we
added dependency models (social and technical) and a
goal modeling.
Version 2.1 16.11.2018 Change request of Jake Tom at 24.11.18.
Version 3.0 02.12.2018 In this version we added more parts of the requirements
modeling for our patient’s module. We defined the
necessary classes with a class diagram, added a state
diagram for the objects of the class diagram and explain
the course of the interactions by a sequence diagram.
Version 3.1 08.12.2018 Change request of Raimundas Mateevici’s at 05.12.18
• Add missing terms to Glossary
• Add missing features to state diagrams
• Add solution-oriented requirements
• Rearrage document for a better overview
o Add section for class and state models
Version 4.0 16.12.2018 Change request of Raimundas Mateevici’s at 12.12.18
• Update traceability model
• Rearrange Patient Module section
3
1. Introduction
The rising demands for health care services and medical consultation have increased the
number of visitations to hospitals, consequently increasing hospital queues, patients waiting
time and patient dissatisfaction.
In view of the realities of increasing demand for quality health care services, it has become
apparent that having some dedicated medical personnel is not just enough to optimally cater
for the growing demand. It is now pertinent that hospital administration is enhanced through
the adoption of technological solutions for better management of health processes and
operations to guarantee quality health care service delivery and operational efficiency.
1.1. Purpose
The purpose of this section is to enumerate the description of the Health Management
solution by detailing information about the context and interface constraints as well as
solution functionality. The document also states the goal to be achieved and the product
scope as well as the functional and non-functional requirements.
This document is the basis for the development of the product as it explains the solutions
designer’s expectations about the user and other infrastructure of that is required by the
solutions. The assumptions and dependencies section highlight any assumptions or
dependencies the application has about the hardware, software, environment and user
interactions associated with it.
1.2. Scope/ System context
The scope of the Health Management Solution includes administrative functions
performed within a medical facility. The aim of the system is to automate the daily
operation of a medical facility. In many institutions, all patient appointments are made by
telephone or directly at the reception desk of the institution. Patient data is stored in
analog files. The new solution is designed for the administration and processing of patient
files and information, appointments, medical history and payment data.
The new system enables doctors to make appointments online, and the practice can
manage the appointments. In addition, information about patients' medical data, medical
history, medical advice and payments is stored. This will allow physicians to spend less
time writing, updating and maintaining records. In addition, online access will allow
patients to check the details as needed.
The scope of the system requirement is that the stakeholders involved understand and
have an idea of how and what will happen in the system. The financial interest of the
4
stakeholders is covered by the cost aspect of the prioritization matrix, the development
interest by the good description of the requirements, as they show what needs to be
implemented, and by the description of the constraints and assumptions. The user
interest of the participants is covered by the description of the actors as well as by the
description of the requirements.
The solution complies with the EU General Data Protection Regulation on the
administration, use, export and storage of data. The software solution is implemented
with MEAN Stack, which includes Angular JS for the frontend, Express.js as middleware,
MongoDB as NoSql database and NodeJS as backend. We use the SCRUM
methodology for the development of the entire system. After each sprint of the
development process we will perform a test phase (manual testing and automated testing
with test tools such as selenium) for each of the new versions of the existing system.
1.3. Definitions, Acronyms, and Abbreviations
This section provides an overview over useful terms and defines them for better
understanding.
Term Definition
Software intensive system System where software plays a pivotal role in
the development, production and deployment
of the system.
Health Management Solution The framework by which the entire the Health
Management operations are done.
Medical facility Facility using the software, can be a hospital
or other facilities needing a software to deal
with the patient’s data
Patient All people coming to the medical facility for
examination
Receptionist/Nurse Person that helps to organize the medical
facility and patients contact
Doctor People examining the patient, they deal with
the patient’s data
Database All the data the software uses is stored in the
database
Module Subpart of the system providing functions for
one of the actors
GUI Graphical User Interface
Web Based Solution Software reachable from the internet
5
Web Browser An application that communicate with the
webserver
Uptime Time in that the software is reachable
Downtime
Time in that the software is not reachable
Server Hardware the system runs on.
Request Signal from the software to the database
Workflow Several actions performed in a row
Pat_X Requirements Id for requirements for the
patient module
Rec_X Requirement Id for requirements for the
receptionist module
Doc_X Requirement Id for requirements for the
doctor module
TX Id for the Tasks of the use case
Web interface The web interface provides the possibility for
the patient to get access to the data.
Invoice A document issued by the doctor’s practice to
the patient that indicates the amount of the
services provider by the doctor.
Permission form A form the patient needs to fill out that his data
is allowed to be used.
Prescription A paper that the patient forwards to the
pharmacy to get his medicaments.
Personal Data Personal information of patient
Password A combination of strings numeric, alphabet or
a combination of both.
credentials Unique user name and password
Data backup A security feature, the data is always stored
twice.
Account A digital record of personal information of
patient detailing bio data, sex, address and
general medical information.
Appointment A confirmed and scheduled consultation with
the doctor.
Use Case Scenario
Non-functional requirement A requirement
6
Functional requirement A requirement that describes a function of the
system.
Solution oriented requirement A requirement that describes a function of the
system and is are elicited from scenarios and
goals.
Class diagram Diagram that describes the classes of the
system and their relations
Sequence diagram Diagram that shows a sequence of
interactions for one actor with the system
State model Shows different states for one object of the
system
based_on Describes a connection between two
Traceability artifacts where the source artifact
is somehow based on the target artifact. E.g.
if a use case scenario gives information for a
functional requirement
satisfies
Schedule A list of appointments
OPD Outpatient department
ER Emergency room
UCX UC = Use Case X = Number of the Use Case
1.4. References
1. video of the doctor visit
2. IEEE template: http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
3. https://www.octalsoftware.com/blog/hims-hospital-management-software-
development-cost-features
4. Information about other systems https://ehealth.intersog.com/blog/medical-software-
types-and-examples
5. Data for prioritization and traceability:
https://drive.google.com/file/d/1MlJ2yMYg0n3ppaUYPtGoyfzrgLUIQSyb/view?usp=
sharing
7
1.5. Overview of Document
This document consists of three sections the Introduction, the Overall Description and the
Specific Requirements.
The Introduction of the documents explains the purpose of this document and improves
the understanding of the rest by providing references and the glossary. The overall
description provides general details about the product. It describes which functions the
product has, the perspective and how parts of the product work together.
The third chapter is a detailed description of the functional requirements and additional use
cases. As well as the prioritization and the traceability of the requirements This is the main
part of the document, as it describes which functionality can be expected from the software.
The Appendix contains further graphics that are important for this document.
2. Overall Description
The purpose of this section is to provide essential description of the product’s perspective
giving information about the context and interface. The product functions section outlines major
functionality the solution will perform. The user characteristics section describes the users and
explains the expectations the solution has about the users. The constraints section contains
detailed descriptions of constraints and safety attributes relating to the solution. The
assumptions and dependencies section summarize the assumptions and dependencies that
have been considered about hardware, software, environment and user interactions
associated with the solution.
2.1. Product Perspective
In the context of the medical facility where operations are manually and digitally executed,
the solution is a completely independent framework that includes four separate and
interrelated modules that allow the medical facility to perform the following functions:
• OPD and consultation management,
• Database management,
• Medical Personal management
• Payment management
8
The solution identifies three groups of users namely: patients, front desk officer/receptionist
and doctors. In addition to that nurses work with the program, but they are performing
functions as the doctor. Figure 1 provides a graphic overview of the different actors.
Each of the user groups works with a dedicated module that models a sequential workflow.
All the three modules are running on a local server of the medical facility and are connected
to the database. The doctor module and the receptionist module are just reachable from
the intranet of the medical facility. Every person working with the system needs personal
credentials to login the system.
The patient’s module can be reached over a web interface from the patient’s device. The
web site for the interface supports the following browsers: Google Chrome, Firefox, Internet
Explorer (IE9, IE10, IE11). Figure 2 shows how the three modules are connected.
Figure 1 This figure provides an overview of the systems actors. The Patient uses the system for the management of the appointments. The doctor uses the system to work with the medical data of a patient. The receptionist and nurse manage patient’s appointments and patient’s data.
9
Figure 2 This figure shows an overview of the system. The system consists of three different modules. All of them are
running on the server of the hospital where in addition the database is located. Two of the modules are reachable
within the intranet of the medical facility. The patient module can be reached from the internet with personal
credentials.
Figure 3: shows the Technical model (actor/stakeholder dependency model) between stakeholders'
relationship and the system and how they depend on each other. It is based on the social model. The circles
represent the actors including the system. The rectangles represent a resource. The hexagon represents a
task. The oval represents a goal. A connection between two actors with the half circle describes a dependency
between two actors. The source of the connection is at the side where the flat part of the half circle is. E.G. The
Doctor depends on the patient concerning GM 11. ‘add new medical data’ as the doctor needs the information
of the patient to add it.
2.2. Product Functions
The solution will perform four core functions for the medical facility. The solution through
the web interface allows the patient to create personal account which enables them to
access the patient module with their unique login details for appointment reservation,
10
appointment rescheduling and cancellation of appointment. The following figure shows the
classes of the patient module for a better understanding of the composition of the module.
Similarly, through the reception module, the front officer/receptionist manages patients’
appointment request, confirms the appointment request, register new patient, assign
patients call for vital sign’s examinations and doctors’ consultation during visit to the
hospital with the solution. Thereby, enabling the receptionist to perform the key OPD and
consultation management task.
In addition to the above, the solution provides the medical facility the capacity to create
and manage medical record upon the visit of patients to the hospital. The process for
creating patient record commences with the receptionist when a patient visits the hospital,
both for existing and new patients, using the receptionist module. When a new patient visits
the hospital, the receptionist log into the system running the solution and registers the data
of the patient. This automatically creates the medical file of the patient upon completion
and stores the data on the server where doctors and nurses can subsequently access the
record during examination of the patient.
Upon completion of consultation with the doctor the before leaving the hospital, the patient
makes a final stop at the front desk station for bills and payment. The generation of patient
bills and invoice for payment will be completely handled suing the receptionist module of
the solution. The receptionist retrieves patient’s record using the billing section of the
receptionist module which provides details and cost of medical services offered to a patient
during the patient’s visit to the hospital.
The doctor module of the solution avails the general medical practitioners and specialist
practitioners to access the medical file of the patient, see investigation result, give drug
prescriptions to patient and add observation result to medical record of patient.
11
The following use case diagram provides an overview over the tasks that the users can
perform with the system.
Figure 4: The main users of the program are the doctor, the patients and the receptionist of the medical facility. The diagram provides an overview over the tasks (presented in the white ovals) the actors want to perform. The Doctor mainly performs tasks that are connected to the medical data of the patient. The Patient and the receptionist are performing tasks that have to do with the management of the patient’s data and the patient's appointments. If an actor is connected to a task it means that he wants to perform this task with the system. The dotted arrow with the description <<extends>> means that the source task is extending the target task .
2.3. User Classes and Characteristics
For the software three main user classes exist:
o Patient: Patients are all people that must see the doctor.
A patient can have different backgrounds.
▪ People who are familiar with internet applications.
▪ People with less experiments with internet applications or web pages or
without the possibility to use an online application.
o Receptionist/Nurse: The receptionist/nurse is the person who is organizing the
appointments and talks first to the patients if they arrive in the hospital
▪ Has small technical knowledge
▪ Is used to work with software in the field of medical practices
o Doctor: In context of the software Doctor and Nurses are treated as one Actor,
as they both must be able to deal with the patient’s data
▪ Have small technical knowledge
▪ Are used to work with software organizing the patient’s data
The three user groups have different interests while working with the system:
12
o Patient:
▪ Wants to manage his/her account
▪ wants to organize his/her appointments (make/reschedule/delete an
appointment)
▪ wants to see and change his/her personal data
o Receptionist:
▪ wants to manage patient appointments (make/reschedule/delete an
appointment, list all appointments)
▪ wants to manage patient’s data (add/change)
• wants to confirm id of a patient
▪ wants to manage patient’s payments
o Doctor:
▪ wants to work with the patient data:
• wants to get detailed information about the patient’s medical
history
• wants to add new medical data to it
• wants to be able to create a prescription for a patient
The following figures are shown to provide a better overview of the actors, their dependencies
on each other and their possible interactions with the system.
13
Figure 5: shows the Social model (actor/stakeholder dependency model) between stakeholders' relationship and
how they depend on each other. The circles represent an actor. The rectangles represent a resource. The
hexagon represents a task. The oval represents a goal. A connection between two actors with the half circle
describes a dependency between two actors. The source of the connection is at the side where the flat part of the
half circle is. E.G. The Doctor depends on the patient concerning GM 11. ‘add new medical data’ as the doctor
needs the information of the patient to add it.
2.4. Constraints
The solution requires fully functional internet network connection and 24-hour server
uptime for optimal functionality. The occurrence of loss of internet connection or server
downtime during an active session of the any of the user, will result to the display of an
error message like “temporarily lost network connection” or “Server not found” depending
14
on the occurrence. Users will need to perform task again when any of these occurrences
is experienced upon resumption of internet network connectivity and server
2.5. Assumptions and Dependencies
During the development of the software we assume that the medical facility using the
software uses computer hardware with a windows operating system. The system must be
windows 10. The medical facility must have two servers for the data, with the capability to
store all the data. One of the severs is used for the data backup. The medical facility must
have a domain, that can be used for the web interface of the patient module. This web
interface must have the rights to access the database of the medical facility. For the web
interface used by patient has a work station with internet connection.
Figure 6: KAOS model relating to the sub goal, Book Appointment (GM4), of the Health Management System.
The model shows booking appointment as a part of the refined and sub goal of visit the doc tor, several
operations to be performed and the automated component to be responsib le for realizing the sub goal. The
parallelograms in the model represent goals, both parental (main) and sub goals. The yellow circles in the
models are symbols depicting the refinement of parental goals into sub goals, while the polygon represents the
agent responsib le for the goals. The arrows show the linkage between the goal and how the goal will be
achieved. A detailed description of the goals can be found in the Appendix (Goal Modeling)
3. Specific Requirements
This section provides an overview of the requirements. The requirements are ordered by the
different actors.
15
3.1. Functional Requirements
Our main source for the functional requirements of the software is a presentation of the
domain topic (1). The prioritization attribute is determined by the prioritization plot in section
3.2. The values are based on a discussion with a domain expert. The traceability
information for the requirements can be found in the appendix. Mandatory requirements
are marked with (*), requirements that should not be implemented are marked with (-).
(At the moment this document does not contain any should not be requirements).
3.1.1. Functional requirements for the patient:
Requirement ID Description
Pat_1 (*) The patient must be able to create an online account.
Prioritization: 1
Traceability:
• Based_on (UC1)
• Based_on (UC2)
Version: Pat_01_V.3.1
Pat_2 (*) The patient must be able to log in to his account.
Prioritization: 2
Traceability:
• based_on (UC1)
• based_on (UC2)
Version: Pat_02_V.3.1
Pat_3 (*) The patient must be able to see the appointment information online.
Prioritization: 4
Traceability:
• Based_on (UC1)
Version: Pat_03_V.2.0
Pat_4 The patient must be able to make an appointment.
Prioritization: 7
Traceability:
• based on (UC 1)
Version: Pat_04_V.2.0
Pat_5 The patient must be able to cancel an appointment.
Prioritization: 5
Traceability:
Version: Pat_05_ V.2.0
Pat_6 The patient must be able to reschedule an appointment.
Prioritization: 6
Traceability:
Version: Pat_06_V.2.0
16
Pat_7 The patient must be able to confirm an appointment online.
Prioritization: 3
Traceability:
Version: Pat_07_V.1.1
Pat_8 The patient must be able to add doctor to appointment.
Prioritization: 8
Traceability:
Version: Pat_07_V.1.1
Pat_9 The patient must be able to change his personal data.
Prioritization: 9
Traceability:
➢ satisfies (UC2)
Version: Pat_08_ V.2.0 Pat_10 The patient must be able to see his personal data (personal data
includes information about medication).
Prioritization:
Traceability:
➢ satisfies (UC2)
Version: Pat_09_ V.2.0
Pat_11 The patient must be able to delete values in his personal data.
Prioritization:
Traceability:
➢ Based_on (Figure 10)
Version: Pat_11_ V.3.1
Pat_12 The patient must be able to register for a new account.
Prioritization:
Traceability:
➢ Based_on (Figure 10)
➢ Based_on (Figure 11)
➢ Based_on (Figure 14)
Version: Pat_12_ V.3.1
Pat_13 The patient must be able to log out from the account.
Prioritization:
Traceability:
➢ Based_on (Figure 10)
➢ Based_on (Figure 11)
➢ Based_on (Figure 14)
Version: Pat_13_ V.3.1
Pat_14 The patient must be able to delete his account.
Prioritization:
17
Traceability:
➢ Based_on (Figure 10)
➢ Based_on (Figure 11)
➢ Based_on (Figure 14)
Version: Pat_14_ V.3.1
Pat_15 The patient must be able to change the password of the account.
Prioritization:
Traceability:
➢ Based_on (Figure 10)
➢ Based_on (Figure 14)
Version: Pat_15_ V.3.1
Pat_16 The patient must be able to pay for the doctor visits.
Prioritization:
Traceability:
➢ Based_on (Figure 10)
Version: Pat_16_ V.3.1
Pat_17 The patient must be able to create a new entry in the personal data.
Prioritization:
Traceability:
➢ Based_on (Figure 10)
➢ Based_on (Figure 11)
➢ Based_on (Figure 13)
Version: Pat_17_ V.3.1
Pat_18 The patient must be able to delete his/her entry of the personal data.
Prioritization:
Traceability:
➢ Based_on (Figure 10)
➢ Based_on (Figure 11)
➢ Based_on (Figure 13)
Version: Pat_18_ V.3.1
3.1.2. Functional requirements for the front-desk/receptionist:
Requirement ID Description
Rec_1 (*) The receptionist must be able to log in to the system.
Prioritization: 1
Traceability:
➢ Based_on (UC1)
➢ Based_on (UC2)
➢ Based_on (UC3)
18
➢ Based_on (UC4)
Version: Rec_01_V.2.0
Rec_2 The receptionist must be able to confirm an appointment.
Prioritization: 9
Traceability:
➢ Based_on (UC 3)
Version: Rec_02_V.3.1
Rec_3 (*) The receptionist must be able to see a list of the appointments of one
day.
Prioritization: 8
Traceability:
➢ satisfies (UC4)
➢ based on (U1)
➢ based on (U3)
Version: Rec_03_V.2.0
Rec_4 (*) The receptionist must be able to add an appointment.
Prioritization: 12
Traceability:
➢ satisfies (UC1)
➢ satisfies (UC2)
Version: Rec_04_V.2.0
Rec_5 (*) The receptionist must be able to cancel an appointment.
Prioritization: 11
Traceability:
➢ satisfies (UC3)
Version: Rec_05_V.2.0
Rec_6 (*) The receptionist must be able to change an appointment.
Prioritization: 13
Traceability:
➢ satisfies (UC3)
Version: Rec_06_ V.2.0
Rec_7 (*) The receptionist must be able to register the data of a new patient .
Prioritization: 2
Traceability:
Version: Rec_07_ V.1.1
Rec_8 The receptionist must be able to confirm the identity of a patient.
Prioritization: 6
Traceability:
Version: Rec_08_ V.2.0
Rec_9 The receptionist must be able to change the data of an existing patient .
19
Prioritization: 3
Traceability:
Version: Rec_09_ V.2.0
Rec_10 The receptionist must be able to see the data of a patient.
Prioritization: 4
Traceability:
Version: Rec_10_V.1.1
Rec_11 The receptionist must be able to confirm the payment of a patient .
Prioritization: 5
Traceability:
Version: Rec_11_ V.2.0
Rec_12 The receptionist must be able to create an invoice for the patient’s
payment.
Prioritization: 7
Traceability:
Version: Rec_12_ V.2.0
Rec_13 The receptionist must be able to confirm, that the patient signed the
permission form.
Prioritization: 10
Traceability:
Version: Rec_13_V.2.0
Rec_14 Front-Desk/Receptionist must be able to manage the payment made by
the patient and the pending bills.
Prioritization: 14
Traceability:
Version: Rec_14_V.3.1
Rec_15 Front-desk/Receptionist must be able to add DoctorID to an
appointment.
Prioritization:
Traceability:
➢ Based_on (Figure 10)
Version: Rec_15_V.3.1
Rec_16 Front-desk/Receptionist must be able to confirm a new patient.
Prioritization:
Traceability: Figure-5.1
➢ Based_on (Figure 10)
Version: Rec_16_V.3.1
Rec_17 Front-desk/Receptionist must be able to confirm the payment for an
appointment.
Prioritization:
20
Traceability:
➢ Based_on (Figure 10)
Version: Rec_17_V.3.1
3.1.3. Functional requirements for the Doctor/Nurse:
Requirement ID Description
Doc_1 (*) Doctor must be able to see the medical data of the patient. The medical
data includes previous examinations and prescriptions.
Prioritization: 1
Traceability:
Version: Doc_01_V.1.1
Doc_2 (*) Doctor must be able to add medical data to the patient’s entry .
Prioritization: 4
Traceability:
Version: Doc_02_V.1.1
Doc_3 Doctor must be able to create the prescription for a patient.
Prioritization: 2
Traceability:
Version: Doc_03_V.1.1
Doc_4 Doctor must be able to print the prescription for a patient.
Prioritization: 3
Traceability:
Version: Doc_04_V.1.1
3.2. Non-Functional Requirements
ID Category Description Properties
NFR_1 Efficiency • The system at the Front desk/receptionist should give responses in 2 seconds after checking the patient's information.
• The system must handle 100 payment transactions per second in peak load.
• The Information System must support 1000 people at the same time.
• Time taken should be minimal for simple report preparation in most of the cases.
• Navigation through one page up or down in a 100-page document shall take at most 1s. Searching the page for a specific keyword shall take at most 5s.
Priority: High Version: NFR_01_V.1.1
Traceability: Rec_10
21
NFR_2 Security • Login the system: Patient using the system must have an email and password. In case of forgotten password/email, a security question and reference email option will be provided during Registering in the system.
• Unauthorized entry in information system will be blocked by Firewall and secured with encryption. An email and mobile notification will be sent when the user logs in the system except when the user is an administrator.
Priority: High Version: NFR_02_V.1.1
Traceability: ➢ Rec_1 ➢ Pat_2
NFR_3 Availability • The downtime of the information system must be less than 10 hours in a week.
• The information system needs to be available >90 percentage during peak hours.
Priority: High Version: NFR_03_V.1.1
Traceability: ➢ Rec_1 ➢ Pat_1 ➢ Pat_2
NFR_4 Survivability • All the data in the database of the information system must be backed in cloud to avoid loss of patients’ data during any major crash to the system.
Priority: High Version: NFR_04_V.1.1
Traceability: ➢ Rec_4 ➢ Doc_3 ➢ Pat_4
NFR_5 Reliability • Software Framework of the Information System shall be robust, bug free satisfying all the requisite requirements and provide good overall user experience.
• The accuracy of the system shall be high.
• Probability of unavailability shall be less than 0.5
• Probability of failure shall be less than 0.5
• Mean-time-to-failure shall be high
Priority: High Version: NFR_05_V.1.1
Traceability: ➢ Doc_4
NFR_6 Maintainability • The Information System must keep log of all the errors occurred and can be easily maintained by the Engineer.
• The cost of maintaining the system shall be low.
• Development of the system shall use regression testing allowing full re-testing in 12 hours
Priority: Medium Version: NFR_06_V.1.1
Traceability: ➢ Doc_2
➢ Rec_5 ➢ Pat_7 ➢ Doc_2
NFR_7 Operability • The Information System can be operated with intermediate computer skill level.
• The Information System can operate in browsers such Microsoft Edge, Google Chrome and Mozilla Firefox.
• Operating System -Window XP, Window vista, Window 7 or higher window version, Linux, macOS.
Priority: Medium Version: NFR_07_V.1.1
Traceability:
➢ Pat_9 ➢ Doc_4 ➢ Rec_11
22
• Database-Microsoft SQL Server Management studio
• User Interface Design-C# 3.0 Data Report Visual studio 2010
• The Information System can be maintained easily by Engineer.
➢ Rec_8
NFR_8 Usability • Training time for using the system shall be minimal. It needs to be less than 1 month.
• Help frames shall be provided for the ease of the user to operate the system.
• New Users can easily perform tasks in the system in a shorter time span
• Experienced User can perform tasks in the system in < 2minutes
Priority: Medium Version: NFR_08_V.1.1
Traceability: ➢ Pat_7
NFR_9 Robustness • Time to restart after failure shall be less than 2 hours.
• Percentage of events causing failure shall be less than 50 %
Priority: High Version: NFR_09_V.1.1
Traceability: ➢ Doc_1
NFR_10 Speed • Payment Transactions/sec shall be > 100
• Response time screen shall be < 2 seconds • Refresh time shall be < 5 seconds
Priority: Medium Version: NFR_10_V.1.1
Traceability: ➢ Rec_11 ➢ Doc_3
NFR_11 Portability • Percentage of target-dependent statements shall be > 50
• Number of target systems shall be high
Priority: Medium Version: NFR_11_V.1.1
Traceability: ➢ Rec_12
NFR_12 Complexity • Information flow between modules shall be fast
• Count procedure calls shall be minimal
Priority: Medium Version: NFR_12_V.1.1
Traceability: ➢ Rec_6
NFR_13 Testability • The system shall be easily tested during
maintenance by Engineer • The system shall be easily tested in case of a
failure
Priority: High Version: NFR_13_V.1.1
Traceability: ➢ Rec_5 ➢ Rec_4
NFR_14 Understandability
• Time taken by a new user to understand the system shall be less than 1 week
Priority: Medium Version: NFR_14_V.1.1
Traceability: ➢ Pat_3
23
NFR_15 Accessibility • The system must function according to the Microsoft/Firefox/Google Chrome Accessibility
Priority: Medium Version: NFR_15_V.1.1
Traceability: ➢ Pat_2
3.3. Prioritization of the Requirements
This section provides the prioritization of the requirements. The diagram compares all
requirements for one actor in the categories cost and value. The values were developed in
coordination with domain experts. The data matrix fot both values can be found in the appendix.
Based on the plots the prioritization attribute can be determined.
Figure 7 Shows the plot of cost and value related to the requirements of the doctor function.
24
Figure 8: Shows the plot of cost and value related to the requirements of the receptionist function.
Figure 9: Shows the plot of cost and value related to the requirements of the patient function.
25
4. Use Cases Used Case ID UC 1
Use Case Name Appointment Reservation
Created By Doctor Team 3 Last Updated By:
Date Created 10-Nov-2018 Date Last Updated
Actors Patient, Receptionist/Nurses, Health Management System Patient and Reception Modules and Server
Description Appointments Reservation for the consultation of doctor
Trigger Notification of reservation(scheduling) of appointment by patient
Preconditions - The Health Management System must be accessible online. - Server and communication medium must be active.
Post conditions The patient can consult the doctor in line with patient's scheduled reservation for consultation.
Normal Flow Patient makes a call/walks in/sends an email for an appointment with the doctor. 1. The receptionist logs into the reception module to check availability of appointment. 2. The receptionist confirms appoint to the patient. 3. The receptionist creates and reserves the appointment as requested 4. The receptionist saves the appointment Patient makes online reservation or appointment through the patient module - Patient performs the following steps: 1. The patient visits the web portal 2. Select the patient module of the web portal 3. Log in to account with details. 4. Checks doctors' consultation schedule 5. Reserves appointment for doctors' consultation through the module.
Alternative Flows - Doctors makes appointment reservation for patient for proper follow-up. - Doctors confirm patients' appointment for follow-up consultation.
Exceptions Server Error: Inability to save due to server down time
Includes Change and cancellation of reservation by patient
Priority Importance for system success: High Technological risk: Medium
Frequency of use Daily Basis
Business Rules This use case is in line with the provisions of the following policy and regulations: Hospital policy on Out-patient Department data management procedure. EU General Data Privacy Regulation. Health Data Management Regulation Health Data Governance
Special Requirements
Appointment reservation and confirmation must be completed within two (2) steps by actors involved
Assumptions It is assumed required level of skills and infrastructures are available for the optimal use of the health management system
Notes and Issues This use case is a work in progress and could be subject to further reviews
26
Used Case ID UC 2
Use Case Name
Patient Data Management
Created By Doctor Team 3 Last Updated By:
Date Created 10-Nov-2018 Date Last Updated
Actors Patient and Health Management System Patient Module
Description The patient updates his/her data online using the patient module
Trigger The patient wishes to perform changes to personal data with the hospital
Preconditions - The Health Management System must be accessible online. - Patient must have an existing account
Post conditions
Patient successful update of personal data
Normal Flow 1.The patient logs on to the system 2.The patient inserts the changed personal data 3.The patient saves the changed data
Alternative Flows
The Health Management System's web portal automatic prompt and update of patients' personal data based on data stored in patients' web browsers
Exceptions Server Error: Inability to save due to server down time
Includes 1. Name Update 2. Address update 3. Sex 4. Family health details
Priority Importance for system success: High Technological risk: High
Frequency of use
Need basis
Business Rules
This use case is in line with the provisions of the following policy and regulations: Hospital policy on Out-patient Department data management procedure. EU General Data Privacy Regulation. Health Data Management Regulation Health Data Governance
Special Requirements
Personal Data update must be completed in one (1) steps by actors involved
Assumptions It is assumed required level of skills and infrastructures are available for the optimal use of the health management system
Notes and Issues
This use case is a work in progress and could be subject to further reviews
27
Used Case ID UC 3
Use Case Name
Management of Patient Appointment
Created By Doctor Team 3 Last Updated By:
Date Created 10-Nov-2018 Date Last Updated
Actors Receptionist, Health Management System Reception Modules and Server
Description Receptionist/Nurses process reservation, schedule, reschedule, change or cancel patients' appointment.
Trigger Receptionist/Nurses receives patients' reservation request online or via email or phone call
Preconditions - The Health Management System must be accessible online. '- Receptionist/Nurses must be logged into module
Post conditions
Send confirmation of appointment to patient
Normal Flow 1.Reception/Nurses receives request for reservation of appointment 2. Reception/Nurses sear for an empty time slot based on the request received. 3. Receptionist/Nurses offers an empty slot to the patient for the appointment to the doctor. 4. Receptionist selects the available time slot from the database in the computer and adds the patient to it. 5. Receptionist/Nurse selects the available time slot from the database in the computer and adds the patient to it 6. Receptionist/Nurse confirms that the time slot is booked for the patient
Alternative Flows
Exceptions - Server Error: Inability to save due to server down time - Internet Network Downtime
Includes 1. Consultation date and time change 2. Rescheduling of appointment 2.Appointment and reservation cancellation
Priority Importance for system success: High Technological risk: High
Frequency of use
Daily basis
Business Use This use case is in line with the provisions of the following policy and regulations: Hospital policy on Out-patient Department reservation and consultation management procedure. EU General Data Privacy Regulation. Health Data Management Regulation Health Data Governance
Special Requirements
Reservation confirmation must be completed within two (2) steps by actors involved
Assumptions It is assumed required level of skills and infrastructures are available for the optimal use of the health management system
Notes and Issues
This use case is a work in progress and could be subject to further reviews
28
Used Case ID UC 4
Use Case Name
Organization and scheduling of doctors' consultation of patient
Created By Doctor Team 3 Last Updated By:
Date Created 10-Nov-2018 Date Last Updated
Actors Receptionist/Nurses
Description Receptionist/Nurses use the receptionist module to organize and schedule daily consultations of doctors.
Trigger Notification from the calendar / task manager on the visitation of patient for medical consultation
Preconditions - Health Management System must be running - Receptionist/Nurses must be logged into the reception module
Post conditions
Patient consult doctor according to confirmed reservation for consultation of doctor
Normal Flow 1. A patient comes to the hospital for his appointment 2. The receptionist views the appointment queue for the day on the reception module and checks the patient’s appointment 3. The receptionist confirms doctor’s availability 4. The receptionist/nurses transfer patient file to nurses in charge of vital signs and general checkup. 5. Nurses transfer patients' file and observations to doctor 6. Nurses call for patient to consult the doctor at the doctors' office
Alternative Flows
Exceptions Absence of Patient without notification
Includes
Priority Importance for system success: High Technological risk: High
Frequency of use
Daily basis
Business Use This use case is in line with the provisions of the following policy and regulations: Hospital policy on Out-patient Department reservation and consultation management procedure. EU General Data Privacy Regulation. Health Data Management Regulation Health Data Governance
Special Requirements
Reservation confirmation must be completed within two (2) steps by actors involved
Assumptions It is assumed required level of skills and infrastructures are available for the optimal use of the health management system
Notes and Issues
This use case is a work in progress and could be subject to further reviews
29
5. Description of the Patient Module In this section we are providing additional information about how the patient Module should be
organized.
With the help of class diagrams, sequence diagrams and state models the organization and the
interaction with the module can be seen.
The patient module is the part the patient can interact with. The classes are extracted of the
requirements of the patient. After that the model was updated with missing methods. That missing
information was added to the requirements of the patient and the receptionist. Based on the
traceability attribute they can be found. Each class contains attributes and methods that provide the
probability to change those attributes
The class diagram shows a possibility to model the different objects of the patient module. Each
patient has one entry for the personal data with the given attributes (shown in the upper part of the
Personal Data object). With the entry for the personal data the patient can perform the outlined
methods (shown in the lower part of the Personal Data object). In addition to that the module should
have the objects Appointment, Account and Patient. Each with the outlined attributes and methods.
Figure 10: Class diagram for the patient module
30
5.1. Interactions with the patient module The sequence diagram outlines the interactions of the actor patient with the other classes of the
patient module.
5.2. Objects of the Patient Module The state models help to understand the different states and interactions with objects and their
attributes that are part of the patient module.
Appointment
This diagram shows the possible states and the changes for the object appointment. The methods
written on the arrows are the methods that can be performed by the user Patient. Each state
describes a combination of the attributes changed and confirmed.
Figure 11 Sequence Diagram. Here the interaction between the actor patient and the classes of the patient module can be seen.
31
Figure 12: State Model for the Object Appointment
Personal Data This diagram shows the possible states and the changes for the object personal data. The methods
are the methods that can be performed by the user Patient. Each method changes the state of the
attributes of the personal data object. E.g. in the empty state all attributes are empty
Figure 13. State model for the object Personal Data
Account
This figure shows the possible states and changes of the states of the object Patient. The methods
are the methods that can be performed by the user Patient. The first method is register where the
patient registers for a ‘New Account’. This state leads to the state of ‘Personal Data’ where the
patient fills the personal data. This is the end state. From the state ‘New Account’, the patient uses
the method createAppointment() to enter the state ‘Appointment’ which is also the end state
32
Figure 14 State model for the Object Account
Patient This figure shows the possible states and changes of the states of the object Patient. The methods on
the arrays are methods that can be performed by the actor patient and by the actor receptionist in
case of the confirm or the delete method. Each method changes the state of the account object.
Figure 15 : State model for the Object Patient
33
Appendix
Cost and value matrixes
Figure App_1: Cost comparison for the requirements of the user doctor
Figure App_2 : Cost comparison for the requirements of the user patient.
Figure App_3 : Cost comparison for the requirements of the user receptionist.
Figure App_4:: Value comparison for the user doctor
34
Figure App_5: Value comparison for the user patient
Figure App_6: Value comparison for the user receptionist
Traceability
Figure Appendix_7: Traceability Matrix for the actor patient
35
Figure App_8: Traceability Matrix for the actor Receptionist
Use Case
NFR_1
NFR_2
NFR_3
NFR_4
NFR_5
NFR_6
NFR_7
NFR_8
NFR_9
NFR_10
NFR_11
NFR_12
NFR_13
NFR_14
NFR_15
UC 1
Based_on
satisfies
Based_on
Based_on
Based_on
Based_on
Based_on
satisfies
UC 2
Based_on
satisfies
Based_on
Based_on
Based_on
Based_on
Based_on
satisfies
UC 3
Based_on
satisfies
Based_on
Based_on
Based_on
Based_on
Based_on
satisfies
UC 4
Based_on
satisfies
Based_on
Based_on
Based_on
Based_on
Based_on
satisfies
Figure App_9: Traceability Matrix for the Non-Functional Requirements
Figure App_10: The traceability model shows the rules for the connection of our traceability artifacts. We have two different types of connection. Based on means one artifact is somehow based on another artifact. E.G. if one Requirement is based on a use case scenario, this scenario shows that this requirement is needed. If one requirement satisfies a use case scenario, a
requirement makes is possible that the whole use case can be handled by the program.
36
Goal Modelling
ID Goal Type Name Description Agent
GM_1 Hard Goal Appointment Reservation
Appointments Reservation for the consultation of doctor
Patient, Receptionist/Nurses, Health Management System Patient and Reception Modules and Server
GM_2 Soft Goal Patient Data Management
The patient updates his/her data online using the patient module
Patient and Health Management System Patient Module
GM_3 Soft Goal Management of Patient Appointment
Receptionist/Nurses process reservation, schedule, reschedule, change or cancel patients' appointment.
Receptionist, Health Management System Reception Modules and Server
GM_4 Soft Goal Organization and scheduling of doctors' consultation of patient
Receptionist/Nurses use the receptionist module to organize and schedule daily consultations of doctors.
Receptionist/Nurses
Goal description
ID Content
GM1 visit the doctor GM2 Get data
GM3 Manage data GM4 Manage appointment
GM5 Confirm appointment GM6 Provide appointment dates
GM7 Check doctor schedule
GM8 Payment invoice GM9 Make payment
GM10 Provide new medical details GM11 Add new medical data
GM12 Get prescription GM13 Give prescription
GM14 Get prescription history
GM15 Get medical report
37
GM16 Provide schedule
GM17 Add medical data GM18 Display appointment
GM19 Check appointment GM20 Check schedule
GM21 Provide invoice
GM22 Show/view appointment GM23 Manage appointment
GM24 Manage patient data GM25 Walk-in (face-to-face)
GM26 Phone call GM27 Email
GM28 Web portal
GM29 Visit hospital reception GM30 contact reception by phone
GM31 send reservation mail GM32 Process request
GM33 Doctor consultation portal GM34 Portal reservation page
GM35 user portal calendar
GM36 send confirmation mail from portal GM37 consultation/appointment system