Introduction

In this individual assignment, you have been tasked with gathering the requirements for a

Paramedical Emergency Response System (PERS). You will create a selection of artefacts from the requirements gathering process for the system described inAppendix 1.

Specifically, you will create:

•   A set of categorised stakeholders;

•   An interview outline;

•   A set of prioritised user stories;

•   A detailed use case;

•   A set of functional and non-functional requirements; and

•   An activity diagram.

This assignment will develop your skills by allowing you to put into practice what has been    taught during the first 6 weeks of the course. If any aspect of the assignment specification is unclear, please seek clarification.

Learning outcomes

After completing this assignment, you will have learnt to:

•    Identify project and system stakeholders for a given problem statement;

•    Prioritise requirements from astakeholder perspective;

•    Describe requirements using appropriate standards; and

•   Write formal use cases following appropriate standards.

Assignment and submission requirements

1.   The assignment must be submitted via Assessment Submission Link on the course website.

2.   The assignment must use the templates/layouts provided in assignment 1 for any  answers, tables, models, diagrams or use case description created. Diagrams must conform to the UML notation used in the course.

3.   The assignment must be submitted in PDF format with a file-size less than 1024KB.

4.   The assignment must be referenced where applicable following the APA 7 method   provided in the Information tab under Student Learning Support link to Referencing Style Guides.

5.   The assignment must document and justify any decisions and assumptions made.

6.   The assignment submission must not copy the scenario or question text from this specification.

7.   Post any questions in relation to the scenario or assignment on the A1 Form.

Marking criteria

The marking rubric for this assignment will be available on the course website. Use the

rubric to ensure you adequately address all aspects of the marking criteria. The assignment will be assessed on the following criteria:

1)   Completeness of solutions;

2)   Clarity of expression;

3)   Consistency within and between tasks;

4)   Technical correctness of the methods used; and

5)   Presentation, spelling, and grammar.

Task 1 - Identifying stakeholders

Week 1 of the course focusses on the knowledge and skills necessary to complete this task.

1.1.    Given the provided scenario, identify the project stakeholders and system stakeholders.

Not all stakeholders are listed in the scenario. Higher marks are awarded for identifying stakeholders beyond the scenario description.

1.2.    For each of the system stakeholders, identify if they are first degree, second degree, or third degree stakeholders.

1.3.    Write a paragraph justifying why you have identified the particular system stakeholders as first, second, or third degree stakeholders.

Hint: there is no prescribed word count for this activity. Be succinct and use enough words to make a clear justification.

Task 2 - Interview outline

Week 3, 4 and 5 of the course focusses on the knowledge and skills necessary to complete this task.

4.1     Write a fully developed “sea level” use case for any use case of your choice from the scenario inAppendix 1. For maximum marks, include all potential extensions you

could reasonable expect.

Ensure you must follow the use case template presented in the course textbook (Figure 7-32). Ensure to address the use case from a “sea level” perspective (i.e. address what the user is trying to achieve in interacting with the system).

Task 5 – System requirements identification

Week 2 of the course focusses on the knowledge and skills necessary to complete this task.

5.1.    Identify the functional requirements of the system.

Chose the highest priority user stories to write functional requirements for and

categories the requirements into areas of the system. Carefully consider the

interactions between the user and the system. The functional requirements should be written in the form:

FR1. The systemshall […]

Ensure your requirements meet the SMART criteria. Aim for 15– 18 functional requirements. Refer to the template for the format.

5.2.    Identify the non-functional requirements of the system based on the user stories completed in the task above, and categorise the non-functional requirements by   using Usability, Reliability, Performance, Supportability and Design Constraints.     These requirements should be written in the form:

NFR1. The system must […]

Ensure your requirements meet the SMART criteria. Aim for 15– 18 high quality non- functional requirements. Refer to the template for the format.

Hint: If there are no explicit non-functional requirements mentioned in the scenario, think from the perspective of various stakeholders of the system and introduce the   non-functional requirements.

Task 6 – Activity diagram

Week 6 of the course focusses on the knowledge and skills necessary to complete this task.

6.1.    Develop an activity diagram for the main success scenario of the use case modelled in Task 4.1. Your diagram should be represented at a sufficient level of detail to

capture all aspects of the scenario. You diagram should follow the style of Figure 7- 39 in the textbook. It should:

•    Use swimlanes to represent the actors in the scenario description;

•    Use branch and merge nodes to show branches in the scenario description;

•    Use fork and join nodes to show parallel activities.

•   Adhere to the UML notation presented in the textbook.

Hint: Ensure you include the system somewhere in the activity diagram and any other relevant actors.

6.2.    Identify the diagramming tool you used to develop the activity diagram.

Workplan

The assignment covers topics from weeks 1– 6 of the course. Each task in the assignment clearly marks which week to refer to in order to complete it. A suggested workplan is:

1)   Read the scenario text inAppendix 1at least twice, highlight keywords, and make notes;

2)   Perform further online research to better understand the domain the scenario addresses;

3)   It is reasonable to attempt to address the tasks in order;

4)   Complete the remaining tasks as youreach the relevant topic in the course; and

5)   Revisit the requirements you identified in Task 5 and improve them based on your user stories and use case.

As you attempt a task, refer to that week’s material. To achieve an HD, you should be

revising all your artefacts (i.e. stakeholders, user stories, etc) as you progress and gain a better understanding of the domain; this will ensure your assignment is complete and    consistent.

Draft Submission

A draft must be submitted to course submission link on the suggested data on first page of this document. We would expect that the draft includes a draft of yourstakeholder

identification, draft interview outline, and a draft of user stories. The draft has two

purposes: it ensures you start the assignment before the last week, and it helps markers see how your assignment and thinking develops into the final version. The feedback on draft

submissions will be provided during Week 5 workshops. Make sure to use the template provided with this assessment.

Extensions

Late submissions will receive 10% deduction per day late. Any submission after 5th  day from

the due date will receive zero mark. Please contact your course coordinator regarding extensions via email, providing the date of the extension and reason for extension.

Academic Misconduct

This is an individual assignment. Your submitted files will be checked against other student’s submissions, and other sources, for instances of plagiarism. Students are reminded that

they should be aware of the Academic Integrity available from the following website:

https://www.eynesbury.edu.au/current-students/essential-information/policies-procedures

Deliberate academic misconduct such as plagiarism is subject to penalties. Information about Academic integrity can be found in course website above.

Dispatcher is responsible for finding an available Ambulance Crew that can take the

case. The Dispatcher must consider the urgency of the case (e.g. Category 1 versus Category 2) as well as the closeness of the Ambulance Crew. If noone is available, the Dispatcher

must ask Ambulance Crews of who can be available.

Dispatchers are centralised to Headquarters spread around the state. There are dispatcher   Headquarters that handle central Adelaide, Northern, Southern, and Hills regions. Cases will be sent to the nearest Headquarters. On average, there will be 20 Ambulance Crews within  a Headquarter’sarea.

Response

Two Paramedics forman Ambulance Crew. An Ambulance Crew is assigned an Ambulance

for their shift. The Ambulance Crew will generally be on the road for their entire shift. Each ambulance will be equipped with a Mobile Data Terminal (MDT). The MDT will run the

system you are developing. The MDT will receive an assigned case from dispatch and tell the Ambulance Crew where the case is. It should give an indication of the type of case (e.g.

“Category 2: chest pain”).

One of the Paramedics in the Ambulance Crew will acknowledge the case. They will also signal when they are on route to the case. Paramedics will assess the cases onsite.

If the case is serious, the Ambulance Crew will transport the Patient to Hospital. They will

turn on lights and sirens if the case is Category 1. The Ambulance Crew must assess with

their general knowledge which Hospital can take the case. The system will need to inform

them of various issues at the hospital; whether a hospital is ramping (increasing , delayed,

CT machine is getting repaired). The system will also need to show the paramedics the latest policies and procedures when required. For example, what are the policies and procedures    around handling COVID-19.

All dates and times when key events happen must be permanently recorded for accountability and for Freedom of Information Act requests.

Paramedics work in shifts. There are four shifts a day (A, B, C, and D shift) to cover 24/7

support. Accordingly, there is no station manager. Instead, Team Leaders work in the shifts   and are responsible for operations during that shift. Any system must consider the tiredness of the users in these critical cases. Team Leaders need reports of Ambulance Crew usage during the shift.

Paramedical Emergency Response System Additional Information

The two current interfaces (dispatch and ambulance MDT) are pretty old.   They were

designed 25 years ago and have served well but there are lots of opportunities to improve them.

Ambulance MDT

The ambulances currently are fitted with full colour displays, GPS location, data network access.  But the software itself is legacy from previous system so is running as

a monochrome text-based interface on the full colour display.     Currently, the dispatcher sends the destination address to along with the particulars of the issue.

E.g.

12 Main Street

Mawson Lakes 5095

Call Back Number 0411000000

Whitehouse with Green Door.  Go into front door turn left.

Caller: Ellen Ripley

Presumptive Status: Zulu

Symptoms

Chest pains, Drowsiness, Alien Bursting from Chest

Other Notes

Presumptive Status example (this one was from Qatar Ambulance service)

Dispatcher

You can assume the existing dispatch system is a basic system that takes the data entered   by the 000 caller and puts it upon the dispatcher system.  The existing dispatch system has a list of ambulances with statuses.   The dispatcher looks at a filtered list of unallocated