A requirement is a stated condition that a product, process, service, system or outcome must satisfy.
Requirements turn needs, laws, goals, standards and constraints into explicit conditions that can guide design and later be checked. “Must support three users”, “must comply with this standard”, “must load within two seconds”, “must preserve privacy” and “should be easy to maintain” are not all the same kind of requirement.
Quick answer: how should requirements be categorised?
- Source: user, law, policy, standard, contract, design, safety, operations?
- Necessity: mandatory, conditional, preferred or optional?
- Type: functional, performance, interface, data, quality, security, operational?
- Scope: which component, workflow, user or jurisdiction?
- Priority: what happens if the requirement is delayed or omitted?
- Verifiability: can conformance be tested objectively?
- Dependency: what other requirements or assumptions does it rely on?
- Acceptance criteria: what evidence counts as satisfied?
- Ownership: who defines, implements and accepts it?
- Change: how is revision governed and traced?
This article complements How to Categorise Constraints, How to Categorise Rules and How to Categorise Standards. Those pages classify limiting or governing structures; this page focuses on explicit conditions a solution must satisfy.
Requirement is not the same as goal
A goal describes a desired future. A requirement specifies a condition that an acceptable solution must meet on the way to that future.
Requirement is not the same as constraint
A constraint limits the solution space. A requirement states what the chosen solution must do or be. Some constraints are converted into requirements, but the distinction remains useful.
Requirement is not the same as rule
A rule governs behaviour under conditions. A requirement expresses a condition for acceptance or operation. A rule may generate one or more requirements.
Stakeholder requirements express needs
Users, customers, operators, parents, learners, maintainers and regulators can each impose different needs on the same system.
Functional requirements describe what must happen
They specify behaviour, capability, transformation or service: calculate, store, display, route, teach, verify or respond.
Performance requirements describe how well
Speed, accuracy, throughput, latency, capacity, reliability and response time are performance dimensions rather than functions themselves.
Interface requirements govern boundaries
They define formats, protocols, inputs, outputs, tolerances and compatibility at the points where systems or people interact.
Data requirements govern representation
Required fields, identifiers, retention, provenance, accuracy, privacy and format may determine whether information can be trusted and reused.
Quality requirements describe acceptable properties
Maintainability, usability, resilience, accessibility and interoperability are often cross-cutting qualities affecting many functions at once.
Safety and rights requirements can be hard gates
Some requirements should not be traded away merely because another option is faster or cheaper. Their authority and non-waivable status should be explicit.
Operational requirements describe real-world running conditions
Staffing, maintenance windows, training, monitoring, backup, support hours and recovery behaviour determine whether a design remains usable after launch.
Mandatory requirements define acceptance
If a mandatory requirement is unmet, the solution should not be represented as fully conforming.
Preferred requirements influence ranking
They add value but can be traded against other preferences when hard conditions are already satisfied.
Conditional requirements activate only in some states
An emergency mode, user type, jurisdiction or threshold crossing may trigger requirements that do not apply during ordinary operation.
Derived requirements preserve traceability
A high-level safety or user need may generate many lower-level design requirements. Each derived condition should point back to the source it serves.
Requirement source determines authority
A statutory requirement, contract term, internal preference and engineering assumption do not carry equal force. Source should never be erased when requirements are consolidated.
Scope should prevent accidental generalisation
A requirement for one user group, country, device or operating state should not silently become universal.
Atomic requirements are easier to verify
Compound statements such as “fast, secure and easy to use” should often be separated so each condition can have its own evidence and acceptance result.
Ambiguous requirements produce ambiguous acceptance
Words such as fast, robust, intuitive and sufficient should be tied to observable criteria where consequence matters.
Verifiability changes requirement quality
A strong requirement makes clear how another competent reviewer could determine whether it has been satisfied.
Verification method should match requirement type
Inspection, test, analysis, demonstration, audit and user evaluation provide different kinds of conformance evidence.
Acceptance criteria are not the same as implementation instructions
A requirement should state what acceptable performance looks like without unnecessarily forcing one design unless the design itself is required.
Over-specification reduces solution freedom
Requirements that dictate unnecessary implementation details can block better alternatives and confuse need with preferred method.
Under-specification hides important boundaries
If critical performance, privacy, compatibility or recovery conditions are missing, a technically completed solution may still fail the real user job.
Conflicting requirements need explicit resolution
Maximum speed, minimum cost, strong privacy and complete flexibility can pull in different directions. Do not hide conflict inside one impossible specification.
Dependencies should be visible
A requirement may rely on another requirement, external standard, interface or data source. Dependency mapping helps explain why a local change can affect distant acceptance criteria.
Priority is not the same as necessity
A mandatory requirement may not need immediate implementation if its feature is scheduled later, while an urgent preferred requirement may deserve near-term attention. Track both dimensions separately.
Requirements change
Law, technology, user needs and system boundaries evolve. Versioning should preserve which requirement set governed each design, test and release.
Change impact begins with traceability
Before changing a requirement, identify the designs, tests, interfaces, risks and dependent requirements linked to it.
Requirements can become obsolete without becoming historically irrelevant
Superseded requirements explain why earlier systems were built and tested as they were. Preserve lifecycle state rather than simply deleting the old record.
AI can extract candidate requirements from documents
Models can identify words such as must, shall, should and may, but wording alone does not determine authority, scope or whether the sentence is genuinely a requirement. Human or governed validation remains important.
A practical requirement record
- requirement ID and text;
- source and authority;
- type;
- mandatory, conditional or preferred status;
- scope;
- priority;
- dependencies;
- acceptance criteria;
- verification method;
- implementation owner;
- acceptance owner;
- linked risks and controls;
- status;
- effective date;
- version and change history.
The deeper idea
Requirements are the bridge between intention and acceptance. They convert broad needs into conditions specific enough that design can proceed and evidence can later show whether the result is genuinely fit for purpose.
To categorise a requirement well is to preserve where it came from, how strongly it binds, what scope it governs, how it will be verified and what other parts of the system must change if the requirement changes.
Final answer
Categorise requirements by source, necessity, type, scope, priority, verifiability, dependency, acceptance criteria, ownership and change state. Keep requirements separate from goals, rules and constraints, write them atomically where possible, and preserve traceability so design, verification and later revisions remain auditable.