The Importance of Non-Functional Requirements

Max Arbow, Senior Product Manager at Mondo Robot

In order to do WHOLE product development, we need to consider both functional and non-functional requirements.

Functional requirements describe what the system should do and how people need to interact with it. Non-functional requirements (NFRs) are qualities and attributes of the product. They are aspects that users have implicit expectations about with regard to how well the software will work.

Requirements may cover, how easy the application is to use, how reliable it is, how sustainable it is over time, how adaptable it is, how well it behaves when unexpected conditions arise, and much much more.

When scoping a project it’s important to capture and agree on non-functional requirements with your client. If you don’t, you run the risk of not meeting client expectations or having major scope creep throughout the development process.

A good method for capturing non-functional requirements: Use what they call anti-stories. When scoping a project, ask your stakeholders these six words: “What do you want to avoid?”

Expect to hear statements along the lines of:

• “I can’t go out and hire like 10 people to support this.”
• Translated to: “The application needs to reduce overhead and support, rather than add new FTEs. It needs to focus on operational efficiencies so that the team can focus on more important tasks. Time to train and onboard employees need to be minimal.
• “My shopping cart abandonment rates can’t go up — this a an enterprise KPI that is tied to all of our employee's performance bonus.”
• Translated to: “The shopping experience needs to focus on making it as easy and quick as possible to make a purchase. The application needs to not crash at critical purchasing points and if it does please let me know immediately.”

In closing, here’s a recap of the top 5 reasons you should care about NFRs:

• NFRs cover the areas of your product that imply a certain level of quality, and they are often unstated by your business stakeholders. As product developers, we need to anticipate these needs, avoid surprises and minimize those occasions where customers think that the product should be better.
• Non-functional requirements are often not scoped upfront and can cause major delays to delivery, not to mention unplanned costs.
• Stakeholders don’t regularly think about this stuff. It is up to us to have these conversations and to discuss the trade-offs before we assume a level of effort and/or risk to the client and the deliverable at hand.
• Many non-functional requirements need ongoing/regular attention. These need to be addressed in an SLA and accounted for in our budgets and SOWs.
• NFRs greatly inform technology decision-making when the most critical non-functional issues are known and documented. NFRs can dominate the architectural design process and also reduce a lot of uncertainty and churn within the team.