Four Cases for Early Requirements Verification

Posted by Brad Egeland

Performing a verification assessment on your requirements during the actual requirement definition process is a key step in validating the requirements.  As I mentioned previously, verifiability is a key characteristic of a good requirement.

Assessing verification as you develop your requirements can provide four major benefits to your requirements and to your project or product:

  • It improves requirement quality
  • It ensures that your requirements support verification
  • It provides a basis for estimating verification cost and schedule
  • It reduces requirements verification costs

Let’s look at each of these statements in more depth…

Early attention to verification improves requirement quality.

Asking “how will we verify this requirement?” before you baseline a requirement is an important step in validating that requirement.  An unverifiable requirement is an unnecessary or bad requirement.  If you can’t verify it, you may not be able to design a product or solution that will meet it.  For example, how you do you verify “the product shall be safe?”   How will designers make it “safe?”  If you can’t verify a safety-related requirement, you may not be able to convince your customers to use the product.

Early verification assessments help to identify additional requirements needed to support verification.

Your product or solution may need features dedicated to support verification, especially tests and demos.  Extra connectors on the wiring harness to connect to test instrumentation or external power, extra data on a display or in a database to give you visibility into an internal process, an inspection portal, or a bracket to hold a part in a test fixture are examples of features that can make verification possible in some cases or reduce it’s costs dramatically in others.  Knowing these requirements before starting design avoids late rework of the solution or product to enable verification.  It will also reduce delays in product development while you await delivery of test support equipment or software, which could have been on a parallel development track if you’d known that you needed it earlier.

Considering the verification approach before development provides a foundation for estimating the cost and time required for verification.

Proving that product meets the requirements is a major cost element in product development, often as much as 50% of the overall cost.  You will go a long way toward avoiding schedule slips and cost overruns by considering verification of each requirement when you build your schedules and budgets.  What test support equipment must be purchased?  You may need a special test facility such as an extreme environment simulation chamber.  Will it be available when your product is ready for the test?  Perhaps you are developing a medical product.  What verification requirements will the government and medical insurers place on your product?  What extra reviews from outside experts and liability insurance will be required before your tests involving human or animal subjects?

If you are a customer acquiring a product, or a developer producing a product for a specific customer, there will usually be a contract in place including the requirements – including an agreement on verification scope and approach.  If the product or solution is complex, testing every possible case or path may be too cost prohibitive.   Vague or open-ended verification plans can overrun the project budget or the leave the customer with a lack of confidence in the solution or product.  Clear statements of verification expectations – generated by an early verification assessment – protect all parties in such a contract.

Making verification assessment part of requirement definition reduces cost.

You can identify the requirements that will be the most costly to verify and rewrite them to reduce the verification cost while still meeting your product’s goals.  You want to do this assessment before investing in designing to the verification-intensive requirements.

Information and concepts for this article were derived, in part, from Hooks and Farry’s book “Customer-Centered Products.”

Tags: , , , , , , , ,

Post comment