Automated Paint Defect Analyser

Software Requirements Specification (SRS)
Paint Defect Analyzer
Team: Team 2
Authors: Evan Moran, Andrew Barnett, Alyssa Werner, Eric Newman, Jinguang Li
Customer: ~~~
Instructor: Dr. Marilyn Wulfekuhler
Template based on IEEE Std 830-1998 for SRS. Modifications Revised: 4/16/2020 1:34 PM
(content and ordering of information)
1 Introduction
 Provide an overview of the entire SRS subsections
 Indicate the topics that will be covered in this document.
1.1 Purpose – Indicate the purpose of this document.

1.2 Scope – Indicate the scope of the software that this document talks about.
1.3 Definitions, acronyms, and abbreviations – List of any definitions and other things
that the reader might not be familiar with.
1.4 Organization – An overview of the organization of this document.
2 Overall Description – A high-level description of the product that is going to be
produced.
3 Product Perspective – Describe all of the interfaces of the product as well as the uses by
different people. This section will also note any constraints on the system.
4 Product Functions – List the functions of the product as defined by the customer
specification. These functions will be shown by different function diagrams.
5 User Characteristics – This section details the expectations that we have of the user of
the system.
6 Constraints – Specify safety critical things that might come into play when using the
software. Specify any IEEE constraints.
7 Assumptions and Dependencies – Assumptions that we as the developers make about
different things concerning the system.
8 Apportioning of Requirements – list requirements that may be out of the scope of this
project, such as things that may be the subject of future work.
9 Specific Requirements – An enumeration of requirements that are needed for this
project.
10 Modeling Requirements – Diagrams that are used to model the requirements, these
diagrams allow us to bridge the application and machine domains.
11 Prototype – A description of the prototype.
12 How to Run Prototype – A description of the prototype and how to use it.
13 Sample Scenarios – a sample scenario of how the user will use the system.
14 References – List of references used in the document.
1.1 Purpose
 What’s the purpose of the SRS document?
 Specify the intended audience.
The purpose of this document is to provide a formal definition for a software product that
is to be used by automotive plants to analyze paint defects on cars. In this document, the
requirements of both parties (the client and the developers) will be listed and will be the
basis for a contract between the two. Everything that is listed in this document is
expected to be delivered by the final product that the developers give to the customer.
The intended audience is the customers that are interested in buying this software and
need to know specific information about the product that they will be buying.
1.2 Scope
 Identify SW product(s) to be produced by name
 Describe the application of SW being specified, including benefits, objectives,
goals. What is the application domain? (e.g., embedded system for automotive
systems, graphical modeling utility) This is the domain description of the
application.
 Explain what SW product will, and if necessary, will not do. This is the
requirement of the application.
 Be consistent with similar statements in higher-level specifications (e.g., the
original project specification from customer)
The software product that is going to be produced is a program that allows paint analysts
to electronically document paint defects on cars. This program is meant to replace an old
paper system that the paint analyst use to document the defects. The benefit of using a
program to do this process is that all of the information will be persisted, and that the
analyst doesn’t have to go through lots of paper to record the defects for each car. This
program will also automatically generate required reports based on the information
entered, whereas in the old system the analyst would have to re-enter the data into the
computer and manually generate reports.
This product will be used by a paint analyst to track and document paint defects that they
see on a car as it goes down the assembly line. This information will be used to generate
different kinds of reports. There can be many different kinds of reports. These reports can
be based on the different sections of the car, the timeframe that the defects happened in,
and also daily data from each station.
 Add more requirements here…
1.3 Definitions, acronyms, and abbreviations

 Define all terns, acronyms, and abbreviations need to understand the SRS. If this
section is extensive, then move to an appendix. It is also possible to provide a
link to other resources for extensive terminology explanation.
SW - software
1.4 Organization
 Describe what the rest of the SRS contains
 Give the organizational structure of the SRS.
Update this as we write more….
2 Overall Description
 Give a brief introduction of what information will be covered in this section.
Start of your text.
3 Product Perspective
 Describe the context for the product
 Is it one element that is part of a bigger system? If so, then give a pictorial
representation or diagram (e.g., data flow diagram – DFD, block diagram) that
describes how your product fits.
 Interface Constraints:
 System interfaces
 User interfaces
 HW interfaces
 SW interfaces
 Communication interfaces
 Other types of constraints:
 Memory
 Operations
 Site adaptation operations (customization that is done on-site).
The product is designed to be used by paint flaw analysts on the assembly floors of
automotive manufacturing plants. The system will allow an analyst to login to the system,
choose a car model and surface, input errors that they observer on the various surfaces of
vehicles and then generate reports. The system is not intended to be part of a larger
system, but will be capable of communicating wirelessly with other systems like printers
or other PCs in order to share reports, but not input data or generate the reports.
The system will work on a handheld tablet where the user interface allows the analyst to
select a model type and the various surfaces that make up that model. The user will then
be able to mark a paint flaw on the surface and indicate its size and type through
secondary menus. Since the company has requested that data be saved for an indefinite
amount of time the, data from previous reports will be stored in a cloud database rather
than on the tablet or local memory drive. This will allow for memory to be expanded as
needed rather than having a finite amount on site.
Customization on site will be minimal but will involve things such as setting up the
device to work with the plant’s wireless network and adding a list of users who will have
access to the system.
4 Product Functions
 Summarize the major functions that software will perform (portions may come
directly from the customer specification – cite as appropriate).
 These function descriptions should be easily understandable by the customer or

to any general reader.
 Diagrams: (for all diagrams, introduce the notation first)
 Give and describe a high-level goal diagram for system.
This software will allow paint defect analysts to easily enter and manage paint
defects onto a two-dimensional frame, as well as compile statistics about current
and past defects onto a generated report. A user, with a tablet computer, will
start by logging onto the system with their credentials before a session. The user
will be presented with the application. The user will be able to create a new unit
as their first step, which will allow them to switch between 3 car parts (left, top,
and right). The user will then be able to touch points on an image of the car part,
in which their taps will be recorded. The size of the defect that is recorded onto
this 2d image will be determined by the size of the marker applied, which is
shown in a window below the 2d rendering, marked “select severity”. Once a unit
has been finished, the user may hit a button that states “finish unit”, in which
information about the unit will be placed on top of a stack on the left side of the
screen. At any point in time, the user may click on any entry in the stack to go
back and edit the old entry.
Once the user has finished with their entries, they may press the “report” button
to see an immediately compiled report of the information entered. This entered
information will be stored in a database, so users can see past reports, as well as
see concatenations of past reports together.
This is a simple use case description diagram for the system:
5 User Characteristics
 Expectations about the user (e.g., background, skill level, general expertise)
The user of this product will be the defect analysts on the assembly line. These analysts
will already have the required mechanical knowledge of the products functionality, as the
job has been done previously on paper. The analysts will need to be trained to use the
tool, which will perform in a similar way to paper and pencil, but with added
functionality.
6 Constraints
 See list of possible constraints from IEEE SRS document.
 Give English descriptions of safety-critical properties
 Give English descriptions of other properties that if violated, the system will not
perform properly.
Start of your text.
7 Assumptions and Dependencies
 Assumptions made about the HW, SW, environment, user interactions.
The assumptions that have been made about this project were based on question and
answer sessions with a customer representative as well as [fill in the position
dr.wulfekuhler played].
-The software is meant to be used on an assembly line inside of factories, from what has
been elicited by the customer it is assumed that there is no internet or local network
access between the devices with the software. Furthermore, as a result of this assumption
it is assumed that standard mass storage devices (E.G USB hard drives and flash drives)
can be used to transfer data from the input device to the long term data storage location.
-We are assuming that after our software delivers a file in the proper format that
whomever decides it is time to print a report has the hardware (printer, ink, etc) available
to print with and the expertise to print whatever they desire. In other words, the software
will provide a file that is able to be printed, but will require another device to finish the
printing. Many modern home printers and nearly all industry printers offer means to print
from USB mass storage devices, email, or FTP (file transfer protocol) so it is further
assumed that one of these methods, or something such as another computer attached to a
printer could handle this.
-We are assuming that data storage capabilities of the software are based on the transfer
of the data to larger data storage. In other words we are assuming that the customer will
be providing the hardware necessary for long term storage. To further clarify, this means
that the software is capable of saving the report in a format that can be brought up at
anytime in the future and even read back into the device, but the actual storage of the data
falls outside of the software responsibility.
-We are assuming that after a report is generated it should never be edited again.
-We are assuming that analysts will be the only people submitting reports and as such we
are requiring simple name logins for each analyst to prevent unauthorized personnel from
accessing the reports.
-We are assuming that there is no reason for a car diagram to be deleted from the system.
Old diagrams are to be kept for future reference so to simplify there will be no feature to
delete new diagrams either.
-We are assuming that if insufficient cars are checked that no report should be generated.
-We are assuming that all analysts will use the same hardware platform to run our
software.
-We are assuming three levels of severity is sufficient to record defects.
-We are assuming that reports will be standardized across plants. In other words we will
only need to generate one kind of report, not several kinds.
-We are assuming that each plant has a small number of models at any given time (ie, at
most 4), and that only need to distinguish between those models.
-We are assuming a report may consist of all units being the same model, or different
models within the same report.
8 Apportioning of Requirements
 Based on negotiations with customers, requirements that are determined to be
beyond the scope of the current project and may be addressed in future
versions/releases.
The customers may want a 3 dimensional representation of a unit, leading to faster defect
discovery and logging.
The customers may want extensive data analysis, pulling together data between plans and
ultimately running statistical analysis on it.
9 Specific Requirements
 Give an enumerated list of requirements.
 As appropriate, use a hierarchical numbering scheme.
1. Sample requirement at the top level

1.1. Level 2 requirement example
1.2. Another Level 2 requirement
2. Select the “Requirement” Style.
1. Create an interface that allows a paint analyst to record and track paint defects to
later analyze and determine if there are any problems with the paint process.
1. Paint defects must be stored forever so that an analyst can come back to it
and view that data.
2. The analyst will generate a report for a given day where they must have at
least 10 units for good sampling purposed. The daily report can consist of
10, 15, or 20 units.
3. Different cars will have different models and images for the analyst to use.
The model that the analyst uses with the system should match up to the car
that they are analyzing.
2. There are multiple kinds of paint defects that are specified by the analyst and the
analyst should be able to categorize the defects entered into the system as needed.
1. The count of the different types of defects should be kept so that the user
can view the different types of defects as a pie chart or bar graph.
2. Paint defects should be tracked according to which area they are found on
the car. This information will be used in the different reports.
3. The analyst should be able to generate reports based on the data entered so that
they can hang it on a wall for people to see.
1. The reports differ for the different paint stations.
2. The different stations for paint analysis are Prime, E-coat, and top coat
3. There can be multiple different reports that an analyst generates. These
could be daily reports, defects per surface reports, and trend of defects per
unit over time. The latter two can have a selectable date range to select the
data to use for the report.
4. If an error is encountered in the report then the report should not be presented.
5. Analysts will have different credentials for logging into the system so that the
plant can keep track of who entered in the information.
6. The analyst moves on one side of the assembly line at a time so a unit could be
the right side of one car and the left side of another.
1. If a large percent of vehicles are failed to be checked, the report should not
be generated for that day.
7. After a report is generated, the data can be edited. After the report is generated the
data is frozen.
8. The time of an audit session needs to be recorded with the name of the analyst
that is signed in to the system.
9. The data cannot be uploaded as it is entered since there is no Wi-Fi on the
assembly line. The analyst will need to upload it in a different area of the plant or
be able to upload it directly to a computer.
10. There should be a notes area for the analyst to be able to specify any other
information that they want to record about a specific unit.
11. Defects should be recorded using ovals since they are mostly smaller than the size
of a pinhead.
12. The analyst will specify the severity of a defect based on their discretion. There
will be 3 different levels of severity.
13. The types of defects and car models should be able to be added and edited by the
analysts after analyzing.
14. The report should also be saved as picture formats, so it is able to be printed or
sent by emails.
15. Different types defects are represented by different colors for easier recognition.
16. The system should recognize which surface of the car a defect is on.
17. Excel reports should be able to be generated so that the analyst can easily identity
trends and view the data in a more robust format.
10 Modeling Requirements
 This is the specification portion of the requirements document. (Specifying the
bridge between the application domain and the machine domain.)
 For each new diagram type introduced, describe the notation.
 Give and describe use case diagrams
 Use the template below to describe each use case.
 Each goal may be satisfied by 1 or more use cases
 Each use case should refer to 1 or more requirements (in Section
3)
 Give and describe a high-level class diagram that depicts the key elements of the
system
 Include a data dictionary to describe each class, its attributes, its
operations, and relationships between classes.
 Representative Scenarios of System:
 Give English descriptions of representative scenarios for each use cases.
 Check: use instances of the class names from class diagram;
refer to the terms used in use case diagram
 For each scenario, give a corresponding sequence diagram
 Check: Objects should be instances of classes in class diagram
 Create and explain a state diagram for all key classes that participate in the
scenarios (from above).
 Check: that all scenarios can be validated against the state
diagrams.
 Check that the events, actions are modeled in the class diagram.
 Check that all variables referenced in the diagrams are declared
as attributes in the class diagram.
Start of your text.
Use Case Name:

Actors:
Description:
Type:
Includes:
Extends:
Cross-refs:
Uses cases:
11 Prototype
 Describe what your prototype will show in terms of system functionality.
 The prototype is showing how the final product may operate on a tablet. Firstly,
the name of the analyst needs to be inputted. Then the user can select the which
side of the model to be analyze because the user might record the defects from
one side of several car models in a row and does not switch the sides often. After
choosing the side, the user need to select which car model he/her is working on.
When everything is ready for the manipulating page, the user can input the
information of the defects by choosing different types of defect on the left side of
the manipulating page and selecting the level of the defect severity on the right,
and then record the locations of the defects by pointing at the picture of the car
model which is located in the middle of the page. After recording the information
of one unit, the user can tap on the “Finish part” button, and the system will store
the data and start with the next unit from selecting the car model. If the user want
to analyze the other side of the units, there is a button on manipulating page to
switch the side. When all of the units are finished, the user needs to tap on “see
report”, the system will compute the input and generate a report. The user can
choose to save it for further use.
12 How to Run Prototype
 Describe what is needed to run your prototype
 What system configuration? (Should be accessible through web.) Are there
plugins? Are there any OS or networking constraints. Give the URL for the
prototype.

 Prototype v1 does not have to executable per se. But there should be sufficient
number of interfaces for the customer to understand the development’s
interpretation of the requirements.

Prototype V2 should also be accessible via a webpage. It should be executable
and provide an interactive interface.
More here when we develop more of the prototype.
13 Sample Scenarios
 Give a sample scenario of using your system. Use real data and problem
scenarios. Include screen captures illustrating what your prototype produces. As
always, be sure to describe all figures.
Add Later…
14 References
 Provide list of all documents referenced in the SRS
 Identify each document by title, report number, date, and publishing organization.
 Specify the sources from which the references can be obtained.
 Include an entry for your project website.
Start of your text.

[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.
15 Point of Contact
For further information regarding this document and project, please contact Prof.
<name> at Michigan State University (<netid> 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.

Automated Paint Defect Analyser

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Automated Paint Defect Analyser

Uploaded by

Copyright:

Available Formats

Software Requirements Specification (SRS)

Paint Defect Analyzer

1.1 Purpose – Indicate the purpose of this document.

 Add more requirements here…

1.3 Definitions, acronyms, and abbreviations

Update this as we write more….

 These function descriptions should be easily understandable by the customer or

This is a simple use case description diagram for the system:

Start of your text.

1. Sample requirement at the top level

Start of your text.

Use Case Name:

More here when we develop more of the prototype.

Start of your text.

You might also like