Share this
How to handle missed requirements
by Sugirtha Murugesan on Jul 9, 2022 4:04:10 AM
A common BA situation:
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.
Identifying Missed Requirement vs. Change Request (High level):
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 –
Reason 1: New requirement would be a part of the nice-to-have requirement:
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
Reason 2: New requirement pops up after the change request sign-off:
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.
Reason 3: Change of stakeholders from the client side:
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.
Reason 4: BAs need to extend their understanding of not only the system at hand but all other systems and processes that communicate with the system at hand :
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.
Keynote
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).
Share this
- Business analysis (135)
- CBAP (41)
- Business analysis skill (34)
- CBAP Certification (32)
- #CCBA (31)
- Career (29)
- ECBA (22)
- #AdaptiveUS (20)
- #BA Certification (18)
- #BA (16)
- IIBA Certifications (16)
- BABoK (15)
- #IIBA (14)
- #AdaptiveUS #BusinessAnalysis (13)
- Uncategorized (13)
- Most Popular (12)
- Announcements (11)
- cbap certification training (11)
- Requirement engineering (10)
- #CBAP_Certification (8)
- #LNMishra (8)
- countdowns (8)
- #BA Skills (7)
- #BA Techniques (7)
- CPRE (7)
- Press Release (7)
- #AdaptiveUS #BusinessAnalysis #BA #BABoK (6)
- #CCBA_Certification (6)
- #Elicitation (6)
- #business analyst (6)
- #BusinessAnalysis (5)
- #PressRelease (5)
- #Business_Analysis (4)
- #ECBA_Certification (4)
- #Requirements engineering (4)
- #cbap_exam_ preparation_tips (4)
- #certifications #AdaptiveUS #BusinessAnalysis #BA (4)
- Business analysis certification training (4)
- Most Recent (4)
- #AdaptiveRocks (3)
- #BA_Certification (3)
- #IIBA Membership (3)
- cbap certification cost (3)
- cbap certification course (3)
- cbap training certification online (3)
- #LearnwithLN (2)
- Business analysis study guides (2)
- CCBA Recertification (2)
- CPOA (2)
- Scrum (2)
- businessanalyst (2)
- cbap question banks (2)
- cbap study guide (2)
- ecba question banks (2)
- ecba study guide (2)
- #AAC (1)
- #AgileBA (1)
- #BAOT (1)
- #BATrends (1)
- #BridgingtheGap (1)
- #ECBA #IIBA #IIBAWorkshop #Certification (1)
- #IIBA #Agile (1)
- #IIBAEgyptChapter (1)
- #IREB (1)
- #NFR (1)
- #OneWorksGroup (1)
- #Partnership (1)
- #SimpleSim (1)
- #ba #businessanalysis #jobdescription #adaptiveus (1)
- #performancemetrics (1)
- Adaptive US (1)
- Agile BA (1)
- Awesome BA (1)
- BABoKV3 based certification (1)
- BACOE (1)
- CBAP Certification Tips (1)
- CBAP Exam Preparation (1)
- CBAP Exam Tips (1)
- CBAP Preparation Tips (1)
- CBAP certification preparation (1)
- CBDA (1)
- ECBA Certification steps (1)
- ECBA V3 certification (1)
- ECBA certificate (1)
- From our Archive (1)
- IIBA CBAP Certification (1)
- KPI (1)
- PMI PBA (1)
- PMP vs CBAP (1)
- Requirements Management (1)
- Scrum rules (1)
- Transitioning to BA (1)
- cbap e-learning (1)
- cbap training material (1)
- ccba certification training online (1)
- ccba or cbap certification (1)
- conflicts resolution techniques (1)
- iiba ecba online course (1)
- productowner (1)
- stakeholders (1)
- testing (1)
- what is scrum? (1)
- March 2023 (2)
- February 2023 (5)
- January 2023 (1)
- December 2022 (4)
- November 2022 (3)
- October 2022 (2)
- September 2022 (4)
- August 2022 (3)
- July 2022 (4)
- June 2022 (9)
- May 2022 (4)
- April 2022 (7)
- March 2022 (6)
- February 2022 (1)
- January 2022 (1)
- December 2021 (2)
- November 2021 (4)
- October 2021 (4)
- September 2021 (2)
- August 2021 (4)
- July 2021 (4)
- June 2021 (2)
- May 2021 (1)
- April 2021 (1)
- March 2021 (4)
- February 2021 (2)
- January 2021 (3)
- December 2020 (3)
- November 2020 (3)
- October 2020 (3)
- September 2020 (5)
- August 2020 (8)
- July 2020 (3)
- May 2020 (5)
- April 2020 (2)
- March 2020 (7)
- February 2020 (6)
- January 2020 (4)
- December 2019 (1)
- November 2019 (3)
- October 2019 (5)
- September 2019 (3)
- August 2019 (2)
- July 2019 (4)
- June 2019 (2)
- May 2019 (3)
- April 2019 (6)
- March 2019 (3)
- February 2019 (8)
- January 2019 (7)
- December 2018 (8)
- November 2018 (6)
- October 2018 (8)
- September 2018 (11)
- August 2018 (11)
- July 2018 (23)
- June 2018 (12)
- May 2018 (19)
- April 2018 (11)
- February 2018 (1)
- January 2018 (3)
- December 2017 (1)
- November 2017 (5)
- October 2017 (2)
- September 2017 (2)
- August 2017 (30)
No Comments Yet
Let us know what you think