# Business Requirements Document (BRD)

# Business Requirements Document (BRD): {{PROJECT_NAME}}

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

<!-- GUIDANCE: The BRD describes WHAT the business needs, not HOW to build it.
Technology decisions belong in the Functional Requirements Spec (FRS) and Technical Spec.
This document is written by a Business Analyst and owned by the Product Owner.
It requires sign-off from the client before development begins. -->

## 1. Executive Summary

<!-- GUIDANCE: 200-300 words maximum. Answer: What problem does this project solve?
Who benefits? What is the proposed solution? What are the expected outcomes?
Write this section LAST, after all other sections are complete. -->

**Project Overview:**
{{EXECUTIVE_SUMMARY_PARAGRAPH}}

**Business Problem:**
{{PROBLEM_SUMMARY_1_SENTENCE}}

**Proposed Solution:**
{{SOLUTION_SUMMARY_1_SENTENCE}}

**Expected Outcomes:**
- {{OUTCOME_1}}
- {{OUTCOME_2}}
- {{OUTCOME_3}}

**Investment:** {{BUDGET_RANGE}} NOK | **Timeline:** {{DURATION}} | **Priority:** {{HIGH/MEDIUM/LOW}}

---

## 2. Business Objectives & Goals

<!-- GUIDANCE: Business objectives are what the organization wants to achieve.
Each objective should be SMART: Specific, Measurable, Achievable, Relevant, Time-bound.
Objectives drive everything else in this document — every requirement should trace to at least one. -->

| ID | Objective | Description | Target | Timeframe |
|----|-----------|-------------|--------|-----------|
| BO-01 | {{OBJECTIVE_TITLE}} | {{DETAILED_DESCRIPTION}} | {{MEASURABLE_TARGET}} | {{DATE/TIMEFRAME}} |
| BO-02 | | | | |
| BO-03 | | | | |
| BO-04 | | | | |

**Alignment to Strategic Goals:**
This project supports the following organizational priorities:
- **{{STRATEGIC_GOAL_1}}:** {{HOW_THIS_PROJECT_SUPPORTS_IT}}
- **{{STRATEGIC_GOAL_2}}:** {{HOW_THIS_PROJECT_SUPPORTS_IT}}

---

## 3. Current State Analysis (AS-IS)

<!-- GUIDANCE: Document the current situation in detail. How does the business operate today?
What processes exist? What systems are used? What are the pain points, inefficiencies, and gaps?
This section forms the baseline against which the TO-BE state is measured. -->

### 3.1 Current Process Overview

{{CURRENT_PROCESS_DESCRIPTION}}

### 3.2 AS-IS Process Flow

```mermaid
flowchart LR
    A([Start]) --> B[{{STEP_1}}]
    B --> C{{{DECISION_POINT}}}
    C -->|Yes| D[{{STEP_2A}}]
    C -->|No| E[{{STEP_2B}}]
    D --> F[{{STEP_3}}]
    E --> F
    F --> G([End])
```

### 3.3 Current Systems & Tools

| System / Tool | Purpose | Users | Limitations |
|--------------|---------|-------|-------------|
| {{SYSTEM_NAME}} | {{PURPOSE}} | {{USER_COUNT/TYPE}} | {{LIMITATIONS}} |
| Manual process | {{WHAT_IS_MANUAL}} | {{WHO}} | Time-consuming, error-prone |

### 3.4 Current State Pain Points

| # | Pain Point | Category | Affected Users | Business Impact | Severity |
|---|-----------|----------|---------------|-----------------|----------|
| PP-01 | {{PAIN_POINT}} | Process / Technology / Data | {{USERS}} | {{IMPACT}} | High/Med/Low |
| PP-02 | | | | | |
| PP-03 | | | | | |

### 3.5 Current State Metrics (Baseline)

<!-- GUIDANCE: These baselines are crucial for proving the project delivered value post-launch. -->

| Metric | Current Value | Source | Notes |
|--------|-------------|--------|-------|
| {{METRIC}} | {{VALUE}} | {{HOW_MEASURED}} | {{CONTEXT}} |
| Process cycle time | {{VALUE}} | Observation / timing | Time from start to finish |
| Error rate | {{VALUE}}% | Issue logs | Manual error rate |
| User satisfaction | {{VALUE}}/10 | Survey | Last measured {{DATE}} |

---

## 4. Future State Vision (TO-BE)

<!-- GUIDANCE: Describe the desired future state. What will the process look like after the project?
What changes for users? What becomes automated? What decisions become data-driven?
Be aspirational but realistic. -->

### 4.1 Future State Description

{{TO_BE_STATE_DESCRIPTION}}

### 4.2 TO-BE Process Flow

```mermaid
flowchart LR
    A([Start]) --> B[{{NEW_STEP_1}}]
    B --> C[{{NEW_STEP_2_AUTOMATED}}]
    C --> D{{{DECISION_POINT_DATA_DRIVEN}}}
    D -->|Threshold met| E[{{NEW_OUTCOME_1}}]
    D -->|Threshold not met| F[{{NEW_OUTCOME_2}}]
    E --> G([End — Automated])
    F --> G
```

### 4.3 Key Improvements

| Area | AS-IS | TO-BE | Improvement |
|------|-------|-------|-------------|
| {{AREA}} | {{CURRENT}} | {{FUTURE}} | {{QUANTIFIED_IMPROVEMENT}} |
| Cycle time | {{VALUE}} | {{VALUE}} | {{X}}% faster |
| Error rate | {{VALUE}}% | {{VALUE}}% | {{X}}% reduction |
| User experience | {{RATING}} | {{RATING}} | Significant improvement |

---

## 5. Market Analysis & Competitive Landscape

<!-- GUIDANCE: Provide context on the market and competition. This helps stakeholders understand
why the project is necessary and how it positions the business. Keep it concise. -->

### 5.1 Market Context

{{MARKET_CONTEXT_PARAGRAPH}}

### 5.2 Competitive Analysis

| Competitor | Solution Type | Key Features | Pricing | Our Advantage |
|-----------|--------------|-------------|---------|---------------|
| {{COMPETITOR}} | Direct / Indirect | {{FEATURES}} | {{PRICING}} | {{ADVANTAGE}} |

### 5.3 Positioning

**Unique Value Proposition:** {{VALUE_PROP}}
**Target Market:** {{MARKET_SEGMENT}}
**Differentiators:** {{DIFFERENTIATORS}}

---

## 6. Stakeholder Needs Analysis

<!-- GUIDANCE: Different stakeholders have different — sometimes conflicting — needs.
Document each stakeholder group's needs before writing requirements.
Requirements that conflict need to be resolved with the PO before finalizing. -->

| Stakeholder Group | Primary Needs | Secondary Needs | Pain Points Addressed | Priority |
|------------------|--------------|----------------|----------------------|----------|
| {{STAKEHOLDER_1}} | {{PRIMARY_NEEDS}} | {{SECONDARY_NEEDS}} | PP-01, PP-02 | High |
| {{STAKEHOLDER_2}} | | | | |
| {{STAKEHOLDER_3}} | | | | |

---

## 7. Business Requirements

<!-- GUIDANCE: Business requirements describe WHAT the business needs, in business language.
NOT technical specifications. Each requirement must:
- Have a unique ID (BR-XXX)
- Trace to at least one business objective (BO-XX)
- Have a clear priority (MoSCoW: Must/Should/Could/Won't)
- Be verifiable (can you test whether it is met?) -->

| ID | Requirement | Description | Priority | Rationale | Source | BO Reference |
|----|------------|-------------|----------|-----------|--------|-------------|
| BR-001 | {{REQUIREMENT_TITLE}} | {{DETAILED_DESCRIPTION}} | Must Have | {{WHY_NEEDED}} | {{STAKEHOLDER/INTERVIEW}} | BO-01 |
| BR-002 | | | Must Have | | | |
| BR-003 | | | Must Have | | | |
| BR-004 | | | Should Have | | | |
| BR-005 | | | Should Have | | | |
| BR-006 | | | Could Have | | | |
| BR-007 | | | Won't Have (this release) | | | |

**MoSCoW Definitions:**
- **Must Have** — Essential for launch; system fails without it
- **Should Have** — High value; include unless significant constraints force exclusion
- **Could Have** — Nice to have; include only if time/budget allow
- **Won't Have** — Explicitly out of scope for this release (prevents scope creep)

---

## 8. Success Metrics & KPIs

<!-- GUIDANCE: Define specific, measurable targets. Each KPI needs a baseline (from current state),
a target, a measurement method, and an evaluation timeline. This enables objective project evaluation. -->

| ID | KPI | Category | Baseline | Target | Measurement Method | Evaluation Date | Owner |
|----|-----|----------|----------|--------|--------------------|-----------------|-------|
| KPI-01 | {{KPI_NAME}} | Revenue / Efficiency / Quality / UX | {{BASELINE}} | {{TARGET}} | {{HOW_MEASURED}} | {{DATE}} | {{OWNER}} |
| KPI-02 | User adoption rate | Adoption | 0% | {{TARGET}}% in 90 days | Analytics | 90 days post-launch | PM |
| KPI-03 | Process cycle time | Efficiency | {{BASELINE}} | {{TARGET}} | System monitoring | 30 days post-launch | Tech Lead |
| KPI-04 | User satisfaction (CSAT) | Quality | {{BASELINE}} | ≥ 8/10 | Post-launch survey | 60 days post-launch | PM |
| KPI-05 | System uptime | Reliability | N/A | ≥ 99.5% | Monitoring | Ongoing | DevOps |

---

## 9. Business Rules & Constraints

<!-- GUIDANCE: Business rules are non-negotiable operational constraints — often from legal,
regulatory, or organizational policy. They are NOT functional requirements but constrain them. -->

### 9.1 Business Rules

| ID | Rule | Category | Source | Enforced By |
|----|------|----------|--------|-------------|
| RUL-01 | {{RULE_DESCRIPTION}} | Legal / Operational / Financial | {{SOURCE}} | {{SYSTEM/PROCESS}} |
| RUL-02 | GDPR: User data must not leave EEA | Legal | GDPR Regulation | Infrastructure |
| RUL-03 | Financial transactions > {{AMOUNT}} require dual approval | Financial | Internal policy | Application |

### 9.2 Regulatory & Compliance Requirements

| Regulation | Applicability | Requirements | Responsible |
|------------|--------------|-------------|-------------|
| GDPR | {{YES/NO}} | Data minimization, right to deletion, DPA required | Tech Lead + Legal |
| {{REGULATION}} | | | |

### 9.3 Technical Constraints

<!-- GUIDANCE: System constraints imposed by the business environment, not technical preference. -->

- Must integrate with: {{EXISTING_SYSTEM}}
- Must support: {{BROWSER/DEVICE/OS}}
- Must run on: {{INFRASTRUCTURE}} (if mandated)
- Data residency: {{COUNTRY/REGION}} only
- {{ADDITIONAL_CONSTRAINT}}

---

## 10. Assumptions & Dependencies

### 10.1 Assumptions

| # | Assumption | Risk if False | Validation Owner |
|---|-----------|--------------|-----------------|
| A-01 | {{ASSUMPTION}} | {{RISK}} | {{OWNER}} |
| A-02 | Client will provide {{RESOURCE/ACCESS}} by {{DATE}} | Delays requirements phase | PM |
| A-03 | Existing {{SYSTEM}} API is stable during development | Integration rework required | Tech Lead |

### 10.2 Dependencies

| # | Dependency | Type | Impact if Unavailable | Target Date | Status |
|---|-----------|------|----------------------|-------------|--------|
| DEP-01 | {{DEPENDENCY}} | Internal / External | {{IMPACT}} | {{DATE}} | Pending |
| DEP-02 | Client data export from legacy system | Client | Cannot populate initial data | {{DATE}} | Pending |

---

## 11. ROI Analysis / Cost-Benefit

<!-- GUIDANCE: Quantify the business case. Use conservative estimates.
NPV = Net Present Value (future cash flows discounted to today's value). -->

### 11.1 Investment Summary

| Cost Category | One-Time (NOK) | Annual (NOK) | Notes |
|--------------|---------------|-------------|-------|
| Development | {{AMOUNT}} | — | One-time |
| Infrastructure | {{AMOUNT}} | {{AMOUNT}} | Ongoing hosting |
| Licenses | {{AMOUNT}} | {{AMOUNT}} | |
| Maintenance | — | {{AMOUNT}} | Post-launch support |
| **Total Year 1** | **{{TOTAL}}** | **{{ANNUAL}}** | |

### 11.2 Benefit Projections

| Benefit | Year 1 (NOK) | Year 2 (NOK) | Year 3 (NOK) | Confidence |
|---------|-------------|-------------|-------------|-----------|
| Revenue increase | {{AMOUNT}} | {{AMOUNT}} | {{AMOUNT}} | {{HIGH/MED/LOW}} |
| Cost reduction | {{AMOUNT}} | {{AMOUNT}} | {{AMOUNT}} | {{HIGH/MED/LOW}} |
| Risk reduction value | {{AMOUNT}} | {{AMOUNT}} | {{AMOUNT}} | {{HIGH/MED/LOW}} |
| **Total Benefits** | **{{TOTAL}}** | **{{TOTAL}}** | **{{TOTAL}}** | |

### 11.3 ROI Summary

| Metric | Value |
|--------|-------|
| Total Investment | {{NOK}} |
| Net Benefit (Year 1) | {{NOK}} |
| Payback Period | {{MONTHS}} months |
| 3-Year ROI | {{PERCENT}}% |
| 3-Year NPV (discount rate: {{RATE}}%) | {{NOK}} |

---

## 12. Implementation Roadmap

<!-- GUIDANCE: Phase the implementation to reduce risk and deliver early value.
Each phase should be independently valuable (not a half-built system). -->

| Phase | Description | Key Deliverables | Duration | Success Criteria |
|-------|-------------|-----------------|----------|-----------------|
| Phase 1 — MVP | Core {{FEATURE}} functionality | {{DELIVERABLES}} | {{DURATION}} | {{SUCCESS_CRITERIA}} |
| Phase 2 — Full Release | Complete feature set | {{DELIVERABLES}} | {{DURATION}} | {{SUCCESS_CRITERIA}} |
| Phase 3 — Enhancement | Advanced features, integrations | {{DELIVERABLES}} | {{DURATION}} | {{SUCCESS_CRITERIA}} |

```mermaid
timeline
    title {{PROJECT_NAME}} — Implementation Roadmap
    section Phase 1 — MVP
        {{START_DATE}} : Requirements & Design
        {{DATE}} : Core Development
        {{DATE}} : MVP Launch
    section Phase 2 — Full Release
        {{DATE}} : Advanced Features
        {{DATE}} : Integrations
        {{DATE}} : Full Launch
    section Phase 3 — Enhancement
        {{DATE}} : Performance & Scale
        {{DATE}} : Analytics & Reporting
```

---

## 13. Risk Assessment

<!-- GUIDANCE: High-level business risks. Technical risks are in the risk register.
Focus on business, organizational, and market risks here. -->

| # | Risk | Probability | Business Impact | Mitigation |
|---|------|------------|-----------------|------------|
| BR-R01 | {{RISK}} | H/M/L | H/M/L | {{MITIGATION}} |
| BR-R02 | Market change reduces project value | Low | High | Quarterly business case review |
| BR-R03 | Key business stakeholder changes role | Medium | High | Document all decisions; dual-approver model |

> Full technical risk register: `[../PROJECT-GOVERNANCE/risk-register.md](../PROJECT-GOVERNANCE/risk-register.md)`

---

## Approval

| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Business Analyst | | | |
| Product Owner | | | |
| AI Director (John) | | | |
| Client Sponsor | | | |
| CEO (Alem) | | | |