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-08-29
last_modified	2026-08-29
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-08-29","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.

Goal and behavioral contract

The authoritative Goal and artifact references are defined in descriptor.yaml. Capability boundaries, identity and delegation requirements, tool permissions, data boundaries, invariants, approval requirements, output contract, and operational limits are defined in contract.yaml. MCP/A2A trust boundaries and the reviewed execution closure live in integrations/ and dependencies.yaml; ASPS and assurance requirements live in assurance.yaml.

Treat those declarations as mandatory execution constraints. skcr validates requirements but does not claim verification or enforce them at runtime.

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.