Requirements and success criteria

Why this matters

“The system must detect cracks well” sounds clear, but on delivery day the team and the user may argue about what “well” means. A well-written requirement works like a contract: it says what must be built, how it will be measured and when it counts as done. ISO/IEC/IEEE 29148 and the INCOSE guidance give the principles for writing requirements that are used worldwide.

From needs to requirements

Requirements are usually written in the pattern “[system] shall [do what] [under what condition] [measurable criterion]”, for example “The system shall identify canal bank cracks 5 cm wide or more with a recall of at least 0.90 on a test image set approved by the user.”

The INCOSE Guide to Writing Requirements, version 4 (2023), defines nine characteristics of an individual requirement: necessary, appropriate, unambiguous, complete, singular, feasible, verifiable, correct and conforming, plus a separate group of characteristics for a set of requirements, such as being complete and consistent.

import re

VAGUE = ["user-friendly", "fast", "quickly", "adequate", "sufficient", "easy", "approximately",
         "as appropriate", "etc", "and/or", "good", "robust"]

requirements = {
    "R1": "The system shall detect canal bank cracks of 5 cm width or more with recall of at least 0.90.",
    "R2": "The system shall be user-friendly.",
    "R3": "The drone shall fly fast and take good photos.",
    "R4": "The system shall complete one 2 km inspection round in at most 15 minutes of flight.",
    "R5": "The system shall store images and send reports and alert the office.",
    "R6": "The system shall mark each defect with coordinates accurate to within 3 m.",
}
for rid, text in requirements.items():
    words = text.lower()
    issues = [f"vague '{w}'" for w in VAGUE if re.search(r"\b" + re.escape(w) + r"\b", words)]
    if not re.search(r"\d", text):
        issues.append("no measurable value")
    if words.count(" and ") >= 2 or words.count(" shall ") > 1:
        issues.append("several requirements in one")
    print(f"{rid}: {'ok' if not issues else '; '.join(issues)}")

R1: ok
R2: vague 'user-friendly'; no measurable value
R3: vague 'fast'; vague 'good'; no measurable value
R4: ok
R5: no measurable value; several requirements in one
R6: ok

Prioritising with MoSCoW

A project has limited time, so the team must know what it must have and what it can cut. The Agile Business Consortium’s MoSCoW method uses four groups:

• Must have: the minimum set that must be delivered; without it the project has failed
• Should have: important, but the system is still usable without it
• Could have: desirable; this is the contingency when time runs short
• Won’t have this time: agreed not to be done in this round, and recorded clearly

The guidance is that Must effort should not exceed 60%. Above that the project is at risk of failure because there is no contingency when problems arise.

effort = {  # requirement: (priority, estimated person-weeks)
    "R1 crack detection": ("Must", 6), "R4 round time": ("Must", 3), "R6 coordinates": ("Must", 2),
    "R5a store images": ("Should", 2), "R5b send report": ("Should", 3),
    "R5c alert office": ("Could", 2), "R7 night flight": ("Won't", 0), "R8 web dashboard": ("Could", 2),
}
total = sum(e for _, e in effort.values())
for group in ("Must", "Should", "Could"):
    share = sum(e for g, e in effort.values() if g == group) / total
    print(f"{group:<6} {share:.0%}")
must = sum(e for g, e in effort.values() if g == "Must") / total
print("Must share OK" if must <= 0.60 else "Must share too high: move items or cut scope")

Must   55%
Should 25%
Could  20%
Must share OK

Verifying requirements

The NASA handbook lists four verification methods. Every requirement must have its method chosen when it is written; if you cannot think of a way to verify it, the requirement is not good enough yet.

Module lab

Common mistakes

Summary

• Requirements turn needs into “shall” statements with measurable criteria
• Good requirements have INCOSE characteristics C1–C9, such as being unambiguous, singular and verifiable
• MoSCoW sets priorities, and the Must group should not take more than 60% of the effort
• Every requirement needs a verification method: inspection, analysis, demonstration or test

Check your understanding

1. Which characteristic does “The system shall send reports quickly” violate, and how should it be fixed?
2. A requirement uses “and” to join three actions. Which characteristic does it violate?
3. Must work is 7 person-weeks out of a total of 10. Does it meet the MoSCoW guidance?
4. Which verification method is used to check that the registration marking is on the airframe?
5. What does “Won’t have this time” mean?