Verification of Requirements
Quality control, which includes validation and verification, is not very popular in Requirements Engineering. Validation and Verification (V&V) is likely to be misunderstood on every step of SDLC (Software Development Life Cycle). According to IIBA (International Institute of Business Analysis™), the purpose of Verify Requirements is to ensure that requirements and designs specifications and models meet quality standards and are usable for the purpose they serve. However, the purpose of Validate Requirements are defined to ensure that all requirements and designs align to the business requirements and support the delivery of the needed value. In this article, I will focus on the requirements verification which answers the question, “Am I delivering the requirements right?”
Requirements Validation vs Requirements Verification
Requirements Engineering Quality Control consists of two elements: requirement validation and requirement verification. V&V checks the requirements for presence of defects with respect to some defined quality characteristics. For this definition, these terms are sometimes considered as one under the requirement validation (Katasonov and Sakkinen 2006).
According IIBA’s BABOK document, these two activities are separable. Output of the requirement validation supports delivered business value. Unlike requirement validation, verification provides requirements or designs, has been developed in enough detail to be usable by a particular stakeholder, is internally consistent, and is of high quality. It can be said that requirement verification is about how you deliver your requirement elicitation documents.
Goal of Verification of Requirements
Requirement quality control is not a mechanical process of checking documents. It is more a matter of communication requirements, as constructed by analysts return to stakeholders whose goals meet these requirements. It is more challenging when customers/end-users lack technical expertise and stakeholders have different backgrounds and lack expertise of the special domain knowledge. Most of the requirements engineering activities are documented by natural language. However, all natural languages are inherently ambiguous.
To ensure high quality products and overcome ambiguity, incompleteness, inconsistency; verification activities must be seen more than “good practices”. With the help of verification of requirements, business analysts and stakeholders check whether documents are ready for the next step which is requirements validation, and provides the information needed for further work to be performed. Quality metrics must be defined by the key stakeholders and analysts.
Requirement Verification Quality Metrics
According to Katasonov and Sakkinen (2006), each individual statement in a requirements specification should be complete, correct, unambiguous, feasible, necessary, prioritized, verifiable, and concise. Additionally, the requirements specification document as a whole should be complete, consistent, traceable, non-redundant, organized, and conformant to standards.
IIBA’s BABOK document defines quality metrics as follows:
Atomic: self-contained and capable of being understood independently of other requirements or designs.
Complete: enough to guide further work and at the appropriate level of detail for work to continue. The level of completeness required differs based on perspective or methodology, as well as the point in the life cycle where the requirement is being examined or represented.
Consistent: aligned with the identified needs of the stakeholders and not conflicting with other requirements.
Concise: contains no extraneous and unnecessary content.
Feasible: reasonable and possible within the agreed-upon risk, schedule, and budget, or considered feasible enough to investigate further through experiments or prototypes.
Unambiguous: the requirement must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need.
Testable: able to verify that the requirement or design has been fulfilled. Acceptable levels of verifying fulfillment depend on the level of abstraction of the requirement or design.
Prioritized: ranked, grouped, or negotiated in terms of importance and value against all other requirements.
Understandable: represented using common terminology of the audience.
Verification Activities
Requirements verification activities are usually carried out during the requirements analysis process. According to Katasonov and Sakkinen (2006), reviewing requirements and translation requirements to alternative forms are the most useful methods.
Reviewing: It can be informal or formal review of the requirements. Distributing requirements to all stakeholders to read is one of the informal methods and highly used in the industry. However, inspection has well-defined stages to review requirements from different perspective such as; author of the documents, design engineers and various stakeholders. Check-list based reading is the form of another formal reviewing technic. Thanks to this method, every relevant requirements quality metric is assessed by reviewers by in a form of questions.
Translation: As discussed above, requirements engineering activities are practiced by natural language. A particular form may be understandable better than natural language description for a particular stakeholder. Also, when translating one form to another, faults can be detected at early stages.
IIBA’s BABOK Guide lists requirement verification techniques as:
- Acceptance and Evaluation Criteria: used to ensure that requirements are stated clearly enough to devise a set of tests that can prove that the requirements have been met.
- Item Tracking: used to ensure that any problems or issues identified during verification are managed and resolved.
- Metrics and Key Performance Indicators (KPIs): used to identify how to evaluate the quality of the requirements.
- Reviews: used to inspect requirements documentation to identify requirements that are not of acceptable quality.
Final Thoughts
Verification of requirements is an iterative process in the requirement analysis to help business analysts and stakeholders check whether documents meet quality criteria, and provides the information needed for further work to be performed. Determining quality metrics and verification activities should be performed by various stakeholders. In order to achieve high quality outputs(i.e requirements) on every step of requirements analysis process, verification should not be considered as nice-to-have practices.
