Software applications and IT systems need to adhere to the demands and wishes of their end-users. Otherwise, they won’t be used by them or they can disrupt the business in which they operate. Functional requirements describe which capabilities the system must support in terms of desired features. For example a registration page for new users, a monthly sales report, or an overview page of the last trending products. Non-functional requirements are not so visible, since they tend to be less tangible. Besides, they are also technically related most of the time. Business representatives need to understand the behavior of the system to formulate them. Questions like “how fast should the system be” and “how portable should the application be” are examples to gather the non-functional ones. Often, they do not feel comfortable with these aspects. The requirements analyst can help here. Make non-functional requirements practical – here’s how.
Reasons to explain
Requirements analysts have the task to gather the functional and non-functional requirements. Especially for large systems, there are a lot of stakeholders – both the supportive ones as well as the negative stakeholders. It’s important to explain why the non-functional requirements are important. Besides, the analyst also needs to select and define the most prominent quality-related aspects. Furthermore, the baseline of the desired quality level(s) should be defined. This all acts as the starting point for the conversations with the stakeholders. Give clear examples to make things practical.
Examples: why non-functional requirements
The following examples can be used to help stakeholders from the business departments understand why non-functional requirements are essential:
- Not a single customer of your internet banking application is willing to share his/her financial information if your software system is not (visually) protected so he/she knows for sure you keep their sensitive data secure.
- If you offer a system for discount cards and the system constantly fails to redeem those cards, end-users will complain (publicly) about your service and stop using it.
- Consider a software application that handles insurance. If this system is unable to apply external changes such as rules and regulations, the system is not future-proof.
These examples all focused on quality-related aspects. It would be best to start with the most prominent requirements.
Examples: select the most prominent quality-related aspects
As seen in the previous list, the quality-related aspects can be very diverse. It would be too much work to collect all prominent quality-related aspects. Instead, this list can be shortened by applying a checklist. Often, requirement analysts use the ISO 9126 standard. Besides this recommended standard, he/she can also refer to equal systems that share the same characteristics.
Stakeholders demand a certain “level of quality (baseline)” of the system before they are willing to accept it as their solution. Some of the most prominent quality-related aspects are:
- Portability of software applications is king if the stakeholder needs to migrate it from one cloud provider to another (in the future). Without this aspect, the application needs to be refactored or even completely rewritten.
- Without proper security (physical and virtual) of data assets, the application is at risk of hackers and other bad actors. Applications that are not secured properly won’t be used (at all) or require a thorough investment to make them secure (enough). Then again comes the question: when is it “good enough”?
- Applications that handle complex information which demands a high level of knowledge from their end-users should be user-friendly. Otherwise, people make mistakes (and might feel stupid) and this demands a lot of data corrections. Even worse: the wrong decisions are made based on low-quality data. These quality-related aspects are essential for applications/systems such as healthcare systems that define the proposed treatment of sick people.
Based on these aspects, it’s now possible to define the desired level/baseline of quality.
Examples: defining the baseline
The baseline of the level of quality needs to address the needs of the end-users. They won’t accept a lower level of the baseline requirements, it’s better to exceed their expectations. It’s impossible to have extremely high levels of requirements for every aspect. Stakeholders might demand it, but the requirements analyst needs to find a balance between the technical capabilities as well as the financial investment which is needed.
Consider the following topics that might bring negative side aspects to the system:
- A system that is “too secure” demands more (manual) tasks that the end-user needs to carry out (think of MFA or restricted access only during strict office hours). Not every system needs this, so keep an eye on the usability aspects as well.
- An application that is extremely portable might not perfectly fit the target system since it needs to support other systems as well. For example wrapper languages around IaC scripts that support multiple cloud providers can’t always use specific features of the primary cloud provider.
Given these aspects, the requirements analyst needs to discuss the pros and cons with the various stakeholders. In the end, he/she needs to define a trade-off for every aspect before the non-functional requirements are transformed into User Stories and put on the backlog of the Scrum team. Without these “cultural aspects”, everything else about the system is useless and a waste of resources.
Make it practical
Non-functional requirements become concrete when applying the main properties of the ISO 9126 standard. The following properties are relevant here: functionality, reliability, usability, maintainability, portability, and last but not least security. Stakeholders should be able to provide relevant answers to make the non-functional requirements as concrete as possible. In the end, these should be translated into working software.
Functionality
It’s important to distinguish the most important features compared to the less important ones. Think of the following questions for stakeholders to find out what’s relevant:
- Which features are mission-critical and which ones are supporting it? This has an effect on the requirements in terms of availability, scalability, etc.
- Will the system or application store or process any privacy-related information? This adds extra requirements in terms of data protection/security, auditing, logging, and data retention.
- Does the system require calculations? If yes, how precise should they be? Would it be OK to round figures or is this strictly forbidden?
- Which features are vulnerable to misuse/fraud? Does the system require specific fraud detection mechanisms?
- What is the value of the data which is being transferred to other systems? Determine the data classification of the various pieces of data.
The above-mentioned questions are just the tip of the iceberg. Once stakeholders have answered these sample questions, it becomes a bit clearer which non-functional requirements are needed. The first category is most important since this has a direct effect on the aspects which follow.
Reliability
IT systems that host applications and the applications themselves need to be reliable to serve customers when they need it. Questions like “how reliable should the system be” are difficult to answer. Therefore, it’s important to make things a bit more concrete:
- What will happen when the core system breaks and is unavailable? How long are customers willing to accept this situation? Also, how do we make sure we recover from it in the given time? Which amount of money are we willing to invest and pay to start all systems back again?
- How many times (per year/month) do we allow for (unexpected) downtime due to maintenance or other disruptions?
- What does the system need to do in case of a failure of a connected external system? Do we present that to our users or do we build a solution to handle this more gracefully (f.e. queuing messages to be handled later)? All come with a price.
Reliability is much more than desired uptime and SLAs as seen from this perspective.
Usability & efficiency
End-users need to understand the system they work with. “How easy” should the system be is difficult to answer. Consider the following questions to breakdown this main question to find the answers from stakeholders:
- Which tasks are executed most often (say 75% of the time)? Are these tasks also the most important ones for each and every stakeholder?
- Is there specialized training needed for end-users to understand the system?
- Should the system support a help feature for every module?
- Which requirements apply to the Graphical User Interface? Do we need it at all or is a console-based application sufficient?
Cloud services offer numerous ways to build ultra-efficient systems. However, they all come with a price, especially if developer teams are not so experienced with them. So the analyst should ask questions like the following to get a good overview of these:
- What is the maximum acceptable time of latency? Does this apply for office hours or only for out-of-office hours?
- How many users should be supported at the same time, should we design performance tests to validate the first version of the solution?
- How fast should the system handle batch processes? And do we need to take into account the number of concurrent users?
It’s best to ask these kinds of questions to application developers and also take into account the end users’ point of view to get a complete picture. Besides these groups, ask the software or infrastructure/cloud architects to come up with proper advice. Don’t forget to include the financial controller as an important stakeholder since he/she needs to make a decision as well.
Maintainability & portability
Your applications need to be maintained without much effort. Although DevOps helps to push changes faster, you should not change a huge number of small files and fire up multiple pipelines with a lot of integration tests just to make that small change. Therefore it’s important to focus on maintainability.
Ask questions like the following to get an answer from your stakeholders:
- Which components of the application(s) are most likely to be changed frequently. And how much?
- Does the system contain components that are developed by another DevOps team or even an external supplier?
- Which components are relatively easy to build and which ones are particularly difficult (and tend to yield most of the issues)?
In terms of portability, you may ask the following questions:
- Does the application need to be platform/cloud agnostic? If yes, what would be the scope of your solution?
- Will the software be sold to third parties or will it only be used internally? Is your intention to open-source the source code?
- Are there any (technical/legal/official) limitations to where the software can run? Think of data legislation that prevents an application to be hosted outside the country of origin of the owner.
- Does the software application replace an existing system? Is it allowed and (technically) possible to change the underlying infrastructure?
Together these questions help to push your stakeholders in the right direction for your requirements.
Security
The last category is security. This is not an afterthought but an extremely important and extensive topic. We can only touch on some of the key aspects here. Consider the following questions as a starting point:
- Does the system need to encrypt data (in transit and at rest)? If yes, which encryption techniques are required / possible?
- What does the DevOps team need to do in case of data leakage?
- Do we allow vulnerabilities with a medium or low-risk score? How fast should we fix critical and highly severe security issues?
- What is the classification (CIA rating) of the data that needs to be protected?
- How will users and other systems get access to the application and which permissions do they need to carry out their tasks?
- How do we make sure we keep the number of security issues as low as possible? What does the process of fixing them look like for this application?
For more information about application security, you can check out the article about shifting security left. The ultimate shift left would be to integrate security-related aspects in the requirements gathering phase.
Wrap up
As seen in this article there are a lot of categories that span the topic of non-functional requirements for software applications. In this article, we’ve created a collection of questions that help you to gather what your stakeholders need. Often, the non-functional requirements tend to get less attention compared to the functional requirements. With the help of this article, I hope I’ve inspired you to gather them as early as possible so your application answers to the needs of your stakeholders and internal organization.
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
