Introduction

Recently, New Product Introduction (NPI) stakeholders participated in a needs analysis on the topics of Design For Six Sigma (DFSS) and Requirements Management. The needs were clear:

To design products and services that help our customers succeed, we need to design quality in from the onset, rather than improving it after feedback from manufacturing and customers.

Specifically, we heard you ask for the following: • Improve NPI speed and predictability • Ensure customer-focused needs are:

documented; translated into features; mapped to technical solutions; and tested

• Improve requirements prioritization • Monitor quality throughout the NPI process• Evaluate and communicate the impact of changes

We are deploying an integrated set of DFSS processes and requirements management tools which provide quantitative insight and a higher degree of certainty about product deliverables.

To ensure we achieve this vision, adherence to the requirements management life cycle is a pre-requisite for test entry.

This booklet is your reference for sound requirements management practices.

Introduction

1

Quality, Predictability & SpeedClear focus on customer needs directs our NPI efforts on a productive and purposeful path; leading to shorter development time, improved revenue and reduced costs.

To meet customer needs, we consider multiple dimensions of quality. The list below is adapted from David A. Garvin’s paper, “What Does ‘Product Quality’ Really Mean?”1

Improving COPQ requires a holistic view:

Customer NeedsRequirements Management Integrated DesignStakeholder CommunicationDevelopment AgilityEnd-to-End TestingDesign For ManufacturabilityCustomer Feedback

Lean Requirements Management

2

Cost Of Poor Quality (COPQ)Costs to be avoided with improved design, processes and controls. Wasted effort due to internal & external failures.

Performance Operation of primary functions

Features Desirable enhancements

Reliability Ability to maintain quality over time

Conformance Meets applicable standards

Durability Robust to use conditions

Usability The ease of install, use & repair

Aesthetics Solution attractiveness

Perceived Quality Image, brand & reputation

Delivering Product PerformanceBy applying resources to document and trace requirements, the core team can flow-down design requirements expressed in terms of customer needs with Critical To Quality (CTQ) goals –and then flow-up test cases aligned with those needs.

Lean Requirements Management

3

Customer Need

System Features

Subsystem Capabilities

Module or Assembly Functions

Component Specs

Component CTQs

Module or Assembly Outputs

Subsystem Outputs

System Performance

Mfg. Process Targets

Mfg. Process Controls

Test

Customer Use Cases

Voice of the Customer

f(x)

f(x)

f(x)

f(x)

WHY: The Utility needs to improve revenue by

minimizing loss

VALIDATE: Valve closes quickly

WHAT: Leak Detect & Remote Shut-off

HOW: Analytics, Controls & Valve

PPAP

Customer Solution

RESULT: Minimized loss due

to leaks

Cp/Cpk

SPC

VERIFY: Test Cases

VOC for innovation

VOC for misdirection

Helping Our Customers SucceedVOC is a powerful tool that drives innovative solutions. Sensus analyzes diverse customer statements to produce clear & unambiguous customer need statements.

Customer Needs

4

Customer Need

“Tommy Traveler needs a fast & ad

hoc means of transportation”

Henry Ford said, “If I’d listened to my customers...

…I would have built a faster

horse.”

To align VOC throughout the development process: Screen ideas within the context of customer value proposition Express high level requirements in terms of customer needs and

detail level requirements in terms of use cases Link customer needs to design and testing using requirements

traceability

Voice of the Customer (VOC)Listening to their needs and responding with solutions

Gathering Customer NeedsUsing effective techniques for gathering VOC enables us to integrate customer needs into the product/solution development process. There is no substitute for spending time with customers to gain a clear understanding of their needs. Contextual Inquiry is one technique that fosters customer participation in the design process and enables us to create solutions that will delight our customers.

1. Contextual inquiry2. Conjoint analysis3. Concept testing4. Lead customer feedback5. Market research6. Web-hosted discussions7. Web and e-mail surveys8. Interviews9. Surveys10. Focus groups

Customer Needs

5

Contextual InquiryThe technique of going to “where the work is done” to

conceptualize work practices, systems and experiences

Managing Customer ValueCTQ is an acronym for Critical To Quality characteristics. The measures of CTQs are the internal quality parameters that directly relate to the wants and needs of the customer

By focusing on CTQs, we will: Reach design maturity faster on critical parameters Improve collaboration and ownership of cross-functional

parameters Facilitate statistical modeling and optimization Connect analysis between system, sub-system and components

EXAMPLE:Why- The customer needs to minimize loss upon detecting a leak.How- Remote actuated shut-off valve.CTQ - Time from leak detection to shut-off. (At a customer level)

CTQ s are quantitatively managed through-out the product lifecycle

Customer Needs

6

“Why”

CustomerNeeds

“How”

SystemCapabilities

CTQs

“When, Where, How Much”

Critical To Quality (CTQ)Key functional variables that control the performance of the

system. The “vital few” measures to assure customer needs are met at every stage of design & deployment.

Linking Needs, Features & CapabilitiesAt each stage of development, the NPI team collaborates to define customer needs and the corresponding technical requirements. Each level links the VOC to the product deliverables and test.

The technique to collaboratively document the relational matrix between two requirement levels is “Quality Function Deployment (QFD)”

The House of Quality relates any two linked levels

Requirements Traceability

7

Relationship Matrix

Customer Needs

Or Features

Capabilities (Technical or Usability Requirements)

Requirements Correlation

Matrix

House of QualityA relational matrix named for its function and appearance

CTQs

Subsystem Capabilities

Use CasesSystem Level

Features

Tests

CTQs

CTQs

CTQs

CTQs

Customer Needs

Translating Needs to RequirementsTo simplify documentation and traceability of customer needs through test, Sensus has defined: Features and Capabilities.

Features are identifiable characteristics that correlate to the customer value proposition. They describe “What” our product will deliver to the customer.

Accurate Metrology System Health Dashboard Remote Disconnect One-button Install

Capabilities are the technical and usability functions of our products. They specify “How” the design will solve our customers’ problems.

Measure Gas Volume Using Ultrasonic Technology Show Outage Map on a Computer DisplayOpen Mechanical Switch via RF Signal Execute Pre-programmed Configuration

A feature typically consists of multiple capabilities. Capabilities may have children and grandchildren.

Requirements Traceability

8

RequirementsThe “must have” functions of the system.

Capability Titles(HOW)

Feature Title(WHAT)

Customer Need

(WHY)Display Real-Time System

Analytics (Health KPIs)

Detect & Alert upon Anomalies

Generate Scheduled System Reports

Manage Distribution

SystemSystem KPI

Analytics

Clear CommunicationsClear and unambiguous documentation of cross-functional commitments for product needs, features and capabilities ensures success in:

translating needs into requirements, aligning a sound system-level conceptual solution, allocating to sub-system and product components forecasting the ability of the design to meet CTQs verifying with internal test, and validating with customers.

Characteristics of Good RequirementsCorrect: Correctly describe the solution behavior & user goals.

Unambiguous: Use specific and appropriate language to avoid ambiguity in

interpretation.Complete: Completely describe the solution’s expected behaviors and feature set.

Consistent: Requirements for the solution must not contradict each other.

Prioritized: Each requirement has its own level of importance, criticality, and value to

our customers. By prioritizing requirements, the development team is focused and effective in prioritization & trade-off decisions

Verifiable: If the requirement cannot be verified as having been met, then the

requirement itself is written poorly. Amendable: Requirements must support any necessary amendments as more is

learned about customer needs or technological capabilities. All stakeholders need to be aware of the change and of their responsibilities in regard to the change.

Traceable: The requirements must be traceable from Customer Need => Design =>

Development => Test

Requirements Quality

9

Customer ExperienceUse Cases enable the NPI team to: Develop a detailed use concept that:

defines the environment the product will be operating in including boundaries and constraints

defines the interaction of the product, the end user and the environment and

satisfies operational, maintenance, support, and disposal needs.

Establish and maintain a definition of required functionality that: supports analysis of requirements to identify logical or

functional partitions helps allocate customer needs to functional partitions,

people or support elements to aid the synthesis of systems considers the sequencing of time critical functions both

initially and during product-component development

Use Cases

10

Use CasesDescribe how the user will interact with the system to

accomplish a particular goal

Stage-Gate® OverviewStage-Gate® is a project road map to drive new products to market quickly and successfully. This framework is based on a proven Stage-Gate® approach.

This process integrates Voice of the Customer (VOC) into product development; assuring quality expectations are met from the onset.

Stage-Gates drive cross-functional collaboration early in the conceptualization, design, development and realization of Sensus solutions. This collaboration enables our teams to:

• Proactively ensure great product design and quality• Balance projects and resources• Assure sufficient systems test coverage• Ship the right products at the right time• Reduce/eliminate premature product launch

Stage Gates

11

Stage 1Preliminary

Investigation

Stage 2Solution Design

Stage 3Development & Verification

Stage 4Controlled

LaunchGeneral

Availability

1 2 3 4 5

Gate 1Go To

Preliminary Investigation

Gate 2Go To

Solution Design

Gate 3Go To

Development & Verification

Gate 4Go To

Controlled Introduction

Gate 5Go To

General Availability

Voice of the CustomerListening to their needs and responding with solutions

12

Stage 0

Stage 0Idea Generation

Market analysis Customer insight Innovative solutions Technological

excellence

VOC & Strategic Fit• Explore market

opportunities• Identify strategic value

and fit• Gather high-level VOC• Analyze competition• Kick off concept team• Innovate• Brainstorm preliminary

concepts• Initiate ground-work

technical investigation

Why will our customers

need a Sensus solution?

Gate 1Go to Investigation

Gate 1: Go To Investigation

REQUIREMENTS MANAGEMENT PRACTICES : All relevant customer needs are clearly & unambiguously documented with sufficient information to answer the following key questions:

What customer problem are we solving?

What is the customer value proposition associated with this need?

How does this idea fit with the overall Sensus strategy?

How do our preliminary solution ideas leverage our core competencies?

What are the right technology capabilities and the right partners to deliver a solution?

What is the estimated probability that this need will result in a profitable business case?

What resources will be needed to further define this solution?

What is the estimated return on investment?

LEADERSHIP DECISIONS:What is the priority of this need & solution within our strategic roadmap?

Is the team authorized to invest in technical investigation & defining solution concepts?

Key Questions

13

14

Stage 1

Stage 1Preliminary Investigation

Analyze customer needs

Quantify customer expectations

Translate to features Identify trade-offs

What features can we deliver?

Scope & Charter• Finalize Market

Assessment• Complete Business Case• Identify the most critical

customer needs (CTQ)• Validate strategic fit• Document concepts• Architect system level

solution • Identify high-level

risk/reward • Forecast technical

feasibility

Gate 2Go to Solution Design

Gate 2: Go to Solution Design

REQUIREMENTS MANAGEMENT PRACTICES: Customer needs are linked to features which are documented with sufficient information to answer the following key questions:

How does the solution fit into our short and long term goals?

What are the most important customer needs (Critical to Quality attributes)?

What are the key features that will solve the customers problems?

What are the high-level feature deliverables, risks and constraints?

How will the customers use this solution?

What is the “informed” probability that this concept will achieve its business case?

What are the right technology capabilities and the right partners to make this concept a reality?

What is the estimated probability that the high level concept will meet the customer needs?

What departments and functions will be needed to deliver this feature set?

What percentage of requirements are re-use from previous projects?

LEADERSHIP DECISION:Is the team authorized to invest in Solution Design (detailed investigation, firm up business case, solution architecture and technical specs)?

Key Questions

15

16

Stage 2

Stage 2Solution Design

Define technical solution(s) to meet customer needs

Verify performance targets

Identify risks, trade-offs and conflicts

How will we meet customer expectations?

Design & Plan• Verify value to customer• Approve business case• Firm up customer needs

and feature definitions• Match customer needs to

technical deliverables (QFD)

• Design solution architecture

• Set Performance Targets• Forecast CTQ

performance• Create Project Mgt. Plan• Plan test strategy

Gate 3Go To Development & Verification

Gate 3: Go To Development & Verification

REQUIREMENTS MANAGEMENT PRACTICES: Customer needs are linked to features and capabilities which are documented with sufficient information to answer the following key questions:

How do we know that target market, customer needs and solution concepts are aligned? Is everybody in agreement?

How have we ensured customer needs and high level solution architecture cover all critical requirements?

How were the lessons learned from previous products been incorporated into this design?

What departments/functions are allocated to deliver these requirements? Are they committed?

What are the strengths/gaps in technology capabilities, resources and the partners to develop this solution as designed?

How is the test strategy linked to the customer needs, features and high-level capabilities?

How will we manage changes to requirements during NPI?

How well does the proposed solution fulfill our customers’ needs? Is this a winning solution definition?

LEADERSHIP DECISION:Is the team authorized and resourced for Development & Verification (building, coding, tools and testing)?

17

Key Questions

18

Stage 3

Stage 3Development & Verification

Ensure Design Margin and Robustness

Optimize Performance

Set Optimal Levels for Trade-offs

Minimize Variation

What assures the best

customer experience?

Develop & Assure Quality• Finalize documentation of

technical capabilities• Design reviews • Code & develop• Assure quality is “designed-

in“ (DFMEA, reliability & design tests)

• 3a: Execute Internal Testing• Analyze CTQs (on target

with acceptable variation)• 3b: Execute validation tests

(field trials, BETA)• Assure manufacturability• Prepare agency approvals

Gate 4Go To Controlled Launch

Gate 4: Go To Controlled Launch

REQUIREMENTS MANAGEMENT PRACTICES: Customer needs are linked to features, capabilities and tests which are documented with sufficient information to answer the following key questions:

How are we linking VOC to the Controlled Launch plan?

What has been the customer response to Proof-of-Concept, Beta and/or early field trials?

How are we ensuring the system will be robust to customer use conditions?

What modeling, simulations and/or validations have been completed on the initial design and prototypes?

What are the predicted/verified performance levels of the CTQs?

How does training, documentation and information for the sales/support team relate back to the features and capabilities of the product?

What are the biggest risks from the process FMEA?

What quality plans and control plans have been put in place?

How well does the solution meet the customer needs?

How does the current financial forecast differ from the original business case?

LEADERSHIP DECISION:Is the product ready to produce and ramp up volume?

Key Questions

19

20

Stage 4

Stage 4Controlled Launch

Validate our solution fulfills functional and usability needs

Ensure supply chain capability

Launch product Achieve business

case

How do we prove we’ve

met customer expectations?

Ramp & Validate• Provide market launch

docs and training• Validate performance to

customer requirements• Facilitate field tests

and/or controlled launch• Validate manufacturing

test systems• Assure manufacturing

readiness and capability (PFMEA, Cp/Cpk & SPC)

• Assure supply chain quality and capacity

• Enable technical support• Final Approvals

Gate 5Go to GA

Gate 5: Go to General Availability

REQUIREMENTS MANAGEMENT PRACTICES: Customer needs were validated by customers during controlled launch; “closing the loop” with sufficient information to answer the following key questions:

What is the feedback from customer validation/field tests? What aspects have delighted our customers? How did we meet customer needs?

What performance goals were met during process and production validation? What goals were not met?

Why is this a great solution for our customers?

How do the sales materials and feature descriptions match with the product capabilities?

What are any risks or gaps in our test coverage?

How have the risks from the FMEA evaluations been mitigated?

How will process CTQs be monitored during production?

What components have CTQ dimensions? Do they meet Cpktargets? How will they be monitored?

How was the technical services team trained and prepared to support customer calls and support requests?

How does the current financial forecast differ from the original business case?

LEADERSHIP DECISION:Should we launch this product to general customers (General Availability?)

Key Questions

21

Key Definitions:Capabilities: The technical and usability functions of our products. Specify “How”

we’ll meet customer needs.Cp & Cpk: Indices that calculate the ratio of tolerance to performance. Cpk

accounts for the shifting of the meanControlled Launch (CL): Controlled product release with all components at fully

released status; to gain early live network experience and validate delivery/support processes

Critical To Quality (CTQ): Key functional factors that control the performance of the system. The “vital few” measures that assure customer needs are met at every stage of design & deployment

CTQ Measure: A factor used to measure performance, (e.g., current draw, Bill of Material cost, Bit Error Rate, etc.)

Customer Needs: Contextual descriptions of customer needs Design of Experiments (DOE): A planned and controlled experiment where

multiple factors are set at discrete levels and the effect of the factors and their interaction is mathematically determined

Failure Mode and Effects Analysis(FMEA): A form of risk analysis that identifies potential failure modes and supports prioritization of actions to prevent or mitigate the effect of the failure

Feature: identifiable characteristics that are correlated to the customer value proposition. They describe “What” our product will deliver to the customer.

Function: The fundamental purpose of a thing expressed in Action-Verb/Noun pair. (e.g., “emit light”)

Generally Available (GA): Product is shippable to the broader market. All delivery & support processes have been successfully validated.

Gate: A “Go/No Go” decision point in the product life cycle.House of Quality (HOQ): An input-output relationship matrix used in the

collaborative process of Quality Function Deployment (QFD).Production Part Approval Process (PPAP) is used in the for establishing

confidence in component suppliers’ processesQuality Function Deployment (QFD): A collaborative and focused method for

deploying VOC throughout the product design stages.RPN: Risk priority number used in FMEA. Statistical Process Control(SPC): Analysis to ensure on-target and low-

variability performance of a system.Validation: The processes to confirm the solution meets the intended use and

applicationsVerification: The process of gathering objective evidence that

design/development outputs meets the input requirementsVoice of the Customer (VOC): The needs of a customer expressed within context

but without pre-assuming a solution.

Definitions

22

1. D. A. Garvin, “What Does ‘Product Quality’ Really Mean?” Sloan Management Review, vol. 26, no. 1, Fall 1984.

Customer Focus TeamsProject Management via dedicated Customer Focus teams provides a governance framework and accountability to ensure the solution will:

Meet customer expectations Achieve the business case Ship when committed

Customer Focus Team Meetings: At a product/solution level, the team identifies applicable deliverables for both product and project management. The team ensures these deliverables are met using cross functional documentation of requirements and CTQs

Gate Reviews: Executive Sponsors and cross-product stakeholders review overall portfolio progress. These meetings facilitate cross-functional communication, resource balancing, and visibility to project progress. “Go/No Go” is approved in these meetings.

Executive Sponsor: The executive sponsor supports portfolio prioritization, resource allocations and strategic decisions.

Appendix A

23

GovernanceDecision making practices that define expectations, assign

authority, and verify performance

ExecSponsor

Gate Reviews

Customer Focus Team Meetings

Failure Modes and Effects AnalysisFailure Modes and Effects Analysis (FMEA) began as a reliability

analysis tool, and is now become a method for risk management.

Failure Mode The manner in which the product/part or service does not

meet the customer’s expectationsEffects Analysis

A study of the effects of failure to achieve the designed function

FMEA Steps:1. Define Function (action-verb/noun pair)2. Identify Failure Modes (no function, impaired function,

intermittent function, intermittent function, unintended function)3. Identify Effect (on customer observable function)4. Identify Cause5. Assess Severity6. Assess Preventability/Detect-ability7. Assess Probability of Occurrence8. Calculate RPN (product of above 3)

Appendix B

24

Customer Observable Functions

We can apply FMEA at any level to see what the effects of failures are at

higher levels and ultimately on the

customer

System

Subsystem

Assembly

Subassembly

Component

Design For Excellence (DFx)Application of DFx methodology during the design stages improves efficiency, and lowers the total cost and lead time of the product.

DFx lifecycle1. Requirements: Market, product & production requirements

provide sufficient information for the core team to determine applicable DFx concepts.

2. Design & Development: Engineers integrate design guidelines into their “work-products”(code, schematic, board layout, mechanical design, BOM, etc.)

3. Reviews: Stakeholders & SME’s review “work-products” and CTQ’s at various levels of maturity. Compliance to DFx confirmed.

4. Output/Action: Documentation and action tracking is via FMEA

5. Control: Any failure modes and quality risks that could not be mitigated through design margin or process capability require Quality Control (i.e., SPC, production tests, etc.)

Appendix C

25

Design Production End of Life

All DFx Factors

Quality Assurance

• Design Guidelines

• Design Reviews

• FMEA

• Test

Design for Manufacturability, Assembly & Testability

Quality Control

Design for Serviceability, Usability, Reliability, Legal Metrology, Safety …

Design for Sourcing & Logistics

Design for Install, Deployment

Design for Disassembly,

Disposal

Design for Performance, Usability

Product & Process Capability

Appendix D

26

Documenting CTQs and monitoring the ability of the design to meet those CTQs through-out NPI answers “is this product on track to meet quality goals?” The capability index is first estimated, then modeled and then measured during the NPI life cycle.

A ratio of “Engineering Tolerance” to “Expected Spread” is defined as the capability index, Cp. Assuming that observed variations result in normally distributed measures:

USL – Upper Specification Limit ; LSL – Lower Specification Limit 6σ – a measure observed of the distribution width or spread

The Cpk index diminishes the Cp ratio for any “off-center” of the observed mean, µ, compared to the engineering target value:

To ensure product & process variations don’t cause customers defects the suggested minimum target for CTQs is: Cp ≥ 2 and Cpk ≥ 1.5

Mean (µ): The mathematical average of measurementsStandard Deviation (σ): A measure of the scatter (or spread) of measurements

σ6Spread ExpectedTolerance SpecifiedCp LSLUSL −

==

2/LSL)USL(| -Target | k

wherek)-Cp(1Cpk

−=

=µ

Statistical Process ControlRegardless of the quality of design, inherent variation is present in production processes. A process that is operating with only “chance causes” of variation is in statistical control.

SPC dimensions correlate well to overall process performance and can help differentiate between the expected pattern of chance causes of variation and unexpected assigned causes of variation.

Control Charts aid in visualizing trends to indicate when a process is out of control. To create these charts, SPC data is periodically collected by randomly selecting individual items to measure at pre-defined intervals of time. The sample mean (x-bar) can be plotted along with the process control limits. Process limits may be calculated from historical process mean, µp and standard deviation, σp:

Similarly, a range chart (R) can be constructed. Statistics tables or software can aid in determining control limits for R charts.

Appendix F

27

Statistical Process Control (SPC):On-going analysis to ensure on-target and low-variability

performance of a system over time.

1 2 3 4 5 6 7 8 9 10Time

UCL

X-bar

LCL

Out of control

Limit) Control(Lower

e)(Centerlin

Limit) Control(Upper

3 LCL

3

pp

p

pp

barXUCL

σµµ

σµ

−==−

+=