brd-writer git:20260323.771ca1cA

Immutable. This exact content never changes and is served at /api/v1/blob/54a2ec238d3de89b.

---
name: brd-writer
description: >
  Write a Business Requirements Document. Use when the user says "write a BRD",
  "business requirements", "document the business need", "vision and scope document",
  "business case for this feature", "what does the business need", "strategic requirements",
  "document why we need this" - even if they don't explicitly say "BRD".
---

## Overview

Based on **Software Requirements** by Karl Wiegers & Joy Beatty - the Vision & Scope Document template that separates business objectives from product scope before any solution is discussed. Also draws on the **BABOK Guide v3 (IIBA)** and its BACCM model - 6 core concepts (Change, Need, Solution, Stakeholder, Value, Context) that frame every business analysis effort. The key insight from Wiegers: a BRD is not a feature list. It defines why the organization needs a change and what success looks like, leaving how to the solution team.

## Workflow

### Step 1: Define the business context (BACCM)
Frame the initiative using BABOK's 6 core concepts:
- **Change**: What is changing and why now?
- **Need**: What problem or opportunity exists?
- **Stakeholder**: Who is affected and who decides?
- **Value**: What business value will this deliver?
- **Context**: What constraints, regulations, or dependencies exist?
- **Solution**: What type of solution is envisioned (not the detailed design)?

### Step 2: Write business objectives
Each objective must be measurable. Format:
```
BO-1: [Verb] [measurable outcome] by [timeframe]
Example: Reduce customer onboarding time from 14 days to 3 days by Q4 [year]
```
Link each objective to an organizational goal or KPI.

### Step 3: Identify stakeholders and their needs
For each stakeholder group:
```
STAKEHOLDER: [Role / Group]
NEEDS: [What they need from this initiative]
SUCCESS CRITERIA: [How they will judge success]
CONSTRAINTS: [Limitations they impose]
```

### Step 4: Define the scope boundary
Use Wiegers' scope definition approach:
- **In scope**: Capabilities this initiative will deliver
- **Out of scope**: Explicitly excluded items (prevents scope creep)
- **Assumptions**: What you are taking as given
- **Dependencies**: External factors that must be true

### Step 5: Document constraints and risks
- **Business constraints**: budget, timeline, regulatory deadlines
- **Technical constraints**: existing systems, integration requirements, data limitations
- **Risks**: what could prevent success, with likelihood and impact

### Step 6: Define success criteria
Quantified metrics that determine whether the initiative achieved its objectives:
```
SC-1: [Metric] moves from [current baseline] to [target] within [timeframe]
Measurement method: [how it will be measured]
```

### Step 7: Assemble the BRD
```
# Business Requirements Document: [Initiative Name]
**Version:** [X.X]  **Status:** [Draft / Review / Approved]
**Author:** [your name]  **Date:** [date]

## 1. Business Context (BACCM)
## 2. Business Objectives
## 3. Stakeholders and Needs
## 4. Scope (In / Out / Assumptions / Dependencies)
## 5. Constraints and Risks
## 6. Success Criteria
## 7. Approval and Sign-off
```

## Anti-Patterns

**1. Writing a feature list instead of a BRD**
Bad: "The system shall have a dashboard with charts and filters."
Good: "Operations managers need real-time visibility into order fulfillment to reduce late shipments by 40%."

**2. Unmeasurable business objectives**
Bad: "Improve the customer experience."
Good: "Increase NPS from 32 to 50 within 6 months of launch."

**3. No scope boundary**
Bad: BRD that lists what's included but never says what's excluded.
Good: Explicit "Out of Scope" section that prevents scope creep during delivery.

**4. Stakeholders listed without needs**
Bad: "Stakeholders: Finance, Operations, IT."
Good: Each stakeholder has documented needs, success criteria, and constraints.

## Quality Checklist

- [ ] Business context framed using all 6 BACCM concepts
- [ ] Every business objective is measurable with a target and timeframe
- [ ] All stakeholder groups identified with needs and success criteria
- [ ] Scope has both "in scope" and "out of scope" sections
- [ ] Assumptions and dependencies are explicit
- [ ] Risks documented with likelihood and impact
- [ ] Success criteria are quantified with measurement methods
- [ ] BRD explains "why" without prescribing "how"