Unfortunately, it often turns out that meeting security or scalability requirements after a product is almost built is far more time-consuming and costly than anticipated. In the worst-case scenario, several parts of the product might have to be rewritten – significantly delaying its launch and increasing expenses as well.
Our non-functional requirements (NFR) guide can help you avoid this scenario, though. In this article, we’ll cover what causes PM/PO and Agile teams to underestimate NFRs and show how you can add them to your project to guarantee that it will be fully functional.
What are non-functional requirements?
Non-functional requirements (often also called quality attributes) are those that describe a system’s performance, security, and overall operational capabilities. Their main purpose is to make a product (whether it be an application, software, or website) more efficient and convenient to use, thus improving the user experience.
Basically, functional requirements focus on what a product should do, whereas non-functional requirements are all about how the product will do that.
To put the differences between these two types into an example, imagine you are building a website for a service and want to include a “create an account” functionality for your users. To make it easier for them to sign up, you plan to add “Sign up with Gmail” and “Sign up with a Facebook account” features to the webpage. Those would be the functional requirements.
In order for the account creation process to be smooth for all of your users, however, there are a few non-functional requirements that you should add to the website requirements lists as well:
- Page loading speed on different devices
- Method and location of storing and securing customers’ data
- Number of users the website can handle without slowing down or crashing
- Action that user should perform when the sign-up method they pick doesn’t work as intended
Will the “Create an account” page work without those requirements? Technically, yes. However, if the page loads slowly or not properly on mobile devices, there’s a higher chance that the user will leave the page than finish creating an account.
Then, you might have to spend extra time and money fixing those issues – something you could have avoided if you added the NFR requirements to your task list from the beginning.
What makes non-functional requirements so challenging to add?
As you can see, NFRs can align your product with the features that future users might need for a given task and also contribute to providing an exceptional user experience.
But if those requirements can be so useful for the creation of an application that is fast, secure, and easy to use, why are they so often overlooked? There are a couple of reasons for that:
➡️ Teams find it hard to capture the right NFR for the project
To know what NFRs ought to be included, Agile teams must ask the stakeholders/clients about their expectations and then also research user expectations.
➡️ NFRs are subjective
It can be difficult to determine how exactly they should be added to the project, as the opinions of users and stakeholders are personal. Developers might also have different opinions on what security measures to include or what is an acceptable response time.
➡️ Tricky to measure and test
NFRs vary so much that each one has to be measured and tested differently. Development teams also often struggle to figure out how they can verify whether the requirements are met or not.
Sometimes it also happens that the development team only includes the most obvious NFRs in the requirements lists (performance, security features, or legal compliance) but skips, say, scalability. That can lead to a situation when their new website or application crashes due to a sudden increase in traffic or number of users, and forces the developers to work urgently on fixing the product.
Non-functional requirements – best practices for adding them to your project
Now that you understand why spending sufficient time researching both functional and non-functional requirements is key to the success of a project, your next question might be: “So what is the best way to include NFRs in my project?”
Below, we have noted four simple steps that will be of great assistance when it comes to adding an NFR criteria right at the start of a project that ought to be in mind its entire development.
Build a non-functional requirements list
NFRs are all about giving your target users a product that they will enjoy using. The first step here is therefore to think about how exactly the website or application should work in order to make using it a pleasure. For example, should the website load quickly on both laptops and mobile devices? Will it be possible to increase the font size? Perhaps security is of the utmost importance for users?
An excellent approach to determine what users will need most is to look at how your target audience uses similar products and what their main issues are when doing so. Based on this information, you can then figure out what features or qualities you should add to your new product.
Talking with the stakeholders or clients about which product qualities they would like to be included (and how they will be critical to the entire product) will also contribute to clarifying the requirement list.
Of course, like with everything in Agile development, an NFR list shouldn’t be set in stone. As priorities during project development change, the NFR list must be verified and modified accordingly.
Set clear expectations for each requirement
After finishing the research phase, you should have a list of quality requirements to focus on during the development stages. The list is probably quite vague for now though, so it’s time to make the requirements a bit more specific.
Think about it – if you want your website to load smoothly, which of the following two requirements would make it easier to test that?
Obviously, the second one. So, together with a list of NFRs that you will follow during the project, you also need to specify how exactly each one should perform and how you will test it later. In one of our previous articles, “NFR in software engineering“, we mentioned a few questions that can make clarifying the objectives for an NFR and later testing them a bit easier for your team.
Another nice approach to specify your goals for non-functional requirements is through using the SMART method to write more specific, measurable, attainable, relevant, and time-bound goals.
Consider how adding NFRs might impact product functionality
The main reason why adding an NFR at the end of the project or after completion is so expensive? Since it often involves rewriting parts of the project just so the main features and, e.g., security functionalities work together without conflicts. In the worst case scenario, you may even need to rewrite most of the website or application code because the ready version doesn’t meet the requirements.
The earlier you prepare the functional and non-functional requirements, the better you’ll be able to gauge how well they will work together and if any trade-offs need to be made. That way, you’ll be able to save your developers’ time (and nerves) and also avoid going massively over budget just because several features need to be adjusted.
Decide how and where you will store the NFR requirements
When it comes to NFRs, many teams also struggle with a method for keeping the requirements documented and visible. One of the most often popular methods to do so is through User stories, for instance:
As someone who keeps worrying about the security of my data, I want it to be password/fingerprint scan protected and encrypted so that I can be sure no one has access to my account.
Two more examples follow from the BrainsLink and Mastering Business Analysis blogs, respectively:
As an impatient and overworked data analyst, I want to process 10,000 records in under 60 seconds so I can get more done in less time.
As an online banking customer, I want my checking account balance to display within five seconds of my request so that I don’t get frustrated and can see if I have the funds to pay my bills.
In case the NFR you picked doesn’t fit nicely into the story metaphors, there are a couple of different methods for noting requirements – include them as “acceptance criteria”, create technical stories, or just add them to your “Definition of Done” checklist. There isn’t one right method of documenting NFRs, so you can pick whichever will be most convenient for your team.
Create a non-functional requirement testing plan
Not enough testing is often one of the main reasons why a website or application needs to be reworked later. But while functional testing is often pretty straightforward, NFRs can be a bit more tricky to verify since each one needs to be tested differently.
Discussing with the developers and testers which methods to adopt for each requirement and planning the testing stage right from the start will make a lot of aspects easier later on, though.
For example, testing the application under heavy load early will give you plenty of data on what you can expect to happen when there are, say, far more users logging into the application than usual. Then, you’ll be able to prepare plans for what to do if such a situation occurs after the application has been released and how to restart it in case of a crash.
As we mentioned in the previous point, however, it’s essential that testing objectives and pass/fail criteria are as specific as possible. For instance, the pass criteria should be “The application must be able to support 10,000 concurrent users” rather than “The application must keep working under heavy load”, since the former will be much easier for you to verify.
Conclusion
Giving non-functional requirements the attention they require can be extremely useful when it comes to completing development projects on time and within budget. Not to mention that this way you can guarantee the ready product will have everything your future users need to keep using the product for longer.
Although researching, specifying, and testing those requirements might take some effort and can be confusing, this will be time well spent. You’ll save time and money on code rewrites and urgent patches down the line, while your users will see that how your product works is just as crucial as what your product does.