MITS5502: Software Engineering Case Study Analysis for Sunshine Motors

This case study analyzes the requirements for a vehicle mechanical service company system, "Sunshine Motors", detailing the development of a comprehensive software solution. The document includes an executive summary, system description, and a defined scope encompassing various functionalities like inventory management, customer and vehicle details input, mechanic scheduling, work order creation, and payment processing. A feasibility study assesses economic, technical, and operational aspects, identifying potential risks and proposing solutions. The requirements specification outlines both functional and non-functional needs, supported by use cases, diagrams, and context models. The analysis covers aspects like inventory management, customer relationship management, and mechanic scheduling. The solution aims to replace a manual system, offering scalability, efficiency, and improved data management. The system is designed to be scalable, allowing for the addition of work bays and new parts/consumables. It includes mobile and web interfaces for database updates, and aims to streamline operations, improve customer service, and enhance overall business efficiency. This document provides a detailed analysis of the project's objectives, scope, and implementation strategy, making it a valuable resource for understanding software engineering principles and project management. The document is a contribution by a student and is available on Desklib, a platform providing AI-based study tools.

CASE STUDY ANALYSIS
Software Engineering Methodology
Specification Document
The Name of the Class (Course)
Professor (Tutor)
The Name of the School (University)
The City and State where it is located
The Date

CASE STUDY ANALYSIS
Table of Content
Executive Summary.........................................................................................................................3
System Description..........................................................................................................................4
Main Objective.............................................................................................................................4
Specific Objectives......................................................................................................................4
Scope................................................................................................................................................5
In scope........................................................................................................................................5
Feasibility Study..............................................................................................................................6
Economic Feasibility....................................................................................................................6
Technical Feasibility....................................................................................................................6
Risks.........................................................................................................................................6
Solutions...................................................................................................................................7
Operational Feasibility.................................................................................................................8
Schedule Feasibility.....................................................................................................................9
Requirement Specification.............................................................................................................10
Functional Requirements...........................................................................................................10
Non-Functional Requirements...................................................................................................12
Assumptions/Constraints...............................................................................................................13
Use Cases.......................................................................................................................................14
Use case diagram.......................................................................................................................14
Use case descriptions.................................................................................................................15
Actors.....................................................................................................................................15
Context Model...............................................................................................................................17
Leveled Set of Functional Models.................................................................................................18
Data Flow Diagram....................................................................................................................18
Flow Chart..................................................................................................................................19
References......................................................................................................................................20
Table of Figures
Figure 1: Use case diagram............................................................................................................15
Figure 2: Context diagram.............................................................................................................18
Figure 3: Data flow diagram..........................................................................................................19

CASE STUDY ANALYSIS
Figure 4: Flow chart.......................................................................................................................20
SPECIFICATION DOCUMENT
Executive Summary
This project is a vehicle mechanical service company system for “Sunshine Motors”
which does not have a previously created system because the current one was manual. The
project is supposed to help manage the vehicles that are being brought to the company premises
together with their owners. The mechanics who are available within the day are assigned to the
tasks according to their expertise and if a car is still needed by the owner, they will be loaned one
by the company. The system should be scalable allowing for addition of Work Bays and addition
of new parts/consumables needed within new/upcoming jobs. A work order is treated as a
session which begins when placed and is closed once the job is done sending a notification to the
customer and creates an invoice for the job. When the customer comes back, they pay for the
invoice and the invoice is flagged closed but in case of users within the system, the invoice is
added to the monthly invoice. The project will have both mobile and web interfaces that will
help in the updating of the system database details.
The proposed project is supposed to solve the manual keeping of records in a way that
accommodates all the company data and provide scalability in case the company decides to
increase their business scope for example the expansion to the neighboring area. The company
should be able to easily increase their business by either adding data into the database as well as
adding of new modules which interact with their system.
This section describes what is expected by the user:

CASE STUDY ANALYSIS
System Description
The system is supposed to keep records for inventory of car parts used for fixing the cars
and also accept input about the cars being fixed and the customer details. Mechanics are
registered and put on a schedule and according to their skills. Work order jobs are to assigned
according to the mechanic’s specific skills. In case the job is done an invoice is created and sent
to the customer that has been created including both labor and the inventory that has been used
up. The payment is then made according to the invoice sent to the customer. In case the invoice
payment is not fully made the sales writer may set it to ‘pending’ or ask the customer is asked to
complete their payment. which may remain pending if the full payment is not made at the
moment.
Main Objective
The main objective of the system is to create a control system for Sunshine System
motors activities.
Specific Objectives
 Incrementing and decrementing of inventory.
 Inputting of car and customer details for car servicing.
 Adding of mechanics.
 Creation of various skills needed within the company.
 Creation of work orders and their sessions.
 Creation of a payment module for services.
 Allowing for loaning of cars needed by customers.
 Addition of work bays

CASE STUDY ANALYSIS
Scope
In scope
 Booking of services.
 Purchasing officer can add inventory.
 Adding of available work bays.
 Adding of the car and customer details by the roadway staff.
 Loaning of available cars to the users that accept company services.
 Adding of the mechanics, their details and skills.
 Creation of roster for the mechanics.
 Creation of work orders and their sessions by the service writer.
 Mechanics add of inventory used for a specific work order.
 Decrementing of the inventory and notification in case of low quantities according to
threshold.
 Closing of session for work orders once they are completed
 Notification of customers of work order completion.
 Creation of invoices and sending to the customer.
 Payment confirmation by the service writer and changing its state.
 Creation of reports for the whole process.
 Tracking of loan car mileage to allow for constant servicing.

CASE STUDY ANALYSIS
Feasibility Study
In order to make sure the system will have a positive improvement within the business
compared to the previous manual system, the system pros are analyzed and weighed against the
cons. In case the pros are more than the cons or the disadvantages have minimum impact on the
business, the new system should be adopted or the previous system upgraded.
Economic Feasibility
Cost Benefit Analysis
The project will increase the cost benefits of the company. Previously, the tasks have
been stored within manual records. This led to financial tracking of transactions to become
hectic. Keeping records of the inventory used was manual. Tracking of the company records
sometimes would become hard leading to unforeseen losses. This led to the inability to keeping
of track of the used inventory therefore would have led to losses in case it was not updated.
Customers would therefore not use the company services in case they were impatient. The
accounting team was also unable to keep track of the monthly statements, processing of payment
and the reporting of the financial transactions.
The system will help enable the reporting of all the business transactions. In case the inventory is
used, the system will update the pricing in the work order which will be used in the invoice for
billing. This will improve the transaction speeds that will help in in keeping track of the
transactions.
Technical Feasibility
Risk assessment and solutions
Risks
o Failure to service the loan cars leading to failure as well as losses.
 Risk Level: Low
o Failure to tracking of payment that has not been completed
 Risk Level: High
o Failure to update/ purchase of the items that have been logged
 Risk Level: Medium

CASE STUDY ANALYSIS
o Minimum entries of inventory
 Risk Level: Low
o Loss of data
 Risk level: High
Solutions
o Failure to service loan cars may be mitigated by creating a timer on the loaned car which
is tripped once a specific amount of time elapses. The odometer values may also be
recorded and kept track off such that they may be
o Failure to track payment of those who are allowed to pay a section of the total may be
mitigated by collecting all the legal data needed in case of a legal issue.
o Failure to update or purchase the items logged may be solved by creating a notification
system while the items are being logged which will notify the purchasing officer as well
as make purchases or send notification to the supplier.
o Low number of entries may be an issue when the scalability of the project is questioned.
The number of entries may more than the capacity of the databases of the system which
may cause functionality issues. This may be solved by the use of a No-SQL database or
an SQL database that may accept a large amount of data.
o Loss of data. This may happen to any system but may be solved by the creation of
redundant data stores for example on different locations or use of an online database.
Backup of the whole database is the most efficient which are then restored in case of
failure.
Most of the risks arising from this project are all solvable by introducing custom modules
within the system which will help solve the issue.

CASE STUDY ANALYSIS
Operational Feasibility
Control efficiency and services
The previous system was a bit archaic and control over it was hectic due to different
working areas such as front office, road staff, mechanic and service writer. When a customer
appears, each section of the business needed to move manually to update each section in order to
allow for the transactions to occur. This system is a bit illogical and may end up causing issues
and normalization of the data would not be achieved.
When the new system is introduced, once a customer enters the front office, they are able
to be recorded together with their vehicle details. The same details are then used by the service
writer to assign a work order after an issue is raised. The mechanic with the specific skill is
assigned then assigned to fix the car and the details are recorded within the work order. In case a
car loan is needed, the user details collected at the front office are used to loan an available car.
When the work order is done the customer is then notified immediately.
All these functionalities are placed within a single system and a single administrator
report area may be used to view all the details of the operations of the system. The administrator
can monitor all the functionalities and find issues within the system or business operations.

CASE STUDY ANALYSIS
Schedule Feasibility
Timeline optimization and optimizing resources
The amount of time needed for the previous system was high due the movement from one
location to the other to update various sections of the business was not optimum.
Different working areas such as front office, road staff, mechanic and service writer
needed to move around to update the various sections or a new record was created in its stead.
The amount of time that was used and creation of records was not optimum making labor needed
for the system to be too much. Renumeration for the workers as well as a probable reduction in
number of workers would increase the company budget if the system is not adopted. The
customer confirmation of a work order would then be done on schedule. They would either come
after a specified period of time or they would be texted or called.
When inventory was used, the manual change in the inventory details in the log was not
optimum. In case of the lack of an inventory item the manual notification through a log or
movement to the purchasing officer to notify them would take a lot of time.
The system to be introduced will require a single input section therefore reducing the
amount of time required to update records of the customers as well as the labor reduction on each
section. Customers are automatically notified on completion of the work order once the
mechanic is done. The mechanic updates the inventory that has been used to the work order and
removed from the inventory.
The new Sunshine motors system will allow for the changes of inventory directly and
updating of the inventory once a mechanic uses an inventory item. In case the amount is lower
than a specific threshold an alert is tripped therefore notifying the purchasing officer of the
dwindling amount within the inventory.
The system will in the long-run improve the amount of time used as well as the amount
of resources used within the business. This will create an optimum environment for the
functioning of the business. Each section of the business will act independently on a central point
of data which they manipulate.

CASE STUDY ANALYSIS
Requirement Specification
Functional Requirements
 Updating mechanics
An administrator should be able to update the mechanics together with their details,
assign them skills and provide them with a work schedule.
 Updating loan cars and view servicing history
Cars available for loaning are input here together with their photos in order for a
customer to confirm the specifications. The administrator can also view the servicing
history for both the loan and customer vehicles.
 Updating customer details
Customers are inputted at the front desk where the customer provides their details to be
used for processing the car and payment.
 Updating vehicle details
Vehicles are inputted at the front desk and mapped to their owner and the issue being
faced by customer are added and the skill needed for servicing and repair determined.
 Updating inventory
Items required for repair or servicing of the vehicles are added by the purchasing
manager.
 Creating work bay
The administrator adds work bays manually in order to allow for the change or addition
of work bays as well as rendering of the status.
 Car loaning
The cars are loaned to a customer accessing a service in case they are available and then
changed to unavailable when the cars are loaned out.
 Creating skills
Skills are created for the mechanics in order to determine the capabilities of the users.
 Creating work schedule
A work schedule is created by the system administrator accommodating the mechanics
giving them a day off and a stand-by day in case of emergencies.
 Creating work orders and their sessions

CASE STUDY ANALYSIS
A service writer is able to provide the tasks to the mechanics for a work order. They then
start a session for the work order once the task is begun. Once the mechanic finishes
working on an order, they close the session for the work order.
 Assigning of mechanics
A mechanic or several are assigned to a specific work order according to the skill needed
to service or repair a vehicle.
 Notifications
Once an order is finished, the system notifies the customer of the finished order and sends
them an invoice for the job.
When a mechanic uses inventory and it goes beyond a threshold, they system updates the
purchase manager of the need for new items.
In case a mechanic finds that the inventory items are not available, they are logged and a
notification is sent to the purchase manager and supplier for the purchase.
 Payment for services
Services rendered are either paid in cash or through a payment module, that is, PayPal or
a bank card, that has been integrated into the current system.
 Invoice creation
An invoice for the work orders created provided with the pricing according to the skill
needed required for its completion.
 Payment confirmation
A service writer is able to confirm the payment made by a customer for the vehicle. The
customer can then pick up their car.

CASE STUDY ANALYSIS
Non-Functional Requirements
 Performance
The system should be able to easily perform the tasks provided such that the system
should easily move between modules without issues and each section of the system
separated according to the various work areas are functional without hiccups.
 Scalability
The system needs to be increased in size in that, in case a new section of the project is
created the system is able to accommodate the new feature. For example, creation of a
new work schedule or addition of a new work bay in the neighboring area.
 Capacity
The number of items that can be added to the database for example for the inventory is up
to 500 items. However, the number may be increased by changing the amount, database
type (SQL to No-SQL) or the database.
 Availability
The system should be available as broken down to the various work stations. The system
should also be available in android for easy movement of the users while carrying out
various functionalities.
 Reliability
The system should be able to carry out the tasks provided by the user. For example, if a
mechanic requests an inventory item, the item should be retrieved from the database if
available and if not, it should be logged. This ensures that the functionalities that were
preset are available.
 Recoverability
In case of data loss, the system should shut down. This will help the admin recover from
it through the admin panel. The data should be backed up each time a transaction occurs
such that in case of data loss the backed-up data may be recovered within the current
system and the system can continue functioning.