Quality and requirements
What is a requirement? Definition and examples
Also: PRD (product requirements document)
In short
A requirement describes what a product or system must do and why, from the point of view of those who use it. Good requirements are clear, testable and linked to a goal. When a requirement changes, tickets, code and documents have to follow.
Why it matters: Requirements connect a decision with the work that carries it out.
- 01
Decision
A goal or priority changes
- 02
Requirement
Updated, with its reasoning
- 03
Tickets
Closed, changed or newly created
- 04
Code and agents
Follow the new state
Why does Requirement matter for your company?
A good requirement names the problem, the desired result and the conditions to check it against. It says what and why, and leaves the how to the team. Whether it sits in a ticket, a section of a PRD or a short note matters less.
Requirements change because markets, customers and strategies change. The danger is when only the document is updated: tickets, code and AI agents then carry on with the old state. Every change therefore needs a reason, an owner and evidence of where it was carried out.
Example: The requirement changes, the code does not
After the decision “Strategy 2027: focus on the DACH mid-market, no US expansion” the product team removes the requirement “prices in US dollars” from the concept. Weeks later it gets built anyway, because the ticket is still open, and a coding agent adds the matching tax logic.
From then on the team links every requirement to the tickets and code that carry it out. When a requirement changes, it sees at once which tickets to close and which changes to stop. The owners decide before more is built.
3 common mistakes to avoid
Describing the solution, not the problem
“We need a dashboard” is not a requirement. Describe which decision it should improve.
Changing only the document
A changed requirement without updated tickets is a silent drift. Update the work, not just the text.
Requirements without reasons
Without the “why” nobody can weigh things up when something changes. Record the reason, for AI agents too.
Step by step
- 1
Name problem and goal
Who has which problem, and how will you know it is solved?
- 2
Make it testable
Add acceptance criteria that can be checked with yes or no.
- 3
Link it to the work
Link every requirement to the tickets and code that carry it out.
- 4
Follow through on changes
When a requirement changes, review every linked ticket, document and AI agent.
Bring one important decision.
In 30 minutes with Marc or Simon we show where your work drifts from the decision today.
Meet the Company BrainRead on in the PM Lab
Articles that go deeper.
Related terms
- Acceptance criteria →Acceptance criteria are testable conditions a piece of work must meet to count as done.
- Definition of Done →The Definition of Done is a shared checklist every piece of a team's work must meet before it counts as finished.
- Organisational memory →Organisational memory is what a company knows and keeps about itself: decisions, experience and reasons, independent of individual people.
- Single Source of Truth →A single source of truth is the one source that counts as authoritative for a given piece of information, such as prices, goals or a decision.