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
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
 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
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM

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.

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…

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

Describe what the rest of the SRS contains
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


Give the organizational structure of the SRS.
Update this as we write more….
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


Give a brief introduction of what information will be covered in this section.
Start of your text.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM

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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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 finish ed, 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:
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM

Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
Revised: 4/16/2020 1:34 PM Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)

-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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM

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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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:
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM

Cross-refs:
Uses cases:
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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 interf aces 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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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…
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM


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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM

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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 4/16/2020 1:34 PM