Day 11: Non-Functional Requirements (NFRs)
Be Better Engineering Leader, a 30 Days Series
This is the third week of a series of daily lessons on how to Be a Better Engineering Leader. I recommend spending up to an hour on each lesson to gain insights into Product, Technology, and People—areas critical for every Engineering Manager.
As an engineering leader, it's not enough to ensure your team delivers product features; you must also ensure these features are built to last. This is where Non-Functional Requirements (NFRs) come in.
NFRs define the technical standards your software must meet to be performant, reliable, secure, and scalable. They complement the functional requirements set by Product Managers and ensure your tech stack maintains quality while scaling effectively.
Define Your NFRs
Define Essential NFRs for Your Tech Stack
Start Simple: Focus on 3-5 key NFRs that are most critical to your product’s success. Consider performance, scalability, reliability, usability, and security as starting points.
Customize for Context: Tailor NFRs to your product and tech stack. For example, a backend service might prioritize response times and uptime, while a mobile app might focus on performance or UX crashes.
Action Step: Use the Markdown or Notion template to document your initial NFRs. Make them specific and measurable. For example, “API response time should not exceed 2 seconds under normal load.”
Integrate NFRs into Your Development Process
Incorporate into 'Definition of Done': A feature is not complete until it meets its associated NFRs. This ensures quality is baked into the product from the start.
Sprint Planning and Reviews: Include NFRs in sprint planning and review meetings. Discuss potential impacts on performance, security, and scalability for upcoming features.
Action Step: Organize a team meeting to integrate NFRs into your Definition of Done and sprint planning. Use examples from the AWS Well-Architected Framework or Twelve-Factor App Methodology to guide the discussion.
Establish Measurement and Monitoring
Tools and Metrics: Select appropriate tools to monitor each NFR. For performance, consider using tools like Grafana or New Relic. For security, implement automated vulnerability scans.
Set Benchmarks: Define acceptable thresholds for each NFR. For example, backend uptime should be 99.9%, and the frontend should comply with Core Web Vitals for at least 90% of users.
Action Step: Set up a basic monitoring dashboard for one critical NFR. Start small, such as tracking backend API response times, and review this metric weekly with the team.
Iterate and Evolve Your NFRs
Feedback Loops: Regularly review NFRs in retrospectives or quarterly reviews. Adjust them as needed based on team feedback and changing product needs.
Stakeholder Input: Align NFRs with stakeholder priorities and business goals. For instance, if the product roadmap shows a major user growth target, focus more on scalability.
Action Step: Schedule a quarterly review session to assess the effectiveness of current NFRs and incorporate feedback from stakeholders and team members.
Extra Resources
Article For Paid Subscribers: Non-Functional Requirements
Blog Post: How to Build Collective Intelligence and Empower Decision-Making
Templates to Define Your First NFRs:
Examples of Inspiration:
Core Web Vitals - Essential metrics for web performance.
The Twelve-Factor App Methodology - Guidelines for building scalable and maintainable applications.
AWS Well-Architected Framework - Best practices for cloud systems.
Google's Site Reliability Engineering - Balancing reliability and feature development.
NFRs are not just technical details—they are strategic tools that ensure your product is functional, reliable, scalable, and user-friendly. Integrating NFRs into your development process bridges the gap between product features and long-term quality, creating a tech stack that is built to last.
Share Your Feedback
How valuable was this lesson for you? Please share your reaction, write the feedback in the comment, as a response to the email or talk to me directly on chat. I would be thrilled to get to know you better so I can adjust my content accordingly.
Has your friend forwarded you this lesson? Consider joining the “Better Engineering Leader” course. More details here.
Do you know anyone who can benefit from the content I share? If so, please forward this email to them.