Learn how to turn software requirements into testable verification objectives and maintain evidence linking those requirements to the tests used to verify them.
This four-hour module develops practical capability in requirements-based testing and traceability, beginning with requirement quality and test derivation before progressing into forward, backward and bidirectional traceability.
Participants assess requirements for testability, derive positive, negative, edge-case and non-functional tests, use Given/When/Then structures, and build a traceability matrix that supports change-impact analysis and regression-scope estimation.
The module concludes with an End-to-End Traceability Dossier combining requirements-derived tests, bidirectional traceability and documented change-impact analysis.
View the Full Software Testing & Verification Programme
What You Will Learn
Module 5 connects software requirements directly to verification activity.
Participants learn how to assess whether requirements are sufficiently clear and testable, how to derive meaningful tests from functional and non-functional requirements, and how to maintain traceability between requirements, tests and results.
The module also develops practical skills in identifying gaps such as orphan requirements or orphan tests and using traceability information to understand the effect of requirement changes.
Topics
- Requirement quality attributes and the SMART checklist
- Deriving tests from functional and non-functional requirements
- Test oracles and the test oracle problem
- Given/When/Then behaviour-driven requirement format
- Requirements decomposition and MoSCoW prioritisation
- Traceability matrix structure: requirement ID, test ID, result, status
- Forward, backward and bidirectional traceability
- Orphan requirements and orphan tests
- Change impact analysis and regression scope estimation
- Traceability tooling: spreadsheet-based and lightweight open-source options
Lab 1: Deriving Tests from a Requirements Set
Learning Objectives: Requirement quality, SMART, test derivation, test oracles, BDD
Description: Review a sample requirements set for testability and derive a documented test case set from it.
Tasks
- Assess three sample requirements against the SMART checklist.
- Rewrite one ambiguous requirement to make it testable.
- Derive positive, negative and edge-case tests for one functional requirement.
- Derive a test for one non-functional (performance) requirement.
- Convert one requirement into Given/When/Then format and write its test.
- Document each test using a Test ID / requirement reference / steps / expected result structure.
Extension Tasks
- Decompose one compound requirement into two testable sub-requirements.
- Prioritise the requirements set using MoSCoW.
Topics Covered
Requirement Quality, Test Derivation, Test Oracles, BDD Format
Open Source Recommendation
No specific tool is required; requirement and test documentation can be captured in an open-source tool such as Robot Framework’s requirement-linked test structure.
Lab 2: Building a Bidirectional Traceability Matrix
Learning Objectives: Traceability matrix, forward/backward traceability, change impact analysis
Description: Build a complete traceability matrix linking Lab 1’s requirements to their derived tests, then analyse a requirement change.
Tasks
- Build a traceability matrix with requirement ID, test ID and status columns.
- Verify forward traceability: every requirement maps to at least one test.
- Verify backward traceability: no test exists without a linked requirement.
- Identify and resolve one deliberately introduced orphan test.
- Apply a sample requirement change and identify affected tests via the matrix.
- Estimate the regression test scope resulting from the change.
Extension Tasks
- Add a version column to track the matrix across two releases.
- Draft a short traceability status summary for a stakeholder audience.
Topics Covered
Traceability Matrix, Forward/Backward Traceability, Change Impact Analysis
Open Source Recommendation
A spreadsheet-based matrix (e.g. LibreOffice Calc) or an open-source ReqIF-based tool such as OpenCert for a lightweight traceability implementation.
Module 5 Coverage Matrix
| Topic | Lab 1 | Lab 2 |
|---|---|---|
| Requirement Quality | ✓ | |
| Test Derivation Techniques | ✓ | |
| Traceability Matrix Structure | ✓ | |
| Forward/Backward Traceability | ✓ | |
| Change Impact Analysis | ✓ |
Module Project: End-to-End Traceability Dossier
End-to-end traceability dossier: derive a full test case set from a sample specification and build a bidirectional traceability matrix with a documented change-impact analysis.
The project brings together requirement assessment, test derivation, traceability and change management into one verification deliverable.
Participants create an evidence chain that links:
Requirement → Derived Test → Test Result/Status → Traceability Evidence → Change-Impact Analysis
This provides a structured basis for understanding not only whether a requirement has been tested, but also which verification activities are affected when that requirement changes.
From Code Coverage to Requirements Evidence
Module 4 focuses on structural evidence showing what parts of the implementation have been exercised.
Module 5 adds another perspective: whether verification activity can be traced back to defined requirements.
The progression therefore becomes:
Structural Coverage & MC/DC
↓
Requirement Quality
↓
Requirements-Derived Tests
↓
Bidirectional Traceability
↓
Change-Impact Analysis
This distinction should remain clear on the page so Module 4 and Module 5 do not compete for the same search intent.
Requirements-Based Test Design
Effective requirements-based testing begins before a test is executed.
Participants first consider whether a requirement is clear enough to verify and whether an appropriate oracle exists for determining the expected result.
The module then moves from requirement analysis into test creation through:
- Positive testing
- Negative testing
- Edge-case testing
- Non-functional testing
- Given/When/Then behaviour-driven structures
This connects specification intent with concrete verification activity.
Building Bidirectional Traceability
Traceability is treated as an active verification mechanism rather than merely a documentation exercise.
Participants examine:
Forward traceability
Does every requirement map to at least one test?
Backward traceability
Can every test be linked to a requirement?
When both directions are maintained, the matrix supports bidirectional traceability and helps expose gaps such as:
- Requirements without tests
- Tests without an identifiable requirement
- Obsolete test cases
- Verification affected by requirement changes
Change-Impact Analysis and Regression Scope
A traceability matrix becomes particularly useful when a requirement changes.
Rather than selecting regression tests without evidence, participants use the traceability relationship to identify which tests are affected and estimate the appropriate regression scope.
This capability becomes increasingly important as the programme moves into larger integration, embedded, safety-critical and CI/CD contexts.
How Module 5 Connects With Later Modules
The artifacts developed here become relevant throughout the remaining programme.
Module 6: Integration & Protocol-Level Testing
Requirements-derived verification thinking can be extended from individual functionality into interfaces, protocols, middleware and data systems.
Module 10: Automotive/ADAS Safety-Critical Testing
Safety-oriented testing relies on connecting technical verification evidence to defined safety and functional expectations.
Module 12: Cross-Industry Standards Bridge & Capstone
That makes Module 5 a genuine part of the programme’s verification-evidence chain rather than an isolated requirements lesson.
Frequently Asked Questions
What is requirements-based testing?
In this module, requirements-based testing means assessing requirements for testability and deriving documented tests from functional and non-functional requirements.
What requirement-quality techniques are covered?
The module includes requirement quality attributes and the SMART checklist, as well as requirement decomposition and MoSCoW prioritisation.
What is a traceability matrix?
The curriculum uses a matrix containing requirement ID, test ID, result and status information to connect requirements with their associated tests.
What is forward traceability?
Forward traceability checks that every requirement maps to at least one test.
What is backward traceability?
Backward traceability checks that tests can be linked back to defined requirements rather than existing without a requirement relationship.
Does the module cover bidirectional traceability?
Yes. Participants build a complete traceability matrix and verify both forward and backward relationships.
Are orphan requirements and tests covered?
Yes. Orphan requirements and orphan tests are included in the curriculum, and the practical lab asks participants to identify and resolve a deliberately introduced orphan test.
Does the module cover requirement changes?
Yes. Participants apply a sample requirement change, identify affected tests through the traceability matrix and estimate the resulting regression-test scope.
Is BDD covered?
The module includes Given/When/Then behaviour-driven requirement format and asks participants to convert a requirement into that format and write its corresponding test.
What is the Module 5 project?
The project is an End-to-End Traceability Dossier containing a derived test case set, a bidirectional traceability matrix and documented change-impact analysis.
