Skip to content

7.2.1  Purpose

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.

7.2.2  Description

Verifying requirements ensures that the requirements and designs have been defined correctly. Requirements verification constitutes a check by the business analyst and key stakeholders to determine that the requirements and designs are ready for validation, and provides the information needed for further work to be performed.

A high-quality specification is well written and easily understood by its intended audience. A high-quality model follows the formal or informal notation standards and effectively represents reality.

The most important characteristic of quality requirements and designs is fitness for use. They must meet the needs of stakeholders who will use them for a particular purpose. Quality is ultimately determined by stakeholders.

7.2.3  Inputs

  • Requirements (specified and modelled): any requirement, design, or set of those may be verified to ensure that text is well structured and that matrices and modelling notation are used correctly.

Figure 7.2.1: Verify Requirements Input/Output Diagram

image.png

7.2.4  Elements

Characteristics of Requirements and Designs Quality

While quality is ultimately determined by the needs of the stakeholders who will use the requirements or the designs, acceptable quality requirements exhibit many of the following characteristics:

  • 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

Verification activities are typically performed iteratively throughout the requirements analysis process. Verification activities include:

  • checking for compliance with organizational performance standards for business analysis, such as using the right tools and methods,
  • checking for correct use of modelling notation, templates, or forms,
  • checking for completeness within each model,
  • comparing each model against other relevant models, checking for elements that are mentioned in one model but are missing in other models, and verifying that the elements are referenced consistently,
  • ensuring the terminology used in expressing the requirement is understandable to stakeholders and consistent with the use of those terms within the organization, and
  • adding examples where appropriate for clarification.

Checklists

Checklists are used for quality control when verifying requirements and designs. Checklists may include a standard set of quality elements that business analysts use to verify the requirements, or they may be specifically developed to capture issues of concern. The purpose of a checklist is to ensure that items determined to be important are included in the final requirements deliverables, or that steps required for the verification process are followed.

7.2.5  Guidelines and Tools

  • Requirements Life Cycle Management Tools: some tools have functionality to check for issues related to many of the characteristics, such as atomic, unambiguous, and prioritized.

7.2.6  Techniques

  • 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.

7.2.7  Stakeholders

  • All stakeholders: the business analyst, in conjunction with the domain and implementation subject matter experts, has the primary responsibility for determining that this task has been completed. Other stakeholders may discover problematic requirements during requirements communication. Therefore, all stakeholders could be involved in this task.

7.2.8  Outputs

  • Requirements (verified): a set of requirements or designs that is of sufficient quality to be used as a basis for further work.