Quezada, Marcos

Halilaj, Ngadhnjim

OMIS 675

LAB7

10/23/16

Summary

Housing Maintenance Ticketing System. The purpose of this document is to lay out the system's functionality. Including functional and non-functional requirements, use cases and wireframes.

Functional requirements

This section shows the system's main functional requirements.

·       Create tenant's account

·       Login into tenant's account

·       Update tenant's profile

·       List tenant's tickets

·       Tenant, Admin and Maintenance Staff (users) can open a maintenance ticket

·       While opening a ticket the user can attach images

·       Admin and Maintenance Staff can change ticket's status

·       Admin and Maintenance Staff can add tools and/or parts to the ticket

·       Admin, Maintenance Staff and Tenant can view the status of a maintenance ticket

·       Admin can generate reports

Non-functional requirements

This sections shows the system's non-functional requirements and their corresponding areas.

Documentation

Create a user manual for the Tenant, Admin and Maintenance Staff.

Fault tolerance

Data should be backed up weekly on a cloud storage service provider.

Interoperability

Generated reports should be compatible with Microsoft Excel.

Maintainability

Web solution should be updated at least once a year to maintain compatibility with platform as a service provider.

Portability

Web solution should be portable to all main platform as a service providers including Amazon, SoftLayer and Microsoft Azure

Response time

CRUD ticket operations should happen within two (2) seconds.

Robustness

Web solution availability should be 99.9%.

Security

Client/Server communication should be encrypted.

Supportability

Web solution helpdesk ticket should be responded within 24 hours and assigned one of the following resolution time flags:

·       Same day (24 hours)

·       Next Business Day (48 hours)

·       No resolution time expected

Use case diagram

This section shows the general use case diagram and a Cockburn's casual descriptions for two of the main use cases.



Open ticket

Cockburn's casual description for the open ticket use case.

Title

Open ticket

Primary Actor

Tenant. Admin and Maintenance Staff are secondary actors for this use case.

Scope

Level

Story

Tenant creates a maintenance ticket.

Tenant selects 'Subject' from a list of possible issues. If the subject is not found in the list, Tenant can select 'Other' and explain the issue in the ticket's description.

Tenant selects 'Unit', 'Room' and 'Priority'

Tenant attaches files.

Tenant submits ticket.

Tenant receives a confirmation message with a ticket number.

Tenant receives an email with the content of the opened ticket.

 

Manage ticket

Cockburn's casual description for the manage ticket use case.

Title

Manage ticket

Primary Actor

Admin. Maintenance Staff is secondary actor for this use case.

Scope

Level

Story

Admin lists all tickets and can filter the list by 'Subject', 'Unit', Dates, 'Priority' and 'Status'

Admin can inspect the content of the ticket by clicking on one.

Admin can perform three tasks related to each ticket 'Update', 'Reply' and 'Close'.

Admin updates ticket status from a drop down list. Options available are 'Pending', 'Assigned' and 'Solved'.

Admin assigns ticket to maintenance staff user.

Status changes generate email to Tenant with the description of the status an …

Scope and level use case reference keys

Scope

Icon

Level

Icon

Organization (black-box)

Filled house

Very high summary

Cloud

Organization (white-box)

Empty house

Summary

Flying kite

System (black-box)

Filled box

User goal

Waves at sea

System (white-box)

Empty box

Subfunction

Fish

Component

Screw or bolt

Too low

Seabed clam-shell

Wireframes

This section shows four (2) wireframes for the main four use cases of the system.

Open ticket

Admin manage ticket

Admin reply

Staff manage ticket

See report on Nim's page

Download report