Most software projects do not fail because the code is bad. They fail because nobody wrote down what the system was supposed to do, and the team found out too late that everyone understood it differently.
Requirements come in two kinds. Functional requirements say what the system must do. Non-functional requirements say how well it must do it. Teams usually write the first kind carefully and the second kind badly, and that is where most expensive surprises come from.
This guide explains both, with examples you can copy, and shows what a QA team does with them. We test software for a living, so we see what happens when requirements are vague: the bug report says “this is wrong”, the developer says “it works as written”, and nobody can prove either side.
What is a software requirement?
A requirement is a statement about what the product must be able to do, written clearly enough that two people cannot read it differently.
That last part is the hard part. “The search must be fast” is not a requirement. It is a wish. Two people will read it as two different numbers, and neither will know when the work is done.
Requirements usually sit in three layers:
- Business requirements — what the company wants to achieve. “Cut the time to open an account from three days to one.”
- Stakeholder requirements — what a particular group of users needs. “A compliance officer must be able to see why an application was rejected.”
- Solution requirements — what the system itself must do and how well. This layer splits into functional and non-functional.
The first two answer why. The third answers what and how well, and that is the layer a development team builds from and a QA team tests against.
Functional requirements
A functional requirement describes a behaviour: an input, an action and a result. If you can imagine clicking something and seeing an outcome, you are looking at a functional requirement.
They are usually written as “the system must…”:
- The system must let a user reset a password using a link sent by email.
- The system must reject a card payment when the card has expired, and show the reason.
- The system must send the customer a receipt within one minute of a successful payment.
- An administrator must be able to block an account without deleting its history.
Common types of functional requirements
- Business rules — the logic the company runs on: who may approve a refund, how a discount is calculated.
- Authentication and authorisation — who can log in, and what each role may see and change.
- Data handling — what is stored, what is validated, what is archived and when.
- Transactions — what happens on success, on failure, and on a half-finished operation.
- Reporting — which reports exist, what goes in them, who can export them.
- External systems — which services the product talks to, and what it does when one of them is down.
- Audit trail — what the system records about who did what, and when. In regulated products this is not optional.
How to collect them
Four questions get you most of the way:
- Who uses this? List every role, including the ones nobody mentions: support staff, finance, auditors.
- What does each role need to get done? Describe the job, not the screen.
- What should happen when it goes wrong? Wrong password, expired card, lost connection, duplicate click. This is where half of all defects live.
- How do we know it is done? If you cannot answer that, the requirement is not finished yet.
Non-functional requirements
A non-functional requirement describes a quality of the system rather than a behaviour: how fast, how reliable, how secure, how many users at once.
These are the ones teams skip, because they feel obvious. They are not obvious. “Fast” means 200 milliseconds to one person and two seconds to another, and the difference between those two numbers can be months of work.
The categories that matter most
| Category | The question it answers | A usable example |
|---|---|---|
| Performance | How fast, under what load? | Search returns results in under 500 ms for 95% of requests, with 200 users active. |
| Scalability | What happens when we grow? | The system handles 10,000 orders an hour without added infrastructure. |
| Availability | How much downtime is acceptable? | 99.9% uptime per month, excluding announced maintenance windows. |
| Security | What must be protected, and how? | All personal data encrypted at rest; passwords hashed with bcrypt; admin access requires two-factor authentication. |
| Compatibility | Where must it run? | The last two versions of Chrome, Safari, Firefox and Edge; iOS 17+ and Android 13+. |
| Usability | How easy must it be? | A new user completes registration in under two minutes without help. |
| Accessibility | Who must be able to use it? | Conforms to WCAG 2.2 level AA. |
| Maintainability | How easy is it to change? | Unit test coverage stays above 70%; a new developer can run the project locally in under an hour. |
| Compliance | Which rules apply? | Personal data processed according to GDPR; payment data never stored on our servers. |
Notice what every example in that table has in common: a number, or a named standard. That is the whole trick. A non-functional requirement without a number is a conversation, not a requirement.
Functional vs non-functional: the difference in one table
| Functional | Non-functional | |
|---|---|---|
| Answers | What does the system do? | How well does it do it? |
| Written as | “The system must…” | “The system shall be…” |
| Comes from | Users and business rules | Expectations, budget, regulation |
| Shapes | Features and screens | Architecture and infrastructure |
| If it is missing | A feature is absent — obvious at once | The product works, then falls over in production |
| Tested by | Functional and regression tests | Load, security, compatibility and accessibility tests |
| Cost of changing it late | Moderate | High — it often means rebuilding |
The last row is the one to remember. Adding a forgotten button is a day of work. Discovering after launch that the system cannot hold the load, or that it stores data it was never allowed to store, can mean rebuilding a large part of it.
The same feature, written both ways
Take one feature — a customer paying for an order — and look at how the two kinds of requirement describe it.
| Functional | Non-functional |
|---|---|
| The system accepts Visa, Mastercard and Apple Pay. | Payment confirmation appears within 3 seconds for 95% of attempts. |
| A declined payment shows the reason and keeps the basket intact. | Card details are never stored on our servers; the provider’s hosted form is used. |
| A receipt is emailed after a successful payment. | The checkout works on the last two versions of the four major browsers. |
| A failed payment can be retried without re-entering the address. | The checkout handles 500 payments a minute during a sale. |
Both columns describe the same checkout. Build only the left one and you have a checkout that works on your laptop and dies on launch day.
What QA does with your requirements
This is the part that usually gets left out of articles on this subject, and it is the part that saves money.
A test case is a requirement with the outcome checked. So when a QA engineer reads your requirements, they are really asking one question: can I tell whether this is true or false? If the answer is no, the requirement goes back.
Here is what that review catches, usually within a day:
- Words with no number. Fast, soon, reliable, user-friendly, a lot of. Each one hides a disagreement.
- Missing failure paths. The requirement says what happens when the payment succeeds. It says nothing about a timeout, a double click, or a provider returning an error.
- Two requirements that contradict each other. One says sessions expire after 15 minutes; another says a long form can be saved and finished later.
- Requirements nobody can test. “The interface must be intuitive.” Replace it with a task and a time, and it becomes testable.
- Non-functional requirements that were never written down. Almost always load and browser support, and in regulated products the audit trail.
Every one of these is cheap to fix in a document and expensive to fix in code. That is why we ask to see requirements before a project starts, not after the first build is handed over for software testing and QA.
Requirements decide what can be automated
There is a second, less obvious effect. Automated tests need a clear expected result — a number, a message, a state. A requirement written as “the report should look right” cannot be automated at all. The same requirement written as “the report shows the total of all paid invoices for the selected month, excluding refunds” becomes an automated check that runs on every build.
So the quality of your requirements sets a ceiling on how much of your test automation is possible. Teams often think automation failed them, when what failed was the sentence the test was written from.
Five mistakes we see most often
- Describing the screen instead of the need. “A dropdown with countries” fixes the solution before anyone has agreed on the problem.
- Leaving non-functional requirements until the end. They drive the architecture. Deciding them after the architecture exists means changing the architecture.
- One requirement containing three. “The user can register, verify their email and invite colleagues” is three requirements, and only two of them will get built.
- No priorities. When everything is essential, the team decides for you, under deadline pressure, at two in the morning.
- Writing them once and never touching them again. Requirements change. A document that stopped matching the product three months ago is worse than no document, because people still trust it.
A short checklist before development starts
- Every role that touches the system is listed, including support and finance.
- Every requirement has an outcome someone can check.
- Every “fast”, “secure” or “reliable” has been replaced by a number or a standard.
- Failure paths are written down, not only the happy path.
- Requirements are prioritised, and someone has the authority to cut the bottom of the list.
- A QA engineer has read them and asked their questions.
FAQ
Can a requirement be both functional and non-functional?
No, but one feature produces both. “Users log in with a password” is functional. “Login completes in under two seconds and locks the account after five failed attempts” is non-functional. Write them as separate lines so each can be tested separately.
Who writes requirements?
Usually a business analyst or a product owner, with input from stakeholders. On smaller teams it is whoever understands the business best. What matters is that a developer and a QA engineer both review them before work starts.
Do we still need requirements if we work in Agile?
Yes. They are shorter and change more often, but a user story with no acceptance criteria is the same problem in a smaller box. The acceptance criteria are the requirements.
How detailed should they be?
Detailed enough that a developer does not have to guess, and short enough that someone will actually read them. If a requirement needs a paragraph to explain, it is probably several requirements.
What if the client cannot give us clear requirements?
That is normal, and it is work someone has to do. A short discovery phase — interviews, a few workflows written down, a prototype — usually costs less than a month of building the wrong thing.
Getting a second pair of eyes
Requirements review is one of the cheapest quality activities there is. It takes a QA engineer a day or two, it needs no environment and no code, and it catches the defects that would otherwise be found after release.
If you want someone to go through your specification before development starts, that is part of what our QA and testing team does. We will come back with the list of questions nobody has answered yet — which is usually the most useful document in the project.
