Functional requirements describe what a web application must do. Non-functional requirements describe the conditions under which it must do it. A system can perform every listed function and still fail the business if it is too slow, difficult to recover, inaccessible to the intended users or unable to handle the expected volume.
Both types belong in the same requirements process. Separating them helps a business ask better questions, assign the right specialists and write testable acceptance criteria.
Functional requirements describe observable behaviour
A functional requirement connects a user, an action, data and an outcome. It may describe creating a case, approving a request, generating an invoice or importing records from another system.
A useful functional requirement normally states:
- which role performs the action;
- what starts the process;
- which data is entered, read or changed;
- which business rules apply;
- what happens in normal and exceptional conditions;
- what result is recorded or communicated.
“The system shall support approvals” is too broad. “A regional manager can approve or reject an expense claim assigned to their region, must provide a reason when rejecting it, and cannot approve their own claim” is much closer to something a team can design and test.
Non-functional requirements describe quality and operating conditions
Non-functional requirements cover characteristics such as performance, availability, security, accessibility, recovery, auditability and maintainability. They should not be written as aspirations such as “fast”, “secure” or “easy to use”. Those words create agreement in a meeting but disagreement at acceptance.
Useful categories include:
| Area | Questions for the business |
|---|---|
| Performance | Which tasks are time-sensitive, and what response is acceptable in normal and peak conditions? |
| Capacity | How many users, records, files or transactions must the system support now and during expected growth? |
| Availability | When must the service be available, and which interruptions would materially affect operations? |
| Recovery | How much recent work could the business afford to recreate, and how quickly must a critical service return? |
| Security | Which roles and data require stronger controls, review or separation of duties? |
| Accessibility | Which users, devices and assistive technologies must be supported? |
| Auditability | Which decisions and changes must be traceable, by whom and for how long? |
| Maintainability | How will the system be updated, tested, monitored and transferred to another support team? |
Functional and non-functional requirements interact
The two categories are not independent. “Generate a report” is functional. “Generate the monthly report for 100,000 records within the agreed reporting window without blocking normal users” adds the operating conditions. “Allow a user to upload a document” is functional. File size, scanning, permitted formats, retention and access controls are non-functional or supporting constraints.
Review each important function against the qualities that matter. Critical payment, approval and data-import workflows usually need stronger requirements for reliability, traceability and recovery than a low-risk informational screen.
Distinguish requirements from constraints
A constraint limits the solution rather than describing the required outcome. Examples include a mandated identity provider, an existing hosting agreement, a browser that must be supported or a fixed date when another system will be withdrawn.
Record constraints separately and explain their reason. Otherwise a temporary preference may be treated as permanent architecture. A supplier should be able to challenge a constraint if it creates unnecessary cost or risk, while still respecting genuine business, contractual or compatibility needs.
Make non-functional requirements measurable
Not every requirement needs a single universal number. It does need a clear method of verification. A performance requirement may define a representative workflow, test data, expected load and acceptable response. A recovery requirement may define the systems included, the restoration exercise and the evidence required.
Use ranges and scenarios where precision would be artificial. For example, define normal and peak operating conditions rather than inventing a very large capacity figure “for the future”. Unsupported targets can increase cost without improving the business outcome.
Prioritise by business impact
Requirements should not all be labelled critical. Prioritise according to the harm caused if the condition is not met. A practical assessment considers:
- whether a core process stops;
- whether data could be lost or exposed;
- whether customers are prevented from completing an important action;
- whether a workaround exists and how sustainable it is;
- whether the requirement is essential for launch or can be improved later.
This creates a more useful delivery conversation than marking every feature as “must have”.
Connect requirements to acceptance evidence
Each important requirement needs a way to prove it has been met. The evidence will differ:
| Requirement | Possible acceptance evidence |
|---|---|
| A role cannot approve its own request. | Permission tests using separate requester and approver accounts. |
| A batch import handles the expected peak file. | Recorded test with representative data and agreed completion criteria. |
| A critical service can be recovered. | A supervised restoration exercise and documented result. |
| The interface supports the agreed accessibility needs. | Automated checks, keyboard testing and appropriate manual review. |
| Changes to sensitive records are traceable. | Audit-log scenarios covering creation, editing, deletion and access permissions. |
Do not postpone all non-functional testing until the final week. Performance, recovery and security-sensitive design can be expensive to correct after the architecture is fixed.
Common mistakes
- Writing only features: the system works in a demonstration but not under real operating conditions.
- Using adjectives instead of criteria: “fast”, “robust” and “secure” cannot be accepted consistently.
- Copying generic targets: numbers are adopted without evidence that they match the business.
- Defining qualities too late: infrastructure, data and integration decisions have already been made.
- Ignoring ongoing operation: monitoring, backup, support and change are left outside the project scope.
- Failing to assign an owner: no one in the business is responsible for deciding what level is necessary.
Questions to put to a supplier
- Which non-functional requirements will materially change the architecture or cost?
- Which targets are based on measured business demand, and which are assumptions?
- How will performance, recovery, permissions and accessibility be tested?
- Which requirements need specialist review before they are accepted?
- What operating data will be monitored after launch to confirm the assumptions?
- How will the requirements be updated when usage or risk changes?
Practical next step
Take the five most important functions in the proposed system. For each one, add the operating conditions that would make it genuinely usable: volume, response, permissions, failure behaviour, recovery and evidence. This exposes missing non-functional requirements without turning the specification into a generic technical checklist.