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
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
1
Introduction
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
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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
1.2 Scope
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.
1.3 Definitions, acronyms, and abbreviations
SW
Software
HW
Hardware
TCP
Transmission Control Protocol, used by internet applications to transfer data.
HWD
Height Width Depth, used after giving measurements of an object (E.G 10
inches by 11 inches by 12 inches HWD)
PNG
Portable Networks Graphic, an image file type.
JPG
Refers to the image file type JPEG which stands for Joint Photographic
Experts Group. It is known to have loss in quality over long term image rewrites.
USB
Universal System Bus, technology often used in Flash Drives to help with
compatibility of devices on the system bus.
SQL
Either refers to the SQL query language itself or Microsoft SQL Database
which uses the SQL query language and provides means for the management
of a SQL database.
Root
Refers to Root (superuser) level access on a computer. This is highest level of
access and should be restricted from most personnel
SD
Card
Sometimes referred to as “memory cards”, they allow storage of files
indefinitely, but are unreliable for long term storage because it takes a
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
relatively low amount of writing to memory before data corruption and
memory failure begin to occur
Wifi
Technology that allows for local area wireless network access. In other words,
it allows for wireless access to the internet and for wireless access across
devices.
IEEE
The Institute of Electrical and Electronics Engineers. The IEEE produces the
standards that were adhered to for many parts of this project including this
SRS Document
1.4 Organization
The organization of this document in terms of section locations follows the order that
is shown in the introduction. This section will describe some of what is contained in
each section following this section. All sections are listed in the order that they appear
after section 1.4 Organization.
2 Section 2 Overall Description: A description of the product that does not go into
heavy technical detail, but instead uses simplified language to describe how the
product is designed and how it will work when completed.
3 Section 3 Product Perspective: This section provides an overview of how the product
workflow will be carried out. It also provides information on constraints related to the
workflow, particularly transfer of data from the device to long term storage.
4 Section 4 Product Functions: Functions of the product as defined by the customer
specification. Shown through product function diagrams.
5 Section 5 User Characteristics: This section details the expectations that the
developers have of the user of the system. In other words, this is what is expected that
the users understand before using the product.
6 Section 6 Constraints: This section details IEEE, safety, software, hardware, and
other constraints in greater detail than other sections that offer little information on
design constraints.
7 Section 7 Assumptions and Dependencies: Assumptions that have been made by the
developers about how the product will be used, what functionality is required of the
product, and the environment the product will be used in.
8 Section 8 Apportioning of Requirements: Requirements that may not be included in
this current project, but could be used to enhance the system after it is finished.
Information here is the result of discussions with stakeholders in the project.
9 Section 9 Specific Requirements: All the identified requirements for this project. The
requirements are enumerated so they can be referenced by developers and identified
within the use case tables.
10 Section 10 Modeling Requirements: The UML diagram, use case diagram, and the
individual use case tables for this project.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
11 Section 11 Prototype: A description of the prototype design.
12 Section 12 How to Run Prototype: A description of how to use it the prototype.
13 Section 13 Sample Scenarios: Details scenarios for work that a user will likely carry
out while using this system
14 Section 14 References: List of sources that were referenced in the creation of this
document
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
2
Overall Description
The product that this document concerns is an application that paint analysts in an
automotive plant can use to document and track paint defects on cars. This application is
meant to overhaul the old system of manually tracking defects on a piece of paper. This
old way of tracking defects wastes a lot of paper and makes it very hard to track the paint
defects over time. The new system will allow analysts to run different reports based on a
given time frame and will also allow analysts to run report automatically after generating
data. Using this method, analysts will only have to enter data once as opposed to writing
the defects down on a piece of paper and then entering this information manually into a
computer.
The application will also allow for a better interface for the analyst to enter the defects for
each unit. Using a tablet will allow the analyst to be very mobile with their work and will
also make it very easy to transition from one unit to the other. The analyst will just have
to carry the tablet and possibly a stylus in order to track defects.
There will be a few different reports will be able to be generated based on the entered
data. These reports include quality analysis reports (such as E-coat and prime coat) as
well as excel reports that will be based on a given time frame. These reports will be based
on the information that is entered using the application. All of the data will be stored in
order to be persisted forever.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
3
Product Perspective
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. This can
also be done with mass storage devices such as USB flash drives or SD cards.
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 some configuration to work with
devices inside the plant such as printers and storage devices. This will likely be handled
by a specialist who will also oversee application installation and integration to the current
system.
Below is a diagram for possible workflows for the application and it’s users. Data is
entered to the tablet where a report is produced. From there, if internet is available it can
be directly uploaded to the database. Otherwise it will have to be exported to a mass
storage device such as USB which can transfer the data to a workstation where the
reports can be added to the database. Finally devices such as printers and workstations
will be able to access the database to use the reports for the future.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
4
Product Functions
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.
Below 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: 3/21/2016 6:13 PM
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
5
User Characteristics
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
product, which will perform in a similar way to paper and pencil, but with added
functionality. To ensure that analysts have a full understanding of the product, it is
expected that users will only a basic knowledge of the technology used in the product. As
such the training will go over every step it would take to follow the workflows that have
been identified. More specifically, part of the product training will include how to
generate,store, and access completed reports. In addition to training on how to use the
application there will also be training on proper handling of the device for physical
security and how to use the tablet (e.g power it on, shut it down, charge the battery).
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
6
Constraints
Regulatory Policies:
The regulatory policy for input to the system is handled by the login credentials given to
analysts. Because only analysts have login credentials they are the only people who can
enter in data. This requires the creation of a login system but solves the problem of
insecure input because information can only be stored after login with proper credentials.
Since the data is being stored long term outside of the device there needs to be
confirmation that the data has been sent correctly. TCP confirms data reception but
requires that the software and hardware support it.
Hardware limitations:
The Samsung Galaxy Tab S2 is the tablet the application will run on. The tablet’s
measurements are 9.34 by 6.65 by 0.22 inches HWD and it weighs 13.7 ounces. The
device runs Android 5.1.1 (aka Lollipop) which will allow for implementation to be
flexible. The device is capable of connecting to local WiFi if it were brought to an office
for example. The device also supports SD cards which are a cheap method to transfer
data between the tablet device and long term storage areas capable of connecting to the
internet.
Interfaces to other applications:
The system needs to interface with Microsoft Excel to produce spreadsheets. To do this it
will output data in (format that works with Excel csv or something) which can be read (or
converted to a file type that works) by Excel. The application is also capable of producing
images that can be read by other image viewers, but there will be no specific interface
built for this. Android now runs Microsoft Mobile Office natively which will ease the
creation of an interface between the application and the hardware.
Parallel Operation:
Because the system is designed to run on the Samsung Galaxy Tab S2 it is possible for
several analysts to work at once without interfering with each other. The only time
several analysts cannot perform a certain operation at the same time is with editing the
same archived report since that would corrupt the data. While in operation the tablets will
have their own copy of the report they are actively working on, it is only once it is
submitted to the database that
Audit Functions:
The system is designed to hold as many reports as available storage allows. Reports can
be stored either with an image file type or an Excel document file type depending on user
selected preference. The implementation will involve selecting a database to use. SQL
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Database is a time tested system that is compatible to store the data. The data will be
accessible based on a user entered duration. For example the user can select a range of
dates spanning one month and see all the reports that were entered in that time.
Reliability Requirements:
The system is designed to run until either the tablet is powered off (by selection or battery
depletion), the application is terminated by root level access, or the application
determines the security of the device has been breached (several failed login attempts).
The system is designed to save changes as they are entered to the device, in the event of a
power failure they would remain on the tablet’s local memory. If the device was
physically compromised but the local storage on the device had not been damaged it
would be possible to recover lost data. Once data has been moved to long term storage it
is required to remain reliably accessible. In offline storage the data will be vulnerable to
physical damage to hardware and to failed transfers from the tablet to storage. Online
backup storage remains vulnerable to hardware damage and failed transfers, but can
implement several internet protocols to ensure reliability.
Signal Handshake Protocols:
As is mentioned in the Regulatory Policies and Hardware Limitations sections TCP will
be used for transfers from offline storage to online backup storage. TCP runs natively on
Android which will ease implementation. TCP is used because it guarantees the delivery
of data in the order which it was sent.
Criticality of the application:
The criticality of the application as it relates to business success through finding paint
defects is in the reliable storage of reports for long term trends and reliable transfer of
reports to storage without corruption. If these aspects of the application fail the reports
will either fail to generate or produce false data which will slow down the discovery of
paint defects.
Safety and Security Considerations:
The system needs to be secure so that it is only accessible by employees with the proper
credentials for reading and writing as physical reports can be produced for unauthorized
personnel to view. This is addressed through the creation of a login system that was
mentioned in the Regulatory Policy section. The system will have no requirements for
how often credentials will need to be updated but will allow for users to do this as
needed. The application has no way of harming a person through physical means, it could
potentially harm mental health indirectly if it lead to someone being fired for missentered data. Hardware failures are not a safety concern either based on quality and
reliability reviews on the Samsung Galaxy Tab S2.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
7
Assumptions and Dependencies
The assumptions that have been made about this project were based on question and
answer sessions with a customer representative as well as the customer..
-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.
-It is assumed that after our software delivers a file in a selected 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. The reports will be delivered either as images in JPG or PNG
format, or as an Excel document. Both of these file types are assumed compatible with
the printers available as well.
-It is assumed that data storage capabilities of the software are based on the transfer of the
data to larger data storage. In other words it is assumed 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.
-It is assumed that after a report is generated it should never be edited again.
-It is assumed 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.
-It is assumed 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.
-It is assumed that if insufficient cars are checked that no report should be generated.
-It is assumed that all analysts will use the same hardware platform to run our software.
-It is assumed five levels of severity is sufficient to record defects.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
-It is assumed that reports will be standardized across plants. In other words we will only
need to generate one kind of report, not several kinds.
-It is assumed that each plant has six or less models of car it produces and that the
application only need to distinguish between those models.
-It is assumed 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: 3/21/2016 6:13 PM
8
Apportioning of Requirements
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: 3/21/2016 6:13 PM
9
Specific Requirements
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.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
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: 3/21/2016 6:13 PM
10 Modeling Requirements
Use Case
Name:
Boot System
Actors:
Analyst
Description:
Give power to the tablet and turn on the paint defect analysis
system
Type:
Primary, Essential
Includes:
None
Extends:
None
Cross-refs:
Requirement 1 (part of the interface is being able to turn it on)
Uses cases:
None
Use Case
Name:
Log In
Actors:
Analyst
Description:
Present a simple login screen to the analyst to verify their credentials
before allowing access to the rest of the system
Type:
Primary, Essential
Includes:
None
Extends:
None
Cross-refs:
Requirement 5
Uses cases:
Analyst must have completed the Boot System use case
Use Case Name:
Shutdown System
Actors:
Analyst
Description:
Shutdown the tablet and the paint defect analysis system
Type:
Primary, Essential
Includes:
Boot System
Extends:
None
Cross-refs:
Requirement 1 (part of the interface is being able to turn it off)
Uses cases:
Analyst must have completed the Boot System use case
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Use Case
Name:
Input Error
Actors:
Analyst
Description:
Enters an error into the system after car, part, and severity have
been selected
Type:
Primary, Essential
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 12
Uses cases:
Analyst must have completed Choose Car, Select Severity, Select
Defect Type, and Select Part use cases
Use Case
Name:
Generate Error Report
Actors:
Analyst
Description:
Generate an error report from the collection of errors that has been
entered for the current session with the time of the session and the
name of the logged in analyst. The report can be exported as either
an Excel document or image file
Type:
Primary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 8, Requirement 17
Uses cases:
None (the analyst can produce blank reports if desired)
.
Use Case
Name:
Add User Credentials
Actors:
Analyst
Description:
Add user credentials so a new analyst can log into the system and
generate reports
Type:
Secondary
Includes:
Boot System, Log In
Extends:
None
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Cross-refs:
Requirement 5
Uses cases:
None
Use Case
Name:
Edit User Credentials
Actors:
Analyst
Description:
Edit the credentials of a user that is already authorized to use the
system
Type:
Secondary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 5
Uses cases:
The Add User Credentials use case has to have been completed at
some point by any Analyst so that there is an entry to edit
Use Case Name:
Choose Car
Actors:
Analyst
Description:
Choose what car model paint defects are being entered for
Type:
Primary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 16
Uses cases:
None
Use Case
Name:
Select Severity
Actors:
Analyst
Description:
Select the severity of the defect from a scale of 1 to 5, 5 being most
severe
Type:
Primary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 12
Uses cases:
Analyst must have completed the Select Part and Create Part use
cases to generate the image
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Use Case
Name:
Create part
Actors:
Analyst
Description:
Create a image of the part so that defects can be entered for that
part of the car
Type:
Primary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 16
Uses cases:
The analyst must have completed the Select Part use case before
they can create an image
Use Case Name:
Select part
Actors:
Analyst
Description:
Choose what part of the car to generate an image for
Type:
Primary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 16
Uses cases:
None
Use Case
Name:
Select Defect
Actors:
Analyst
Description:
Choose type of defect for entering a defect onto the report. Different
types of defects will be represented by different colors on the image
and final report
Type:
Primary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 15
Uses cases:
Analyst must have completed Select Part and Create part to
generate an image to enter defects on
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Use Case
Name:
Edit Defect Types
Actors:
Analyst
Description:
Add or remove defect types that can be selected to the system.
Allow user to choose the color to represent defect
Type:
Secondary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 13
Uses cases:
None
Use Case
Name:
Edit Notes
Actors:
Analyst
Description:
Allow the analyst to write notes onto the report which will be
included when the report is generated
Type:
Primary
Includes:
Boot System, Log In
Extends:
None
Cross-refs:
Requirement 10
Uses cases:
None
Shown below is the use case diagram created from the use cases identified. To keep the
diagram clean there are no <<include>> indications on the diagram. All includes can be
found in the use case tables.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
11 Prototype
The prototype is showing how the final product may operate on a tablet. Firstly,
the user needs to input the basic user information which includes the name of the
user, the shift, the plant and the station he/she is working at. When the user
information is entered, the user can select the car models and which side of the
model to be analyze. There are three parts of the model to be choose which are
the left, the right, and the top. Then the system will generate a picture in the
middle of the manipulating page once the user is done selecting and tap on the
“create part” button. After that, the user can choose different types of defects and
the severity of the defects under the picture. When everything is ready, the user
now can record the locations of the defects by pointing at the picture of the car
model. After recording the information of one unit, the user can tap on the “Add
part” button, and the data will be stored in the system. If the user wants to view or
modify the information of previous units, he/she can always pick the units to
check on in the “Unit history” list which is on the left side of the manipulating
page. When all of the units are finished recording, the user needs to tap on “see
report”, the system will compute the input and generate a report for analyzing.
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: 3/21/2016 6:13 PM
12 How to Run Prototype
In order to run the prototype, a user needs a web browser. This web browser needs to
be relatively new to take advantage of some newer features of up to date web browsers
(as of December 2015). The prototype was developed and tested on the newest version
of the Google Chrome browser (version 47.0.2526). (THIS PROTOTYPE DOES NOT
CORRECTLY PLACE DEFECTS ON INTERNET EXPLORER OR FIREFOX, PLEASE
USE GOOGLE CHROME.)
The prototype URL is:
http://www.cse.msu.edu/~cse435/Projects/F2015/Groups/Team2/demo.html
Just going to the website will allow the user to run the prototype. The next section will be
a sample scenario of how a paint analyst would use this prototype to complete their
analysis.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
13 Sample Scenarios
We will know go through a sample scenario that an analyst might encounter, and provide
information on how this analyst would enter the information he/she sees into the
prototype.
Upon entering the application, the user will immediately be prompted to enter some
information. This information consists of the name of the analyst, the shift they are
working, the plant they are at (This may be a fixed configurable setting later), and also
the station at which they are analyzing. All of this information will be used later to track
different aspects of a report. Below is what the information form will look like:
Once all of the required information is entered, the analyst can simply click save
changes to dismiss the form. The time is also recorded when the form closes so that we
know what time the audit session started.
The next step in the process of recording a defect is to select a car model and the part of
the car that is being analyzed. For the purposed of the prototype, we only have 2 models
but this will eventually be based on the models that the factory produces. Choosing the
car model is based on a drop down, and selecting the car part is based on buttons. Once
a model is selected and a part is also selected, the user can click create part to open up
a picture of the car model to work on. The form described here is shown below:
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
Once this form is clicked, the user will be left with the following page:
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
This is the main part of the page in which the analyst will select the defects and their
severities and put them onto the corresponding location of the car. The defect severity
changes the size of the oval placed on the image. For the sake of this scenario, let’s
assume that an analyst sees a crater defect with a severity of 5 on the roof of the car. In
order to put this into the system, the following configuration should be chosen:
Then, the analyst can simply click the location of the defect on the roof of the car. This
will place a large blue oval on the roof of the car. The image of the car will now look like
this:
Now let’s assume that there are no more defects that the user wants to enter for that
part of the car. The analyst will click add part in the lower right of the screen and the
analysis for that part will be recorded and added to the unit history pane on the left side
of the screen. This will look like the following picture:
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
The analyst will then continue to enter defects into the system until they have reached a
total of 10 right sides, 10 left sides, and 10 tops. After this quota has been meet, the
analyst can select the See Report button at the bottom of the unit history pane to see the
report. Here is what the pane should look like if 30 parts have been entered into the
system:
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
The following report is generated from the mock data that we have provided:
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 PM
The right side of the page contains several tables that categorize the defects based on
their location on the car. The picture cuts off most of the tables since the list goes on a
long ways, but there in total 8 tables that correspond to different sections of the car.
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 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.
[2]
IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications. IEEE Computer Society, 1998. - Available through CSE 435 Website
[3]
"Samsung Galaxy Tab S2 (9.7-inch) Review: A Big Screen in a Slim Package." CNET.
N.p., n.d. Web. 01 Dec. 2015. - Web article
[4]
"Living With a Samsung Galaxy Tab S2." PCMAG. N.p., n.d. Web. 01 Dec. 2015. - Web
article
[5]
http://www.cse.msu.edu/~cse435/Projects/F2015/Groups/Team2/ -project website
Template based on IEEE Std 830-1998 for SRS. Modifications
(content and ordering of information)
Revised: 3/21/2016 6:13 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: 3/21/2016 6:13 PM