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 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:
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.
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.
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.
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.
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?
