What is a non functional requirement?
Non-functional requirements sometimes present a challenge to business analysts, starting with the question, What is a non-functional requirement? This article answers that.
What is a requirement?
A requirement in business analysis is a capability needed by the users of a system.
Requirements are usually considered as being either functional or non functional.
To read more about requirements in general, see this article.
To read about succeeding with requirements, see this article.
So what is a non functional requirement?
To answer the question, ' What is a non functional requirement ', I looked in a dictionary. The definition was, 'Something that doesn't work'.
I checked another well known dictionary; that didn't even list the word.
Presumably, somebody, at some time, thought that if the term, 'functional requirement' described the functions that users needed, then the word ‘non-functional’ was the obvious term to cover everything else.
How wrong can you be?
Simple answers to, “What is a non-functional requirement”?
I’m sure you’ve seen one-liner attempts to describe the word.
- “System qualities””
- “Constraints”
- “How well the system does what it does”
and so on.
But there are significant problems with these attempts.
The problem with ‘simple’ definitions
The term, ‘Non-functional requirement ’ covers a lot of things, often very different things.
It’s a made up word, which is why you see different forms, for example:
- ‘Nonfunctional’, as often used in English articles
- ‘Non-functional’, as typically used in American (US) articles, and in this article
- Non functional
There’s not always a clear line between functional and non-functional, which perhaps makes it impossible to apply simple definitions.
Let’s put it in the context of buying a car.
You as a car buyer
Your functional requirements
These are very straightforward, for example:
- Go forward and backward
- Turn left and right, not at the same time
- Change speed, faster and slower
What car can’t do these things?
If you’re buying a new car from an approved dealer your first demands would probably not be:
- “Let me see if it starts”.
- “Okay, now let me see if it can accelerate, brake, etc.
That’s because we expect all cars to be able to do these things, even cars with no human driver.
So, what are the things that really affect our purchasing decision?
- Performance?
- Reliability?
- Safety?
- Security?
- Looks?
- Build ‘quality’?
- Comfort – Luxury?
- ‘Feel’ of the drive?
And of course for most of us there’s the little question of what we can afford.
More questions
For everything on that list we have to ask more questions, for example:
- What do you mean by comfort or the feel of the drive?
- What’s your required level of:
- performance
- reliability
- safety
- ….
These things seem to have something to do with quality, which is why non-functional requirements are sometimes referred to as ‘quality requirements’.
Quality requirements
The trouble with referring to ‘quality requirements’ is that, although we probably all have an intuitive feeling for what is meant by quality. it’s another word that’s difficult to describe.
For ‘quality’ in the context of cars, we might immediately think of brands such as:
- Mercedes
- Range Rover
- Rolls-Royce
- Aston Martin
- Ferrari
and so on.
Each one of these brands probably causes different ideas of quality to spring to mind. For example, the Ferrari suggests speed and power, whilst the Rolls Royce suggests luxury. All of them suggest wealth. There’s something elusive about the word, quality. Can we come up with a better definition?
Quality reconsidered
All modern cars are built to very high quality specifications. It’s the norm and so we take it for granted.
In everyday language, we probably reserve the word, 'quality', for cars that do something over and above the norm, for example, those that are built to perform at very high speeds or to provide the ultimate in luxurious interiors or to be outstandingly safe and secure. These are the things that push up the price. Quality in this sense costs money.
A more useful, and accepted, definition of quality is, 'fit for purpose'.
Problem solving
Probably the most fundamental thing to understand about specifying a requirement is that it must relate to a problem to be solved or an objective to be achieved.
Given that any car will get you from A to B, what are your personal objectives? What problem are you trying to solve?
What are your objectives in buying this car?
Perhaps your main objective is one of the following:
- Get across town as cheaply as possible once or twice a week
- Get across the country as reliably as possible every day
- Take the children to school as safely as possible
- Have room for a large family and a dog
- Have a bit of fun and excitement
- Go shopping
- Inner city driving
- Drive off road
- A holiday motor home
- Fuel economy
The price differences between such alternatives can be extreme.
Why do these things create such price differences?
The obvious first answer is that these different situations require different levels of components and construction.
Because high-performance sports cars can reach such high speeds they require something special in the design and build of the braking systems, the frame, suspension andwheels.
And whereas a small, low-power ‘run around’, can be a perfectly fine car for the purposes for which it was designed and built, you couldn’t make it go faster by fitting an engine from a Ferrari.
You couldn’t make it better at climbing mountains by installing the wheels and suspension from a Land Rover.
And would you really want to put the upholstery from a Rolls-Royce into your everyday running around?
And that’s the trouble with these things. You can’t make just one change. You’re talking about an entirely different type of vehicle. It’s the whole design and architecture that has to change. You’re talking about every single aspect of the vehicle, individual aspects and combinations of aspects.
Multiple objectives
To make the problem worse, you may have multiple objectives and if you can only afford or only desire one vehicle, then you’re likely to have conflict.
The architectures required to achieve each of the above objectives are all very different.
To resolve such conflicts, you’re probably going to have to compromise and choose an architecture that balances your objectives and gives you just enough of what you’re after in each case.
Architectural requirements
The so called non-functional requirements tend to affect many if not all aspects of the construction. They affect its architecture.
Before going any further with this one, let’s return to the world of IT and computer systems.
Specifying requirements for a computer system
Functional requirements
There are often lively conversations generated around the question of whether to write functional requirements as
- Traditional requirement statements
- Use cases
- User stories
- ‘Formal’ requirements statements
- …..
But is this really the big issue?
- A traditional requirement might be stated as:
- A receptionist shall be able to check-in a guest
- A user story might look something like:
- As a receptionist, I need to be able to check-in a guest in order to….
- A use case identifies
- A role, such as a receptionist
- A function, such as ‘Check-in guest’
In essence, and perhaps superficially, they all look rather similar.
I assume that in all cases the business analyst knows that it is essential to define acceptance criteria and a business rationale.
Getting yourself understood
Even if we hate traditional requirement statements or use cases and absolutely love user stories, we can probably get ourselves understood by users, developers and testers, with any of these approaches by observing the following guidelines:
- Use the ‘business’ language of the organisation
- Use pictures, models, diagrams, tables, examples and simulations, where helpful
- Keep things as simple as possible
Functional requirements, such as: ‘The ‘user role’ shall be able to create an account’, can be developed and implemented with an approach along the lines of:
- Discuss with users to get the appropriate level of detail to ensure understanding and agreement, on what is meant by an account
- Discuss with developers to get to the appropriate level of detail to develop an application with which the relevant user role can create an account
- Discuss with testers and users to establish acceptance criteria
- Build the application
- Test the application
Testing the application for compliance with the functional requirement will have one of two basic results:
- An account is created – The application works
- An account is not created – The application doesn’t work
It’s black-and-white. You can’t half create an account or create half an account. At the end of the test, the account is either there or it isn’t.
If we realise we’ve missed a functional requirement, which we probably usually do, it’s normally straightforward to add it. Or perhaps defer it until later, which takes us to priorities.
Priority
With functional requirements, we can use a priority system such as MoSCoW
- Must
- Should
- Could
- Want
which can affect the order for the iteration in which functions are developed and implemented.
Non-functional requirements
Non functional requirements are nothing like that.
Categories of non-functional requirement include:
- Performance
- Security
- Usability
- Capacity
to name just a few.
You can’t launch a product that doesn’t have these characteristics, even they are implemented at a ‘minimum level’. You can’t defer any of them to a later iteration.
Let's examine a few types of non-functional requirement
Performance
Once the application has been written, an experienced programmer might be able to optimise it for speed of operation, but there’s a limit to what they can achieve like that.
There are other things that need to be considered:
- Hardware, its capacity and its capability
- Operating system: you may need one that’s designed for specific operating conditions
- The network, a mix of hardware and software
- The database and the database management system, design strategies and the skill of the database designer
These are not things that most application programmers and testers deal with and they affect more than the basic application.
And what exactly do we mean by performance anyway?
- Response time to an enquiry?
- Transactions per second?
- Throughput?
- Capacity?
- Accuracy?
However we qualify it, we can see that it affects the architecture of the entire system, hardware and software.
Security
Security is an odd one.
In some systems of categorisation it’s referred to as a functional requirement.
It strikes me as a hybrid. Car manufacturers for example may describe certain security features on their vehicles:
- Alarms
- Locking devices
- Tracking devices
all of which make the car more difficult to steal.
These things probably involve both hardware and software and as features they presumably qualify as 'functional'.
But then we can get various grades, or quality levels, of these pieces of equipment, which is typically what is referred to as a non-functional requirement.
For computer systems, the design, build and monitoring of the security aspects is of course a highly specialised operation.
The average application programmer and functional tester is not trained to do this.
Safety
Safety has similar characteristics to security.
Again the car manufacturers can add certain features
- Airbags
- Devices in the wing mirrors that make them light up when an overtaking vehicles get close
- Devices in the headlights to show up people at the sides of the road
and so on.
Once again, all of these may be described as functions and once again these functions will certain qualities in the material used and the construction and testing processes.
Usability
User interface design together with accessibility is a specialism that requires an understanding of human perception and the characteristics of the users themselves.
In the design of a car, can all the controls in the car be reached easily and ‘safely’, keeping your eyes on the road?
Does the average application tester know what it means to create a test for usability?
How to gather non functional requirements
It’s an iterative process.
- Write down what the users tell you they require in termsof:
- Performance
- Security
- Usability
- ….
- More specifically, ask about their objectives, the problem they are trying to solve.
- Ask for a rationale for their choices. If there’s no rationale, it’s not a requirement
- Hand this information to the specialists responsible for implementation and to the sponsor responsible for budgeting.
- Go back to the users with the cost and development estimates for what they’ve asked for and with the sponsor’s comments, perhaps toned down a bit
- If they still want it and can afford it, you’re done
- Else adjust the figures and repeat as necessary
- No sweat
Specifying and implementing non-functional requirements
In specifying requirements, we have to think about who will be receiving them.
To facilitate this, rather than thinking of non-functional requirements as a group, think about each type, e.g.
- Performance
- Security
- Usability
- ….
For each type, we need to determine:
- What sort of specialist is needed to implement it?
- What information does that specialist to get the context and detail they need to determine what they have to do?
- What skills are required to test the finished product?
For specialists, we have:
- Database designers
- Security experts
- Performance specialists
- Software experts
- Hardware experts
- User experience experts
- ....
In practice of course, the technical specialists probably tell the business analysts what they need to know.
Frequently it’s about the numbers:
- How many transactions per minute?
- How long does this information need to be retained for?
- How much data?
- What is the cost of downtime?
- ….
The business analysts may have forms designed to capture the relevant information.
The main job is then to get the forms to the right people.
Specifying ranges of acceptable values
We mentioned that functional requirements are black and white. Things either work or they don’t.
Architectural requirements can be associated with a range of values:
- Unacceptable
- Ideal
- ‘Over the top’ – (too expensive) for the situation
These numbers might be associated with averages:
- Mean
- Mode
For example, we need a response time at the user's monitor no greater than 2 seconds for 80% of the transactions/time.
Designers need these ranges so that they can ensure that the overall system will work within acceptable tolerances.
The different categories of architectural requirement must be balanced.
Perhaps increases in security levels cause reduced performance.
Like putting a wheel on a car, the nuts are gradually tightened so that the wheel is not skewed by over tightening any one of them.
It’s an iterative process.
So perhaps none of the elements are performing at their ideal level, but collectively the system is performing with agreed limits; it's a compromise.
Testing architectural requirements
Testing architectural requirements demands special skills and special tools.
It might involve simulating large numbers of users or background activity to obtain a realistic view of the production environment.
Not all testers have these skills or know how to use these tools.
Do we need to go through all this trouble?
When designing critical software for:
- Vehiclesignalling systems, control systems, trading systems, and so on.
- Air traffic control
- Signaling systems.
- Body scanners
- Control systems
- Trading systems
and so on, it's vital to obtain the right information that will lead to appropriate designs. Lives and the survivability of organisations can depend on this.
But does this really happen for the average office system?
For systems with special criteria, high loads, etc, somebody has to do this before the product gets built and tested.
If that somebody is to be the business analyst, they need the skills and knowledge to be able to do it.
Your definition?
Can you think of a simple definition to answer the question, 'What is a non functional requirement?' that covers everything discussed in this article?