What a requirement is
A requirement is a statement of something a product, system or piece of work must do, or a quality it must have, written so that people can later check whether it was met. “The pump must deliver water” is a wish. “The pump must deliver at least a stated flow at a stated pressure” is a requirement, because someone can measure it.
Requirements engineering is the set of activities used to find, write down, agree, change and check those statements. It applies to software, hardware, buildings, processes and services alike. The vocabulary differs between industries, but the underlying problem is the same: the people who want something and the people who build it must share an understanding of what “done” means.
Why requirements matter
Many project problems are not caused by poor construction. They come from building something that was misunderstood, or from discovering late that two people had different pictures of the goal. Fixing a misunderstanding on paper is typically far cheaper than fixing it after parts have been made or code has been shipped, which is the main reason teams spend time on requirements early.
Requirements also serve several quieter purposes:
- They give the team a shared reference when opinions differ.
- They give testers something concrete to check against.
- They help estimate effort, because vague goals cannot be sized.
- They record what was agreed, which matters when a customer later remembers it differently.
From needs to requirements to design
It helps to separate three layers that are often blurred together.
Needs are what the users, customers or the organisation want to achieve, usually in their own words: “I want to stop checking the tank by hand.” Requirements are the translation of those needs into statements the builders can work with: “The system shall report the tank level to a display in the control room.” Design is the chosen way to meet the requirements: which sensor, which wiring, which software.
Keeping these layers apart protects you from a common trap, which is writing a design choice as if it were a requirement. If the requirement says “use an ultrasonic sensor”, you have closed off alternatives before anyone compared them. A good requirement says what is needed and leaves the how open unless there is a real reason to fix it. The broader engineering design process picks up from there, weighing options against the requirements.
Large systems repeat this translation several times. System-level requirements are broken down into requirements for subsystems and components, each level adding detail. Drawing system boundaries early helps, because you cannot say what a system must do until you have said what is inside it and what is outside.
The main activities
Requirements work is not a single phase. It usually involves these activities, often overlapping:
- Elicitation. Learning what people need, through stakeholder interviews, observation, workshops and reading existing documents.
- Analysis. Spotting conflicts, gaps and unrealistic demands, and separating essential needs from preferences.
- Writing. Expressing each requirement clearly and testably. Good habits for writing requirements are covered on their own, but the short version is: one idea per statement, plain words, something you can check.
- Agreement. Having the people affected review and accept the result.
- Change control. Handling the new ideas that inevitably appear. Without a process for this, scope creep tends to follow.
- Verification. Showing that the finished work meets each requirement, through test, inspection, analysis or demonstration.
Kinds of requirement
Requirements are often sorted into what a system does and how well it must do it. The first group is functional: “the system shall log each login attempt.” The second covers qualities such as speed, reliability, safety, usability and maintainability, usually called non-functional requirements. Both matter. A system can do every listed function and still be unusable if it is too slow or too fragile.
There are also constraints, such as a budget, a deadline, a required interface, a regulation or an environment the product must survive. Constraints are not negotiable in the same way as preferences, and they deserve to be recorded just as carefully. Rules and standards vary by country and industry, so follow the ones that apply to your own work rather than assuming a general guide covers them.
Closing the loop with testing
A requirement that cannot be verified is a hope. Each requirement should come with an idea of how it will be checked, and that idea is worth considering when the requirement is written, not after the product exists. Acceptance criteria turn a requirement into a pass-or-fail condition for a particular piece of work, and requirements traceability keeps a visible link from each requirement to the design elements and tests that cover it, so that nothing is quietly dropped.
Different test levels check different things. Unit tests and integration testing look at parts and their connections, while system-level tests ask whether the whole thing meets the original requirements. In hardware, prototype testing plays a similar role. Quality assurance, in turn, is partly about making sure this checking is planned and actually done.
Common problems
Some patterns recur in almost every organisation:
- Vague words. “Fast”, “user-friendly” and “robust” mean different things to different readers.
- Hidden assumptions. Things everyone “obviously” knows turn out not to be shared.
- Missing stakeholders. The people who maintain, install or support a product are often forgotten until late.
- Solutions disguised as requirements. As above, this narrows options too early.
- Requirements that never change. Needs shift, and a process that cannot absorb change tends to be bypassed.
Keeping it proportionate
The amount of formality should match the risk. A small internal tool may need a short list agreed in a conversation. A medical, aviation or structural project may be expected to follow detailed, formal processes set by regulators and standards bodies, and in those cases qualified professionals and the applicable rules decide what is needed. This article is general background, not a substitute for them.
Whatever the scale, the useful habit is the same: write down what is needed in words others can check, agree it with the people affected, and keep it connected to the design and the tests as the work moves along.