SDLC & NFR
Consider the following scenario: you have spent 3-4 months on building a cool responsive app and you think you are ready to share it with the world. You have built this app with the latest JavaScript framework and you feel confident that once deployed it will run flawlessly. However, once it hits the market it times out after a couple of concurrent users on various pages and functionalities. Déjà vu? I think we have all seen it happen.
Waterfall model
If we think about processes and extensive testing with rigorous well-defined phases one after another, we can imagine that non-functional testing is in that plan somewhere. Why, because we are thinking about what kind of testing we will need upfront(analysis and design phase) and as non-functional requirements are operational aspects of a product or app these are considered as a separate phase in the GANNT-chart. This does differ quite a bit from iterative models which will get covered later in this blogpost.
However, it doesn’t mean that once something is planned that it will get the necessary focus / priority or will get executed. If a project is overtime and budget cuts are around the corner this phase will also be threatened.
Iterative models
SCRUM
In agile development you work in sprint-model with a typical breakdown of epic > story > task which means that the granularity is much more low level which means that non-functional requirements are much more difficult to define. This doesn’t mean that they cannot be defined and can’t be checked on a single story level but you need to think outside the box.
You could add an acceptance criterion on a single story for non-functionals for example: Functionality X should be able to function within 150ms on 50 concurrent users. However, you should always keep the bigger picture in mind which means the overall performance testing and not just a single functionality.
You can add non-functional requirements as your definition of done (DoD) for example once the organisation has defined a UX-guideline the development teams can add this in their DoD which means that all user stories should adhere to this guideline.
A last measure I want to give as a tip is adding specific user stories for non-functional requirements. This will empower the team to think about the non-functional requirements from a users’ perspective.
KANBAN
Kanban same same but different, I only want to mention a solution I saw from a team that worked Kanban, which had a separate swim lane for NFR’s so that they actually redesigned their process if necessary for a work item.
Team roles & NFRs
It is evident that non-functional requirements are important for any member of the team – be it scrum master, developer, QA, release train engineer or a support engineer. In each role however, the scope would be different.
I want to take the roles described above and give an insight into how non-functional requirements can differ between roles:
- Scrum master: for a scrum master it is critical to understand the costs that are created by not adhering to NFR’s for example by only prioritising them at the end of the sprint. This could lead to not targeting the sprint goal as committed to the customer.
- Product owner : as a business analyst or product owner you look at NFR’s from an end users’ perspective. This means that in your role as a proxy from business to techies you should be able to truly explain what an end user wants.
- Dev / QA engineers : for technical peers in a team, it’s very important to understand the impact and relevance of an NFR, per functionality he/she is working on or even on a full product.
NFRs aren’t just technical afterthoughts!
To conclude non-functional requirements aren’t just technical afterthoughts that stay invisible during the project, no, they are the foundation that determines whether your application is successful or fails in the real world. Wether you are using a waterfall or iterative approach, the key is to make NFR’s a shared responsibility across all roles rather than relegating them to a final testing phase.Remember, no amount of beautiful code or innovative features can compensate for an application that crashes under real-world usage.