This case study will take us through the different scenarios in the day of the business analyst and demonstrate the challenges, also I have discussed the solution to those challenges based on the success elements and the business analysis best practices that I specified in the article ‘’ Practical approach to elicit requirements successfully.
Learn More: Practical Approach To Elicit Requirements Successfully
Read Kelly as the Customer and Alex as the BA in the case study.
Scenario 1
Kelly – I am glad we have covered all points regarding the attributes we need to capture while creating controls.
Alex – We have covered multiple ways in which a user can create controls in the system and have also covered all attributes.
Kelly – Sounds great, but I just had one question - how can I load controls from my legacy systems, I think your product has an upload functionality.
Alex – Yes we have the upload functionality, but we have not discussed about any legacy systems and also the upload functionality will not be able to directly load data into our system we need to have a mapping of the data.
Kelly – Ok I get that, but this is most critical for us as we boast about having a standardized control library based on which we perform assessments.
Alex – Can we look at an alternative, as a first time set up can we manually create the controls in the system.
Kelly – No, that’s extremely tedious for us and we are looking at optimizing time so we can’t create the controls manually.
Alex – Ok I get that and what about the assessments can you perform them yearly.
Kelly – I am afraid you do not understand the context in which we perform assessment, this is not an annual process it is rather adhoc and the control assessments are based on the control frequency defined.
Challenge 1 – Complete requirement of being able to load controls from the legacy system was missed.
Solution 1 – If the BA had closely reviewed the SOW he would not have missed the transition requirement stated in the SOW which included data from legacy systems to be imported into the new system.
Challenge 2 – Alternate suggested by BA to create the controls manually was not appropriate.
Solution 2 – The alternate proposed by the BA was inappropriate, if the BA had read the business need he would be able to address the customer pain point of optimizing time and also the BA had not performed due diligence to know that this was a business critical functionality that distinguishes their customer from their competitors in the market.
Challenge 3 – The BA asked if control assessments could be performed annually.
Solution 3 – Questioning is key to requirement elicitation, even though the BA might not be an expert at the domain but the BA should be aware of the domain context else they will not be able to ask the right questions to elicit requirements successfully.
Scenario 2
Alex – Hello Kelly, it’s great to meet you and the team and I look forward to our detailed focus group sessions that I plan to conduct starting tomorrow.
Kelly – It’s great to meet you Alex, but I was not aware about starting focus group discussions from tomorrow. Unfortunately my team will be busy for the next 2 days with a mandatory company level training program.
Alex – Oh I am sorry, I wish I had discussed this with you. Meanwhile can you please provide me samples of the controls from your legacy system, as a ground work I can begin analysing them.
Kelly – I was not aware that you will need this data, I would have been able to give it to you but the systems only generates a weekly report and this week report will only be generated on Friday.
Alex – Oh Ok, well let me look at what else I can do during this time.
Kelly – Well we can help answer your questions, you can send us an email and after the training we can spend some time to respond to you.
Alex – Oh, but I do not have any questions ready, however let me quickly draft them and send it across while you attend the training.
Challenge 4 – The technique chosen to elicit requirements was not discussed with the customer.
Solution 4 – If the BA would have planned the focus group discussion with the customer buy in, the team would have made themselves available.
Challenge 5 – The level of detail required was not discussed with customer and no heads up on what data might be required was provided.
Solution 5 – If the BA would have planned the level of detail required and clearly discussed with the customer what is required then the customer would be prepared well in advance.
Challenge 6 – The BA did not have the questions for discussion handy.
Solution 6 – Questioning is the key to elicit requirements, so it is critical for the BA to come prepared with the basic set of questions and rest can be elaborated during the discussions.
Scenario 3:
Alex – Hi Kelly, I have shared the survey questionnaires, please share them with your team. Once you have the responses share it back so that I can start analysing.
Kelly – Sure, thanks for sending the questionnaire I have shared it with the team.
Kelly – HI Alex, I have shared the responses from the team, please review and begin your analysis and we will be available tomorrow for discussion.
Alex – Thanks Kelly.
Alex – Hi Team, thanks for sharing your responses, I have noted a few questions that I would like to discuss.
Team – Sure.
Alex – For the control frequency I see that some users have stated that it should be captured at the control level and some have stated that it should be captured while defining assessments, so what would be most appropriate.
Team – Well the internal controls team thinks it is best captured at the control level as one should know well in advance how frequently the control should be assessed.
Alex – Is the compliance team satisfied with this.
Team – Compliance team thinks differently, why one should define the frequency upfront it could rather be a choice that one can make while performing assessment.
Alex – Team I think I have a proposal to make, shall we make the control frequency as optional during the control stage so that the choice of entering it upfront lies with the user.
Team – That’s a great suggestion, we agree to it.
Alex – I am glad we have a conclusion, I will have this documented.
Challenge 7 – There was a conflict in requirements within two stakeholder groups in the team.
Solution 7 – The BA needs to play the key role of a facilitator to help teams resolve conflicts and have a shared understanding which was very well demonstrated by the BA in this scenario. Also the BA made an appropriate recommendation to which the team agreed, this should be captured and followed up as minutes of today’s discussion.
Scenario 4
Alex – Hi Kelly, we had a very eventful and fulfilling focus group session last week. I wanted to keep you posted on the progress, based on our discussions I have prepared the FSD (Functional Specification Document) and mock ups.
Kelly – Great that’s quite some progress, but haven’t you prepared the workflow diagrams.
Alex – Well I have created swim lanes and included them as a part of the FSD (Functional Specification Document).
Kelly – I am afraid that would not be sufficient as we need to be able to see the sequence of activities involved in the process from start to finish.
Alex – Ok I will work on that and include them.
Kelly – That would mean you require more time, instead I would suggest we refer our BRD 2.1 section for the workflow.
Alex – Ok, that should be fine.
Kelly – Well I think swim lanes would be a good way to depict how users interact with the system at various stages in the process, thanks for including them.
Alex – Yeah I think it’s a great tool to call out all stakeholders and see all the possible scenarios in which they will interact with the system. Well I was just thinking of a scenario, what happens when your compliance officers are not able to create the controls themselves? do they assign it to someone else to do it on their behalf.
Kelly – I am glad you brought that up, yes we have acting compliance officers who can do it, but this would need a whole big step of getting appropriate approvals, let’s discuss this in detail with the team.
Alex – Okay, I will include this in the agenda for the next meeting, also looks like we have then missed out the designated compliance officer stakeholders who will create controls on behalf of the compliance officers, I will add this also to the agenda for the next meeting to make sure all requirements for these stakeholders are captured.
Challenge 8 – Workflow diagram was not prepared by the BA.
Solution 8 – The BA should have discussed the level of detail required, and if workflows was a requirement then it should have been included.
Challenge 9 – BA agreed to use customer BRD Section 2.1 as the reference for workflow diagram.
Solution 9 – This is not appropriate, in some cases the customers propose to use their own documents as reference, as a best practice this should be completely avoided and only one single base lined document should be used as a reference, using multiple documents becomes an overhead for the whole team to view requirements at multiple locations and also the responsibility and accountability of customer documents lies with the customer and the BA has no control on the changes
Challenge 10 – The scenario of compliance officers not being able to create controls was missed.
Solution 10 – Many time while documenting requirements some missed requirements are uncovered, the BA should make sure to cover all corner cases which was very well demonstrated by the BA in this scenario.
Challenge 11 – The acting compliance office stakeholder was completely missed out.
Solution 11 – Sometimes while uncovering corner cases we stumble upon the missed stakeholders, as a good practice ensure appropriate stakeholder analysis is performed so that no stakeholders are missed. It was good that the missed stakeholder was at least identified at this stage else it would involve a lot of rework if identified at a later stage.
Challenge 12 – Inconsistent use of role names was observed, Kelly called the missed stakeholders as acting compliance officers whereas Alex called them as designated compliance officers.
Solution 12 – As a good practice ensure there is consistent use of terms and definitions throughout the document as inconsistency leads to confusion.
Scenario 5
Alex – Hi Team, during discussion with Kelly yesterday we identified two important items that we should discuss in today’s meeting. Also I would like to discuss the non-functional requirements, I had shared the same in the meeting agenda.
Team – Yeah thanks for sharing the agenda it helped us to come prepared, we certainly missed some important discussion.
Team – So Alex, does you system have an offline access capability, which means the compliance officer can create the controls offline and sync it up with the system at a later point.
Alex – Well the tool has a lot of extendable capability which means this would be a customization of the product. We can certainly do this, but this needs to be tracked as a change request and should follow the change management process. I would suggest you weigh and see if this requirement is critical as this will affect the cost and schedule of the project.
Team – We are not sure about this.
Alex – I need to understand this requirement in detail and also need to understand how critical this is for the business to be able to make recommendations. Do you see the compliance officer doing this often, Kelly was mentioning that you have acting compliance officers? Can we leverage this role to create the controls and have an approval process in place? This would just mean that we can configure a workflow in the system. Also this recommendation would be possible only if we assume that acting compliance officers would be able to create controls online as the tool does not provide the option to create them offline.
Team – Well this sounds reasonable, it is better to opt for a configuration rather than a customization. We appreciate your suggestion.
Alex – Thank you team, this brings us to the last point of discussing the non-functional requirements.
Kelly – I am glad you want to discuss the non-functional requirements, but I will need to rope in our technical team for this discussion, so let’s plan this separately.
Alex – Sure.
Challenge 13 – The customer was requesting for an offline capability.
Solution 13 – The BA demonstrated great negotiation skill in this scenario. The BA was clearly able to call out the customization and also state the impact. It is very critical to call out all customization upfront so as to avoid any conflicts at a later stage, most often customers do not agree to track it as a change request. Many times customer just makes an ask, if closely analysed the offline functionality will not be used so often so it is definitely not worth the cost and the time, such requirements can be discussed and negotiated with the customer.
Challenge 14 – The BA proposed a workflow to be included as a configuration.
Solution 14 – Again the BA demonstrated great understanding of the tool capability and was able to make appropriate recommendations and help customer meet the needs. As a BA it is always critical to completely understand the business need and make appropriate recommendations. Here the BA was proactive in calling out the assumptions and constraints, it is a best practice to document all the assumptions and constraints for further reference. Also as a best practice do not leave any open ends or ambiguity in requirements.
Challenge 15 – The non-functional requirements were not discussed,
Solution 15 – It is essential that the non-functional requirements should be discussed. It is absolutely ok to involve the larger cross functional teams for additional technical discussion. As a good practice the non-functional requirements should be captured in a separate document.
Scenarios 6
Alex – Hi Team, last week while documenting requirements we uncovered missed requirements, missed corner cases, missed stakeholders and agreed on recommendations. Based on the last week activities I have made lot of updates to the FSD (Functional Specification Document) and I request you all to spend quality time to review it.
Kelly – Thanks Alex, we appreciate your effort in detailing things, but the team thinks they should be fine with what’s in it as we have spent time discussing this.
Alex – Kelly I do understand the teams point of view, but I would highly recommend them to spend some good time on review as this will help us understand all the requirements from the system capability perspective and also help us uncover anything that is missed, any ambiguity or anything wrongly understood. In my experience I would say this is the most critical step to confirm if all of us are on the same page.
Kelly – Thank you Alex, the team now understand the importance of this activity. We will review and share our feedback.
Alex – Thanks for your co-operation.
Kelly – Alex, we believe that this was a fruitful exercise and the team has some points to discuss/clarify.
Alex – This is great, I will review them and provide my feedback, and the team can again review.
Kelly – Well I think this back and forth of multiple reviews is going to be time consuming both for you and the team.
Alex – I do understand your point, in that case I would recommend that we maintain an issue log where we can discuss all open items in the FSD and list all the clarifications, discussions and actions and then I will finally update the FSD.
Kelly – This is a good recommendation.
Alex – Great, I will list the issues and set up a call to discuss and close them.
Alex – Hi Team, thanks for your time to clarify the issues, the FSD is updated based on our discussions and is available for final review and sign off.
Kelly – Alex the team has reviewed the FSD and we formally agree to sign off. I will send you an email for confirmation. We appreciate all your effort.
Alex – Thanks Kelly, I would like to take this opportunity to thank you and the team.
Challenge 16 – The customer was not willing to perform a detailed review.
Solution 16 – It is recommended that the BA enforces a good review process to ensure all issues are addressed and clear, concise and complete requirements are obtained. This was very well demonstrated by the BA in this scenario.
Challenge 17 – The customer had issue with multiple review cycles
Solution 17 – Multiple reviews can be overwhelming, the BA in this scenario demonstrated one way to minimize the review effort, there can be multiple ways of optimizing the review process but it is the onus of the BA to maintain the audit trail and version control of the FSD so that all changes are tracked and a final base lined version is available for sign off. Again sign off is a critical step, in this scenario the customer readily agreed to sign off, but in case customer does not provide a sign off it is the onus of the BA to enforce the sign off. The sign off can be actual formal template, hard copy sign off or just and email confirmation, this varies from organization to organization and can vary from customer to customer.
I hope this comprehensive case study of identifying the requirement elicitation challenges and successful way of overcoming those sets you up with all the successful elements to elicit requirements in the future.
