Software Requirements Specification for Squeaky Surf's Rental System
VerifiedAdded on  2025/04/30
|23
|3306
|414
AI Summary
Desklib provides past papers and solved assignments. This project details the design of Squeaky Surf's board rental system.

Assignment 1 5902
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Contents
Introduction...........................................................................................................................................3
User stories............................................................................................................................................4
Use case Modelling...............................................................................................................................6
Use case description..........................................................................................................................6
Class Diagram Modelling....................................................................................................................13
State Machine Modelling.....................................................................................................................15
System Sequence Diagram..................................................................................................................16
Modelling the database........................................................................................................................19
Conclusion...........................................................................................................................................20
References...........................................................................................................................................21
Introduction...........................................................................................................................................3
User stories............................................................................................................................................4
Use case Modelling...............................................................................................................................6
Use case description..........................................................................................................................6
Class Diagram Modelling....................................................................................................................13
State Machine Modelling.....................................................................................................................15
System Sequence Diagram..................................................................................................................16
Modelling the database........................................................................................................................19
Conclusion...........................................................................................................................................20
References...........................................................................................................................................21

List of figures
Figure 1: Use case Diagram...................................................................................................................7
Figure 2: Class diagram.......................................................................................................................14
Figure 3: State machine modeling.......................................................................................................16
Figure 4: System sequence diagram....................................................................................................17
Figure 5: ER diagram..........................................................................................................................20
List of tables
Table 1: Use case description 1.............................................................................................................7
Table 2: Use case description 2.............................................................................................................8
Table 3: Use case description 3.............................................................................................................9
Table 4: Use case description 4...........................................................................................................10
Table 5: Use case description 5...........................................................................................................11
Table 6: Use case description 6...........................................................................................................12
Figure 1: Use case Diagram...................................................................................................................7
Figure 2: Class diagram.......................................................................................................................14
Figure 3: State machine modeling.......................................................................................................16
Figure 4: System sequence diagram....................................................................................................17
Figure 5: ER diagram..........................................................................................................................20
List of tables
Table 1: Use case description 1.............................................................................................................7
Table 2: Use case description 2.............................................................................................................8
Table 3: Use case description 3.............................................................................................................9
Table 4: Use case description 4...........................................................................................................10
Table 5: Use case description 5...........................................................................................................11
Table 6: Use case description 6...........................................................................................................12
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

Introduction
According to the case study, there is the company named Squeaky surfs who want to operate
the business at seven various breaches & about the Esperance national park of Western
Australia in the south. As because of the increasing the tourism the government required the
system to manage the business of rental more effectively. There are different stocks of boards
like Malibu, Longboard, Fun board, Gun, Fish & shortboard. The SUP & surfboards are
available for the children’s & adult & women & men are identified by the color, the admin
may add more stocks of boards, track the records, the customer may take boards on rent by
paying the rent, customers may also fill the feedback form to review the information. They
also provide the service & repair that is exchange with the ex-boards if required as they deal
with the shop of Brain’s board ‘WaxOff-WaxOn’. In the below report, section one, recognize
the user stories, in section second derive the use case diagram with help of the user stories, In
section three, required to draw the class diagram having a specialization, In section four,
draw the state machine diagram by utilizing the different levels of the boards. In section five,
required to draw the sequence diagram of the system by using any use case. In section six, it
is required to design the user interface. In the last section that is seven, required to create the
entity relationship diagram.
According to the case study, there is the company named Squeaky surfs who want to operate
the business at seven various breaches & about the Esperance national park of Western
Australia in the south. As because of the increasing the tourism the government required the
system to manage the business of rental more effectively. There are different stocks of boards
like Malibu, Longboard, Fun board, Gun, Fish & shortboard. The SUP & surfboards are
available for the children’s & adult & women & men are identified by the color, the admin
may add more stocks of boards, track the records, the customer may take boards on rent by
paying the rent, customers may also fill the feedback form to review the information. They
also provide the service & repair that is exchange with the ex-boards if required as they deal
with the shop of Brain’s board ‘WaxOff-WaxOn’. In the below report, section one, recognize
the user stories, in section second derive the use case diagram with help of the user stories, In
section three, required to draw the class diagram having a specialization, In section four,
draw the state machine diagram by utilizing the different levels of the boards. In section five,
required to draw the sequence diagram of the system by using any use case. In section six, it
is required to design the user interface. In the last section that is seven, required to create the
entity relationship diagram.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

User stories
As a customer, I want to rent the board from the location & return it to the same location as it
will not lead undersupply & oversupply.
Acceptance criteria
ï‚· The customer required to register.
ï‚· The lookup should be by account number or by name.
ï‚· The items will be sort by the location in the bin.
ï‚· The system required to detect the stocking.
ï‚· The trailer & pickup will again locate the location.
As a customer, I want to have the payment functionality as to there will be no bill splitting
(Dimitrijević, 2015).
Acceptance criteria
ï‚· The customer required the identification at the time of hiring.
ï‚· The $150 will be deposited on the board that will apply to the credit card of the
customer.
ï‚· The deposit will be refunded on the return of board.
ï‚· The rental charges will be applied on categories (short term, weekly & daily).
ï‚· No bill will be split on the single customers for the whole transaction of rental.
As Squeaky surf, I want to track the records as to replace the stock, & avoid the bad brands.
Acceptance criteria
ï‚· Detail of the records of each record.
ï‚· The devices to display & scan.
ï‚· Track the records that required to be replaced.
As a customer, I want the feedback form as review the information & to discover the
customer problem.
Acceptance criteria
ï‚· The forms will be handed to the customers will hiring the boards.
As a customer, I want to rent the board from the location & return it to the same location as it
will not lead undersupply & oversupply.
Acceptance criteria
ï‚· The customer required to register.
ï‚· The lookup should be by account number or by name.
ï‚· The items will be sort by the location in the bin.
ï‚· The system required to detect the stocking.
ï‚· The trailer & pickup will again locate the location.
As a customer, I want to have the payment functionality as to there will be no bill splitting
(Dimitrijević, 2015).
Acceptance criteria
ï‚· The customer required the identification at the time of hiring.
ï‚· The $150 will be deposited on the board that will apply to the credit card of the
customer.
ï‚· The deposit will be refunded on the return of board.
ï‚· The rental charges will be applied on categories (short term, weekly & daily).
ï‚· No bill will be split on the single customers for the whole transaction of rental.
As Squeaky surf, I want to track the records as to replace the stock, & avoid the bad brands.
Acceptance criteria
ï‚· Detail of the records of each record.
ï‚· The devices to display & scan.
ï‚· Track the records that required to be replaced.
As a customer, I want the feedback form as review the information & to discover the
customer problem.
Acceptance criteria
ï‚· The forms will be handed to the customers will hiring the boards.

ï‚· To get the details of the boards & customers.
ï‚· This form will be overviewed by the staff & link the information.
As Squeaky surf, I want to have different boards of stocks to add multiple boards at each
location.
Acceptance criteria
ï‚· Required the system to manage the rental business easily & effectively.
ï‚· The boards are only available for a limited time period.
ï‚· It includes Malibu, fun board, Longboard, Shortboard & fish.
As a customer, I want the functionality for repair & service of the boards as to exchange them
with the ex- surfboards.
Acceptance criteria
ï‚· The customer required to be registered.
ï‚· The customer should do with payment.
ï‚· It will exchange the surf with the ex-surf boards.
ï‚· Add the suppliers in the portfolio (Lucassen, 2016).
ï‚· This form will be overviewed by the staff & link the information.
As Squeaky surf, I want to have different boards of stocks to add multiple boards at each
location.
Acceptance criteria
ï‚· Required the system to manage the rental business easily & effectively.
ï‚· The boards are only available for a limited time period.
ï‚· It includes Malibu, fun board, Longboard, Shortboard & fish.
As a customer, I want the functionality for repair & service of the boards as to exchange them
with the ex- surfboards.
Acceptance criteria
ï‚· The customer required to be registered.
ï‚· The customer should do with payment.
ï‚· It will exchange the surf with the ex-surf boards.
ï‚· Add the suppliers in the portfolio (Lucassen, 2016).
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

Use case Modelling
Figure 1: Use case Diagram
Use case description
Table 1: Use case description 1
Use case name: Add various stock of boards
Scenario: Add multiple boards stock for customers
Triggering event: When customers want to buy new & various
different boards.
Brief description: By adding the various different stocks of
boards, it will increase the marketing & the
customer may choose the boards according to
their choice & also it provides the
flexibilities.
Actors: Admin
Related use case:
Stakeholders: Customers,& staff members
Pre-conditions: Space is needed to be available.
Figure 1: Use case Diagram
Use case description
Table 1: Use case description 1
Use case name: Add various stock of boards
Scenario: Add multiple boards stock for customers
Triggering event: When customers want to buy new & various
different boards.
Brief description: By adding the various different stocks of
boards, it will increase the marketing & the
customer may choose the boards according to
their choice & also it provides the
flexibilities.
Actors: Admin
Related use case:
Stakeholders: Customers,& staff members
Pre-conditions: Space is needed to be available.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Different boards stocks are added.
The customer may choose any board.
Post-conditions: The customer required to pay the rent for the
selected board.
Activities flow: Actors
1. The admin
will manage
the boards.
2. The admin
will upload
the boards in
the system.
3. The admin
will approve
the boards
selected by
the
customers.
System
1. The system
will display
the boards.
2. Let the
customers
choose the
boards.
Exception conditions: 1. The boards will not display.
2. The categories will not be selected by
the customers (Jagtap, 2016).
Table 2: Use case description 2
Use case name: Feedback form
Scenario: The customers will fill the feedback forms.
Triggering event: When the customers provide the feedback.
Brief description: By filling the feedback form by the customer this
help to overview the services & check by the staff
members & find the information link to that board.
Actors: Admin & customers
Related use case: Customers will fill the form.
Stakeholders: Customers, staff members & Admin.
The customer may choose any board.
Post-conditions: The customer required to pay the rent for the
selected board.
Activities flow: Actors
1. The admin
will manage
the boards.
2. The admin
will upload
the boards in
the system.
3. The admin
will approve
the boards
selected by
the
customers.
System
1. The system
will display
the boards.
2. Let the
customers
choose the
boards.
Exception conditions: 1. The boards will not display.
2. The categories will not be selected by
the customers (Jagtap, 2016).
Table 2: Use case description 2
Use case name: Feedback form
Scenario: The customers will fill the feedback forms.
Triggering event: When the customers provide the feedback.
Brief description: By filling the feedback form by the customer this
help to overview the services & check by the staff
members & find the information link to that board.
Actors: Admin & customers
Related use case: Customers will fill the form.
Stakeholders: Customers, staff members & Admin.

Pre-conditions: The forms are needed to be print.
The customer may select the board.
Post-conditions: The customer required to fill the form after
returning the board.
Activities flow: Actors
1. The admin
will
manage
the
feedback
forms.
2. The
customer
will fill the
feedback
forms.
3. The admin
will review
this once
in the six
months.
System
1. The system
will display
the feedback
form.
2. The system
will submit
the form to the
admin.
Exception conditions: 1. The feedback form will not display.
2. The form will not submit (Karim, 2017).
Table 3: Use case description 3
Use case name: Track the records
Scenario: The system required to track history.
Triggering event: When customers will buy the boards.
Brief description: The system will track the records of the boards
to replace the stocks of board & ignore the poor
brands.
Actors: Admin
Related use case:
The customer may select the board.
Post-conditions: The customer required to fill the form after
returning the board.
Activities flow: Actors
1. The admin
will
manage
the
feedback
forms.
2. The
customer
will fill the
feedback
forms.
3. The admin
will review
this once
in the six
months.
System
1. The system
will display
the feedback
form.
2. The system
will submit
the form to the
admin.
Exception conditions: 1. The feedback form will not display.
2. The form will not submit (Karim, 2017).
Table 3: Use case description 3
Use case name: Track the records
Scenario: The system required to track history.
Triggering event: When customers will buy the boards.
Brief description: The system will track the records of the boards
to replace the stocks of board & ignore the poor
brands.
Actors: Admin
Related use case:
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide

Stakeholders: Admin ,& staff members
Pre-conditions: Make the database of the boards that are used by
customers.
The customer required to choose the board.
Post-conditions: The system will only track the record of the
board whose rent is already paid.
Activities flow: Actors
1. Admin will
review the
records.
System
1. The system
will track the
records.
Exception conditions: 1. No record found by the system.
2. The record will not add (Yue, 2015).
Table 4: Use case description 4
Use case name: Payment functionality
Scenario: Customer will pay the rent by using the
functionalities of the system.
Triggering event: When the customer will purchase the boards.
Brief description: The customer will pay the rent of the board
by utilizing the functionalities of the system.
As the rent deposit by the customer will be
applied to the credit card of the customer &
the deposit will be return & the rental charges
will be applied.
Actors: Admin & customers
Related use case:
Stakeholders: Customers,& Admin
Pre-conditions: The account of the customer is required.
The account & address must be linked with
the customers.
The authorization services for the credit/
debit card should be available.
Pre-conditions: Make the database of the boards that are used by
customers.
The customer required to choose the board.
Post-conditions: The system will only track the record of the
board whose rent is already paid.
Activities flow: Actors
1. Admin will
review the
records.
System
1. The system
will track the
records.
Exception conditions: 1. No record found by the system.
2. The record will not add (Yue, 2015).
Table 4: Use case description 4
Use case name: Payment functionality
Scenario: Customer will pay the rent by using the
functionalities of the system.
Triggering event: When the customer will purchase the boards.
Brief description: The customer will pay the rent of the board
by utilizing the functionalities of the system.
As the rent deposit by the customer will be
applied to the credit card of the customer &
the deposit will be return & the rental charges
will be applied.
Actors: Admin & customers
Related use case:
Stakeholders: Customers,& Admin
Pre-conditions: The account of the customer is required.
The account & address must be linked with
the customers.
The authorization services for the credit/
debit card should be available.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Post-conditions: The customers have their own account.
Activities flow: Actors
1. The admin
will approve
the payment.
2. The
customers
will select the
mode of
payment.
System
1. The system
will send the
confirmation
message to
the respective
customers.
Exception conditions: 1. No board will take on rent.
2. The payment system is not
working.
Table 5: Use case description 5
Use case name: Services & repair
Scenario: The customer will apply for repair & service
of the board.
Triggering event: If the boards are not working properly.
Brief description: The service & repair will be used when the
board is not in good condition by the
customer. So, the board will be replaced by
the ex-surf in this case.
Actors: Admin, & customers
Related use case: Customer will request for the services &
repair.
Stakeholders: Customer & Admin
Pre-conditions: The customer has already taken on rent.
The board is not in working condition.
Post-conditions: The customer will require paying the
additional cost.
Activities flow: Actors
1. The service &
System
1. The
Activities flow: Actors
1. The admin
will approve
the payment.
2. The
customers
will select the
mode of
payment.
System
1. The system
will send the
confirmation
message to
the respective
customers.
Exception conditions: 1. No board will take on rent.
2. The payment system is not
working.
Table 5: Use case description 5
Use case name: Services & repair
Scenario: The customer will apply for repair & service
of the board.
Triggering event: If the boards are not working properly.
Brief description: The service & repair will be used when the
board is not in good condition by the
customer. So, the board will be replaced by
the ex-surf in this case.
Actors: Admin, & customers
Related use case: Customer will request for the services &
repair.
Stakeholders: Customer & Admin
Pre-conditions: The customer has already taken on rent.
The board is not in working condition.
Post-conditions: The customer will require paying the
additional cost.
Activities flow: Actors
1. The service &
System
1. The

repair will be
approved by
the Admin.
2. The customer
will ask for
the repair &
services.
system
will accept
the
payment.
Exception conditions: 1. The system will not work
(Faitelson, 2017).
Table 6: Use case description 6
Use case name: Rent the board
Scenario: The customer takes the board on the rent for
usage.
Triggering event: The customer required to register themselves.
Brief description: The customer will take the board on the rent
for the usage after paying the rent. They may
only use it if the customer has paid the rent.
Actors: Admin, Staff members & customers
Related use case:
Stakeholders: Customers,& staff members
Pre-conditions: The customer required to register themselves.
The customer has the account.
Post-conditions: The board should be return in a good manner.
Activities flow: Actors
1. The admin
will
manage
the rent.
2. The
customer
will pay
the rent to
System
1. The system
will accept
the rent of the
board.
approved by
the Admin.
2. The customer
will ask for
the repair &
services.
system
will accept
the
payment.
Exception conditions: 1. The system will not work
(Faitelson, 2017).
Table 6: Use case description 6
Use case name: Rent the board
Scenario: The customer takes the board on the rent for
usage.
Triggering event: The customer required to register themselves.
Brief description: The customer will take the board on the rent
for the usage after paying the rent. They may
only use it if the customer has paid the rent.
Actors: Admin, Staff members & customers
Related use case:
Stakeholders: Customers,& staff members
Pre-conditions: The customer required to register themselves.
The customer has the account.
Post-conditions: The board should be return in a good manner.
Activities flow: Actors
1. The admin
will
manage
the rent.
2. The
customer
will pay
the rent to
System
1. The system
will accept
the rent of the
board.
⊘ This is a preview!⊘
Do you want full access?
Subscribe today to unlock all pages.

Trusted by 1+ million students worldwide
1 out of 23
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.