Validate Requirement

Just to recall previous posts, after requirement is elicited, no matter it’s confirmed or not, it can be specified and modelled. At this moment in time, there are two actions need to be done separately: Verify Requirement and Validate Requirement.

Recollect the purpose of Verify Requirement is to ensure requirement is stated correctly. Validate Requirement, on the other hand, is to ensure correct requirement is stated. In other words, Validate Requirement assures that all requirements and designs align to business requirements and support the delivery of needed values. Let’s assume requirement is an essay. Verify Requirement is most likely to check the accuracy of grammar or spelling, while Validate Requirement is to check if each sentence and paragraph support the topic or thesis.

Clearly, Verify Requirement and Validate Requirement, thus, are ongoing processes.

Let’s find out what we will do to Validate Requirement.

According to BABOK ver 3, Validate Requirement comprises of 3 elements:

• Identify Assumptions: this step is especially important in unprecedented products or services, as there is no similar previous experience on which to rely. Still, it’s also important to other kinds of project. The reason is no prophecy or prediction is certainly to happen – there are always unpredictable things about responses of customers, stakeholders, etc. We agree that Identify Assumptions is important, yet difficult. Even with experienced professionals, wrong assumptions are still unavoidable in some cases. Another thing is risk, which always come together with assumption. Each assumption might be right or wrong, and an associated risk of a wrong assumption arises as a result. Therefore, both assumption and corresponding risk must be identified for better management.
• Define Measurable Evaluation Criteria: the purpose of a system is to improve the conditions of Current State and to achieve Future State. In other words, the expected benefit or goals are already defined when identifying Future State (and perhaps Potential Value). However, it is in business term, quite qualitative. We need a quantitative measurement to ensure the requirement elicited is enough and accurate to achieve the goal. For this action, Acceptance and Evaluation Criteria technique is effectively used, and because it’s also widely used by a BA throughout many KA, we’ll entail this technique in the next post.
• Evaluate Alignment with Solution Scope: if a requirement does not bring benefit to stakeholder, it’s clearly should be eliminated. Still, it’s possible that a requirement can be of benefit to a specific stakeholder but not be a part of the desirable solution. Based on many internal also external factors such as cost, timeline, etc. the Solution Scope is finalised at Strategy Analysis period, and this second kind of requirement could lead us into 2 ways: either the requirement being eliminated or the Solution Scope (also the Future State) must be re-evaluated and revised. Clearly, if a design does not support any in-scope requirement, it must also be changed.

Thanks for reading!

Reference:

1. IIBA. 2015. BABOK. Version 3.0.