Classifying Requirements and Non-Functional Categories

Key ideas#

The Wiegers model at a glance#

In Karl Wiegers’ model, business rules inform business requirements (recorded in a vision and scope document), which lead to user requirements, which lead to functional requirements. In parallel run quality attributes, external interface requirements and constraints. Functional and non-functional requirements come together in the software requirements specification (SRS). The BABOK® Guide uses a different split (business, stakeholder, solution, transition), but the two map onto each other reasonably well. The levels are explained on Levels and Types of Requirements.

Four practical categories of non-functional requirements#

Kastsevich’s sketchnote, which sets Wiegers’ model next to the BABOK scheme, groups non-functional requirements (NFRs) into four buckets. Use them as prompts during elicitation:

Seven characteristics of a single requirement#

Wiegers and Beatty (ch. 11) list seven, and note who is best placed to judge each:

• Complete — contains all the information needed to implement it. Flag known gaps explicitly as TBD (“to be determined”).
• Correct — describes the needed capability accurately and does not contradict its parent requirement. User representatives judge this, not the analyst.
• Feasible — can be built within known technical, budget and time limits. Developers judge this.
• Necessary — traces back to a source with authority and to a business objective. You can answer “why is this here?”
• Prioritized — has an implementation priority.
• Unambiguous — every reader reaches the same reading. The authors describe two kinds of ambiguity: the author can see more than one reading, or, more dangerously, each reader sees a different reading that looks obvious to them.
• Verifiable — a tester can design a test that shows it is met. Without this, “is it done?” becomes a matter of opinion.

Four characteristics of a set of requirements#

• Complete — nothing is missing. Fully complete is not achievable in practice, and any specification with TBDs is formally incomplete.
• Consistent — no conflicts with requirements at the same level or above. Record the author of each requirement so you know whom to ask when conflicts appear.
• Modifiable — every requirement has a unique ID and is stated once. Text duplicated in several places will eventually drift apart.
• Traceable — each requirement can be linked back to its origin and forward to design, code and tests. You do not have to record every link, but the format must allow it: short, uniquely numbered statements rather than long narrative paragraphs.

Other versions of the list#

Kastsevich’s sketchnote gives a shorter list of six: clear, complete, applicable, prioritized, implementable (confirmed by developers) and testable (confirmed by testers), checked through peer reviews and walkthroughs. Maglinets’ lecture course, drawing on IEEE work and Wiegers, lists twelve properties. It adds a numeric metric for every NFR, ordering by both importance and stability, a split between necessary and merely useful requirements, and consistency both between levels and within a level. Maglinets also uses the trade-off triangle of resources, time and scope: change one side and the others must adjust, which is one more reason to state each requirement only once.

Where requirements come from#

Requirements come from people (stakeholders) and from documents (existing requirements, standards). Check that information is reliable and current, bring in a subject-matter expert when needed, and always have a stakeholder as the source of a requirement. Do not invent requirements yourself.