requirements-document · diff
v1.0.0 to v1.0.0
3 added, 7 removed. Audit A to B.
---
- name: requirements-document
description: >
- Produce a structured requirements document (BRD or FRS) with business
- context, stakeholder needs, functional requirements, non-functional
- requirements, constraints, and assumptions. Use when a project or system
- needs formal requirements capture beyond user stories or use cases.
+ name: requirements-document
version: 1.0.0
- authors:
- - Marie-Lynne Block
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).