Arena
Best Practices

Gain Insights for Your
Product and Quality Processes

Product Requirements Management Matters

Product Requirements Team No matter what business you are in, requirements management matters and is, indeed, management—not a one-time collection of voice of customer (VOC) wishes, technical checklists, marketing projections, and sales requests. Without active, day-to-day, week-to-week product management (which we might argue is requirements management), products fail to launch or miss targets. Dr. Christof Ebert, an adviser, and researcher in product strategy and development, notes that usually only half of the originally allocated requirements will appear in a final product release.¹

If this is true, we should consider how to know which half is the right half. Dr. Ebert cites several examples of product and company failures that resulted from an inability to manage products with requirements management from the beginning of new product development (NPD). From the software world, he refers to Netscape, one of the first browsers many of us of a certain generation experienced. In 1995, Netscape had 80% of the market share but was bankrupt by 2003. One of Netscape’s managers captured the main failure point: “We had no product management; it was just a collection of features.” Dr. Ebert also points to the much-belabored Nokia and his discussions with Nokia senior management who claim the lack of effective product management is a primary contributor to its continued loss of market share.

Companies that want to avoid product failures need good product management processes that encompass product requirements management best practices. Today’s customers, regulators, and competitors have unprecedented visibility into product performance and quality upon product release. Consumers read social media and marketplace comments. Regulators like the FDA offer a public dashboard of adverse events. Suppliers monitor quality with systems that support oversight and ultimately contract negotiations.

How much can you save on product development?

A single product design mistake can result in quality or manufacturing issues—delaying your next product launch and running costs into the millions.

Our cost calculator includes visible costs, such as team expenses and tooling, along with strategic cost impact analysis from lost market opportunities and customer dissatisfaction.

To calculate the costs of your product development errors and how much you can save, simply input your business details, select a challenge, and see the real-world cost impact as validated by our customers.

Calculate Savings

Product performance and quality demands are increasing. For example, many industries and market spaces do not allow a company to release a “buggy” or poor quality product with the goal to fix or improve it after its release. For FDA regulated medical device companies, CFR 21 Part 820 requires traceable, documented management of design planning, design inputs, design review, design outputs, and design verification. The FDA enforces this to ensure products meet “user needs, intended use, and specified requirements.” In other words, the FDA strives to ensure products are safe and effective as intended.

Project & Requirements Management Challenges

requirement management scale Cross-functional, requirements management is one of the primary areas product companies can focus on to improve new product introduction (NPI) success because it is an area most companies do poorly today. The 280 Group 2015 survey found that a frightening 49.2% of respondents reported teams within the same company using different processes for project management.²

Dr. Ebert’s work echoes this survey, citing the critical role of product management between strategy and implementation. His research shows success factors for companies include having “a standardized product lifecycle,” clear requirements of customer value, and consistent communication, which we attribute to common, understood, and shared processes across the company. requirement management quote In the domain of complex products with mechanical, electrical, and software components (and the teams for each area in research, engineering, operations, and supply chain partners), strong data shows that most NPI teams are still using office tools to write and manage requirements.

According to LNS, over 90% use spreadsheets for some or all tracking. Such management methods are disconnected from the product record, quality actions, and, most likely, other product requirements, particularly in other engineering disciplines (e.g., mechanical, electrical, software). One avenue to solving some of the requirements management challenges is implementing a standard product management process across all product development engineering teams (e.g., hardware, software, electrical, firmware), operations, quality, and partners.

For complex product companies as well as highly regulated industries such as medical devices, a single accepted and unified process provides better visibility of product management goals, issues, and product dependencies to improve NPD results.

What Is Product Requirements Management?

Product requirements management is the process of documenting, analyzing, tracing, prioritizing, and agreeing on product requirements and then controlling change and communicating to relevant stakeholders. Requirements management occurs throughout an NPD project leading to NPI. Requirements are typically:

Design constraints
Testable
Interface-centric (what the product is perceived to be)
Mostly about what the product should do

The FDA quality system regulation describes design input, design output, and design verification (product requirements management), all elements of design controls, for medical device companies. Design input specifies requirements and requirements management. Design output and design verification describe steps that ensure the outputs conform with the inputs.

21 CFR 820.30 (c) “Design input. Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented.”

21 CFR 820.30 (d) “Design output. Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements…”

21 CFR 820.30 (f) “Design verification. Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements…”

Managing your product requirements well, using a product requirements management tool, can help you break through NPI barriers and be compliant with quality system regulations.

Doing Product Requirements Management (Insert Your Word of Choice Here)

Faster. Better. More Efficient. With Higher Quality. What your company needs this quarter or this year out of a product requirements management tool may differ from what you needed last year or what your competitors need. Regardless of your overall objectives, the following components are present in the best requirements management tools. Using a requirements tool with these components will bring you closer to your NPD goals.

Component 1: Connected, Visible Requirements

Requirements launch formal NPD work by identifying and understanding customer needs. Driven from market trends, customers, technology, product gaps, and opportunities, companies seek to innovate, leapfrog in the market, capture bigger market shares, and stay relevant through new products. Every single requirement needs to be captured, justified, prioritized, monitored, and adjusted simply. Dr. Ebert insists that “requirements are a contract mechanism for the project internally and often for a client externally.” Contracts need to be documented, structured in a coherent manner, and visible to everyone.

DON’T	DO	CONSIDER
Let requirements float around in the ether. Almost everyone documents requirements, so this seems too obvious. However, sometimes the obvious needs to be stated.	Identify and document requirements somewhere, anywhere.	When documenting requirements, keep in mind you will eventually want them somewhere they can be shared, modified, updated, changed, prioritized, and/or discarded (yes that happens) as the product work continues.
Allow teams to capture requirements in disparate formats.	Document requirements in a structure that provides transparency, makes sense, and provides easy use. Other product areas (bills of materials, change processes, quality efforts) have structures for the data. While new product development needs to allow for creativity and innovation space, we also can benefit from requirements structures that allow requirements to change, reflecting research, exploration, and collaboration.	Consider structural attributes like what you use in the more controlled areas of your product processes—required fields of data versus optional, categorization and prioritization attributes, and connections to associated information. Determine the right scope of application for each requirement as well as how concrete or abstract it should be—this will help with re-use (discussed below).
Make it difficult for teams to see requirements. Teams typically do not try to hide information (unless you have an obstructionist culture, which is beyond the scope of this discussion); however, it is easy to document requirements in such a way that it inhibits sharing.	Document and manage requirements in a way that encourages better collaboration during product development efforts and then in future for next NPD projects.	Ease of access and the spirit in which the information is made available matter if you want teams to regularly refer to and collaborate on requirements.
Keep requirements separate from the rest of the product record. If requirements are documented in individual documents or stand-alone systems, then there is no connection to the larger product record (e.g., items, assemblies) or other processes (e.g., issue management, quality) without manual intervention.	Connect requirements to each other (minimally) and to developing product record (optimally). Manual notation of product lines, item and assembly numbers can be done at this step.	Invest in optimal efficiency and traceability with requirements managed in the same system as the product record and quality processes. As progress is made on NPD, the full product record reflects changes.

Component 2: Collaborative Requirements Management

equation for encouraging requirements management Product management might be described as an iterative act of asking questions, listening, and listening some more, then collating all inputs to create product plans that generate the biggest possible value to the company. As Dr. Ebert mentions, good product management must balance “projects, people, and politics” and have a firm grasp of value proposition and priorities as early as possible.

Many product management teams do these challenging tasks well but might be tempted to stop after the first iteration. Managing requirements is a constant balancing act, even adjusted daily in domains with short product development cycles and/or where teams follow design processes such as SCRUM and Agile development. These immediate adjustments in product design can affect multiple teams when working on complex, integrated products. Transparent requirements management processes help you meet NPI goals by aligning product development and delivery. Therefore, be prepared to be active, not passive in your management. Encourage teamwork and collaboration as you iterate and work through product or process issues.

How do you encourage both product managers and all team members to participate? One way is to ensure your processes provide visibility to all in a user-friendly system. Visibility increases accountability and what is visible is what gets tracked. A requirements management tool with connected, visible requirements not only enables sharing and collaboration; it also encourages a culture of making the requirements active, updated, and accurate.

Component 3: Requirements Re-Use

If requirements are set down in a connected, structured manner, actively managed, and visible across the teams (Components 1 and 2), then you are positioned to continuously improve future NPD efforts through requirements re-use. Why re-use requirements? When you structure your requirements for re-use, you gain higher team productivity and less frustration, potentially faster delivery of products, lower development costs, and more consistency in the NPD process.

How do we benefit from requirements re-use? Requirements that can be searched across product lines and assemblies, customer complaints, quality actions, and more with full history of prioritization and risk analysis provide invaluable jump starts for new, related NPD efforts.

Requirements Re-Use Considerations

Re-using requirements is beneficial in the same way as re-using any other type of information, materials, and product design work. Effort goes into the creation and verification of good requirements—don’t throw the work away without considering its value to future NPD efforts. In considering if re-use is possible, you can evaluate the level of re-use, modifications necessary, and analysis of effort involved in re-use given level and modifications.

First, when considering if requirements can be re-used, look at the level of information that is applicable for the next project. Begin with the requirement statement—often much work has gone into creating a good statement: one that is necessary, verifiable, and attainable, answers a need, and is clearly stated. If you have been involved in generating good requirements, or subject to dealing with bad requirements, you appreciate this work and want to re-use when possible.

Next, look at the attributes of the requirement—categorization, reason code, priority, product parts, and lines—to see if these attributes will apply in the re-use scenario. Then, you can evaluate the use cases, customer stories, constraints, test cases, and other associated information to determine applicability for the new requirement. Finally, in some cases, re-use of sets of requirements may be possible—in cases of branch products or assemblies used in multiple lines, for example.

Once you have determined what can be re-used, you need to calculate the modifications necessary to this information. You may find you don’t need to modify the requirement at all, but usually you will need to make some modifications—often to requirement attributes, we have discussed, sometimes to the definition of the requirement itself, or to some of the associated information you will re-use. The modifications you need to make will help determine the level of effort required by your team. ease of requirements reuse Having all requirements in a visible, accessible requirements management tool will accelerate all your re-use efforts—consider past well-constructed requirements as a library of possible requirements for leveraging your future team efforts. A good requirements tool connected to the product record will simplify re-use with easy options, including reference linking, modifications, and history tracking.

Requirements Management Tools

If your company is a part of the new norm of companies with complex products containing software, mechanical, electrical, and/or firmware parts, your choice of a requirements management tool is more critical than for a company with a simpler product. The three components we discussed are found in the best requirements management tools.

1. Connected & Visible	One place for all requirements across impacted teams Support for various requirements attributes/data sets and supporting files Ability to reference and connect to other key product record information such as bill of materials, customer complaints, quality actions, and product projects/tasks Secure, easy access for everyone, including trusted partners
2. Collaborative Requirements Management	Manage prioritization and risks Understand requirement change impact on the entire product team, including operations One central accessible place for visibility, communication, and accountability
3. Re-Use	Connection/links of requirements to products and revisions Clear history of past actions for knowledge sharing

Benefits of Requirements Management Done Well

Forrester found that a significant reason for product delays was “unclear or changing requirements.”³ More and more organizations are becoming Internet of Things (IoT), complex product companies. This intricate world includes product development, testing, compliance, sourcing, regulatory bodies, global markets, and dispersed teams. And, we cannot forget customers demanding their needs are met faster. In this setting, doing requirements management better translates into gains in employee empowerment, faster NPD/NPI cycles, easier iterations, risk reduction, cost reductions, continuous quality improvement, simplified audits, and most importantly—products your customers want.