Part 4: Excellent Requirements and Requirement Collections: 19-Soft-A5 Requirements and Specifications, May 2015, Q4

Part 4: Excellent Requirements and Requirement Collections (20%)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Characteristics of an individual excellent requirement. These seven properties (essentially the IEEE 830 / ISO 29148 quality characteristics applied to a single requirement statement) are each described briefly below.

Characteristic	Brief explanation
Complete	The requirement states everything it needs to, with no missing information the reader must guess at — every function, condition, response and unit of measure it should specify is actually present in the text, not left implicit or "to be determined."
Correct	The requirement accurately represents a real capability, condition or constraint the system must satisfy; it reflects what the stakeholders actually need and what the system is genuinely capable of, not a mistaken restatement of either.
Feasible	The requirement can actually be implemented within the project's real technical, schedule and budget constraints; a technically perfect requirement that no team could build with the available time, skills and technology is not excellent, however well written.
Necessary	The requirement is genuinely needed — traceable to a real stakeholder need or business objective — and its omission would leave a real, identifiable deficiency in the system; requirements included "just in case" or because they seemed like a good idea fail this test even if they are otherwise well formed.
Prioritized	The requirement carries an explicit indication of its relative importance or urgency (e.g. Must/Should/Could, or a numeric rank) so that, when schedule or budget forces a trade-off, the team knows which requirements can be deferred or cut without guessing.
Unambiguous	The requirement has exactly one interpretation for every reader, technical or non-technical; if a business analyst and a developer can honestly read the same sentence and reach two different understandings of what is required, it is ambiguous, however grammatically correct.
Verifiable	There exists a finite, practical way — a test, inspection, demonstration or analysis — to determine objectively whether the delivered system satisfies the requirement; a requirement that cannot in principle be checked ("the system shall be user-friendly," unquantified) is not a real requirement no matter how well-intentioned.

Characteristics of an excellent requirements collection. These three properties apply to the requirements set as a whole, not to any single requirement in isolation.

Characteristic	Brief explanation
Consistent	No two requirements in the collection contradict one another, either directly (one says a field is mandatory, another says the same field is optional) or indirectly through their combined effect (two individually reasonable rounding rules that together violate a stated accounting-balance requirement); consistency is a property of the set, and checking it requires comparing requirements against each other, not just reading each one alone.
Modifiable	The collection is organized (structured, cross-referenced, free of unnecessary redundancy) so that a single change — a new regulation, a stakeholder correction — can be made cleanly in one place without leaving stale, contradictory copies elsewhere in the document; a requirements set where the same fact is restated in five places is unmodifiable even if each individual restatement is itself correct and clear.
Traceable	Every requirement in the collection can be traced backward to the stakeholder need, business goal or higher-level requirement that motivated it, and forward to the design element, code and test case that satisfies and verifies it; this bidirectional trace is what makes it possible to answer both "why do we need this?" and "what would break if we removed this?" for any requirement in the set.

Concept & Theory

Topic. Requirements-quality characteristics: per-requirement (IEEE 830 / ISO 29148) versus per-collection.

Key relations. Individual-requirement characteristics (complete, correct, feasible, necessary, prioritized, unambiguous, verifiable) are checkable by reading one requirement statement in isolation; collection characteristics (consistent, modifiable, traceable) require comparing requirements against each other and against the surrounding documentation structure, and cannot be assessed from any single statement alone.

Why this works. Separating the taxonomy into "properties of one requirement" versus "properties of the set" mirrors exactly how these are checked in practice — a requirements review can assess unambiguity and verifiability requirement-by-requirement, but consistency and traceability need a cross-referencing pass over the whole document (or a requirements-management tool) — and it is why a set of seven individually excellent requirements can still form a poor collection if, for instance, two of them are mutually inconsistent.

Common pitfall. Confusing "unambiguous" (one requirement, one reading) with "consistent" (two requirements, no contradiction) — a requirement can be perfectly unambiguous on its own and still conflict with an equally unambiguous sibling requirement elsewhere in the document; unambiguity is checked one sentence at a time, consistency is not.

Source. ISO/IEC/IEEE 29148 (requirements quality characteristics); Wiegers & Beatty, Software Requirements, 3rd ed.; Sommerville, Software Engineering, 10th ed., §4.6 (Requirements validation).

Question 4 of 4: Part 4: Excellent Requirements and Requirement Collections

Part 4: Excellent Requirements and Requirement Collections (20%)