Protocol

Replace quality adjectives with observable conditions

An adjective cannot fail a test until the team agrees what it means.

When it fits

Acceptance depends on words such as fast, easy, robust, flexible, sufficient or user-friendly.

When to avoid it

Metrics can create false precision. Choose a threshold because it reflects a real need, not because a number looks rigorous.

Why it matters

Translate the quality word into the observable outcome that matters: timing, error rate, supported scenario, completion rate, accessibility criterion, recovery condition or other measurable evidence. If you cannot define it yet, keep it as a goal and mark the measurement question open.

Steps

Two reviewers using the same evidence can reach the same pass/fail judgement.

An example

'The report should load quickly' becomes 'For the agreed reference dataset, the report reaches an interactive state within the accepted performance threshold measured in the test environment.'

Check your result

Two reviewers using the same evidence can reach the same pass/fail judgement.

Keep this limit in mind

Metrics can create false precision. Choose a threshold because it reflects a real need, not because a number looks rigorous.

Connected ideas

Evidence and sources

Supports

NASA guidance warns against unverifiable terms such as easy, fast, adequate or user-friendly unless they are translated into criteria that can be tested, demonstrated, inspected or analyzed.

Qualitative goals can still be useful during discovery when they are explicitly treated as goals rather than acceptance requirements.

Appendix C: How to Write a Good Requirement · Verifiability/Testability

All sources (1)

Appendix C: How to Write a Good Requirement