Squeaky Surf Rental: A Business Systems Analysis Project (MAN5902)

Desklib provides past papers and solved assignments for students. This project details the analysis and design of Squeaky Surf's rental system.

Business Systems Analysis
MAN5902
Student Name:
Enrolment number:

Table of Contents
Section 1- Identifying user stories..............................................................................................3
Section 2 – Use case modelling.................................................................................................5
Section 3 – Class diagram modelling.........................................................................................7
Section 4- State machine modelling...........................................................................................7
Section 5- System sequence diagram.........................................................................................8
Section 6- Designing the user interface.....................................................................................9
Section 7- Modelling the database...........................................................................................12

Section 1- Identifying user stories
 As a customer, I want a variety of boards available at each Squeaky Surf store at a
lower price than other board rental stores.
Acceptance criteria:
o View an image of the surfboard or the hoverboard.
o View more information about the product.
o View products filtered by category.
o Pay online and submit user verification.
o Rent boards in three categories, short-term, weekly & daily
 As an inventory manager, I want to view the list of stock available at each store so
that it can be efficiently managed.
Acceptance criteria:
o See complete inventory list of all stores.
o Filter and view products based on what’s liked most by the customers.
o Accept or reject store supply requests.
o Keep a check on the quality of the products.
 As a store manager, I want to make product requests and manage store specific data.
Acceptance criteria:
o Be able to send requests to inventory manager in case there is understocking
or overstocking of products.
o Update product inventory lists for the online users to see.
 As a product shipment staff member, I want to get updates about the understocking
and overstocking of products for efficient and quick shipment of products from one
store to another.
Acceptance criteria:

o Get updates and live status of inventory at stores.
o The inventory lists must get updated as soon as a user rents a product from a
store.
o Get details about overstocking or understocking of products at stores.
o Suggestion about which store should provide another store some products such
that balance is maintained.
 As a finance employee, I want to track all the finances of Squeaky Surf and get
complete analytic data for all store sales.
Acceptance criteria:
o View store-wise financial collections with complete details about which
product is being rented the most at which store.
o Other financial and analytic data also available.

Section 2 – Use case modelling
Use case name: Create customer account
Scenario: Generate new customer acc. online
Triggering event: New customer wants to rent boards from Squeaky surf
Description: Customer inputs their details and submits valid identification proof
online
Actors: Customer
Related use case: May be invoked by rent now use case
Stakeholders: Financial, sales
Preconditions: Identification proof validation services must be available
Account handling subsystem must be present
Postconditions: Account must be created
Identity must be validated
Customer must be able to rent products
Flow of activities: Actor- Customer wishes to rent a surfboard or a hoverboard
System- New customer is created and ID verified
Exceptions: Customer ID could not be validated
Customer details invalid
Use case name: Relocate products
Scenario: Transport products from one store to another
Triggering event: Overstocking or understocking of products at stores
Description: Customers would want all kinds of products available at each store and
hence all stores must offer all kinds of products
Actors: Product shipment staff
Related use case: None.
Stakeholders: Shipping, sales
Preconditions: Store managers have got relocation requests approved from the
inventory manager
Postconditions: Inventory is better managed well in time
Flow of activities: Actors- Store manager requests inventory
System- Sends request to inventory manager
Actor-Inventory manager accepts
System- Notifies relocation staff
Exceptions: Relocation staff unavailable.
Inappropriate shipment requests by the store managers.
Use case name: Rent boards
Scenario: Customer pays the fee and chooses the board they wish to rent from the
three available pack types
Triggering event: Customer visits the store and wishes to rent a board
Description: Customer looks up the inventory of the store and rents one or more
boards he/she likes

Actors: Customer, store manager
Related use case: none
Stakeholders: Customer, sales, finance manager
Preconditions: Customer must have an account
Customer must be willing to rent a board from the available boards at
the store
Postconditions: Inventory is available
Customer is verified by ID
Flow of activities: Actor- Customer places a rent order for a board
System- Sends notification to the store
Prompts the customer to pay fee
Actor- Customer enters payment information
System- Verifies payment information and processes transaction
Exceptions: Transaction failure
Inventory unavailable
Damaged inventory
Figure 1: Use case diagram for Squeaky surf rental

Section 3 – Class diagram modelling
Figure 2: Class diagram for Squeaky Surf rental service
Section 4- State machine modelling
Figure 3: State machine model for Squeaky surf rental

Section 5- System sequence diagram
Figure 4: System sequence diagram for Squeaky surf rental service

Section 6- Designing the user interface
This section gives a basic UI design for the customer login type where they register and login
first. Then they are allowed to choose the board type they want to rent along with the plan.
They are then redirected to the payment page where they fill up the card details and make
payment for the board rent.
Figure 5: Registration screen

Figure 6: Login page
Figure 7: Choose board type

Figure 8: Choose board
Figure 9: Payment page