Reference no: EM133662163

Systems Analysis and Design

Task - Requirements Analysis, Use Case and Activity Diagram

Task description: In this Assignment, you will take what you have learnt in weeks 1, 2 and 3 and apply this to a case. You will critically review a set of requirements and diagrams in one case, and demonstrate your understanding of a second case by creating a Requirements Matrix, a Use Case Diagram and an Activity Diagram. You will also justify your designs in short descriptions accompanying each of these outputs.

Task overview

Read the Criterion-Referenced Assessment Rubric at the end of this document.

Note: there are two cases in this assignment - (Sample) Case 1 relates to steps 2-5 below, and Case 2 relates to steps 6-11.

View the Sample Requirements list, Sample Use Case Diagram and Sample Activity Diagram for Case 1 (below).

For the Sample Requirements list, identify four (4) errors. For each error, list the requirement from the list that the error occurs in, and describe what the error is and why it is an error.

Each error description should only be 1-2 sentences and can be listed as dot points or in table format

Example format: Requirement: [list requirement] Error: [describe error, e.g., misses X, or is not Y, or does not follow principle Z, etc.], this is an error because [describe the affect the error has on the usefulness of the requirement, referring to the SMART principles]

For the Sample Use Case Diagram, identify four (4) errors. For each error, list the specific Use Case(/s) and/or relationship between Use Cases and/or other feature of the diagram that the error relates to, describe what the error is and why it is an error.

Each error description should only be 1-2 sentences and can be listed as dot points, in table format or as an annotation to a copy of the diagram

For the Sample Activity Diagram, identify four (4) errors. For each error, list the specific Activity(/s) and/or shape(/s) between Activities and/or other feature of the diagram that the error relates to, describe what the error is and why it is an error.

Each error description should only be 1-2 sentences and can be listed as dot points, in table format or as an annotation to a copy of the diagram

Read Case (below).

Develop a new Requirements Matrix to show the functional requirements of the system that would fall under subsystems User Interface, Scooter and Bike Management, and Payment Management. Aim for:
15 Essential Functional Requirements
5 Desirable Functional Requirements
1 Optional Functional Requirement

You should include the suggested number for each priority of requirements, totalling around 21 Functional Requirements in your matrix. A small amount less or more may be ok depending on the quality of the ones you include, but you will need to stay around the number stated above. Whilst each will have certain priority, and the list may not be comprehensive, you need to ensure that all are relevant to the case and are concise, specific, measurable and actionable. You will also need to define 2 modules within each of the above subsystems and include these in your matrix.

Draw 1 (one) Use Case Diagram capturing how actors interact with the system across the range of important functions available in the system (focus on the ones described in the case description).

Aim to include around 15-20 Use Cases in your diagram (no more than 23). Ensure that the use cases you do include are important and relevant to the system being represented.

Remember to include relevant relationships between elements of the diagram such as use cases and actors, and use cases and other use cases

Describe your Use Case Diagram by answering the below 3 questions (2-3 sentences each):

Pick one extends or includes relationship in your diagram (be specific) and justify why you have drawn it as an extends or includes relationship

Describe one actor in terms of where they interface with the system, based on your diagram

c) Note the aspects of the wider system that are out of scope of your diagram and justify why

Draw an Activity Diagram, representing how a rider would find and rent an e-scooter for transit from one point to another, and, assuming the e-scooter's battery became nearly empty, how a "juicer" would be involved and complete tasks relevant to them (as described in the case).

Remember to balance detail with clarity in your diagram. Take note of the following guidelines regarding scope:

Use around 2-3 swimlanes to differentiate system activities initiated by different actors. For activities performed by a subsystem with no interaction with an actor, you may use a separate "system" swimlane, however, ensure all other activities performed in actor swimlanes describe system interactions.

Use up to 40 shapes (shapes include activities, boxes, decision nodes, fork and joins, start and end nodes, etc. but does not include arrows) to show the process of user activities.

Use decision nodes two or three times and fork and join two or three times in your model.

Preferably, your activity diagram will be vertical, rather than horizontal (this will make it easier when merging it into the submission PDF).

Describe your Activity Diagram by answering the below 3 questions (2-3 sentences each):

Pick a fork and join in your diagram (be specific) and justify why it is a fork and join (i.e., why is it necessary and why does it need to be depicted in this way to accurately illustrate this part of the flow)

Pick a decision node in your diagram (be specific) and justify why it is a decision node (i.e., why is it necessary and why does it need to be depicted in this way to accurately illustrate this part of the flow)

Describe aspects that may occur before your start node or after your end node that are out of scope of your diagram and justify why.