/
← L2: Technical Documentation Generation Lab 1: Create flowcharts/Mermaid diagrams →
Module 8 — AI-Driven Documentation & Visualization

L3: BRD to Requirement Traceability

L3: BRD to Requirement Traceability

BRD to Requirement Traceability

In the previous lessons, we used Claude to generate diagrams and technical documentation from existing code. However, enterprise architecture starts long before the code is written—it begins with the Business Requirements Document (BRD). The historical failure point in the Software Development Life Cycle (SDLC) is the translation of business intent into technical implementation.

This lesson covers how AI Architects use Claude to enforce Requirement Traceability , ensuring every line of code and every unit test maps directly back to a specific business mandate.

1. The Traceability Gap in Traditional SDLC

In a standard enterprise, Product Managers write a 30-page BRD in plain English. Engineers read it, interpret it, and write Jira tickets. Months later, QA writes test cases.

The Architectural Vulnerability: During this manual game of telephone, three things happen:

  • Scope Creep: Developers build features not requested in the BRD.

  • Dropped Requirements: Edge cases mentioned on page 14 of the BRD are forgotten and never coded.

  • Tautological Testing: QA tests the code as it was written, not as the business requested.

The Agentic Solution: By ingesting the BRD directly into Claude, the model acts as an impartial, mathematical bridge between Business (Text), Engineering (Code), and Quality (Tests).

2. Agentic BRD Parsing (The Extraction Phase)

An LLM cannot enforce traceability if the requirements are buried in conversational paragraphs. The first architectural step is using Claude to extract and structure the BRD.

The Extraction Prompt:

You pass the raw BRD to Claude with strict constraints:

"Read the attached BRD. Extract every actionable requirement into a structured JSON array. Assign a unique ID to each requirement (e.g.,REQ-AUTH-001). For each, identify the Actor, the Action, and the Acceptance Criteria. Do not hallucinate technical solutions; only extract the business intent."

Architectural Advantage: You have now transformed an unstructured Word document into a deterministic JSON schema that programmatic pipelines and downstream agents can consume.

3. Generating the Requirements Traceability Matrix (RTM)

The Requirements Traceability Matrix (RTM) is an artifact that proves every requirement has been designed, built, and tested. Traditionally, this is a massive Excel spreadsheet that no one wants to update.

Architects use Claude to automate the RTM.

  • The Workflow: Whenever a new feature is merged, the CI/CD pipeline triggers an Auditor Agent.

  • The Task: The agent reads the extracted REQ IDs, scans the GitHub commit messages, scans the Jira ticket IDs, and scans the generated unit test names.

  • The Output: Claude generates a Markdown table linking [BRD Requirement] -> [Jira Epic] -> [PR/Commit] -> [Test Name]. If a row in the matrix is missing a test, the agent flags the build as non-compliant.

4. Forward Traceability: BRD to Jira to Code

Once requirements are extracted and the RTM structure is established, you orchestrate Forward Traceability (ensuring the business intent drives the code).

  • Jira Ticket Generation: You chain the JSON output from the Extraction Phase into a Jira Agent. "For everyREQ ID in this JSON, generate a Jira User Story. Format the description in standard BDD (Behavior-Driven Development) format: Given / When / Then."

  • Code Generation Guardrails: When instructing Claude Code to build the feature, you do not just say "build the login page." You prompt: "ImplementREQ-AUTH-001 and REQ-AUTH-002. Add a docstring to the top of the generated controller explicitly linking back to these requirement IDs."

5. Backward Traceability: The Scope Creep Defense

Backward traceability is the process of looking at the physical codebase and proving that the code belongs there.

LLMs are eager to please and will often generate "bonus" features (e.g., adding an unauthorized "Export to CSV" button to a table just because it saw that pattern in its training data).

The Architectural Defense:

During the Pull Request review phase, the Reviewer Agent is given both the PR diff and the extracted BRD JSON.

  • The Prompt: "Review this code. Trace every function and API endpoint back to a specificREQ ID in the provided BRD. If you find code that cannot be mathematically traced back to a business requirement, flag it as 'Unauthorized Scope Creep' and request its removal."

By sandwiching the SDLC between Forward Traceability (Agent-generated tickets) and Backward Traceability (Agent-audited PRs), the AI Architect guarantees that the final application is a mathematically perfect reflection of the business intent.