BRDs are dying. Here's what replaces them.

I once watched a product team spend three weeks writing a 47-page BRD for a feature that took two sprints to build. The document had a revision history, a sign-off matrix, an appendix with wireframes, and a glossary that defined the word "user." Six people approved it.

Nobody opened it again after the kickoff meeting.

The developers worked from the Jira tickets. The testers worked from the Jira tickets and their own interpretation of the UI. The BRD sat in SharePoint, a monument to process, untouched by the people actually building the software.

This is not unusual. This is normal.

The disconnection problem

BRDs aren't bad documents. The format — capturing what the business needs, why it needs it, and what success looks like — is genuinely useful. The problem is that BRDs exist in isolation.

Requirements live in a Word document or Confluence page. Test cases live in a spreadsheet or test management tool. Development tasks live in Jira or Linear. These three systems don't talk to each other. They reference each other informally, with phrases like "See BRD section 4.2" that nobody will ever follow.

This means there's no way to answer basic questions: Which requirements have test coverage? Which test cases don't trace back to any requirement? If requirement 3.1.4 changes, which test cases need to be updated?

These aren't theoretical concerns. I've sat in audit meetings where a team spent three days manually building a traceability matrix — mapping requirements to test cases in a spreadsheet — because nobody had maintained that mapping during development. Three days of a senior QA engineer's time, just to prove to an auditor that yes, we tested what we said we'd test.

What waterfall got right (and wrong)

Waterfall had one thing going for it: the process assumed that requirements were stable. You wrote them once, everyone agreed, and then you built to spec. In that world, a BRD made sense. It was the source of truth, and it didn't change.

Agile killed that assumption, but it didn't replace the BRD with anything equally rigorous. User stories are great for capturing intent — "As a user, I want to reset my password so that I can regain access to my account" — but they often lack the specificity that testers and developers need. Acceptance criteria help, but they're frequently written as afterthoughts: "Password reset should work." We're back to the same problem.

Living requirements

What's replacing the BRD isn't a different document format. It's a different relationship between requirements and everything downstream.

A living requirement is one that stays connected to its test cases, its development tasks, and its verification status throughout the project. When the requirement changes, the connected test cases are flagged for review. When a test case fails, you can see which requirement is at risk. When someone asks "is this feature done?" you can answer with data, not opinions.

This doesn't require a specific tool, but it does require a specific habit: treating requirements as the backbone of your test strategy, not as a document you file and forget.

Some teams do this with well-maintained Jira epics and linked test cases. Some use tools like Notion with relational databases. Some use dedicated requirements management platforms. The mechanism matters less than the principle: requirements and tests must be linked, and those links must be maintained.

Bridging the gap with automation

Here's where things get interesting. A well-written requirement contains most of the information you need to write test cases. "The system shall allow users to reset their password via email. The reset link expires after 60 minutes. Users cannot reuse their last 5 passwords." From that single requirement, you can derive at least six test cases: happy path reset, expired link, reuse of last password, reuse of 6th-oldest password, invalid email, and reset while already logged in.

Parsing requirements and extracting testable conditions is exactly the kind of work that automation handles well. Not because AI is magic, but because the pattern is consistent: requirement in, conditions out, test cases structured around those conditions. A human still needs to review the output, add context, and prioritize. But the extraction itself? That's mechanical work that shouldn't take a senior QA engineer four hours per feature.

This is the direction the industry is moving: not away from requirements, but toward requirements that do more. Requirements that don't just describe what to build, but that generate the scaffolding for how to verify it was built correctly.

The BRD isn't dead — it's evolving

If your team still writes BRDs, I'm not going to tell you to stop. A well-written BRD is more useful than a pile of vague user stories. But I am going to suggest that the BRD shouldn't be the end of the requirements process. It should be the beginning.

Take that BRD, extract the testable requirements, link them to test cases, and maintain those links as the project evolves. Whether you do that manually or with tooling, the result is the same: requirements that matter beyond the approval meeting.

The 47-page BRD that nobody reads is dying. Good riddance. What replaces it is smaller, connected, and alive.