Information

Systems Project
SYSTEMS ANALYSIS & DESIGN
ALEX BUTTERWORTH, ALISTAIR DICKSON,
ABDULRAHMAN ALAMMAR, LIAM MALONE, ELLIOTT
NIXON

CONTENTS

Contents ...................................................1
Introduction................................................2
Use case diagram........................................2
Top down entity relationship diagram........3
Bottom up entity relationship diagrams......4
Appendix A:...............................................5
Appendix B:...............................................5
Relational Data Analysis.............................6
Appendix A normalisation:........................6
Appendix B normalisation:........................7
Decisions and Assumptions.........................8
Use Case Diagram:....................................8
Entity Relationship Diagram:....................8
Use case descriptions.................................9
Final Group Entity Relationship Diagram. 14
INTRODUCTION

This report details the design of a digitalised system for Rays Rentals.
Contained within is a complete use case diagram, a top down entity
relationship diagram, data normalisation (from appendix A and B) and
two bottom up entity relationship diagrams (from the normalisation of

appendix A and B). We also detailed any decisions made in the design
process as well as any assumptions made along the way.

USE CASE DIAGRAM

Key:

Must have
Should have
Could have

TOP DOWN ENTITY RELATIONSHIP

DIAGRAM

BOT TOM UP ENTITY RELATIONSHIP

DIAGRAMS

Appendix A:

Appendix B:

RELATIONAL DATA ANALYSIS

Appendix A normalisation:

Appendix B normalisation:

DECISIONS AND ASSUMPTIONS

Use Case Diagram:

Assumptions:

In our use case diagram, we assumed that the customer must pay

for the bike in order to collect it.

We also assumed that as well as buying bikes and removing them
that the owner would want to be able to record the selling of bikes.

Decisions:

We decided that you could update the bike maintenance history

without servicing a bike, this is because servicing bikes and fixing
bikes are two different tasks.

Entity Relationship Diagram:

Assumptions:

In our entity relationship diagram, we assumed that the

Manufacturer was the entity containing the information of the

external supplier who manufactured and supplied parts for Rays
Rentals.
We also assumed that the Dealer entity contained information
about an external source, which both buys and sells bikes from
Rays Rentals.

Decisions:

We decided that one rental contains one bike, rather than having

multiple bikers per order. This means renting out multiple bikes
will require multiple rentals.
We noticed from our bottom up relational data analysis that we
needed to add a sellDate and sellPrice to our bike record.

USE CASE DESCRIPTIONS

Use Case: Enter Reservation

Owner: Owner, General Staff
Pre-Conditions
Checked availability of bike
Post-Conditions
Update bike record
Customer pays for bike
Primary Path
Success:
1. Select customer from table
2. Select bike type from table
3. Choose from available bikes
4. Enter reservation details (dates, due back)
5. Submit reservation
Failure:
1.
2.
3.
4.
5.
6.

Select customer from table

Select bike type from table
Choose from available bikes
Enter reservation detail in the past
Error message Please enter a future date
Return to Primary Path Step 4

Alternate Path
In case of new customer:
1. Enter new customer details
2. Return to Primary Path Step 2
Notes
By Will Southall

Use Case: Update Maintenance Record

Owner: Customer, Hiring
Pre-Conditions

The customer returns a bike and reports a fault with it.

The hiring department receives a bike back from a customer and notices
a fault

Post-Conditions

When the fault has been fixed, the maintenance staff remove it from the
database and notify the system that the bike is now available to be hired
out

Primary Path

The hiring department asks the customer if everything was okay with
the bike they hired. If they report a fault, the staff inspect the bike.

If a fault is found, the staff enters the details of the fault into the system,
as well as marking the bike as unavailable for hire.

The fault is then uploaded to the maintenance database, which is

checked regularly by the maintenance staff.

Alternate Path

No faults are reported or found

Notes
By Alistair Dickson

10

Use Case: Report a Fault

Owner: Customer, Staff
Pre-Conditions

Customer finds a fault in a bike and report it to staff.

Staff finds a fault in a bike and update it in the system.

Post-Conditions

The maintenance department checks the system and then fix the bike.

The fault marked as checked and updated in the database.

Primary Path

Customer reports a fault to staff about a fault in a specific bike, the

staff check the bike and (if there is a fault) enter fault details in the
database with the bike number.

The technicians check the reported bike and specify the exact fault,
and fix it.

Alternate Path

Sell the bike if the fault is not repairable.

Order the needed parts to repair the fault.

Notes
By Abdulrahman Alammar

11

Use Case: Removing Bikes from the System

Owner: Report Remove bikes from system Ray rentals
Pre-Conditions

1) Place the bike in the broken bikes section of the storage, this
separates the working bikes from broken so the bikes can be found
quicker.
2) Check bikes for parts that might be needed on other models in
our repair station.
Post-Conditions

- We process it to another company who purchases scrap bikes

from us. (Scrap yard or bike parts store)
- We then have made less of a loss when we have broken bikes
reported in by customers.
Primary Path

1. The bike has been reported as broken and Ray rentals take the
bikes and places the broken bike into the broken bike section of
the storage.
2. Check the bike to see if it can be repaired with parts. (If yes
then send to repairing department.)
3. Strip bikes for parts to be used on repairing other bikes.
4. Any parts left sell to a 3rd party.
Alternate Path

1) The bike has been reported as broken and Ray rentals take
the bikes and places the broken bike into the broken bike
section of the storage.
2) Check the bike to see if it can be repaired with parts.
3) Send the bike to repairing station where it is fixed and reused after being checked.
Notes
By Liam Malone

12

13

FINAL GROUP ENTITY RELATIONSHIP

DIAGRAM

14