SpiraTest Requirements Traceability: Linking Tests to Requirements

Requirements traceability answers two critical questions: "Which requirements are tested?" and "Which tests cover this requirement?" Without it, you're guessing at coverage. With it, you can prove to stakeholders, auditors, or regulators exactly what's been verified — and what hasn't.

SpiraTest's traceability system links requirements, test cases, test executions, and defects into a connected graph. This guide explains how to build and use that graph effectively.

Why Requirements Traceability Matters

For development teams: Know which tests to run when a requirement changes. If Requirement R-47 changes, the traceability matrix immediately shows which test cases cover R-47 — run those.

For QA teams: Identify coverage gaps before a release. If a requirement has no linked tests, it's going out untested.

For regulated industries: Compliance frameworks (FDA, ISO 9001, DO-178C, IEC 62443) require documented evidence that each requirement was tested and passed.

For product teams: Release confidence. A coverage report showing 95% of requirements with passing tests is a real answer to "are we ready to ship?"

The Traceability Model in SpiraTest

SpiraTest traces relationships between these entities:

Requirements
    ↕
Test Cases
    ↕
Test Runs (Executions)
    ↕
Incidents (Defects)

Each arrow is a bi-directional association. From a requirement, you can see all tests that verify it, all executions of those tests, and all defects found during those executions. From a defect, you can trace back to the test step that found it, the test case it belongs to, and the requirement it covers.

Setting Up Requirements

Requirements in SpiraTest form a hierarchical tree. Good structure here makes traceability more useful.

Recommended Structure

Feature: User Authentication (REQ-1)
├── User Story: Login with email (REQ-2)
├── User Story: Login with OAuth (REQ-3)
├── User Story: Password reset flow (REQ-4)
└── User Story: Session timeout (REQ-5)

Feature: Shopping Cart (REQ-6)
├── User Story: Add items to cart (REQ-7)
├── User Story: Update quantities (REQ-8)
└── User Story: Remove items (REQ-9)

Parent requirements inherit coverage from child requirements. If REQ-2, REQ-3, REQ-4, and REQ-5 all have passing tests, REQ-1 shows as fully covered.

Requirement Importance Levels

Set importance (priority) on requirements:

• Critical — must be covered before any release
• High — should be covered
• Medium — cover if time permits
• Low — nice to have

Importance levels appear in coverage reports, letting you filter to see critical requirement coverage separately.

Linking Test Cases to Requirements

From the Test Case Editor

1. Open any test case
2. Click the Requirements tab
3. Click Add Association
4. Search and select requirements this test covers

You can link one test case to multiple requirements. A login test might cover REQ-2 (email login) and partially verify REQ-1 (the parent feature).

From the Requirements Editor

1. Open any requirement
2. Click the Test Cases tab
3. Click Add Association
4. Select test cases that verify this requirement

Both directions create the same link — use whichever is more convenient.

Bulk Association via Excel Import

For existing test case libraries, use the SpiraTest Excel importer to bulk-create associations:

1. Export your requirements to a spreadsheet with their IDs
2. Export your test cases with their IDs
3. Create a mapping sheet: TestCaseID | RequirementID
4. Import via Data Tools → Import → Test Case Requirement Associations

This is much faster than manually linking hundreds of test cases.

Understanding the Requirements Coverage Report

The main traceability view is the Requirements Coverage report.

Navigate to Reports → Requirements Coverage (or check the requirements list — each row shows a coverage indicator).

The report shows for each requirement:

• Coverage Status: Covered, Not Covered, or Partially Covered
• Test Cases: Number of linked test cases
• Last Execution: When tests were last run
• Execution Status: Passed, Failed, Blocked, Not Run

Coverage Status Definitions

"Not Covered" requirements are your biggest risk — they're going to production completely untested.

Filtering the Coverage Report

Filter by:

• Release — show coverage for a specific release
• Importance — focus on critical requirements
• Test Set — show coverage from a specific test execution campaign
• Component — show coverage for a specific system component

A common pre-release filter: Importance = Critical OR High, Release = 2.4. This shows your most important requirements and whether they're tested for the upcoming release.

Building a Traceability Matrix

The Traceability Matrix is a grid showing requirements vs. test cases, with execution status in each cell.

In SpiraTest: Reports → Traceability Matrix

The matrix shows:

• Rows: requirements (filtered by release, component, etc.)
• Columns: test cases
• Cells: ✅ Passed, ❌ Failed, ⏳ Not Run, blank (not linked)

For regulated environments, export this matrix to PDF for audit documentation:

1. Configure filters to show the relevant scope
2. Click Export to PDF
3. Include in your quality records

Tracking Coverage for a Release

A common workflow before a release:

1. Create a Release in SpiraTest

1. Navigate to Releases
2. Click Insert Release
3. Set name (e.g., "v2.4"), start date, end date, version number

2. Associate Requirements with the Release

For each requirement included in this release:

1. Open the requirement
2. Set the Release field to your target release

3. Create a Test Set for the Release

1. Navigate to Test Sets
2. Create "v2.4 Release Testing"
3. Add test cases that cover the requirements for this release

4. Run the Test Set

Execute the test set with your QA team. As tests pass and fail, the release coverage updates in real time.

5. Review Coverage Before Release

Before sign-off:

1. Open the Requirements Coverage report
2. Filter by Release = "v2.4"
3. Filter by Importance = "Critical" or "High"
4. Any "Not Covered" or "Failed" requirements are release blockers

This gives you a clear, defensible answer about release readiness.

Defect Traceability

When a tester marks a test step as failed and logs a defect, SpiraTest automatically links:

• The defect → the test step → the test case → the requirement

This creates full downward traceability from requirement to defect.

Using Defect Traceability

Impact analysis for bug fixes: "Which requirements are affected by this defect?" Open the defect, navigate to linked test cases, then linked requirements.

Regression test selection: When a defect is fixed, look at the linked test cases. Those are the minimum tests to run to verify the fix.

Requirement risk assessment: A requirement with 5 linked defects has more risk than one with 0. The Requirements report can show defect count per requirement.

Traceability for Automated Tests

Automated tests integrate with SpiraTest via APIs or plugins. For automated test results to contribute to traceability, they must be linked to test cases that are linked to requirements.

Linking Automated Tests to Test Cases

1. Create the test case in SpiraTest manually
2. In the test case, set Automation Host and link to the automation engine
3. Link the test case to requirements as normal
4. When automated tests run, they report results back to the SpiraTest test case

The requirement coverage then reflects automated test results in addition to manual execution.

SpiraTest Automation Integrations

SpiraTest has native integrations with:

• Selenium WebDriver (Java, .NET, Python)
• JUnit and NUnit
• pytest
• Jenkins and GitHub Actions
• Visual Studio / MSTest
• Postman (API testing)

Each integration maps automated test results to specific test cases in SpiraTest, feeding the traceability chain.

Advanced Traceability: Risk-Based Testing

For risk-based testing approaches, combine requirement importance and coverage data:

1. Set Importance = Critical on your highest-risk requirements
2. Filter coverage report by importance
3. Prioritize test execution to ensure critical requirements are covered first
4. Use the test set scheduling to ensure critical tests run early in each cycle

The coverage report shows critical requirements at risk before you run out of testing time.

Compliance and Audit Support

For regulated industries, SpiraTest's traceability provides audit evidence:

• FDA 21 CFR Part 11 — electronic records with traceability from requirements to test results
• ISO 9001 — documented test coverage evidence
• DO-178C — safety-critical software test evidence
• IEC 62443 — industrial cybersecurity test requirements

Export the traceability matrix and coverage reports in PDF for your quality records. SpiraTest timestamps all actions with user attribution — who created what, when, and with what result.

Summary

Requirements traceability in SpiraTest pays off when:

• You can instantly answer "is Requirement X tested?"
• Release readiness reports are generated automatically, not assembled manually
• Defects trace back to requirements, making impact analysis fast
• Compliance audits can be answered with exported reports, not manual spreadsheet work

Start small: link your critical requirements to test cases in your current sprint. As the practice becomes habitual, coverage gaps become visible and actionable.

Continuous Testing Beyond Test Management

SpiraTest tracks what your team has planned and executed. For knowing whether your production app is working right now, you need continuous monitoring.

HelpMeTest runs tests against your production app every 5 minutes, 24/7. Write tests in plain English. Get alerted instantly when something breaks — no test framework required.

Start monitoring free →