NSF Business & Operations Advisory Committee Meeting NSF Business Analysis Project Status
Business system analysis project
21
Business System Analysis project Jordan Hughes 14394686 Renatt Verbruggen
-
Upload
jordan-hughes -
Category
Documents
-
view
44 -
download
1
Transcript of Business system analysis project
Business System Analysis project
Jordan Hughes
14394686
Renatt Verbruggen
Use Cases
Check/Repair van
DESCRIPTION Step Action
1 Mechanic receives van
2 Mechanic carries out checks
3 Mechanic finds problem with van
4 Mechanic fixes issue with van
5 Mechanic returns van after issues are solved
6 Repairs recorded on system
Collect van
DESCRIPTION Step Action
1 Customer makes booking
2 Customer arrives on given date
3 Customer shows booking reference
4 Customer receives van
5 Customer drives away
Return van
DESCRIPTION Step Action
1 Customer returns van on requested date
2 Customer shows booking reference
3 Van is checked for damages
4 Van is marked as returned on the system
5 Customer is issued with invoice for van
Request/accept booking
DESCRIPTION Step Action
1 Customer requests to hire a van
2 Customer gives details for booking
3 Customer receives booking order
4 Customer accepts offer
5 Customer gives details for the order to be marked on the
system
Check availability
DESCRIPTION Step Action
1 Customer rings up with booking request
2 Staff check system for customers request
3 Systems returns information about availability
4 Customer can make a booking
5 Van not available and order is lost
Charge fines
DESCRIPTION Step Action
1 Customer returns van
2 Customer has broken contract
3 Fines calculated
4 Customer issued with invoice containing fines
Register/remove van from system
DESCRIPTION Step Action
1 Staff receive new van
2 Staff add new van and relevant details to the van system
3 Old vans or damaged vans are removed from the system
4 System updated
Contact supplier
DESCRIPTION Step Action
1 Order is received
2 Staff contact supplier and place order
3 Supplier orders in required van
4 Supplier delivers van to company
5 Supplier receives payment for order
Use cases (Cockburn Template)
USE CASE 1 Check information
Goal in Context Customer makes a query to our company, expects to find out the
necessary information to make a decision
Scope & Level Company
Preconditions We know they need information about our company and our
services.
Success End
Condition
Customer has the relevant information they needed.
Failed End
Condition
We don’t have the information about the customer’s request and
they don’t make an order.
Primary,
Secondary Actors
Customer, staff.
Credit card company, bank,
Trigger Query from customer comes in.
DESCRIPTION Step Action
1 Customer calls in with a query request
2 Find out what the customer is looking for and take down
relevant details.
3 Staff check the van management system for the necessary
information to answer customers query
4 Staff receives information from system
5 Staff pass on the desired information to the customer
6 Customer has all information needed to make a decision.
7
EXTENSIONS Step Branching Action
2a Customer carries out independent research
3a Staff consult the van management system
5a Customer unsatisfied with information returned
VARIATIONS Branching Action
6a Customer goes somewhere else to book
RELATED
INFORMATION
Current bookings, reservations ,if it is a previous customer
located on the system
Priority: top
Performance Less than 5 minutes per transaction
Frequency 3 a week
Channel to actors Verbal, digital
OPEN ISSUES
Due Date Until completed
...any other
management
Information...
Superordinate’s Manage customer relationship through system(use case 2)
Subordinates
USE CASE 2 Making a booking
Goal in Context To book a van
Scope & Level Company
Preconditions Customer has contacted the company
Success End
Condition
Customer makes a booking and we collect money for order
Failed End
Condition
Customer doesn’t book a van
Primary,
Secondary Actors
Customer, company
Bank
Trigger Customer needs a van
DESCRIPTION Step Action
1 Rings up company
2 Staff check system for van availability
3 Creates booking with details
4 Order recorded on system
5 Customer collects van
6 Customer returns van
7
8
Payment received
System updated
EXTENSIONS Step Branching Action
2a Staff check van management system
5a Customer doesn’t collect van
6a Customer doesn’t return van
VARIATIONS Branching Action
7a Customers pays in full
2a
Van not available
RELATED
INFORMATION
Priority: top
Performance Less than 5 min
Frequency 3 a week
Channel to actors Verbal, digital
OPEN ISSUES
Due Date Determined by user
...any other
management
Information...
Superordinate’s Maintain customer relationship
Subordinates Document order and take for it using credit card or other
payment method
Class Name: Customer ID: 1 Type: Concrete, domain
Description:
The person who is looking to rent a van
Associated Use Cases:
3
Responsibilities Collaborators
Contact van retail company
Booking
Choose desired van type
Organise booking
Collect van
Collect
Return van
Return
Pay for van
Attributes
text
verbal
Relationships booking
Generalisation (a-kind-of)
Person
Aggregation (has-parts)
Other Associations
Class Name: Supplier ID: 2 Type: Concrete, domain
Description:
The person who supplies the company with the
Necessary van to facilitate an order
Associated Use Cases:
1.
Responsibilities Collaborators
Receives order
order
Gets van required
Delivers van
Collects payment
payment
Attributes
Relationships
Generalisation (a-kind-of)
Person
Aggregation (has-parts)
Other Associations
Class Name: Mechanic ID: 3 Type: Concrete, domain
Description:
The person responsible for checking and maintaining the vans
Associated Use Cases:
1.
Responsibilities Collaborators Check van
van
Repair van
Return van
Sequence diagram/Communication diagram part 1
Sequence diagram/Communication diagram part 2
Summary:
Starting off I read the case summary in details making notes of what system
was required and what conditions orders were made under. I created a list of
the use cases and actors involved in the case study because they are necessary
to carry out the functions of the van hire business. I then made a use case
diagram showing the relationship between actors and use cases and so on.
Two of the uses cases were put into the Cockburn template giving them a
detailed run through of what’s involved and expected from each of them
including extensions and variations.
I then put three of the use cases into a crc card showing processes,
attributes and collaborators associated with each of them. These are helpful
when modelling the class diagram which is a diagram showing the structure of
the business with the classes attributes. I then made two sequence diagrams
which illustrate two important processes necessary for the van hire company
to carry out their business. Branching from the sequence diagrams I made two
communication diagrams which is used to show how objects interact with each
other in a process being carried out.
After this was completed I chose to make a state diagram based around
a customer. The state diagram is used to show the developments of a
customer during the whole booking a van process. For the last part of the
project I made a package diagram showing the organization of different parts
of the system and how they depend on each other. Along with that I made a
deployment diagram showing the physical architecture of the system and how
it all relates to each other also a component diagram to show how components
are connected together to add to up to make larger components part of one
large system.
Assumptions I made in the project are that the customer contacts the company
through phone and only the company staff access the van management
system. Payment for booking is taken after the customer returns the van and
the total price including/excluding fines is issued.
