The Devil is in the (Non-Functional) Details

Some systems are a joy to use. Others create extreme frustration and waste valuable time. Why? What’s the difference? Well, let’s think about the characteristics of good and evil systems:

The “angels” of systems are:

• intuitive, easy to use
• fast
• reliable, always up and running
• error free (mostly)

The “devils”:

• frequently down
• glitches kick you out and force you to login multiple times
• lock-up and cause you to restart your computer
• can’t easily customize your user experience
• poor help features
• not intuitive, hard to use, hard to find what you need
• processing time is slow
• doesn’t work on mobile devices

It’s not that the devils lack key features. In fact, the devil systems have great features we want to use, but we can’t access them. These frustrating systems waste our time. Our complaints trace back to missed or incorrect non-functional requirements (aka: quality of service requirements or supplementary requirements).

The challenge I will put out to you, ask your stakeholders and users what they don’t like about the system . . . they will likely tell you all about the things they don’t like and these are likely missed non-functional requirements. Our stakeholders, users and even ourselves take for granted and assume the non-functional aspects of systems.

Protecting Value

As a BA, your job is to protect value—to ensure that business sponsors get the results they expect. While you identify needs, define features, write use cases, uncover business rules and manage issues, don’t forget about the non-functional requirements!

Missing non-functional requirements can:

• Increase project risks
• Dramatically reduce stakeholder value
• Limit the productivity of internal and external users
• Create foundational defects that are difficult and expensive to fix

Defining non-functional requirements

Non-functional requirements:

• Describe the constraints or quality of the service/system/process/product as a whole or
• Describe constraints or quality measure of individual features or requirements.

Common categories of non-functional requirements include:

• Security -What requirements are needed to prevent misuse, keep unintended users out, authenticate users, keep data confidential to the appropriate users and non-users, and which actions can be taken by which users?
• Usability-Is the solution understandable to users? Do users intuitively know how to perform the action they want? Are there sufficient help resources or easily found contacts for help?
• Reliability & Efficiency-When does the system need to be available? What is needed to recover from errors effectively? What is the acceptable time for the system to perform certain functions?
• Transferability-Can the solution be used in other environments–technical or business? Does it need to be?
• Maintainability-What are the requirements around the ease of modifying the solution? How easy is it to add rules and logic, add users, change a component without impacting others?
• Compatibility-What other application, systems and solutions does the solution need to operate with?

Non-functional requirements example

An example always helps right? So, let’s use Angie’s Pizza Shoppe. They make most of their money delivering pizzas to busy downtown office workers during lunchtime. They want implement an online ordering system to minimize order errors and create efficient lunch delivery service. Check out these non-functional requirement examples:

Non-Functional Requirement	System or Feature Level
The system shall provide a way to recover/view orders when the system is down	System
Scheduled system downtime should be between 3AM and 7AM.	System
The time it takes a user to place an order online should be equal or less than the amount of time it takes to place a phone order, which averages 5 minutes.	System
Credit card numbers should be hidden from all internal users except the general manager.	Feature
When entering credit card information the system needs to return an authorization/approval of valid card to the user within 10 seconds of submitting.	Feature
The system should work on mobile device platforms (Apple, Android) as well as desktops and laptops.	System
Angie’s Pizza Shoppe toppings vary by season. Internal users need to be able to modify the topping list daily, without a system release.	Feature

Documenting non-functional requirements

Obviously, requirement deliverables vary widely across projects and organizations, but you need to find a way to:

• Elicit non-functional requirements from stakeholders
• Review/prioritize non-functional requirements with stakeholders
• Share non-functional requirements with sponsors, developers, testers, etc.

When determining the best way to document non-functional requirements for your project, remember that some will trace to the whole system and some will trace to features, user stories, or individual requirements. You might “document” the non-functional requirements by:

• Creating a separate non-functional requirement document
• Adding them to your requirement list denoting NFR in the “requirement type column”
• Listing them at the end of each use case
• Adding them to your user stories acceptance criteria
• Communicating these requirements verbally to the developers on your team
• Listing them on your process models and flow charts

Let’s not create devilish systems by ignoring non-functional requirements at the system whole or feature levels. Don’t assume your developers and testers understand system constraints or quality measures. Let’s be mindful of the value non-functional aspects of the solution bring to our users and stakeholders.

Don’t forget to leave your comments below.