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.

Pull existing user interviews, support ticket themes, NPS verbatims, and competitor teardowns. Don't restart research that's already been done — check the research repo (Dovetail, Notion, Confluence) before scheduling new interviews.

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.

Cluster interview notes, workshop output, and survey results into 3-7 themes. Each theme should have a problem statement, the evidence behind it (quotes, counts), and a candidate scope decision (in / out / later).

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.

An explicit out-of-scope list prevents "I thought that was included" arguments at the demo. Include known constraints — browser support matrix, mobile OS minimums, data residency, third-party rate limits.

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.

The executive sponsor and business owner sign off on the final requirements document. Verbal "sounds good" in a Slack thread is not sign-off — get a name attached to the artifact in writing.

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.

Walk the engineering team through the requirements, NFRs, and out-of-scope list. Confirm the tech lead has identified a technical design owner for the architecture doc that follows. Sprint planning for sprint 1 happens in this same week.