Most business analysts would have faced a situation where they are told they have missed a requirement. Most of the time, the beginning of a change request starts as a missed requirement. Then the business analyst does thorough research about this and provides the necessary information, after which that case of missed requirement would be either accepted as a change request or missed requirement.
In this article, I would like to share my experience regarding the various scenarios of handling a missed requirement.
We may face this scenario at any phase of a project. The following steps will assist in identifying the difference between missed requirements and change requests at the first level –
Step 1: Identify if the new requirement falls within the scope.
Step 1a. If yes, does the endpoint of the requirement exist in the current requirements?
Step 1b: If no, at which point in the scope does the requirement make the process extend beyond the scope?
Going in the direction of the change request:
If “Step 1b” is true, we can term that the new requirement should be taken in the direction of change request analysis.
Going in the direction of missed requirements:
If “Step 1a” is true, then
Step1a.1: Look for an existing requirement that has a similar endpoint.
Step 1a.2: Highlight the processes of both the existing and new requirements as different swim lanes within the overall process.
Step 1a.3: Look for similarities and differences between them with respect to the user, variables, and constants, external factors affecting the process, the effect of transition requirement, if any, and the effect on non-functional requirements of the system involved.
Some of the observational output after the above step: -
Output 1: If the new requirement seems repetitive and adds no value to the system, then the above can be explained to the stakeholder, and the requirement can be ignored.
Output 2: f the new requirement is hardly repetitive but adds value to the system or user in some form, then we need to analyze further the reason for not bringing this up during the requirement phase.
Some of the major reasons for the occurrence of output 2 –
In most cases, these requirements would have appeared as second-level or tertiary-level nice-to-have requirements, and the client would have been interested in the must-haves and primary-level nice-to-haves. In this scenario, this is now a negotiation about having the new requirement in the primary or secondary level nice-to-haves. Therefore, this can’t be termed a missed requirement.
Way to mitigate: Right at the beginning, when we get the buy-in for the must-haves, we should get the buy-in for all the nice-to-haves at various levels.
Most recommended techniques to be used for the above mitigation: Prioritization, backlog management, and Functional decomposition to a detailed extent, and then mark the nice-to-haves at various levels
In certain cases, some change requests would have been accepted without a complete analysis of the impact on the process. In such cases, certain requirements that would be part of such a change request would be considered a missed requirement if the requirement crops up after the acceptance sign-off of the relevant change request.
Ways to mitigate: We have to do a complete analysis of the effect of the change request, such that we have no grey area left. Because missed requirements crop up from these grey areas only.
Most recommended techniques to be used for the above mitigation: Scope modeling, concept modeling, process modeling, process analysis, and item tracking.
When there is a stakeholder change from the client side, we can expect changes in the understanding of the previously signed-off requirements. In such cases, their expectation might not be met. As a result, their understanding of the requirement might crop up as a new requirement. In this scenario, this misunderstanding has to be handled. This doesn’t qualify as a missed requirement in most cases.
Ways to mitigate: Understand the various powers of stakeholders and include all the mandatory stakeholders in the requirement phase so that the above effect can be minimized.
Most recommended techniques to be used for the above mitigation: Organization modelling, roles & permission matrix, and a complete stakeholder list.
Sometimes, due to the lack of knowledge of the associated system, BA might miss certain interrelated requirement, which involves more than one system. In this case, this is a missed requirement.
Ways to mitigate: We have to do complete research of all the allied systems, at least at those points at which those allied systems interact with the system at hand.
Most recommended techniques to be used for the above mitigation: Interface analysis, prototyping, data flow diagram, process modelling, analyzing transition requirements, and non-functional requirements in relation to the system at hand.
In a nutshell, all the above could be mitigated if we do a self-reflection about the techniques used for requirement analysis in two ways – One is to see if there were any mistakes in following the technique, and another way is to see if adding some other technique for the analysis would lead to complete requirement gathering phase (this depends on the system).