RIGHT Blogs                                                              

Testing Requirements for Ambiguities

In my previous blog Requirements and Ambiguities, we have seen the necessity to clean out the ambiguities to have qualitative requirements. In this blog let us to talk about how to conduct an ambiguity review.

Dictionary meaning of Ambiguity is as follows:

• - An expression whose meaning cannot be determined from its context
  - Unclearness by virtue of having more than one meaning

Ambiguities in requirements arise when the requirement statements are interpreted in different ways. Ambiguities also arise when the requirements are incomplete.

Ambiguity review is conducted as a part of application testing in the early stages of a project. Ambiguity review is done to test the requirements for ambiguities, clarity and completeness.

Once the requirements document is received from the client, all the ambiguous requirements have to be noted and logged in a defect tracking system which can be a simple Excel sheet or a tracking tool like JIRA, Clear Quest etc. The following ambiguity checklist can also be used for tracking the ambiguities. 

• - Scope of the requirement must be clearly defined and also, requirements should ensure that all items mentioned in the scope are defined clearly and precisely.
  - The requirements references should be clear without any ambiguity.
  - The Statement used in a requirement document should be clear without any confusion.
  - Test whether the requirement fits with the context, examine the flows of data to and from the system on the context diagram.
  - Assumptions made on requirements if any, should be explicitly stated.
  - Requirements talk about relationship precedence.
  - Requirements should clearly state the implicit cases
  - Requirements should be clear when comparing with other components.
  - Requirements should be clear with boundary values.
  - The system characteristics should be stated clearly and must be easily understood by the users.
  - The requirements should not have open end statements. Open ended statements will lead to different interpretations.
  - All the sections in the requirement document should be completed. Irrelevant sections need to be removed from the requirements document.
  - Need to ensure that all the acronyms and important phrases or words used in the requirements are well defined in the Acronyms section. The definitions should match the descriptions in different sections.
  - The interaction/interfacing/ dependencies on other systems should be clearly stated. The requirements in this case should be cross checked with the owners of the other systems.
  - Simple misuse of the language in which the document is written is a significant source of these ambiguities. Typical examples ``all'', ``each'', and ``every'' to denote sets; positioning of ``only'', ``also'', and ``even''; precedences of ``and'' and ``or''; ``a'', ``all'', ``any'', ``each'', ``one'', ``some'', and ``the'' used as quantifiers; ``or'' and ``and/or''; ``that'' vs. ``which''; parallelism; pronouns referring to an idea; multiple adjectives.
  - Requirements should state the flexibility of the system in response to changing conditions or business needs.
  - Ensure that the non functional requirements like environment, infrastructure etc. are clearly defined and described.
  - Comparatives, such as "earliest", "latest", "highest". - Words ending in "est" or "er" should be suspect.

Sometimes the requirements may be ambiguously written as the stakeholders strive to arrive at a qualitative requirement. In this case the client may de-scope the requirement or cancel the requirements or consider the requirement for a future release. The ambiguous or incomplete statements need to be rewritten. In case the requirements are not valid they need to be removed from the requirements document. Once that is done it is good to have a meeting with the client and identify the owners for each of the issues. It is important to follow up with the owners of the issues and discuss them about the ambiguities and make sure that all the defects are closed by correcting the requirements.

The purpose of ambiguity testing is not to find the missing requirements or to redefine requirements. However, during the meeting with the stakeholders, if it is found that the ambiguity is due to a missing requirement then the missing requirement needs to be documented by the authors of the requirement document.

Ambiguity testing is a part of the application testing at Alliance. We have a good process for ambiguity testing and have successfully delivered defect free requirements to our clients.