What are non functional requirements in software engineering

August 11, 2020

What is a Non-Functional Requirement?

If you think of functional requirements as those that define what a system is supposed to do, non functional requirements (NFRs) define constraints which affect how the system should do it.

While a system can still work if NFRs are not met, it may not meet user or stakeholder expectations, or the needs of the business.

NFRs also keep functional requirements in line, so to speak. Attributes that make the product affordable, easy to use, and accessible, for example, come from NFRs.

Let’s get more specific.

Essential Tips for Modern Requirements Management | Perforce

Types of Non Functional Requirements

There are many common categories of non functional requirements.

NFRs are often thought of as the “itys.” While the specifics will vary between products, having a list of these NFR types defined up front provides a handy checklist to make sure you’re not missing critical requirements.

This is not an exhaustive list, but here’s what we mean:  

NFR “Itys”

Security — Does your product store or transmit sensitive information? Does your IT department require adherence to specific standards? What security best practices are used in your industry?

Capacity — What are your system’s storage requirements, today and in the future? How will your system scale up for increasing volume demands?

Compatibility — What are the minimum hardware requirements? What operating systems and their versions must be supported?

Reliability and Availability — What is the critical failure time under normal usage? Does a user need access to this all hours of every day?

Maintainability  + Manageability—How much time does it take to fix components, and how easily can an administrator manage the system? Under this umbrella, you could also define Recoverability and Serviceability.

Scalability – The Black Friday test. What are the highest workloads under which the system will still perform as expected?

Usability — How easy is it to use the product? What defines the experience of using the product?

“Ity’s” don’t cover all types, however.

Other Common Types of Non-Functional Requirements

Performance — How quickly does the system respond to users’ actions, or how long does a user wait for a specific operation to happen?

Regulatory — Are there requirements you need to satisfy for compliance?

Environmental — What types of environments will the system be expected to perform within?

📖 READ THE WHITE PAPER: 9 TIPS FOR WRITING USEFUL REQUIREMENTS >>
 

Non Functional Requirements Examples 

Now that you understand the types of NFRs, let’s look at some actual examples.

• Each page must load within 2 seconds.
• The process must finish within 3 hours so data is available by 8 a.m. local time after an overnight update.
• The system must meet Web Content Accessibility Guidelines WCAG 2.1.
• Database security must meet HIPAA requirements.
• Users shall be prompted to provide an electronic signature before loading a new page.

All of these add more specific restrictions or instructions to what would be functional requirements. Where the functional requirement defines the “what,” it often needs a NFR to define the “how.” So you might see something like:

Functional requirement: When an order is fulfilled, the local printer shall print a packing slip.
Non Functional Requirement: Packing slips shall be printed on both sides of 4”x 6” white paper, the standard size for packing slips used by local printers.

▶️ WEBINAR ON-DEMAND: ESSENTIAL TIPS FOR MODERN REQUIREMENTS MANAGEMENT >>

Best Practices for Writing Non-Functional Requirements

Our blog on functional requirements outlines some tips on how to write requirements well, and they apply to both functional and non functional requirements. Some include:

• Be consistent in terminology and format.
• Quantify requirements — if a stakeholder wants a website to load “quickly,” ask what that means (3 seconds or less? 2 seconds or less?)
• If you intend to reuse the requirement, write it as such — use “accept payment” rather than “accept payment through Apple Pay,” for example.

For the full list, and more on functional requirements, read the blog >>

More Best Practices on Requirements

After all the work you put into writing your requirements, you don’t want excessive changes — or requirements churn — to negatively impact cost, quality, or meeting deadlines. Fortunately, you can keep requirements churn in check. Click the button to download the white paper 5 Best Practices for Reducing Requirements Churn.

SAVE MONEY with reduced churn

Paula Rome

Senior Product Manager, Perforce

Paula is a Senior Product Manager for Helix ALM. With a diverse background, including roles from computational physicist to startup founder, she believes software should first and foremost make our lives easier. She specializes in application lifecycle management, with an emphasis on testing and requirements management. When out of the office, she’s always looking for a chance to play inline hockey.