38
Requirement Specification Version 4.0 HEALTH MANAGEMENT SOLUTION INA BOESECKE, ABDUL-RASHEED OTTUN, SHASWATA SAHA, EMENIKE HILARY SOMTOCHUKWU 2018

Requirement Specification Version 1...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

  • Upload
    others

  • View
    9

  • Download
    0

Embed Size (px)

Citation preview

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