[pic]

The Ambiguity Review Process

© Richard Bender
Bender RBT Inc.
17 Cardinale Lane
Queensbury, NY 12804
518-743-8755
rbender@BenderRBT.com

The Ambiguity Review Process

Purpose:

An Ambiguity Review improves the quality of requirements by making them deterministic, unambiguous, correct and complete. An Ambiguity Review is a testing technique that eliminates defects in the requirements phase of the software development lifecycle, thereby avoiding those defects from propagating to the remaining phases of the software development lifecycle.

Description:

Someone trained in the Ambiguity Review Process performs the Ambiguity Review. The Ambiguity Reviewer is not a domain expert, and is not reading the requirements for content, but only to identify ambiguities in the logic and structure of the wording. The Ambiguity Review takes place after the requirements (or a section of the requirements) reach first draft, and prior to them being reviewed for content, i.e., correctness and completeness by domain experts. The Ambiguity Reviewer identifies all ambiguous words and phrases on a copy of the requirements. If CaliberRM is used to capture requirements, then the ambiguities are documented directly in CaliberRM. A summary of the findings is presented to the requirements author.

Deliverables:

The Ambiguity Review deliverables include the following:

• If the requirements are in a document, then the ambiguities are documented on either a copy of the requirements or in a separate document. • If the requirements are stored in CaliberRM, then the ambiguities are documented directly in CaliberRM. • A summary of the Ambiguity Review findings. • Optionally, if a defect tracking tool is being used, all defects found in the initial Ambiguity Review are logged as one incident, with the number of issues noted. After the next revision of the requirements, if open issues remain, they are logged as individual incidents.

The Ambiguity Review Checklist:

The Ambiguity Review Checklist powers the Ambiguity Review Process. The Ambiguity Review Checklist identifies 15 common problems that occur in writing requirements.

ϖDangling else ϖAmbiguity of reference ϖScope of action ϖOmissions τCauses without effects τMissing effects τEffects without causes τComplete omissions τMissing causes ϖAmbiguous logical operators τOr, And, Nor, Nand τImplicit connectors τCompound operators ϖNegation τScope of negation τUnnecessary negation τDouble negation ϖAmbiguous statements τVerbs, adverbs, adjectives τVariables, unnecessary aliases ϖRandom organization τMixed causes and effects τRandom case sequence ϖBuilt-in assumptions τFunctional/environmental knowledge ϖAmbiguous precedence relationships ϖImplicit cases ϖEtc. ϖI.E. versus E.G. ϖTemporal ambiguity ϖBoundary ambiguity

As an example, one of the Ambiguity Review Checklist items is the Dangling Else. A Dangling Else can be identified when one of the following sets of words is used in a sentence:

MUST BE, WILL BE, IS ONE OF, SHOULD BE, COULD BE, CAN BE, or SHALL.

As an example, an excerpt from a set of requirements states the following:

“The Marriage Status must be either Married, Single, or Divorced.”

This requirement states what happens under normal circumstances, or the “go” path. However, it is not a complete requirement, because it does not describe what happens if we are off the “go” path. What is the exception or error condition if another value is entered in the Marriage Status, such as Separated?

List of Words that Point to Potential Ambiguities

Many ambiguities referred to in the Ambiguity Review Checklist items can be identified by looking for key words and phrases in the requirements. The following list of words point to potential Ambiguities:

Dangling Else

can could is one of must shall should will would

Ambiguity of Reference

above below it such the previous them these they this those

Ambiguous Adjectives

all any appropriate

custom efficient every

few frequent improved

infrequent intuitive invalid

many most normal

ordinary rare same

seamless several similar

some standard the complete

the entire transparent typical

usual valid

Ambiguous Adverbs

accordingly almost approximately by and large commonly customarily efficiently frequently generally hardly ever in general infrequently intuitively just about more often than not more or less mostly nearly normally not quite often on the odd occasion ordinarily rarely roughly seamlessly seldom similarly sometime somewhat transparently typically usually virtually

Ambiguous Variables

the application the component the data

the database the field the file

the frame the information the message

the module the page the rule

the screen the status the system

the table the value the window

Ambiguous Verbs

adjust alter amend

calculate change compare

compute convert create customize derive determine edit enable improve indicate manipulate match maximize may minimize might modify optimize perform process produce provide support update validate verify

E.G. versus I.E.

e.g. i.e.

Implicit Cases

also although as well besides but even though for all other furthermore however in addition to likewise moreover notwithstanding on the other hand otherwise still though unless whereas yet as required as necessary

Temporal Ambiguity

after annually at a given time at the appropriate time bimonthly biweekly daily every other month every other week fast in a while later monthly quarterly quickly soon twice a month twice a year weekly yearly

Boundary Ambiguity

up to among including

Totally Ambiguous

etc. sentences that end with ?

Ambiguity Review Metrics

In a typical Ambiguity Review, 15 pages of requirements can be reviewed for Ambiguity and documented per day. Using CaliberRM, the equivalent of 25 pages of requirements can be reviewed for ambiguity and documented per day. The increased efficiency occurs because of the CaliberRM Glossary feature. The List of Words that Point to Potential Ambiguities is loaded in the CaliberRM Glossary. Each time a word from the List occurs in the requirements, it is highlighted in blue, making it easier for the Ambiguity Reviewer to identify potential ambiguities.

Benefits of an Ambiguity Review:

• Higher quality requirements are made available to the domain experts to read for correctness and completeness. • Defects are corrected at the earliest point in the software development lifecycle (defect avoidance instead of defect identification in latter phases of the software development lifecycle). • The cost of correcting defects is at its lowest point in the software development lifecycle. • Timely feedback from the Ambiguity Review reduces issue resolution time. • All members of the Project Team can work from one clear set of requirements, thereby reducing the chance of scrap and rework throughout the software development lifecycle.

Ambiguity Review Training

The Ambiguity Review Process is taught in three courses offered by Starbase Corporation. These courses are:

• Finding Ambiguities in Requirements (one day), aimed at anyone who has to read requirements • Writing Testable Requirements (three days), aimed at anyone who has to write requirements • Requirements-Based Testing (three days), aimed at anyone who has to test software