Requirements Document Template: Examples, Acceptance Criteria, and Change Log
Published:
Last Updated:
Category: Marketing DX, Marketing Strategy
Authors: Shusaku Yosa
A requirements document helps stakeholders judge the necessary work and its completion conditions in the same terms. Headings alone are insufficient when entries say only “user-friendly” or “migrate existing data.” Connect required behavior, conditions, verification, ownership, and evidence through requirement IDs. Keep undecided items visibly undecided. The screens, volumes, and performance values below are fictional examples.
The role of requirements: RFPs, design, and contract documents
An RFP seeks comparable proposals; requirements turn needs and constraints into stakeholder agreements. Design develops the implementation, but technical constraints such as supported environments or existing-system connections may themselves be requirements. The distinction between what and how is useful, not an absolute prohibition on technical conditions.
IPA’s explanation of requirements definition describes analyzing user needs and reaching agreement. Requirements may develop before supplier selection or continue afterward; there is no single sequence that starts only after contracting.
Regardless of who drafts, allocate reviews of business need, technical feasibility, and verification methods. Ask for unfamiliar wording to be explained through capability and limits. Do not sign off while technical feasibility remains nobody’s responsibility.
IPA’s model transaction and contract materials provide a reference on documents and responsibilities. Actual contractual scope and precedence require agreement between the parties; presence or absence of one row does not alone settle legal responsibility.
A seven-section outline and a copyable requirements table
Use these seven sections as a starting point. For an inapplicable topic, decide whether it is unnecessary or addressed elsewhere. Choose the detail needed for agreement and verification rather than a supposedly standard page count.
Section | Contents | Traceable reference |
|---|---|---|
1 Overview | Purpose, scope, exclusions, assumptions, approvers | Scope and decisions |
2 Business | Users and current / future workflow | Workflow and roles |
3 Functional | Required operations and behavior | Requirement and test IDs |
4 Screens | Display, inputs, navigation, errors | Screen inventory and checks |
5 Data | Meaning, transfer, retention | Definitions and migration population |
6 Non-functional | Performance, security, availability, environments | Measurement and operating conditions |
7 Migration and operation | Move, stop, recover, operate | URL map, procedures, handover |
The requirements table should include ID, user or rationale, behavior and conditions, priority, acceptance criteria, verification method and test ID, responsible reviewer, evidence, and version or status. Use a separate matrix when one requirement maps to several tests. A goal such as increasing inquiries from 30 to 60 monthly belongs in the business background, not as an outcome guaranteed by system delivery alone.
Testable functional and non-functional examples
Requirement / rationale | Required behavior or condition | Acceptance and test | Owner / evidence / status |
|---|---|---|---|
F-01 / separate editing and approval | Editors save drafts; approvers publish the approved version | T-01: editor cannot publish. T-02: approver can publish the specified version | Business and technical reviewers / operations and version record / v1 pending |
D-01 / preserve information | Migrate the agreed 480 articles | Reconcile IDs, text, images, publication state, and mapped URLs | Migration owner / differences and review records / v1 test pending |
N-01 / search response | Environment v1, agreed 10,000-record dataset, 100 concurrent users, 10-minute load test | Response-time p95 at most 800 ms for the agreed measurement population; error criterion remains TBD-02 | Technical owner / script version, environment, logs / final acceptance held |
For F-01, test prohibited actions as well as permitted ones. Identify role, version, and the distinction between saving and publishing. Add necessary error, permission, and retry cases. A number or feature name does not make a requirement testable by itself.
The 10,000 records, 100 concurrent users, ten minutes, and 800 ms are fictional, not recommended defaults. p95 is the 95th percentile of the measured response times. Fix the timing boundary, success and failure treatment, load pattern, data, cache, repeat runs, and environment. Do not grant final acceptance while the error-rate criterion remains undecided.
For clear, feasible, verifiable requirements and verification matrices, see NASA’s Systems Engineering Handbook appendices. This is a reference from another domain, not a source prescribing these performance numbers or Japanese contract terms.
Google’s explanation of LCP distinguishes the largest contentful paint from complete page loading. Its good threshold of 2.5 seconds or less concerns the 75th percentile of real-user observations, assessed by device category. It is not a promise that every page fully loads within 2.5 seconds over 4G. Keep laboratory checks and field evaluation separate.
Migration, legacy URLs, and post-launch operations
D-01 does not pass merely because the destination contains 480 articles. Reconcile target IDs, text, images, publication states, and mapped URLs, and define the treatment of excluded content. Separate full-population checks from sample content checks, recording sample selection and its limits.
Legacy URL | Content decision | Response or destination | Verification |
|---|---|---|---|
/service/ | Retain at the same URL | 200 and self-referencing canonical | Content and internal links |
/old/service-a | Move equivalent content | 301 or 308 to /service-a | Final URL, content, new canonical |
/old/guide-a and /old/guide-b | Consolidate related content | 301 or 308 to relevant combined page | Preserve both information needs |
/old/expired-event | Retire without relevant replacement | 404 or 410 | No blanket redirect to unrelated homepage |
Google Search Central’s site-move guide explains relevant permanent redirects and 404/410 for removed content without a replacement. Do not turn blanket homepage redirection into a generic requirement.
Migration requirements also cover cleanup, incremental updates, stopping the old environment, recovery, and the operating owner. Consider data received after launch when planning rollback. Agree relevant backup, access, retention, and accessibility topics with the appropriate specialists.
Buyer and technical reviews, and acceptance checks
Business reviewers check user context, information, roles, and exclusions. Technical reviewers check feasibility, dependencies, permissions, performance, security, and test methods. Involve operations, information governance, or accessibility expertise where needed. A short checklist is an entry point, not a completeness guarantee.
Acceptance records should identify the version, environment, data, procedure, expected and actual results, evidence, and reviewer. Distinguish pass, untested, fail, and any conditional treatment. Conditional progress needs remaining conditions, a deadline, and an authorized decision. Untested is not passed.
When a mismatch appears, distinguish misunderstanding, implementation defect, missing requirement, and new scope. Do not automatically assign undocumented work to the buyer. Check the underlying agreement, proposal, and contract references, and avoid requiring a single operational contact to make every specialist judgment.
Manage open decisions and approved changes
ID / version | Open question or change | Decision owner / timing | Impact and status | Related requirements |
|---|---|---|---|---|
TBD-01 / v1 | Supported browser range | Buyer owner and technical lead / before it becomes a design premise | Environment and test population / open | N-02 |
TBD-02 / v1 | Load-test error acceptance criterion | Both technical leads / before acceptance tests are fixed | Performance evaluation and final acceptance / open | N-01 |
CR-02 / v1 | Change single approval to multiple stages | Authorized parties / after revised estimate review | Reassess effort, tests, dates / awaiting approval | F-01, T-01, T-02 |
For each unknown, state what decision enables which next activity. If proceeding on an assumption, share the consequences if it proves wrong and a review date. Escalate missed decision dates with their downstream effects.
For changes, retain the reason, affected requirements, cost, dates, dependencies, acceptance method, estimate, and decision. Changes need not always occur, but a process does not remove commercial negotiation or authorization when they do. Keep the previous baseline and revision history; update the current version only with adopted conditions. Start with three important requirements and fill in behavior, verification, evidence, and owner. Visible unknowns are more useful than invented certainty.
For the next step, use How to Write an RFP: A Filled Example with Mandatory Criteria and a Scoring Sheet; Website Redesign Planning: Phases, a URL Migration Map, and Launch Checks; How to Write a Creative Brief: A Filled Example for the Problem, Audience, and Budget.
