How to Write a Business Requirements Document for Projects That Include AI Features

The twelve sections every modern BRD needs, plus the new AI Features section that 2026 projects cannot ship without.

46% of code written by GitHub Copilot users is now AI-generated. Cursor reached $1B in annual revenue in 2025. Anthropic's Claude Code, Cognition's Devin, and a growing class of agentic coding tools are reading specifications and writing production code from them.

The shift changes what a Business Requirements Document needs to contain. A BRD that was complete in 2023 is now missing a section.

This article walks the twelve sections of a 2026-ready BRD, what the new AI Features section must specify, and the failure modes that catch teams who skip it.

What a BRD Is and Why It Still Matters in 2026

A Business Requirements Document captures what a business needs a solution to do, in language that stakeholders can validate and developers can build from. It sits between discovery (which defines whether to build at all) and design (which defines how to build it).

The 2026 conversation about whether BRDs are obsolete in an AI-coding world has the wrong premise. AI coding agents do not eliminate the need for specifications. They sharpen it. Vague prompts produce vague code. A BA-discipline BRD is the structured prompt the entire delivery team works from, whether the team is humans, agents, or both.

The Twelve Sections of a 2026 BRD

Every credible 2026 BRD covers twelve sections. Eleven are traditional. One is new.

‍

The traditional sections still carry their original weight. Stakeholders, scope, functional and non-functional requirements, constraints, assumptions, dependencies, acceptance criteria, traceability, and sign-off are the analytical scaffolding that prevents 80% of software failures, which still trace back to requirements issues.

What changes in 2026 is what counts as a complete requirements set when the build includes an AI component. Section 7 is the addition.

## [H2]

The New AI Features Section: Six Components a BRD Must Specify

When a project includes an AI feature (a chatbot, a recommendation engine, a document classifier, an agentic workflow, anything that produces output a deterministic system cannot), the BRD needs a dedicated section that specifies six components.

‍

Model Selection Criteria, Not Model Names

A BRD does not name the vendor. It names the criteria any acceptable model must meet: accuracy floor on a defined evaluation set, latency ceiling at p95, cost per call, data residency, and licensing constraints. Naming a specific model in the BRD locks the project to one vendor before the analysis is complete.

Data Dependencies and Lineage

Training data source, inference data source, refresh cadence, quality thresholds, and the data contract with every upstream system that feeds the model. The data owner is named in the BRD, not assumed. 60% of AI projects unsupported by AI-ready data are abandoned through 2026. The BRD is where that risk gets surfaced before commitment.

Acceptance Criteria for Non-Deterministic Behaviour

Traditional acceptance criteria assert a single correct answer. AI features rarely produce one. Replace single-answer assertions with statistical thresholds: 90% of responses match the reference across a defined test set. Hallucination rate stays below a documented ceiling. Outputs flagged as low-confidence trigger a defined fallback. The criteria are testable, just at a different unit of measurement.

Performance NFRs Specific to AI Features

Standard NFRs (availability, security, scalability) still apply. AI features add a layer: accuracy at p95, latency at p95, hallucination rate ceiling, token cost per transaction, throughput under load, and degraded-mode behaviour when the model is unavailable. Each one specified with a number, not an adjective.

Governance and Decision Boundaries

What the AI can decide alone. What requires human review. What is logged for audit. Who owns the output. How user override works. Which regulatory framework applies (EU AI Act, Bill C-27, sector-specific rules). The governance section is where compliance gets designed in, instead of bolted on after the audit finding.

Drift Detection and Monitoring

An AI feature ages differently than a deterministic one. Input distributions shift. Model accuracy degrades. The BRD defines what drift means for this use case, the metric that detects it, the threshold that triggers review, and the retraining or rollback path. This is the only requirements section that lives actively after deployment.

Common Failure Modes When the AI Section Gets Skipped

Three patterns recur in 2026 post-mortems on failed AI features:

The vendor pick happens before the BRD is written. A platform gets selected on a demo. The BRD then describes what that platform can do. Acceptance criteria match vendor capability instead of business need. The project ships, the demo works, the use case does not.

Acceptance criteria copy the deterministic template. User stories include single-answer acceptance criteria for non-deterministic features. UAT testers reject outputs that are statistically acceptable but lexically different from the example. The product is functional, but the test framework cannot validate it.

Governance is documented in the security policy, not the BRD. Decision authority, audit logging, and human-review rules are written as compliance artefacts and never make it into the build specifications. Six months post-deployment, an audit finds the model deciding things nobody scoped it to decide.

How Business Analysis Canada Writes BRDs for AI-Inclusive Projects

Our Analysis & Design service produces BRDs that delivery teams can build from without rework, including when the build involves AI components. Our analysts hold CBAP credentials, work across Agile, waterfall, hybrid, and SAFe, and write BRDs that are methodology-adaptive: user stories for Scrum teams, formal BRDs for waterfall, epics for SAFe.

For projects with AI features, we add the section above. Model criteria are defined in collaboration with your technical leads. Acceptance criteria are agreed with QA before the build starts. Governance rules are signed off by the stakeholder accountable for the regulatory exposure. The result is a BRD that humans, AI coding agents, and audit teams can all read against.

Frequently Asked Questions

Q: What is a Business Requirements Document?

A: A Business Requirements Document (BRD) captures what a business needs a solution to do, expressed in language that stakeholders can validate and developers can build from. It typically covers scope, stakeholders, business and functional requirements, non-functional requirements, constraints, dependencies, acceptance criteria, and traceability. A 2026-ready BRD adds an AI Features section when the build includes AI components.

Q: Do I still need a BRD if my team uses AI coding tools like Copilot or Cursor?

A: Yes. AI coding tools amplify whatever specification they are given. A clear BRD produces clean code faster. A vague BRD produces broken code faster. Specification engineering has become a recognised practice in 2026 precisely because AI coding tools depend on structured, unambiguous requirements.

Q: What goes in the AI Features section of a BRD?

A: Six components: model selection criteria (not vendor names), data dependencies and lineage, acceptance criteria for non-deterministic behaviour, performance NFRs (accuracy, latency, hallucination rate), governance and decision boundaries, and drift detection and monitoring.

Q: How do you write acceptance criteria for an AI feature?

A: Replace single-answer assertions with statistical thresholds. Instead of “the system returns X”, write “90% of responses match the reference across the defined test set” or “hallucination rate stays below 2%”. Define what counts as a match, what the test set is, and what happens when the threshold is missed.

Q: Who writes the BRD on an AI project?

A: A business analyst writes the BRD with input from the product owner, technical lead, data owner, and the stakeholder accountable for governance. The AI Features section in particular needs collaboration between the analyst and technical leads to define realistic model criteria and acceptance thresholds.

Ready to Write a BRD Your Team Can Build From?

Start with a free consultation. We will assess your project, identify the BRD sections you need (including AI Features, when applicable), and scope a focused analysis engagement that produces specifications your delivery team can build from without rework.

‍