01 — Requirements and Planning Checklist#

Verify that the project solves a validated problem, has measurable goals, clear scope, testable requirements, realistic delivery plans, and defined API/frontend requirements.

Scope: Shared / cross-cutting. This file is one part of the 01_Requirements_and_Planning.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

• Project / product:
• Release / version / environment:
• Scope and applicable jurisdictions / markets:
• Reviewer / owner:
• Review date:
• Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

1. Copy this reusable checklist into project-specific review records; leave the shared template unchecked.
2. Mark [x] only after verifying a check with a linked requirement, decision record, research finding, or other evidence. Record failed or inapplicable items (including N/A rationale) in project-specific review notes or an issue tracker, keyed by REQ ID.
3. Assign owners and deadlines for unclear requirements, unvalidated assumptions, unresolved dependencies, and other blockers.
4. Review the plan when the project scope, audience, API contracts, interface requirements, or external constraints change. These checks support project planning; they do not replace expert legal, security, or accessibility review.

Goals and success criteria#

• REQ-001 The project problem statement identifies the user or business need, current pain point, and intended outcome without assuming a predetermined solution.
• REQ-002 Target users, customer groups, service operators, and representative usage contexts are identified from research or documented assumptions.
• REQ-003 Existing user research, analytics, support data, or comparable evidence informs the proposed solution.
• REQ-004 Critical unvalidated assumptions are recorded with an owner, method of validation, and target review date.
• REQ-005 Measurable product objectives and outcomes are agreed with accountable stakeholders.
• REQ-006 Success metrics define units, baseline, target, measurement period, data source, and reporting owner.
• REQ-007 Leading indicators and longer-term outcomes are distinguished so that activity is not mistaken for user value.
• REQ-009 Target markets, supported languages, expected traffic, and launch constraints are written down.
• REQ-010 Business, user, operational, and technical goals are prioritized when trade-offs arise.
• REQ-011 Outcomes and metrics are reviewed with users or their representatives where feasible.
• REQ-012 A minimum viable release hypothesis states what will be learned and what evidence would justify expanding or stopping the work.

Scope and stakeholders#

• REQ-013 A named sponsor/product owner is accountable for the product goal and final scope decisions.
• REQ-014 A stakeholder map includes users, delivery teams, support, operations, vendors, data owners, and affected business units.
• REQ-015 Decision rights, review responsibilities, approvers, and escalation paths are explicit.
• REQ-016 In-scope and out-of-scope capabilities are listed for the planned release.
• REQ-017 The system boundary and adjacent business processes, including manual or offline steps, are documented.
• REQ-018 Must-have, should-have, could-have, and deferred work are prioritized using consistent criteria.
• REQ-019 The planned first release is small enough to validate important assumptions within the available time and resources.
• REQ-020 Dependencies on other internal teams, procurement, vendors, or external approvals have named owners.
• REQ-021 User groups with disabilities, low connectivity, limited digital literacy, or other access barriers are considered in scope decisions.
• REQ-022 Regulated activities, contractual commitments, and relevant legal or policy review needs are flagged for specialist owners.
• REQ-023 Data ownership, personal-data handling, hosting constraints, and third-party access are identified early.
• REQ-024 Budget, staffing, platform constraints, and commercial commitments are explicit.
• REQ-025 Stakeholder disagreements and scope trade-offs have documented resolutions or accountable escalation.
• REQ-026 Scope changes follow a transparent impact-review and approval process.

Requirements and acceptance criteria#

• REQ-027 Each requirement has a unique identifier, concise description, owner, priority, and source or rationale.
• REQ-028 User needs are written independently from proposed implementation where feasible.
• REQ-029 User stories or equivalent items map to one or more validated user needs or business objectives.
• REQ-030 Functional requirements describe observable inputs, outputs, state transitions, and relevant business rules.
• REQ-031 Non-functional requirements specify measurable performance, availability, security, privacy, accessibility, maintainability, and support needs as applicable.
• REQ-032 Requirements clearly distinguish mandatory constraints from optional preferences.
• REQ-033 Each requirement is necessary, feasible, internally consistent, and understandable to both stakeholders and implementers.
• REQ-034 Vague terms such as 'fast', 'secure', 'intuitive', or 'scalable' are replaced with measurable or inspectable criteria.
• REQ-035 Every priority requirement includes testable acceptance criteria, including expected positive behavior.
• REQ-036 Important negative, boundary, failure, and recovery cases have acceptance criteria.
• REQ-037 Roles, permissions, and tenant boundaries are specified for protected operations.
• REQ-038 Required data fields, ownership, lifecycle, retention, import/export, and deletion behavior are described where relevant.
• REQ-039 External system interfaces and data handoffs have explicit inputs, outputs, responsibilities, and error handling expectations.
• REQ-040 Assumptions, unresolved questions, exclusions, and known conflicts are recorded with owners.
• REQ-041 Priority requirements are traceable to acceptance tests, design decisions, or verification methods.
• REQ-042 Stakeholders review and approve the current requirements baseline before major implementation or handoff.
• REQ-043 Changes to baselined requirements record the reason, impact on scope/cost/schedule, approver, and dependent artifacts.

Dependencies and delivery plan#

• REQ-044 The delivery plan has milestones with owners, approximate sequencing, and objective completion criteria.
• REQ-045 Technical discovery, proof-of-concept work, and unresolved high-risk assumptions are scheduled early.
• REQ-047 Tasks are sized for observable progress, with high-uncertainty work broken down or time-boxed.
• REQ-048 Capacity assumptions, key roles, specialist access, and availability are checked against the roadmap.
• REQ-049 Estimates distinguish evidence-based commitments from rough forecasts and show major uncertainties.
• REQ-050 Risk registers document likelihood, impact, mitigation, owner, trigger, and review date for material risks.
• REQ-051 The plan allows time for discovery, accessibility, security/privacy reviews, integration, migration, documentation, and operational handover.
• REQ-052 Technical spikes or prototype findings are converted into decisions or revised requirements.
• REQ-053 Delivery progress is reviewed against outcomes and completed work, not only task counts.
• REQ-054 A regular feedback and prioritization cadence includes stakeholder demos or user validation where useful.
• REQ-055 Change-control practices allow reprioritization while making impact on release commitments visible.
• REQ-056 The planned release contains rollback, support, training, and communication ownership where applicable.
• REQ-057 Agreed readiness and sign-off criteria identify who can block or approve proceeding.

Release gate#

• The scope, objective, target users, and success criteria have been reviewed and approved by the accountable product owner or sponsor.
• All release-critical requirements have unambiguous acceptance criteria, identifiable owners, and a feasible verification approach.
• High-impact assumptions, dependencies, external approvals, constraints, and delivery risks are resolved or have explicitly accepted, time-bound mitigation plans.
• API and frontend requirements are agreed by relevant consumer/provider and user-experience owners, or documented as genuinely not applicable.
• The delivery plan has an accountable owner, realistic milestones, a process for changes, and explicit readiness/sign-off responsibilities.

Domain-specific approval rule: Do not approve a release plan with undefined success criteria, conflicting critical requirements, unowned blocking dependencies, or unapproved material scope or risk decisions. A planning sign-off is not proof that implementation or release tests have passed.

Trusted references and scope#

The checklist translates the following primary guidance into project-planning verification tasks; it does not reproduce the referenced standards or imply formal certification.

• NASA Systems Engineering Handbook — requirements definition — clear, traceable, feasible, verifiable requirements and design constraints.
• NASA Systems Engineering Handbook — requirements quality and traceability — uniqueness, consistency, testability, and verification planning.
• GOV.UK Service Manual — learning about user needs — evidence-based needs and traceability into delivery work.
• GOV.UK Service Manual — performance metrics — purpose, benefits, measurements, and iteration.
• GOV.UK Service Manual — deciding on priorities — transparent prioritization across features and other work.
• The Scrum Guide (2020) — product goal, product backlog, and definition of done (use if relevant to the team's delivery method).
• OpenAPI Specification 3.2.1 — standard interface description for HTTP APIs (when applicable).
• W3C — WCAG 2.2 — testable web accessibility criteria (when applicable).

Applicability: Requirements management practices vary with project size, industry, development method, and jurisdiction. Do not automatically impose Scrum or government-service requirements on other teams; tailor the controls to actual risks and users.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

• Test focus: acceptance criteria, negative scenarios, and scope changes; include shared/cross-team controls where applicable.
• Cross-stack: Cucumber + Playwright.
• Python: pytest-bdd + pytest; for pytest-based suites, run python -m pytest -q.
• TypeScript: Cucumber.js + Playwright + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
• JavaScript: Cucumber.js + Playwright + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
• Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

• spec-driven-development — Check requirements against executable acceptance criteria (addyosmani/agent-skills, 116,378 repo stars).
• writing-plans — Identify missing verification steps and owners (obra/superpowers, 316,578 repo stars).
• breakdown-test — Derive negative and edge-case test scenarios (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the shared / cross-cutting scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.