Requirement Gathering Checklist

The product manager builds a stakeholder map covering the executive sponsor, business owner, end-user representatives, engineering lead, design lead, and any compliance / security reviewers. Note who has sign-off authority vs. who is consulted — confusing the two is the most common reason requirements get re-litigated mid-sprint.

Capture 2-4 measurable outcomes the project must move — activation rate, time-to-onboard, support ticket volume, ARR retention. Vague objectives ("improve UX") are the leading cause of scope creep; if you can't write the success metric as a number with a target, push back before continuing.

Determine whether the feature touches PHI (HIPAA), cardholder data (PCI), EU resident data (GDPR), or California residents (CCPA/CPRA). Flag accessibility scope (WCAG 2.1 AA) for any public-facing UI. Compliance constraints become non-functional requirements that change the design — surfacing them late is expensive.

Run 30-45 minute 1:1 interviews with each stakeholder group. Use open-ended prompts ("walk me through how you do this today") before closed ones. Record with consent; have a second interviewer take notes so the lead can listen. Aim for 5-8 interviews before synthesizing.

Facilitate a story-mapping or event-storming session with engineering, design, and the business owner. Use the "As a [persona], I want [outcome], so that [value]" format. Capture the workshop board (Miro, FigJam) as the source artifact for the next step.

Send a targeted survey (Typeform, Google Forms, in-app) to validate that interview themes generalize. Keep it under 8 questions; mix Likert with one open-ended. Aim for n≥30 responses before treating results as signal, not anecdote.

Use Given/When/Then or numbered AC under each user story in Jira / Linear. Each criterion is testable as a single assertion — if QA can't write a test from it, it's not done. Avoid soft verbs like "support" or "handle" without specifying inputs and outputs.

Cover performance (p95 latency targets), availability (SLO), security (authn/authz model, encryption at rest/in transit), accessibility (WCAG 2.1 AA), and observability (what gets logged/metricked). NFRs ignored at requirement time become production incidents at launch.

List entities, fields, retention rules, and PII classification. Identify upstream/downstream systems (CRM, billing, analytics) and the contract with each — REST endpoint, event topic, webhook. New external dependencies require vendor security review; flag them now, not in code review.

The tech lead reviews for technical feasibility and rough sizing (T-shirt or story points). Design reviews for UX coherence. Capture concerns as comments on the requirements doc; resolve or defer each one explicitly before sign-off.

AppSec reviews the threat model — STRIDE, data flow, trust boundaries. Privacy reviews data minimization, retention, lawful basis for processing, and DPIA need under GDPR. Required separately when the regulatory-data answer earlier was Yes.

Tag each requirement Must / Should / Could / Won't. The Must list is the MVP; Should items go into v1.1 backlog; Won't is documented to close the loop with stakeholders who asked for them. If the Must list exceeds engineering's capacity estimate, negotiate now.

Resolve each comment with a change to the doc or a written rationale for keeping current language. Track the diff so reviewers can re-review just the deltas, not the entire document.

Each Must-have requirement becomes an epic; each acceptance criterion becomes a story or task. Link back to the requirements doc URL on every epic so future readers can trace the origin without asking around.

Document who can approve scope changes mid-build, what triggers a full re-review (e.g., any change to NFRs, data model, or compliance scope), and where change requests are filed. Without this, every "small tweak" becomes a side-channel Slack ask.