OutSystemsDev Zone

Snow White and the 7 NFRs: The Truth About Non-Functional Requirements

Whenever I hear, ‘functional requirement,’ I think of Disney princesses. I think of Ariel and Cinderella. I think of how each is central to her story and embodies a specific identity, and then I think of the princess who stands out as a true metaphor for functional requirements – the one who reflects the role perfectly: Snow White.

Snow White and her 10 non-functional requirements

Snow White is a functional requirement if I ever saw one. She is at once central to her story, its main protagonist, its raison d’etre, yet surrounded by a host of supporting characters – dwarfs – whose roles are necessary for the story to be complete.  No dwarfs, no real story. It’s that simple. If a single dwarf is missing, the entire story is compromised. Snow White is compromised.

And it’s nearly the same with applications. If an application is the story and Snow White is the functional requirement, then we can think of dwarfs as non-functional requirements (NFRs). If a single NFR is missing from an application then that application is compromised. Deploying an unpredictable application is the same as adding maintenance issues and technical debt directly to your application portfolio. Eventually, that application will have to be addressed, those NFRs will have to be added, and the IT department who deployed the app will have to contend with the cost of changing software.

How does this happen? Changing and maintaining software is hard and therefore expensive to do and IT departments are often rushed or underfunded. However, if they are in a ‘Just do it’ mode then those operational, non-functional requirements that make an application
complete are easy to leave out or are ‘forgotten.’ The consequences of leaving these NFRs out of an application lead directly to the
aforementioned maintenance problems and increased technical debt.

Here’s the list of most common NFRs that we see our customers worrying about:

The truth about non-functional requirements: maintainability dwarfThe truth about non-functional requirements: portability dwarf
1. Maintainability

The ease with which the system can be changed, whether for bug fixes or to add new functionality. This is important because a large chunk of the IT budget is spent on maintenance. The more maintainable a system is, the lower the total cost of ownership will be.

2. Portability
The ease with which software can be installed on all necessary platforms and the platforms on which it is expected to run.
The truth about non-functional requirements: reliability dwarfThe truth about non-functional requirements: scalability dwarf
3. Reliability

The capability of the software to maintain its performance over time. Unreliable software fails frequently, and certain tasks are more sensitive to failure (for example, because they cannot be restarted, or because they must be run at a certain time).

4. Scalability

Software that is scalable has the ability to handle a wide variety of system configuration sizes. The nonfunctional requirements should specify the ways in which the system may be expected to scale up (by increasing hardware capacity, adding machines, etc.). Scalability ensures usability for five users or five thousand.

The truth about non-functional requirements: flexibility dwarfThe truth about non-functional requirements: auditability dwarf
5. Flexibility

If the organization intends to increase or extend the functionality of the software after it is deployed, that should be planned from the beginning; it influences choices made during the design, development, testing, and deployment of the system. Flexibility is the ease with which the system can be reused, deployed, and tested.

6. Auditability

When something goes wrong, you need to understand the root cause of it. So it is normal that auditability is a common NFR. The problem is that you hardly remember to have all the checkpoints in the process, all the exceptions logged, and to ensure that the subsystem to support it does not interfere with your application performance.

The truth about non-functional requirements: documentation dwarfThe truth about non-functional requirements: performance dwarf
7. Documentation

It’s hard to keep complex system documentation up to date. Even if you’re able to document the initial version of your application, by the time you’ve finished, the application has changed and its documentation is outdated.

8. Performance

The performance constraints specify the timing characteristics of the software. Certain tasks or features are more time-sensitive than others; the nonfunctional requirements should identify those software functions that have constraints on their performance.

The truth about non-functional requirements: security dwarfThe truth about non-functional requirements: usability dwarf
9. Security

Integrity requirements define the security attributes of the system, restricting access to features or data to certain users and protecting the privacy of data entered into the software. (Download OutSystems Success Story with HP Fortify to learn how we do it)

10. Usability

Usability relates to how easily users can learn how to use a system and how efficient they are while using it. Highly usable systems reduce the effort required to read or input data and prevent users from making errors resulting in increased operational efficiency.


Like Snow White’s dwarfs these NFRs are necessary to complete the story of the application. While you might consider 2 or 3 important NFRs for a project (like performance and security), you’ll probably skimp on others, or you might miss out on them all together.

And if you do allocate time to deal with them all, when the project schedule slips, an NFR may be the first thing you drop… because no one really sees them, and your team will be looking at the functional requirements instead.

So, whether you plan for NFRs or not, chances are high you won’t cover them 100% of the time in your development project. You’ll compromise and overlook the whole story – the whole application.

But you should try. You should try to avoid adding technical debt and maintenance nightmares to your future portfolio whenever possible. The cost of change is real, and the moment you deploy your app, you’ll have to address its problems.

From your experience, what are the NFRs you constantly see developers and project teams dropping most often?


About the author

Gonçalo Borrêga

After ten years of hardcore development, Gonçalo got bored with the repetitive tasks that are required project after project. So, he adventured into finding the best way to bring automation and productivity to the rest of us.


Hi Goncalo,
Nice story above almost as nice as Snow White and the seven dwarfs.
Most NFR I encounter are:
– scalability (easy hackable environments for as far as you may call it hacking)
– inconsistent interface (a very common one)
a. button or icon (when should you provide the user with a delete button and when will you display a red cross for a delete action)
b. To pop-up or not to pop-up (popping up drills down the level blurring the higher level but it also provides some technical hassle sometimes. (NotifyWidgetGetMessage())
You don’t want to slow the interface down just because you need to make like 4 web calls in order to make the interface refresh properly.
– bad (re)use of common libraries

When you say scalability and relate it to “easy hackable environments”, I’m more inclined to relating it to Reliability, which is more related to how tolerant the system is in case something goes wrong in the process (e.g. if a third party system is unresponsive or lacking performance, how can I 1) troubleshoot and be aware the problem is there and 2) ensure my own system does not fall apart because of that). Not only creating less point of failures, but monitoring them is key there. I read one book (Release It) a bunch of years ago that gives great, real examples on this. Worth the read.
On the inconsistent interface… I think its really about Usability. And it is definitely one that is usually put aside. I believe the main reason it is “forgotten” is because, as Software Engineers, we struggle to find proper scientific education on the rules of usability. It is something that still lies in the field of UX or Visual Design… For all others, there are strict engineering practices to address them (just search for software architecture and you’ll find tons of info to add up to what you’ve learned in college). For usability, it’s a totally different story. Whatever is out there is mainly for public, consumer facing, web sites. But on Enterprise applications this is getting more and more important as the expectations of the users are exactly at the same level as the one they have when they use online consumer sites… Will IT ever be able to provide the same level of experience in their complex enterprise applications?

I love the analogy, Goncalo. I’ve found the changing the terminology can improve things too: instead of “non-functional requirements”, which sounds like they don’t do much, the term “operational features” helps Ops and Dev to talk about these requirements in the same way as with end-user features.
I blogged about this here:
In particular, the operational features are scheduled alongside end-user features for sprints/iterations, and the product owner takes responsibility for the operability of the software, as well as delivery of end-user features.

[…] OutSystems Blog » Functional Requirements and Their Poor Cousins: The Truth About Non-Functional Re…. […]

Ron B

the analogy is priceless makes u think “how nobody thought of it before 🙂

[…] I’d recommend Gonçalo Borrêga’s fun explanation of non-functional requirements in his article on Outsystems. He explains that while the functional requirements are like Disney princesses, the […]

Leave Your Comment