(Image credit: Adobe Stock.)
Whether partnering with a custom solutions provider, creating a home-brew application, or purchasing an out-of-the-box product, most companies will follow a standard approach for evaluating their needs for a new or updated system. Commonly, the first step is to identify the core functional requirements that need to be satisfied. First and foremost, the solution must meet the base business and process needs. However, this is only half of the first step. These core functional requirements typically will only address how something works but not how well it works. To completely identify requirements includes considering the non-functional requirements (NFR) of the system. It can be argued that this second half of requirements is as important as the first, if not more so in some cases.
Non-functional requirements differ from functional requirements in several important ways. Functional requirements describe how a system will work: what screens will users see, how the screens transition from one to the next, what data can be entered, how and when will the data be saved and retrieved, and so on. These are commonly seen through the lens of the primary users of the system, as they must have these requirements met in order to do their jobs.
Functionality and Quality
By contrast, non-functional requirements describe the quality of a system. This simple but broad description covers a number of attributes including performing well under normal and extreme usage patterns (performance and scalability), quickly adapting the application to changing or varying business rules (configurability), addressing productivity for novice and expert users (usability), and preventing unauthorized access or transfer of data (security). These sets of requirements can be seen and experienced by many stakeholders beyond just the primary end-users. Viewing it this way, it is clear that outlining and fulfilling only the functional requirements could lead to a half-baked solution.
It is not uncommon or unexpected for a customer to be focused primarily on the functional requirements, as the visible and tangible assets can create the perception of a high-quality system. Often, non-functional requirements can be prioritized lower or treated as afterthoughts constrained by time, budget, and resources. This is a mistake. Non-functional requirements have a significant impact not only on the architecture and design of a system, but also on the long-term total cost of ownership (TCO).
To illustrate this, consider Amazon.com and the architecture, infrastructure, and hardware required to maintain a system serving over 150 million unique users per month. Even when stripping the site down to the most basic features of e-commerce (search, add to cart, and checkout), having such an enormous user base demands constant up time, a highly responsive system, and an ordering process simple enough for your grandmother to send you a birthday present. Hiccups in any of these areas could be costly. In 2013, merely 30 minutes of down time cost Amazon nearly $2 million. This is, of course, is an extreme example, and the engineers at Amazon have created a remarkably robust architecture to prevent disruptions, but the site would not function as well as it does without having considered the needs of the company beyond its front-facing capabilities.
Given that non-functional requirements are not a new concept, one would hope that they have become so ubiquitous in software development that major applications should never experience such issues. Unfortunately that is not the case. In 2016, the launch of the highly anticipated mobile game Pokemon Go attracted over 50 million players in the first month after release. The game gave players the chance to capture and power up fantasy creatures—Pokemon—in an augmented reality platform, an exciting experience for players familiar with the video game series. This massive userbase overwhelmed the game’s servers often preventing users from logging in or reliably playing the game in the first few weeks. Additionally, features within the game, such as tracking nearby Pokemon, were slowly disabled and removed over time due to the volume of network traffic between the client and the servers. While features met their functional requirements well, it appears that non-functional requirements were not given adequate weight. Overall, this led to a poor user experience until the game stabilized.
The Bigger Picture
The importance non-functional requirements can be demonstrated to be more than stretch goals or afterthoughts by connecting their value to important business goals. Projected growth, potential features, geographic expansion, or the execution of a company’s long-term strategy can be hindered by the dreaded “system constraints” born from neglecting NFRs.
Given these observations, what are some considerations for specific non-functional requirements? Let’s review two of the aforementioned non-functional requirements as a way to better understand see how they connect to business goals, and identify key areas of focus.
A thoughtful product owner will consider how much and how quickly a system’s user base will grow. Building a system only for the present or average load can limit growth and significantly limit business goals. Scalability non-functional requirements are as much a business issue as they are an IT issue. Though a solution can be quickly developed, tested, and deployed without considering how a system might function under increased load, addressing scalability concerns may be more difficult to solve on a live system than one still on the drawing board. When considering how much a system may need to scale, a product owner must consider when the system is under the most load, including what time of day and what time of year. Perhaps most activity happens early in the morning or just after lunch. Maybe usage spikes significantly on weekends. Some industries, like retail, need to consider increased transactions leading up to major holidays. In any case, the system must be architected to handle peak loads as well as day-to-day traffic.
How might systems handle spikes in demand? A straight forward tactic is to scale-up existing hardware with improved components thus increasing overall processing power. A system can also scale-out by adding additional hardware and servers to serve more concurrent users. However, a scalability bottleneck can occur in any layer of a system’s architecture. Aside from the application running on its main hardware, less obvious areas to review include available network bandwidth, database responsiveness, and dependencies on external services and integrations.
Aside from hardware concerns, a system must be easily usable by its core audience to be a success. Usability as a non-functional requirement category entails too many parts to detail here. However, a key component that cannot be understated or overlooked is an understanding of what types of users will access the system. What about users who rarely access the application? Can such users stay familiar with the flow and nuances of the screens from session to session at that usage frequency? Are on-screen tips and a wizard-supported workflow helpful to guide users through a process? When accommodating novice or infrequent users, the application must have an intuitive and consistent layout to be accessible.
Conversely, an expert user who works on the system daily may find this level of hand holding more annoying than helpful. For power users, the layout of screens can focus on completing as many tasks as possible in an efficient way. This could mean that instead of a set of screens to enter one set of data, one screen with a different layout could allow for multiple entries at once with less on-screen help. Neither design here changes what data is stored from a user, thereby changing no functionally required fields, but the non-functional usability requirements must be assessed before the workflow is built to maximize the user experience.
Not Just How, But How Well
As solution providers increasingly deliver more functional, more stable, and more flexible software systems, the project leadership must consider not only how the product will work, but how well it will work. To separate and neglect non-functional requirements—or to prioritize them far below or after functional requirements—is to tacitly approve building an inherently flawed and incomplete system. To meet the business’ current and long-term goals, the product owners, architects, business analysts, and technical leaders must take a holistic approach to defining new features and updates. Over the long term, it’s more often than not that the non-functional capabilities of a system that determine its value and lifespan, and whether or not the company views it as a success, or just another sub-optimal delivery from IT.