4. 3
Babatunde, Sooraj, Fawaz, Timothy
1 Introduction
System Solutions are a small IT consultant agency located in the heart of London. We advise,
analyse, design, maintain and upgrade computer systems for organisations across the world.
We specialise in the provision of technological solutions to Businesses
LSBU is a university located in Elephant & Castle, LSBU has recently acquired a fleet of 400
rechargeable electric powered cars (e-cars) operating in a 24-hour rental store near Southwark
Station. LSBU E-car rental’s store in Southwark is open 365 days of the year and operates
for 24 hours a day.
LSBU has contracted System Solutions to model LSBU’s E-car business. The Task is to
propose improvements to the business processes and the supporting data model as well as
propose a new and improved prototype information system.
2 Executive Summary
Systems Solutions have assigned Tunde, Sooraj, Fawaz and Timothy to the team tasked with
the provision of solutions to suit LSBU’s business needs. The team will work using the agile
process to software development which involves:
Scrums – A chance to meet the client and address issues that may have arisen during
the duration of the project (George Ubakanma).
Meetings – An opportunity for the project team to get together, assign tasks, review
tasks and plan for future task according to the Gantt chart previously prepared.
Sprints – A chance to re-visit the sprint backlog made during the Scrums with the
client and get further clarification from the client if needed.
The project commenced with a Scrum, this gave team project team the opportunity to clarify
some issues about the case study with the client. A Gantt chart was subsequently produced
which detailed the date, time and task allocation of deliverables for the client. The team
would also meet at regular intervals with both the client and themselves as the project
progressed. To understand the inner workings of LSBU’s E-car operation we needed to
model the current system and see where we could incorporate our technological expertise.
This report will aim to provide concrete technological improvements to a promising business
organisation. It will also be touching on research & development opportunities as part of the
in depth look at LSBU’s E-Car Business.
5. 4
Babatunde, Sooraj, Fawaz, Timothy
3 Existing System
3.1 Use Case
The above diagram is the Use case constructed for the existing LSBU E-car system. The
diagram was derived from information collected in Scrums with the Client and information
provided prior to commencing. The project team are outsiders to LSBU’s E-car business and
had to understand the current system before proposing improvements.
The project team modelled the entire LSBU system in this Use Case but will only be
concentrating on the Membership/Rental, Maintenance and Insurance sections of this
Diagram.
To begin with, we have 5 actors that all interact with the system at a given time which are,
Customer, Rental Clerk, Insurance, Engineer and Admin. We chose these actors because we
felt that they predominantly interacted with the system for our given topic, ‘rental’,
‘maintenance’ and ‘insurance’.
6. 5
Babatunde, Sooraj, Fawaz, Timothy
Membership
When a new customer comes to rent an E-car, if the customer is not a current Member they
must fill a Membership form and provide ID. The Membership form is passed on to the
Rental Clerk, the Rental Clerk confirms that the form is completed correctly, makes copies of
the ID and passes it on to the Admin Officer. The Admin Officer processes the application
and compares it against existing Members before preparing a Membership card. The Admin
Officer then gives authority for the Rental Clerk to take a registration fee. After the customer
has paid they may now rent an E-Car.
Rental
When a Member requires an E-car they present their Membership card at the rental store and
sign a one-day Rental Agreement. The Rental Clerk checks the Rental Agreement against the
file of outstanding Rental Agreements and takes payment from the Member before giving
permission to Engineers to provide and E-car.
Maintenance
At the end of a Rental Agreement period the customer returns the E-car to the Rental store
and the Engineer gives the E-car a Visual Inspection, if undamaged the Engineer gives the
Rental Clerk permission to sign off the Rental Agreement before customer may leave. If the
E-car is damaged the Engineer’s Service Report will identify the cost and the customer will
be informed. The rental Clerk then sends a copy of the Engineer’s Service report to the
Insurer who invoices the Member for subsequent repair costs.
Insurance
The Actor (Insurer) comes into action mainly when things go wrong. With regards to the
customer in an event of breakdown, accident and damages the insurer deals with resolving
the issues. The customer would report the accident to the insurer who then provide a repair,
recovery or replacement to the vehicle. In the event of a no or late return from the customer
of the vehicle, the insurer would deal with recovering the costs from the customer.
We have understood the role of the insurer and plan to make a few improvements on this
system to really satisfy the client upon completion. After some discussion we felt that the
client was very keen to improving this aspect of the system so we aim to put a lot of extra
time in ensuring this is achieved.
7. 6
Babatunde, Sooraj, Fawaz, Timothy
Use Case Name: Fill MembershipForm
Scenario: Customerfillsoutmembershipformtosign
up to LSBU E-Car
TriggeringEvent: CustomerRequestssignup
BriefDescription: In orderfor a customerto take out a vehicle,
theymustbe a member
Actors: Customer
RelatedUse Case: Formsto Admin
Stakeholders: Customer,Rental Clerk,Admin
Preconditions: Customermustholda licence andpassthe
checks
Flowof Activities: Actor System
1.Customerwantsto
become a member
1.1Produces
membershipform
ExceptionConditions: 1.1 customerisalready a member
Use Case Name: Prepare MembershipCard
Scenario: Customerhassignedupto become a
member
TriggeringEvent: Customerawaitsmembershipcardafter
signingup
BriefDescription: The rental clerkpreparesthe membership
card after receivingthe membershipform
Actors: Rental Clerk
RelatedUse Case: Givesmembershipcard
Stakeholders: Customer,Rental Clerk,Admin
Preconditions: The rental clerkhas takena photocopyof the
ID and receivedthe authorityfromthe
admin
Flowof Activities: Actor System
1.Rental clerk
preparesthe
membershipcard
1.1. Systemstores
the new member
details
1.2. Systemchecks
on the new member
1.3. Systemprintsoff
new membership
card
ExceptionConditions: 1.1. The customerdoesn’tpassthe check
1.2. The Admindoesn’tgive authority
Use Case Name: TakesPayment
Scenario: The customerwantsto become a member
TriggeringEvent: Customerhasbecome a member
8. 7
Babatunde, Sooraj, Fawaz, Timothy
BriefDescription: Once the customerhas become a member,
he/she hasto paythe one off membership
fee
Actors: Rental Clerk
RelatedUse Case: Preparesmembershipcard,signagrement
Stakeholders: Customer,Rental Clerk
Preconditions: The customerwouldhave hadto of
completedthe membership formandbeen
acceptedbyadminwhogivesthe authority
to the Rental Clerk.
Flowof Activities: Actor System
1.1. Takesthe
payment
from
customer
1.2. Provides
receipt
1.1. Payment
approvedby
customer
1.2. Update
membership
information
ExceptionConditions: 1.1. Transactiongetsdeclined
1.2. The customerhasn’tfilledouta
membershipform
1.3. Customerhasn’tgotmembership
card
Use Case Name: GivesMembershipCard
Scenario: CustomerGivesthe Rental Clerktheir
membershipcard
TriggeringEvent: Customerwantsto renta vehicle
BriefDescription: As the customerisinterestedinrentinga
vehicle,theyhave topresenttheir
membershipcard
Actors: Customer
RelatedUse Case: PresentCard,CheckAgainstFile
Stakeholders: Customer,Rental Clerk
Preconditions: The customerwouldhave to holda
membershipcard
The customerwouldhave to be a member
Flowof Activities: Actor System
1.1. Requeststohire
a vehicle
1.1. Checksif
member
1.2. Checkscustomer
informationagainst
file
1.3. Returns
membershippassed
or failed
ExceptionConditions: Customerhasto holda membershipcard
Customerhasto be a member
9. 8
Babatunde, Sooraj, Fawaz, Timothy
Use Case Name: GivesPermission
Scenario: EngineergivespermissiontoRental clerkto
put car on hire
TriggeringEvent: Customerwantsto renta car and rental clerk
checksif the selectedcarcan be put outon
hire
BriefDescription: Whenthe customerselectstheirchosen
vehicle,the rental clerkhastorequest
informationfromthe engineerwhetherthe
car isinworkingorder,therefore leadingto
give permissionactivitywhere engineergives
the permissiontoputcar on hire.
Actors: Engineer
RelatedUse Case: Provide E-Car
Stakeholders: Engineer,Rental ClerkCustomer
Preconditions: Car must be inworkingorderto be able to
give permission.
Flowof Activities: Actor System
1.1. Receives
requestfora
chosencar
1.2. Does
necessary
checkson
car
1.3. Gives
permission
for car to go
on hire
1.1. Message
sentto
engineer
1.2. Engineer
updates
information
on vehicle
1.3. Message
sentto the
Rental Clerk
withdecision
ExceptionConditions: Car doesnot passchecks
There are nohire cars left
Use Case Name: ReportAccident
Scenario: Customerhasan accidenton one of the
rental cars
TriggeringEvent: Accidentoccurred
Brief Description: Whena customerhas an accident, they
mustreport itimmediatelytothe insurance
Actors: Customer
RelatedUse Case: Repair,Recovery,Replacement
Stakeholders: Customer,Insurance
10. 9
Babatunde, Sooraj, Fawaz, Timothy
Preconditions: Customermusthave hireda car through
LSBU E-Car
Customermusthave signedthe customer
agreement
Flowof Activities: Actor System
1.1. Has an
accident
1.2. Contacts
insurance
1.1. Receives
agreement
from
insurance
1.2. Customer
agreement
updated
ExceptionConditions: The customeron the agreementwasn’t
drivingthe vehicle
Use Case Name:
Scenario:
TriggeringEvent:
BriefDescription:
Actors:
RelatedUse Case:
Stakeholders:
Preconditions:
Flowof Activities: Actor System
ExceptionConditions:
Use Case Name: Late Payment
Scenario: Car returnedpastcontractual agreement
TriggeringEvent: ReturnE-Car
BriefDescription: The customerreturnsthe hire car afterthe
rental periodhascome to an endand is
therefore finedforlate return
Actors: Customer,insurance
RelatedUse Case: Invoice Costs
Stakeholders: Customer,LSBU E-Car,Insurance
Preconditions: Customermusthave exceededcontractual
period
Flowof Activities: Actor System
1.1. Customer
returnsE-Car late
1.1. Customer
invoiced
11. 10
Babatunde, Sooraj, Fawaz, Timothy
1.2. Customer
agreementupdated
ExceptionConditions:
Use Case Name: Visual Inspection
Scenario: Engineerinspectvehicle
TriggeringEvent: Rental car returned
BriefDescription: The engineerdoesavisual inspectionof the
car to checkfor damages
Actors: Engineer
RelatedUse Case: SignOff
Stakeholders: Customer,Engineer
Preconditions: Rental vehicle mustbe returned
Flowof Activities: Actor System
1.1. Engineerdoes
visual inspection
1.1. Rental
agreementupdated
ExceptionConditions: Customerhadan unreportedaccident
Use Case Name: DetailedInspection
Scenario: Engineerdoesavisual inspectiononvehicle
TriggeringEvent: Damageson car found
BriefDescription: A detailedinspectionof the vehicle isdone
whendamageshave beenfoundonthe
vehicle afterthe customerhasreturnedit
Actors: Engineer,Customer
RelatedUse Case: Update CustomerAgreement
Stakeholders: Customer,Engineer,Rental Clerk
Preconditions: Car must have beenfoundwithdamages
Flowof Activities: Actor System
1.1. Customer
returnscar
1.2. Engineer
finds
damages
1.3. Engineer
does
detailed
inspections
1.4. Engineer
sendsof
report
1.1. Logs car
returned
1.2. Customer
agreement
updated
ExceptionConditions: Car had damagesfromprevioushire.
12. 11
Babatunde, Sooraj, Fawaz, Timothy
3.2 Activity Diagram
Membership/Rental
When a Customer/Member comes to the Rental store to rent an E-car, the Rental process
begins. The Rental Activity Diagram commences with a Starting Pseudo which points to a
Decision node called <Member?>.
If the Customer is not a Member, the Rental process progresses to the (Fill Form) activity. At
this activity the Customer must fill a Membership form provided by the Rental Clerk. The
Rental process then transitions to the (Provide ID) activity. The Customer provides ID to the
Rental Clerk and the process transitions to the (Take Copies). The Rental Clerk makes copies
of the ID provided by the Customer and the process transitions to (Authority). The Rental
Clerk must gain authority from the Admin Officer. The Admin Officer (Checks) the
Membership form carefully against the existing file of Rental Membership forms before
issuing a new Rental Membership card. The Admin Officer gives the Rental Clerk
(Authority) to take (Payment) from the Customer. The Rental Clerk takes (Payment) from the
Customer and transitions to (Sign Agreement). The Member Signs a Rental agreement and
the Rental Clerk gives authority to the Engineer to Provide and E-car.
If the Customer is a Member, the Rental Clerk scans their Membership Card and checks their
details against the file of existing Member forms and a file of outstanding Rental
Agreements. The Rental process then transitions to the (Payment) activity. The Member
13. 12
Babatunde, Sooraj, Fawaz, Timothy
must make payment for their E-car causing a transition to (Sign Agreement) where the
Member signs the agreement for the rental. The process transitions to the (Authorize
Engineer) activity. At this activity the Rental Clerk gives authority to the Engineer before the
Rental progresses to its final activity called (Provide E-car). At this activity, the Engineer
provides an E-car to the Member which causes a transition to the Ending Pseudo.
Maintenance
The above diagram is the Activity diagram for the Maintenance process in the LSBU E-car
business. It represents the actors involved in completing the Maintenance process and the
activities involved.
The Maintenance process commences when a Member returns an E-car back to the Rental
store. A starting Pseudo is used to represent the return, the Pseudo transitions to the (Visual
Inspection) activity. At this activity, the Engineer gives the E-car a (Visual Inspection)
before the process transitions to a Decision activity called <Damage?>. A Decision activity
has been included to differentiate a damaged, returned E-car from a non-damaged one.
If the E-car is not damaged, the process transitions to the (Permission) activity. At this
activity the Engineer gives permission to the Rental Clerk to allow the Member to Sign off
their Rental Agreement. The process transitions to the (Sign Off) activity where the Member
signs of the Rental Agreement and is allowed to leave.
If the E-car is damaged, the process transitions to the (Detailed Inspection) activity. At this
activity, the Engineer gives the E-car a Detailed Inspection and prepares a Service Report.
The (Detailed Inspection) activity has two paths that are completed simultaneously.
The First Path transitions to an activity called (Send Report), the Engineer sends his Detailed
Inspection report to the Rental Clerk. The process progresses and transitions into the (Inform
14. 13
Babatunde, Sooraj, Fawaz, Timothy
Member) activity. At this activity the Rental Clerk Informs the Member on results of the
Detailed Inspection report and the path transitions to the Ending Pseudo.
The Second Path continues after the Engineer send his Detailed Inspection Report to the
Insurer, this causes a transitions to the (Send Report) activity. At this activity the Insurer
receives the Detailed Inspection Report and send it to the Member, causing a transition to the
(Invoice) activity. At the Invoice activity the Member receives the Invoice for repair to the
E-car. The process transitions to the final activity called, (Payment). At this activity the
Insurer receives payment and the Maintenance Activity Diagram for the Existing system halts
with an Ending Pseudo.
Insurance
The diagram above is the Activity diagram for the Insurance process within the LSBU’s E-
car organisation
When a Customer/Member is involved in an Accident or a Breakdown the Insurance process
begins. The existing Insurance Activity Diagram commences with a Starting Pseudo which
transitions to the first activity called (Report) at this activity, the Member will report their
accident to the Insurer. The Insurance process transitions to the (Repair/Replace/Recover)
15. 14
Babatunde, Sooraj, Fawaz, Timothy
activity. At this stage the Insurer will aim to repair, replace or recover the E-car based on the
circumstances. Progress away from this activity is guarded by a Decision node called
<Members Fault?>which diverts the process based on circumstances.
If the Accident or Breakdown is the Members fault, the Insurance process transitions to the
(Invoice) activity. The Insurer sends the Member an invoice for repairs to the E-car. The
process transitions to the (Payment) activity. At this activity, the Member will make payment
for the invoiced repairs. The Existing Insurance activity diagram then transitions to the final
activity called (Update Agreement) the Insurer must contact LSBU with details of the
accident, allowing them to update the Member’s Rental Agreement.
4 Proposed System
4.1 Use Cases
4.1.1 Membership
Redundant Role
The Current LSBU E-car system functions for its current requirements, but the project team
felt there were matters within the Membership process that required resolving.
The Rental Clerk doesn’t seem to be trusted, valued, or deemed effective enough to take on
some and if not all the roles currently performed by the Admin Officer. This meant involving
the Admin Officer in the Membership Process. The project team thought this was an
16. 15
Babatunde, Sooraj, Fawaz, Timothy
important issue that needed sorting out before embarking on methods of streamlining its E-
car business.
There is no detailed reason why the Rental Clerk cannot complete all the tasks currently
performed by the Admin officer. The removal of the Admin officer, will allow the
Membership process to move more smoothly allowing the Rental Clerk to give a more
personalised service. The Rental Clerk needs to be capable of performing the current tasks
specified by their role and also oversee the Membership process with help from our proposed
system solutions. To achieve this, the following hardware will need to be acquired:
HD Camera – will enable the Rental Clerk to take photos of the new customer during
the membership process.
Document Scanner – A document scanner will be needed to digitalise the customers
ID and proof of address.
Card Printer – Will allow the Rental Clerk to print a membership card for a new
Member.
EPOS Machine – Will enable the Rental Clerk to take electronic payment from
customer.
Card Scanner – Will enable the Rental Clerk to scan membership cards
Signature Pen & Pad – Will enable a Member to sign document such as a Rental
Agreements.
Engineer workstation – Will allow Engineers to receive alerts via the workstation to
provide, return and upload Inspections.
Removing the Admin officer’s tasks in the membership process and passing it onto the Rental
Clerk is imperative to the new system. The hardware is needed to complete the membership
process and will be used in other cases. If the Rental Clerk position is not fully trusted, the
automatic checks will maintain the systems integrity because the Rental Clerk will not rights
to modify or skip that task.
Membership checks
The Rental process is an opportunity to make an impression on the Member. The Rental
Clerk should not be manually doing Checks, this task should be completed by the proposed
system. All Membership checks will be done automatically by the Rental Clerk. The Rental
Clerk will not have the ability to skip this step in the rental process.
This proposed improvement will speed up the Rental process, the Rental Clerk will not be
wasting valuable time crosschecking information manually. A Rental Clerk’s time is best
spent engaging with the customer. This will give the customer an overall impression of
efficiency and reduction in the time between paying and driving off with an E-car
Membership Use Case Description
17. 16
Babatunde, Sooraj, Fawaz, Timothy
The diagram above is the proposed Use Case for the Membership process, it shows the
interaction between Customer, Rental Clerk and LSBU’s system. When a Customer comes
to the Rental Store to register as a Member they must fill in a Membership form and Provide
ID to the Rental Clerk. The Rental Clerk takes photographs of the Customer using the HD
camera attached to his/her Workstation and uploads it to a Membership form on the system.
The Rental Clerk scans the Customer’s ID and proof of address which is also uploaded to the
Membership form. The Rental Clerk runs Pre-Membership Checks on the Customer via the
system, this is to prevent previously banned Members from re-registering. If the Member
passes Membership Checks the Rental Clerk then requests and takes a one off registration fee
from the Customer. The Rental Clerk prints out a new Membership Card and presents it to
the Member who is then able to rent an E-car.
4.1.2 Rental
Improved Engineer authorisation
The Engineer is an important part of the rental process they provide, maintain and inspect E-
Cars. They are currently contacted manually by the Rental clerk to provide an E-car. This is
a waste of valuable time during the Rental process and may impact on customer’s impression
of LSBU’s E-car business.
The project team proposed a solution to the authorisation process, the Engineer would be
provided a workstation to complete his tasks and most importantly to receive alerts of new
rental and returns. The time between the customer making payment and driving off with an
E-car is further reduced
18. 17
Babatunde, Sooraj, Fawaz, Timothy
Car Packages
Cars are very much part of our lives, daily we rely on them to get us from place to place. If
you look on most streets in the United Kingdom you can see clearly that we drive various
types of cars with many different specifications. A tourist needing a car rental for a day in
the city may choose a small car like the current LSBU E-car to traverse around the city but a
family of four needing a car rental for a few days will need a bigger car with a stronger
engine to transport the whole family around the city or further if they so wish.
The need for E-car packages was holding back the type of customer that use LSBU’s
business and is important in the long term. Therefore, the project team have devised a
proposed improvement in the information system to allow for such a scenario. LSBU should
acquire a set of E-Cars capable of transporting the average family, the cars needs to be faster
than the current E-car stock. In addition the Customer will also be able to increase the length
of their rental agreements allowing them to enjoy their chosen E-car for Longer.
Rental Use Case Description
Above is the proposed Use Case description for the Rental process, it shows how the
customer would interact with the proposed system during the Rental process. When a
Member requires an LSBU E-car, they come to the Rental store and present their
Membership Card. The Rental Clerk scans the Member’s card and proceeds to run
Membership Checks. If the Membership checks are successful, the Member may choose an
E-car package that suits them best. The Member signs a Rental Agreement based on their
choice of E-car Package and make payment for the rental. If the Payment Transaction is
successful, the Rental Clerk authorises the Engineer via his/her workstation. The Engineer
receives an alert at his workstation to provide an E-car. When the Engineer provides the E-
car, the Rental Use Case ends.
Use Case Name: Present Card
Scenario: Customer to produced membership card
Triggering Event: Rental Clerk scan card and dose membership check
Brief Description: Customer must be register as a member to have a membership
card
Actors: Customer
Related Use Case: Choose Car Package
Stakeholders: Rental Clerk, Engineer
Preconditions: Customer must have an account on LSBU’s E-Car system
Post conditions: Customer must be an existing member
Flow of activities: Actor System
1. Customer desire to hire a e-
car
1.1. System provides Login
Details
1.2. System prompt for
customer membership
number
Exception conditions: 1.1. Customer is already registered
19. 18
Babatunde, Sooraj, Fawaz, Timothy
Use Case Name: Scan Card
Scenario: Rental Clerk Scans customer’s Membership Card
Triggering Event: Rental Clerk dose a membership card check
Brief Description: Rental Clerk must scan the membership card on to the system
Actors: Rental Clerk
Related Use Case: Authorised Engineer
Stakeholders: Customer, Engineer
Preconditions: Customer must have an membership card
Post conditions: Customer must be an existing member provide an
membership card
Flow of activities: Actor System
1. Customer present card 1.1. System scan card details
and pass details to rental
clerk
Exception conditions: 1.1. Customer details is not on the system
Use Case Name: Membership Check
Scenario: Rental Clerk must check for existing membership card
Triggering Event: Rental Clerk does a membership check
Brief Description: Customer must be already register to be a member
Actors: Rental Clerk
Related Use Case: Authorized Engineer
Stakeholders: Customer, Engineer
Preconditions: Rental Clerk search for customer details on system
Post conditions: Customer details must be on the system
Flow of activities: Actor System
1. Rental Clerk retrieves
customer details
1.1. System searching
customer details
1.2. System searching
membership card
Exception conditions: 1.1. Customer details is not on the system
1.2. Rental Clerk mistype customer details
Use Case Name: Choose Car Packages
Scenario: Customer can chooses an e-car
Triggering Event: Customer must login to choose an e-car
Brief Description: Customer must be an existing member to hire a e-car
Actors: Customer
Related Use Case: Payment transaction
Stakeholders: Customer, Engineer
Preconditions: Customer must login to hire a e-car
Post conditions: Customer must have an existing login
Flow of activities: Actor System
1. Customer chooses e-car 1.1. System searches
car availability
Exception conditions: 1.1. Car availability is limited
20. 19
Babatunde, Sooraj, Fawaz, Timothy
Use Case Name: Sign Agreement
Scenario: Customer sign agreement after choosing e-car
Triggering Event: Customer must chooses a car
Brief Description: Customer chooses a car package then sign the agreement
Actors: Customer
Related Use Case: None
Stakeholders: Customer, Engineer
Preconditions: Customer to sign agreement after choose package car
Post conditions: Customer signs pay for hire car
Flow of activities: Actor System
1. Customer sign the
agreement
1.1. Check if previous history
with customer agreement
Exception conditions: 1.1. Customer has no history agreement renting e-car
Use Case Name: Payment Transaction
Scenario: Customer has to pay for renting e-car
Triggering Event: Customer must agree on renting the e-car
Brief Description: Customer must sign the agreement before renting e-car
Actors: Customer
Related Use Case: None
Stakeholders: Customer, Engineer
Preconditions: Customer pay for renting e-car
Post conditions: Customer might choose another e-car package
Flow of activities: Actor System
1. Customer input payment for
renting e-car
1.1. System provide
confirmation renting e-
car
1.2. System email
customer renting e-car
Exception conditions: 1.1. Customer email is incorrect
1.2. Email cannot be sent to the customer
1.3. Payment cannot be processed
21. 20
Babatunde, Sooraj, Fawaz, Timothy
Use Case Name: Authorised Engineer
Scenario: Rental Clerk must complete the check
Triggering Event: Rental Clerk must check the agreement
Brief Description: Rental Clerk must authorised engineer after payment is taken
from customer
Actors: Rental Clerk
Related Use Case: None
Stakeholders: Customer, Engineer
Preconditions: Engineer provides e-car for customer
Post conditions: Customer receives e-car
Flow of activities: Actor System
1. Engineer check for
authorisation
1.1. System provides information
for customer
1.2. System provides rental
authorisation
Exception conditions: 1.1. Authorisation is not received
Use Case Name: Provide E-Car
Scenario: Engineer must have authority for Rental Clerk
Triggering Event: Engineer provide e-car to customer
Brief Description: Authorised by Rental Clerk to Provide E-car
Actors: Engineer
Related Use Case: None
Stakeholders: Customer, Engineer
Preconditions: Customer pick up e-car
Post conditions: Customer e-car information is not on system
Flow of activities: Actor System
1. Engineer provides e-
car
1.1. System Confirms customer
e-car packages
Exception conditions: 1.1. Customer e-car package is not receives
22. 21
Babatunde, Sooraj, Fawaz, Timothy
4.1.3 Maintenance
Above is our improved use case description, it shows the interactions with the proposed
system during the Maintenance process. The project team identified processes aimed at
improving the current LSBU E-car Maintenance process. The improvements are described
below.
The Project team immediately found faults with the Maintenance process. The Rental Clerk
has to wait for permission from the Engineer before signing off the Rental Agreement even in
the case where there is no damage to the E-car. When there is damage to the E-car the Rental
Clerk must manually send a copy of the Engineer’s Service Report to the insurer which is a
waste of the Rental Clerks valuable time.
The proposed improvement to the Maintenance process in the LSBU’s E-car business is as
follows:
Payment Terms & Conditions– All members must sign an agreement that
allows LSBU and its Insurer to hold their card details for the duration of their rental
and most importantly be able to charge the account if damage to the E-car is found
during Engineers inspections.
23. 22
Babatunde, Sooraj, Fawaz, Timothy
Single Inspections – There will only be one inspection, the Visual Inspection will
be removed from the Engineer’s tasks. A single detailed inspection will be completed
by the engineer with the end result being a Service Report uploaded to the system.
Quick Drop-off – LSBU already hold a lot of information about the members,
Drivers Licence details, Address, Telephone and Electronic payment details etc. A
member will now be allowed to leave as soon as they have dropped of the E-car with
the added assurance that LSBU is capable of contacting them in the chance that there
is damage to the car.
Automatic Update – The Rental Clerk will have no need to Send Reports to the
Insurer manually, this will be an automated process done at the click of a mouse by
the Rental Clerk or during daily system updates.
In the proposed improved maintenance system when a Member returns an E-car the Rental
Clerk confirms Membership and alerts the Engineer who collects the car from the Member.
The Rental Clerk then signs off the agreement subject to the result of an inspection by the
Engineer. The Member may leave at this point, the rest of the maintenance process will be
performed by LSBU staff and system in conjunction with the insurer’s system. The Engineer
prepares a report which is uploaded to the system, the Rental Clerk may view the Service
Report at this point and it is automatically relayed to the Insurer’s system who deals with
Invoicing and collecting Payment.
The proposed improvement will benefit the Member greatly in reducing waiting times after
drop off. The process of reporting to damage to the Insurer is further improved speeding up
the process and leaving no room for tampering.
Use Case Name: Return Car
Scenario: Customer drops off e-car
Triggering Event: Customer sign agreement
Brief Description: Customer returns e-car after renting
Actors: Customer
Related Use Case: None
Stakeholders: Rental Clerk, Engineer
Preconditions: Customer return e-car
Post conditions: Customer sign off agreement
Flow of activities: Actor System
1. Customer return e-car
2. Customer sign agreement
1.1. System requires
signature
2.1. System Checks
customer signature
2.2. System accept
signature
Exception conditions: 1.1. Customer Signature is not on the system
1.2. Customer Signature is incorrect
24. 23
Babatunde, Sooraj, Fawaz, Timothy
Use Case Name: Scan Membership Card
Scenario: Rental Clerk Searching for Customer details
Triggering Event: Rental clerk retrieves rental agreement
Brief Description: Rental Clerk checks for customer details after customer return
e-car
Actors: Rental Clerk
Related Use Case: Retrieves rental agreement
Stakeholders: Customer, Engineer
Preconditions: Rental Clerk input customer details
Post conditions: Rental clerk compare for customer details and rental
agreement
Flow of activities: Actor System
1. Rental Clerk Searches
Customer Rental
Agreement
2. Rental Clerk Searches
for Customer Details
3. Rental Clerk compares
Customer details with
Rental Agreement
1.1. System produces
Customer Rental
Agreement
2.1. System Produces
Customer Details
3.1. System produces a
comparison with customer
details and Rental
agreement of e-car
Exception conditions: 1.1. Customer details is incorrect or not on the system
1.2. Rental agreement is not on the system or is incorrect
Use Case Name: Authorized Inspection
Scenario: Rental Clerk accepts the e-car
Triggering Event: Rental Clerk Authorized inspection and retrieves service report
Brief Description: Rental Clerk authorized inspection
Actors: Rental Clerk
Related Use Case: Update Insurer
Stakeholders: Customer, Engineer
Preconditions: Rental Clerk does inspection on e-car
Post conditions: Rental clerk gives authorized detailed inspection on e-car
Flow of activities: Actor System
1. Rental Clerk given
inspection on e-car
2. Rental Clerk Retrieves
Service Report
1.1. System Send Inspection
to Engineer
2.1. System produce Service
Report
Exception conditions: 1.1. Service report can produce an error
1.2. Inspection does not get authority from rental clerk
25. 24
Babatunde, Sooraj, Fawaz, Timothy
Use Case Name: Prepares Service Report
Scenario: Engineer does inspection on e-car
Triggering Event: Engineer produces service report
Brief Description: Engineer produces service report on system
Actors: Engineer
Related Use Case: None
Stakeholders: Customer, Rental Clerk
Preconditions: Engineer get the authority to inspect returned e-car
Post conditions: Engineer produced a service report for rental clerk
Flow of activities: Actor System
1. Engineer produced a
service report
1.1 System send service
report to rental clerk
Exception conditions: 1.1. Service report does not get sent to rental clerk
1.2. Service report might have inaccurate details
Use Case Name: Update Insurer
Scenario: Rental Clerk retrieves service report
Triggering Event: Rental Clerk updates the insurer
Brief Description: Rental Clerk sends service report to Insurer
Actors: Rental Clerk
Related Use Case: None
Stakeholders: Customer, Engineer
Preconditions: Rental Clerk Retrieves Service Report
Post conditions: Rental Clerk sends service report to insurer
Flow of activities: Actor System
1. Rental Clerk sends
service report to
Insurer
1.1. System Sends Service report
to insurer by email
Exception conditions: 1.1. Service report haven’t been to the insurer.
26. 25
Babatunde, Sooraj, Fawaz, Timothy
4.1.4 Insurance
Above is our improved Use case diagram for the Insurance process. The diagram was derived
using the existing LSBU E-car Use case and improvements the project team outlined for
implementation in the proposed LSBU E-car system.
LSBU E-Car Mobile App
In the current system, in the event of an incident (accident/breakdown) involving an LSBU E-
car, the Member would have to contact LSBU’s insurer directly. The Insurer will handle and
recover, repair or replace the E-car depending on circumstances. The Insurer then contacts
the Rental store to inform of the incident, The Rental store then updates the customer’s
agreement accordingly.
The current Insurance process has its flaws, the issues with the system are mainly around
manual communications and delays in the processing of information. A possible solution to
this would be the introduction of an LSBU E-car mobile Application. An LSBU E-car App
should be available to Members in the event of an incident such as an Accident or
Breakdown. If a Member is involved in an Accident involving an E-car, they should be able
to access the App on their smartphone and send and Accident Report. In the event of a
Breakdown, a Member may use the App to call their insurer directly via the App.
The Insurance Use case has one Actor (Member) interacting with 3 systems, the LSBU E-car
App, LSBU and the Insurers system. If a Member has an accident, then they can access the
App on their phone to fill an Accident Report form. The Member takes pictures of damages
to the E-car and uploads them into the form. The Member sends the form electronically via
the LSBU E-car app. The Accident Report form is sent to the Insurer’s system and LSBU’s
system simultaneously. The <Include> attached to the (Upload accident form) use case
indicates that the uploaded Accident Report form must be sent to the Insurer and LSBU
system.
27. 26
Babatunde, Sooraj, Fawaz, Timothy
If a Member has a breakdown, they may use the LSBU E-car App to contact the Insurer. The
LSBU E-car App has a “Call” button programmed, this button allows all authenticated
Members using the App to call LSBU’s Insurer. The Insurer will have all the relevant details
needed to process a recovery automatically sent to the Insurer via the App when the call is
made.
If the Insurer is contacted by the Member in the event of a Breakdown, the Insurer must
contact LSBU by phone or electronically sending details about the incident. The Rental Store
will then update the Member’s Rental Agreement/Account accordingly.
The proposed LSBU E-car App is an addition to the current LSBU process, Members will
still be able to contact the Insurer directly by dialling the number provided at the back of their
Membership Card in the event of an incident.
Use Case Name: Access App
Scenario: Customer has an accident
Triggering Event: Customer access app
Brief Description: Customer has an accident and access the app
Actors: Customer
Related Use Case: None
Stakeholders: Rental Clerk
Preconditions: Customer Access app
Post conditions: Customer fills in accident form
Flow of activities: Actor System
1. Customer Access App
2. Customer Fill Accident Form
3. Customer upload picture
1.3. System produces app
access
2.1. System produces
Accident form
3.1. System send picture to
Rental Clerk and
insurer
Exception conditions: 1.1. Accident form does not
28. 27
Babatunde, Sooraj, Fawaz, Timothy
Use Case Name: Check for overdue
Scenario: Rental Clerk Check for overdue rental
Triggering Event: Rental Clerk Retrieves updates on accident form
Brief Description: Rental Clerk retrieves check updates on rental and accident
form
Actors: Rental Clerk
Related Use Case: None
Stakeholders: None
Preconditions: Rental Clerk check for updates on system
Post conditions: Rental Clerk call the customer for overdue rental
Flow of activities: Actor System
1. Rental Clerk Checks for
overdue rental
2. Rental Clerk checks for
updates on accident form
3. Rental Clerk update
customer agreement
1.1. System produce details of
overdue rental with contact
details
2.1. System produces details on
accident form
3.1. System updates rental
agreement
Exception conditions: 1.1 System produces inaccurate details
1.2 System does not updates for accident form
1.3 System does not updates overdue rental
1.4 Customer agreement is not updated
29. 28
Babatunde, Sooraj, Fawaz, Timothy
4.2 Activity Diagrams
4.2.1 Rental
Above is the Activity Diagram devised by the project team based on the Rental Use case
documented earlier in this document. The Swimlane headings indicate the Actors that
interact with the system during the Rental process.
The starting Pseudo leads to the first activity (Present Membership Card), A Member presents
their card to The Rental Clerk. The Rental Clerk scans the Membership card and the systems
progresses to a Decision activity called <Card Scanned?>, if the Membership card cannot be
scanned successfully, the system will halt and proceed to the Ending Pseudo. A card that
cannot be verified is most likely fraudulent.
If the Membership Card scans correctly, the system moves to the next process which is
(Membership Checks). The Membership Checks process leads to a Decision activity called
<Positive?>, if the Member Checks fail, the system will halt and exit the rental process. The
<Positive?> Decision Activity has been included to prevent Members from having more than
one Rental Agreement therefore only one E-car per customer. If the Member checks are
passed the Member may choose an E-car package that suits their needs, the next activity will
be for the Rental Clerk to Prepare a Rental Agreement based on the Member’s choices so far.
The Member signs the agreement and proceeds to Payment Transaction.
A Decision activity called <Successful>has been included after the Payment Transaction
activity, if payment is not <Successful> the system moves to the Ending Pseudo. The
30. 29
Babatunde, Sooraj, Fawaz, Timothy
Decision Activity has been added to protect LSBU assets. A Member cannot rent an E-car
without confirmation of a successful Payment Transaction. If Payment is successful the
LSBU system notifies the Engineer on his Workstation to Provide an E-car. The Rental
Activity is completed at this stage.
4.2.2 Maintenance
The diagram above is the activity diagram derived from the Maintenance Use case. The
swimlane has different actors in there that show the interaction and processes that’s
happening when an E-car is returned. The actors involved during this process are the
Member, Rental Clerk, LSBU System, Engineer and the Insurance system.
When a Member returns an E-car to the store, the Rental Clerk scans the Member’s
Membership Card. We included a decision node at this point saying <Has Card scanned?> in
case there are technical issues with the Membership Card or a fraudulent transaction was
imminent. The decision node has two paths, if the Membership Card scans successfully, the
Rental Agreement is retrieved from the LSBU system. If the card does not scan, the Decision
node moves to <Confirm Member Identity> the Rental Clerk must confirm the identity of the
Member manually using the LSBU system. If the Member identity cannot be confirmed then
the activity flow ends. If Identity can be confirmed, the flow continues and we reach the next
process which is <Retrieving Agreement>.
At this point we reach a “Fork node”. A Fork node “is a control node that splits a flow into
multiple concurrent flows” (Visual-paradigm.com). We used a fork node to show the
activities that takes place simultaneously. One of the activities that take place is the member
31. 30
Babatunde, Sooraj, Fawaz, Timothy
signing off the rental agreement. The member is then free to leave. This activity flow ends
here and therefore we used a “final node” to end the activity.
Simultaneously the second activity using the fork node involves the LSBU computer system
notifying the Engineer to collect and perform an inspection on the recently returned E-car.
The Engineer produces a Service Report which determines if the Member is liable for any
damages occurred during the duration of the Rental Agreement. The Engineer uploads the
Service Report to the LSBU system.
The Rental Clerk retrieves an alert on their Workstation indication a new Service Report has
been uploaded by the Engineer, a Decision Activity is included called <Any Damages> at
this stage to alert the Rental Clerk of a decision to be made manually by him/her. The Rental
Clerk examines the Service Report, if there is damage to the E-car, the Rental Clerk must
send a copy of the Service Report Electronically to the Insurer’s system. If there is no
damage to the E-car, the activity flow is finished with a “Finishing node.”
32. 31
Babatunde, Sooraj, Fawaz, Timothy
4.2.3 Insurance
The diagram above is the Activity diagram derived from the Insurance Use case. Swimlane
headings are labelled with the Actors involved during the Insurance process. The Actors
involved during this process are the Member, LSBU and Insurance system. In the event of an
incident (Accident or Breakdown) an LSBU Member may utilise the LSBU E-car App to
communicate with LSBU and its Insurer. The App gives the Member an alternative method
of alerting the Insurer by telephoning.
33. 32
Babatunde, Sooraj, Fawaz, Timothy
The diagram begins with a starting Pseudo leading to the first activity <Access LSBU App>.
In this Activity, the Member involved in an incident will Access the LSBU E-car App. A
Decision Activity has been added to determine if the incident is an <Accident or Breakdown>
and their corresponding activities.
In the event of a Breakdown, the Member is able to access the LSBU E-car App and click on
the “Call” button. The “Call” button which is programmed with the Insurer’s breakdown
number, calls the Insurer and electronically transfer the Member’s details to the Insurer’s
system. The Insurer <Contacts LSBU> informing them know of the breakdown and also
arranges to <Repair, Replace, Recover> the E-car. Contacting LSBU allows the Rental Store
to update the Member’s Rental Agreement. The Breakdown section of the Insurance activity
ends with an end Pseudo.
In the event of an Accident, the LSBU App directs the Member to <Fill accident form>.
The Member populates the Accident Report form and is directed to <Upload Pictures>,
pictures of the incident can be uploaded to the Accident form at this stage. After uploading
pictures to the Accident form, it is uploaded. The uploaded Accident form has two
destinations. The first destination is to <Send to LSBU System>, this allows the Rental Store
to update the Member’s Rental Agreement. This activity is completed with an ending Pseudo.
The Second destination for the Accident report is to <Send to Insurer>, this allows the Insurer
to <Repair, Replace, Recover> the E-car. This Activity is ceased by leading to an ending
Pseudo.
4.3 Class Diagram
34. 33
Babatunde, Sooraj, Fawaz, Timothy
The diagram above is the constructed class diagram for the proposed system. The class
diagram shows how the system works and the relationships between the different classes
we've found in the system. We had to also refer to the existing system to make sure that the
relevant associations are present in our Class.
A Class in a Class diagram is “a category or classification of a set of objects or things”
(Satzinger, 2012). It contains attributes which refers to the properties of the class. In classes
you also have primary keys and foreign key. Primary key is a unique identifier of record. A
relational database must have a primary key making it easier to find a record. A foreign key is
the primary key from another table.
Our proposed system has the following main classes and attributes:
Customer (CustomerID, Name, Address and DOB)
The primary key for this class is CustomerID.
Maintenance (MaintenanceID, CarID*, CarType, Model, RegNo, CarHistory)
The primary key for this class is MaintenanceID and the foreign key is CarID
RentCar (CarID, CustomerID*, CarType, Model, RegNo, DateRent, DateReturn)
The primary key for this class is CarID and the foreign key is CustomerID
Insurance (InsuranceID, CarID, CustomerID, Model, RegNo, TypeOfCover,
StartDate, EndDate)
The primary keys for this class is InsuranceID and the foreign keys are CarID and
CustomerID.
Multiplicities allows statements about the number of associations in a class.
The multiplicity between the classes are:
Customer - RentCar: The multiplicity between the Customer and RentCar is a ONE
to ONE relation. This is because LSBU only allows one customer to rent one car at
one time.
Customer - Insurance: The multiplicity between the Customer and Insurance is a
ONE to ONE relation. This means that each renting member is insured to one
Insurance policy provided by LSBU.
Insurance - RentCar: The multiplicity between Insurance and RentCar is a ONE to
MANY relation. This is because each rented vehicle is insured to one insurance
policy for the duration of the agreement.
RentCar - Maintenance: The multiplicity between RentCar and the Maintenance is a
ONE to MANY relation. This is because each vehicle that is rented out by LSBU can
undergo several maintenance checks.
Additionally in the diagram, we have also included the association classes which associate
the different classes using a dashed line. The association classes for the proposed system are:
35. 34
Babatunde, Sooraj, Fawaz, Timothy
CusRenCar (CustomerID*, CarID*)
This association shows the relationship between the Customer and Renting ab E- car.
It contains the Primary Key from Customers table and the Primary Key from the
RentCar table to become the attribute for the association class. The two attributes then
form together to make a composite key and become the primary key of the new
association class.
MainRenCar (MaintenanceID*, CarID*)
This association shows the relationship between Maintenance and Rented cars
It contains the Primary Key from Customers Maintenance table and the Primary Key
from the RentCar table to become the attribute for the association class. The two
attributes then form together to make a composite key and become the primary key of
the new association class.
InsuRenCar (CarID*, InsuranceID*)
This association shows the relationship between Insurance and Rented cars.
It contains the Primary Key from RentCar table and the Primary Key from the
Insurance table to become the attribute for the association class. The two attributes
then form together to make a composite key and become the primary key of the new
association class.
These above classes and associations are part of the LSBU's proposed E-Car system. The
system will be updated automatically in comparison to its old conventional method where
this was achieved manually.
5 Refined Diagrams
5.1 Refined Use Case
Rental
Figure 1 –Rental Use Case
36. 35
Babatunde, Sooraj, Fawaz, Timothy
We have made refinements to some of the initial ideas behind the use cases in the diagram
and also added in new processes. These changes are:
Sign Agreement:
In Figure 1, Members previously had to Rental Agreement manually, System solution
decided to change this process and make it electronic. In figure 2, the refined use case, a
Member is able to sign the agreement form electronically. This allows LSBU to upload to
digital form and safeguard against fire or loss.
Authorise Engineer:
In Figure 1, the rental clerk previously had to manually contact the engineer to authorise an
E-car. After thoughts about the process, we came to a conclusion that it is long winded and
therefore we wanted to make it easier. In Figure 2, the rental clerk authorises the Engineer by
sending a notification to the Engineers workstation. We believe this is a faster way of
communication between the rental clerk and the engineer, speeding up the process of the
customer receiving the e-car.
Car Packages:
One of the things we added to Figure 2 was the option of <Car Packages>. System Solution
believes customers should be able to choose their own package. This refinement came after
the client has requested for advice on expanding their business. We believe allowing
members to choose their car package will increase the groups of people that wants to hire a
car.
Figure 2 - Refined Rental Use
Case
38. 37
Babatunde, Sooraj, Fawaz, Timothy
The diagram shows the initial use case which System Solution came up with. It shows the
processes that happening between the Actors (Customer and Rental clerk) and the systems
(LSBU app system, Insurance System and the LSBU system).
The use case shows the interaction of the customer and the app when the customer is met
with an accident. The customer launches the app to fill out the accident form. They then take
pictures of the damages caused to the vehicle and then finally upload the accident form. The
use case shows the form being sent to both the LSBU system and the Insurance system using
an <<include>>. This means that the previous action must be completed for this to take place.
If only the form is uploaded then tit is sent to the corresponding systems.
Since this use case was initially meant to shows the process of Insurance, we’ve also included
late return of e-cars and the processes for it. The use case diagram also shows the rental
clerk’s interaction with the LSBU system. The rental clerk looks for any overdue vehicle in
the system. They also call the customer to let them know that they are overdue on their
agreement.
In the new use case we’ve produced for Insurance, we’ve taken out the rental clerk’s
interaction with the LSBU system looking out for overdue vehicles. System Solution believes
it’s better to have the rental clerk’s interaction with the system as a different use case that
shows late return. Another refinement we’ve implied on the use case is the process of the
customer contacting the insurer. We included this because the member has to contact the
insurer should their e-car breakdown. If the E-Car has a breakdown, the member has to call
up the insurer using the app. This will mean that the insurer will receive the relevant
information about who the member is because the member is logged onto the app. The
insurer will arrange for the repair/replace/recover and then will contact LSBU updating them.
This is <<included>> to the LSBU system. In the LSBU system, the member’s agreement is
updated.
40. 39
Babatunde, Sooraj, Fawaz, Timothy
Figure 1 is the initial proposed activity diagram for Rental which System Solution came up with. We
believe there are many flaws with this diagram therefore we decided to change it.
Figure 2 is the refined activity diagram which System Solution has come up with. It includes the
improvements which we believe is necessary. The improvements are:
Decision Nodes:
We’ve added in two additional decision nodes in the latest activity diagram. The first decision comes
after the card is scanned by the Rental Clerk. This decision node asks whether the card has been
scanned. If it’s successfully scanned then the process continues. If the card does not scan then then the
process is at a halt and ends with an end pseudo.
Another decision node we put in place is after the <<Payment Transaction>> process. This decision
node is called <<Successful>>. System Solution believes this is necessary because the process
shouldn’t be able to be continued if the payment successful has failed. If it fails, then the process will
come to a halt and the flow of activities will end with an end node. If the payment is successful then
the process carry’s on to the next activity which is <<Authorise Engineer>> before the Engineer
providing the e-car and the flow of activities ending with an end pseudo.
Car Packages:
Another inclusion of activity which System Solution has put in place is <<Choose Car Package>>.
We’ve put this activity node in because we are allowing the customers to choose their car package.
We believe customers should be able to choose their own package allowing them flexibility.
Insurance
41. 40
Babatunde, Sooraj, Fawaz, Timothy
This is the initial proposed activity diagram for Insurances which System Solution came up with. In
this system, the activity diagram contains two starting Pseudo. The first Pseudo leads you to the first
activity which is <Access LSBU App>>. The customer accesses the LSBU if they have an accident.
They can then <<fill accident form>> and <<upload>> pictures of the damages. Once this is done, the
customer uploads the accident form. Once uploaded, the accident form is sent to both the insurer and
LSBU system. The insurer reports the information from the report form onto their system and updates
the agreement. This finishes with an end node. The rental clerk also updates the member agreement
with the details of the accident. This flow of activities ends with an end node.
The second pseudo starts of at the LSBU system. This activity flow shows the Rental Clerk checking
for overdue E-cars on the LSBU system and contacting the customer. If the customer does not
respond the rental clerk then contacts the police and the insurer to alert them of the missing vehicle. If
the customer does respond to the phone call by the rental clerk, then their member agreement is
updated with additional fines/cost.
We realised that in the initial activity diagram there is no way of showing what will happen if the
customer has a breakdown and its slightly confusing because there are two insurance scenario
processes happening in one activity. To solve this problem, we decided to refine our existing activity
diagram to show the process of the customer contacting the insurer when they have a breakdown and
we also split the activity diagram. Now we have an insurance process that shows what happens when
the customer has an accident or breakdown and another activity diagram that shows what happens
when an e-car is overdue. We believe both these scenarios affect the insurance.
42. 41
Babatunde, Sooraj, Fawaz, Timothy
In the new activity diagram, if the customer has a breakdown or an accident, they access the app and
then we put in place a decision node, <<accident or breakdown>>, which takes the activities in two
pathways.
If the customer has an accident, they now access the app to fill out the form, upload images and
upload them. This is sent to both the insurer and the LSBU system. The insurer looks after the
“recovery/repair/replace” of the vehicle and is then updated in the agreement. The rental clerk updates
the agreement on the LSBU system.
If the customer has a breakdown, they launch the app and press a “call” button which is pre-
programmed on the app. This is a direct line to the insurer who will then look after the
“repair/recovery/replace” and they will update the agreement. The insurer will also contact the rental
clerk to update the rental agreement.
6 State Machine Diagrams
6.1 Rental (Tunde)
The above diagram is the Rental State Machine diagram derived from the Rental Activity
diagram. State Machine diagrams help to understand what “States” a machine may be in
during the Rental Process.
There are 5 States in the proposed Rental State Machine Diagram, The beginning Pseudo-
state leads to the first State <Available> during this State the machine is, a Guard Condition
called [Scan] guards progress to the next State. If a Membership card scans correctly,
progress is made to the <Security> State. The <Security> state is the stage at which the
Member’s details associated with the Membership Card are run through Security protocols.
A Guard Condition called [Checks] guards progress to the next State. A loop has also been
added to the <Security> state, if the Membership Card fails Security, the loop directs them
back to <Security>. If Security fails a number of times, the transition progresses to the end
Pseudo. If a Membership Card passes Security checks it progresses to the <Payment> state.
A successful payment transaction must take place at this stage. A Guard Condition has been
added called [Accepted], this guards progress to the next state. If a successful payment
transaction is not made, a loop has been added to the prevent progress to the next state. If
payment is accepted, the activity continues to the next state called [Paid]. At this state the
Member is provided will all the relevant details they need and relevant agreement to rent an
E-car. The final state is called <Rented>, at this State the transaction details are updated and
43. 42
Babatunde, Sooraj, Fawaz, Timothy
saved on the LSBU system. The Engineer is alerted to provide an E-car via his workstation
and the Rental State Machine Process is completed.
6.2 Maintenance (Sooraj)
The diagram above is the Maintenance State Machine diagram derived from the Maintenance
Activity diagram. The Maintenance process goes through 4 different states, Returned,
Maintenance Checks, Update and Available. The Maintenance process begins when a Rental
Agreement has expired and a Member brings back an E-car to the store.
The Diagram begins with a Starting Pseudo, the Pseudo leads to the first State called
<Returned>. At the <Returned> state a Member returns an E-car, the Rental Clerk scans the
Member’s card which leads to the next state called <Membership Checks>. If <Membership
Checks> fail a loop has been added to prevent progress to the next state. If <Membership
Checks> pass, two Guard Conditions called [Retrieve Agreement] and [Sign Off] have to be,
met before progressing to the next state. The transition moves to the next state called
<Maintenance Checks>.
At the <Maintenance Checks> state, the E-car is collected from the Member by the Engineer
who completes an Inspection of the E-car. The Engineer uploads a Service Report for the
returned E-car onto the LSBU system. There is a Guard Condition called [Inspection], this
has been added to prevent progress to the next state if Inspection of the E-car has not been
done. The LSBU system is able to differentiate if an E-car has passed or failed Inspection
based on the Engineers Service Report.
If the E-car fails Inspection the Maintenance process progresses to the <Update> state. At
the <Update> state, the Service Report is automatically sent to LSBU’s Insurer who prepares
an invoice for repairs needed to the E-car. The Maintenance State Machine Diagram then
ends with an Ending Pseudo.
If the E-car Passes Inspection, the Maintenance process progresses to the <Available> state.
In the <Available> state, the records are updated and the E-car is made available to rent on
the LSBU system. The Maintenance State Machine Diagram then ends with an Ending
Pseudo.
44. 43
Babatunde, Sooraj, Fawaz, Timothy
6.3 Insurance (Tunde)
The above diagram is the insurance state machine diagram derived from the insurance
activity diagram. The states mentioned in this diagram helps you understand what happens
during the insurance process.
The Insurance Process has two states, <Notification> and <Update>. There are four Guard
Conditions which must be met before completing the Insurance Process, these are [Fill form],
[Upload Pictures], [Update LSBU], [Update Insurer] and [Make Call]. There are 2 loops
attached to the Insurance State diagram.
The diagram begins with a starting Pseudo, the transition leading to the first state is named
(Accident/Breakdown). In the incident of an accident, the Member may utilise the LSBU E-
car App, reaching the first state called <Notification>. The Member must meet the three
guard conditions before transitioning to the next state. The Member must [Fill Form],
[Upload Pictures] before being able to transition to the <Update> state. If the two Guard
Conditions are not met a loop has been added to return the Member to the <Notification>
state therefore halting progress. If the Member meets the Guard Conditions, [Fill Form] and
[Upload Pictures] they can upload their Accident Report and transition to the <Update> state.
At the <Update> state the two Guard Conditions [Update LSBU] and [Update Insurer]. This
means both LSBU and the Insurer will receive the Accident Report. A loop has been added
to the Update state to prevent progress if the Guard Conditions are not met.
In the incident of a Breakdown, the Member may utilise the LSBU E-car App to contact its
Insurer. At the <Notification> state, the member must [Make call] to the Insurer before
transitioning to the <Update> state. The <Update> state has three Guard Conditions, [Update
LSBU] and [Update] or [Update Insurer] but in this situation, only the Insurer will be
Updated who then Updates LSBU via their system. A loop has been added to the <Update>
state preventing progress to the ending Pseudo.
46. 45
Babatunde, Sooraj, Fawaz, Timothy
7.2 Sequence
Rental
Sequence diagrams are used to show the interaction between objects in that “sequential”
order which they occur in (Bell, 2014).
The above diagram shows the rental process and the order of events that takes place when a
customer wants to rents an e-car. The input information for ‘createNewMember’ is sent
across over to the system. This is the process of registering a new customer to the LSBU
system. Once registered, the system returns a customer ID for the new member along with the
other information inputted at the start. This process shows the “customer” receiving their
personal ID which means they are now a “member” of LSBU Rental and can rent an e-car.
The second input is carried out by the customer who chooses the E-car package.
The member is able to choose their preferred e-car package from the LSBU system. Once the
member chooses an e-car, the relevant information about the e-car is given back to the
customer from the LSBU system.
Insurance
47. 46
Babatunde, Sooraj, Fawaz, Timothy
The above diagram shows the sequence of events that takes place in the event of an accident.
The customer fills in the accident form on the app by inputting the details of the incident and
parties involved. This accident report is sent to the LSBU system for the Rental Clerk to
access and to the Insurance system. The “AccInfo” from the App includes the details which
the member has filled in on the accident form. This is for the rental clerk and the insurer to
find out who the member is.
Maintenance
The above diagram illustrates the process that takes place when the engineer carries out an
inspection and is sent to the rental clerk. It begins with ‘Engineer’ who produces a report
based on the findings from the inspection. The “produceReport” on the diagram shows the
report being produced and the information that is on the report. This is sent electronically to
the LSBU system from the Engineers workstation. From the LSBU system, the rental clerk is
able to access this report and look the service report before deciding whether to contact the
customer should the report indicate any damages to the vehicle.
48. 47
Babatunde, Sooraj, Fawaz, Timothy
8 Testing
TC# Test Case Excecution Stage Expected Result
Test
Result Date Tested Tester TC Timer
1 A. Page pops up without error P 06/12/2015 1m
2 B. Login page pops up P 06/12/2015 1m
3
3. Username and Password enter A. Username and Password
Successfull
P
06/12/2015 1m
4 4. Fill in Form A. Form filled in without error P 06/12/2015 5m
5
A. Button Sign Agreement
successfull
B. Button Reset Successfull
C. Button Logout Successfull
P
06/12/2015 1m
6 D Button Search Successful P 06/12/2015 1m
7
8. Fill in Sign Agreement Form A. Sign Agreement form
successful
P
06/12/2015 5m
8
A. Button I agree and pay
successfull
B. Button Back Successfull
C. Button Reset Successfull
P
06/12/2015 1m
9 D Button Logout Successful P 06/12/2015 1m
10 13. Click Radio Button A. Radio Button Successful P 06/12/2015 1m
11
14 Fill Payment form A. Payment form filled in without
error
P
06/12/2015 5m
12
A. Button Submit and pay
successfull
B. Button Back Successfull
C. Button Reset Successfull
P
06/12/2015 1m
13 D Button Logout Successful P 06/12/2015 1m
15. Click button Submit and pay
16. Click on button Back 17.
Click on Button Reset 18.
Click Button Logout
Comment/(or Requirement
xref)
User rents car on e-car website
1. Open Browser
2. Click on Login
5. Click button Sign Agreement
6. Click on button Reset
7. Click on Button Logout
9. Click button I agree and pay
10. Click on button Back 11.
Click on Button Reset 12.
Click Button Logout
0 5 10 15
1
Untested Passed Failed
49. 48
Babatunde, Sooraj, Fawaz, Timothy
9 Research & Development
9.1 Automate & Improve efficiency
LSBU has requested that we develop plans to Automate and improve efficiency in all
business processes. With increased user advancements in businesses globally, consumers are
looking to improve systems to expand on automation. This relieves stress placed on
manpower and increases customer flexibility. The project team have been able to come up
with many solutions to automate and improve efficiency, which have been detailed
throughout this report.
Insurance
We have developed ideas for an LSBU app, which is used mostly for when the customer has
an accident or breakdown. This enables the customer to be able to fill out the forms on their
smartphone, once the form is completed images can be taken on the app and appended to the
form and the form can be sent across to the insurer and LSBU E-Car instantly, vastly
improving efficiency through the automated service.
There is a call button on the app for the user for an automated call service straight to the
insurer when necessary. This allows the customer to have a fast and efficient method of
contacting the insurer.
Automatic updates are set for the rental agreements for when new information is put in place
for when accidents/damages/no-returns occur. This update relays information to the insurance
automatically as well without having to send out physical documents or create an email with
all the information.
Rental
Another form of improvement to automation is the possibility to make a booking via the
mobile app. This enables the customer to book a rental vehicle through the app as opposed to
having to go into store to do so. This reduces customer time spent in store and enables the
staff of LSBU E-Car to offer a vehicle a lot quicker than if they came and tried to select a
package in store. Furthermore, many vehicles go out on hire daily so to ensure the customer
gets their desired package it would be best to book prior to arrival in advance of the date
preferred.
When a customer decides to come into store to rent a vehicle they have to sign the agreement,
once they have chosen and paid for their desired car. To improve the efficiency, the rental
clerk would provide a signature pen and pad where the customer then can create an electronic
signature which goes straight onto the agreement. This reduces the time the customer spends
at the rental store as the rental clerk doesn’t have to print of the entire agreement in order for
the customer to sign it and for the rental clerk to scan it back onto the system thus improving
efficiency through the automated electronic signature.
Maintenance
With maintenance playing a vital role in keeping vehicles legal, ensuring LSBU E-Car
business doesn't encounter any losses, damages, no returns, un-roadworthy etc. provisions are
in place to hold regular checks.
When a vehicle is returned by a customer an automated message from the system is sent to
the engineer to inspect the vehicle as soon as possible. This allows for a car to be thoroughly
checked once so that if there are no problems in the engineer report, then the vehicles can go
back on the road straight away. This benefits LSBU E-Car as it will increase the number of
50. 49
Babatunde, Sooraj, Fawaz, Timothy
hire cars that are available to go back on the road giving more of an efficient service to the
customers with more cars being in stock and more revenue being made on the daily rentals.
The automatic updates allows for the engineer reports to be sent over to the insurance
instantly by the rental clerk.
9.2 User Interface
LSBU has requested research and Development expertise on how to design a new website to
manage their daily operations. System Solutions have good knowledge in website design and
we utilised those skills to produce solutions we believe are current and adaptable for future
expansion.
LSBU does not currently have a website, this is unimaginable for a company that is at the
forefront of renting modern Electronic Cars to the public. System Solutions have decided that
LSBU needs a Website to direct their customers to and a mobile application available to
download on all platforms for Members to communicate with LSBU and their Insurer.
Home Page
51. 50
Babatunde, Sooraj, Fawaz, Timothy
The diagram above is a representation of what we believe the LSBU E-car Website should
look like, it provides the customer the ability to communicate with LSBU and make use of its
E-car Rental services. The website also allows LSBU to push information to customers via
the website, things like promotional packages, User Experience Stories and FAQ. Having a
website will reduce the amount of calls to the Rental Clerk allowing him/her to attend to
other tasks. The Menu button can be placed at the top of the pages to help the user navigate
the site. The Login page is available for anyone to access, but only authenticated Members
are allowed further access. The Login page allows Members to access the Online Rental
Process, their account information and information about their E-car. If a Member is
authenticated they can reserve a car, choose an E-car Package that suits their needs best. The
Member will then have to pay for the choices made during the Online Rental Process. If
payment is successful, the Member’s rental specifications are electronically updated on the
LSBU system ready for the Rental Clerk and Engineers attention.
LSBU Mobile Application
The diagram above is a representation of what we believe the LSBU E-car Application
should look like, it provides the customer the ability to communicate with LSBU and its
Insurer in the event of an Accident or Breakdown. A Member may communicate details of an
accident to LSBU & its Insurers by accessing the LSBU E-car Application to upload pictures
of an Accident, fill in, and send Accident Report. LSBU can also use the Mobile application
to collect user location data which can be used for targeted marketing and business decisions
52. 51
Babatunde, Sooraj, Fawaz, Timothy
9.3 Automated Mail outs
LSBU has requested methods of producing and sending out automated Promotions and
Discount mail outs to customers. System solution came up with a way of implementing this
by giving the customer the option to opt in to receiving marketing mail on the membership
form during the membership process. A Member may login via the app or the website and opt
in or out online. The member may also and opt in or out in store the rental clerk is able to do
this. The rental clerk will scan the Membership Card and alter preferences to the Member’s
taste. When a customer chooses to opt in to the mailing list, their email will be added to a list
of Members who have agreed to opt in. A template email needs to be set up by LSBU and
updated regularly with current discounts and promotions. Macros can then be set up to mail
merge the list with the template. These emails will be sent out automatically to all the
Members that have opted in to mailing list. The macros can be set up to email the customers
at a certain time or the rental clerk can send to everyone by a single click during promotional
periods. If emails need to be sent to a selection of Members alerting them about discounts
that match their previous needs, macros can be set up in database which will look up for all
the Members that fit the criteria and Emails may be sent to them.
There are laws which LSBU needs to be aware of before they think about direct marketing to
customers. By law, you must check if the customer wants to be contacted by email or in any
other means of communication. You must get permission from them if you want to send them
promotions or offers. The customers also hold the right to opt out of mailing list if they want
to. When sending emails to customers, it is within law that you must clearly state who you
are, what the promotions are on offer and whether there are any conditions.
The project team believes the ability to target segments of current and previous Members
whose details are held in the database hold is invaluable to the future of LSBU’s E-car
Business.
9.4 Reports
Information systems such as the one described in our proposal are powerful beyond any
human’s capability, with the click of a mouse it is possible to generate useful data which can
be used in day to day activities in the organisation and most importantly by Administrators
and Managers to hone in on their target customer. Currently information is in paper form
which means human beings have to sift through documents to make any meaningful use of it.
The proposed system will include a database that stores details of Members who have opted
in to receiving marketing mail from LSBU.
The necessary infrastructure is there to allow LSBU to create Reports suited to the user, a
Customer Relations Management (CRM) tool will need to be purchased to manage the LSBU
system in conjunction with the database. The CRM will provide the interface in which
member of Staff can interact with the business but most importantly run reports based on
their job roles. The project team have outlined some possible reports for the following job
roles within the LSBU E-car business.
53. 52
Babatunde, Sooraj, Fawaz, Timothy
Admin/Manager
Sales reports – a list of all rental during a specified amount of time which the user may
specify
Staff report – a list of all staff members working at LSBU and their personal details
Car reports- a complete inventory of the company E-car fleet updated daily
Inspection reports – a list of all cars that failed inspection from the Engineer
Member reports – a list of all current member showing how many E-cars they may have hired
if any.
Banned – a list of all ex Member, and an option to ban a Member for misuse of an E-car
Agreement reports – a list of all outstanding rental agreements waiting to be signed off for
various reasons.
Rental Clerk
Member reports
Car reports
Agreement reports
Inspection reports
Engineer
Car reports
Member reports
Inspection reports
Reports are effective at turning Data into useful information, such targeted information can
be utilised by LSBU in the marketing promotions and as a cost management tool. The
project team expect LSBU’s E-car Company to grow and with this proposed improvement
they will be able to better manage their customers.
9.5 Electronic Payments
Electronic Mobile Payments is the method used when a customer pays for goods or services
on a Smartphone. This technology has only recently gained momentum, due to
improvements in smartphone manufacture. Manufacturers and software developers are racing
ahead in finding new ways of utilising the power of a Smartphone.
LSBU has requested research on how to accept Electronic Mobile Payments from their
Members. The project team has outlined details on what an LSBU E-car Application would
look like in this report previously. The Mobile App can be used to direct Members to
information and services they need and Members can also make reservations and pay for
services. The LSBU website will need a method of collecting payments from Members, the
following are methods that may be utilised by LSBU:
Credit/Debit Cards- is a payment card issued to users (cardholders) as a method of payment.
It allows the cardholder to pay for goods and services based on the holder's promise to pay
for them.
54. 53
Babatunde, Sooraj, Fawaz, Timothy
Cloud-based mobile payments:
Google Wallets – is a payment system which Google has produced. The name speaks
for itself; it allows customers to add their existing account (credit cards, debit cards,
loyalty card, gift cards) on their mobile app. This acts like a wallet that allows
payment transactions to take place using NFC (Near Field Communication). Another
way in which Google wallets can be used is to transfer the money from the account
holder to the other account.
PayPal – is a similar system incorporated by Google Wallets. It also allows payments
to be made through the internet. PayPal is one of the safest methods of payment. It’s
free to use and allows you to store all your accounts in one place.
The Project team believes payment transactions made via the LSBU E-car app should be
done via Debit/Credit card on a secure 3d authorisation screen. The Member would receive
an email confirming their payment and their chosen car package. The member can then go
into store and collect the vehicle after producing their reference number attached to an email
and their ID and no further payment is required on site. Cloud-based mobile payments are
also on the increase in terms of usage. A link can be added to the Payment form on the LSBU
E-car app which directs the Member to a Cloud-based mobile payments site, allowing them
to pay for rentals.
9.6 Visualization of GPS tracking
LSBU has requested research on the possibility of introducing visualisation of GPS tracking
data on all E-cars. Visualisation of GPS tracking involves being able to see where any of
LSBU’s E-Car is and how it is being used. This service is not alien to the motoring industry,
most insurance companies have an option called “Black box”. A Black box provides the same
service as the GPS module we wish to install in all LSBU E-Cars. A company called ‘Insure
the Box’ offers this service currently and it has been very successful for them (Insure the Box
2015).
LSBU’s E-Cars are currently fitted with a hidden tracking device which is monitored by
LSBU’s Insurer. In the event of loss/theft of an E-car, LSBU must contact their Insurer for
data relation to the location of the E-car. In order to be able to utilise data relating to E-cars,
LSBU must do one of the following things:
Re-address the contract they have with their Insurer relating to hidden trackers on
their E-cars
Gain live access to data relating to E-cars.
Install their own “Black box” in all E-cars
The project team believes that LSBU should install their own “Black box” on all E-cars, this
will vastly improve their current business allowing them to gain insight into Member
behaviours. The “Black box” must be accompanied by Visualisation software, this maps the
Member’s route which can be relayed to the Rental Store servers ready to be accessed if
needed. If a Member is involved in an accident, the Rental store can review the Member’s
driving pattern, route, speed, braking etc. and respond accordingly.
LSBU can improve efficiency vastly by incorporating this technology with their E-cars.
55. 54
Babatunde, Sooraj, Fawaz, Timothy
This will remove external stakeholders like the Insurer who is currently tasked with
monitoring of LSBU’s E-cars.
9.7 Business expansion
LSBU requires new research and development on expanding its business model to allow
longer term rentals and within 2 years, increase its E-car stock by 150% opening 3 new
branches in North, East and West London. System solutions have good knowledge on the
current LSBU systems and were perfectly placed to deliver the opportunities LSBU craves.
System Solution has already proposed the idea of GPS tracking previously in this document.
GPS tracking can help LSBU determine suitable locations for opening new stores. Every
E-car will be fitted with a GPS tracker, it monitors the E-car and collects data about the
member’s use of the E-car. The date collected is reported back to the LSBU system. This data
will need to be sorted through and transformed into useful information about Member usage,
this will help LSBU know and target the geographical layout of their current Members. This
approach to Data is becoming more and more common in organisations, by deploying such a
tactic LSBU will have a better indication of where a new Store might be placed. Customers
are more likely to rent an E-car if the Rental store is close to where they live so it is easy for
them to pick up and drop off. The benefits of having multiple branches will also mean that
the customer can drop an E-car off to multiple branches; it doesn’t have to be the one they
picked up from. This will give the Member more flexibility when it comes to the end of their
contract, they can drop off to their closest branch.
LSBU aims is to increase their stock by 150% by the end of year two. Starting off with a fleet
of 400. In order for LSBU to increase their stock, they need to have the sufficient funds
available to purchase new E-cars. The project team believes it is a “big ask” to expect a small
organisation without an Online presence to increase their stock by 150% by the second year
of operation. The proposals brought continuously in this report will aid to increase revenue
for LSBU but there will be a shortfall. The project team also believes that it may be possible
to gain financial backing by finding an Investor to cover the shortfall. This may mean giving
up some of the profits to the Investor but the ends justifies the means.
Another way of increasing profits and expanding the LSBU business is by offering customers
Long Term Rentals. Currently LSBU offers a one day agreement for customer. This could
reduce the number of customers that use their service. LSBU should offer longer Rental
Agreements for any kind of any E-car Package the Member may choose. The project team
also believes that LSBU should entertain the idea of having Long Term Rentals that leads to
the Member being given the opportunity to purchase the E-car. A member may sign a Rental
Agreement for 2 years, when the Rental Agreement ceases LSBU may offer the Member the
opportunity to purchase the E-car. A Customer with a long term need of a car may find this
the perfect opportunity to own a car.
56. 55
Babatunde, Sooraj, Fawaz, Timothy
10 Conclusion (Tunde)
Conclusion
The LSBU E-car project has been a long but rewarding journey, The Team assigned to this
project gained insight into the current LSBU operation and wider business environment.
At the start of the project the System Solutions set the goal of providing concrete
technological improvements to LSBU’s business. The existing LSBU business may be fit for
its current purpose but any plans of expansion in its current state will definitely fail. The
business is feasible and provides a unique approach to current concerns about emissions and
climate change.
The Member journey in the current system was very dated which limits its expansion
capabilities. The project team outlined ways of improving membership process that is fit and
capable of allowing LSBU to meet its future plans. The removal of a redundant role in the
process will reduce payroll which can be invested in other aspects of the business.
The most critical section to the success of LSBU is the Rental process, the solutions outlined
in this report takes into account all the current procedures necessary for a Member to
complete the rental process. Improvement will work in cohesion with the current system but
with new technologies driving it forward.
The fixed assets of any organisation are important to the longevity of its business model. The
project team has detailed methods of keeping LSBU’s most valuable assets (E-cars) safe and
in tip top condition. Members who are now able to rent for longer will feel the benefits of the
improvement which will hopefully reflect on the LSBU’s profits.
Systems Solutions has gone beyond the call of duty and actually created blueprints for a
proposed website and application. This will help LSBU get its value proposition to its
customers directly, while offering discounts and promotions to keep them loyal. Online
operations allow LSBU to collect information about their Members for marketing purposes.
Big data is increasingly being used by organisations to monitor and target customers and will
be a welcome addition to the new LSBU System.
The project team has worked hard to find solutions to LSBU’s business and we believe the
proposal brought to you in this document should be implemented in its entirety.
60. 59
Babatunde, Sooraj, Fawaz, Timothy
11.3 Team minutes
MINUTE 1
Discussion of Completed Work Brought to Meeting
This was our first discussion on strategy, the team decided on the following:
● Collect each other’s numbers, email, telephone
● Create Google drive folder for us to share and collaborate on the project
Discussion of Scheduling of Future Work
The team decided to complete the following tasks before the next meeting:
● Familiarise yourself with the case study (Everyone)
● Create use cases based on the current system (Everyone)
● Create a Gantt chat (Fawaz)
● Prepare minutes template (Tunde)
Any Other Business
N/A
Meeting Prepared By: - Tunde
Meeting Attended By: - Name:-Tunde, Fawaz, Sooraj, Timothy
Date: - 19/10/2/2015
61. 60
Babatunde, Sooraj, Fawaz, Timothy
MINUTE 2
Discussion of Completed Work Brought to Meeting
Tasks from 19/10/15
1. Familiarise yourself with the case study (Everyone)
Is it complete? - yes, everyone is on track with the case study
Is it acceptable to the team? - Yes
If not, what does the team require and by when? - N/A
Who failed to meet a deadline and why? - N/A
What help/support can the rest of the team offer? - N/A
Are there implications for project scheduling? - N/A
2. Create use cases based on the current system (Everyone)
Is it complete? - No
Is it acceptable to the team? - No
Who failed to meet a deadline and why? - Tunde, Fawaz
If not, what does the team require and by when? - Team has decided to meet up on Tuesday
and complete the initial use case and any outstanding work.
What help/support can the rest of the team offer? - N/A
Are there implications for project scheduling?- No, because the gantt chart is not completed
but issues may arise if the situation continues.
3. Create Gantt chart (Fawaz)
Is it complete? - No, initial draft was set up
If not, what does the team require and by when? - to be completed in class
4. Template for minutes
Is it complete? - Yes
Discussion of Scheduling of Future Work
Is the assignment schedule as in the contract?
If there is slippage, how does the team plan to recover? - The team has decided to meet up
every Tuesdays at 12pm for an hour to catch any slippage.
Is everybody clear about new deadlines that affect them?- Yes.
Any Other Business
Minute Prepared By: Sooraj Subash
Meeting Attended By:
Name:-Tunde, Sooraj, Timothy, Fawaz
Date: - 26/10/15
