# Requirements Engineering > Use when the work is still at the “what should we build” stage rather than design or implementation. Apply before spec-writing, architecture, API design, planning, or coding when interviews, personas, stakeholder notes, or discovery artifacts must be turned into prioritized functional requirements, non-functional requirements, scope boundaries, traceable sources, and explicit “the system shall” statements; not for acceptance criteria, PRD drafting from an approved requirements doc, spec review, or implementation. - Skill: `yknothing/requirements-engineering-2` (Agent Skill) - Install (CLI): `npx skillmds@latest add yknothing/requirements-engineering-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/yknothing/requirements-engineering-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: yknothing (https://skillmd.com/u/yknothing) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/yknothing/requirements-engineering-2 --- # Requirements Engineering > Transform user needs and business goals into precise, testable requirements. ## Context Requirements engineering bridges discovery and design. It takes the "what users need" from discovery and turns it into "what the system must do" for architecture. Poor requirements are the #1 cause of project failure -- not because requirements are missing, but because they're ambiguous, contradictory, or incomplete. This skill may start from more than one upstream shape: - a discovery evidence set such as market research, personas, and feasibility findings - a routed entry-stack handoff such as `problem-frame` and `design-direction` - an `intake-brief` that records constraints, open questions, and the intended next step Do not force every route through the same upstream artifact bundle. Start from the approved upstream direction that actually exists, then preserve its constraints faithfully. ## Inputs - **design-direction** -- Preferred directional input when [problem-framing](../../00-discovery/problem-framing/SKILL.md) has already compared options and selected a path. Treat this as the strongest signal for what release or iteration direction should be converted into requirements. - **problem-frame** -- Clarifies the problem statement, non-goals, assumptions, and open questions that requirements must preserve rather than silently resolve. - **intake-brief** -- Supplemental routing and scope context. Useful for preserving work type, urgency, methodology choice, and handoff risks. - **market-research-report** -- Market context, competitor gaps, or opportunity framing when the work is still anchored in discovery evidence. - **user-persona-set** -- User goals, pain points, and behavior patterns that requirements should trace back to. - **feasibility-report** -- Go/no-go and risk context. Use especially when viability, operational constraints, or timeline limits shape what can become a requirement. Minimum expectation: - either an approved `design-direction`, or - a reviewed discovery evidence set that makes the problem and target user clear enough to write requirements without guessing If neither exists, stop and route back upstream instead of inventing requirements from vague intent. ## Process ### Step 1: Gather Functional Requirements For each user persona and journey, identify what the system must do: - User actions (login, create, search, purchase, export) - System responses (validate, calculate, notify, persist) - Business rules (pricing logic, access control, workflow transitions) Use a consistent format: "The system shall [action] when [condition] so that [benefit]." ### Step 2: Identify Non-Functional Requirements Quantify quality attributes **only when the source material supports a bound or when you clearly label an assumption that still needs owner confirmation**: - **Performance**: Response time < 200ms p95, support 1000 concurrent users - **Security**: OWASP Top 10 compliance, SOC2 Type II, data encryption at rest - **Scalability**: Handle 10x growth without architecture changes - **Availability**: 99.9% uptime (8.7 hours downtime/year) - **Accessibility**: WCAG 2.1 AA compliance When the source gives a direction but not a number: - Convert it into a bounded requirement only if the bound is explicitly sourced - Otherwise record it as an **open question** or **assumption requiring review** - Do **not** invent precise targets just to make the document look complete ### Step 3: Prioritize Use MoSCoW (Must/Should/Could/Won't) or RICE (Reach x Impact x Confidence / Effort): - **P0 (Must)**: Product is unusable without these - **P1 (Should)**: Important but workarounds exist - **P2 (Could)**: Nice to have, include if time permits - **P3 (Won't)**: Explicitly out of scope for this iteration ### Step 4: Validate and Resolve Conflicts - Review with stakeholders for completeness - Check for contradictions between requirements - Verify technical feasibility with architect - Ensure traceability (each requirement links to a user need) - Flag any requirement or NFR whose precision is assumption-driven rather than source-driven - Preserve upstream non-goals and open questions from `problem-frame`, `design-direction`, or `intake-brief` instead of silently collapsing them into solution commitments ### Step 5: Document with Traceability Each requirement should have: ID, description, priority, source (which user need), acceptance criteria reference, and status. If a metric, SLA, or retention bound is not directly supported by the source material, include it only as: - an explicitly labeled assumption, or - an open question with a named owner ## Quality Gate - [ ] All P0/P1 requirements documented with clear acceptance criteria - [ ] Non-functional requirements quantified where evidence exists; otherwise converted into explicit open questions or assumptions - [ ] No unresolved contradictions between requirements - [ ] Stakeholders have reviewed and signed off - [ ] Requirements are traceable to user needs ## Anti-Patterns 1. **Solution masquerading as requirement** -- "Use Redis for caching" is a solution, not a requirement. The requirement is "cache frequently accessed data to achieve < 50ms read latency." 2. **Vague requirements** -- "The system should be fast" is untestable. Quantify everything. 3. **Invented precision** -- Turning "must remain responsive" into "p99 < 800ms" without a source or approved assumption creates false certainty. Mark unknown bounds as open questions. 4. **Requirements by committee** -- Too many stakeholders without a single owner leads to bloat. One person owns the requirements doc. 5. **Scope creep via "just one more"** -- Each new requirement has a cost. Evaluate against the backlog, don't just add. ## Related Skills - [problem-framing](../../00-discovery/problem-framing/SKILL.md) -- provides approved direction, non-goals, and open questions when the route is known but the solution direction was fuzzy - [spec-writing](../spec-writing/SKILL.md) -- transforms requirements into detailed specification - [domain-modeling](../domain-modeling/SKILL.md) -- runs in parallel to model the domain - [acceptance-criteria](../acceptance-criteria/SKILL.md) -- creates testable criteria from requirements