Two questions about any system
When you describe what something should be, you are really answering two different questions. The first is “what should it do?” The second is “how well should it do it, and under what conditions?”
Functional requirements answer the first. Non-functional requirements answer the second. A system can meet every functional requirement and still fail its users if the second set is ignored.
Functional requirements
A functional requirement describes a behaviour, function or service. It usually has the shape “the system shall do X when Y happens.” Everyday examples:
- A kettle shall switch itself off when the water boils.
- A booking website shall let a user choose a date and confirm a reservation.
- A data logger shall record a temperature reading at a configured interval.
- A door controller shall unlock when a valid card is presented.
These are the features people usually think of first, and they are generally the easier ones to write and to test: either the kettle switches off or it does not.
Non-functional requirements
Non-functional requirements describe qualities and limits. They are sometimes called quality attributes or “the ilities”, because many end that way. Common categories include:
- Performance. How fast, how many at once, how much capacity.
- Reliability and availability. How long it runs without failure, how quickly it recovers.
- Safety. What hazards must be controlled and how.
- Security. Who may access what, and how data is protected.
- Usability. How easily the intended users can learn and operate it.
- Maintainability. How easily it can be repaired, updated or extended.
- Environmental limits. Temperature, humidity, vibration, power supply and similar conditions.
- Compatibility. Which other equipment, formats or systems it must work with.
For the kettle, “switches off when water boils” is functional. “Remains safe to touch on the outside during normal use” and “works on the local mains supply” are non-functional. For the booking site, “confirms a reservation” is functional, while “shows the confirmation within a few seconds under normal load” and “works on a phone screen” are non-functional.
Why the second group is easy to miss
People describe what they want in terms of actions, so quality expectations often stay unspoken. Nobody says “the kettle should not fall apart after a month” until it does. These qualities also tend to affect the whole design rather than one feature, which means discovering them late can force expensive rework. A response time that is too slow, for example, may depend on the overall architecture rather than on any single piece of code.
Many serious engineering failures involve qualities rather than missing functions: something that worked but was too weak, too hot, too slow or too hard to use correctly. Studying engineering failures tends to show how often an unstated limit sits behind the problem.
Making non-functional requirements testable
The main risk with quality requirements is vagueness. “The system shall be fast” or “easy to use” cannot be verified. Rewrite them with something observable.
| Vague | More testable |
|---|---|
| Fast | A page loads within a stated time on a stated connection, for a stated number of users |
| Reliable | Runs for a stated period between failures under stated conditions |
| Easy to use | A new user completes a defined task within a stated time without help |
| Rugged | Survives a stated drop height or temperature range |
The numbers in a real project come from the stakeholders, standards and measurements, not from a general article, so treat the table as a pattern rather than a set of values. If you cannot name a number yet, record the question openly, for example “response time target to be agreed”, rather than leaving a vague word in its place. Related habits are covered in the guidance on writing requirements.
Trade-offs between qualities
Qualities often pull against each other. Making something more secure may make it less convenient. Adding margin for reliability may add cost and weight. Higher performance may use more power. Because these conflicts are real, they should be surfaced and decided deliberately. Simple decision matrices are one way to compare options against weighted qualities, and design margins are a common tool for reliability and safety questions.
Some non-functional requirements, such as safety and regulatory ones, are not negotiable in the way convenience features are. Rules vary by country and industry, so follow the standards and the qualified professionals that apply to your work.
A small worked example
Imagine a handheld device that measures a room’s temperature and shows it on a display.
Functional requirements might be:
- Measure the temperature at regular intervals.
- Show the latest value on the display.
- Warn the user when the value passes a limit they set.
Non-functional requirements might be:
- The displayed value shall be accurate to within a stated tolerance across the stated operating range. This connects to measurement uncertainty.
- The device shall run on its batteries for a stated period.
- The display shall be readable in normal indoor lighting.
- The enclosure shall withstand a stated everyday knock.
Notice that the second list drives some of the biggest design decisions: the sensor choice, the battery size and the housing. Leaving it out would not just lower quality; it would leave the designers guessing.
Practical tips
- Ask, for every functional requirement, “how fast, how often, how many, under what conditions?”
- Walk through a checklist of quality categories during stakeholder interviews so unstated expectations come out early.
- Keep each requirement to one idea so each can be tested separately.
- Do not turn a design choice into a quality requirement. “Use a particular database” is a design decision, not a performance requirement.
- Review the list with the people who will operate, install and maintain the product, not only the buyers.
Treating both kinds with equal care gives the team a complete picture: what the system does, and the standard it must meet while doing it.