Nonfunctional Requirements are the Key to User Adoption

Functional requirements in software development are obligatory because they define what the application does and satisfy system use cases. How the application goes about doing that—the so-called nonfunctional requirements—can be more important, however, because they determine constraints and restrictions on the design of any system. Nonfunctional requirements address an application’s scalability, extensibility, stability, security, reliability, and availability for the user.

Addressing nonfunctional requirements (NFRs) is key to the success of any project or program because the best, most feature-rich products in the world will only garner user adoption if they meet the “ilities” named above. The product may perform its function, but if it does not do so within acceptable parameters then usage of the product declines, sometimes to the point where users consider it a hindrance to performing their jobs.

NFRs are also essential to meeting contractual service-level agreements (SLAs) between developers and clients (users). For example, an SLA may hypothetically require that a system support 100,000 users concurrently across all time zones. Or it may require that data be cached or compressed so it can be accessed by users in austere environments with low-bandwidth connectivity. The ability to comply with those SLAs may determine whether the customer’s needs are satisfied or not, ultimately determining if the product is successful or becomes shelfware.

A nonfunctional requirement is something that can impact either the adoption of, the use of, or the agreements that you have with your customers—all of which could make it more likely that customers will take their business elsewhere.

As such, NFRs should be top of mind for company product managers and product owners, development teams, organizations undergoing digital transformations, third-party product development outfits, as well as those looking to improve the way employees, partners, and customers access needed data.

NFRs are Out of Sight

Like the hidden, underwater part of an iceberg, many requirements in software development are for NFRs that are out of sight of the user. These can be at the core of the application and include everything from:

• How to store the responses (in a database, spreadsheet, or plain text file)

• How they will protect the data while it moves across networks and while it is at rest

• How to provide authorized users access to the data

• Which programming language to use

There should be nonfunctional requirements associated with every piece of functionality. Typical NFRs fall into a variety of buckets that include:

• Performance – how quickly does the application respond to user input?

• Capacity – how many users can access the application at the same time?

• Extensibility – how easy or hard is it to make changes and updates to the application?

• Availability – how much time can the users tolerate the application not being available?

• Usability – how easy is it to use?

• Regulatory – does it meet applicable laws and regulations?

• Security – is it safe from attack and abuse?

There are dozens of other NFRs that relate to specific functionality and may even be industry-specific. They may include backup, configuration management, disaster recovery, compliance with privacy regulations, readability, testability, and throughput.

Security: A Key Nonfunctional Requirement

Security is one of the most important nonfunctional software requirements but is sometimes looked at as an afterthought. When security controls are not considered during development—or when they are bolted on post-development—companies risk the loss of intellectual property and potentially expose their customers’ personal identifiable information. In addition to these risks, companies face reputation losses and potential fines imposed for data breaches that can quickly exceed the costs of meeting applicable compliance regulations.

However, those detriments are easily avoided, costs are saved, data is protected, and solutions are improved when security is considered upfront as an NFR and is included in all phases of an implementation, regardless of the methodology.

Authentication/authorization is one example of a security NFR that applies to industries ranging from online retailers to parts manufacturers. For the latter, companies that offer their customers products and services like technical publications, service bulletins, customer support, and subscription-based services need to be able to control individual access to all the offerings.

Best Ways to Ensure NFRs are Collected

In Sila’s case, the discovery process requires close cooperation between our clients and our project team including business analysts, developers, product owners, and architects.

Discovery should also extend out beyond the client and development team relationship to include the end users and customers of the application(s). In the aerospace industry, for example, these could be the actual aircraft operators, parts distributors, or maintenance facilities who can share their pain points. In retail organizations, we engage with the customers of retail clients and those who interact most closely with their customers, to understand their issues.

To facilitate NFR discovery:

• Do ensure the development team and clients understand why NFRs are important. Set the stage for success and be proactive about preventing unnecessary rework down the road.

• Do have interactive design sessions as part of discovery where developers and clients are challenged to think about how the application will be used. Will it be deployed globally? Are there language issues associated with the application? Should the application only run on certain types of servers? Is a certain connection speed required, and do all your customers have that? This necessitates an understanding of your business model and customers.

• Do use iterative software development methodologies such as Agile paired with a DevOps culture to facilitate the discovery of NFRs that were not initially identified. When the development teams are doing quick turns and delivering software every two-to-three weeks, you are routinely evaluating and assessing the product for new functional and nonfunctional requirements that necessitate changes in the design.

These discovery processes are essential because they will define the service level agreements that need to be met contractually. They can also drive the design, architecture, and approach to the project, while identifying NFRs you need to keep customers happy.

Takeaways

Nonfunctional requirements are sometimes an overlooked component of product development because they tend to be less visual and more implicit. They may go unnoticed until customers complain.

For this reason, addressing NFRs is critical—regardless of how functional or feature-rich your product may be. If it does not work in alignment with customer expectations in terms of response time and other NFR metrics, then it won’t be embraced.