Purpose 6.6.1
The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfill its goals and objectives, and meet a stakeholder need.
Description 6.6.2
Requirements validation is an ongoing process to ensure that stakeholder, solution, and transition requirements align to the business requirements.
Assessing what the outcome will be for the stakeholder when their need is satisfied can be helpful when validating requirements. Implementation of the requirements as a whole must be sufficient to achieve that desired future state for customers and users. In many cases, stakeholders will have different, conflicting needs and expectations that may be exposed through the validation process and will need to be reconciled. See Manage Solution Scope and Requirements (4.1).
Input 6.6.3
Business Case: The business case describes the overall business objectives and measurements that the solution is expected to deliver. To be valid, a requirement must
contribute directly or indirectly to the business case. Other business requirements, including the business need, required capabilities, and solution scope may also be used for validation.
Stakeholder, Solution, or Transition Requirements [Verified]: Requirements need to be verified for validation to be completed. If a requirement cannot be verified, it cannot be successfully implemented and so cannot meet a business need. However, validation activities may begin before requirements are completely verified.
Elements 6.6.4
Identify Assumptions .1
In many cases it may not be possible to prove that implementation of the requirement will result in the desired benefit. If an organization is launching an unprecedented product or service, it may be necessary to make assumptions about customer or stakeholder response, as there are no similar previous experiences to rely on. In other cases, it may be difficult or impossible to prove that a particular problem derives from an identified root cause. Stakeholders may have assumed that certain benefits will result from the
Figure 6–6: Validate Requirements Input/Output Diagram Inputs
6.6 Validate Requirements 5.5
Business Case
6.6 Requirements
[Validated]
Tasks Using This Output 7.5 Validate Solution
6.5 Stakeholder,
Solution, or Transistion Req'ts [Verified]
Requirements Mgt.
and Communication
+
Requirements Analysis Validate Requirements
implementation of a requirement, and these assumptions must be identified and defined so that associated risks can be managed. See Define Assumptions and Constraints (6.4).
Define Measurable Evaluation Criteria .2
While the forecasted business benefits are defined in the business case, the specific measurement criteria and evaluation process may not have been included. Following the definition of the benefits that will result from the implementation of a requirement, it is necessary to define the evaluation criteria that will be used to evaluate how successful the resulting change has been after the solution is deployed (see Metrics and Key Performance Indicators (9.16) for information on the selection of appropriate criteria, and Evaluate Solution Performance (7.6) for details on how this assessment is performed post-implementation).
Determine Business Value .3
The business case defines the value delivered by a solution that meets the solution scope, but it is also possible to assess individual requirements or features to determine if they also deliver business value. Specify and Model Requirements (6.3) outlines some ways in which a requirement can deliver business value. A requirement that does not deliver direct or indirect value to a stakeholder is a strong candidate for elimination. Value does not need to be monetary. Business value can be delivered through requirements that support compliance with regulatory or other standards, alignment with internal standards or policies of the organization, or increased satisfaction for stakeholders, even if those things do not have a direct measurable financial benefit.
Determine Dependencies for Benefits Realization .4
Not all requirements contribute directly to the end result desired by the organization and described in the business case. See Manage Requirements Traceability (4.2) for the types of relationships that might exist.
Evaluate Alignment with Business Case and Opportunity Cost .5
A requirement can be of value to a stakeholder and still not be a desirable part of a solution. A requirement that is not aligned with the business case should be defined and approved in a separate business case, or considered for removal from the solution scope.
Ultimately, each requirement must be traceable to the objectives in the business case, and should also minimize the opportunity cost of implementation.
At the project level, opportunity cost refers to the benefits that could have been achieved with an alternative investment rather than this one. In other words, it is the cost of what you cannot do or have because you chose to invest in this project instead of another one.
This concept can also be applied to decisions made within a project. For example, if a project team spends time and energy implementing a feature in a software application, that effort cannot be applied towards additional testing, training for the users, bug fixes, or other project work. That lost work represents the opportunity cost of the decision. The opportunity cost of any decision is equal to the value of the best alternative use of those resources.
Techniques 6.6.5
Acceptance and Evaluation Criteria Definition (9.1): Acceptance criteria are the quality metrics that must be met to achieve acceptance by a stakeholder.
Metrics and Key Performance Indicators (9.16): Used to select appropriate performance measures for a solution, solution component, or requirement.
Prototyping (9.22): Prototyping of product components is used to gain user agreement with the proposed solution.
Risk Analysis (9.24): Risk analysis can be used to identify possible scenarios that would alter the value delivered by a requirement.
Structured Walkthrough (9.30): Review meetings are conducted to confirm whether the stakeholder agrees that their needs are met.
Stakeholders 6.6.6
All Stakeholders: Virtually all stakeholders are involved in or impacted by validation activities.
Outputs 6.6.7
Requirements [Validated]: Validated requirements are those that can be demonstrated to deliver value to stakeholders and are aligned with the business goals and objectives.
If a requirement cannot be validated, it does not benefit the organization, does not fall within the solution scope, or both.
The Solution Assessment and Validation Knowledge Area describes the tasks that are performed in order to ensure that solutions meet the business need and to facilitate their successful implementation. These activities may be performed to assess and validate business processes, organizational structures, outsourcing agreements, software applications, and any other component of the solution.
Business analysis plays a vital role in ensuring that the process of reviewing, selecting, and designing the solution is done in a way that maximizes value delivered to stakeholders.
The business analyst knows the business environment and can assess how each proposed solution would affect that environment. The business analyst is responsible for ensuring that stakeholders fully understand the solution requirements and that implementation decisions are aligned with the relevant requirements.
Note: the performance of all solution assessment and validation activities are governed by the business analysis plans (see 2.3), and business analysis performance metrics should be tracked (see 2.6).