School of Engineering ITECH2002 System Modelling Assignment 1 Project

This document presents a comprehensive solution for a system modelling assignment, likely for a course like ITECH2002. The solution encompasses various aspects of system analysis and design, including user stories, use case diagrams, and class diagrams. The document begins with user stories, outlining the needs and goals of different user roles, such as Gigster and Administrator. It then provides a user goal table, mapping user goals to specific use cases. A use case diagram visually represents the system's functionality, followed by detailed use case descriptions for actions like managing building records, sending fit-out requests, processing payments, and user sign-up. The solution also includes descriptions for querying bookings, submitting gig proposals, and managing tickets. Finally, a class diagram illustrates the system's structure and relationships between different components. The assignment demonstrates how to analyze and document system requirements using industry-standard techniques.

Running head: SYSTEM MODELLING
SYSTEM MODELLING
Name of the Student
Name of the University
Author Note

1SYSTEM MODELLING
Table of Contents
User Stories......................................................................................................................................2
User Goal Table for User Story.......................................................................................................2
Use Case Diagram...........................................................................................................................3
Use Case Description.......................................................................................................................3
Class Diagram for Sub-system......................................................................................................10
Bibliography..................................................................................................................................11

2SYSTEM MODELLING
User Stories
Gigster: As a G!gM@n@g3rs’ member, I can check available location based on dates so I can
book a space.
Acceptance criteria
1. Available spaces are displayed.
2. The duration of availability is calculated.
3. The duration of availability is displayed.
Administrator: As a G!gM@n@g3rs’ admin, I can check location, gagster and payment value
so I can inspect and manage ticket.
Acceptance criteria
1. The booking history is retrieved and displayed.
2. The gigster details are displayed.
3. The location details are displayed.
User Goal Table for User Story
User User Goals Resulting Use case
Gigster To make booking against a proposal for
space.
Submit gig proposal and
submit bookings
Administrator To inspect and manage tickets. Manage ticket and query
booking.

3SYSTEM MODELLING
Use Case Diagram
Figure 1: Use case Diagram
Source: created by author
Use Case Description
Use Case Name Manage building Record
Actor Owner
Description The owner of the company manages the building record according
to their facilities, lease details payment, location status etc.
Trigger event Building has been taken on lease

4SYSTEM MODELLING
Move in date set
Preconditions Owner must exist.
Building must exist.
Post conditions Status must change.
Priority High
Normal Course Admin contacts with the real estate agent
Get access in the system
Create every record for every building that they have leased.
System stores the record.
Changes the status of the building.
Alternative Course None
Includes Change Status, if the building gets occupied and vacant.
Extends None
Assumptions Owner have the full access of the system.
Use Case Name Send fit-out request
Actor Owner
Description The request for fit out of a newly acquired or modified
infrastructure of the building is sent to the fit-out specialist.
Trigger event Move in date set
Building is assessed to check it is operational or not.
Preconditions Specialist must exist.

5SYSTEM MODELLING
Owner must exist.
Building must exist.
Post conditions Fit out request must receive by the specialist.
Priority High
Normal Course State of the building assessed.
Owner checks the register of all listed specialist for fit out.
Sends the fit out request.
Alternative Course None.
Includes None
Extends None
Assumptions State of the building is unwell.
Email of the specialist is stored within the system.
Use Case Name Pay
Actor Owner
Description Payment is made against the services and rent of the building. The
payment is made in regular interval of time or for the each set of
services.
Trigger event Service has been acquired.
Meal has been acquired.
Technician has been hired.
Building is acquired.
Preconditions Owner must exist.

6SYSTEM MODELLING
Building must exist.
Fit-out specialist must exist.
Real-estate agents must exist.
Technician must exist.
Supplier must exist.
Post conditions Payment notification should be sent to the beneficiary email.
System should store the each payment record.
Priority High
Normal Course Owner inspects the services which has been done.
Owner updates the records with actual figures.
System updates the billing record.
Payment is done according to the records.
Alternative Course None.
Includes None.
Extends None.
Assumptions System updates the billing for each changes of records.
Use Case Name Sign up
Actor Gigster
Description For accessing the system for rental, user (gagster) needs to sign up.
Trigger event User needs to book place
Preconditions User must exist.

7SYSTEM MODELLING
User details must not exist in the system already.
Post conditions User should be able to log in.
User must check the available space.
Priority High
Normal Course Users go to the website.
Users enter their details to sign up.
System stores the record.
Alternative Course None
Includes None
Extends None
Assumptions User understands the website and sign up process.
Use Case Name Query Booking
Actor Admin
Description Admin can query the bookings according to the payment, location
and space.
Trigger event Admin needs to check payment history.
Admin needs to check location history for a gagster.
Admin needs to check available space.
Preconditions Admin must exists.
Booking must exist.

8SYSTEM MODELLING
Payment history must exist.
Location must exist.
Post conditions System must display the results.
Booking may get rejected.
Booking may get authorized.
Priority Moderate
Normal Course Admin queries the system.
System displays the results.
Admin rejects/authorizes the booking request.
Alternative Course None.
Includes None
Extends Reject and authorize
Assumptions Admin has the system privileges.
Use Case Name Submit Booking
Actor Gigster
Description Gigster applies a booking of the space for a gig proposal.
Trigger event Gigster needs a place.
Gigster has submitted proposal.
Preconditions Contracted Gig proposal must exist.
Gigster must exist.
Post conditions System stores the Booking.

9SYSTEM MODELLING
System flags the gig proposal.
Priority Moderate
Normal Course User checks the gig proposal is contracted or not.
Selects place and date.
Submits the booking request.
Alternative Course User changes the place and date.
Includes None
Extends None
Assumptions User have the privileges to check availability and book.
User can book more than one place.
Use Case Name Submit gig proposal
Actor Gigster
Description Gigsters submit their proposal with all the description of type,
technology used, market and potential.
Trigger event Gigster needs a place.
Preconditions Gigster must exist.
Postconditions Proposals must be stored in the system.
Priority Moderate
Normal Course Gigster sign in to the system.
Creates a proposal.
Submits the gig proposal.
Alternative Course None.

10SYSTEM MODELLING
Includes None.
Extends None.
Assumptions Gigsters have the privileges to submit.
Use Case Name Manage Ticket
Actor Admin
Description Admin creates the ticket or the system automatically raise a ticket
when component of the system gets malfunctioned.
Trigger event System has detected the malfunction.
Ticket has been raised.
Preconditions System must detect malfunctioning.
Sensors must exist.
Post conditions Ticket is raised.
Priority High
Normal Course System collects the sensors’ data.
Malfunctioning is detected.
Ticket is raised.
Alternative Course System collects the sensors’ data.
Malfunctioning detected.
Admin raise a ticket.
Includes None
Extends None

11SYSTEM MODELLING
Assumptions Sensors are working well.
The readings are correct.
Class Diagram for Sub-system
Figure 2: Class diagram
Source: created by author

12SYSTEM MODELLING
Bibliography
Al-Khiaty, M. A. R., & Ahmed, M. (2016). UML class diagrams: Similarity aspects and
matching. Lecture Notes on Software Engineering, 4(1), 41.
Dimitrijević, S., Jovanović, J., & Devedžić, V. (2015). A comparative study of software tools for
user story management. Information and software technology, 57, 352-368.
Petre, M. (2013, May). UML in practice. In 2013 35th International Conference on Software
Engineering (ICSE) (pp. 722-731). IEEE.
Schlee, C. (2013). Use Case Identification and Description. In Targeted Advertising
Technologies in the ICT Space (pp. 61-93). Springer Vieweg, Wiesbaden.
Vachharajani, V., Vasant, S., & Pareek, J. (2016). Feasibility Study of Proposed Architecture for
Automatic Assessment of Use-Case Diagram. In Proceedings of International
Conference on ICT for Sustainable Development (pp. 97-104). Springer, Singapore.
Wautelet, Y., Heng, S., Hintea, D., Kolp, M., & Poelmans, S. (2016, November). Bridging user
story sets with the use case model. In International Conference on Conceptual
Modeling (pp. 127-138). Springer, Cham.