Derived requirements traceability is a form of requirements management focused on tracing requirements that aren’t explicitly defined in higher-level requirements, but which are necessary for meeting them and for making the overall system work as expected. In derived requirements traceability, teams will document the dependencies and logical links between these lower-level requirements and other system elements.
Derived Requirements, Explained
For example, let’s say a hypothetical automotive system has a higher-level requirement stating that it must be capable of traveling at very high speeds. A derived requirement in this case might say that the system also needs to be lightweight. While this requirement is not defined by the project stakeholders, satisfying it is essential to the engineering process of the entire system. If the end result is not light enough, the original requirement for fast travel won’t be met, either.
Another way to look at it: Derived requirements are decomposed from other requirements, including business and stakeholder requirements. Adequately tracing them serves several general purposes:
- It facilitates impact analysis, by helping identify all the work products that might need modification before implementing a proposed change.
- It follows the life of a requirement, both forward and backward in relation to customer needs, and from origin through implementation.
- It creates a roadmap, showing at which points each requirement or business rule was implemented.
- It simplifies the packaging up of requirements baselines, which are snapshots of approved requirements assigned to product releases at points in time.
- It helps meet certain medical regulatory requirements, such as the design controls under FDA CFR 21 820.30 for aligning device design inputs and outputs.
In practice, proper derived requirements traceability will involve cataloging all of the connections between derived requirements and other types of requirements, plus business rules, architecture and design components, source code modules, test cases, help files, and documentation. This process ensures that the product in question is ultimately maintainable, compliant, and tightly aligned with customer expectations.
Enabling Traceability as Part of Requirements Management
For sufficient derived requirements traceability, each requirement must have a unique and persistent label that allows for unambiguous tracking throughout the project. A centralized, modern requirements management solution is preferable to numerous discrete requirements documents for this purpose.
Not only does such a management tool provide one convenient place for collecting feedback and collaborating in real time on reviews and approvals, but it also supports live traceability of upstream and downstream relationships, with clear visibility into the impact of changes on all levels of requirements as well as test coverage. Accordingly, project teams can set up four distinct types of traceability links for their derived requirements.
The Four Types of Derived Requirements Traceability
1. Forward to Requirements
When customer needs evolve, requirements may have to be adjusted in response. By making these adjustments, project teams can keep pace with changes in customers priorities, introductions of new business rules, and modifications of existing rules, among other events.
2. Backward From Requirements
Tracking backward from requirements can provide clarity into the origin of each derived requirement. For instance, a requirements management tool could show the link between the derived requirement, the requirement it came from, and the customer use case being addressed.
3. Forward From Requirements
Once derived requirements begin flowing into downstream deliverables during product development, it’s possible to draw trace relationships between requirements and their corresponding elements. This type of link provides assurance that every requirement is satisfied by a particular component.
4. Backward to Requirements
Finally, this type of link allows for visibility into why certain features were created. Consider how most applications include lines of code that don’t directly relate to stakeholder requirements. Even so, it is important to know why a software engineer wrote that code in the first place.
While a full accounting of all four types is beyond the scope of this piece, let’s look at a more in-depth example of the fourth type. Suppose a tester discovers unexpected functionality with no corresponding requirement. It could indicate two divergent possibilities:
- The underlying code might have been implemented to meet a legitimate implied (derived) requirement, which could then be added to the requirements specification.
- Alternatively, it might simply be orphan code that no longer belongs in the current product.
Traceability links create clarity in such situations, shining a light on how the different pieces of a system all fit together. Conversely, test cases derived from – and traced back to – individual requirements offer a mechanism for detecting unimplemented requirements, because the tester won’t find the expected functionality.
There are many types of traceability relationships possible within a project, and not all of them will be needed on every project. However, there are good motivations for implementing derived requirements traceability, via a best-in-breed solution with flexibility that can be leveraged as needed for a given project.
The Main Motivations for Derived Requirements Traceability
At a high level, traceability contributes to a more efficient product lifecycle and superior project management. More specific reasons for implementing it include:
Certification
Traceability data can support certification of safety-critical products, by demonstrating that all requirements were implemented.
Impact analysis
By tracing derived requirements, it’s less likely that something will be overlooked when determining the effects of changes to requirements.
Maintenance
Clear traceability simplifies maintenance, as changes (e.g., in response to updates to government regulations or corporate policies) can be performed with more confidence. A modern requirements management tool makes it easier to show where each applicable rule was addressed in requirements.
Project tracking
Traceability information offers an accurate record of the implementation status of planned functionality, with missing links indicating work products not yet created.
Reengineering
List functions in a legacy system set for replacement and use traceability data to record where they were addressed in the new system’s requirements and software components.
Reuse
With derived requirements traceability in place, it’s more practical to reuse product components by identifying packages of related requirements, designs, code, and tests.
Risk reduction
Documenting component interconnections reduces risk in the event that a key team member with essential knowledge about the system departs the project.
Testing
The links between requirements, tests, and code help indicate the likely locations of bugs when a test yields an unexpected result. Also, knowing which tests verify which requirements will save time by allowing for the elimination of redundant tests.
The second article in this series discusses the requirements traceability matrix, and the final part proposes a procedure for making requirements traceability work on your projects.