Purpose 6.5.1
Requirements verification ensures that requirements specifications and models meet the necessary standard of quality to allow them to be used effectively to guide further work.
Description 6.5.2
Verifying requirements ensures that the requirements have been defined correctly; that is, that they are of acceptable quality. Requirements that do not meet quality standards are defective and must be revised. Requirements verification constitutes a final check by the business analyst and key stakeholders to determine that the requirements are:
ready for formal review and validation by the customers and users, and
▶
provide all the information needed for further work based on the requirements to be
▶
performed.
Input 6.5.3
Requirements [Any Except Stated]: Any requirement may be verified (including business, stakeholder, solution, and transition requirements). Verification is a quality check performed following analysis of a requirement.
Requirements Analysis Verify Requirements
Elements 6.5.4
The business analyst verifies that requirements have been specified in well-written requirements statements.
Characteristics of Requirements Quality .1
At a minimum, a high quality requirement exhibits the following characteristics:
Cohesive: A cohesive set of requirements relates to only one thing, whether that is a business process, business rule, organizational unit, or so forth. All requirements in a set or model should support its overall purpose and scope.
Complete: The entire set of requirements should represent all relevant requirements.
Also each individual requirement should be complete. Ensure each requirement is self-contained without any missing information.
Consistent: Ensure that individual requirements do not contradict each other or describe the same requirement using different wording. In addition, the level of detail supplied for each requirement in a set or model should be the same.
Figure 6–6: Verify Requirements Input/Output Diagram Inputs
6.5
Verify Requirements
6.5 Requirements
[Verified]
Tasks Using This Output
*
Requirements [Any Except
Stated]
6.6 Validate Requirements Requirements Mgt.
and Communication
+
Correct: Defects in requirements will lead to defects in the resulting solution.
Feasible: Each requirement must be implementable within the existing infrastructure, with the existing budget, timeline and resources available to the team (or the project must develop the capability to implement the requirement). The business analyst needs to work with the project team to make these determinations.
Modifiable: Related requirements must be grouped together in order for requirements to be modifiable. This characteristic is exhibited by a logical structuring of the requirements.
Unambiguous: Individual requirements must never be unclear. A requirement must not allow for multiple divergent valid interpretations of the requirement.
Testable: There must be a way to prove that a requirement has been fulfilled. Each requirement should be testable—that is, it must be possible to design a test that can be used to determine if a solution has met the requirement or some other means of determining whether to accept a solution that meets the requirement.
Verification Activities .2
Verification activities are typically performed iteratively throughout the requirements analysis process. Verification activities include:
Check for completeness within each requirements model. For example, data flow
▶
diagrams will have all components and data flows labeled, and all data flows will have arrows indicating direction.
Compare each prepared requirements model (textual or graphical) against all
▶
other prepared requirements models. Check for elements that are mentioned in one model that are missing in the other models. Also check that the same component is referenced the same way in all models – for example, use of consistent language, e.g.,
‘customer’ and ‘client’. Resolve all discrepancies, correcting terminology, or adding/
deleting components as needed.
Make sure all variations to the documented processes have been identified and
▶ documented. Pay particular attention to common branching logic – e.g. “none found”, “one and only one found” or “more than one found”.
Make sure all triggers and outcomes have been accounted for in all variations.
▶
Make sure the terminology used in expressing the requirement is understandable to
▶ stakeholders and consistent with the use of those terms within the organization.
Add examples where appropriate for clarification and to strengthen the business
▶ case.
Techniques 6.5.5
General Techniques .1
Acceptance and Evaluation Criteria Definition (9.1): Ensure that requirements are stated clearly enough to devise a set of tests that can prove that the requirement has been met.
Requirements Analysis Validate Requirements
Problem Tracking (9.20): May be used to ensure that any problems identified during verification are resolved.
Structured Walkthrough (9.30): Used to inspect requirements documentation to identify ambiguous or unclear requirements.
Checklists .2
Checklists are useful as a quality control technique for requirements documentation.
They may include a standard set of quality elements that the business analyst or other reviewers use to validate the requirements or be specifically developed to capture issues of concern to the project. The purpose of a checklist is to ensure that items that the organization or project team has determined are important are included in the final requirements deliverable(s), or that process steps that the organization or project team has determined must be followed are addressed. Checklists may also be developed on a project basis to help ensure consistency of approach and outcomes, particularly on large projects where multiple sub-project teams are working.
Stakeholders 6.5.6
All Stakeholders: The business analyst, in conjunction with the domain and technical 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, virtually all project stakeholders are involved in this task.
Output 6.5.7
Requirements [Verified]: Verified requirements are of sufficient quality to allow further work based on those requirements to be performed.