Datasheet

What Is the Big Deal About Testing? ■ 5
When unclear requirements are translated into developers’
technical specifications, misalignment of the original ambigu-
ous business requirement and misinterpreted technical specifi-
cation results in significant rework. (Interestingly, the same
people who created the requirements and introduced problems
in the requirements phase couldn’t see their mistakes until the
user acceptance phase, when they could spot them.)
So, we recommend as a best practice for those people creating
requirements — double-check initial requirements for ambigu-
ity, contradictions, and incompleteness.
This effect is not limited to software. The following example
shows what can happen in situations where people omit neces-
sary details — they have a clear idea of what they want and
have made preconceived assumptions, but neglect to commu-
nicate the specifics of what they require.
Defects in this phase happen mostly because
the requirements themselves are incomplete,
ambiguous, or contradictory.
MQM.book Page 5 Wednesday, May 7, 2008 11:29 AM