Requirement Summarizer

Overview

Extract and organize the essential information from requirement documents into a structured markdown summary that highlights core features, constraints, and priorities.

Workflow

Follow these steps to summarize requirement documents:

1. Read and Understand the Document

First, read the entire requirement document to understand its structure and content:

Identify document type (PRD, RFC, user story, business requirement, etc.)
Note any existing structure (sections, headers, numbering)
Understand the context and scope of the requirements

2. Extract Key Information

Systematically identify and extract:

Core Features:

Main functionality being proposed or required
User-facing capabilities
System behaviors and interactions
Integration points with other systems

Constraints:

Technical limitations or requirements
Business constraints (budget, timeline, resources)
Regulatory or compliance requirements
Compatibility or platform constraints
Security or privacy requirements
Performance requirements (latency, throughput, scalability)

Priorities:

Explicit priority labels (P0, P1, P2, Critical, High, Medium, Low)
MoSCoW categorization (Must have, Should have, Could have, Won't have)
MVP vs future phases
Required vs optional features
Blocking vs non-blocking items

3. Generate Structured Summary

Create a markdown report with the following structure:

# Requirements Summary: [Document Name]

## Document Metadata
- **Source**: [Document title/filename]
- **Type**: [PRD/RFC/User Story/Business Requirement/etc.]
- **Date Analyzed**: [Current date]

## Executive Summary
[2-3 sentence overview of what this requirement document defines]

## Core Features

### [Feature Category 1]
- **[Feature Name]**: [Brief description]
  - Priority: [P0/P1/P2 or Must/Should/Could]
  - Notes: [Any relevant context]

### [Feature Category 2]
...

## Constraints

### Technical Constraints
- [Constraint description]
- [Constraint description]

### Business Constraints
- [Constraint description]
- [Constraint description]

### Compliance/Regulatory Constraints
- [Constraint description]

### Performance Constraints
- [Constraint description]

## Priority Breakdown

### Critical/Must-Have (P0)
1. [Feature/requirement]
2. [Feature/requirement]

### High Priority/Should-Have (P1)
1. [Feature/requirement]
2. [Feature/requirement]

### Medium Priority/Could-Have (P2)
1. [Feature/requirement]
2. [Feature/requirement]

### Future/Won't-Have (P3)
1. [Feature/requirement]

## Key Decisions & Open Questions
- **Decision**: [What needs to be decided]
  - Options: [If applicable]
  - Impact: [Why this matters]

- **Open Question**: [Unclear requirement or missing information]

## Success Criteria
[How will we know this is successful? Metrics, acceptance criteria, or outcomes]

## Dependencies
- [External dependencies or prerequisites]
- [Related systems or teams]

## Timeline & Milestones
- [Key dates if mentioned in requirements]
- [Phase breakdown if applicable]

4. Quality Checks

Before presenting the summary, verify:

Completeness: All major features, constraints, and priorities captured
Clarity: Each item is clearly described without ambiguity
Accuracy: Information faithfully represents the source document
Organization: Related items grouped logically
Priorities: Priority levels are consistently applied
Actionability: Summary provides clear understanding of what needs to be built

5. Handle Edge Cases

Multiple conflicting priorities:

Note conflicts in "Key Decisions & Open Questions"
Flag for stakeholder clarification

Implicit vs explicit priorities:

If priorities aren't explicitly stated, infer from context (deadline pressure, business value, user impact)
Mark inferred priorities with "(inferred)" notation

Vague or ambiguous requirements:

Capture them in "Open Questions"
Suggest clarifying questions

Missing information:

Note gaps in "Open Questions"
Highlight critical missing details

Best Practices

Be concise but comprehensive:

Capture essential details without copying entire paragraphs
Use bullet points for scanability
Link back to specific sections of source document if helpful

Maintain objectivity:

Extract what's written, not what should be written
Flag concerns or gaps but don't rewrite requirements

Prioritize based on evidence:

Use explicit priority markers from the document
When inferring, base on business value, user impact, dependencies, and timeline

Adapt to document type:

PRDs/RFCs: Focus on technical details, system design, and architecture constraints
Business requirements: Emphasize business value, ROI, stakeholder needs
User stories: Extract acceptance criteria, user journeys, and UX requirements
Epics: Break down into constituent stories and themes

Handle different priority systems:

P0/P1/P2/P3 (common in tech)
Critical/High/Medium/Low
MoSCoW (Must/Should/Could/Won't)
Phase 1/2/3 or MVP/Future
Convert between systems when helpful for clarity

Example Usage

User request:

"Summarize the requirements from this PRD and identify what's critical for the first release"

Response approach:

Read the PRD document
Extract all features, noting which are marked for MVP/Phase 1
Identify technical and business constraints
Map explicit and implicit priorities
Generate structured markdown summary
Highlight critical items for first release in Priority Breakdown section