Requirements document

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

# 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).