Post on 21-Apr-2020
transcript
TU/e 1BV10 Business Requirements Document (BRD)
E
Business Requirements Document (BRD)
This document is based on a template from Noble Inc. adapted from Appendix B of UML for the IT Business Analyst, 2nd edition (cengage, 2009) by Howard Podeswa, Director of Program Development for Noble Inc.
The template has also been adapted to fit the needs of Course 1BV10 “Design of Business Information Systems” at the Eindhoven University of Technology. For the sake of clarity, some parts were removed, others have been added, and some were rephrased.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Business Requirements Document (BRD) Project No.: 2
Production Priority: 1
Target Date: 12 June 2018
Approved by:
Dr. Maryam Razavian, IE&IS
Dr. Baris Ozkan, IE&IS
Dr. Estefanía Serral, IE&IS
Prepared by:
Jeroen de Croock 0965312
R.A.J van der Heijden 1015833
M.P.J. van der Vleuten 1019095
S.G.J. Bekkers 0950370
E.M. van der Pas 0947716
A.H. van de Velde 0995745
Filename: D2_group2.pdf
Version No.: 2.46
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
1.1
Table of Contents 1 Change Log 4
2 Executive Summary 5
2.1 Background 5
2.2 Objectives 5
2.3 Requirements 5
3 Scope 6
3.1 Use-Case Diagram 7
3.2 Actor Descriptions 8
4 Use Case Descriptions 8
5 Test Case Descriptions 11
6 Conceptual Data Model 14
Appendix A: Conceptual Data Model 16
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
1 Change Log
Name Time Subject Description
whole group 15-05-2018 3.1 use case diagram made 1st version
Roel & Martijn 22-05-2018 3.1 use case diagram made 2nd version
Roel & Martijn 22-05-2018 3.2 actor description made 1st version
Roel & Martijn 23-05-2018 4 use-case descriptions made 1st version
Roel & Martijn 23-05-2018 3.1 use case diagram made 3rd version
Amber & Jeroen 18-05-2018 5. test cases made 1st version
Amber & Jeroen 21-05-2018 5. test cases made 2nd version
Amber & Jeroen 25-05-2018 5. test cases made 3rd version
Amber & Jeroen 22-05-2018 2.1 background made 1st version
Amber & Jeroen 22-05-2018 2.2 objectives made 1st version
Amber & Jeroen 22-05-2018 2.3 requirements made 1st version
Amber & Jeroen 24-05-2018 2. Executive summary made 2nd version
Sjoerd & Eef 18-05-2018 6. Conceptual model made 1st version
Sjoerd & Eef 22-05-2018 6. Conceptual model made 2nd version + assumptions
Sjoerd & Eef 24-05-2018 6. Conceptual model
Completed 2nd version + assumptions + multiplicities checked
whole group 30-05-2018 7. screen flow diagram made 1st version
Roel 06-06-2018 7. screen flow diagram Made 2nd version
Martijn & Roel 07-06-2018 3.1 use case diagram Made 4th version
Martijn & Roel 07-06-2018 3.2 actor description Made 2nd version
Martijn & Roel 07-06-2018 4 use case descriptions made 2nd version
Sjoerd & Eef 04-06-2018 consultation Stand-up meeting + planning
Sjoerd & Eef & Amber 05-06-2018 8.1 Domain model
translation of conceptual model into domain model
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Sjoerd & Eef 06-06-2018 8. Mendix app made the pages with microflows
Sjoerd 06-06-2018 8. Mendix app security
Eef 07-06-2018 8. Mendix app
page and association patient_treatment_treatmentplan_activitytypes
Sjoerd&Eef 08-06-2018 8.Mendix app Finalization of the app pages, microflow, layout
Sjoerd 08-06-2018 8.Mendix app
Implemented the different coordinators with different homepages and updated securty settings
Amber & Jeroen 04-06-2018 2. Executive summary
Processing feedback, made 3rd version
Roel 10-06-2018 7. screen flow diagram made 3rd version screen flow administrative worker
Jeroen 10-06-2018 1. Mendix showcase First and second showcase
Amber 09-06-2018 8.1 Domain model Made 1st version
Jeroen 11-06 7. Mendix showcase Third showcase
Amber 10-06-2018 8.1 Domain model Made 2nd version
Jeroen 07-06-2018 5. Test cases Test cases adjusted by given feedback
Amber 05-06-2018 6. Conceptual data model
Processing feedback, made 3rd version
Jeroen 05-06-2018 All Mid-project spell and syntax check
Amber & Jeroen 11-06-2018 8.1 Domain model Made 3rd version
Sjoerd & Eef 11-06-2018 8. Mendix app Final changes and layout
Sjoerd & Eef & Amber 12-06-2018 8.1 Domain model Made 4th version
Martijn 12-06-2018 8.2 securities Made 1st version
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
2 Executive Summary
2.1 Background
The implementation of a new information system is being considered by Stichting Geestelijke Gezondheidszorg Eindhoven en de Kempen (GGzE) to cut down on cost. This is because of a decrease in public funding and to challenge increasing competition. GGzE currently has multiple paper based procedures for multiple uses. One of these is for instance the treatment plan of a patient. A solution for this problem will be an Electronic Patient Dossier (EPD) that is able to be expanded with regards to future subsystems.
For this project we have a several stakeholders. These include the board of Stichting Geestelijke Gezondheidszorg Eindhoven en de Kempen, patients, doctors and physicians. In this case we can question the involvement of the patient itself since they are not a user of the system. However, it is their information that is stored within the system. They can’t have a proposition about the user interface, but can remark the system’s privacy regulations for instance. The board of GGzE are high-level stakeholders and need to approve the system as a whole before it can be implemented. The doctors and physician are users of the information system. A stakeholder that doesn’t have a direct influence on the system are the insurance companies. However, if the final system won’t be functioning correctly, the insurance companies can also financially suffer.
2.2 Objectives The goal of this new information system is to handle patient’s data electronically. The new system should include all current processes to improve the managing of patients’ files. By making sure that the level of quality and efficiency increases, the services to patients of the GGzE will also ameliorate. The system will provide substantial profits within a 3 year horizon and the costs of implementing and designing the system will be recouped within 2 years.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
2.3 Requirements
The following requirements will be implemented in the system:
Functional:
- The coordinator is able to see and register the results of a screening via the information
system
- The coordinator is able to assign a patient to a doctor via the information system
- The doctor is able to see a list of patients assigned to them via the information system
- The doctor is able to define and update a treatment plan as well as the outcome of
activities via the information system
- The doctor is able to flag overall treatment outcomes in the system via the information
system
- The information system should support outcomes at the entire treatment plan level
- The coordinator and doctors are the only users who are allowed to access and
manipulate clinical patient data within the information system
- Coordinators can only see patient data from patients that are assigned to their care
group via the information system
- Doctors can only see patient data from patients that they give treatment to via the
information system
- Administrative staff can only have access to administrative patient data via the
information system
Non-functional:
- Security: the system should secure the patient’s data
- Reliability: the system should be reliable to its end users
- Privacy: the patient’s data should only be accessible by the people who are allowed to
- Performance: the system should not lag
- Compatibility: the system should be compatible with future subsystems
- Capacity: the system should be able to store as much patient data as needed
- Intiutively: the system should be easy to manage by employees
Because of complexity issues the requirement that new activity types need to be edited dynamically to accommodate for future activity types ,will be out of scope.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
3 Scope There are two use cases that are out of scope in the use-case diagram. The managing of the screening is out of scope because this is an activity done by the coordinator. The system is not involved in this and because of that it is out of scope. Also the referral of the patients is out of scope. It is done by a primary caregiver or by the patient itself, with the help of a self-assessment survey. The referral of the patients is out of scope because it happens outside GGzE so also outside of the system.
3.1 Use-Case Diagram
Figure 1 - Use-case diagram
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
3.2 Actor Descriptions Actor
Role in Use-Cases
Administrative worker
Takes care about all the administrative tasks in the GGZE, is responsible for registering patients in the system. The administrative worker can only access standard patient data, for example: name and telephone number.
Coordinator Is responsible for the screening when the patient comes to the GGZE. After this screening the coordinator assesses whether the patient should receive a treatment or not. This result is also filled in in the system by the coordinator. The coordinator uses these results to match a patient to a care group and a doctor. The coordinator can also query both standard as well as sensitive patient data. During the treatment of a patient, the coordinator has to monitor the treatment progress.
Doctor The doctor is responsible for the treatment plan and the activities. He or she creates a treatment plan in the system that exists out of activities for every patient. When there is no activity at the GGZE that matches the needs of a patient, the doctor can create and add a new activity in the system. The doctor is able to query both sensitive as well as standard patient data.
Employee The employee is a generalisation of all the employees working at the GGZE. An employee is able to query standard patient data.
Physician The physician is a generalisation of the doctors and coordinators at the GGZE. An physician is able to query sensitive patient data.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
4 Use Case Descriptions
Use Case Name Query standard patient data
Use Case ID UC1
Description Employee queries standard patient data from the system.
Actors
Employee
Trigger Employee needs standard patient data.
Basic Flow 1. Employee searches for standard patient data of a specific patient in the system. 2. Employee receives standard patient data from the system.
Alternate Flows 2’. Standard patient data list is empty. 3’. Ask administrative worker to add standard patient data. 4’. Employee receives standard patient data.
Error situations
-
Use Case Name Register patient
Use Case ID UC2
Description The patient will be registered in the database which includes being assigned to a care group, using the patient data from the referral.
Actors
Administrative worker
Trigger The patient data from the referral is received.
Basic Flow 1. Patient data is reviewed by administrative employee and care group has been specified by primary caregiver.
2. Patient is assigned and registered to care group.
Alternate Flows 2’. Patient is not yet assigned to care group because primary caregiver was not able to do that 3’. Admin employee gives survey to patient 4’. patient fills in survey 5’. see step 2
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Error situations
Use Case Name Process screening result
Use Case ID UC3
Description The coordinator assesses whether the screening result is positive or negative.
Actors
Coordinator
Trigger The coordinator screens the patient.
Basic Flow 1. Coordinator assesses result of screening.
Alternate Flows -
Error situations -
Use Case Name Manage treatment plan
Use Case ID UC4
Description The managing/composition of the treatment plan for a patient.
Actors
Doctor
Trigger A new patient is assigned and the doctor has to add or remove activities to the patient’s treatment or the doctor gets negative feedback on the progress of a treatment plan.
Basic Flow 1. Doctor has a (new) patient assigned to his care group. 2. According to the care group of the patient the activities of the treatment plan are
determined. 3. Doctor will further decides the set of activities that will constitute the treatment
plan. 4. Doctor adds or removes those activities to the standard treatment plan.
Alternate Flows 1’. Patient is assigned to the intensive/forensic care group and has no standard treatment plan. 2’. Doctor creates treatment plan. 3’. Doctor adds activities to the treatment plan.
Error situations
When the doctor makes a mistake, he or she has to adapt the treatment plan until it is right.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Use Case Name Manage standard activities
Use Case ID UC5
Description Evaluation of the progress that the patient makes during the treatment and adapt existing standard activities to meet the requirements of a specific patient. This is different than managing the treatment plan because an individual activity can be changed to adapt it to the needs of the patient.
Actors
Doctor
Trigger Evaluation of the progress results the knowledge that the treatment plan is not optimal.
Basic Flow 1. Evaluation of the progress that the treatment plan makes on the treatment of the patient is done by the doctor.
2. Doctor concludes that the treatment does not fulfils the needs of the patient entirely.
3. The doctor adapts activities to meet the requirements of the patient. 4. Implement adapted activities to the treatment plan.
Alternate Flows 2’. Doctor concludes that no adaption of the treatment plan is needed. 3’. Nothing is changed in the treatment plan.
Error situations
-
Use Case Name Adding new type activities
Use Case ID UC6
Description Create new type of activities and add them to the treatment plan.
Actors
Doctor
Trigger When the existing type of activities cannot be adapted to match the needs of the patient.
Basic Flow 1. No activity that fits the need of the patient exists. 2. The doctor creates new standard activity. 3. The new standard activity is added to the list of standard activities 4. The new standard activity is available to apply to the treatment plan.
Alternate Flows -
Error situations
-
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Use Case Name Query sensitive patient data
Use Case ID UC7
Description Physician queries sensitive patient data (for example, treatment plan and doctor) from the system.
Actors
Physician
Trigger Physician needs sensitive patient data.
Basic Flow 1. Physician searches for sensitive patient data of a specific patient in the system. 2. Physician receives sensitive patient data from the system.
Alternate Flows -
Error situations
Sensitive patient data list is empty.
Use Case Name Assign patient to a doctor
Use Case ID UC8
Description The coordinator assigns a patient to a doctor of his or her care group.
Actors
Coordinator
Trigger Patient receives a positive screening result.
Basic Flow 1. Coordinator searches for free doctors. 2. Coordinator assigns patient to a free doctor.
Alternate Flows 2’. No free doctor is available in the system. 3’. Coordinator searches for all the doctors in the care group 4’. Coordinator assigns patient to a doctor with the least amount of patients allocated.
Error situations
-
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Use Case Name Monitor treatment outcomes
Use Case ID UC9
Description Monitor the outcomes of a treatment for a specific patient.
Actors
Coordinator
Trigger This is assessed on a standard base every fixed period of time.
Basic Flow 1. Searches sensitive patient information in the system. 2. Reviews the treatment progress of this patient. 3. Gives feedback to doctor
Alternate Flows -
Error situations
-
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
5 Test Case Descriptions Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC1
UC1 Patient is registered by the admin staff.
The employee fills in a patient form to search for a specific patient.
The system will show the result of the query so the employee is able to select the patient.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC2
UC1 Patient is registered by the admin staff.
The employee fills in a patient form to search for a specific patient.
The system will show an empty list of patients since the query data is not correct.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC3
UC2 The patient’s referral is received by the admin staff.
The administrative worker fills in the registration form to register the patient.
The system gives the admin worker a confirmation that the patient has been registered.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC4
UC2 The patient’s referral is received by the admin staff.
The administrative worker fills in the registration form to register the patient.
The system gives the admin worker an error that the patient hasn’t been registered.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC5
UC3 Patient is assigned to
The coordinator assigns the patient to a doctor within their care group.
The system gives a confirmation that the
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
a care group.
patient is assigned to a doctor of their care group.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC6
UC3 Patient is assigned to a care group.
The coordinator assigns the patient to a doctor within their care group.
The system will give an error saying that all doctors are at their capacity. The coordinator has to overbook a doctor.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC7 UC4 The patient is assigned to a doctor.
The doctor decides on the set of activities that the treatment plan consist of.
The system allows the doctor to assign a standard treatment plan to the patient by giving an overview of standard treatment plans the doctor can choose from.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC8
UC4 The patient is assigned to a doctor.
The doctor decides on the set of activities that the treatment plan consist of.
The system allows the doctor to create a treatment plan from scratch via a form.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC9
UC4 The patient has no treatment plan.
The doctor wants to manage the patient's treatment plan.
The system allows the doctor to create a treatment plan from scratch via a form.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC10
UC5 The patient has a treatment plan.
The doctor adds a standard treatment activity to the patient’s treatment plan.
The system allows the doctor to assign a standard treatment plan to the patient by showing a list of standard activities
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
the doctor can choose from.
Test Case
Use Case ID
Prerequisite Test Case Scenario Expected Result
TC11
UC6 Doctor wants to use an activity that’s not listed as a standard activity
The doctor creates a new type of activity.
The system will allow the doctor to create a new type of activity via a form.
6 Conceptual Data Model
Figure 2 – Conceptual data model
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
In the figure above (figure 2) our conceptual data model is shown, as well as in appendix A. The following assumptions have been made:
● We assume not every coordinator has to perform screenings. ● We assume a patient does only belong to a single care group for every moment in time. ● ● There is an association between doctor and activity type because we want it to be
possible for doctors to add new activity types. The multiplicity of this association is on both ends *. Because doctors can work together to add a new activity type and the doctors are possible do add no or several new activity types..
● Further there is a shared aggregation between treatment plan and activity types, because a treatment plan consists of activity types. However, the activity types can also exist on their own.
● The treatment plan can either be a standard treatment plan or a composed one. Standard treatment plans are available for the acute and rehabilitation groups. For the forensic groups, a treatment plan should be made from scratch, therefore a treatments plan for these groups is always composed.
● The treatment of a patient can consist of both a treatment plan and activity types. Itt is also possible that a doctor composes a treatment of only one activity types or only select one treatment plan.
● We assume the process of writing a referral by the primary caregiver for the patient is out of scope, because this is not of interest for the system of the GGzE.
● We assume that the care group is determined by either a survey or the referral. In the case of the referral no entity is needed in the model because the adm. staff can fill in the care group of the patient based on the data of the referral.
● The survey is filled in by the patient and is thus about the patient. But is also associated with the adm. staff because we assume that they will fill in the answers of the patient of the survey in the system.
● We assume that the long term outcome of a treatment is indicated by the fact whether a treatment is successful or not, therefore outcome is an attribute of treatment .
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
7.User Interface Design
Screen flow administrative staff
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Screen flow coordinator
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Screen flow doctor
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
8.Mendix Implementation
8.1 Domain Model
8. Provide arguments why those two are consistent
We will first look at the entities and after that we will look at the associations between
entities.
Entities
‘Screening result’ is in our conceptual data model a separate entity which is connected
to the patient and the coordinator, because the patient will be screened by the
coordinator. The coordinator then fills in yes or no as result of the screening. In Mendix
this can be modelled easier in the domain model. The screening result here is modelled
as a attribute of the patient with an enumeration of yes or no. Hereby the screening
result can be filled in by the coordinator. The benefit is that without the extra entity for
screening result but an extra attribute in the domain model for ‘screening result’, no
extra data grid has to be made to show and make the link between the patient and the
screening result.
The entity ‘care group’, which is an attribute of ‘patient’ in our Mendix model, is
modelled as an enumeration. The enumeration is based on the generalization made in
our conceptual model. In our conceptual model, we have the three different care groups
(‘Acute’, ‘Rehabilitation’ and ‘Forensic’) as subclasses of the superclass ‘caregroup’. In
order to make the handling easier, the domain model of Mendix has the entity
‘caregroup’ not as entity but as attribute of the entities patient, coordinator and doctor.
For the conceptual model it is easier to model caregroup as entity so instead of having
to change an attribute on multiple places, you only had to change the entity once (which
would make sure the associations also changed). In Mendix it is more convenient to
have it as attribute so no extra associations have to be made and thus unnecessary
complexity can be avoided. The model is still consistent, because the patients are in
both cases linked to one of the three earlier mentioned care groups. Besides, the
change to make ‘caregroup’ an attribute, instead of an entity was easily made. All
enumerations, as mentioned in the conceptual data model, were modeled in the
domain model as well, without applying further changes.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Another generalization which is present in the conceptual model is the treatment plan.
In the conceptual model is mentioned that the treatment can have a composed
treatment plan or standard treatment plan. In the domain model this generalization is
not modelled anymore, because in Mendix the treatment plans which are standard are
predefined and saved in de database. The composed treatment plans can still be made
by the doctor itself in de application. Hence, the generalization is not modelled in
Mendix.
The last generatlization of the conceptual model is that a coordinator is a physician. This
is not further modelled in the domain model. In the domain model only coordinator is
modelled. However, all physician which have the userole of coordinator can access the
system as coordinator. This is something which does not have to be modelled in the
domain model but has to be taking care of by the system administration when making
the account for a physician.
While those two generalizations are removed, the generalization of person is kept in our
Mendix domain model. However the attributes of person are stored in each subclass.
We only use person as an entity to make the association with the entity of account. This
association is has no added value for the conceptual model as is only makes is possible
to make XPaths that the user (account) of the system only can see and or edit other
persons which are associated to them.
The following entities are modelled to same in the conceptual model and in the domain
model: survey, activity session, activity type, treatment, medicine and treatment plan.
These entities could be modelled the same way because they all kept the same
attributes in Mendix. So there was no need to change these.
Associations
In general assigning multiplicities in Mendix is different than in an uml class diagram. In
Mendix the choose of multiplicities consist of 1-*, 1-1 or *-*. In our conceptual model
we used the multiplicity 1* several times which does not exist in Mendix. When
transforming our conceptual model to the Mendix domain model all the 1*
multiplicities are changed to a * multiplicity. With change still all possibilities of different
numbers of multiplicities are possible as also indicated with the 1*. But the restriction of
having at least one of the entity is lost. This can be explained by the example of the
association between patient and treatment which contains on both ends the multiplicity
1* in the conceptual model. When the patient is registered it can not have immediately
a treatment, causing that it can not be a restriction to have at least one treatment.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
When a treatment is made, it will be attached immediately to the patient so treatment
will always have a patient. The entity treatment can not be made in the database
without connection to a patient. In the remaining cases the loss of the restriction is
solved by putting commitments on attributes.
In our conceptual model a shared aggregation between treatment plan and activity type
is modelled. Mendix does not support association types such as composition or
aggregation. So a normal association had to be used to describe this relation but in the
properties of the association the delete behavior is specified. The option “an object can
only be deleted if it is not associated with any other object(s)” is selected because it is a
shared aggregation. For three other associations we specified the delete behavior in
Mendix. When a patient is deleted, the treatment and the survey of that that patient
will be completely deleted. The last delete behavior that is installed is that when a
treatment is deleted, the treatment plan will also be deleted automatically. These last
three delete behavior are useful for our database to make sure no redundant data is
stored in the database.
The last difference between the Domain model and our conceptual model are two
constraints. The first constraint {The doctor whom the patient is assigned to need to be
assigned to the same caregroup as the patient} which is not present in the domain
model, but is processed in Mendix as an Xpath. As the coordinator who assigns a doctor
to a patient only can see the doctors which are associated to him/her and patients of his
or her caregroup. Because the list of patients is retrieved by the microflow with the
Xpath for example [ReferralCaregroup = 'Rehabilitation'] for the coordinator of the
rehabilitation care group. The other constraint, {If the care group is acute or
rehabilitation than standard treatment plan, if the care group is intensive than
composed treatment plan}, is processed by that the treatment plan has got also the
attribute of caregroup. Such that the predefined/standard treatment plans can be seen
to which care group they belong.
The following associations are the same in both models: medicine and doctor, medicine
and patient, activity session and treatment, treatment and activity type, admn staff and
patient, patient and doctor, activity type and doctor, coordinator and patient, activity
session and activity type.These could be modelled the same way because there were no
constraints or other special forms of associations between these entities.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
In Mendix you can assign an owner to an association. This has been done with the
conceptual model in our mind. However, these relations are not visible in our
conceptual model.
To summarize, when converting our conceptual model to a Mendix model we made sure
that no information is lost. Due to Mendix the way Mendix operates we needed to
change, add or delete attributes, entities or associations. However, the main idea
behind the structure and functionalities of both models are the same.
8.2 Security
Define which (security) roles there are in the system and which forms, microflows and
data objects they can access, by filling out the following tables.
Role Description
Administrative Worker Should be able to add patients in the system and define the care group
Coordinator_acute Should be able to add doctors in the system and match patients of his own care group to doctors. The coordinator should also be able to add patients to the system.
Doctor Should be able to compose treatment plans with the help of all kinds of activities. The doctor should also give updates about the progress of a treatment.
Coordinator_forensic Should be able to add doctors in the system and match patients of his own care group to doctors. The coordinator should also be able to add patients to the system.
Coordinator_Rehab Should be able to add doctors in the system and match patients of his own care group to doctors. The coordinator should also be able to add patients to the system.
Patient Should be able to check in the system whether or not he or she should use any medication. And if so which one.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Form Roles
ActivitySession_NewE
dit
Doctor; User
ActivityType_NewEdit
Doctor; User
ActivityType_NewEdit_2
Doctor; User
ActivityType_Select None
Add_ActivityType Doctor; User
Add_Medicine Doctor; User
Add_Treatmentplan Doctor; User
Coordinator_NewEdit
User
Doctor_NewEdit Administrative_Worker
Doctor_NewEdit_Coordinator
Coordinator; User
Doctor_Set_ActivitySessions
Doctor; User
Homepage Administrative_Worker; User
Hompage_Coordinator_Acute
Coordinator_Acute; User
Hompage_Coordinator_Forensic
Coordinator_Forensic; User
Homepage_Coordinator_Rehab
Coordinator_Rehab; User
Homepage_Doctor Doctor; User
Homepage_Patient None
Medicine_NewEdit Doctor; User
Medicine_NewEdit_Doctor
Doctor
Medicine_Select None
MyPatients_Coordinator
Coordinator; User
MyPatients_Doctor Doctor; User
Overview_Treatment_Plan_A_R
None
Patient_NewEdit Administrative_Worker; User
Patient_NewEdit_Coordinator
Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; User
Patient_NewEdit_Doctor
Doctor; User
Patient_NewEdit_Patient
Patient; User
Survey_NewEdit None
TestPatient User
Treatment_NewEdit Doctor; User
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Treatment_NewEdit_2
Doctor
TreatmentPlan_NewEdit
Doctor
TreatmentPlan_Select
None
Microflow Roles
AssignDoctorFromPati
ent
Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab
AssignPatientToDoctor
Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab
CalculateCareGroup None
CoordinatorDoctor Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab;
Administrative_Worker; Patient CoordinatorPatient_Acute
Coordinator_Acute; Administrative_Worker; Patient
CoordinatorPatient_Forensic
Coordinator_Forensic; Administrative_Worker; Patient
CoordinatorPatient_Rehab
Coordinator_Rehab; Administrative_Worker; Patient
CreateSurvey Administrative_Worker
DeletePatient Administrative_Worker
DoctorMedicine Doctor
DoctorPatient_M Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Doctor
DoctorPatients Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab
PatientMedicine Doctor; Patient
RemoveDoctor Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab
RemoveMedicine Doctor
RemovePatient Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab
RemovePatientFromDoctor
Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab
ShowCareGroup Administrative_Worker
SubmitSurvey Administrative_Worker
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Data object Roles
ActivitySession Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient;
Administrative_Worker(can only access but cannot create or delete an activity
session) User; Doctor (can access, create and delete activity sessions)
ActivityType Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient;
Administrative_Worker (can only access but cannot create or delete an activity
type) User; Doctor (can access, create and delete activity types)
AdmStaff Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient; Doctor;
Administrative_Worker ( can only access but cannot create or delete an
AdmStaff) User can access, create and delete an AdmStaff)
Coordinator Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient; Doctor
(can only access but cannot create or delete a Coordinator) User (can access,
create and delete a coordinator)
Doctor Patient; (can only access but cannot create or delete a Doctor)
Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab;
Administrative_Worker; Doctor; User( can access, create and delete a doctor)
Medicine Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab;
Administrative_Worker; Patient; (can only access but cannot create or delete a
medicine) Doctor; User (can access, create and delete a medicine)
Patient Patient; Doctor; Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; (can only access but not create or delete a patient) User; Administrative_Worker (can access, create and delete a patient)
Person User (can access, create and delete a patient)
Survey Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient; Doctor;
(can only access but cannot create or delete a survey) User;
Administrative_Worker (can access, create and delete a survey)
Treatment Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient;
Administrative_Worker (can only access but cannot create or delete a
treatment) User; Doctor (can access, create and delete a treatment)
TreatmentPlan Coordinator_Acute; Coordinator_Forensic; Coordinator_Rehab; Patient;
Administrative_Worker (can only access but cannot create or delete a
treatmentplan) User; Doctor (can access, create and delete a treatmentplan)
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
8.3 Top-3 Mendix Showcase
8.3.1 Mendix Showcase 1: …
In our Mendix implementation we made sure that a doctor could add medication and
assign this to patients. This is a surplus since doctors normally didn’t have to specify this.
The microflows associated with this showcase can be seen in figure 1 and 2.
Fig 2.
Fig 1.
As seen in figure 3. doctors are able to
search medication, enter new
medication, edit medication and delete
medication. If a medication has not
been entered into the system, it can of
course also not be linked to a patient.
When adding a new medicine into the
system, the doctor can specify the
name, frequency of use and a
description.
Fig 3.
In the patient tab the doctor is able to
assign medication to a patient. In this
screen (figure 4) the doctor needs to
select the medication and click ‘select’.
Now the medicine has been assigned
to the patient.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
fig 4.
8.3.2 Mendix Showcase 2: …
The system offers a certain amount of standard activity types for certain care groups.
The forensic group doesn’t have standard activities or standard treatment plans so the
doctor has to create these from scratch. Our system makes it possible for doctors to
create new activity types and assign these to certain patients. Before an activity type
can be added to the treatment plan of a patient it first has to be created. This is done in
the section ‘Manage activity types’ as seen in figure 5.
fig 5.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
An activity type consists of a name, standard price, session length, medicine used, an
end date and a frequency. Furthermore, a doctor is able to search, create, edit and
delete activity types. To assign an activity type to a patient’s treatment plan the doctor
first has to search the patient in the system. After that he is able to select the treatment
of the patient and assign the recently created activity type. This form is shown in figure
6.
fig. 6
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
8.3.3 Mendix Showcase 3: …
At last, doctors are able to note a session outcome and an overall treatment outcome.
The treatment outcome can be entered into the system when the treatment of a patient
is selected as shown in figure 7. In this figure also an overview of our custom made
theme for GGzE can be seen.
fig. 7 fig 8.
When creating an activity session the doctor can also note the outcome of that
session(figure 8). In the case that a patient returns to the hospital, the doctor is able to
see at a glance if the previous activities of the patient were successful (figure 9).
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Appendix A- User Interfaces
Screen Name and Brief Description
Screenshot of Mendix Form
Login screen – The employee is asked to fill in their username and password to get access to the system.
Error incorrect details – An error says that the username and/or password is incorrect.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Main menu – The administrative employee can choose the functions to see the patients, doctors or coordinators data.
Display patients – A list of all the patients is shown in this screen.
Display patient search form – A form is shown where data about a specific patient can be filled in to find that patient.
Display empty patient list – An empty patient list is found, this means that there are no
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
patient matching the data that is provided. Display found patients – A list with all the patients that match the search criteria is shown.
Registration form – A screen is shown where new data about a patient can be added of where existing data can be modified.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display doctors – displays a list of all the doctors.
Display doctor search form - A form is shown where data about a specific doctor can be filled in to find that doctor.
Display empty doctor list – the data that is filled in does not match the data of any doctor,
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
so an empty doctor list is shown. Display found doctors – all the doctors that match the search criteria are shown in this screen.
Display data of doctor – Displays all the data that is available about a specific doctor.
Display coordinators – displays a list of all the coordinators.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display coordinator search form - A form is shown where data about a specific coordinator can be filled in to find that coordinator.
Display empty coordinator list – no coordinator is found that matches the search criteria, so no coordinator is shown.
Display found coordinators & their data – displays all the coordinators that match the search criteria and shows the available data of the coordinator.
Screen Name and Brief Description
Screenshot of Mendix Form
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Login screen – The employee is asked to fill in their username and password to get access to the system.
Error incorrect details – An error says that the username and/or password is incorrect.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Main menu – The employee sees the basic data about patients and doctors.
Display patients – A list of all the patients is shown in this screen.
Patient selected – Shows the list of all the patients with the selected patient marked blue.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display patient data list – displays the data list from a specific patient, in this screen the data can also be edited.
Display Doctors – Displays a list of all the doctors.
Display new doctor data form – Displays a data form where data from a new doctor can be filled in to add a new doctor.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Doctor selected – displays the list of doctors with the selected doctor marked blue.
Display doctor data form – Displays the data of an existing doctor, in this screen the data can also be edited.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Doctors’ patient selected – The list of patients for a specific doctor is shown and the selected patient is marked blue.
Screen Name and Brief Description
Screenshot of Mendix Form
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Login screen – The employee is asked to fill in their username and password to get access to the system.
Error – incorrect details – An error says that the username and/or password is incorrect.
Main menu – The employee can choose between the function to see the
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
patients, the function to see the activity types, treatment plan and medication. Display patients – A list of all the patients is shown in this screen.
Display patient search form – A form is shown where data about a specific patient can be filled in to find all the available data of that patient.
Display empty patient list – An empty patient list is found, this means that there are no patient matching the data that is provided.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display patient search results – A list with all the patients that match the search criteria is shown.
Display patient data – All the data that is available for a specific patient and his or her treatment plan is shown in this screen.
Patient is selected – The screen with the selected patient marked blue is displayed.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Edit patient data – A screen with the data sheet of the patient is shown and it is possible to edit the data.
Display medication overview – An overview of all the options with regard to the medicines that the patient uses is shown here.
Display medication list - The list with all the medicines that a patient uses is displayed here.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display medication search form – A search form is displayed in the screen with the medicine list.
Show medication search results – Shows the medicines list that matches the search criteria.
Display empty medication search results list – Shows in the screen that there are no medicines that match the search criteria.
Confirmation delete medicine – Displays a confirmation which asks if the doctor is sure that he or she wants to delete the medicine.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display treatment overview – displays all the options with regard to the treatments
Display treatments – Displays a list of all treatments for that specific patient.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display new treatment form – Displays the data sheet that has to be filled in to add a new treatment for the patient.
Selected treatment plan – Displays the a list of all the treatments with the selected treatment marked blue.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display treatment data – displays the treatment data sheet where the doctor can edit the treatment.
Confirmation delete treatment plan – displays a confirmation if the doctor wants to delete a treatment plan.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display add treatment plan – displays a form with the data that needs to be filled in to create a new treatment plan.
Treatment selected plan – displays the selected treatment plan marked in blue.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Confirm delete treatment plan – asks for confirmation if the treatment plan needs to be deleted.
Display activity types – displays a list of all the available activity types.
Display add activity type – Displays the screen where an activity type can be added.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display activity types – Displays a list of all the available activity types.
Show activity type list – Displays the list with all the activity types that are available.
Activity type selected – shows the list of all the activity types with the one that is selected marked in blue.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display activity type data – displays all the data of an activity and the doctor can edit the data here.
Display activity type search form - Displays a search form where data can be entered to search for a specific activity type.
Display empty activity type search – displays an empty list of activity types, which means that there are no activity types that match the search data.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display activity type search results – displays all the search results that match the search criteria.
Confirmation delete activity type – shows a confirmation if a doctor wants to delete the activity type.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Show activity type registration form – shows a data form where all the information about an activity type can be added to create a new activity type.
Display list of medicines - displays a list of all the medicines available.
Display medicine data form – displays a data sheet where data about the medicine can be added to create a new medicine in the system.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display medicine search form – displays a search form where data about a medicine can be filled in to search for a specific medicine.
Display medicine search results – displays a list with all the medicines that match the search criteria.
Medicine selected – displays the list of medicine with the selected medicine marked in blue.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Confirmation delete medicine – asks for confirmation from the doctor that the medicine needs to be deleted.
Display medicine data list – shows all the available data of the medicine and in this screen, that data can be edited.
Display empty medicine search results list – displays an empty list of medicines because there are no medicines that match the search criteria.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display treatment plans – displays a list of all the treatment plans available.
Display search form – Displays a search form where data about a treatment plan can be entered to find a specific treatment plan in the system.
Treatment plan selected – Displays a list of the treatment plans with the treatment plan that is selected marked blue.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Confirm delete treatment plan - asks for confirmation from the doctor that the treatment plan needs to be deleted.
Display treatment plan data form – displays the data from a treatment plan and in this screen, this data can be edited.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Display new treatment plan form – displays the data form in which data can be added to create a new treatment plan.
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.
TU/e 1BV10 Business Requirements Document (BRD)
Appendix A: Conceptual Data Model
Copyright ♥ 2010 by Noble Inc. Adapted from UML for the IT Business Analyst, 2nd ed. (cengage, 2009). All rights reserved.
Copyright ♥ 2018 by Eindhoven University of Technology, School of Industrial Engineering, Information Systems.