Business Analysis Notes

Requirements engineering

Requirements Traceability

4 min read · Updated

In short Traceability means recording where each requirement came from and which design elements, code and tests implement and verify it. Kept selectively, these links reveal missing and unnecessary requirements and make change impact analysis fast.

Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed. (Microsoft Press, 2013), ch. 29.

On this page

Key ideas#

Four directions#

Wiegers and Beatty describe tracing in four directions: - Needs → requirements: every customer need is covered. - Requirements → needs: every requirement has a known origin. - Requirements → work products: every requirement is designed, built and tested. - Work products → requirements: every piece of design, code or test exists for a reason, including infrastructure code no user asked for directly.

A full chain runs from business requirements, through user requirements, features and quality attributes, to functional requirements; then to architecture and design, code, and tests at every level. Business rules feed requirements at several levels, and a change request can touch any link. The authors’ central advice: do not maintain every possible link. Pick the few that pay off on your project. A single type, such as “functional requirement → test”, may be enough.

  • Spotting missing requirements (a business requirement with nothing below it).
  • Spotting unnecessary requirements (a functional requirement with no parent).
  • Showing regulators that every mandatory requirement is implemented (not the same as proving it is implemented correctly).
  • Impact analysis when something changes, and finding every place a changed business rule is implemented.
  • Status tracking: a missing link is work not yet done.
  • Reuse of a package of related requirements, design, code and tests.
  • Debugging: a failed test points to the likely code.

The authors warn that outdated link data is worse than none, because it sends people down false trails. Keep a link type only if you can state why.

Non-functional requirements trace differently#

Some quality attributes never become a module. A response-time requirement may drive the choice of hardware, algorithm or architecture; a portability requirement limits which language features developers use. Others, such as integrity, produce ordinary derived functional requirements (passwords, biometric login) that you trace as usual.

Requirements management tools can flag every link attached to a changed item as suspect. Someone reviews each flagged item and clears the flag by hand once it is confirmed or updated. The ripple effect of a change becomes a to-do list.

An economic choice#

Traceability is mandatory in regulated fields such as aviation and medical devices. Elsewhere, a small, stable team may rely on shared memory. Wiegers and Beatty suggest most projects should at least trace business requirements to user requirements. Manual tracing breaks down beyond a couple of hundred requirements, so you need a tool, but the tool cannot create links for you: only people know why a link exists.

How to apply it#

  1. Explain to the team what traceability is for and who is responsible for what.
  2. Choose one or two link types to start with.
  3. Choose a format (one wide matrix or several two-way matrices) and where it lives.
  4. Decide which parts of the product to cover first: the most critical or most volatile.
  5. Assign an owner for each link type, plus a coordinator, often the business analyst (BA). Testers typically own “requirement ↔ test” links; architects or developers own “requirement ↔ design” links.
  6. Build link updates into existing steps, so a link is recorded when a piece of work is finished.
  7. Agree naming conventions so every linked item has an unambiguous identifier.
  8. Collect link data in small increments; never save it for a milestone or the end of the project.
  9. Audit periodically. A requirement marked “implemented and verified” with incomplete links means the tracing process itself has slipped.

Example#

The Workshop, a fictional chain of bike-repair shops, traces its online booking requirements in one wide matrix. The BA copies the approved (baselined) specification, keeps only the IDs, and fills the other columns as work is completed, not as it is planned, so a filled cell proves real work.

User requirement Functional requirement Design element Code Tests
UR-03 Book a repair slot online FR-03.1 Show free slots at the chosen workshop Slot calendar screen booking/slots ST-12, UT-40
UR-03 FR-03.2 Hold a slot for 10 minutes during checkout Slot-hold service booking/hold ST-13
UR-05 Get repair-status updates FR-05.1 Send an SMS when status becomes “Ready” Notification service notify/sms (none yet)

The empty test cell shows that FR-05.1 is built but not yet tested. For one-to-many and many-to-many relationships, a set of two-way matrices works better, for example use cases in columns, functional requirements in rows, and an “x” at each intersection. A requirement marked under two use cases is being reused.

Pitfalls#

  • Tracing everything “just in case” → keep only link types with a stated purpose.
  • Filling cells during planning → fill them when the work is done.
  • Leaving tracing to the end → update links continuously.
  • Nobody owns the links → name an owner for each link type.

Sources and further reading#

  • K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 29.