The document discusses requirements management practices for new product introductions. It emphasizes the importance of clearly documenting customer needs and linking them to product features, capabilities, and tests throughout the design and development process. A stage-gate process is used to drive cross-functional collaboration and ensure customer expectations are met. Key questions are provided for leadership reviews at each stage to assess alignment with customer needs and authorize moving to the next stage of product development.

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

2. Quality, Predictability & Speed
Clear 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 Needs
Requirements Management
Integrated Design
Stakeholder Communication
Development Agility
End-to-End Testing
Design For Manufacturability
Customer 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

3. Delivering Product Performance
By 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

4. VOC for innovation
VOC for misdirection
Helping Our Customers Succeed
VOC 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

5. Gathering Customer Needs
Using 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 inquiry
2. Conjoint analysis
3. Concept testing
4. Lead customer feedback
5. Market research
6. Web-hosted discussions
7. Web and e-mail surveys
8. Interviews
9. Surveys
10. Focus groups
Customer Needs
5
Contextual Inquiry
The technique of going to “where the work is done” to
conceptualize work practices, systems and experiences

6. Managing Customer Value
CTQ 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”
Customer
Needs
“How”
System
Capabilities
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.

7. Linking Needs, Features & Capabilities
At 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 Quality
A relational matrix named for its function and appearance
CTQs
Subsystem
Capabilities
Use CasesSystem
Level
Features
Tests
CTQs
CTQs
CTQs
CTQs
Customer
Needs

8. Translating Needs to Requirements
To 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 Display
 Open 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
Requirements
The “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
System
System KPI
Analytics

9. Clear Communications
Clear 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 Requirements
Correct:
 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

10. Customer Experience
Use 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 Cases
Describe how the user will interact with the system to
accomplish a particular goal

11. Stage-Gate® Overview
Stage-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 1
Preliminary
Investigation
Stage 2
Solution
Design
Stage 3
Development
& Verification
Stage 4
Controlled
Launch
General
Availability
1 2 3 4 5
Gate 1
Go To
Preliminary
Investigation
Gate 2
Go To
Solution
Design
Gate 3
Go To
Development &
Verification
Gate 4
Go To
Controlled
Introduction
Gate 5
Go To
General
Availability
Voice of the Customer
Listening to their needs and responding with solutions

12. 12
Stage 0
Stage 0
Idea 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 1
Go to Investigation

13. 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. 14
Stage 1
Stage 1
Preliminary 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 2
Go to Solution Design

15. 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. 16
Stage 2
Stage 2
Solution 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 3
Go To Development &
Verification

17. 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. 18
Stage 3
Stage 3
Development & 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 4
Go To Controlled
Launch

19. 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. 20
Stage 4
Stage 4
Controlled 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 5
Go to GA

21. 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 Cpk
targets? 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

22. 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 mean
Controlled 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’ processes
Quality 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
applications
Verification: The process of gathering objective evidence that
design/development outputs meets the input requirements
Voice 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.

23. Customer Focus Teams
Project 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
Governance
Decision making practices that define expectations, assign
authority, and verify performance
Exec
Sponsor
Gate Reviews
Customer Focus Team
Meetings

24. Failure Modes and Effects Analysis
Failure 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 expectations
Effects 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 Cause
5. Assess Severity
6. Assess Preventability/Detect-ability
7. Assess Probability of Occurrence
8. 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

25. 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 lifecycle
1. 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

26. 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 measurements
Standard Deviation (σ): A measure of the scatter (or spread) of
measurements
σ6SpreadExpected
ToleranceSpecified
Cp
LSLUSL −
==
2/LSL)USL(
|-Target|
k
wherek)-Cp(1Cpk
−
=
=
µ

27. Statistical Process Control
Regardless 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 10
Time
UCL
X-bar
LCL
Out of control
Limit)Control(Lower
e)(Centerlin
Limit)Control(Upper
3LCL
3
pp
p
pp
barX
UCL
σµ
µ
σµ
−=
=−
+=