If you were to describe one of the applications or pieces of software you use everyday, you would probably describe what we call “functional requirements.” These are what a product must do. We associate using things with their utility and their capability to do things. However, there are myriad other aspects of the products we rely on that are not specifically concerned with functionality. These nonfunctional requirements.
Functional requirements define what a product must do and what its features and functions are. Nonfunctional requirements (NFR) describe the general properties of a system that constrain and shape its structure. In this post, we’ll take a closer look at NFRs, their role and importance, and provide a non functional requirements checklist for you to review.
What are Non Functional Requirements (NFRs)?
Nonfunctional requirements include all the standardized, foundational properties of a system. These range from its availability, usability, performance, security, scalability, portability, and accessibility. Even though you might not have thought about these aspects when using a product, people have innate preferences and needs regarding their user experience. NFRs ensure that these needs are met at the right time and in the right place.
Simply put, while functional requirements represent the system’s capabilities to offer valuable solutions to users, NFRs are the critical operations that support them.
Why NFRS are Important?
NFRs are just as important as functional requirements, but in ways that give shape to the system rather than substance.
For example, a website can look and feel amazing, but if it has intermittent availability it can’t serve anyone. Likewise, everything can appear excellent and function seamlessly, but if it is not secure, users are at constant risk of exposure, which is disastrous for any business trying to establish brand loyalty and a positive reputation.
Another reason NFRs are salient is that, often, they are not regarded as such, They are consistently overlooked, underreported, and underestimated, to the detriment of the project as a whole. If they are overlooked, the project risks failure or costly refactoring when they run up against any number of limitations that are not defined in the system.
If they are underreported, they are often implemented incorrectly, which causes a slew of other problems immediately and down-the-line. If they are underestimated, then the project runs the risk of going over budget, negatively affecting the profit margins of the product
Because they are so essential to successful projects, developers and designers alike will benefit from reviewing our non functional requirements checklist.
Non Functional Requirements Checklist
This non functional requirements checklist guides a user through all the typologies to consider when building out their NFRs. Keep in mind that this is by no means an exhaustive list, but rather a guide for those beginning their exploration of NFRs.
Basic Typologies For You To Consider
1. Performance (Efficiency)
The speed at which a system performs certain tasks is critical to an enriching user experience. If users are made to wait for pages to load or data to update, it can derail their workflow. While this is mainly the responsibility of the project’s solutions architect, certain parts of a system will have performance expectations that should be met per the client’s needs.
2. Security
A main concern for any system is how well it is able to block unauthorized access or behavior modification while maintaining ease of use. Everything from session timeouts to password constraints should be considered for all roles and permissions. Again, this is largely the concern of the architects on the project, but the business analysts should coordinate between the dev team and the product owner so that everyone is on the same page.
3. Scalability/Maintainability
Scalability refers not only to the size of a system, but its ability to accommodate growth and change in the future, often under different circumstances. These considerations need to be factored into the architecture and design from the beginning. The scales can also refer to increased audience or processing load.
4. Accessibility
Technology connects us, and some people have different abilities that affect their use practices. As such, NFRs that have to do with facilitating access to as wide a range of people as possible are extremely important. The Americans with Disabilities Act Standards for Accessible Design outlines specific guidelines for achieving accessibility.
Again, these requirements need to be considered at the outset of projects to avoid having to redo work down the line. This is a prime area for automation since the standards are released on a cyclical basis and widely distributed.
5. Localization/Globalization
Localization is another NFR that is essential to square away from the start, especially if your product will be used internationally. Essentially, these requirements work to facilitate use in different cultural, linguistic, and geographic settings. These include things like languages and dialects, cultural sensitivities, or date and time formats.
Even something as specific as time zones can become disastrous if not formatted correctly. Furthermore, as financial transactions are increasingly digitized, currency and exchange requirements have become essential to successful use of products in any locale.
6. Portability (Compatibility)
Our world is full of devices and it is essential that you determine which devices your end users can use to access your products and services. What kind of hardware? Will mobile be included? How many resolutions will you support? How many browsers? All of these questions will need to be asked and answered before development starts.
7. Usability
The majority of software used today is by people who did not build it. A well-coded back end is only as good as the front end design and user experience. The concept of usability includes incorporating considerations of user personas and the general target audience(s) into the system’s design and behaviors.
8. Compliance
As more and more of our lives take place online or are intertwined with technology, the more laws and regulations come to bear on how our technology is produced and must behave. There are levels to this, of course, from local to state to national and international. Your engagement depends, for the most part, on your target audience. However, certain things, like HIPAA compliance, are required for certain markets.
The reason compliance should be an early consideration is that it often comes with data and reporting requirements that must be built in from the beginning.
9. Availability / Reliability
Most importantly for web-based products, availability refers to the time the system is active between maintenance work or outages. In order to quantify this characteristic, analysts use data points such as the average of the time between system failure events. This gives us some idea of the system’s performance which we can use to set benchmarks.
Documenting NFRs
Understanding the types and identities of NFRs is an essential skill because client’s often do not understand or appreciate their complexity and importance. Moreover, because they are persistent qualities and constraints that give structure to a system, their effects need to be organized in a way as to enable referential integrity throughout the project lifespan. We recommend keeping this non functional requirements checklist easily accessible, so that you can reference it in the future.
A good way to think about NFRs and their documentation is to ensure each of them has the following qualities. They should be bounded, meaning constrained by a quantified limit. How is the requirement measured and what is the target or ceiling?
They should be independent, meaning they should have their own set of evaluation criteria. Because they are intrinsic characteristics of the system and will affect all or most of the work that will be done, they need to be negotiable. Lastly, they should be testable and eventually, all NFRs will have testing scripts written for them in detail.
NFRs Implementation
One of the main challenges of NFRs is that, unlike functional requirements, they affect work along the project timeline and sometimes throughout its entire lifecycle. NFR Implementation should be considered along two distinct paths.
If the NFR requires incidental implementation, such as compliance changes, your team must organize work for the deadline. Other requirements necessitate change over time and improvements can be made along the way. In any case, the most important consideration is how the requirements interrelate with various parts of the system, affect its behavior, and how that comes to bear on its development and maintenance over time.
Have a question about NFRs or our non functional requirements checklist? Contact us here.
Think it might be time to bring in some extra help?
Read these next...
Request a free project quote
We will review your request and provide a project cost assessment within 1 — 2 working days.
Request a free project quote