# BRD Template — eight-section shipping format

> The eight-section schema below is the format used by the reference BRDs in this appendix. It is one rung up from Chapter 2's six-field cognitive minimum: same discipline, more operational sections, ready to be signed off and shared.

Bracketed italic text is the *guidance* to be replaced when authoring. Those bracketed prompts also serve a second purpose: in the transcript-driven elicitation loop (see [`Section 2 elicitation prompts`](airs-exemplar.md)), they become the natural `[PLACEHOLDER]` markers the loop produces when the transcript does not contain the answer for a section.

---

## Business Requirements Document

### [Project / Dashboard Name]

- **Project**: *[one-line description]*
- **Stakeholder**: *[primary role, not name]*
- **Date**: *[request date]*
- **Priority**: *[High | Medium | Low]*

### 1. Executive Summary

*[One paragraph: the business need, the decision the work will inform, and the expected outcome. Read this paragraph to someone who knows nothing about the project. They should know what is being built, who it serves, and why it matters by the end of it.]*

### 2. Business Context

*[Why is this work necessary now? What do stakeholders use today to inform this decision, and what is wrong with it? Three to six bullets or one tight paragraph.]*

### 3. Key Business Questions

*[The specific questions the artifact must answer. Group by theme if more than five. Each question is one sentence and is testable: a reader can ask the chart and get a defensible answer.]*

***[Theme A]***

1. *[Question 1]*
2. *[Question 2]*

***[Theme B]***

1. *[Question 3]*

### 4. Success Criteria

*[The conditions under which the artifact will be considered to have done its job. At least one criterion per stakeholder group named in Section 5. Each criterion is measurable; "users find it useful" is not measurable.]*

| Criterion | Measurement |
| --- | --- |
| *[Criterion 1]* | *[How will we know it is met?]* |
| *[Criterion 2]* | *[How will we know it is met?]* |

### 5. Stakeholder Requirements

*[Who uses this, how, and how often. Distinguish primary users (who must be served) from secondary users (who benefit if served).]*

#### Primary Users

- *[Role 1]*: *[usage pattern]*
- *[Role 2]*: *[usage pattern]*

#### Secondary Users

- *[Role 3]*: *[usage pattern]*

### 6. Data Requirements

| Requirement | Detail |
| --- | --- |
| **Data Sources** | *[Systems, files, or semantic models]* |
| **Refresh Frequency** | *[Real-time / daily / weekly / monthly]* |
| **Historical Horizon** | *[Time window required]* |
| **Data Sensitivity** | *[Public / internal / confidential / restricted]* |
| **Known Quality Issues** | *[Gaps, lags, definition differences]* |

### 7. Deliverables

| Item | Detail |
| --- | --- |
| **Format** | *[Power BI dashboard / report / embedded view / PDF]* |
| **Access Method** | *[Power BI Service / Teams / SharePoint / app]* |
| **Mobile Required** | *[Yes / No]* |
| **Target Go-Live** | *[Date]* |
| **Review Cadence** | *[How often the deliverable will be revisited]* |

### 8. Constraints & Assumptions

*[Things the work depends on that are not under the analyst's control (constraints) and things being treated as true without separate verification (assumptions). Each one is one sentence.]*

- **Constraint**: *[...]*
- **Assumption**: *[...]*

### Approval

| Role | Name | Date | Signature |
| --- | --- | --- | --- |
| Stakeholder | | | |
| Data Owner | | | |
| Analyst | | | |

---

**Source**: Appendix E § Section 1 of *The Defensible Decision*. Reproduced verbatim for copy-paste use. The bracketed prompts inside each section serve double duty — they explain what each section is for, and they become the natural `[PLACEHOLDER]` markers when the transcript-driven loop encounters a gap.