Software Requirements Specification (SRS) Project ...cse.msu.edu/~cse435/Projects/F2015/Groups/Team4/files/requirements...Template based on IEEE Std 830-1998 for SRS. Modifications

Template based on IEEE Std 830-1998 for SRS. Modifications

(content and ordering of information)

Revised: 11/23/2015 12:59 PM

Software Requirements Specification (SRS)

Project Automotive Defect Paint Analysis (ADPA)

Team: Group 4

Authors: Brian Wyss, Ryan Bruns, Jarrod Rouggeau, Si Wang

Customer: Mackinac Software LLC

Instructor: Marilyn Wulfekuhler



Revised: 11/23/2015 12:59 PM

1 Introduction

Provide an overview of the entire SRS subsections

Indicate the topics that will be covered in this document.

Start of your text.

1.1 Purpose

What’s the purpose of the SRS document?

Specify the intended audience.

Start of your text.

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)

Start of your text.

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.

Start of your text.

1.4 Organization

Describe what the rest of the SRS contains

Give the organizational structure of the SRS.

Start of your text.



Revised: 11/23/2015 12:59 PM

2 Overall Description

Give a brief introduction of what information will be covered in this section.

Start of your text.



Revised: 11/23/2015 12:59 PM

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).

Our ADPA system is expected to remove the paper trail currently being used by the

customers. With this system the customer will be allowed to remove the paper from the

floor and really help to streamline the input process for the workers on the floor. Our

solution will be cross platform mobile solution as no platform we have looked at really

needs to utilize much of the system hardware. We will be utilizing the Phone-Gap

platform to accomplish our goal which is more than adequate to accomplish this.

The system will work as a collection of two systems. The device will act as the notepad

which will allow the system to work with no connection as we are not guaranteed or even

allowed to have a connection on the floor for security concerns. Data will be stored on

the device until a connection is gained and then will upload all reported defects. To

accompany the device, which can be any device thanks to the cross platform

functionality, we will be designing a web interface for generating these reports and

visualizing the data input by the operators. Our web interface will allow for range based

query and worker based queries to see the defects spotted by each worker to conduct

performance reviews.

NEED A DATA FLOW DIAGRAM

(tablet) -> site server <- (manager can view)

We will be utilizing JavaScript and HTML/CSS on the front-end and using PHP for the

back-end storage. These languages will allow for us to very easily be able to interface

with many languages as the program is evolved or changed. As many of us are familiar



Revised: 11/23/2015 12:59 PM

with these technologies, it also plays nicely into the need for maintenance as these are

widely used languages and the speed to mitigate these issues will be very high.

Our interface constraints are at a bare minimum, with our cross platform solution we are

able to keep our interfaces down to any sort of device that is able to run our software

adequately which will keep up to date with some of the latest releases from Windows,

Android, and Apple to keep our software up to date. The bare minimum that will be able

to run on would be iOS 6, Android 4.4, and Windows 8. To tie along with our software

interface, the systems interfaces will follow suit as well. We will be running across all of

the popular web browsers with IE 9 being the bare minimum of the supported browsers

with Chrome, Firefox, and Opera being preferred browsers of choice for our systems.

The user interface will be kept as simple as possible to allow for speed and quickness for

the operator to be able to get into a rhythm when they are processing paint defects. A user

will be able to quickly select the needed data from a list of dropdowns, this takes as much

of the typing away from the user as possible to allow for speed, presently the only typing

we have is for the user to enter their name to tie them to a defect.

Hardware interfaces will allow for any modern tablet, our tablet of choice would be the

Google Nexus 7 from 2013 since it has reliable removable storage, adequate processing

power, and a screen that fits the requirement to be portable but not unwieldy, and is cheap

and . Our communication interfaces will be via the internet utilizing PHP to send the files

off to our server for storage, however, as we will be unable to verify a connection at all

times, we will be using the removable storage to retrieve our defects file from the device

upon shift closing.



Revised: 11/23/2015 12:59 PM

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.

Start of your text.

The ultimate goal, if nothing else, is to remove the paper trail that is generated and

redundancy that each operator must do on a daily basis. Our ultimate goal is to place our

product in the hands of the operators and have it successfully perform to remove the

paper currently being used by these operators to detect paint defects.

Some of the major functions of our application is to allow for the quick processing of

paint defects and to place the operators in a stable environment that will not change so

they are quickly able to do their job (“do not change the environment” per requirements

elicitation). Our system will also allow for reports to be generated at the end of the shift

as well as generated on an as needed basis. These as needed basis reports might be

something from a specific date range or per operator for conducting a performance

review.

NEED A LOT OF DIAGRAMS HERE.



Revised: 11/23/2015 12:59 PM

5 User Characteristics

Expectations about the user (e.g., background, skill level, general expertise)

Our user expectations are for someone that is familiar with the current system, they do

not have to specifically be used to the current defect processing system, but familiarity

with data entry is a major positive. We expect our operator to have a general

understanding of the car and what qualifies as a true defect and they should have a

standard discretion about defect severity. We developed our system to be very user

friendly with plenty of labeling where necessary and each dropdown to have expected

data that the user can identify with. It should be straightforward for the operator user

interface as to how to enter a defect and process that defect on the car. The report

generation is also as straightforward as possible with very little kept from the user. We

wanted to allow the user to be able to quickly see all reports and thanks to our dataTables

plugin they can easily search or sort by a given field and even export to a .csv file for

longer term collection.

(Someone have anything else to add?)



Revised: 11/23/2015 12:59 PM

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.

One major constraint that will need to be addressed on each medium will be if our PHP

code will be able to run as such. If PHP is not installed correctly or uses a current version

we will have to go about updating/installing it as necessary.

Another constraint will be the device, we will need to work very closely with our

customers if they decided to allow workers to bring in their own devices and run the

application from there. This shouldn’t be an issue given our cross-platform goal, but this

can definitely be seen as a major pitfall. Our mitigation for this risk will be to use a

standard device that we will support with no questions asked which will be the Nexus 7

from 2013.

We will need to allow for the system to access the GPS coordinates of a device to

mitigate a user enter faux data when they are not on site if these devices are their own

personal devices. However, we will be supplying the devices for work purposes therefore

they should remain on site at all times.

(NEED ANOTHER CONSTRAINT OR TWO)



Revised: 11/23/2015 12:59 PM

7 Assumptions and Dependencies

Assumptions made about the HW, SW, environment, user interactions.

Start of your text.

Hardware assumptions we will be making will be mainly focused around a cheap

Android tablet, Nexus 7 (2013), due to its low price point, mountable/removable storage,

adequate screen size, reparability, and processing power. We will be allowing for other

devices from the major manufacturers as well as Apple iOS 6+ and Windows 8+. For our

software we will be targeting each distribution of Android, iOS, and Windows that has

the highest market percentage as the bare minimum accepted as we have found that

versions that fall below these percentages can have very adverse effects on the

application. For example, if we supported Android 2.3.4 to 4.1 we would have a very

different set of languages that we can use and styling that we can use, since we know for

a fact our application will behave differently with these versions. Some assumptions

about our user interactions will be focused around that a user should be presently at their

station when using the application, they should not be sitting in their house entering faux

data. To mitigate this, in a later version we could tie the defects to a GPS coordinate for

data integrity. We expect the user to understand the system quickly and be able to

navigate around quickly.



Revised: 11/23/2015 12:59 PM

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.

Start of your text.

Might come back to this, but someone feel free - Ryan



Revised: 11/23/2015 12:59 PM

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. Quickly enter defects

a. Intuitive design

2. Work without need for a connection to the internet

3. Be able to generate a wide range of reports

4. SOMEONE ADD MORE



Revised: 11/23/2015 12:59 PM

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:



Revised: 11/23/2015 12:59 PM

Uses cases:



Revised: 11/23/2015 12:59 PM

11 Prototype

Describe what your prototype will show in terms of system functionality.

Our prototype will show the following in terms of functionality

Defect Entry – we will showcase how our system will be able to enter a

defect and the fields and windows that a user will be presented with in order

to enter a given defect.

Report Generation - we will also showcase our report generation for the

interested party to create reports. These reports will allow for many things to

see if a person is performing well in capture defects or just to see the amount

of defects that might have happened on a given date, week, or month.




Revised: 11/23/2015 12:59 PM

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.

Our prototype is runnable from the following link found here

(http://cse.msu.edu/~cse435/Projects/F2015/Groups/Team4/links.html) under the

Prototypes section you are able to view the iterations of the prototype to identify what has

changed across them. Any plugin that we need are included in the respective HTML file

and will also be available locally so in case of a lost connection the page will behave like

normal. We have no OS or networking constraints as we are not streaming any of the data

or pulling/posting web data. That will be accomplished when the user returns to their

computer to place their data for the day.

http://cse.msu.edu/~cse435/Projects/F2015/Groups/Team4/links.html



Revised: 11/23/2015 12:59 PM

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.

1. Let’s begin with a quick defect entry that I just found on the left-panel of a

Chevrolet Impala.

Enter basic information before clicking image



Revised: 11/23/2015 12:59 PM

2. I then go ahead and click on the door panel since that is where the defect I found

was located.

3. I am then prompted to describe the defect and click submit. The user can select

the severity from low to high and has a dropdown of defects to choose from.

Save defect and notice spot on car



Revised: 11/23/2015 12:59 PM

4. Then just to verify, I will confirm my defect is listed in the results table.

Searched for “Chester”



Revised: 11/23/2015 12:59 PM

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.

[2] http://cse.msu.edu/~cse435/Projects/F2015/Groups/Team4/

[3]

http://cse.msu.edu/~cse435/Projects/F2015/Groups/Team4/



Revised: 11/23/2015 12:59 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.

Documents

Software Requirements Specification (SRS) Project ...cse.msu.edu/~cse435/Projects/F2015/Groups/Team4/files/requirements...Template based on IEEE Std 830-1998 for SRS. Modifications