- 1. Writing Requirements
- 1 What is Requirements Management?
- 2 Non-functional requirements examples and templates
- 3 Product requirements document template and examples
- 4 How to write system requirement specification (SRS) documents
- 5 How to Write an Effective Product Requirements Document
- 6 Functional vs. Non-functional requirements
- 7 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 8 8 Do’s and Don’ts for Writing Requirements
- 2. Requirements Gathering and Management Processes
- 3. Requirements Traceability
- 4. Requirements Management Tools and Software
- 5. Requirements Validation and Verification
- 6. Meeting Regulatory Compliance and Industry Standards
- 7. Project Management
- 8. Measuring Requirements
- 9. Conquering Key Requirements Management Challenges
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