Functional Requirements
Functional Requirements (FR) define what the system should do. They describe specific behaviours and are best communicated in User Story format.
Example:
As a customer, I want to be sent a tracking link when my order is marked shipped, so that I know when to expect delivery
Non-Functional Requirements
NFRs, on the other hand, deal with how the system should operate. They ensure qualitative aspects like performance and security.
Example:
The login screen must load in under 3 seconds and support up to 5,000 users simultaneously.
It’s common for NFRs to take a back seat in requirement gathering sessions. Such topics are rarely met with the same excitement or urgency as customer facing features, yet they are critical to a project’s success and tend to be much harder to retrofit.
Getting Started with NFRs
It’s important to start by identifying key NFRs early in the process. Even without detailed specs, having agreed upon NFRs sets a foundation for success.
Here’s a list of common NFRs for web-based systems:
- Security: Internal or external application, data sensitivity, third party vulnerabilities, compliance needs
- Performance: Speed under expected load
- Accessibility: WCAG, device compatibility
- Scalability: Do we need architecture that supports horizontal scaling
- Maintainability: Who will do the work, how much documentation is needed, what does code quality look like
- Testability: Manual or automated? Unit, Integration, E2E?
- Reliability: Redundancy, SLAs from third parties
- Recoverability: Disaster recovery