Requirement Gathering For Headspace Integrated Patient Management System

Further background

Every project has actors or stakeholders that are involved in different aspects of the project. Stakeholders in a project are important and influential to the overall success path of a project but the level of importance and influence depends on which type of stakeholder an actor is in a project. A stakeholder map diagram is used to show what type of stakeholders will be involved with the system. To help give a conceptual view of how different actors will be interacting with the system, a use case diagram is used where by use cases modeled in the use case diagram can be described in details to form a use case description. This report aims at showing the types of stakeholders that are going to be involved in the headspace project and how actors are going to interact with the system.

A stakeholder is any individual or organization that is directly or indirectly involved in the development of a project (Humphrey, 1989). A stakeholder has a stake in the project thus the stakeholder can benefit or lose from the success or failure of a project. There are four types of stakeholders

• Internal executive stakeholders- These type of stakeholders are usually the management of the organization undertaking the project or the board of directors of the organization. These stakeholders are responsible for making executive decisions in the organization.
• External executive stakeholders- These type of stakeholders make executive decisions concerning the organization but are not part of the organization. These type of stakeholders can be the higher power, for example the department of the government that controls activities of the organization or funds the activities of the organizations
• Internal operation stakeholders- These type of stakeholders are directly involved with the project. They can be the team of staff that is undertaking the project.
• External operations stakeholders- These type of stakeholders are the intended end users of the project and stand to benefit from the implementation of the project. They are mainly involved with the project after it has been completed and deployed.

Figure 1: Stakeholder map diagram

Stakeholders are drawn on four quadrants mapped on a plane axis. There are two factors that determine where a given type of stakeholder appears in the stakeholder map. These factors are;

• Influence- This is the level of authority that that the stakeholder has over the decisions that are made regarding the project. These decisions may include financial decisions or major decisions that might affect the outcome of the project.
• Importance- This factor specifies how important a stakeholder is to the overall success or failure of the project.

Based on the stakeholder map diagram in figure 1 the different stakeholders are placed each on different quadrants based on their level of influence on the project and how important they are to the project.

• Internal executive stakeholders- According to the stakeholder map diagram, these stakeholders are the most important and the most influential to the project. This can be attributed to the fact that these stakeholders are the executive decision makers and any major decision made in the organization must be made by them. This makes them the most influential because they will approve the budget and the start of the project.
• External executive stakeholders- According to the stakeholder map diagram, these type of stakeholders are very influential to the project but are not very important to the project. Their level of influence is determined by the fact that they are the sponsors. For this case, the external executive stakeholders are comprised of the Australian government. The external executive stakeholders are not very influential to the project because they do not make the most critical executive decisions regarding the project but rather approve decisions made by the internal executive stakeholders.
• Internal operations stakeholders-According to the stakeholder map diagram, these type of stakeholders are very important to the project nut are not very influential on the success path taken by the project. Theses stakeholders are comprised of the team of developers that will be developing the system. The team can be internal to the organization or can be outsourced to develop the project. These stakeholders are very important to the project because they determine the fend product that will come out of undertaking the project. This is because they are the developers and will determine if the end product is a good system in general or a bad system in general. To enforce these type of stakeholders, a quality assurance team is introduced whose sole purpose is to make sure that the end product meets its requirements in every aspect. However, these type of stakeholders are not very influential to the project because they follow and work according to the decisions made by the internal executive stakeholders.
• External operation stakeholders- these type of stakeholders are comprised of the end users of the system. For this project, the end users are the headspace worker, emergency department workers and the patient themselves. Al these stakeholders interact with the system in one way or another. The internal operations stakeholders make and tune the system in consideration of the external operation stakeholders. According to the stakeholder map diagram, external operations stakeholders are have the least influence of the critical path take by the project and they are also not very important because they do not make executive decisions regarding the project.

Questionnaire is a technique of requirements gathering that involves distribution of either open ended or close ended questions to respondents with the aim of gathering requirements by analyzing the answers answered on the questionnaires by the respondents (Humphrey, 1995). For this project the questionnaires can be addressed to external operations stakeholders who will be the end users of the proposed system. Since the primary objective of the system is the patients, this sample questionnaire is addressed to the patients.

National Youth Mental Health Foundation (Headspace) questionnaire to facilitate requirements engineering for the proposed system Headspace integrated patient management system.

1. What is your name? ____
2. What is your date of birth? ____
3. How many times have you visited a headspace worker? ___
4. How many different mental health specialists have you visited? ____
5. How does it feel to repeat your story to different specialists you visit?
6. Would you feel free with your story stored in an information system? (if No give a reason)
7. How easy is it for you to access internet from your home? __
8. How would you like to know information about appointments made with a specialist?
9. Can you allow information about your recovery to be used to help others experiencing the same condition as you?
10. Give your personal recommendation on how you expect the new integrated system to work

Use case diagram

Figure 2: Use case diagram

The following are the use cases derived from the use case diagram.

The headspace worker interacts with the system through the following use cases;

• Login- in this use case, the headspace worker logs into their account using a username and password. This use case involves sending a one-time login pin for more secure authentication.
• Manage patient- The headspace worker adds a patient to the system through this use case. The headspace worker can add a new patient, update an existing patient or delete a patient from the records
• Manage notes- The headspace worker captures the story of the mentally ill patient through this use case. The headspace worker can add a note, update an existing note or delete a note.
• Send patient to ED- the headspace worker sends a patient to the emergency department using this use case.
• Schedule appointment- The headspace worker schedules a patient appointment using this use case.

The emergency department worker interacts with the system through the following use cases;

• Login- in this use case, the ED worker logs into their account using a username and password. This use case involves sending a one-time login pin for more secure authentication.
• Admit patient- When a patient is sent to the emergency department by a headspace worker, the ED worker records details of the admission using this use case.
• Discharge patient- A patient is discharged from the emergency department through the system through this use case. When the patient is discharged, a notification is sent to the headspace who sent the patient to the emergency department.

The patient interacts with the system through the following use cases.

• Login- in this use case, the patient logs into their account using a username and password. This use case involves sending a one-time login pin for more secure authentication.
• View appointments- the patient can view appointments scheduled by the headspace worker using this use case.

Use Case ID:	UC-1
Use Case Name:	Login
Created By:	student name	Last Updated By:	Student name
Date Created:	9/7/2017	Date Last Updated:	9/7/2017

Actors:	Headspace worker, ED worker, patient
Description:	A headspace worker, ED worker or patient logs in to their account
Trigger:	Login request
Preconditions:	· User must have an account · User must have a working mobile phone
Post conditions:	A user session is created
Normal Flow:	· User sends in login request · System displays login page · Use enters username and password · System verifies the username and password are correct · System sends an OTP to the user through a text message · User enters the OTP · System creates a session and authenticates the user
Alternative Flows:	User does not enter the correct username and password · System notifies the user to enter the correct username or password User enters the wrong OTP · System notifies the user to enter the correct OTP
Exceptions:	OTP not received · User chooses resend OTP option
Includes:	Sending OTP
Priority:	High
Frequency of Use:	Very frequent
Business Rules:	Every user must exist in the system
Special Requirements:	Users must use a browser and must have access to the internet to do a login
Assumptions:	Every user has an existing account in the system
Notes and Issues:	Use of OTP ensures more security by preventing hacking where malicious users get access to a user’s username and password.

References

Deutsch, M. S. (1982). Software Verification and Validation, Realistic Project Approaches. Prentice Hal.

Humphrey, W. S. (1995). A Discipline for Software Engineering. Addison-Wesley Longman.

Humphrey, W. S. (1989). Managing the Software Process. Addison-Wesley Publishing Company.