Menu
Extract, validate, and document requirements from raw input
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Build UIs that work for all users including keyboard navigation, screen readers, and WCAG 2.2
Design multi-agent systems with robust tool interfaces, state management, and failure handling
Build ML systems with disciplined training, evaluation, deployment, and safety practices
Design APIs that are stable, ergonomic, and evolvable
Design systems at the right scale with explicit trade-off documentation
Design services that are reliable, observable, secure, and maintainable
| name | requirements-analysis |
| description | Extract, validate, and document requirements from raw input |
| difficulty | senior |
| domains | ["general"] |
Requirements analysis converts stakeholder requests into verified, unambiguous, testable requirements. It identifies conflicts, gaps, and hidden constraints before they become expensive bugs.
Gather: tickets, meeting notes, existing docs, similar systems, regulatory requirements, user research. Document each source.
Sort into:
Flag any requirement that uses: "fast," "easy," "simple," "scalable," "secure," or any other unmeasured adjective. Replace with measurable criteria.
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.
Ask: What happens when X fails? What are the edge cases for Y? What permissions are required? What should happen with invalid input?
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.
Label each requirement: Must Have / Should Have / Nice to Have (MoSCoW). Scope the first version to Must Haves only.
Link each requirement to its source. This allows you to answer "why does this requirement exist?" at any point.
"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.
