Requirements Document

---
name: requirements-document
description: >-
  Generates a Business Requirements Document (BRD) or Functional Requirements Specification (FRS)
  skeleton populated from the user's input. It structures requirements with unique IDs, priority,
  source, and acceptance notes — making them traceable and reviewable.
version: 1.0.0
tags:
  - requirements
  - brd
  - frs
  - functional-specification
  - documentation
metadata:
  skill-author: 'Marie-Lynne Block'
---

## What this skill does

Generates a Business Requirements Document (BRD) or Functional Requirements Specification (FRS) skeleton populated from the user's input. It structures requirements with unique IDs, priority, source, and acceptance notes — making them traceable and reviewable.

## When to use it

- User asks to "write a requirements document", "produce a BRD", or "create a functional spec".
- A project needs formal requirements sign-off before design or build begins.
- Requirements must be traceable to use cases, test cases, or regulatory obligations.
- User wants to consolidate user stories, use cases, and constraints into a single document.

## Key concepts

### BRD vs. FRS

| | BRD — Business Requirements Document | FRS — Functional Requirements Specification |
| --- | --- | --- |
| **Audience** | Business stakeholders, project sponsors | Solution architects, developers, testers |
| **Focus** | What the business needs and why | What the system must do |
| **Language** | Business language | Technical/functional language |
| **Produced by** | Business analyst | Functional/technical analyst |
| **Input to** | FRS, project charter | Design specs, test plans |

This skill produces **both in a single document** unless the user specifies one type only.

### Requirement types

| Type | Description | Prefix |
| --- | --- | --- |
| Business requirement | High-level business need or goal | BR- |
| Functional requirement | Specific system behaviour | FR- |
| Non-functional requirement | Quality attributes (performance, security, etc.) | NFR- |
| Constraint | Fixed boundary (budget, regulation, tech stack) | CON- |
| Assumption | Stated truth that has not been verified | ASM- |

### Priority

Use MoSCoW: **Must have** / **Should have** / **Could have** / **Won't have (this release)**.

## Instructions

1. **Establish document metadata.** Project name, author, version, date, approvers.

2. **Write the business context.** Problem statement, business objectives, and scope. Draw from the user's input or the output of a `write-epic` or `gap-analysis`.

3. **Identify stakeholders.** Reference `stakeholder-map` output if available, or list roles.

4. **Document business requirements (BR-).** High-level needs expressed in business terms. Each BR maps to one or more FRs.

5. **Document functional requirements (FR-).** One behaviour per requirement. Each FR must be:
   - **Specific** — no ambiguous language ("the system shall display the order total" not "the system shall handle orders well").
   - **Measurable** — include a threshold where relevant ("within 2 seconds").
   - **Traceable** — reference the BR it satisfies.
   - **Testable** — a tester should be able to confirm it passes or fails.

6. **Document non-functional requirements (NFR-).** Cover relevant quality attributes: performance, scalability, security, availability, usability, maintainability, compliance.

7. **Document constraints (CON-).** Fixed boundaries the solution must operate within.

8. **Document assumptions (ASM-).** Statements assumed true; if proven false, requirements may change.

9. **Add open issues.** Requirements not yet agreed or information still needed.

10. **Produce the document** using the format below.

## Output format

```markdown
# Requirements Document: [Project / System name]

| Field | Detail |
| --- | --- |
| **Version** | 0.1 — Draft |
| **Date** | YYYY-MM-DD |
| **Author** | [name] |
| **Status** | Draft / In review / Approved |
| **Approvers** | [names or roles] |

---

## 1. Business context

### 1.1 Problem statement

[What problem is being solved and for whom.]

### 1.2 Business objectives

1. [Objective 1]
2. [Objective 2]

### 1.3 Scope

**In scope:** [What this project / system covers]  
**Out of scope:** [What is explicitly excluded]

---

## 2. Stakeholders

| Stakeholder | Role | Interest |
| --- | --- | --- |
| [Name / role] | [Team] | [What they need from this project] |

---

## 3. Business requirements

| ID | Requirement | Priority | Source |
| --- | --- | --- | --- |
| BR-001 | [The business need in business language] | Must have | [Stakeholder / regulation] |

---

## 4. Functional requirements

| ID | Requirement | Priority | Traces to | Notes |
| --- | --- | --- | --- | --- |
| FR-001 | The system shall [behaviour] [condition] [threshold]. | Must have | BR-001 | [Clarification or constraint] |
| FR-002 | The system shall [behaviour]. | Should have | BR-001 | |

---

## 5. Non-functional requirements

| ID | Category | Requirement | Priority |
| --- | --- | --- | --- |
| NFR-001 | Performance | [The system shall respond to [action] within [N] seconds under [load].] | Must have |
| NFR-002 | Security | [The system shall [security behaviour].] | Must have |
| NFR-003 | Availability | [The system shall achieve [N]% uptime per [period].] | Should have |

---

## 6. Constraints

| ID | Constraint |
| --- | --- |
| CON-001 | [Fixed boundary — technology, budget, regulation, timeline] |

---

## 7. Assumptions

| ID | Assumption | Impact if false |
| --- | --- | --- |
| ASM-001 | [Stated truth not yet verified] | [What changes if this is wrong] |

---

## 8. Open issues

| ID | Issue | Owner | Due |
| --- | --- | --- | --- |
| OI-001 | [Unresolved requirement or missing information] | [Role] | [Date or TBD] |

---

## Appendix: Traceability matrix

| BR | FR(s) | Use case(s) | Test case(s) |
| --- | --- | --- | --- |
| BR-001 | FR-001, FR-002 | UC-001 | TC-001, TC-002 |
```

## Examples

### Example 1 — Customer portal BRD

**Input:** "Write a BRD for a self-service customer portal where customers can view invoices, raise support tickets, and update their contact details."

**Expected output:** Business context with three objectives (reduce support calls, improve data accuracy, increase customer satisfaction). BR-001 to BR-003 per capability. FR-001 to FR-009 specifying system behaviours. NFRs covering session timeout (security), page load time (performance), and WCAG 2.1 AA (accessibility).

### Example 2 — Building from other skill outputs

**Input:** User provides output from `write-epic` and `gap-analysis`.

**Expected output:** Requirements document where BRs map to epic goals, FRs address the gaps, and constraints come from the epic's out-of-scope section. Traceability matrix pre-populated.

## Notes

- Write FRs using "The system shall…" (mandatory) or "The system should…" (desirable). Avoid "must", "will", or "can" — they have ambiguous force.
- Every FR must be testable. If you cannot write a test that would fail if the FR is not met, the FR is not specific enough.
- Version the document. Requirements change — v0.1 Draft → v0.2 In review → v1.0 Approved.
- This skill integrates with `use-case` (FRs and use cases should be mutually traceable), `acceptance-test-plan` (FRs drive test cases), and `gap-analysis` (gaps become requirements).