Article
Writing a Requirements Document People Actually Use
A requirements document is not a formality. It is the tool that makes sure everyone pictures the same thing before money is spent.
What it genuinely needs
- Business goal. What must change, and how success is measured.
- The current process, as it really is, including the embarrassing steps.
- The intended process, with roles and decision points.
- Data. What is stored, where it comes from, who may see it.
- Integration. Which systems must connect and what data moves.
- What is out of scope. This list matters as much as what is in scope.
- Acceptance criteria. How we know the work is done.
Write sentences, not technical terms
Requirements should read as sentences a business person can check: "Every new website lead must have an owner within 15 minutes." A sentence like that can be tested at handover.
Common traps
- Writing the solution instead of the need. "We need field X" often hides the real requirement.
- Gathering requirements only from managers, without asking the people doing the work.
- A wish list with no priority. Mark items must, should and later.
One decision maker
A project with five equal voices goes in circles. Name one person who decides when opinions differ.
Use it for testing
This document becomes the basis for testing before go-live. See acceptance testing before go-live and the readiness checklist.