Use When
- a Business Requirements Document is needed to bridge strategy and detailed requirements; use prd-generation for product scope and user value, or initialize-srs for formal system specification.
- Use this procedure when the required source artefacts are available and
Business Requirements Documentis the next lifecycle deliverable.
Do Not Use When
- Use
prd-generation and initialize-srswhen that neighbouring route owns the decision or deliverable. - Do not invent missing project evidence, standards clauses, thresholds, or stakeholder decisions.
Required Inputs
| Artefact | Source or provider | Required? | Behaviour when missing |
|---|---|---|---|
| Vision, business goals, stakeholders, processes, constraints, and BRD decision gate | Sponsor, business owner, and project context | Yes | Stop the affected step, name the missing source, and return only a qualified gap record. |
Workflow
- Inspect the required inputs and log the exact sources, versions, and unresolved assumptions.
- Apply this skill's existing domain workflow and decision rules to produce
Business Requirements Document. - Stop when a required source, accountable decision owner, or deterministic test oracle is absent.
- Recover by preserving valid work, marking the blocked scope, and returning the narrowest qualified artefact plus the next evidence needed.
Outputs
| Artefact | Consumer | Acceptance condition |
|---|---|---|
| Business Requirements Document | Requirements engineering, sponsor, and solution evaluation | Required sections are populated, source links resolve, and every material requirement or decision has an observable review or test oracle. |
Evidence Produced
| Evidence | Reviewer | Acceptance condition |
|---|---|---|
Source, decision, trace, and validation record for Business Requirements Document |
Requirements quality reviewer | Inputs used, decisions made, checks run, failures, and unassessed items are explicit. |
Capability and permission boundaries
Read and search are required. Editing is allowed only when the request authorises creation or repair of the named requirements artefact. Publishing, production mutation, destructive action, spending, and certification require explicit authority.
Degraded mode
Fallback: if a required file, reviewer, standard source, network check, renderer, or execution capability is unavailable, return the narrowest useful qualified result and mark the affected check not assessed; never convert an unassessed check into a pass.
Decision Rules
| Choice or condition | Action | Failure or risk avoided |
|---|---|---|
| The BRD would duplicate an approved PRD without adding business decisions | Skip it and record the rationale and downstream source of truth. | Contradictory scope documents. |
| Required inputs and test oracles are complete | Continue through the existing workflow and record evidence. | A deliverable whose acceptance cannot be reproduced. |
| A mandatory source or owner is missing | Stop the affected branch and issue a qualified gap record. | Fabricated context or unauthorised decisions. |
Quality Standards
- Preserve stable identifiers and bidirectional traceability from project evidence to
Business Requirements Documentand its acceptance checks. - Apply ISO/IEEE measures only with a named metric, method, threshold, evidence source, and responsible reviewer; run the anti-slop gate before release.
Anti-Patterns
- Producing
Business Requirements Documentfrom assumed context. Fix: cite the project source or mark the scope blocked. - Accepting a material requirement without a deterministic oracle. Fix: add a measurable result, boundary, and verification method.
- Crossing into
prd-generation and initialize-srswithout routing the decision. Fix: hand off the named input and preserve trace links. - Treating an unavailable check as passed. Fix: mark it
not assessedand state the release consequence. - Claiming standards, statutory, or stakeholder approval without evidence. Fix: cite the source and reviewer or qualify the claim.
References
Overview
This skill generates a Business Requirements Document (BRD) that bridges strategic vision to detailed technical requirements. The BRD captures business objectives, scope boundaries, business rules, process flows, and measurable success criteria. The skill includes a decision gate that evaluates whether a formal BRD is warranted for the project, making it optional for smaller or agile-first initiatives.
When to Use This Skill
- After stakeholder analysis and elicitation have been completed
- When the project requires formal documentation of business requirements before SRS authoring
- When multiple stakeholder groups need a shared understanding of business scope and rules
- When regulatory or contractual obligations mandate a BRD artifact
Quick Reference
| Attribute | Value |
|---|---|
| Inputs | projects/<ProjectName>/_context/vision.md, projects/<ProjectName>/_context/features.md, projects/<ProjectName>/<phase>/<document>/stakeholder_register.md, projects/<ProjectName>/<phase>/<document>/elicitation_log.md |
| Output | projects/<ProjectName>/<phase>/<document>/brd.md |
| Tone | Business-formal, objective, decision-oriented |
| Standards | IEEE 29148-2018 Section 6.4, Business Requirements Gathering Ch.2-4 |
| Optional | Yes -- includes decision gate |
Input Files
| File | Location | Required | Purpose |
|---|---|---|---|
| vision.md | projects/<ProjectName>/_context/vision.md |
Yes | Business goals, problem statement, constraints |
| features.md | projects/<ProjectName>/_context/features.md |
Yes | Feature list with descriptions |
| stakeholder_register.md | projects/<ProjectName>/<phase>/<document>/stakeholder_register.md |
Yes | Stakeholder roles, classifications, communication plan |
| elicitation_log.md | projects/<ProjectName>/<phase>/<document>/elicitation_log.md |
No | Elicitation findings with source attribution |
| glossary.md | projects/<ProjectName>/_context/glossary.md |
No | Domain terminology (IEEE 610.12) |
Output Files
| File | Location | Description |
|---|---|---|
| brd.md | projects/<ProjectName>/<phase>/<document>/brd.md |
Complete Business Requirements Document |
Core Instructions
Step 0: Decision Gate
Before generating the BRD, evaluate whether a formal BRD is warranted. Present the following checklist to the user:
| Criterion | Yes/No | Weight |
|---|---|---|
| The project involves multiple stakeholder groups with competing priorities | 3 | |
| Regulatory or compliance requirements mandate formal business documentation | 3 | |
| The project is contractually obligated to deliver a BRD | 3 | |
| The project budget exceeds the organization's "small project" threshold | 2 | |
| The project spans multiple departments or business units | 2 | |
| The project replaces or integrates with existing business processes | 2 | |
| The project timeline exceeds 6 months | 1 | |
| Stakeholder alignment is uncertain or contested | 1 |
Scoring:
- Calculate weighted score: $Score = \sum (Weight_i \times YesFlag_i)$
- If $Score \geq 8$: BRD is recommended. Proceed with generation.
- If $4 \leq Score < 8$: BRD is optional. Present recommendation to user and await confirmation.
- If $Score < 4$: BRD is not recommended. Suggest proceeding directly to SRS or user story generation. Halt unless user overrides.
Reference: references/decision-gate.md
Step 1: Read Context Files
Read all required input files. Optionally read elicitation_log.md and glossary.md. Log every file path read. If vision.md, features.md, or stakeholder_register.md is missing, halt execution and report the gap.
Step 2: Generate Document Header
Write the document header containing:
- Project name (from
vision.md) - Version:
1.0 - Date: current date
- Authors: extracted from context or marked
[AUTHOR-TBD] - Document Status:
Draft - Approval signatories: extracted from stakeholder register (Sponsor, key stakeholders) or marked
[SIGNATORY-TBD]
Step 3: Generate Executive Summary
Write a concise summary (2-3 paragraphs) covering:
- The business problem or opportunity being addressed
- The proposed solution at a high level
- The expected business value and strategic alignment
- Key stakeholder groups affected
Use active voice. Do not include implementation details. Ground every assertion in vision.md content.
Step 4: Generate Business Objectives
For each business goal in vision.md, produce a formal business objective:
#### BO-XXX: [Objective Title]
- **Description**: [What the business seeks to achieve]
- **Alignment**: [Which strategic goal this supports]
- **Success Metric**: [Quantitative measure of achievement]
- **Target Value**: [Specific threshold]
- **Timeline**: [Target date or milestone]
- **Source**: [Stakeholder ID or context file reference]
Flag objectives lacking a measurable success metric with [METRIC-TBD].
Step 5: Generate Scope Definition
Define the project scope with explicit boundaries:
In Scope:
- List every feature from
features.mdthat is included in this project phase - For each item, provide a one-sentence scope statement
Out of Scope:
- List features, integrations, or capabilities explicitly excluded
- For each exclusion, provide a rationale
Scope Assumptions:
- List assumptions that, if invalidated, would change the scope
- Tag each with
[ASSUMPTION]
Step 6: Generate Stakeholder Summary
Summarize stakeholder information from stakeholder_register.md:
- Key stakeholder groups and their interests
- Decision-making authority mapping
- Communication and engagement summary
- Conflicts or competing priorities identified during elicitation
Step 7: Generate Business Requirements
For each business requirement identified from context files and elicitation findings, produce a formal entry:
#### BR-XXX: [Requirement Title]
- **Description**: The business shall [requirement statement in active voice].
- **Priority**: Critical | High | Medium | Low
- **Source**: [Stakeholder ID] -- [Elicitation Finding ID if available]
- **Rationale**: [Why this requirement exists]
- **Acceptance Criterion**: [Measurable condition for satisfaction]
- **Dependencies**: [BR-YYY, BR-ZZZ] (if any)
- **Assumptions**: [Related assumptions]
Requirements shall use "The business shall..." or "The organization shall..." language (not "The system shall..." which belongs in the SRS).
Step 8: Generate Business Rules
Document business rules that govern system behavior:
#### RULE-XXX: [Rule Name]
- **Statement**: [Formal rule statement]
- **Source**: [Regulatory body, policy document, or stakeholder]
- **Type**: Constraint | Policy | Computation | Inference
- **Example**: [Concrete example of the rule in action]
- **Exceptions**: [Conditions under which the rule does not apply]
For computation rules, express the formula in LaTeX notation. Example:
- $LateFee = Balance \times DailyRate \times DaysOverdue$
Step 9: Generate Process Flows
For each major business process affected by the project:
- Identify the process name and owner
- Document the current state (as-is) process steps
- Document the future state (to-be) process steps
- Highlight changes and improvements
- Describe the process using a numbered step sequence
If a process cannot be fully described from available context, flag it with [PROCESS-INCOMPLETE: Additional elicitation required for {process name}].
Step 10: Generate Success Criteria and Remaining Sections
Success Criteria:
- Define 3-7 measurable success criteria linked to business objectives
- Each criterion shall include: metric, baseline, target, measurement method, and review frequency
Assumptions and Constraints:
- Assumptions: Conditions believed to be true but not yet verified (tag each
[ASSUMPTION]) - Constraints: Fixed limitations on the project (budget, timeline, technology, regulatory)
Glossary:
- Include all domain-specific terms used in the BRD
- Align definitions with IEEE Std 610.12-1990 where applicable
- Reference
glossary.mdif available
Write the completed document to projects/<ProjectName>/<phase>/<document>/brd.md. Log the total count of business objectives, requirements, rules, and process flows.
Output Format Specification
The generated brd.md shall follow this structure:
# Business Requirements Document: [Project Name]
## Document Header
## 1. Executive Summary
## 2. Business Objectives
## 3. Scope Definition
### 3.1 In Scope
### 3.2 Out of Scope
### 3.3 Scope Assumptions
## 4. Stakeholder Summary
### 4.1 Key Stakeholders
### 4.2 Decision Authority
### 4.3 Communication Summary
## 5. Business Requirements
## 6. Business Rules
## 7. Process Flows
### 7.1 Current State (As-Is)
### 7.2 Future State (To-Be)
## 8. Success Criteria
## 9. Assumptions and Constraints
### 9.1 Assumptions
### 9.2 Constraints
## 10. Glossary
## 11. Standards Traceability
## 12. Approval and Sign-off
## Appendix A: Revision History
Common Pitfalls
- Skipping the decision gate and generating a BRD for projects that do not warrant one, creating unnecessary overhead
- Writing system-level requirements ("The system shall...") instead of business-level requirements ("The business shall...")
- Defining business rules without examples, making them ambiguous and unverifiable
- Listing assumptions without tagging them, causing scope confusion when assumptions prove false
- Omitting the as-is process flow, making it impossible to quantify the improvement the to-be process delivers
- Including implementation details that belong in the SRS rather than the BRD
Verification Checklist
- Decision gate was evaluated and the score justified BRD generation
- All required input files were read and logged
- Every business goal in
vision.mdmaps to at least one business objective with a success metric - Every business requirement uses "The business shall..." or "The organization shall..." language
- Every business requirement has a priority, source, and acceptance criterion
- Business rules include type classification, examples, and exception conditions
- Computation rules use LaTeX notation for formulas
- Process flows include both as-is and to-be states (or are flagged as incomplete)
- Success criteria are measurable with baseline, target, and method defined
- All assumptions are tagged with
[ASSUMPTION] - Glossary aligns with IEEE Std 610.12-1990
- Standards Traceability section maps to IEEE 29148 Section 6.4
Integration
| Direction | Skill | Relationship |
|---|---|---|
| Upstream | 01-stakeholder-analysis |
Consumes stakeholder register |
| Upstream | 02-elicitation-toolkit |
Consumes elicitation findings |
| Downstream | 02-requirements-engineering/waterfall/01-initialize-srs |
Feeds business context for SRS |
| Downstream | 02-requirements-engineering/waterfall/05-feature-decomposition |
Business requirements decompose into system features |
| Downstream | 02-requirements-engineering/agile/01-user-story-generation |
Business requirements inform epic/story creation |
Standards Compliance
| Standard | Governs |
|---|---|
| IEEE 29148-2018 Section 6.4 | Business requirements specification process |
| Business Requirements Gathering Ch.2 | Business objective formulation |
| Business Requirements Gathering Ch.3 | Business rule documentation |
| Business Requirements Gathering Ch.4 | Process flow analysis |
| IEEE Std 610.12-1990 | Terminology definitions |
Resources
references/brd-template.md-- Complete BRD template with examplesreferences/decision-gate.md-- Decision criteria for BRD necessity