Business Modelling for Squeaky Surf: A System Design Project
VerifiedAdded on  2025/05/01
|18
|2458
|388
AI Summary
Desklib provides past papers and solved assignments for students. This project details the business modeling for Squeaky Surf.

MAN 5902
Assignment Part-B
Business Modelling
Student name:
Student id:
Assignment Part-B
Business Modelling
Student name:
Student id:
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Table of Contents
Introduction......................................................................................................................................4
Section-1: Identifying User Stories.................................................................................................5
Section-2: Use Case Modelling.......................................................................................................7
Section-3: Class diagram modelling..............................................................................................11
Section-4: Stage Machine Modelling............................................................................................12
Section-5: System sequence diagram............................................................................................13
Section-6: Designing user interface...............................................................................................15
Section-7: Modelling the database.................................................................................................16
Conclusion.....................................................................................................................................17
References:....................................................................................................................................18
Introduction......................................................................................................................................4
Section-1: Identifying User Stories.................................................................................................5
Section-2: Use Case Modelling.......................................................................................................7
Section-3: Class diagram modelling..............................................................................................11
Section-4: Stage Machine Modelling............................................................................................12
Section-5: System sequence diagram............................................................................................13
Section-6: Designing user interface...............................................................................................15
Section-7: Modelling the database.................................................................................................16
Conclusion.....................................................................................................................................17
References:....................................................................................................................................18

List of figures
Figure 1: Use case diagram..............................................................................................................7
Figure 2: Class diagram.................................................................................................................11
Figure 3: State Machine Modelling...............................................................................................12
Figure 4: Sequence diagram..........................................................................................................13
Figure 5: User interface.................................................................................................................15
Figure 6: ERD diagram..................................................................................................................16
List of Tables
Table 1: use case 1...........................................................................................................................7
Table 2: use case 2...........................................................................................................................8
Table 3: use case 3...........................................................................................................................9
Table 4: use case 4...........................................................................................................................9
Table 5: use case 5.........................................................................................................................10
Figure 1: Use case diagram..............................................................................................................7
Figure 2: Class diagram.................................................................................................................11
Figure 3: State Machine Modelling...............................................................................................12
Figure 4: Sequence diagram..........................................................................................................13
Figure 5: User interface.................................................................................................................15
Figure 6: ERD diagram..................................................................................................................16
List of Tables
Table 1: use case 1...........................................................................................................................7
Table 2: use case 2...........................................................................................................................8
Table 3: use case 3...........................................................................................................................9
Table 4: use case 4...........................................................................................................................9
Table 5: use case 5.........................................................................................................................10
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

Introduction
Squeaky Surf is a business company that provides different kinds of skateboards for the rental
and the company is operating at seven different beaches in the south of WA (Western Australia).
There are different types of boards such as Fun board, Gun board, etc. available in each location
of the company. They also provide SUP (Stand-up paddle) boards such as surf, race, flatwater,
etc. these boards are available in all sizes from children to adults and also in variants of men and
women. The customer who rents the boards must return it on the same day or the duration for
which they hire the boards. But the company is facing some problems because the customer hires
the board from one location but return it to the another which creates overstock at one location
and understock at others. To resolve this problem, the company is planning to develop a new
system that will notify about the availability of the boards, allow customers to make payment
online that will help the company. This report explains the user stories to determine the
requirements for the new system, use case diagrams, sequential diagram. User interface is also
designed in this report to understand the functionality of the new system.
Squeaky Surf is a business company that provides different kinds of skateboards for the rental
and the company is operating at seven different beaches in the south of WA (Western Australia).
There are different types of boards such as Fun board, Gun board, etc. available in each location
of the company. They also provide SUP (Stand-up paddle) boards such as surf, race, flatwater,
etc. these boards are available in all sizes from children to adults and also in variants of men and
women. The customer who rents the boards must return it on the same day or the duration for
which they hire the boards. But the company is facing some problems because the customer hires
the board from one location but return it to the another which creates overstock at one location
and understock at others. To resolve this problem, the company is planning to develop a new
system that will notify about the availability of the boards, allow customers to make payment
online that will help the company. This report explains the user stories to determine the
requirements for the new system, use case diagrams, sequential diagram. User interface is also
designed in this report to understand the functionality of the new system.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Section-1: Identifying User Stories
The user stories describe the types of users and their needs like what they need and user stories is
required as it helps in identifying the requirements for a system. For the organization Squeaky
Surf, the user stories are:
1. Customers:
User story:
As a customer, I want to hire the boards as per the requirement from one place and return
back it.
Acceptance criteria:
1. Customer must be registered.
2. The boards must be available on the specified location.
3. The system must check the availability of the boards.
4. The system must show the types of boards.
5. Customer must deposit the deposit amount.
User story:
As a customer, I want to have the payment functionality since there is no bill splitting at
this time.
Acceptance criteria:
1. The total amount must be shown depending on the number of boards rented.
2. Payment bill must be displayed according to the rental category.
3. Bill should be split after returning the boards.
Customer should deposit the amount of $150.
User story:
As a customer, I want to have the feedback form so that I can provide the condition of the
board.
Acceptance Criteria:
1. Feedback form must be handed to each customer after returning the board.
Customer must fill all the criteria of the feedback form (Max, 2018).
The user stories describe the types of users and their needs like what they need and user stories is
required as it helps in identifying the requirements for a system. For the organization Squeaky
Surf, the user stories are:
1. Customers:
User story:
As a customer, I want to hire the boards as per the requirement from one place and return
back it.
Acceptance criteria:
1. Customer must be registered.
2. The boards must be available on the specified location.
3. The system must check the availability of the boards.
4. The system must show the types of boards.
5. Customer must deposit the deposit amount.
User story:
As a customer, I want to have the payment functionality since there is no bill splitting at
this time.
Acceptance criteria:
1. The total amount must be shown depending on the number of boards rented.
2. Payment bill must be displayed according to the rental category.
3. Bill should be split after returning the boards.
Customer should deposit the amount of $150.
User story:
As a customer, I want to have the feedback form so that I can provide the condition of the
board.
Acceptance Criteria:
1. Feedback form must be handed to each customer after returning the board.
Customer must fill all the criteria of the feedback form (Max, 2018).

2. Staff Members
User Story:
As a staff member, I want to pick up the board so that I can relocate it to the location where
it is needed.
Acceptance Criteria:
1. The location where boards are understock must be displayed by the system.
2. The location where boards are overstock must be displayed by the system.
3. The system must notify that the rental duration of the board.
User Story:
As a staff member, I want to check the feedback form filled by the customer.
Acceptance Criteria:
1. Customer must fill the feedback form.
2. All the information related to the specified board must be linked to it.
3. Record of each board must be kept by the system (Roman, 2016).
3. Manager
User Story:
As a manager, I want to review the feedback and the board’s working condition so that bad
boards can be avoided and replaced.
Acceptance Criteria:
1. Feedback form must be filled out by the customers.
2. The system must record the history of every board (Max, 2016).
User Story:
As a staff member, I want to pick up the board so that I can relocate it to the location where
it is needed.
Acceptance Criteria:
1. The location where boards are understock must be displayed by the system.
2. The location where boards are overstock must be displayed by the system.
3. The system must notify that the rental duration of the board.
User Story:
As a staff member, I want to check the feedback form filled by the customer.
Acceptance Criteria:
1. Customer must fill the feedback form.
2. All the information related to the specified board must be linked to it.
3. Record of each board must be kept by the system (Roman, 2016).
3. Manager
User Story:
As a manager, I want to review the feedback and the board’s working condition so that bad
boards can be avoided and replaced.
Acceptance Criteria:
1. Feedback form must be filled out by the customers.
2. The system must record the history of every board (Max, 2016).
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

Section-2: Use Case Modelling
Figure 1: Use case diagram
Full description of all use cases
Table 1: use case 1
Use Case Name Board Rents
Scenario Customers need to rent the board.
Triggering
event
Registration should be done to rent the board.
Explanation Customer can rent the boards by registering themselves and make
payment along with the deposit amount
Actors Customers
Related use case Payment
Stakeholders Staff members
Figure 1: Use case diagram
Full description of all use cases
Table 1: use case 1
Use Case Name Board Rents
Scenario Customers need to rent the board.
Triggering
event
Registration should be done to rent the board.
Explanation Customer can rent the boards by registering themselves and make
payment along with the deposit amount
Actors Customers
Related use case Payment
Stakeholders Staff members
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Precondition Boards must be available.
Payment functionality must be available.
Postcondition Customer account must be created.
Account must be linked with the customer.
Deposit amount must be refunded.
Activity Flow Actor System
1. Customer needs to make the
account.
2. Customer should make the
payment
1.The system should create the
account of customers.
2. The system should check the
availability of the boards.
Exception
Conditions
Credit/debit card details are not valid for making payment (Scott,
2018).
Table 2: use case 2
Use Case Name Payment
Scenario Customer needs to make the payment
Triggering event Payment should be done to rent the board.
Explanation The customer makes the payment via debit/credit card to rent the
board and to submit the deposit amount.
Actors Customers
Related use case -
Stakeholders Customers, system admin
Precondition All the details must be entered
Post condition Payment credentials must be valid
Activity Flow Actor System
1.Select payment method
mode.
2. A customer fills all the
payment details.
3. Click the submit button to
make the payment.
1. The system should display the
different method mode.
2. The system must enter all the
information.
3. The system must generate the
payment slip.
Exception
Conditions
Credit/debit card details are not valid for making payment.
Use Case Name Add/Repair boards
Scenario Repairing and adding of boards
Triggering event Damaged boards should be notified
Explanation Boards that are damaged should be notified and add other if
necessary and to the location where it is overstock
Actors Staff Member
Related use case Feedback, Notify overstock and understock boards.
Stakeholders Staff Members, customers, system admin
Payment functionality must be available.
Postcondition Customer account must be created.
Account must be linked with the customer.
Deposit amount must be refunded.
Activity Flow Actor System
1. Customer needs to make the
account.
2. Customer should make the
payment
1.The system should create the
account of customers.
2. The system should check the
availability of the boards.
Exception
Conditions
Credit/debit card details are not valid for making payment (Scott,
2018).
Table 2: use case 2
Use Case Name Payment
Scenario Customer needs to make the payment
Triggering event Payment should be done to rent the board.
Explanation The customer makes the payment via debit/credit card to rent the
board and to submit the deposit amount.
Actors Customers
Related use case -
Stakeholders Customers, system admin
Precondition All the details must be entered
Post condition Payment credentials must be valid
Activity Flow Actor System
1.Select payment method
mode.
2. A customer fills all the
payment details.
3. Click the submit button to
make the payment.
1. The system should display the
different method mode.
2. The system must enter all the
information.
3. The system must generate the
payment slip.
Exception
Conditions
Credit/debit card details are not valid for making payment.
Use Case Name Add/Repair boards
Scenario Repairing and adding of boards
Triggering event Damaged boards should be notified
Explanation Boards that are damaged should be notified and add other if
necessary and to the location where it is overstock
Actors Staff Member
Related use case Feedback, Notify overstock and understock boards.
Stakeholders Staff Members, customers, system admin

Precondition The boards should be damaged
Postcondition The boards repaired must be in good working condition.
Activity Flow Actor System
1. Staff member checks the
customer’s feedback form.
2. Staff member checks the
damaged board.
3. Repair the damaged one
and add the new boards at
understock location.
1. The system must notify about
the customer feedback.
2.The system must notify the
damaged board.
3. The system must notify the
location where boards are
understock.
Exception
Conditions
The repaired boards will still not be working properly.
Table 3: use case 3
Use Case Name Feedback
Scenario Feedback form to check the quality of boards
Triggering event Feedback form must be fill
Explanation To check the quality and working condition of the boards, customer
should fill the feedback form at the time of rent.
Actors Customers
Related use case Board rent
Stakeholders Customers, staff member
Precondition Customer must rent the board
Postcondition Customer must fill the feedback form after using the board
Activity Flow Actor System
1.The customer fills the feedback
form.
1.The system should provide
the feedback form
Exception
Conditions
Feedback form would not have been filled properly.
Table 4: use case 4
Use Case Name Check feedback form
Scenario Checking the feedback form
Triggering event To determine the boards, the form must be checked
Explanation The feedback form which is being filled by customer must be
checked by the staff member in order to determine the condition of
boards.
Actors Staff members
Related use case Feedback
Stakeholders Staff members, customers, and Manager
Precondition The form should be filled by the customer
Postcondition The form must be checked by the staff members
Postcondition The boards repaired must be in good working condition.
Activity Flow Actor System
1. Staff member checks the
customer’s feedback form.
2. Staff member checks the
damaged board.
3. Repair the damaged one
and add the new boards at
understock location.
1. The system must notify about
the customer feedback.
2.The system must notify the
damaged board.
3. The system must notify the
location where boards are
understock.
Exception
Conditions
The repaired boards will still not be working properly.
Table 3: use case 3
Use Case Name Feedback
Scenario Feedback form to check the quality of boards
Triggering event Feedback form must be fill
Explanation To check the quality and working condition of the boards, customer
should fill the feedback form at the time of rent.
Actors Customers
Related use case Board rent
Stakeholders Customers, staff member
Precondition Customer must rent the board
Postcondition Customer must fill the feedback form after using the board
Activity Flow Actor System
1.The customer fills the feedback
form.
1.The system should provide
the feedback form
Exception
Conditions
Feedback form would not have been filled properly.
Table 4: use case 4
Use Case Name Check feedback form
Scenario Checking the feedback form
Triggering event To determine the boards, the form must be checked
Explanation The feedback form which is being filled by customer must be
checked by the staff member in order to determine the condition of
boards.
Actors Staff members
Related use case Feedback
Stakeholders Staff members, customers, and Manager
Precondition The form should be filled by the customer
Postcondition The form must be checked by the staff members
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

Activity Flow Actor System
1. Customer fills the feedback form.
2. Staff member checks the form
regularly.
3. The manager checks the form
after 6 months
1. System must provide the
feedback form.
2The system must notify the
form.
Exception
Conditions
The feedback form will not properly be checked by the members
(Scott, 2018).
Table 5: use case 5
Use Case Name Notify overstock and understock boards
Scenario Notification of boards availability
Triggering event The location where boards are available or not
Explanation To check the availability of the boards, the system notifies the
location where the boards are overstock and understock.
Actors System admin
Related use case Feedback, check feedback form
Stakeholders Customers, staff members, and manager
Precondition All location must be checked
Postcondition Identify the location where it is understock or overstock
Activity Flow Actor System
1. System admin checks all the
location.
2. Admin can check the location
where it is understocked and
overstock.
1.The system must provide
the availability of boards at
all location.
2. System must notify the
location where boards are
overstock and understock.
Exception
Conditions
The system provides wrong information
1. Customer fills the feedback form.
2. Staff member checks the form
regularly.
3. The manager checks the form
after 6 months
1. System must provide the
feedback form.
2The system must notify the
form.
Exception
Conditions
The feedback form will not properly be checked by the members
(Scott, 2018).
Table 5: use case 5
Use Case Name Notify overstock and understock boards
Scenario Notification of boards availability
Triggering event The location where boards are available or not
Explanation To check the availability of the boards, the system notifies the
location where the boards are overstock and understock.
Actors System admin
Related use case Feedback, check feedback form
Stakeholders Customers, staff members, and manager
Precondition All location must be checked
Postcondition Identify the location where it is understock or overstock
Activity Flow Actor System
1. System admin checks all the
location.
2. Admin can check the location
where it is understocked and
overstock.
1.The system must provide
the availability of boards at
all location.
2. System must notify the
location where boards are
overstock and understock.
Exception
Conditions
The system provides wrong information
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Section-3: Class diagram modeling
Figure 2: Class diagram
The figure which is shown above represents the modeling of the class diagram. Basically, it is a
structure diagram used to define the structure of the system. For the organization Squeaky Surf, a
class diagram is created for its new system that the company needs to implement and use. The
classes, operators, and its attributes are shown in the class diagram along with the relationship
among them. All the classes are arranged in such a way that it brings the common characteristics.
As shown in the figure, the top part represents the name of the class and the below rows
represents the attributes of the class. The class Adult and Children are the inheritance class of
Customer class while class Stands up paddle and Surf are inheritance class of class Board stock
Figure 2: Class diagram
The figure which is shown above represents the modeling of the class diagram. Basically, it is a
structure diagram used to define the structure of the system. For the organization Squeaky Surf, a
class diagram is created for its new system that the company needs to implement and use. The
classes, operators, and its attributes are shown in the class diagram along with the relationship
among them. All the classes are arranged in such a way that it brings the common characteristics.
As shown in the figure, the top part represents the name of the class and the below rows
represents the attributes of the class. The class Adult and Children are the inheritance class of
Customer class while class Stands up paddle and Surf are inheritance class of class Board stock

and it is represented with the triangle shape. Admin is the main class and all remaining classes
are its part, hence it shows the aggregation among them (Margarete, n.d.).
Section-4: Stage Machine Modelling
Figure 3: State Machine Modelling
A state machine is a model used to show the single object and helps in understanding the state of
the object that affects the reactions to the activities or an event. An event is the activity occurs at
a certain time and there is no duration for the occurrence of the event. The diagram which is
shown above represents the state machine modeling for the company Squeaky Surf, where it is
showing the events of the company. For this company, there are seven states namely rent boards,
check stock, select type, understock type, add new boards, make a payment, and return the
boards. These states are represented by the rounded corners rectangles and the arrow represents
the transition of one state into another state. The solid black circle as shown in the figure
represents the starting state and the terminating state of the state machine model (de et al. 2017).
are its part, hence it shows the aggregation among them (Margarete, n.d.).
Section-4: Stage Machine Modelling
Figure 3: State Machine Modelling
A state machine is a model used to show the single object and helps in understanding the state of
the object that affects the reactions to the activities or an event. An event is the activity occurs at
a certain time and there is no duration for the occurrence of the event. The diagram which is
shown above represents the state machine modeling for the company Squeaky Surf, where it is
showing the events of the company. For this company, there are seven states namely rent boards,
check stock, select type, understock type, add new boards, make a payment, and return the
boards. These states are represented by the rounded corners rectangles and the arrow represents
the transition of one state into another state. The solid black circle as shown in the figure
represents the starting state and the terminating state of the state machine model (de et al. 2017).
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide
1 out of 18
Related Documents

Your All-in-One AI-Powered Toolkit for Academic Success.
 +13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
Copyright © 2020–2025 A2Z Services. All Rights Reserved. Developed and managed by ZUCOL.