Techniques BABOK Guide v3, 10.30
Non-Functional Requirements Analysis
In short Functional requirements say what a solution does; non-functional requirements say how well it must do it and under what conditions. This technique helps you find the qualities that matter, such as speed, availability, security, and ease of use, and turn each one into a measurable target that can be tested.
Based on: IIBA, BABOK® Guide v3, technique 10.30 “Non-Functional Requirements Analysis”; Watermark Learning, BABOK v3 Study Tables, section 10.30; K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 14; D. Paul, D. Yeates, J. Cadle (eds.), Business Analysis (BCS), 2nd ed., ch. 9–10.
On this page
What it is#
Non-functional requirements (NFRs) describe the environmental conditions and qualities under which a solution must stay effective, and the criteria for judging how well it operates. They are also called quality attributes or quality of service requirements. They do not describe specific behavior; that is the job of functional requirements.
The BABOK Guide organizes the technique around three elements:
- Categories — the kinds of quality you consider, such as performance, availability, reliability, security, usability, scalability, maintainability, portability, compatibility, and compliance.
- Measurement — how each NFR is expressed so that it can be checked.
- Context — the conditions under which the requirement applies: which users, which load, which times, which environment.
Wiegers and Beatty add a useful split. External attributes show up while the system runs and matter mainly to users, for example availability, performance, security, and usability. Internal attributes matter mainly to developers and support staff, for example modifiability, portability, and testability, but they still reach users indirectly. They also treat constraints, such as a mandatory platform or regulation, as a separate class that narrows the design options.
When to use it#
The Watermark study tables link the technique to 7.1 Specify and Model Requirements (defining quality-of-service attributes) and 8.1 Measure Solution Performance (defining the expected characteristics of the solution). In practice:
- as soon as the main functions are known, before architecture or vendor choices are made;
- when writing acceptance criteria;
- when evaluating a solution that is already running.
The study tables credit NFRs with a strong influence on whether a system succeeds and is accepted: they state the constraints the solution must respect and give measures of how well the functional requirements must be met.
Do not write NFRs for every category out of habit. Pick the ones that matter for this solution and record why you left out the rest.
How to do it#
- Start from a broad list of categories, so that you do not overlook a whole area of quality.
- Shortlist with stakeholders. For each category, ask whether it matters here and to whom. Write down why you excluded the others; Wiegers and Beatty recommend this.
- Prioritize the shortlist. Wiegers and Beatty suggest pairwise comparison: for each pair, ask “if we could have only one of these, which matters more?” You will need the answer when two qualities conflict.
- Elicit concrete expectations. Users rarely answer “how reliable must it be?” usefully. Ask about real scenarios, and, as Wiegers and Beatty suggest, ask what would be unacceptable; limits are often easier to state than goals.
- Add context. State the load, time windows, devices, and user groups to which each requirement applies.
- Make it measurable. Give each NFR a scale (what is measured, in which unit), a method of measurement, a minimum acceptable level, and a target. Wiegers and Beatty present Tom Gilb’s Planguage, which uses keywords such as SCALE, METER, MUST, and GOAL for exactly this.
- Check cost and trade-offs with the delivery team. Improving one quality often hurts another; extra security checks, for example, can slow response times.
- Link each NFR to the functions it applies to and to the tests that will verify it.
Example#
The Workshop, a fictional chain of 12 bike-repair workshops, is building online booking and repair-status notifications. The first draft said: “The booking site must be fast and always available.” After analysis (figures are illustrative):
| ID | Category | Requirement and context | Scale and method | Minimum | Target |
|---|---|---|---|---|---|
NFR-01 |
Performance | Available slots display after a customer picks a workshop, on a mid-range phone on a mobile network | Seconds to full display, 95th percentile, monthly test | 4 s | 2 s |
NFR-02 |
Availability | Online booking from 06:00 to 23:00 local time | % of that window in service, per month | 99% | 99.5% |
NFR-03 |
Usability | First-time customers book without help | Share of participants completing a moderated test | 7 of 8 | 8 of 8 |
NFR-04 |
Security | Customer phone numbers are visible only to staff of the booked workshop | Pass/fail access test | Pass | Pass |
NFR-05 |
Performance | Status message sent after a mechanic changes the status | Minutes, per message log | 99% within 10 min | 99% within 5 min |
The owner first asked for near-perfect availability. The development team explained that it would need redundant hosting at a much higher cost. Because customers can still phone to book, the owner accepted 99.5% as the target; the study tables warn that overly strict NFRs drive up development cost and may need negotiation.
Common mistakes#
- Leaving NFRs until late. The BCS book warns that NFRs are often deferred or treated superficially, and links this to real failures such as insufficient capacity at launch and unusable web forms. → Discuss quality from the first workshops.
- Vague adjectives (“user-friendly”, “fast”) → add a scale, a measurement method, and a target.
- Naming a mechanism instead of a need (“use passwords”) → state the need (“only authorized staff can see customer contact details”), as Wiegers and Beatty advise.
- Gold-plating → strict targets cost money; agree on what is good enough.
- One number with no context → state load, conditions, and user group.
- Ignoring conflicts → prioritize qualities so you know which wins.
- Forgetting internal qualities → ask developers and support staff about maintainability and testability.
- Arguing over qualitative NFRs → the study tables note some NFRs are hard to measure on a scale; agree on a proxy measure or a test procedure.
Template#
| ID | Category | Requirement (what, for whom, under which conditions) | Scale and measurement method | Minimum | Target | Applies to | Rationale / source |
|----|----------|-----------------------------------------------------|------------------------------|---------|--------|------------|--------------------|
| NFR-01 | | | | | | | |
Checklist#
- Categories reviewed and exclusions explained
- Remaining qualities prioritized against each other
- Each NFR has context, a scale, a method, a minimum, and a target
- No implementation mechanism disguised as a requirement
- Cost and trade-offs checked with the delivery team
- Each NFR linked to functions and to verification tests
Sources and further reading#
- IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.30 “Non-Functional Requirements Analysis”.
- Watermark Learning. BABOK v3 Study Tables. 2016. (study aid for the BABOK Guide). Section 10.30.
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Ch. 14 (quality attributes, Planguage, trade-offs).
- D. Paul, D. Yeates, J. Cadle (eds.). Business Analysis, 2nd ed. BCS, The Chartered Institute for IT, 2010. Ch. 9–10 (non-functional requirements).