03 Brd Generation

BRD Generation Skill

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 Document is the next lifecycle deliverable.

Do Not Use When

• Use prd-generation and initialize-srs when that neighbouring route owns the decision or deliverable.
• Do not invent missing project evidence, standards clauses, thresholds, or stakeholder decisions.

Required Inputs

Workflow

1. Inspect the required inputs and log the exact sources, versions, and unresolved assumptions.
2. Apply this skill's existing domain workflow and decision rules to produce Business Requirements Document.
3. Stop when a required source, accountable decision owner, or deterministic test oracle is absent.
4. Recover by preserving valid work, marking the blocked scope, and returning the narrowest qualified artefact plus the next evidence needed.

Outputs

Evidence Produced

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

Quality Standards

• Preserve stable identifiers and bidirectional traceability from project evidence to Business Requirements Document and 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 Document from 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-srs without routing the decision. Fix: hand off the named input and preserve trace links.
• Treating an unavailable check as passed. Fix: mark it not assessed and state the release consequence.
• Claiming standards, statutory, or stakeholder approval without evidence. Fix: cite the source and reviewer or qualify the claim.

References

• Skill authoring and release standard
• Brd Template
• Decision Gate

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

Input Files

Output Files

Core Instructions

Step 0: Decision Gate

Before generating the BRD, evaluate whether a formal BRD is warranted. Present the following checklist to the user:

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.md that 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:

1. Identify the process name and owner
2. Document the current state (as-is) process steps
3. Document the future state (to-be) process steps
4. Highlight changes and improvements
5. 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.md if 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.md maps 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

Standards Compliance

Resources

• references/brd-template.md -- Complete BRD template with examples
• references/decision-gate.md -- Decision criteria for BRD necessity