What makes a great product? Is it just about features which are the functional requirements, or is there more to it like the non-functional requirements?
When building software in scrum, teams often focus on functional requirements, which are the things a system must do.
But what about non-functional requirements (NFRs)? Are they just an afterthought?
Let’s explore the two types of requirements, why they’re both important and how to handle the NFRs in scrum.
Difference between functional and non-functional requirements
Functional requirements: The what
Functional requirements define what a system should do. They focus on core functionalities that enable users to complete tasks.
Think of them as the must-have features in a product backlog.
Examples of functional requirements:
- A user must be able to log in with an email and password.
- The system should send an email confirmation after a purchase.
- An admin can add or remove users.
Non-functional requirements: The how
Non-functional requirements, on the other hand, define how a system performs.
They cover performance, security, usability, scalability, and other quality aspects that impact user experience.
Examples of non-functional requirements:
- The application should load within two seconds.
- The system must handle 10,000 concurrent users without downtime.
- User data should be encrypted to ensure security.
Why are NFRs often overlooked?
Scrum teams often prioritise functional requirements because they are visible and measurable.
After all, it’s easier to showcase a new login feature than to prove the system is scalable.
However ignoring NFRs can lead to performance issues, security vulnerabilities, and poor user experience.
How to handle NFRs in scrum?
1. Make NFRs visible in the backlog
If a non-functional requirement doesn’t appear in the backlog, they won’t get attention. Create user stories for NFRs just like functional requirements. For example:
User story for performance:
As a user, I want the homepage to load within two seconds so that I can quickly access information.
User story for security:
As a system administrator, I want all passwords to be encrypted so that user data remains secure.
2. Define acceptance criteria for NFRs
How do you know an NFR is met? Set clear acceptance criteria to measure success. For example:
- Performance: The homepage must load in under two seconds when tested with 1,000 users.
- Security: All data must be encrypted using AES-256 encryption.
3. Integrate NFRs into Definition of Done (DoD)
Want to ensure NFRs are always considered? Add them to the Definition of Done (DoD). For example:
- Code must meet performance benchmarks.
- Security tests must pass before deployment.
- System should be tested for scalability.
4. Discuss NFRs in sprint planning
Sprint planning isn’t just for functional work. Discuss NFRs early so they don’t become last-minute surprises. Address questions like:
- How will this feature impact system performance?
- Does it introduce new security risks?
- Can our infrastructure handle increased load?
Functional vs. Non-Functional: Which one matters more?
Both are equally important!
Functional requirements deliver features, while non-functional requirements ensure quality.
A product with great features but poor performance is frustrating to users. Likewise, a highly secure, fast system without useful features won’t succeed.
Scrum teams must give non-functional requirements the same priority as functional ones.
By making NFRs visible, measurable, and part of the backlog, teams can build software that not only works. It also works well.
So, next time you refine your backlog, ask yourself a question. Do we focus only on what the system does? Or do we also consider how well it does it?
If you want to learn more about handling NFRs in agile, here is a detailed guide. This guide provides comprehensive information. It explains the process step by step.
I hope you found this post helpful.
