Quality Criteria For Requirements: List of Weak Words
Quality Criteria For Requirements: List of Weak Words
Quality Criteria For Requirements: List of Weak Words
Non-prescriptive only describe the outside behavior of the specified object, must refrain
from prescribing a specific technical solution.
Unambiguous do not use weak words without a precise meaning. A requirement is
unambiguous when it possesses a single interpretation.
List of weak words:
o a little, about, accordingly, actual, adequate, again, all but, almost, also, analogous,
another, anything, apparent, approximately, articulate, as a whole, at the most,
o basic, besides, best, better ,big, bit,
o certain, certainly, circa, clear, clearly, close by, closely, common, conditionally,
considerable,
o decided, dedicated, defined, definite, detailed, determinately, different, directly,
distinct, diverse,
o else, enough, especially, evidently, explicit, extensive, extremely, every
o few,
o grand, great,
o however, huge,
o if need, improved, in detail, in most instances, indeed,
o just,
o largely, later, like, likewise, limited, long-standing,
o maybe, mostly, much,
o nearly, necessarily, no case, no way, not exhaustive, obvious,
o of course, ongoing, or so, ordinary, other,
o particular, perhaps, persistent, possible, powerful, precise, presently, prodigious,
provisory,
o qualified, quite,
o related,
o satisfactory, seemingly, self-evident, separately ,several, shortly, similar, someday,
something, sometimes, soon, special, still, sufficient, sure, sustained,
o to be announced, to be confirmed, to be defined, to be desired, to be detailed, to
be determined, too,
o ultimate, uncommon, unique, unlike, usual,
o well, where
Verifiable The requirements must be verifiable in two ways: do the requirements satisfy
the sponsor's needs, and does the system satisfy the requirements. A requirement is
verifiable if it can be proved that the requirement was correctly implemented. Verification
may come via demonstration, analysis, inspection, or testing
o Are all of the requirements feasible? (I.e., possible to implement)
o Is each requirement testable or verifiable?
o Does each requirement use concrete terms and measurable quantities?
Agreed analyzed and clarified Reviewed and accepted by all parties (customer, supplier,
developer, tester). The software development process should begin with supplier and
customer agreement on what the completed software must do.
Validated and up to date Each requirement should document something the customers
really need or something that is required for conformance to an external requirement, an
external interface, or a standard and to make sure that the newest version of customer
requirements is available for all users and used for writing the requirements.
Correct Each requirement must accurately describe the functionality to be delivered. The
reference for correctness is the source of the requirement, such as an actual customer or a
higher-level system requirements specification.
Realizable (feasible) It must be possible to implement each requirement within the known
capabilities and limitations of the system and its environment
Traceable every aspect of the finished system should be able to be traced back to the
requirements.
o Is each requirement expressed separately, rather than intermixed with other
requirements
o Can each item be traced to its origin in the problem environment