Requirements Documentation
Transform stakeholder needs into structured requirements documents with user stories, acceptance criteria, and traceability matrices.
The developers built exactly what the spec said — and it's completely wrong. Requirements were ambiguous, acceptance criteria were missing, and nobody traced back to what the user actually needed. Poorly documented requirements are the #1 cause of project failure, rework, and blown budgets.
Who it's for: business analysts translating stakeholder needs into functional requirements, product owners writing user stories with clear acceptance criteria, project managers ensuring requirements traceability from business need to delivery, systems analysts documenting technical specifications, consultants gathering and structuring client requirements
Example
"Document requirements for our new customer portal" → Complete requirements package: 25 user stories in standard format with acceptance criteria, functional requirements matrix with priority and complexity, non-functional requirements (performance, security), traceability matrix linking stories to business objectives, and a requirements review checklist
New here? 3-minute setup guide → | Already set up? Copy the template below.
# Requirements Documentation
## Your Role
You are an expert business analyst. Your job is to transform stakeholder needs into structured, traceable requirements with clear user stories, acceptance criteria, and priority rankings.
## Core Principles
- Separate what (requirements) from how (implementation)
- Every requirement needs acceptance criteria in Given/When/Then format
- MoSCoW prioritization with honest Must-have discipline
- Trace every requirement to a business objective
- Flag and resolve conflicting requirements explicitly
## Instructions
Produce: business requirements document, functional and non-functional requirements, user stories with acceptance criteria, MoSCoW prioritization, traceability matrix to business objectives, and conflict resolution notes.
## Output Format
- **User Stories**: As a [persona], I want [action], so that [benefit]
- **Acceptance Criteria**: Given [context], When [action], Then [expected result]
- **Priority**: MoSCoW classification with rationale
- **Traceability**: Requirement ID, business objective, user story, acceptance criteria
## Commands
- "Requirements document" - Full BRD from stakeholder inputs
- "User stories" - Story format with acceptance criteria
- "Prioritization" - MoSCoW ranking
- "Traceability matrix" - Requirements-to-objectives mapping
What This Does
Converts stakeholder interviews, meeting notes, and business needs into structured requirements documents — with user stories, acceptance criteria, priority rankings, and traceability to business objectives.
Quick Start
Step 1: Download the Template
Click Download above to get the CLAUDE.md file.
Step 2: Gather Stakeholder Inputs
Compile meeting notes, feature requests, business needs, and any existing specifications.
Step 3: Start Using It
claude
Say: "Transform these stakeholder interview notes into a structured requirements document with user stories, acceptance criteria, and MoSCoW prioritization."
Document Structure
| Section | Content |
|---|---|
| Business Requirements | High-level needs tied to business objectives |
| Functional Requirements | What the system must do |
| Non-Functional Requirements | Performance, security, scalability constraints |
| User Stories | As a [user], I want [action], so that [benefit] |
| Acceptance Criteria | Given/When/Then conditions for each story |
| Traceability Matrix | Requirements mapped to business objectives |
Tips
- MoSCoW prioritization: Must-have, Should-have, Could-have, Won't-have this time
- Acceptance criteria are contracts: If it doesn't have criteria, it's not a requirement
- Trace to business value: Every requirement should map to a business objective
- Separate what from how: Requirements define outcomes, not implementation
Commands
"Create requirements from these stakeholder notes"
"Write user stories with acceptance criteria for [feature]"
"Prioritize requirements using MoSCoW"
"Build a traceability matrix linking requirements to objectives"
Troubleshooting
Requirements too vague Say: "Add acceptance criteria using Given/When/Then format for every requirement."
Too many Must-haves Ask: "If we could only ship 5 features, which ones? Those are the real Must-haves."
Conflicting requirements Specify: "Flag conflicts and document which stakeholder owns each requirement."