Analysis of Stakeholders and Use Cases for Patient Management System

This report presents a comprehensive analysis of stakeholders and use cases for a patient management system, specifically designed for Headspace. It begins with an introduction to the project and the importance of stakeholder involvement, followed by a detailed stakeholder map categorizing stakeholders based on their influence and importance. The report then outlines a questionnaire designed to gather requirements from Headspace workers, detailing the questions asked. Use case diagrams and descriptions are provided, illustrating the system's functionalities, including managing patients, scheduling appointments, and handling patient records. A fully developed use case description for discharging a patient from the Emergency Department is also included, detailing the main success scenario and potential extensions. References to relevant literature are provided to support the analysis.

COVER PAGE
STUDENT DETAILS
COURSE DETAILS

Contents
1 Introduction..............................................................................................................................................3
2 Stakeholder map......................................................................................................................................3
2 Questionnaire...........................................................................................................................................5
2.1 Introduction statement.....................................................................................................................5
2.2 Questions...........................................................................................................................................5
3 Use case diagrams and descriptions.........................................................................................................7
3.2 Use case diagram...............................................................................................................................7
3.2 Use case description..........................................................................................................................7
3.3 Fully developed use case description................................................................................................8
Main success scenario.........................................................................................................................8
Extensions............................................................................................................................................8
4 References................................................................................................................................................8

1 Introduction
For any project, there are parties that are directly involved in the project and those parties that will be
involved with the project after its completion and deployment. Any of these parties has a contribution
and might gain or lose depending on the overall success of the project. To model and show how the
different stakeholders are involved in a project a stakeholder map diagram is used and for the
stakeholders who will be the end users interacting with the system after it has been completed and
deployed, a use case diagram is used (Gamma, Helm, Johnson and Vlissides, 1995).
2 Stakeholder map
The following diagram shows the stakeholder map with four quadrants comprising of the internal-
operation, external-operation, internal-executive and external-executive.
Figure 1: Stakeholder map
According to the stakeholder diagram above, there are four types of stakeholders in this project. The
stakeholder map is drawn on four quadrants drawn on axis plane with two factors determining which
stakeholder appears in what quadrant of the axis plane. The two determining factors are;

 Influence- Influence of a stakeholder is the level of authority that the stakeholder has over the
major decisions that are made regarding the project.
 Importance- Importance of a stakeholder is how crucial holder is or what key role does the
stakeholder play in the development of the project up to deployment and use of the system
(Bartini, Furlani and Nardelli, 2002).
By analyzing the diagram, the four stakeholders can be defined depending on their influence on the
project and how important they are to the project;
 Internal operations stakeholders- These are stakeholders that deal with the development of the
system. These stakeholders can be the team of developers that will be going to be developing
the system where by the team can be an internal team to the organization or external team
which has been outsourced to come and do the development in cases where there is no internal
team or the internal team of developers is not capable of handling such a project. The internal
operation stakeholders might also the network administrators that are going to be maintaining
the physical infrastructure of the network that the system is going to be running on or eve the
database administrators who will be responsible of maintaining the underlying database of the
application after it has been deployed. From the stakeholder map diagram, it’s clear that
internal executive stakeholders have low influence on the project but are very important to the
project. Internal operations stakeholders have low influence on the project because they do not
make any major decisions regarding the project or provide the funding that will be used to
undertake the development life cycle. However, internal operation stakeholders as they
determine the end success of the project because the product that they create is either bound
to fail if it has not been created according to the laid out standards or its going to succeed if it
has been developed in a good standard way.
 Internal executive stakeholders- These are the stakeholders that make executive decisions
internally to the organization. For this project, these stakeholders are the management of the
headspace program that are responsible of making corporate executive decisions regarding the
organization. Internal executive stakeholders have s high influence on the success of the project
and are very important to the success of the project as seen in the stakeholder map diagram.
These stakeholders are important to the project because they make all the executive decision in
the organization thus ultimately the success or undertaking depends on the decisions made by
the internal executive stakeholders. The high level of influence on the project can be attribute to
the fact that internal executive stakeholders control the direction of the project through factors
like money and other resources, thus their influence on the project determines the failure or
success of a project.
 External executive stakeholders- these type of stakeholders make executive decisions from
outside the organization. These stakeholders can be though as the overseers of the project who
are mainly the sponsors. For this project, the external executive stakeholders is the Australian
government which gave the funds to establish the headspace program. According to the
stakeholder map the external executive stakeholders have high influence on the success of the
project but are not very important to the project. The high level of influence can be attribute to
the fact that the Australian Government through another department like the health
department oversees the whole program thus have an authority on anything that is approved by

the internal executive stakeholders. However, they are not very important to the project as they
are external to the organization and are not involved in all the aspects of the organization.
 External operations stakeholders- These stakeholders are the end users of the proposed system
who will be interacting with it through various ways. For this project, the external operations
stakeholders are the headspace workers including the psychologists, psychiatrists and all the
other staff that will be using the system in any way. The external operation stakeholders can
also be external to the organization for example the patients who are the primary concern of
the whole project. The emergency department workers will also interact with the system
externally to the headspace organization. These stakeholders have low influence on the system
and are not very important to the implementation of the project. This can be attribute to the
fact that they do not provide executive decisions regarding the project or the funding that are
used to undertake the project. However, these stakeholders cannot be disregarded as they are
the end users of the system thus they have to be put into a lot of consideration when
implementing the system.
2 Questionnaire
Questionnaires are a good method of requirements gathering as they are easy to use and analyze after
collecting data (Rumbaugh, Jacobson and Booch, 1999). For the proposed project, the most important
stakeholder to give the questionnaire so as to come up with requirements to be used prepare a
specification document is the headspace worker. The headspace worker is the most suitable stakeholder
because he or she will be interacting with the system than any other stakeholder after its
implementation.
2.1 Introduction statement
Questionnaire to facilitate requirements engineering for the proposed headspace patient management
system that will help in patient management and rehabilitation.
2.2 Questions
1. What is your name? ______________________________________________________________
2. What is your profession as a headspace worker? (Choose below)?
General practitioner
Psychologist
Psychiatrist
Others
3. How many years have you worked in the Headspace organization
One to three years
Three to five years
Five to ten years
More than ten years
4. Approximately how many patients do you interact with every day? _____________________

5. How does the first time the patient gives their personal story differ from any other subsequent
times? (Give brief explanation)
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
6. How do you record the story given by a patient for the first time?
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
7. What circumstances make you send a patient to the emergency department?
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
8. How do you know a patient you sent to the emergency department (if any) has been released?
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________
9. Would you like an information system to help you manage patient information? (If No give a
reason)
Yes
No
______________________________________________________________________________
______________________________________________________________________________
10. How would you recommend the information system to be?
______________________________________________________________________________
______________________________________________________________________________
______________________________________________________________________________

3 Use case diagrams and descriptions
3.2 Use case diagram
Figure 2: Use case diagram
3.2 Use case description
 Manage patient- The manage patient use case is done a headspace worker where they can
either add a patient, update the patient details or delete the record of a patient.
 Schedule appointment- A headspace worker schedules a patient appointment through this use
case.
 Manage notes- A headspace worker manages the notes that are gotten from an appointment.
The headspace worker can add a note, update an existing note or even delete the patient note.
 Send patient to ED- when a patient is sent to the Emergency department the headspace worker
records the details of the event through this use case

 Admit patient- Admit patient use cause is used by the Emergency department worker to record
the details of the admissions. During the stay, the ED worker may add notes to the patient
records.
 Discharge patient use case- This use case is used by the emergency department worker to
discharge a patient. It includes ending a notification to the headspace worker who sent the
patient to the emergency department.
 Login- the patient logs in to the system through this use case using a username and password
created when the patient is added to the system.
 View appointments – This use case is used by the patient to view all the scheduled
appointments by a headspace worker.
3.3 Fully developed use case description
The discharge patient use case by the Emergency department worker is considered for fully
development
Main success scenario
I. ED worker searches for a patient using the patient ID or patient name
II. System displays all the patients who match the search results
III. Ed worker selects the patient
IV. System fetches the patient details from the database
V. ED worker selects discharge patient
VI. System asks for a confirmation of whether to discharge the patient.
VII. ED worker confirms the discharge.
VIII. System saves the details of the discharge.
Extensions
I. ED worker confirms discharge. System sends a notification to the headspace worker who sent
the patient to the emergency department.
4 References
E. Gamma, R. Helm, R. Johnson, and J. Vlissides. (1995) .Design Patterns: Elements of Reusable Object-
Orientated Software. Addison-Wesley.
C. Batini, L. Furlani, and E. Nardelli. (2002). what is a good diagram? In 4th International Conference on
the Entity Relationship Approach, pages 312–319.
J. Rumbaugh, I. Jacobson, and G. Booch. (1999). The Unified Modeling Language Reference Manual.
Addison-Wesley