The Soul of Your Software: A Practical Guide to Non-Functional Requirements for UK SMEs
You’ve got a brilliant idea for a piece of bespoke software. You’ve worked with a partner to map out all the features, the user journeys, and what every button needs to do. In our last guide, we talked about these as functional requirements, the ‘what’ of your system, the essential blueprint that turns an idea into a working application.
But let me ask you a question. When you think of a car, what makes a Ferrari different from a Ford Fiesta? They both have engines, wheels, and steering. They both meet the basic functional requirement of getting you from A to B. The difference isn’t in what they do, but in how well they do it. It’s the speed, the handling, the safety, the roar of the engine, the quality of the leather.
That difference, that character, that quality, that soul is what we call non-functional requirements (NFRs) in the software world.
They are the most overlooked, yet most critical, aspects that determine whether you end up with a high-performance business asset or a clunky liability that nobody wants to use. For an SME investing in a bespoke build, getting this right isn’t just a technical detail; it’s the defining factor between a project that flies and one that flops.
Is your software idea defined for success? Talk to our experts today to ensure the quality and performance of your project from day one.
From Doing the Job to Doing it Brilliantly
If functional requirements are the architect’s blueprint showing the rooms and the layout, non-functional requirements are the building inspector’s checklist for the entire property.
- Foundation Quality (Reliability): Will the house stand up in a storm?
- Insulation & Energy Rating (Performance): How much will it cost to heat? Does it hold its temperature?
- Locks & Alarm System (Security): How easy is it for someone to break in?
- Accessibility Ramps & Door Width (Usability): Can everyone actually use the building comfortably?
- Room to Extend (Scalability): Can you add a conservatory later without knocking the whole thing down?
You wouldn’t build a house without specifying these things, yet an astonishing number of software projects focus only on the features. The result? A piece of software that technically “works” but is painfully slow, a nightmare to use, wide open to hackers, or crashes the moment more than three people log on.
From my experience, these “quality attributes” are what truly dictate user adoption and long-term return on investment. You can have the most feature-rich system in the world, but if it takes ten seconds to load a page, your staff will find a workaround on a spreadsheet. It’s that simple.
The Anatomy of a Measurable NFR
The biggest mistake people make with NFRs is being vague. A developer can’t build or test something that is subjective. A good non-functional requirement must be a clear, quantifiable, and testable statement.
Vague words are the enemy. Terms like “fast,” “easy to use,” and “secure” are feelings, not instructions. The key is to anchor them to a number.
Poor Example: “The system should be fast.”
- Problem: Whose ‘fast’? The developer’s on a brand-new machine with a direct server connection, or your salesperson’s on a three-year-old laptop using hotel Wi-Fi?
Good Example: “The customer search page shall load and display results in under 1.5 seconds for 95% of requests during standard UK business hours (09:00-17:00 GMT).”
- Why it’s better: It’s specific, measurable, and testable. We know what to measure (page load), the target (1.5s), the success rate (95%), and the context (business hours). It’s a contract, not a suggestion.
Let’s look at another one.
Poor Example: “The system needs to be user-friendly.”
- Problem: This is completely subjective. You can’t write a test for “friendliness.”
Good Example: “A new user, after a 30-minute introductory training session, must be able to create a new client record, add a contact, and schedule a follow-up call without further assistance in under 5 minutes.”
- Why it’s better: This defines a clear, observable outcome. It sets the context (a new user, specific training), the task, and a time limit for success. Our testing team can sit someone down and time them. It’s pass or fail.
The ‘…ilities’: Your Checklist for Software Quality
When we start a project, it’s easy to get lost in the features. To make sure nothing gets missed, we group NFRs into categories. Thinking this way acts as a vital checklist to cover all the angles of your software’s personality.
Performance
Oops, nothing like starting a list with something that doesn’t fit into headings rules of being an …ility. Pretend it is called performancibility. This is all about speed and responsiveness. How quickly does the system react to user input? This is often measured in response times, transaction volumes, or concurrent users.
- Example: “The system shall support 150 concurrent users submitting orders, with an average transaction confirmation time of less than 3 seconds.”
Scalability
This is about your software’s ability to grow with your business. What happens when your user base doubles? Or when you have a massive spike in traffic on Black Friday? A scalable system can handle increased load without falling over.
- Example: “The system architecture must be designed to handle a 50% increase in user volume year-on-year for three years with only linear increases in hosting costs.”
Security
This isn’t an optional extra; it’s a fundamental business requirement. This covers who can access the system (authentication), what they can do (authorisation), and how the system is protected from malicious attacks.
- Example: “All user passwords must be stored using PBKDF2 hashing and be protected against brute-force login attempts by locking an account for 10 minutes after 5 failed attempts.”
Usability (or User Experience – UX)
How easy and intuitive is the software to use? Good usability reduces training costs, increases productivity, and improves staff morale. As we saw above, this is best defined with task-oriented, measurable goals.
- Example: “The process of generating a standard monthly sales report shall require no more than four clicks from the main dashboard.”
Reliability & Availability
This is about dependability. What percentage of the time is the system online and working correctly? This is often expressed as “uptime.” For a business-critical system, this is paramount.
- Example: “The public-facing e-commerce portal shall have a minimum uptime of 99.9%, excluding a pre-notified weekly maintenance window of 2 am-3 am on Sundays.”
Maintainability
This is a big one for long-term cost of ownership. How easy is it for developers to fix bugs, make updates, or add new features in the future? Well-structured code and good documentation are key.
- Example: “The system shall adhere to PSR-12 coding standards, and all new business logic must be covered by a minimum of 80% unit test coverage.”
The Cost of Neglect – Tying NFRs to Your Bottom Line
This is the part that often gets missed. Thinking about NFRs can feel a bit abstract, but ignoring them has real, measurable, and often painful financial consequences. This isn’t about tech for tech’s sake; it’s about protecting your investment and driving business results. Let’s translate the ‘…ilities’ into pounds and pence.
Performance → Lost Revenue
This is the most direct link. Slow websites kill sales. Studies have consistently shown that even tiny delays have a huge impact on user behaviour.
- The Bottom Line: As published by Forbes, a 1-second delay in page load time can lead to a 7% reduction in conversions. For an e-commerce site turning over £500,000 a year, a 1-second slowdown could be costing you over £35,000 in lost sales. Suddenly, investing in performance optimisation doesn’t seem like a luxury, does it?
Security → Existential Risk
A security breach isn’t just an IT headache; it’s a business catastrophe. The consequences are multi-layered: regulatory fines, reputational damage, customer churn, and legal costs.
- The Bottom Line: According to IBM, the average cost of a data breach is now over £4.2 million in the UK. For an SME, a serious breach isn’t just a cost; it can be an extinction-level event. Defining robust security NFRs is one of the cheapest insurance policies you can buy.
Reliability → Operational Paralysis
What does it cost your business if your core operational software goes down for an hour? Or a day? You can’t process orders, you can’t manage logistics, you can’t serve customers.
- The Bottom Line: Calculate your ‘cost of downtime’. If your business generates £1.5 million in revenue a year and operates 365 days a year, your daily revenue is £4,100, or £170 per hour. A system specified at 99% uptime can still be down for over 87 hours a year. Improving that to 99.9% (less than 9 hours of downtime) could save your business over £10,000 in lost revenue.
Usability → Wasted Payroll
A clunky, hard-to-use system drains productivity. If five employees each waste just 30 minutes a day fighting with your software, that’s 2.5 hours of salaried time you’re losing every single day.
- The Bottom Line: Across a year, that adds up to over 600 hours. If the average loaded cost of those employees is £25 per hour, you are spending over £15,000 a year paying people to be frustrated. Good UX pays for itself in efficiency gains.
Framing NFRs in this way changes the conversation. You’re no longer discussing abstract technical concepts; you’re making strategic business decisions about risk, revenue, and operational efficiency.
Worried about the hidden costs in your software build? Let’s have a conversation about defining measurable, business-focused requirements that protect your bottom line.
Common Pitfalls: Where Good Intentions Go Wrong
Having built systems for SMEs for over 15 years, I’ve seen the same NFR-related mistakes derail projects time and again. Here’s what to watch out for.
The “We’ll Bolt it on Later” Fallacy
Mistake: Treating performance or security as something you can “add in” at the end of the project.
Why it’s a Problem: This is like building a bungalow and then deciding you want it to be a skyscraper. Core quality attributes are architectural. They have to be designed in from day one. Trying to retrofit security into an insecure application is a nightmare, it’s expensive, incomplete, and will never be as robust.
The Subjectivity Sinkhole
Mistake: Not quantifying the requirements, as we discussed earlier. Sticking with vague words like “flexible” or “robust.”
Why it’s a Problem: It leaves everything open to interpretation and disagreement. When you say “user-friendly” and the developer delivers something you find confusing, who is right? Without a measurable target, you have no way to formally test and accept the work.
The Gold-Plating Problem
Mistake: Going to the other extreme and over-specifying. Demanding 99.999% (“five nines”) uptime for an internal reporting tool that’s used once a week.
Why it’s a Problem: Every ‘9’ you add to your uptime requirement can add a zero to the cost. The technical architecture needed for 99.999% availability is vastly more complex and expensive than for 99.9%. Good NFRs are about being realistic and appropriate for the business context.
Forgetting the Real World
Mistake: Testing performance on a high-end developer machine connected directly to the server, and then being shocked when it’s slow for users in the field.
Why it’s a Problem: The user’s environment is the only one that matters. You must define and test NFRs in a context that mimics real-world conditions, including network latency, browser types, and typical user hardware.
The Soul in the Machine
A successful software project delivers on two fronts. It must do what the business needs it to do (functional), and it must do it in a way that is stable, secure, and satisfying to use (non-functional).
They are two sides of the same coin. One is the brain; the other is the soul. By defining your NFRs with the same rigour as your features, making them measurable, tying them to business value, and designing them in from the start, you transform your project. You move beyond a simple list of features and start defining the actual quality of the asset you are building. It’s the single best way to mitigate risk, control long-term costs, and ensure your investment pays dividends for years to come.
Further Reading
The Software Requirements Specifications part of our blog is a great place to start if you want to deep dive into other parts of an SRS.
