Place Order

ICT284 Systems Analysis and Design

 

Q Task Possible

marks
1a Stakeholders and Requirements: Stakeholders 5/10
1b Stakeholders and Requirements: Functional requirements 7/10
1c Stakeholders and Requirements: FURPS+ Non-functional requirements 7/10
2a Use case modelling: user goal technique – brief descriptions 3/10
2b Use case modelling: user goal technique – Use case diagram 7/20
3 Use case modelling – event decomposition technique 3/20
4 Domain modelling – UML domain model class diagram 8/20
GEN Presentation including layout, formatting, grammar and spelling check
TOTAL MARKS 40/100

  

Question 1: Stakeholders Requirements

Introduction

Based on the case study of MulchNetwork which is a green waste recycling business its business processes can be automated to produce Eze-Mulch information system. The primary goal of this automation is to ensure that the whole process of assigning clients and contractors have been made easier and convenient. Additionally, this can allow clients to have an advance notice on when to receive the products they have ordered from the contractor as well as enabling both the client and the contractor to keep track of the delivery of such products. With this automation, the contractor can clearly know the work schedule and the postal codes to use when disbursing the products ordered by the client. Automation of this business process can go along the way to serve different types of clients i.e. individuals, corporates, among others. This paper provides system analysis and design overview for the implementation of Eze-Mulch information system.

  • List of the Stakeholders for the Proposed Eze-Mulch

Implementation of Eze-Mulch system will comprise of different stakeholders, each having his/ her own interest. Such stakeholders include the owner (MulchNetwork), who will represented by the manager. The second stakeholder is system requirement analyst, system developers, and software tester. This can be explained further as follows:

  1. Owner (MulchNetwork)-In the implementation of Eze-Mulch System, the interest of the project owner will be represented by the manager, who will be keen in ensuring that the proposed system has been implemented in accordance with the requirements set. The manager will also act as a project manager and ensure that planning, preparing of the schedule, and resource allocation have been done promptly.
  2. System requirement analyst will be concerned with determining the needs for the implementation of the system, acting as a liaison between the manager and development team.
  • Software developers-The main interest of software developers is to ensure that they have delivered they proposed system within the given timeline, and in accordance with the requirements.
  1. Software tester-Software tester play a critical role in application development. He/ she will be solely responsible in designing tests scenarios for Eze- Mulch system.

You should focus more on the non IT side stakeholder because they have more impact to the system

  • Functional Requirements for Eze-Mulch System

Functional requirements are part of system analysis and they define what the system should do. Additionally, functional requirements provide a description of the services that should be offered by a system. The following are the notable functional requirements for Eze-Mulch system:

  1. The system should allow client and contractor to register for the services offered.
  2. The system should allow the client to order a product from the contractor.
  • The system client should send an advance notice on when to receive the product ordered.
  1. The system should allow the contractor to view the work schedule for every day.
  2. The system should have calendaring feature for scheduling purposes.
  3. The system should have messaging feature for notification purposes for both client and contractor. (Should be able to send reminder messages for the scheduled messages).
  • The system should be incorporated with Google maps to show the location of the job and direction.

There should be more

  • Non-functional Requirements

FURPS is an approach for validating the prioritized requirements after having an understanding with the client requirements. Ideally, FURPS+ technique make the             requirements classification to focus on understanding of different types of non-functional requirements

  1. Security: The system should provide a high level of security to the personal information entered by client or contractor.
  2. Reliability: The system should be highly reliable in terms of performance and should provide the expected results.
  • Maintainability: the system should accommodate continuous refinement to make it better as the technology advances.
  1. Scalability: the system can handle the growing amount of work by adding the required resources. Eze-Mulch system will be developed in a way that it will accommodate the future growth to make it better.

You should have followed URPS+ , you missed some of the classifications

Requirements and system implementation requirements for Eze-Mulch can be described using the diagram below.

 

 

 

 

Question 2: Use Case Modelling: User Goal Technique

Functional requirements for use case modelling for new dive      computer to be worn in the wrist include the following:

  1. System should allow user/ diver to measure the time and depth during diving.
  2. The system should allow user to calculate and display an ascent profile.
  • The system should use decompression algorithm to indicate the remaining time.
  1. The system should through the use of audible alarms warn divers when surpassing the no-stop limit.
  2. The system should show recommendations of ascent rate or other limits beyond which there is an increase in the risk.
  3. The system should enable mounting of the dive computers
  • The system should allow user to add, modify, or remove settings via the dive computers.
  • The system should allow user to receive dive data during and after dive
  • List of use case name and an informative description
Use Case Description
Name Receive Dive Data
Description It allow measuring of time and depth during diving
Actors Diver/ wrist watch owner
Primary Scenario 1.     Measure the time and depth.

2.     Search for dive data during dive

3.     Search for dive data after dive

4.     Receive dive data during and after dive

Your presentation is not exactly what the question wanted. Your answer only mention 1 use case with 4 included use cases.

  • Draw a use case diagram representing the same information

If to follow (a) answer, there should be included use case here. There are also additional use cases. Hence marks only awarded for title + user + automation boundary and notations. You should also include a legend

 

Question 3: Use Case Modelling-Event Decomposition Technique

In the application of use case modeling-event decomposition, this technique is used to identify use case at sufficient level of details. In deriving the table capturing via use case modelling event decomposition, one must make a list of each external events making list of states events, identifying and making the name of the use case for each state and temporal event. Additionally, it is important to identify and make the name of the use case for each state events that require change of system status.

Event Type of event Use case Brief Description Actors (Only for External Events)
Checking the availability Primary Bookinginvalid use case name Customers check the availability of service and proceed to do booking Customer
Customer wants to cancel booking Secondary Booking invalid use case name Customer cancel the booked servicetoo brief Customer
Staff checks the safety of the customers Primary Perform checks Staff do inspection  of the control systems to ensure safety       what happen next? Staff
Admin wants to view adhoc status report Primary Print Reports Admin view can view adhoc status report from the new system, and information relating to mechanical checks  and services Admin

 

Far too few

Question 4: Domain Modelling

Inappropriate title

Missing multiplicity

Booking details?

The attributes may not be enough to support the case

 

 

References

Adams, K. M. (2015). Nonfunctional requirements in systems analysis and design (Vol. 28). Cham, Switzerland: Springer international publishing.

Klimek, R., & Szwed, P. (2010). Formal analysis of use case diagrams. Computer Science, 11, 115-131.

paper