Modelling and AnalysisLesson 1
Functional vs Non-Functional Requirements
10 minutes
Every requirement on a project sits in one of two buckets. Functional requirements describe what the system must do. Non-functional requirements describe how well it must do it. Getting this split wrong is the most common reason systems pass UAT but fail in production.
The clean definitions
Functional requirementA specific behaviour the system must perform. Verbs: calculate, store, send, validate, display, allow. Always answers 'what does the system do'.
Non-functional requirementA quality the system must exhibit while performing its functions. Performance, security, availability, usability, scalability, accessibility. Answers 'how well, how fast, how safely'.
Examples from an SA insurer
The same project produces both kinds. Three of each.
| Type | Requirement |
|---|---|
| Functional | The system must calculate a motor insurance premium based on the driver's age, vehicle, postcode and claims history. |
| Functional | The system must send an SMS to the policyholder when their claim status changes. |
| Functional | The system must allow an underwriter to override an auto-rejected quote with a documented reason. |
| Non-functional | A premium calculation must complete within 2 seconds at the 95th percentile under a load of 500 concurrent quotes. |
| Non-functional | All personal information (as defined by POPIA) must be encrypted at rest and in transit. |
| Non-functional | The system must be available 99.5% of the time during business hours (08:00 to 18:00 SAST), Monday to Friday. |
The FURPS+ taxonomy
A useful checklist for non-functional requirements. Walk this list when scoping any project so you do not miss a quality dimension.
1
Functionality
Features and capabilities. The functional requirements live here.
2
Usability
How easy the system is to learn, use, navigate. Accessibility (WCAG conformance) lives here in SA enterprise contexts.
3
Reliability
Uptime, error rates, mean time between failures, mean time to recover, data integrity.
4
Performance
Response time, throughput, concurrent users, resource consumption.
5
Supportability
Maintainability, testability, configurability, observability.
6
The "+": constraints
Design constraints, implementation constraints (must use specific tech), interface constraints (must integrate with X), legal/compliance constraints (POPIA, FICA, FAIS).
How to write testable non-functional requirements
Most non-functional requirements written by junior BAs cannot be tested. The fix is to add concrete numbers and conditions.
Bad: 'The system must be fast.'Cannot be tested. What is fast? For whom? Under what load? On what device?
Better: 'Quote responses must return within 2 seconds.'Testable, but missing context. What percentage? Under what load?
Good: '95% of quote responses must return within 2 seconds at 500 concurrent users.'Specific, testable, conditioned on realistic load.
Excellent: 'Under expected production load (500 concurrent users), 95% of quote responses must return within 2 seconds and 99% within 5 seconds.'Tail latency captured. Both happy and unhappy cases bounded.
Why this split matters
The shelfware risk
Most systems that 'meet the requirements but fail in production' fail on non-functional dimensions the BA never specified. The functional requirements were captured, the system does what it says, but it falls over at 200 concurrent users or takes 30 seconds for a simple query. Both kinds need explicit specification. The functional ones are easy to remember. The non-functional ones are easy to forget.
SA-specific non-functional requirements to watch
1
POPIA compliance
Personal information processing constraints. Often the regulatory non-functional driving the most design decisions on SA enterprise systems.
2
B-BBEE-relevant constraints
If the system is involved in procurement or supplier reporting, B-BBEE scorecard inputs are constraints.
3
Load shedding resilience
Specifically: the system should recover cleanly from an unplanned outage of up to 4 hours. Many SA enterprises spec this explicitly now.
4
Multi-language support
11 official languages, although English is the default. SMS notifications to retail customers often need at least 2-3 language support.
5
Bandwidth-constrained operation
Branch staff in low-bandwidth areas (rural, township, mobile data). The system must remain usable when connectivity is slow or intermittent.
Key Takeaways
- Functional = what. Non-functional = how well. Two buckets. Every requirement fits in one.
- FURPS+ is the checklist. Functionality, Usability, Reliability, Performance, Supportability, plus constraints.
- Non-functional requirements need numbers. Concrete thresholds, percentages, load conditions. Otherwise untestable.
- Shelfware usually fails on non-functional dimensions. The functional ones get captured. The NFRs get forgotten.
- SA context matters. POPIA, B-BBEE, load shedding, multi-language, low-bandwidth are common SA NFR categories.