How do you select the appropriate verification level and technique for each requirement?

1 Types of requirements

The level of abstraction, perspective, and domain all determine different types of requirements. Functional requirements describe what the system should do in terms of inputs, outputs, and behaviors. Non-functional requirements refer to how the system should perform in terms of quality attributes like reliability, usability, and security. Interface requirements explain how the system should interact with other systems, devices, or users in terms of data formats and protocols. Domain requirements refer to rules and constraints that apply to the system's domain such as legal, regulatory, ethical, or environmental aspects. The nature and scope of each type of requirement will vary and require a different verification level and technique.

2 Verification levels

Verification levels refer to the various stages of the system development lifecycle where requirements are checked for validity, completeness, and accuracy. At the conceptual level, requirements are elicited from stakeholders and the feasibility, scope, and objectives of the system are defined. At the specification level, requirements are analyzed, modeled, and documented in a formal or semi-formal way. At the design level, requirements are translated into a logical and physical architecture. At the implementation level, requirements are implemented in code. And at the testing level, requirements are verified against the actual system behavior. Each verification level may require a different verification technique based on its purpose and outcome.

3 Verification techniques

Verification techniques refer to the methods and tools used to check that the requirements are correct, consistent, and traceable. Reviews, walkthroughs, prototypes, simulations, and tests are some of the common techniques used. Reviews involve formal or informal inspections of the requirements documents or artifacts with stakeholders. Walkthroughs are structured presentations of the requirements documents or artifacts with the author explaining the logic and rationale behind them. Prototypes are simplified versions of the system or its components that demonstrate key requirements or features. Simulations are models or representations of the system or its environment that simulate expected behaviors or conditions. Tests are experiments or evaluations of the system or its components that compare actual results with expected ones. Each technique may have different advantages and disadvantages depending on cost, time, and effectiveness.

4 How to select

When selecting the appropriate verification level and technique for each requirement, you need to consider the type of requirement, its complexity, risk level, stakeholder involvement, and available verification resources. Functional requirements may need more testing than non-functional requirements, while complex requirements may require more reviews and walkthroughs. Risky requirements may need more prototypes and simulations than low-risk ones. Requirements that involve more stakeholders may need more reviews and walkthroughs than those that involve fewer stakeholders. Requirements with more verification resources available can use more sophisticated techniques than those with fewer resources. By applying these factors to each requirement, you can select the most suitable verification level and technique for it, as well as plan your verification activities accordingly.

5 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?