Software Requirements Specification (SRS)
Automotive Paint Defect Analysis Project
Team: 5
Authors: Arturo Barajas, Allen Huynh, Zackery Keith, Leinbach Mitchell, Joseph
Norwood
Customer: Mackinac Software, LLC
Instructor: Dr. Marilyn Wulfekuhler
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
1 Introduction
Table of Contents
Table of Contents
1.0 Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, Abbreviations
1.4 Organization
2.0 Overall Description
3.0 Product Perspective
4.0 Product Functions
5.0 User Characteristics
6.0 Constraints
7.0 Assumptions and Dependencies
8.0 Apportioning of Requirements
9.0 Specific Requirements
10.0 Modeling Requirements
11.0 Prototype
12.0 How to Run Prototype
13.0 Sample Scenarios
14.0 References
15 Point of Contact
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
1.1Purpose
The purpose of this document is to present a detailed description of the
Automotive Paint Analysis Defect System. It will explain the purpose and features of the
system, the interfaces of the system, what the system will do, and the constraints under
which it must operate. This document is intended for both the stakeholders and the
developers of the system.
1.2Scope
This software system will be a Automotive Paint Analysis Defect System for
Mackinac Software, LLC. This system will be designed to detect and analyze defects on
the exterior of a vehicle. Analysis of the types and number of defects can lead to a
discovery of the cause of the defects, which can then be addressed and prevented. The
system will be automated to eliminate paper diagrams that are currently used to track
defects by an analyst. They system will also automatically generate the desired reports
from the entered data. The system will not be be able to automatically detect defects, and
will still require input from the analyst. The client would like to use the system at all
three of the GM plants they have contracts for, Lansing Delta Township, Lansing Grand
River, and Lake Orion Assembly.
1.3Definitions, acronyms, and abbreviations
Term
Audit
Definition
Daily report that focuses on defects
per unit
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Database
Collection of all the information
monitored by this system.
DPU
Defects per unit
Software Requirements Specification
A document that completely describes
all of the functions of a proposed
system and the constraints under
which it must operate.
Stakeholder
Any person with an interest in the
project who is not a developer
User
Reviewer or Author
1.4Organization
The next chapter, the Overall Description section, of this document gives an
overview of the functionality of the product. It is used to establish a context for the
Product Perspectives in the next chapter. The Product Perspectives will include the
context of the product and interface constraints. This document will then cover the
following in order: Product Functions summarizing the major functions that the software
will perform , User Characteristics describing expectations about the user, Constraints,
Assumptions and Dependencies, Various Requirements, Prototype information, and
finally Sample Scenarios
2 Overall Description
In automotive manufacturing, the exterior of a vehicle must not contain flaws or
imperfections in the paint and finish (consumers purchasing a new vehicle expect a
flawless finish). When defects are detected, they are corrected on the assembly line.
Analysts working on the assembling line will use the system outlined in the following
chapters to record those defects and store them in a database.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
3 Product Perspective
At present, paint defect analysts at the GM plants record defects using paper diagrams of
wireframes of each vehicle model produced at the plant. The analyst will mark on the
diagram where and what kind of defect exists on the vehicle at certain checkpoints on the
assembly line. When enough sampling is done, the data is collated to make a daily report
of the defects that were recorded. This information is retained for a longer period of time
to produce different types of reports and to track defects over time.
The Automotive Paint Defect Analysis System is the replacement for the current method
of recording paint defects. The system will be implementing a client-server model. The
system will consist of the following components:
● Android Tablet: The defect analysis software will operate on android tablets
whose recommended specifications will be provided to the client. These tablets
will be used by client analysts to record defects and generate reports. These
tablets will not be networked and operate completely independent of each other.
● Defect Analysis Software: This is the software that will run on the android tablets.
Client analysts will be able to use this software to record defects, collate sample
data, and output reports.
● Windows 7 Workstation: A workstation will be placed in the plant manager's
office to store the database.
● Database: The database will store paint defect data long-term in order to generate
long-term reports with statistical data.
The Defect Analysis Software on the Android Tablets will attempt to connect to the
database when an internet connection is available. While connected to the database any
reports that are generated and CSVs of the data will be stored to the database. If there is
no internet connection at time of report generation, all data will be stored on the tablet
until an internet connection is established. Once established, the data will be pushed to
the database.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Interface Constraints:
● System Interfaces: Tablets will store paint defect data locally. They will be able to
store paint defect data to the database via wireless network in the manager's
office. Tablets will also be able to generate long-term reports while connected to
the database in the manager's office.
● User Interfaces: The primary user interface will be the Defect Analysis Software
on the android tablet. From this software the user will be able to collect sample
data, collate the data into daily and long-term reports, and store to and read from
the database.
● Software Interfaces: The defect analysis software will connect to a database over
a network to store sample data and generate long-term reports. Reports stored on
the database will be searchable by date.
● Communication Interfaces: The workstation on which the database is stored and
the tablets used to record paint defect data will connect to a wireless network in
the Manager’s office away from the factory floor.
● Site-Specific Configurations: Each tablet will need be configured with the names
of the analysts, car model wireframes, and checkpoints of the plant at which it
will be used.
4 Product Functions
The Functions performed by the product are as follows:
● Record Paint Defects: Analysts will be able to indicate the location, type, and
severity of a paint defect by touching a point on a wireframe of the car model.
● Collate Data: Once the specified number of samples has been collected by the
analyst the data will be collated and stored to a csv on the tablet.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
● Generate Reports: The analyst can generate a daily report or different types of
long-term reports from local data on the tablet or from the database.
● Store Old Data: When an audit is completed the tablet will either attempt to store
the report and a csv of the data to the database, or, if not connected, it will store
the data locally until connected to the database.
5 User Characteristics
There will be two classes of users of the product. First are the paint analysts using the
data input functions of the product. These users will be familiar with the process of
identifying and classifying paint defects and must have a basic understanding of tablet
technology (e.g. how to wake the device and open an app). However, besides a brief
tutorial on the use of the product they should require no additional training or skills
beyond those they used for the old pen and paper system.
The other class of users includes the managers who control the database. These users will
be able to access old reports. These users should be familiar with navigating the
Windows file system using the standard file system browser and with opening Excel
documents.
A third class of user that could be affected by the new system is the set of users who
make decisions based on the generated reports. However, this group will not see any
change in their day-to-day activities, as the generated reports will contain all the
information they’re used to.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
6 Constraints
The program has no safety-critical constraints. The Android tablet must be kept in good
working order and not dropped or otherwise damaged, as this may result in the loss of the
current unit’s data. The database must be backed up regularly, or else damage to the
Workstation may result in loss of data.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
7 Assumptions and Dependencies
● It is assumed that the plant has WiFi access in the manager’s office and that there
is an available location to store and charge the Android tablets
● It is also assumed that the user can view the cars from four angles: right, left, topright, and top-left.
● Finally, it is assumed that the plant will grant sufficient notice to add new models
to the program before they go into production.
● The software depends on a valid copy of Microsoft Excel for report generation.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
8 Apportioning of Requirements
There are no requirements currently scheduled for future versions of the project.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
9 Specific Requirements
1. The system must run correctly on an Android tablet
1.1. It must not crash while in use
1.1.1 If it does crash, it must recover the data pertaining to already-completed
vehicles in the sample
2. The system must support a user
2.1. When the system begins running, it must record the user's name, the date, and
the station where inspections are taking place
2.2. This information must be exported along with the data
3. A user must be able to input paint defects for samples of various models
3.1. User can start an audit by inputting their name, the date, and the station
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
3.2. The user must be able to quickly select the model and color that is coming down
the line
3.3. The user must be able to quickly add a defect:
3.3.1. select the type of defect
3.3.2. click and drag to place and scale the defect
3.3.3. select the severity of defect.
3.3.4. input note about the defect.
3.4. The user must be able to advance to the next unit
3.5. The system must calculate and display the number of completed units (left, right,
top of same model)
3.6. The user must be able to complete a report and mark it as ready for submission
3.7. A user must be able to add/remove car models.
3.8. A user must be able to select the Plant and Station they are reporting for.
4. The system must be able to create reports for specific time periods
4.1. The system must export data to a CSV for use in excel
4.2. The system must make a pretty report with graphs and tables
4.2.1. Quality Analysis Report
4.2.1.1. Must display the station, plant, time, date, analyst name, shift,
models in sample, unit count in sample, total defects, DPU
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
4.2.1.2. Must show the wireframe of each model in the sample with defect
locations superimposed
4.2.1.2.1. Defects should be color-coded according to a legend
4.2.1.2.2. Defects can be drawn as ovals
4.2.1.3. Must show the proportion of total defects are in each category in a
pie chart
4.2.1.3.1. Defects should be color-coded according to a legend
4.2.1.4. Must show a table for general severity overview and a severity table
for each zone
4.2.2. Defect Analysis Report
4.2.2.1. Must display plant, date, analyst name, shift, station
4.2.2.2. Summarizes the total defects, total units, and dpu
4.2.2.3. Counts defects and dpu by location
4.2.2.4. Counts defects and dpu by type
4.2.2.5. Lists all defects, and their:
- Position in sequence
- Color
- Model
- Defect location
- Defect
- Defect notes
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
4.2.3. Defect trend report
4.2.3.1. Must display a graph of DPU over a user-selected period of time
5. The system must store old data
5.1. When a report is completed, its data and the report must be sent to a central
location where it can be backed up and accessed from the web
5.2. These reports must be searchable by date
5.3. If the tablet has no internet connectivity when it completes a report, it must store
the report until it can send the data to the central location
10 Modeling Requirements
The following diagram is a Use Case Diagram. This shows the outside “actors” who
interact with the system as well as the specific actions they will take in the use of the
system. The circles are specific use cases/actions. The solid lines indicate a connection
between an “actor” and an action they can take. The dashed lines indicate that the circle it
points to is an action included in the one it points from.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Use Case
Name:
Add/Delete Car Models
Actors:
Manager
Description:
The Manager adds or deletes a car from the list of options, so the
Line Workers can select the correct type of car that they are looking
at for a particular run.
Type:
Primary
Includes:
Extends:
Cross-refs:
3.7
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Uses cases:
Use Case
Name:
Set Up Device/Configure
Actors:
Manager
Description:
The Manager must install and configure the device.
Type:
Primary
Includes:
Extends:
Cross-refs:
1
Uses cases:
Use Case
Name:
Select Plant
Actors:
Line Worker
Description:
The Line Worker selects which plant they will enter defects for.
Type:
Primary
Includes:
Extends:
Cross-refs:
3.8
Uses cases:
Use Case
Name:
Select Station
Actors:
Line Worker
Description:
The Line Worker selects which station they will be located at and
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
enter defects for.
Type:
Primary
Includes:
Extends:
Cross-refs:
3.8
Uses cases:
Use Case
Name:
Select Model
Actors:
Line Worker
Description:
The Line Worker selects what model of car he will be reporting on.
Type:
Primary
Includes:
Extends:
Cross-refs:
3.2
Uses cases:
Use Case
Name:
Select Paint Color
Actors:
Line Worker
Description:
The Line Worker selects what paint color the car in question is,
because it may make a difference in terms of defects.
Type:
Primary
Includes:
Extends:
Cross-refs:
3.2
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Uses cases:
Use Case
Name:
Enter Defect
Actors:
Line Worker
Description:
The Line Worker touches a spot on an on-screen wire-frame car
mock-up to indicate there is a defect in that spot.
Type:
Primary
Includes:
includes Select Severity and Select Defect Type
Extends:
Cross-refs:
3, 5
Uses cases:
Line worker must have completed selecting plant, station, model,
and paint color.
Use Case
Name:
Select Severity
Actors:
Line Worker
Description:
The Line Worker selects what paint color the car in question is,
because it may make a difference in terms of defects.
Type:
Secondary
Includes:
Extends:
extends Enter Defect
Cross-refs:
3.3.3
Uses cases:
Line worker must have completed selecting plant, station, model,
and paint color.
Use Case
Name:
Select Defect Type
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Actors:
Line Worker
Description:
The Line Worker selects what type of defect he is reporting.
Type:
Secondary
Includes:
includes Input Note
Extends:
extends Enter Defect
Cross-refs:
3.3.1
Uses cases:
Line worker must have completed selecting plant, station, model,
and paint color.
Use Case
Name:
Input Note
Actors:
Line Worker
Description:
The Line Worker inputs a note about the defect if more detail is
needed beyond selecting a type of defect.
Type:
Secondary
Includes:
Extends:
extends Select Defect Type
Cross-refs:
3.3.4
Uses cases:
Line worker must have completed selecting plant, station, model,
and paint color. Also must have completed Enter Defect and Select
Defect Type.
Use Case
Name:
Create Long-Term Report
Actors:
Analyst
Description:
The Analyst tells the system to generate a long-term report and the
report is generated.
Type:
Primary
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Includes:
includes select date
Extends:
Cross-refs:
4.2.2, 4.2.3
Uses cases:
Use Case
Name:
Create Daily Report
Actors:
Analyst
Description:
The Analyst tells the system to generate a daily report and the
report is generated.
Type:
Primary
Includes:
includes select date
Extends:
Cross-refs:
4.2.1
Uses cases:
Use Case
Name:
Select Date
Actors:
Analyst
Description:
When the Analyst tells the system to generate a long-term
report/CSV or daily report, he must select the date-range or day
respectively.
Type:
Secondary
Includes:
Extends:
extends Create Long-Term Report, Create Daily Report, and
Export to CSV
Cross-refs:
4
Uses cases:
Analyst must have begun one of: Create Long-Term Report, Create
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Daily Report, or Export to CSV
Use Case
Name:
Export to CSV
Actors:
Analyst
Description:
The Analyst tells the system to export defect data to CSV format so
they may examine it in Excel at a later date.
Type:
Primary
Includes:
includes select date
Extends:
Cross-refs:
4.1
Uses cases:
The following is a high-level Class Diagram. This shows the different classes to be used
in the software as well as some of the attributes and operations associated with them.
Each rectangle is a class, with the name at the top. Attributes are preceded by a dash(-)
and operations are preceded by a plus (+). the lines indicate connection between classes,
showing which classes “know” each other, meaning they can interact.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
The following are descriptions of the classes involved:
System: A class to represent the system as a whole. This has operations to export reports
of the gathered data, and acts as a collection of all workers.
Worker: A class to represent a worker/device which indicates the person’s Name,
Station, and Plant. In addition, it has operations to enter/remove defects and change cars.
It also acts as a collection of cars that have been examined.
Car: A class to represent a car, which may actually pieces of several cars. This has
attributes to describe the Date it was examined, and the Color of paint. This also has
operations to Add/Remove a defect and choose a Model. This also acts as a collection of
defects.
CarModel: A class to represent a model of car, with a Name, and Images associated with
that specific model.
Defect: A class to represent a specific defect, including attributes to describe Severity,
Note about the defect, and an X, Y location on the image.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
The following are scenarios for each Use-Case:
1. Add/Remove Car Model:
a. Worker Adds a new Car Model to available list.
2. Set Up/Configure Device:
a. Manager installs software.
3. Select Plant
a. Worker chooses plant he works in.
4. Select Station
a. Worker chooses Station he works in.
5. Select Model
a. Worker selects model of car he is observing.
6. Select Paint Color
a. Worker selects paint color of current car.
7. Enter Defect
a. Worker enters a defect
8. Select Severity
a. Worker selects severity of current defect being entered.
9. Select Defect Type
a. Worker selects type of defect he is entering.
10. Input Note
a. Worker inputs a note about current defect being entered.
11. Create Long Term Report
a. Analyst tells system to generate a long term report.
12. Create Daily Report
a. Analyst tells system to generate a daily report.
13. Select Date
a. Analyst must select desired date range when generating report.
14. Export to CSV
a. Analyst tells system to export data in CSV format.
The following are Sequence Diagrams for the various Use-Cases. These diagrams are
meant to show the sequence of events(function calls) for a scenario. The sequence
progresses from left to right, with the corresponding class name in a rectangle and the
function call underneath.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
The following is a State Diagram for the System. You begin in the Idle State. This
diagram is meant to show how the flow of control moves around in the system. Each
arrow indicates the direction of movement from one state to another, with the
corresponding text showing the event that causes the state shift.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
11 Prototype
Prototype functional deliverables:
●
●
●
●
●
●
●
●
●
●
●
Prompt for user and location and checkpoint information to begin Audit
○ records
Ability to select vehicle model type
Selection of viewing perspective (i.e. Left Side)
Display status of each view perspective for defects
Selection of defect type and severity
Paints defect on schematics wireframe/overview of vehicle
Store completed data as backup that is accessible via network
System exports data to a CSV
Generate final reports in an simple format with visual aids, such as, graphs and
tables.
Ability to search reports by date
Stores completed report until connection to central location network is available.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
12 How to Run Prototype
To run the prototype one needs either an android operating system tablet for the app, or
a web browser (Firefox, Chrome, Edge, IE, etc.) to run. There will be no plugins to
access the web page. They needs to be internet connectivity to use the application or
web application.
URL (currently for prototype):
http://webdev.cse.msu.edu/~norwoo25/cse435/prototype/startpage.php
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
13 Sample Scenarios
A worker will be begin the Audit as shown above in the image. They will input their
name (username), the facility location, and the checkpoint for the analyst. In this case
they are doing the checkpoint at the Lansing-Delta Township.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
From this image you can see that once the audit begins the model of the vehicle
must be selected, Transverse. Current information will be displayed and the user picks
the current viewing angle of the vehicle.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
Once continue is pressed this screen (above) will be shown. The defects on the vehicle at
that angle will be drawn. Severity and types of defects will be shown. There were already
a few defects from a previous inspection.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
However, the analyst finds some other defects. So they select a point on the vehicle
outline from that viewing angle. Once selected they will be prompt for a category of the
defect and the severity level. This is illustrated above.
Once confirmed they can continue added more defects discovered. Upon completion for
that sample vehicle they can proceed to the next vehicle after a confirmation prompt upon
hitting “Next Car”. The data after this completion will be stored as backup in case of
failure of internet connectivity or any other failures.
User does all the same steps for all the vehicles at that checkpoint. Once completed report
will be saved and sent out.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
14 References
[1]
D. Thakore and S. Biswas, “Routing with Persistent Link Modeling in Intermittently
Connected Wireless Networks,” Proceedings of IEEE Military Communication, Atlantic
City, October 2005.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM
15 Point of Contact
For further information regarding this document and project, please contact Prof.
Wulfekuhler at Michigan State University (wulfekuh at cse.msu.edu). All materials in
this document have been sanitized for proprietary data. The students and the instructor
gratefully acknowledge the participation of our industrial collaborators.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 10/12/2015 1:45 PM