Place Order

SYSTEM ANALYSIS & DESIGN: ASSIGNMENT

Table of Contents

 

1a: Stakeholders and Requirements: Stakeholders. 2

1b: Stakeholders and Requirements: Functional Requirements. 2

1c: Stakeholders and Requirements: FURPS+ Non-Functional Requirements. 5

2a: Use Case Modelling: User Goal Technique – Brief Descriptions. 6

2b: Use Case Modelling: User Goal Technique – Use Case Diagram.. 7

3: Use Case Modelling – Event Decomposition Technique. 8

4: Domain Modelling – UML Domain Model Class Diagram.. 13

 

1a: Stakeholders and Requirements: Stakeholders

Stakeholders Description
Investors and Owners They aim business to maximize profits. The investors focus on customer demands and experienced staff in the related field with suitable vehicles, land/buildings and systems to manage Eze-Mulch business efficiently.
Government Agencies The government agencies assess environmental protection as a major function. They help us in providing permit for handling waste management activities. They can also act as a client.
Customers/Individual /Schools /business They will use Eze-Mulch services to collect and dispose of waste. i.e, tree branches and leaves removed from homes, offices, stores etc.
Contractors The contractors will provide different services to clients on behalf of Eze-Mulch and company will pay them accordingly. The tree contractors will provide trees cutting and leaves collection based on demand of the clients.
Managers The managers will manage whole Eze-Mulch system online including assigning of clients/contractors, services and managing schedule.

 

1b: Stakeholders and Requirements: Functional Requirements

 

  1. User Registration
  • System will validate the format of email entered & also the existence of the email id, via the account activation process.
  • System will allow user to recover password, by answering security question OR by sending email to the alternate email, provided at the time of registration.
  • after X number of days, the system will delete “registered but not activated” users accounts (defined in the configuration)
  • System will send the “Activation reminder” email 24 hrs before deleting the account.
  • The system should validate all passwords that contain upper and lower case letters and numbers (Essential).
  • If user attempts to recover the password, system will send the link to change the password, instead of sending the password.
  1. User can be clients, tree contractors or managers having different system access priviledges.
  2. After getting login to the system clients can request quote from the tree contractor on the basis of services, they want i.e, pruning, load of mulch, load of firewood or to make their truck empty. As soon as the contractor generate a quote for the client; system will send email alert (clients can check by getting login to the system or via email).
  3. Tree contractors can access the Eze-Mulch system 24/7 to check the services clients requested.
  4. Eze-Mulch system automatically assign clients and contractors on the basis of the services requested and contractor’s availability.
  5. Calendaring and Scheduling
  • Eze-Mulch system will maintain schedule on daily basis to notify contractors about their next two days working time including location, role and truck status.
  • The managers will enter each contractor working/off days in the schedule.
  • The system will generate automatic alert message when all local contractors are busy and provides a list of substitute tree contractors with the URL in the alert message.
  • Eze-Mulch system will maintain record of all of its users including clients, contractors or management staff.
    • Clients can be individual schools, local government or businesses.
    • Management staff are managers to maintain the system.
  1. Text Messaging
  • Eze-Mulch system will use GPS system (Google maps) to send text messages to the contractors one day before the task to get performed and also on the morning to get their job done on time. Beside, GPS system will also provide the exact location of where the task has to be performed.
  • In case contractor is unable to fulfil the job, GPS system will sent a notification to the Eze-Mulch system which will assign a substitute contractor on the basis of substitute list available in the system.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1c: Stakeholders and Requirements: FURPS+ Non-Functional Requirements

  1. Functionality: Eze-Mulch system should be able to function properly on laptops, desktops, tablets and mobile phones.
  2. Usability
  • Eze-Mulch system shall provide mouse and keyboard navigation.
  • Eze-Mulch system shall be easy to navigate by using clear words, menus and drop-down lists.
  • Eze-Mulch system shall be accompanied with a user manual.
  1. Reliability: Eze-Mulch system shall be available 24 hours a day for application users.
  2. Performance: Eze-Mulch system shall not take longer than 15 seconds to respond to a page request for members; when using an internet connection that is 56k or higher
  3. Supportability: The Eze-Mulch system should be supportable in latest equipment’s such as computers, monitors, printers etc.

 

Implementation requirements

The software implementation will be performed on Friday evening to minimize impact. The implementation will be performed all on one day rather than in phases.

 

Physical Requirements

  • Hardware Requirements: Database Server, Web Server, Application Server

 

Interface Requirements

  • Hardware Interfaces: Monitor, keyboard, Mouse, Printer, Scanner, Camera
  • Software Interfaces: Browser: Mozilla Firefox, Opera, Google chrome
  • Operating System: windows 7,8,10
  • Tools & Technologies: PHP, MySql, Flash Plug-ins, Ajax, XML
  • Database: Mysql 5+
  • Communications Interfaces: Wireless network, mobile phone, desktop PC, notebook computer, iPad, smart phones etc.

 

2a: Use Case Modelling: User Goal Technique – Brief Descriptions

user User goal and resulting use case
User/Diver activate dive computer

view device time remaining (DTR)

check No Deco status

Check O2 Accumulation

View ASC br graph

View N2 bar graph

ON Conservative Factor (CF)

ON Deep Stop (DS)

ON Safety Stop (SS)

View battery

view warning level

view alarm level

select dive mode

select gauge mode

select free mode

select advance settings

select option

select menu

view menu

connect app

set alarm group

set utilities group

set time group

upload settings

download data

 

*These details are based on Aqua Lung Dive Computer.

 

 

 

 

 

 

 

 

 

2b: Use Case Modelling: User Goal Technique – Use Case Diagram

 

 

 

 

 

 

 

 

 

 

3: Use Case Modelling – Event Decomposition Technique

 

 

 

 

 

 

 

 

 

 

 

 

Actors Usecase Event Type of Event Brief Description
Customer Subscribe flight session 1.      The customer register and login into the system

2.      This usecase begins when the customer click “subscribe flight session”

a.      System prompts a message “subscribed successfully

b.      System will send a reminder text notification to the customer one week and one day before the session.

3.      The use case ends successfully.

 Primary This usecase will provide flight session details to the customers, when they are going to be happened including session date, duration, time, payment etc.
Customer Request flight session 1.      The customer login into the system

2.      This usecase begins when the customer “request flight session”

a.   System prompts a message to select either basic session or super session.

3.      The customer selects the desired session.

4.      The use case ends successfully.

 Primary The customer will have two options to select session from either basic or super session. The basic session is cheaper than super session while in super session customer will have the option to record illusions.
Customer Make tunnel booking 1.     The customer login into the system

2.     The customer selects flight session

3.     This usecase begins when the customer “make tunnel booking” via online or through FF centre.

4.         The use case ends successfully.

 Primary The customer can make tunnel booking via online or through FF centre but the tunnels are only booked to parties of four.
Customer Request client information 1.     The customer login into the system

2.     The customer selects flight session

3.     The customer “make tunnel booking” via online or through FF centre.

a.      System prompt to client information page

4.     The customer provides client information.

5.     The use case ends successfully.

 Primary To make tunnel booking customer will provide all the required details asked by the system to proceed.
Customer Select tunnels 1.     The customer login into the system

2.     The customer selects flight session

3.     The customer “make tunnel booking” via online or through FF centre.

4.     The customer provides client information.

5.     This usecse begins when the customer “select tunnels”.

a.      System will display a dropdown menu to select option either “Tunnel 1 & 2” or “Tunnel 3 & 4”.

6.     The customer selects the tunnel.

7.     The use case ends successfully.

 Primary The customer will select tunnels either Tunnel 1 & 2 or Tunnel 3 & 4. Tunnel 1 & 2 will provide basic flying experience while Tunnel 3 & 4 belongs to super flight session and will also include recording of imagery.
Trained staff, staff Accompanied flight session 1.      The customer login into the system

2.      The customer selects flight session and provide booking details.

3.      The staff assign trained staff from the list available to accompanied flight sessions.

4.      The use case ends successfully.

 Primary The staff will allocate trained staff from the list available. The trained staff must have first-aid training certificate, parachute instructor license and should pass medical exam.
Service engineer Inspect tunnel chamber 1.     This use case begins when service engineer “inspect tunnel chamber” before each session.

2.     The use case ends successfully.

 secondary To maintain customer safety before each session tunnel chamber will be inspected by a service engineer to check for chamber, control systems, physical damage, integrity of cleanliness and hygiene, any dropped belongings from the previous session, etc.
Service engineer Technical check of parachute equipment’s 1.     This use case begins when service engineer check technical working of parachute equipment’s before each skydiving session.

2.     The use case ends successfully.

 secondary The technical check made by the service engineer before each session will be recorded into the system.
Service engineer Mechanical check of tunnels 1.     This use case begins when service engineer mechanically check tunnels equipment’s daily.

2.     The use case ends successfully.

 secondary On daily basis mechanical working of the tunnels will be examined by the service engineer.
manufacturer Service tunnel engine 1.      This use case begins when manufacturer perform service of tunnel engine.

2.      The use case ends successfully.

 secondary The service will be performed after every 3 months or 50 hours of usage.
manufacturer Examine/

repair chamber turbine mechanism

 1.      This use case begins when manufacturer examine/repair chamber turbine mechanism.

2.      The use case ends successfully.

 secondary The examine/repair of chamber turbine mechanism will take 4 days to be fully repaired.
Staff Manage adhoc status report 1.     The staff will manage ad-hoc status report. Primary The ad-hoc status report will be based on each tunnel including its status, current hours of use and date of next scheduled service.
Staff Manage mechanical checks & services report 1.     The staff will manage mechanical checks & services report Primary This report will be send to tunnel manufacturer as a part of the maintenance agreement.
Staff Manage customer tunnel usage report 1.     The staff will manage customer tunnel usage report Primary This report will contain tunnels used by the customers.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

4: Domain Modelling – UML Domain Model Class Diagram

ICT284 assignment