There are a number of “rules” for writing requirements statements. These
rules help to ensure that the requirements can be clearly understood and
that it is possible to determine whether or not the new system meets
each of the requirements. Poorly written requirements lead to
misunderstanding and misinterpretation and can lead to a system that
does not do what the users need it to do.
The analyst uses the list of requirements that the users identified and
rewrites each requirement to meet the criteria listed below.
Each requirement statement:
• Either describes a task that the user needs the system to
perform, or states a system performance expectation.
• Identifies only one requirement; avoids the words “and,” “also,”
“with,” and “or.”
• Is a complete sentence, with a subject (usually “the system”) and
predicate (intended result, action or condition).
• Uses “must” (not “may” or “should” or “will” or “shall”); written as
“The system must….”
• Is generally stated in positive terms (i.e., “the system must xxxx” vs.
“the system must not xxx”); however, there are times when “must
not” is the more appropriate way to express the requirement.
• Is measurable; includes a measure or metric that can be used to
determine whether the requirement is met (e.g., time or quantity),
where appropriate; avoids the use of terms that cannot be defined
and measured, such as “approximately,” “robust,” “user friendly,” etc.
• Is achievable and realistic; avoids terms such as “100% uptime,” or
“no failures.”
• Is complete; it can stand alone and be understood.
• Must be testable; that is, there must be some way to test the system
to determine whether the requirement is met.