What comes first: Functional or non-Functional Requirements?
Well-defined features are the goal of most teams. A lot of the concerns I heard from teams were linked to the quality of requirements. Sure, we have a lot of areas to improve but are we starting at the right point?
Let’s speak about non-functional requirements (NFRs) as the foundation level for understanding of functional requirements.
What is the Source of Requirements?
What is the source of requirements in your project? Who gave you the scope of your work and who controls it? You are correct if you are saying that it is the team and anyone around who can bring the value to the end product. Usually your Project’s Backlog contains User Stories, Defects, Technical Improvements, Technical Debt etc.
But what if we take a step up in the hierarchy of our company? What is the source of requirements then?
A Company’s Strategic Goals are the ultimate Source for Requirements
Business is driven by money and interests in Return of Investment, Gross Margin and Profitability. Everything your team is working on is based on the business development strategy.
80% of project management executives don’t know how their projects align with their company’s business strategy (by changepoint.com)
Usually a business is set up to bring value to end customers. This value is represented by products/services it provides and is the part of Strategic Goals.
Where do we have NFRs?
Non-functional Requirements (NFRs) are the foundation of all of your business value. Don’t agree? Let’s see.
Here’s a complex issue: tech stories or non-functional items or whatever you want to call them. I can’t help giggling whenever someone talks about “non-functional requirements”. Sounds too much like “things that shouldn’t function”. :o) I’m referring to stuff that needs to be done but that is not deliverable, not directly related to any specific stories, and not of direct value to the product owner. We call them “tech stories”.
- Henrik Kniberg
How well will the system perform? This is one of the question of NFRs. If you take a look at my drawing you may find out that the backlogs (levels) we usually have on our projects are based on NFRs. Why? Basically due to the fact that in user-oriented development we operate with user (or consumer) expectations of the system. And usually this is not a question of “How the system should work” but a question like “How do I expect the system to interact with me”.
A non-functional requirement is a requirement that specifies constraint that can be used to judge the operation of a system, rather than specific behaviors
When we speak about functionality only from the functional side we can miss a very important and time consuming level called as “User Expectations” regarding system stability, reliability and speed.
Well, have we ever seen Facebook become unavailable? Maybe a few times, but they are continuously updating the system on a daily basis. This is the result of well planned NFRs by Facebook architecture on the epic planning level.
NFR Identification
Remember the golden rule — you are only ready for what you have planned. This means the system you are building should start with a single question: what is the user expecting from this system?
How fast should it work? What is the response time from our API? Are we going to support IE9? Do we need to invest time in this? Where and how are we going to log exceptions?
Remember on the Requirements level. Most of us mainly think about Business Requirements and User Requirements.
By identifying you NFRs for particular Epic/Feature/Story you have the ability to select proper tools, technologies and infrastructure components to reach your goal.
Managing NFRs. 3 Easy Steps
NFRs are much wider properties than “browser support” or “device matrix”.
Take a look at the table below, it contains the most popular areas of non-Functional Requirements.
Identifying NFRs is very easy. There are a lot of techniques you can use with your team:
- Interviews
- Brainstorm
- Prototyping
- Workshops
- Questionnaire
- End-User Requirements
- SLA, SLO
Step 1. Identification. When you discuss a particular Epic/Feature/Story think about basic parameters such as: How fast should it work, how can we control that the service works as expected, how are we going to scale the system? This are your NFRs which you have to manage in the backlog. We name them Enablers or Technical Stories.
After you understand the NFRs on the different levels you have to measure them to make acceptance criteria.
Step 2. System>Attribute>Metric. is the easy way to collect the “Measurable criteria” of the functionality. This will help you to define Acceptance testing.
Everything you can measure you can judge.
Step 3. Identify Impact. When you completed the NFRs backlog allocate time to identify the impact for each element in this backlog. Why? It is possible to skip some NFRs if needed, but people around have to understand what they risk when they miss and can take possible impact into account.
We use visualization for Impact. Visualization catches attention. And attention to NFRs is what we need, right?
Conclusion
Chicken or egg is the proper question to ask about requirements. Basically FR & NFR are flip sides of the medal. Theoretically you can make a development without NFRs specified, but then this “unknown” can appear at unexpected moment. As a good Project Manager/Scrum Master you have to try to decrease the level of unknown, right?
Thank you for reading! Feel free to hit the recommendation button if you found this article helpful!
If you want to stay updated with my latest articles feel free to subscribe!
*Text is based on my presentation on Kyiv PM Day Conference.
