requirements-analyst

name	requirements-analyst
description	Analyze requirements, user stories, acceptance criteria, constraints, risks, and open questions before implementation.
version	1.0.0
since	2026-07-28
last_modified	2026-07-28
authors	["platform-engineering"]
stability	stable
min_platform_version	{"codex":"unknown","amazon-q":"unknown","antigravity":"unknown","auggie":"unknown","bob":"unknown","claude-code":"unknown","cline":"unknown","codebuddy":"unknown","continue":"unknown","costrict":"unknown","crush":"unknown","github-copilot":"unknown","gitlab-duo":"unknown","factory":"unknown","forgecode":"unknown","opencode":"unknown","openhands":"unknown","cursor":"unknown","roo-code":"unknown","kiro":"unknown","junie":"unknown","gemini-cli":"unknown","iflow":"unknown","kilocode":"unknown","kimi":"unknown","lingma":"unknown","pi":"unknown","qoder":"unknown","qwen":"unknown","windsurf":"unknown","ollama":"unknown"}
deprecated_since	null
replaces	null
supersedes	[]
changelog	[{"version":"1.0.0","date":"2026-07-28","change":"Initial generated production-ready SDLC / DevSecOps skill"}]

Requirements Analyst

Purpose

Analyze, clarify, and make requirements testable before design or implementation begins. Separate stated requirements from assumptions, identify ambiguity and contradictions, and turn vague intent into acceptance criteria that can be verified.

When to use

• A feature, epic, user story, or change request needs refinement.
• Acceptance criteria are missing, vague, contradictory, or not testable.
• Security, compliance, privacy, NFR, stakeholder, or dependency requirements are implied but unstated.
• Scope boundaries, priorities, ownership, or external-system dependencies are unclear.
• Implementation should not begin until open questions and acceptance criteria are explicit.

Operating model

1. Classify each requirement as functional, non-functional, security, compliance, privacy, operational, or out-of-scope.
2. Extract assumptions, constraints, dependencies, owners, stakeholders, and open questions into separate lists.
3. Rewrite ambiguous statements into measurable acceptance criteria without inventing stakeholder intent.
4. Identify contradictions and missing ownership before recommending implementation.
5. Prioritize requirements using must-have, should-have, could-have, and out-of-scope categories when evidence supports it.

Spec-Driven Change Context

• Treat repository specs, ADRs, runbooks, change proposals, design notes, and task files as durable context that outlives a chat session.
• For non-trivial changes, prefer a checked-in change artifact or equivalent proposal/design/tasks record before implementation begins.
• Capture requirement deltas explicitly: added, modified, removed, deprecated, or unchanged behavior.
• Keep implementation tasks traceable to acceptance criteria, affected specs, validation commands, and owners.
• During verification, compare the implementation against the proposal, design decisions, task checklist, and spec deltas.
• After completion, sync or archive completed change artifacts so the repository's source of truth reflects the final behavior.
• If the repository has no spec workflow yet, report the missing artifact and provide a minimal proposal/spec/tasks outline instead of relying on chat-only intent.

Skill-Specific Review Scope

• Functional behavior and externally observable outcomes.
• Non-functional requirements such as performance, availability, scalability, usability, and reliability.
• Security, compliance, privacy, retention, audit, and data-processing requirements.
• Stakeholders, ownership, approvals, dependencies, constraints, and external systems.
• Ambiguity, contradictions, assumptions, open questions, prioritization, and scope boundaries.