# Requirements Analysis

> Extract, validate, and document requirements from raw input

- Skill: `vignesh2027/requirements-analysis` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vignesh2027/requirements-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vignesh2027/requirements-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: vignesh2027 (https://skillmd.com/u/vignesh2027)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vignesh2027/requirements-analysis

---


## Overview

Requirements analysis converts stakeholder requests into verified, unambiguous, testable requirements. It identifies conflicts, gaps, and hidden constraints before they become expensive bugs.

## When to Use

- After gathering stakeholder input but before writing specs
- When requirements come from multiple sources that may conflict
- Before estimating effort on a project
- When the system must integrate with external systems or regulations

## Process

### Step 1: Collect all sources
Gather: tickets, meeting notes, existing docs, similar systems, regulatory requirements, user research. Document each source.

### Step 2: Extract and categorize requirements
Sort into:
- **Functional** — What the system does
- **Non-functional** — How well it does it (performance, security, availability)
- **Constraints** — What the system cannot do or cannot use
- **Assumptions** — Things believed true but not verified

### Step 3: Check for ambiguity
Flag any requirement that uses: "fast," "easy," "simple," "scalable," "secure," or any other unmeasured adjective. Replace with measurable criteria.

### Step 4: Check for conflicts
List pairs of requirements that could contradict each other. Example: "must respond in under 100ms" vs "must encrypt all data at rest and in transit." Resolve or prioritize explicitly.

### Step 5: Check for completeness
Ask: What happens when X fails? What are the edge cases for Y? What permissions are required? What should happen with invalid input?

### Step 6: Validate with stakeholders
Walk through the requirements list with at least one stakeholder. Every ambiguity you resolve costs nothing here; every ambiguity you miss costs exponentially more later.

### Step 7: Prioritize
Label each requirement: **Must Have** / **Should Have** / **Nice to Have** (MoSCoW). Scope the first version to Must Haves only.

### Step 8: Create a traceability matrix
Link each requirement to its source. This allows you to answer "why does this requirement exist?" at any point.

## Anti-Rationalizations

**"We can figure out edge cases as we go"**
Edge cases figured out during implementation become design debt. Edge cases figured out during requirements analysis become requirements.

**"The stakeholder said it clearly"**
Verbal clarity is not written clarity. What they said and what they meant often diverge when you write it down and ask them to confirm.

## Verification Requirements

- [ ] All requirements are measurable (no unmeasured adjectives)
- [ ] No unresolved conflicts between requirements
- [ ] Edge cases documented for all critical flows
- [ ] Requirements prioritized with MoSCoW
- [ ] Traceability matrix exists (requirement → source)
- [ ] Stakeholder sign-off obtained