Hire eScooter to explore Perth
Modelling Exercise
Assignment 2
Modelling Exercise
Hire eScooter to explore Perth
Modelling Exercise
This assignment is based on a running example over the different sections to provide a sense of coherence between the models like a real project. The format of this assignment is deliberately “open ended” to challenge critical thinking. In places you will need to make assumptions in order to make progress and anticipate problems in system operation. Find the scenario below.
Scenario
Hire eScooter to explore Perth
Perth’s public electric Scooter (eScooter) scheme is a newer and carbon footprint friendly way to explore the city with the first 30 minutes being free of charge. Available are over 100 docking stations and 500 eScooter for hire. The pricing starts at $2 AUD for 2 hours after the initial 30 minutes free of charge. After the first 2,5 hours, it costs an extra $2 AUD for each additional half an hour. eScooters can hired using a bank card at the docking station, or using the official Rent-an-eScooter app. They are available for hire 24/7, every day of a year. The scheme aims at supporting the users to travel around the city quickly and easily.
eScooters are available for hire at the docking-station terminal with a bank card or contactless payment card – just touch the screen and follow the instructions to begin. Getting started for the user is easy: simply hire an eScooter, ride it, and then return it to any of docking stations across the city once the user isn’t using it anymore so that no additional charges apply. eScooter can be hired as many times as the user wants it within the eScooter access period the user has purchased.
Rent-an-eScooter access fees:
- $2AUD for 2 hours
- $90 AUD annually (only available to registered members)
Rent-an-eScooter additional fees:
- $2 AUDfor every additional half hour (or partial half hour) after the first 5 hours.
Other charges: If the user doesn’t return the eScooter, or returns it back late or damaged, the user may be charged up to $300 AUD.
Hire eScooter to explore Perth
the Rent-an-eScooter app
The app, available on iPhones and on Android, is the only app to send eScooter-release codes straight to users phone. The user just downloads the app and registers for pay-as-you-pedal. Use the app to ‘hire now’ from a nearby docking station and get the release code. The user then taps the code into the docking point and enjoy the ride.
The app allows the user to also:
- see up-to-the-minute information about which docking stations have eScooters and spaces available
- plan a journey with an easy-to-follow map
- receive notifications summarising the cost at the end of their journey
- see the recent journeys and charges.
Required sections:
Section 1 – Identifying user stories
Identify the required user stories for the proposed system. List the user stories as well as their acceptance criteria. (10 marks)
Section 2 – Use case modelling
Derive the required use case diagram from the identified user stories (hint: you will need to identify the main processes the system must perform) – and document them to an appropriate level. (20 marks)
Section 3 – Activity diagram modelling
Create the required activity diagrams for the proposed system. (20 marks)
Section 4 – System Sequence Diagram
Choose the developed use cases and produce the relevant system sequence diagrams (30 marks)
Section 5 – Designing the user interface
Propose a user interface for the new system showing the relevant user interface interaction path for one user story/use case. (20 marks)
The assignment should be submitted in Blackboard and Turnitin as follows:
| Value: | 30% (Assignment will be marked on 100 and scaled to 30) |
| Format: | Group assignment (max. 4 people per group) that will require you to apply technical business analysis modelling skills to a set of case scenarios. |
| Due date & time: | 04 May ,2020 |
| How to submit: | Electronically, via Blackboard>Assessments > Assignment 2
|
| Format | PDF Document with ECU cover sheet |
NO LATE SUBMISSIONS WILL BE ACCEPTED
Completing this assessment will help you achieve some of the following learning outcomes
- Evaluate the implications of future trends in business systems analysis.
- Compare the effects of different national and organisational cultures on requirements.
- Critique appropriate strategies to use information systems to meet requirements.
- Apply stakeholder and communication theories to manage stakeholders and their communications needs.
Marking Rubrics:
| Criteria | Fail
| Pass Threshold | Credit | Distinction | High Distinction
|
| User stories 10%
| Irrelevant user stories that do not make sense logically and do not follow the user story pattern. Acceptance criteria are nonexistent or do not relate to the user story. | A few user stories have been identified. They follow the user story pattern but have broad mistakes. They are related to the case. Acceptance criteria are relevant but weak. | Some relevant user stories have been identified. They mostly follow the user story pattern but have major mistakes and are correct in general. Acceptance criteria for each user story apply to some extent. | The majority of relevant user stories have been identified. They all follow the user story pattern with some manor mistakes and are largely logically correct. Acceptance criteria applies logically to the user story in most cases. | All required user stories have been identified. They all follow the user story pattern and are logically correct. Acceptance criteria applies logically to the user story. |
| Use case modelling 20% | The use case diagram shows the wrong use cases or entirely irrelevant use cases. The diagram contains too many major modelling mistakes and does not follow UML notation in large parts. The use case descriptions are not detailed enough or are irrelevant or incorrect by not following the shown template. | The use case diagram shows only a fraction of use cases derived from the user stories. The diagram is modelled correctly according to UML notation, but contains major mistakes. The use case descriptions are logically correct but contain major mistakes. | The use case diagram shows the majority of use cases derived from the user stories. The diagram is modelled mostly correctly according to UML notation with some mistakes. The use case descriptions are logically correct with some mistakes only and mostly follow the shown template. | The use case diagram shows the majority of use cases derived from the user stories. The diagram is modelled correctly according to UML notation with some minor mistakes. The use case descriptions are logically correct with some minor mistakes only and follow the shown template. | The use case diagram shows all use cases derived from the user stories. The diagram is modelled correctly according to UML notation. The use case descriptions are logically correct and follow the shown template. |
| Activity diagram modelling 20%
| The activity diagram shows incorrect activities and the flow between them. The diagram contains too many major modelling mistakes and does not follow UML notation in large parts. The identified activities are not detailed enough. | The activity diagram shows mostly correctly identified activities. The flow is identified correctly with some major mistakes. The diagram contains some major modelling mistakes but follows UML notation in large parts. The identified activities are detailed correctly. | The activity diagram shows correctly identified activities with some mistakes. The flow is identified correctly with some mistakes. The diagram is modelled correctly and follows UML notation. The identified activities are detailed correctly. | The activity diagram shows correctly identified activities with some minor mistakes. The flow is identified correctly. The diagram is modelled correctly and follows UML notation. The identified activities are detailed correctly. | The activity diagram shows correctly identified activities and the flow. The diagram is modelled correctly and follows UML notation. The identified activities are detailed correctly. |
| System sequence diagram 30% | The SSDs are not logically derived from the requirements for most of its part. Entities are not meaningful and relevant for the action sequence of the system and have major mistakes. Actions and attributes are not meaningful and have major mistakes. The sequence is not logically correct. | The SSDs are logically derived from the requirements for only some parts. Only a few entities are meaningful and relevant for the action sequence of the system, with major mistakes. Most actions and attributes are meaningful, with major mistakes. The sequence is logically correct, stable and content. | The SSDs are logically derived from the requirements for most parts. Some entities are meaningful and relevant for the action sequence of the system, with some mistakes. All actions and attributes are meaningful, with some mistakes. The sequence is logically correct, stable and content. | The SSDs are logically derived from the requirements for most parts. Most entities are meaningful and relevant for the action sequence of the system, with some minor mistakes. All actions and attributes are meaningful, with some minor mistakes. The sequence is logically correct, stable and content. | The SSDs are logically derived from the requirements for most parts. All entities are meaningful and relevant for the action sequence of the system. All actions and attributes are meaningful. The sequence is logically correct, stable and content. |
| Designing the user interface 20% | The user interface does not correctly depict the interaction path for a defined user story/use case. Screen designs are not meaningful, hard to understand. Not showing relevant information, information show on the screen has not been derived from the requirement models. Screen flows through user interaction are not stable and not logically correct. | The user interface correctly depicts the interaction path for a defined user story/use case. Screen designs are understandable, showing mostly relevant information, but with major mistakes. Information show on the screen has mostly been derived from the requirement models but with major mistakes. Screen flows through user interaction are stable and logically correct for most paths. | The user interface correctly depicts the interaction path for a defined user story/use case. Screen designs are meaningful, showing relevant information with some mistakes. Information show on the screen has been derived from the requirement models, with mistakes. Screen flows through user interaction are stable and logically correct. | The user interface correctly depicts the interaction path for a defined user story/use case. Screen designs are meaningful, showing relevant information with some minor mistakes. Information show on the screen has been derived from the requirement models, with some minor mistakes. Screen flows through user interaction are stable and logically correct. | The user interface correctly depicts the interaction path for a defined user story/use case. The entire screen design is meaningful, showing all relevant information. All information show on the screen has been correctly and logically derived from the requirement models. All screen flows through user interaction are stable and logically correct. |
Completing this assessment will help you achieve some of the following learning outcomes:
- Assess business needs and processes and be able to effectively model them.
- Construct and interpret a variety of system description documents, including physical and logical data flow diagrams, entity-relationship diagrams, structured English, and decision tables/decision trees.
- Clarify effectively systems specifications and to be persuasive in these presentations.
