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: Backend / API-specific. 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.

Dependencies and delivery plan#

• REQ-046 Dependencies and critical-path constraints are tracked, including API access, domain approvals, design assets, and vendor timelines.

API Checks#

• REQ-058 List every planned API consumer, provider, integration purpose, trust boundary, and accountable owner.
• REQ-059 Define the API's supported operations, resource names, identifiers, methods, and expected workflows before development.
• REQ-060 Specify request/response contracts, required and optional fields, validation rules, types, examples, and error semantics.
• REQ-061 Use an agreed machine-readable API description such as OpenAPI when suitable, with documented version and ownership.
• REQ-062 Define authentication, scopes, object-level and role-based authorization requirements for each protected operation.
• REQ-063 Specify data classification and fields permitted for each consumer; prohibit unintended sensitive-data exposure.
• REQ-064 Document idempotency, timeouts, retries, pagination, quotas, and rate-limit expectations where relevant.
• REQ-065 Define consistency, concurrency, and transactional behavior for conflicting or repeated state-changing requests.
• REQ-066 Document versioning, deprecation, backwards compatibility, and consumer migration expectations.
• REQ-067 Specify third-party API dependencies, contract limits, service-level expectations, cost, and fallback behavior.
• REQ-068 Define webhook/callback ownership, event payloads, authenticity requirements, and failure handling when used.
• REQ-069 Agree API acceptance examples and contract test ownership with both producer and consumer.
• REQ-070 Define API observability requirements for metrics, failures, tracing identifiers, and data-safe logs.

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 API and service behavior 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 backend / API 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.