Requirements & Traceability

Link every requirement to the test cases that verify it and their latest results — so you can prove coverage, find gaps, and see the blast radius of a change.

The traceability matrix

The traceability matrix connects three layers: requirements → test cases → run results. It answers two questions at once:

• Forward: for a given requirement, which test cases verify it, and are they passing?
• Backward: for a given test case, which requirement does it exist to protect?

That mapping makes coverage auditable and turns "did we test this?" into a lookup rather than a debate.

Where requirements come from

VigilQA builds the requirement layer from what you already have:

• Knowledge Base scenarios — every KB scenario is a requirement by default, identified by its id.
• Imported requirement documents — a Word, PDF, or Markdown spec run through Extract from Document becomes structured requirements with stable IDs.
• External requirement IDs — tag a scenario with a ticket or requirement reference (e.g. req: JIRA-1420) and the matrix groups tests under it.

How tests map to requirements

Generated test functions are named test_<scenario_id>_*, so the link from a requirement to its tests is automatic. For hand-written tests, add a docstring tag and they are picked up too:

def test_checkout_rejects_expired_card():
    """
    @requirement: REQ-CHECKOUT-014
    Verifies an expired card is declined at checkout.
    """
    ...

Reading the matrix

Requirement	Test cases	Status	Coverage
REQ-CHECKOUT-014 · Expired card declined	3	3 pass	Covered
REQ-CHECKOUT-015 · Refund to original method	2	1 pass · 1 fail	At risk
REQ-CHECKOUT-016 · Partial refund	0	—	Uncovered

The matrix highlights two problems teams usually miss:

• Uncovered requirements — a requirement with no test cases (surfaced together with CoverageGap, which can generate the missing tests).
• Orphan tests — a test case not tied to any requirement, which usually means either a missing requirement or dead test code.

Change impact

Because the mapping is bidirectional, editing a requirement immediately shows which tests need to be re-run, and a failing test points back to the exact requirement at risk. This feeds Release Readiness: requirement coverage is one of its gate signals.