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
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
1.1 Purpose
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.2 Scope
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.3 Definitions, acronyms, and abbreviations
Term / DefinitionAudit / Daily report that focuses on defects per unit
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.4 Organization
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.
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.
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.
● 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.
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.
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, top-right, 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.
8 Apportioning of Requirements
There are no requirements currently scheduled for future versions of the project.
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
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
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
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.
Use Case Name: / Add/Delete Car ModelsActors: / 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
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 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
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
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
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 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.