This is another common question.  It is also a major complaint of both developers and testers.  Developers often receive requirements from their customers that are not verifiable.  How many times do we see requirements like the following: “The system shall be user friendly.”  “The system shall be robust.”  “The system shall perform better than the previous version.”  Unverifiable requirements add considerable risk for both the customer and the developer.

Mandatory characteristics for any requirement is that it is Needed, Verifiable, and Attainable.  I call these the NVA characteristics.  In other blogs “Do we really need all these requirements?” and “Are the requirements Attainable?”  I address the “Needed” and “Achievable” aspects of good requirements.  In this article, I will focus on “Verifiable”.

Question – why ask for something when it cannot be proven it was built, performed or  implemented as intended?  A requirement that is not verifiable could result in the developers developing the wrong thing or the testers (people doing verification) verifying something other than what was intended.  If the true intent of the requirement is not clear, stakeholder expectations may not be met.  Furthermore, the system may pass verification but fail validation thus  resulting in rework and impacting budget and schedule.

Reasons why there are unverifiable requirements

If you were to research to find the root cause for unverifiable requirements, you will discover that there are many.  However, I have found 3 reasons for unverifiable requirements that stand out the most:

• The requirement is written poorly
• The requirement is incomplete
• The requirement is not documented at the level where it will be verified
  

Requirement is written poorly

A requirement that is written poorly can be understood (or interpreted) more than one way making it ambiguous and unverifiable.   A major defect is when ambiguous terms (user friendly, robust, capable of, and/or, use of pronouns, etc.) are included in the requirement.  Other defects include failing to be concise by using unnecessary  “-ly” words (adjectives and adverbs) or the use of multiple terms of reference for the system for which the requirements are being written.   In requirement writing, adjectives and adverbs add confusion and ambiguity.  If you use multiple terms for the system under development, developers may think the requirement is for something other than the system of interest.

If a requirement it is not clear, concise, or is grammatically incorrect, you are introducing the potential for (1) misinterpretation, and (2) inability to verify.   If a requirement is stated negatively, it may not be verifiable (it is difficult to prove that a system never, ever does something.)  If the requirement contains more than one thought, which thought do you verify?  If a requirement is written poorly and can be understood more than one way, whose interpretation is correct, the developer who developed the solution based on his/her interpretation or the verifier who is executing the test case based on his/her interpretation or the requirement author whose intent is paramount yet open to interpretation?

Requirement is incomplete

A requirement should  contain information needed to understand the intent in either the requirement text or in an attribute of the requirement (rationale).  A requirement is incomplete when there is information missing or information is stated incorrectly making the requirement difficult to understand and verify.   A classic case is when there is an interface requirement that does not point to where the interface is defined.  Another case is when a value is not defined (has a “to be determined” (TBD) or “to be supplied” (TBS)).   Stating absolute values or failing to include a range can also make the requirement unverifiable.  (It is very difficult to show the system can achieve a performance level of exactly 95%  every time.  What if the system does better?)  An incomplete requirement can result in the requirement not being able to be implemented as intended and stakeholder expectations not being met.

Requirement is not documented at the level where it will be verified.

Proper allocation of requirements to system architectural levels is very important to effective verification and validation.  All requirements must be documented at the level where they will be implemented and verified.  Specifying a requirement at a level higher than where it will be verified may make it difficult or impossible to verify at that level.  When writing requirements, always ask yourself: “Does this requirement apply to the level I am writing requirements for?”  The requirement may be valid, but not for that level.  If the requirement is not being stated at the correct level, move it to the correct level.

Avoiding unverifiable requirements

• Communicate, Communicate, Communicate.  To minimize the risk of writing unverifiable requirements, employ requirement elicitation techniques and leverage your soft skill sets of communication and stakeholder and meeting management.  It is essential that requirement writers work with the stakeholders to ensure that their wants, needs and expectations are clearly understood, and that their intent is correctly captured in the form of a well written requirement.
• Develop use cases, stories, scenarios, and concepts as a way to understand stakeholder needs.  When the stakeholders state a need in ambiguous terms, ask them what they mean.  Ask what they mean by “user friendly”, “robust”, “better”, etc.  Get the stakeholders to state their definitions and expectations for these areas in verifiable terms.
• Train your team in how to write defect free requirements and define your requirement development process.
• Practice continuous requirement validation as part of your process.  Continuous requirement validation is when the requirement development team reviews each requirement for goodness, completeness, correctness, consistence, need, verifiability, and feasibility as they are being written rather than waiting until they have a “big, bad, requirement spec”  full of defective requirements.
• Involve the developers and verifiers during elicitation and requirement writing.   If they don’t understand the requirement, they can say so and work with the responsible parties to clarify. and re-write the requirement so its intent is clearly understood and the requirement is verifiable.
• Start planning for verification early.  Make the verification method a mandatory attribute that is captured for each requirement.  Just thinking about the method you would use to verify a requirement can result in having to rewrite the requirement to make it verifiable.
• Develop a checklist to help avoid requirement defects that result in unverifiable requirements such as the checklist we provide our students:  “Rules of Writing Good Requirements.”  [Contact Lou Wheatcraft at info@argondigital.com to get a copy.]
• Push back when customers or other stakeholders provide you with unverifiable requirements.  How can you meet their expectations if the requirement is defective as described earlier?

If you have any other questions, feel free to ask your question on our “Ask the Experts” page and we will do our best to provide a timely response.