The Essential Guide to Requirements Management and Traceability
- 1. Requirements Management
- 1 What is Requirements Management?
- 2 Why do you need Requirements Management?
- 3 Four Fundamentals of Requirements Management
- 4 Adopting an Agile Approach to Requirements Management
- 5 Conquering the 5 Biggest Challenges of Requirements Management
- 6 Three Reasons You Need a Requirements Management Solution
- 2. Writing Requirements
- 1 Functional requirements examples and templates
- 2 Product requirements document template and examples
- 3 How to write system requirement specification (SRS) documents
- 4 Adopting the EARS Notation to Improve Requirements Engineering
- 5 Jama Connect Advisor™
- 6 Frequently Asked Questions about the EARS Notation and Jama Connect Requirements Advisor
- 7 How to Write an Effective Product Requirements Document
- 8 Functional vs. Non-Functional Requirements
- 9 What Are Non-Functional Requirements and How Do They Impact Product Development?
- 10 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 11 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- 4. Requirements Traceability
- 1 What is Traceability?
- 2 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 3 How to Create and Use a Requirements Traceability Matrix
- 4 Live Traceability vs. After-the-Fact Traceability
- 5 How to Overcome Organizational Barriers to Live Requirements Traceability
- 6 Requirements Traceability, What Are You Missing?
- 7 Four Best Practices for Requirements Traceability
- 8 Requirements Traceability: Links in the Chain
- 9 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- 1 Understanding ISO Standards
- 2 What is ISO 13485? Your Comprehensive Guide to Compliant Medical Device Manufacturing
- 3 A Guide to Automotive Safety Integrity Levels (ASIL)
- 4 Compliance Management
- 5 What is FMEA? Failure Modes and Effects Analysis
- 6 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 8. Project Management
- 9. Measuring Requirements
- 10. Systems Engineering
Requirements Traceability – What are you missing?
For systems engineers, business analysts, and product owners, requirements traceability (the ability to trace requirements to downstream development, test, verification, validation, and risk activities) is an unquestioned good and an unquestioned need. Traceability is required to demonstrate compliance to relevant standards in industries such as medical device, automotive, semiconductor, aerospace, and financial services. In addition to compliance requirements, traceability is quite helpful to assess the impact of change required on all relevant requirements and related downstream activities. But the largest potential value is missed by many organizations.
After-the fact use cases
The two main use cases for traceability noted above are both reactive to requests: the need to demonstrate standards compliance to third parties and the need to analyze the impact of a change request. Both use cases view requirements as static and passive. Requirements are documented and links created to downstream artifacts in software, hardware, and electrical development test and risk assessment — which are stored in a system. The system then waits until a request comes in from outside to document that a process has been followed or to identify which elements are impacted by a change. Both use cases reflect an after-the-fact mindset that limits the value that can be achieved from the effort put into establishing traceability.
Analogies to other business-critical functions
To view something we think we know well in a new light, it is often helpful to place it in a different context and look at it from a fresh perspective. So, let’s give it a try and compare traceability in the product development process to traceability in the new customer acquisition process.
For engineers, these processes may at first appear to be too disparate for an apt analogy, but at a fundamental level, they are quite similar. Both start with a documented value (requirement vs. opportunity) that must transition through multiple phases and involve many other functions to reach the desired outcome (release vs. win) — and all sorts of things can go wrong along the way leading to delays, costs incurred, and failure.
The aspect I want to focus on is how these two processes are managed. In the sales process, the element of value (the opportunity) is living — actively measured, analyzed, and tracked for exceptions on a daily basis. The key process metrics are defined with ranges for acceptable performance. Current process performance is automatically calculated based on the movement through stages of all opportunities. Alerts are raised for opportunities stuck in a process stage too long (relative to average dwell times) and predictions are made about future period performance based on the opportunities in the system.
In contrast, for most product development organizations, requirement traceability is static and in after-the-fact analysis and not living — in the way opportunities are traced in sales as described above. To make requirement traceability living (like a sales opportunity) traceability would require software-enabled best practices in the following areas:
- Process metrics must be defined
- Actual performance against process metrics must be captured
- Once standard metric performance is defined, current performance must be compared to the standard
- Exceptions need to be defined
- Alerts need to be set up to notify when exceptions occur
- Learnings need to be incorporated into process improvement
Once these steps are taken to improve requirements traceability, then requirements become living, not static, and performance improvement is possible: the risk of negative product outcomes is reduced, and process performance is improved; the product development process can then be data-driven, measured, and managed like all other business-critical processes. Without measurement, there is no way to benchmark performance against other organizations. There is no way to learn, no way to know, and no way to improve.
Better to stay in the dark?
There may be some that would prefer to keep the product development process shrouded in mystery and avoid data-driven analysis, measurement, and process performance improvement. There used to be chief revenue officers (CROs) that felt the same way. It is extremely hard to find any current CROs with that mindset. Those that can lead through data and drive performance improvements gain the support of leadership and elevate their careers. The same opportunity is now on the table for product leadership to turn requirements traceability into living requirements in order to reduce the risk of negative product outcomes and improve the performance of the end-to-end product development process.
In This Webinar, Learn More About the High Cost of Poor Requirements Management
Traceability: Relationships between items to show evidence of requirement decomposition and verification coverage.
RELATED ARTICLE: Better Product Development: Five Tips for Traceability
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started by filling out this form so we can connect!