---
artifact-status: draft   # draft | approved — approval state of this generated file (gate reads this)
---
# Business Requirements Document (BRD)

> **Last Updated:** [Date]
> **Business Owner:** [Name]
> **Contributors:** [Names/Roles]

> Section order follows the governance sub-artifact chain: Business Objective (BO) → Problem → Scope → Business Requirement (BR) → Business Rule (BRU) → Actor (AT) → Business Flow (BF) → Entity (E) → Entity State (ES) → Constraint & Assumption (CA). A section that does not apply is kept and marked `N/A` (the agent skips it).

---

## 1. Executive Summary

**Project / Initiative Name:** [Name]

**Summary:**
[2-3 sentences: what this initiative is, what business problem it solves, expected outcome.]

**Decision Required By:** [Date]

---

## 2. Business Objectives

> **BO = one strategic, system-level statement of intent** — the WHY at its highest level. Format `BO-NNN`. Do NOT restate the measurable numbers that belong to a BR. Cardinality **1 BO : N BR** — every BR references exactly one BO.

| ID | Business Objective (strategic) |
|----|--------------------------------|
| BO-001 | [e.g. Optimise the order placement and fulfilment process to grow revenue and cut operating cost] |

---

## 3. Problem Statement / Business Need

**Current State:**
[Describe the problem, pain point, or opportunity. What is broken or missing today?]

**Impact:**
[Quantify impact where possible: cost, time, revenue lost, compliance risk, etc.]

**Why Now:**
[Market timing, regulatory deadline, competitive pressure, strategic priority]

---

## 4. Project Scope

### 4.1 In Scope
- [Business capability / domain 1]
- [Business capability / domain 2]

### 4.2 Out of Scope
- [Explicitly excluded item 1]
- [Explicitly excluded item 2]

---

## 5. Business Requirements

> **BR = a measurable business outcome this initiative must achieve — the WHY, not a feature.**
> Each BR is a measurable breakdown of a BO and **references exactly one BO** (a BR with no BO is an orphaned outcome). If the initiative were cancelled, the BRs are exactly what would not be achieved.
> System behaviour (e.g. "guest can checkout without an account") is **NOT** a BR — that is an FR and belongs in the PRD.
> Every FR in the PRD traces back to at least one BR here (the PRD enforces this via its BR Reference column).

| ID | BO Ref | Business Requirement (measurable outcome) | Priority |
|----|--------|-------------------------------------------|----------|
| BR-001 | BO-001 | [e.g. Increase checkout completion rate from 60% to 85% within 6 months] | Must |
| BR-002 | BO-001 | [e.g. Reduce order processing time from 3 days to 1 day] | Should |
| BR-003 | BO-001 | [Measurable business outcome] | Could |

**Priority scale:** Must / Should / Could / Won't

> ✅ Right: "Reduce cart abandonment below 20%."  ❌ Wrong: "Guest can checkout without an account" (system behaviour → FR in PRD).

---

## 6. Business Rules

> Constraints and policies that apply across the business — **not features**. Stable rules the system must always honour. Each rule records its **scope** (which entity or flow it governs) and **source** (regulatory or business policy). A Feature Spec later cites these via `BRU-NNN` inside its Acceptance Criteria, and each BRU must be verified by at least one test.

| ID | Business Rule | Scope (entity / flow) | Source |
|----|---------------|-----------------------|--------|
| BRU-001 | [e.g. An order is only confirmed once payment succeeds] | E-002 Order | Business policy |
| BRU-002 | [e.g. No refunds for orders under $10] | E-004 Payment | Business policy |

---

## 7. Actors

> Person or system that **interacts directly** with the product, at the business-role level (not a detailed persona yet). Format `AT-NNN`.
> Distinguish from a **Stakeholder** (has authority or interest but does not interact directly — those live in the Project Charter, not here).
> A **human actor** flows downstream to a Persona in the PRD; an **external system actor** flows to an Integration Contract in the SAD (and to SAD.System Context).

| ID | Actor | Type | Description |
|----|-------|------|-------------|
| AT-001 | [e.g. Guest] | Human | [Buyer without an account, via web] |
| AT-002 | [e.g. Registered Customer] | Human | [Buyer with an account] |
| AT-003 | [e.g. Warehouse Staff] | Human | [Handles dispatch via internal admin screen] |
| AT-004 | [e.g. Payment Gateway] | External system | [Receives payment requests via API] |
| AT-005 | [e.g. Carrier] | External system | [Delivery / logistics provider] |

---

## 8. Business Flow

> The agreed business process from the **organisation's** point of view (not the system's). Step-by-step, in business language. **Every step names its actor by `AT-NNN`** — no free-text role names. The PRD derives User Flows from these.

| ID | Business Flow |
|----|---------------|
| BF-001 | [e.g. AT-001 Guest selects product → AT-003 Warehouse Staff confirms stock → AT-001 Guest pays via AT-004 Payment Gateway → AT-003 Warehouse Staff dispatches → AT-005 Carrier delivers] |

---

## 9. Entities

> Core business objects the business defines and operates. **Business name + definition only** — no attributes, no technical relationships (those belong in PRD.Product Data Model and SAD.Data Architecture).
> **Entity mode: Inline** — entities are recorded directly here. (The separate Domain Glossary & Entity-Doc mode is managed outside this kit.)

| ID | Entity | Business Definition |
|----|--------|---------------------|
| E-001 | [e.g. Customer] | [Person who buys goods] |
| E-002 | [e.g. Order] | [A purchase transaction] |

---

## 10. Entity States

> Lifecycle and states of each entity in **business language** — state names and transition conditions only. No technical events or state machines. **Conditional:** only entities that have a meaningful business lifecycle need a row; reference/master data (e.g. Product, Category) can be `N/A`.

| Entity | States & Transitions |
|--------|----------------------|
| E-002 Order | [e.g. Draft → Confirmed (payment succeeds) → Shipped (warehouse dispatches) → Delivered; Cancelled (only allowed before Shipped)] |

---

## 11. Constraints & Assumptions

> Constraints and assumptions captured and signed off from pre-sale, in five groups. **NFR Constraints here seed the PRD's Non-Functional Requirements.**

### 11.1 Business Constraints
- [e.g. Fixed budget; hard launch deadline; data must not be stored outside Singapore]

### 11.2 Technical Constraints
- [e.g. Must deploy on Azure; must integrate with existing SAP]

### 11.3 NFR Constraints
- [e.g. Uptime 99.9%; checkout page P95 ≤ 2s — these seed PRD.NFR]

### 11.4 Security & Compliance Constraints
- [e.g. PCI-DSS Level 1; PDPA / GDPR compliance]

### 11.5 Assumptions
- [Assumption 1 — what we assume to be true, e.g. customer provides their own server infrastructure]
- [Assumption 2]

---

<!-- The Glossary below is not one of the governance sub-artifacts (which end at Constraints & Assumptions above). It is kept because the kit sources project agent context / domain terms from BRD.Glossary. Stakeholders, Timeline, and Cost-Benefit live in the Project Charter, not the BRD. -->

## 12. Glossary

> Domain terms and ubiquitous language shared with the customer. Source for the project's agent context (`/tas-agents`). Add a term whenever a clarification reveals one.

| Term | Definition |
|------|------------|
| [e.g. Guest Shopper] | [Customer who has not created an account] |
| [e.g. Confirmed Order] | [Order whose payment has succeeded] |

---

## Completeness Disposition

> Business-completeness lenses (`.tas/rules/common/business-completeness.md`). Every lens
> dispositioned before approval — Covered (with `AT/BF/BR/BRU` ref) or `N/A — reason`. No blank rows.

| # | Lens | Disposition | Ref / Reason |
|---|------|-------------|--------------|
| L1 | Actor & role coverage | | |
| L2 | Entity lifecycle (business CRUD) | | |
| L3 | Identity & access governance | | |
| L4 | Data confidentiality & scope | | |
| L5 | Notifications & feedback | | |
| L6 | Exception & edge paths | | |
| L7 | Data lifecycle | | |
| L8 | i18n / l10n | | |
| L9 | Reporting & analytics | | |
| L10 | Onboarding & first-run / bootstrap | | |

---

## Changelog

> The **Customer Sign-off Reference** column is required on any row that sets the version to Approved — point to the email or file the customer signed (signer name + date).

| Date | Version | Changes | Author | Customer Sign-off Reference |
|------|---------|---------|--------|-----------------------------|
| [Date] | 1.0 | Initial draft | [Name] | — |

---

## AI Usage Log

| # | Date | Command | Input (est.) | Output (est.) |
|---|------|---------|-------------|---------------|
| 1 | [Date] | /tas-brd | ~{N}k | ~{N}k |
| **Total** | | | **~{N}k** | **~{N}k** |