Vehicle Functions: Definition to Validation

Joe Lotz Kenworth Truck Co.

If I had an hour to save the world, I would spend 59 minutes defining the problem.

— Albert Einstein

• Requirement Engineering

• Requirement Quality

• V-Cycle

• Validation

•Hands-On Exercise

Agenda

Act 1:

Life, Liberty, and the Pursuit of Good Requirements

We all hate software defects.

If we are all smart and just work hard we shouldn’t have them.

Software Defects

Requirements account for two of the top 10 sources of defects! • Miscommunication of requirements introduces error in code

• Last minute changes in the requirement introduce error

• Software – SPICE/ASPICE

• Embedded – AutoSAR

•Hardware – Six Sigma (DFSS)

• Functional Safety – ISO26262

Quality Initiatives

Best Practices

Standards

Tools

Procedures

REQUIREMENTS!!!

Requirements must be written “SMART” – Specific

– Measurable

– Attainable

– Realizable

– Traceable

Garbage In = Garbage Out

• Specificity covers several areas: o Clear- no ambiguity

o Consistent- same terminology is used throughout

o Simple- avoid double requirements like “system shall be X and Y”

o An appropriate level of detail

• Indicators of an unspecific requirements include: o Phrases like “obviously, clearly, certainly”

o Ambiguities like “some, several, many”

o Terminators like “etc, such as, and so on”

Specific

• General guidelines o Ensure pronouns are clearly referenced

o When numbers are specified identify the units

o Use pictures to clarify understanding

o Ensure all acronyms or unique terms are defined

o Avoid “TBDs” in the requirement, unless it is in the GAPS field

Specific

• Measurable means it is testable. Once this function or product is built the requirement can be, in fact, be verified to be accomplished. – Bad Example: “The vehicle shall meet all the driver’s needs.”

• A common failure is a requirement that is specific but has no metric to test. – Bad Example: “The system shall be implemented within an optimized

architecture.”

– The only way to measure this is to compare it to the absolute optimum.

Measurable

• General guidelines o What other requirements need to be verified before this requirement?

o Can this requirement be verified as part of the verification for another requirement? If so, which one?

o How much data and what test cases are required?

o Can the test be conducted in-house?

o Specification authors attempt to consider these but it is the ultimate responsibility of the Test Engineer to ensure requirements are measureable.

Measurable

• An attainable requirement means it is possible for the system to meet this requirement. o Bad Example: “The function shall be 100% defect free.”

Attainable

Requirement Intermission

Karl Wieger’s Cosmic Truths

1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.

2. Requirements development is a discovery and invention process, not just a collection process.

3. Change happens.

4. The interests of all the project stakeholders intersect in the requirements process.

5. Customer involvement is the most critical contributor to software quality.

6. The customer is not always right, but the customer always has a point.

7. The first question an analyst should ask about a proposed new requirement is “is this requirement in scope?”

8. Even the best requirement document cannot and should not replace human dialogue.

9. The requirements might be vague, but the product will be specific.

10. You’re never going to have perfect requirements.

Karl Wieger’s Cosmic Truths

Source: More About Requirements: Thorny Issues and Practical Advice

1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.

2. Requirements development is a discovery and invention process, not just a collection process.

3. Change happens.

4. The interests of all the project stakeholders intersect in the requirements process.

5. Customer involvement is the most critical contributor to software quality.

6. The customer is not always right, but the customer always has a point.

7. The first question an analyst should ask about a proposed new requirement is “is this requirement in scope?”

8. Even the best requirement document cannot and should not replace human dialogue.

9. The requirements might be vague, but the product will be specific.

10. You’re never going to have perfect requirements.

Karl Wieger’s Cosmic Truths 10 Commandments

Source: More About Requirements: Thorny Issues and Practical Advice

1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.

2. Requirements development is a discovery and invention process, not just a collection process.

3. Change happens.

4. The interests of all the project stakeholders intersect in the requirements process.

5. Customer involvement is the most critical contributor to software quality.

6. The customer is not always right, but the customer always has a point.

7. The first question an analyst should ask about a proposed new requirement is “is this requirement in scope?”

8. Even the best requirement document cannot and should not replace human dialogue.

9. The requirements might be vague, but the product will be specific.

10. You’re never going to have perfect requirements.

Karl Wieger’s Cosmic Truths

Source: More About Requirements: Thorny Issues and Practical Advice

1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.

2. Requirements development is a discovery and invention process, not just a collection process.

3. Change happens.

4. The interests of all the project stakeholders intersect in the requirements process.

5. Customer involvement is the most critical contributor to software quality.

6. The customer is not always right, but the customer always has a point.

7. The first question an analyst should ask about a proposed new requirement is “is this requirement in scope?”

8. Even the best requirement document cannot and should not replace human dialogue.

9. The requirements might be vague, but the product will be specific.

10. You’re never going to have perfect requirements.

Karl Wieger’s Cosmic Truths

Source: More About Requirements: Thorny Issues and Practical Advice

1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.

2. Requirements development is a discovery and invention process, not just a collection process.

3. Change happens.

4. The interests of all the project stakeholders intersect in the requirements process.

5. Customer involvement is the most critical contributor to software quality.

6. The customer is not always right, but the customer always has a point.

7. The first question an analyst should ask about a proposed new requirement is “is this requirement in scope?”

8. Even the best requirement document cannot and should not replace human dialogue.

9. The requirements might be vague, but the product will be specific.

10. You’re never going to have perfect requirements.

Karl Wieger’s Cosmic Truths

Source: More About Requirements: Thorny Issues and Practical Advice

1. If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.

2. Requirements development is a discovery and invention process, not just a collection process.

3. Change happens.

4. The interests of all the project stakeholders intersect in the requirements process.

5. Customer involvement is the most critical contributor to software quality.

6. The customer is not always right, but the customer always has a point.

7. The first question an analyst should ask about a proposed new requirement is “is this requirement in scope?”

8. Even the best requirement document cannot and should not replace human dialogue.

9. The requirements might be vague, but the product will be specific.

10. You’re never going to have perfect requirements.

Karl Wieger’s Cosmic Truths

Source: More About Requirements: Thorny Issues and Practical Advice

Act 2:

There’s gold in them there hills!

Act 2:

Dabbing to the Oldies

V-Cycle Visualizations

Product/Functional Reqs & Architecture

SW/HW Technical Reqs & Design

“Engineering”

“Business” Validation

Functional Validation

Tech Validation

Business Level

Product Level

System Level

Component Level

Needs & Constraints

Business Level

Product Level

System Level

Component Level

SPICE

Design & Implement Test & Validation PACCAR Global

[-] A

bstra

ctio

n [+

]

[-] Timing [+]

Two-Dimensions?

Business Level

Product Level

System Level

Component Level

Vertical Axis = “Abstraction” Level

[-] A

bstra

ctio

n [+

]

[-] Timing [+]

Concurrent Engr = Not a Waterfall!

Business Level

Product Level

System Level

Component Level

V-Cycle Visualizations

Business Level

Product Level

System Level

Component Level

V-Cycle Visualizations

Traceability

Functional Specifications

Technical (Control System) Specifications

Software Specifications

Component Hardware Specifications

Functional Requirement Specification Functional Design Specification

Technical Control System Specification

Software Requirement Specification

Hardware Specification

Example: Windshield Wipers and Washer Function

Architecture Requirement Specification

Mapping Back to V-Cycle

Functional Specifications

Technical (Control System) Specifications

Software Specifications

Component Hardware Specifications

Spec A Spec B

Spec C

Spec E

Spec F

Spec D

Functional Requirement Specification

Functional Requirement Specification

(FRS)

Understanding the work

Understanding the product

Documenting the requirements

Functional Requirements

Business Requirements

Constraints Regulatory Requirements

Prototype

Business Use Cases 1. ------ 2. ------ 3. ------ 4. ------

Scenarios/ User Stories 1. ------ 2. ------ 3. ------ 4. ------

Gov’t Regulations (FMVSS, CMVSS, NHTSA ,etc)

Standards (SAE, ISO, TMC, etc)

Vehicle Property Standards (SOS)

Function and Property Roadmaps

Functional Design Specification

Design Concept System

Constraints

Functional Design

Specification (FDS)

Control System Reqs

Functional Architecture

Understanding the work

Understanding the product

Documenting the requirements

Functional Requirement Specification

(FRS)

Prototype Simulation (Fuel Econ, Functional, HMI, etc.)

Black-Box Model

Business Level

Product Level

System Level

Component Level

Why so Many Layers???!

Complex Systems are…Complex

Translators Requestors Control Functions Arbitrators Governors Actuators

Actual functional architecture for MY14.

Currently Used Tools

IBM Rational Rhapsody Functional & E/E Architecture

Software Architecture

Functional & Technical Models

Requirement Specifications MS Word

Test Plans and Results

Finale: Show Me the Money!

(Hands on Exercise)

Aliens have landed! As the Chief Engineer of United States, it is up to you to establish diplomatic relations.

Requirement Exercise

It has been decided that you will teach our intergalactic visitors how to prepare the official dish of university students, the Peanut Butter and Jelly Sandwich**.

Instructions

1. I will break you into teams – Cross functional teams of people you are unfamiliar with are

common

2. You will have exactly [X] minutes to prepare instructions on making a PB&J sandwich.

– Rarely do you work without a deadline, time to market is important

3. Your instructions/requirements must be sufficient to communicate to aliens from a foreign planet how to make this sandwich.

– This is your job!

•Assume the aliens: – speak/read English

– are familiar with nouns (bread, knife, plate)

– have human biological function and capabilities (can see, opposable thumbs, etc)

– do not have a priori knowledge (they have never seen or heard of peanut butter, jelly, or sandwich)

• This exercise is focusing on the quality of the instruction/requirement document

Assumptions

• The following are available to you: – One (1) Loaf of white bread in a bag

– One (1) Jar of Peanut Butter

– One (1) Jar of Jelly

– One (1) Butter Knife

– One (1) Paper Plate

– One (1) Napkin

Bill of Materials

• You now have exactly 3 minutes to ask “the customer” questions about anything!

Questions and Clarifications