Non-functional requirements checklist

Direct answer

Non-functional requirements describe how the software must behave rather than what it does: how quickly it responds, when it must be available, who may see what, which devices it must work on, what is recorded, how it is restored after a failure and who owns the hosting. They are usually missing from a first brief because everyone assumes them, and assumptions differ. The cost shows up late, when a feature works but not on the tablet the warehouse uses, or nobody can say who may delete a record. This checklist gives you eight areas to answer in your own words. It sets no numbers for you: values such as speed or uptime are decisions for your business, and a vendor should not claim them without agreeing how they will be measured. Use it alongside the software project scope checklist.

1. Performance expectations

Describe what 'fast enough' means to the people using it, in situations rather than numbers you have not measured. Prompts:

• Which actions must feel immediate, and which can take a moment?
• How many people will use it at the same time at the busiest point of the day or month?
• How much data will accumulate, and does it need to stay searchable?
• Are there imports, exports or reports that run on large amounts of data?
• What connection quality can users be expected to have?

2. Availability

Availability is about when the software must work and what a stoppage costs. Decide which hours matter, whether occasional short interruptions for maintenance are acceptable, and which functions are critical versus convenient. A system used only in office hours needs a different answer from one that customers use overnight. Write down who would be affected and what workaround exists during an outage. Do not accept a general promise of high availability without a definition of how it is measured.

3. Security and access

Security requirements start with who may do what. Prompts:

• Which roles exist, and what may each see, change or delete?
• How do people sign in, and who can reset access?
• How is access removed when someone leaves?
• Which data is sensitive, and who may export it?
• Are there rules from your customers or regulators that apply? Have a qualified adviser confirm which

4. Devices and browsers

List the devices people actually use, including shared or older ones, and the browsers installed on them. Decide whether it must work on phones, tablets or barcode scanners, and whether it must work with a poor connection. State which versions you consider supported, because 'works everywhere' cannot be tested. Ask people on the floor what they use rather than relying on the office setup.

5. Accessibility

State whether the software must be usable by people with visual, motor or hearing limitations, and which guideline you want to work towards. Even where no rule applies to you, basic requirements such as keyboard use, readable contrast and clear form labels improve the experience for everyone. Whether a legal obligation applies is a question for a qualified adviser, not something this page can decide.

6. Audit trail

An audit trail records who changed what and when. Decide which actions need it: approvals, price changes, deletions, permission changes, exports. Decide who may view the history and how long you need to keep it. If a dispute or an internal review is plausible, the history is what settles it. Also decide whether records are deleted for real or only marked as removed.

7. Backup and recovery

Backup is a decision about how much you can afford to lose and how long you can afford to wait. Write down what data must be recoverable, how far back you may need to go, who is allowed to trigger a restore, and how you will find out that a restore works. A backup that has never been restored is an assumption. The backup and restore plan guide goes deeper.

8. Hosting and ownership

Decide where the software runs and, crucially, in whose name. Prompts:

• Which accounts host the code, the database and the domain, and who owns them?
• Where must data physically reside, if anywhere?
• What will hosting and services cost to run, and who pays?
• What do you receive at handover: code, configuration, documentation, credentials?
• How would you move to another supplier if you chose to?

How to use the answers

Turn each answer into a sentence in your requirements document, with an owner and a way to check it. Where you cannot yet answer, list it as an open question rather than leaving it blank. A vendor who reads this list should be able to say which items are included in the price, which are extra and which they cannot commit to. The answer 'we will see' is a signal to ask again. See also web application access requirements for the access items to prepare.