Science of requirement gathering and the role of a BA

[Music] Hello everyone and thank you for joining another episode of the identity navigator. This is Rohit and today I plan to talk to you all about the science of requirement gathering. What are the components of this framework and why should we really care about this and what typically goes wrong in most of the requirement gathering work that is being carried out.

But before we deep dive into the topic, uh hopefully all of you are having a beautiful beautiful holidays. Uh those of you who celebrate Christmas or Hanukkah, uh had a great uh festival with lots of festivities. Uh was able to spend some time with your loved ones.

I had a pretty relaxing time at work. Uh most of the people were off. I also met a very interesting person by the name of Mike Newen Shounder.

So Mike is a VP analyst at Capinger Cole and he was visiting New York. He reached out to me via LinkedIn. We literally did not know each other.

Uh he asked me out uh as a friend though. Uh so he asked me out uh and we agreed to meet up for a coffee. He was kind enough to drive all the way to my office location and we met up.

And for for those of you who do not know me, I really don't like small talks or social interactions. So I was secretly hoping that Mike would say no that something came up at the last moment and he would cancel but he was persistent. So he did not uh and he was there on time.

We met near WTC uh and I was very conscious of why did I agree to this? But once I met him, it was a great interaction. Mike came across as somebody who is very genuine.

Uh he know a ton about our industry. He obviously knows a lot of the same people that I do. But most importantly, he really came across as somebody who is very likable.

So uh Mike, thank you for making me step outside of my comfort zone and I hope to meet with you soon. uh whenever you are in New York, you have a pal to reach out to now. So uh this is something that I'll be uh doing more in New York as well.

Uh trying to meet some new people. So if any of you are ever in the vicinity of New York City, please reach out to me via LinkedIn or my email and we can definitely plan to meet. All right.

Uh enough about that. Uh today is December 31st. So the next episode will not come out uh before new year or next year now.

So here is to all of you. Have a fantastic start of your new year. I wish you the very best of everything that you hope for and everything that life has to offer.

So happy new year and let's look into the science of requirement gathering now. So what's the number one reason for not being able to optimize resourcing in any project or not being able to allocate the adequate amount of resourcing in any project. Now there are reasons which are outside of our controls right like budget and economy and whatn not but it is also technical debt which takes a ton of time supporting maintaining and removing garbage or legacy processes that are very little value add.

The reason for technical debt is often times considered to be introduction of new tech but it is not. We actively create technical debt every day by implementing suboptimal processes in the name of budgets, speed or executive pressure. So it is not just the old tech but it is the improper implementation that we carry out every day.

And the number one reason for creating technical debt in IM is because we try to design against suboptimal business processes. The processes which are captured by business analyst who then create requirements for the same. So by the time a developer is involved identifies the complexity uh and sometimes even an architect is involved the requirements are already signed off and thus now you have to build against something which is suboptimal in the first place.

I I recently spoke about you know most of the business problems disguise themselves as IM problems and IM team get a ton of flake for the problems that are really business problems. So your user onboarding or your user offboarding IM is just there to automate it but if there are business processes in place which are complex or convoluted or complicated for no reason IM should not be solving this problem. we can be leveraged as anme but it is really a business problem.

Now once we carry out these requirements and get a sign off on these requirements and uh start to develop against them we are in no way shape or form you know we we we are not in a state to actually go ahead and discuss about process rationalization because we have already gone over that hump. So that is where business analyst and how do we gather the requirements becomes such a crucial piece of the puzzle. Often I've seen that the role of business analyst is not given enough importance as much as it should.

These are either subtechnical or semi-technical resources or sometimes junior resources or sometimes maybe uh people who just wanted to get an easy gig. But for me being a business analyst is one of the hardest gig that there is because you have to lead without authority. You also have to understand all the functional use cases of IM.

At the same time, you have to understand what's next in the market. You also need to understand uh the non-functional requirements, the high availabilities, uh the infrastructures and whatnot. At the same time you have to sometimes talk to very pissed-off stakeholders and sometimes very senior stakeholders.

So if you are trying to uh go from a path of individual contributor to a management or a leadership, I think you should definitely try to be try to be a business analyst for the next 6 months or so and really understand the pressures there is in terms of stakeholder management and being good in both technical aspect as well as in uh stakeholder management aspect. So I've commonly seen that the job responsibilities of BAS are to get requirements signed off in time and this is the only matrix that matters in their performance review and and these are what I call false KPIs or key performance indicators. It's like me telling my website designer that they would be evaluated on the number of visitors on the website because in my eyes the number of visitors are proportional to sales but let's say somebody else replaces me and they are just looking at the KPI that I created the sales part is that forgotten and it is all about the click rate that is measured.

So we need to remember that matrix are a means to an end and not the end. And these are false KPIs but these are also called you know I I in my head I I call them matrix gaslighting. These are false measurement of of the actual result that we are trying to achieve.

Uh in this episode we are zooming in on the corner store of any project's foundation. The requirement gathering framework. It is a process that if done right can lead your projects to its desired destination with precision, clarity and auditability.

Many a times you will refer to these concepts like the art of requirement gathering, the art of coding and the art of project management. Now I am not a fan of calling this or any other discipline in IM or software engineering ecosystem art. And this is my rationale because the difference between art and science essentially lies in their method purpose and their means of inquiry.

Art is often aimed at expressing emotions, conceptual ideas and creating aesthetically pleasing objects. It is subjective and open to interpretation. The purpose of art is to evoke a response or provoke thought in the viewers or audience.

Science on the other hand seeks to understand the natural world through empirical evidence and observation. It is objective and based on fact. The purpose of science is to science is to produce knowledge and understanding through research, experimentation and observation.

So think about this. The method of arts are varied and unstructured. They might involve improvisation and personal expression.

In science, we need to be systematic. There should be scientific methods. There should be uh systematic observation, experimentation and analysis.

It it relies on repeatable and controlled methods to test predictions and theories. But most importantly, art is highly subjective. The same piece of art can mean different things to different people.

It is often evaluated based on personal taste, feeling, and cultural context. Science strives for objectivity. Scientific results are expected to be the same regardless of who observes them.

It is often evaluated based on repeatability, validity, and reliability. So think about this quick analysis of art and science that we just carried out. Do you want your process to be subjective in nature or objective in nature?

Do you want your processes to be repeatable in nature or do you want them to be influenced by personal taste? Do you want them to be same to everybody or do you want them to be interpreted differently by different people? And the outcome of art is the creation of something unique that may have emotional or aesthetic value.

Whereas for science we are looking for an outcome that is development of theories, laws and models that explain or predict natural phenomena or employee onboarding and offboarding and whatnot. So in essence art and science are two fundamentally different ways of exploring and understanding the world. Art is about personal expression and the human experience whereas science is about seeking objective truths through methodological processes.

Both are invaluable to society. Don't get me wrong, uh they contribute to culture and knowledge in distinct ways. But let's step into the shoes of your BA or if you are BA then hang on to those shoes.

How is your performance being judged when there is no subjective guidelines on what or how you must capture requirements. Your performance then rests on the development team on whether they can or cannot understand requirements. And that is the reason for my personal disliking of calling anything like this art.

We need to provide our personal exact our people exact parameters to judge their work based on the outcome of their work and not by the feeling of other teams. Requirement gatherings can often seem like a mix of both science and art. But there is a growing consensus on the importance of treating it more like a science.

And why do we need to treat it like a science? Because we are looking at something that is associated with science. And we want those things to be associated with our requirement gatherings, the framework, the process.

And some of them are repeatability and pred predictability. So we need our process to be repeatable and this should lead to predictable outcomes. When requirement gathering is approached scientifically, it ensures that the process can be replicated across various projects with consistent results.

This is particularly crucial for identity and access management projects which requires a high degree of precision and must comply with strict regulatory requirements. datadriven division uh decisions treating requirements gathering as a science mean relying on data and evidence rather than intuition or personal experience for IM projects which are often complex and security sensitive making decisions based on hard data reduces the risk of overlooking critical requirements reduction of bias so for outward-f facing IM systems we which must cater to a diverse user base this object activity is key to ensuring that the system is inclusive and meets the needs of all user segments. Enhanced communication you know as scientific methods provide a common language that could be understood across different disciplines in the context of IM where requirements must be communicated to stakeholders from various departments IT security legal etc.

A standardized approach ensures clarity and reduces misunderstanding and most importantly science is iterative and so is effective requirement gathering. So by continuously refining processes based on outcomes and feedbacks organization can improve their IM solution over time. So that is why we need to treat requirement gathering as a science.

We need to make it repeatable, predictable, datadriven. We need to be explicit about detection of bias. We need to carry out a structured analysis.

The measurement and validation uh should have a scientific way of getting them done. There should be enhanced communication with the common protocols and the continuous improvement. In conclusion, while there is an art to understanding and interpreting stakeholder needs.

The processes and frameworks for gathering and managing these requirements benefit from a scientific approach. For IM projects with their technical complexity and and need for audit trails, a scientific approach is not just beneficial but necessary to ensure the security and reliability of the system. So why is requirement gathering so important?

Oh yeah, another thing that Mike told me u I did ask him about the feedback u on my podcast. He was very appreciative which was very humbling and very kind of Mike. He did tell me that you know he weirdly liked me cping during some of the episodes because he felt like that added a touch of human element to it.

Uh he's weird. I told you all. He also did tell me that music uh was very distracting and I could probably get away with music.

Uh and I did tell him I'll try as soon as I figure it out how to do it. The music is gone. So, thank you for your kind words, Mike, and your fair analysis.

I I I think you were right. I was actually very nervous because I was going to talk to him about we were uh about to discuss the executive orders the Biden's executive orders on AI which was the last episode of this podcast. Uh Mike is an authority on that subject.

So I did look at my notes before going to meet him but he was very kind and did not embarrass me there. So all right let's back to the subject. So why is requirement gathering so important?

So imagine setting sail without a map. You might catch a good wind, but will you arrive where you need to be? That's where gathering requirement is not just a phase.

It's a disciplined approach to charting the course of your project. While generally requirement gathering focuses on what a system must do, it requires additional work for an IM initiative because there is compliance with regulations like GDPR, HIPPA and numerous others. An IM system must be built on a framework that just not robust but also transparent and traceable.

The ability to audit who exist what, when, and under what permissions or which permissions isn't just a nice to have for our systems. It's a must-have. This is where the skills of requirement gathering comes in.

It is not just about knowing what the system should do, but understanding the who, the what, and why behind every transaction. It's about ensuring that every touch point is locked, every user's journey is traceable, and every action taken within the system is accountable. Imagine launching an IM system that can't tell you who changed the record or accessed sensitive data.

That's like a ship setting sail without a log book, navigating blind in a sea of potential breaches and regularity storms. That is why as business analysts or project navigators, the depth of our requirement gathering must match the depth of the digital sea we are traversing. It's not just about the technical specs.

It's about the narrative of security, the story of compliance and the script of user interaction. Every login, every role assignment, every permission modification must be chaptered in a well doumented saga of security. And this narrative begins with comprehensive requirement gather.

As a BA, whether you wear a technical hat, a compliance helmet or a user experience gap, your mission is to weave those threads into a cohesive and secure tapestry. That is why your role in requirement gathering is as much about understanding the laws of digital lands as it is about the technical know-hows. It is really unfair for a role to be able to understand the business, understand the technology, be a master negotiator, be great at leading without authority, be able to carry out stakeholder negotiations.

push back when required, forwardlooking and that is why BA role is not a simple rule and anybody who doesn't understands this or short staffs their BAS actually messes up their projects in the very first phase and that is where all this technical debt or fighting with infighting with the stakeholders comes into picture because you have agreed to something with them. and you have agreed to their requirements. You have already taken 20 hours of their time gathering the requirements.

So BA is a tough job because your first impression is your last impression. Sometimes the business might feel like you don't know enough and sometimes the business might feel like you do not understand what they are saying. So it is a tough gig.

There is no doubt about it. And and let's not forget the outward facing nature of of our IM systems means the audience of the security play isn't just internal stakeholders. It's the customers.

It's the partners. It's potentially the whole enterprise who don't care about IM right but we care about them because some of them or most of them make money for the business that pays our our salary. So in the vast ocean of identity and access management, requirement gathering is your anchor ensuring that no matter how strong the tides of change and regulation, your IM system stands unwavering, a bastion of security and a beacon of compliance.

So within this requirement gathering framework, let's deep dive a little bit more into this business analyst rule. A business analyst plays a crucial role in the bridge between the company's business needs and the solution provided by IT services or other stakeholders. And the core duties of a BA can or should include understanding business objectives.

They should be able to identify and understand the business needs and objectives by working closely with stakeholders to define and prioritize business requirements. This is to say they should be very sharp to understand the business. At the same time, they should be likable so that business should be willing to spend time with them.

Conducting research, they should be able to perform thorough research to gain a deep understanding of current business processes, systems, and the context in which the business operates. Uh you will not be given everything on a platter. You would have to dig deep into those confluence pages, those shareepoint, the documents, the link that business shares.

So you should be very very good at research requirement gathering. Obviously they should be able to elicit, analyze and specify requirements through interactions such as interview, workshop and surveys with stakeholders. Now there are multiple tools about how do you carry out requirement gathering meetings.

You can have interviews, workshops, stakeholders, uh whiteboarding sessions and uh whatn not. But at the end of the day, the key word here is the BA should be able to analyze the requirement. They should go through a first level of analysis during that meeting itself.

And in this requirement gathering phase, this can also involve or this should involve creating detailed business analysis outlining problems, opportunities and solutions for a business. They should be able to critically evaluate the information gathered and reconcile conflicts, decompose highle information into details and abstract up from low-level information to a general understanding. Documentation goes without saying.

They should be able to translate and simplify requirements and ensure that they are properly documented and maintained throughout the project life cycle. They should be able to carry out process modeling. Now this is where I think most BAS fail.

They should be able to create process models, specifications, diagrams and charts to provide directions to developers and project teams. So we need to remember that developers have not spoken to the business. It's the BAS who have spoken to the business.

So they should not believe that their job should be done if they have filled in an Excel file because that is what the objective was. They should be able to provide anything that is needed so that the developers understand the discussions and details creating those process models, specifications, diagrams, charts, whatever it it takes so that the developers understands what is truly expected of them. They should be able to assess available solutions and identify new approaches that can meet business objective.

This can include accessing the business impact and risk associated with the new solution. BA should be helping with project management support because assisting with project management by helping to plan projects, monitor timeline, ensure that project deliverables meet business requirements. They need to act like a as as a layers on between business units, technology teams and support teams ensuring open communication and that stakeholders needs and concerns are addressed.

They should be able to test solutions or help to test solutions, identify problems and suggest improvements, ensure that the deliverables meet the business requirements and are of highest quality. Because if you have ever played the game of telephone right one person says something to other person other person says the same thing to the third person and and like and like so you know the information gets diluted. So if the business talks to BA they document something the document is looked at by the QA QA creates test cases based upon that there's a lot of loss of information.

So with VAS helping to test solutions, identifying problems and you know ensuring that the deliverables meet the business requirements that loss of information doesn't happen and we can ensure the highest quality deliverable change management right uh if done right BAS are the people who the business know and trust the So BA should be facilitating change management efforts associated with projects including communications and training plans to ensure smooth adoption of new systems or processes. They should be able to contribute to strategic planning and help in decision-m processes by providing datadriven insights and analysis. Continuous improvement.

They should be able to advocate for and and contribute to the continuous improvement of internal processes and deliverables. It's not a one-sizefitit all. Every company is different.

Every uh team is different. Every initiative is different. And they need they should they absolutely have to stay a breast of technology trends and advancements to bring the best solution to the company and maintain a competitive edge.

[Music] So to summarize, I I told you this is a tricky job. This is a hard job. They should be able to understand business objectives, conduct research, gather requirements, analyze requirements, document requirements and manage requirements, process modeling, solution assessment and validation, project management support, stakeholder management, quality assurance, change management, strategic planning, continuous improvement and technology analysis.

Now, there is a hot debate. Should business analyst be technical or non-technical? Hold that thought.

We'll navigate these murky waters in just a moment. But let's deep dive into our requirement gathering framework. I've given it a lot of thought and I've tried to simplify it as much as possible.

So I've tried to keep it away from any buzzwords or jaggers. So it's a fivephase voyage elicitation, analysis, documentation, verification and management. Right.

These are the five phases of our requirement gathering framework. Each phase is a stepping stone to the next, ensuring that no details are left. In elicitation, it's all about discovery.

As a solo navigator, your compass here is your ability to listen, observe, and ask probing questions. It is about engaging stakeholders, conducting interviews, sending out surveys and truly understanding the needs that drive the project. Then we sail into analysis.

This is where you as a BA must decode the information gathered. It's a process of distillation, separating the wheat from the chaff to pinpoint the core requirements. Now on to documentation.

This is where the business analyst becomes the ctographer meticulously mapping out the requirements clear concise and comprehensive because this documentation is your best defense against the turbulent seas of project ambiguity. I don't sometimes mind uh BAS carrying out a sort of Moscow rationalization here. must have, should have, could have, good to have.

You know, what is something that the business absolutely needs versus what is something that's good to have or nice to have. It is good for a developer to know or a project uh manager or a product owner to know. Moving on, verification is your checkpoint.

Are we still on course? This phase is about validating the requirements with all stakeholders. It's a collaborative effort to ensure that the map accurately reflects the territory.

You shouldn't be talking to your stakeholders and then going away and then not talking to them before we are ready for the release. And finally, we have management. Requirements aren't set in stone.

They are like the tides constantly shifting. As a business analyst, you must be able to adapt at managing these changes without losing sight of the shoreline. Right.

So the five phase that we spoke about in the requirement gathering framework are elicitation, analysis, documentation, verification and management. Now often the requirements gathered by business analysts are marked as final against which the development is carried out. At max the requirements are classified in functional and non-functional buckets.

But for me that's not enough. That's not granular enough. System should also be considered from additional lenses.

Now considering the following only during the design phase leads to a Lego brick architecture anti pattern. So what are those lenses through which you should be looking at those requirements outside of those functional and non-functional buckets? Usability.

The solution must be appropriate to the technical competence of the intended users and ergonomically acceptable to those users. Imagine everybody in your company has an Android phone. I said imagine.

and you create an Apple app or an iPad app for it. Interoperability. The solution must provide for the long-term requirements for the interoperability between communicating information systems and applications.

Integration. The solution must integrate with the wide range of computer applications and platforms for which it might be required in the long term. Supportability.

The solution must be capable of being supported in the environment within which it has been designed to be used. Let's say your company is all about cloud or your company is all about onremise or your company is all about Java. need to think about these things during the requirement gathering phase itself.

These should be the buckets against which you are uh creating your requirements. Low cost development. The solution should be a modular design and hence capable of being integrated into a development program at minimal cost.

One of the things that I have seen most often in in security is we are always fighting amongst usability versus security. You know all of you must have seen that XY chart in which usability is on the X-axis and then security is on the Y-axis or vice versa. And and we need to have you know something which is both usable and secure.

But it's it's not a two-dimensional problem. It's a fourdimension problem. And those four dimensions are usability, security, cost, and time to market because fast time to market is as important as any of the other three things.

So the solution should be capable of being integrated into a development program with minimal delay. Scalability of platforms. The solution should fit with the range of computing platforms with which it might be required to integrate.

Scalability of cost. The entry-level cost should be appropriate to the range of business applications for which the solution is intended. Scalability of security level.

The solution should support the range of cryptographic and other techniques that would be needed to implement the required range of security strengths. Reusability. The solution should be reusable in a wide variety of similar situations to get the best return on investment in its acquisition and development.

Operations cost. The cost impact on system operations should be minimized. Administration cost the solution should provide an efficient means for security administration to optimize the cost of this activity.

And then risk based cost benefit effectiveness. The reduction of risk which is the benefit should be appropriate to the cost of acquisition, development, installation, administration and operation. So you know we don't just have to look at it or all the requirements from a functional and non-functional bucket.

These are all the other things that I mentioned that you need to look at while drafting your requirements. Now all of this might not be applicable for your cases 100% of the time and that is why you know the Moscow framework or must have should have nice to have might come into picture. For some of you time to market would be a mustave.

The system should be ready in the next 3 months. For some of you it doesn't matter. For some of you the cost should be under a definitive amount.

For others doesn't matter. Right? So look at usability, interoperability, integration, supportability, low cost development, fast time to market, scalability of platforms, scalability of cost, scalability of security level, reusability, operations cost, administration's cost and risk based cost benefit effectiveness as your additional buckets while drafting your requirements.

Now back to uh the point that I raised earlier about the debate that should business analyst be technical or non-technical. The truth is it is not black and white. A technical background can be a strong tailwind empowering you to understand complex systems and communicate effectively with the IT crew.

However, the essence of business analyst role is to bridge the gap between stakeholders and developers to speak both languages fluently. A business analyst can be technical possessing a strong understanding of technology, systems and data analysis tools or nontechnical focusing more on business processes, management and planning. However, even non-technical BAS need a certain level of technical proficiency to effectively communicate with IT stakeholders and understand the possibilities and limitations of technology solutions.

The balance between technical and non-technical skills can depend on the specific role, industry, and the company the PA is working in. But it it's less about your technical prowess and more about your ability to translate needs into actionable solutions. Make no mistakes, this is a tough job.

Sometimes not getting the respect it deserves and treated like an entry-level resource or a job. I personally prefer my BAS to be extroverts, understand human emotions, hardworking and inquisitive. A BA should ideally exhibit a blend of interpersonal, analytical, technical, and management traits that enable them to effectively perform their role.

And some key personality traits that are beneficial for a BA. Again, your mileage may vary, but are analytical thinking, ability to dissect complex problems, analyze data, and derive meaningful insights to make informal decisions. Now, some of these things that I talk about are non-negotiable.

Technical versus nontechnical is a different beast. That's a different thing. You can succeed without one or the other.

But without these things that I'm going to mention, a BA will not be able to succeed. Analytical thinking being the first one of it. Communication skills being the second.

Proficient in both verbal and detail communication. Able to clearly articulate ideas, requirements, and solutions to both technical and nontechnical stakeholders. Problem solving.

An innate desire to solve puzzles and challenges. Finding creative solutions to business issues. Detail oriented attentiveness to the minuteest of details without losing sight of the big picture ensuring that all aspects of the projects are covered, considered and addressed.

Empathy, the ability to understand and share the feeling of others, which is crucial when dealing with stakeholders and understanding their needs. I typically don't like BAS being too complaining, you know, negotiation and and persuasion, capable of navigating disagreements and convincing others of the validity of their feelings and recommendations. Adaptability.

Comfortable with change. Able to adjust strategies or approaches in dynamic business environments. Facilitation.

Ability to guide discussions, manage conflicts, and drive consensus during workshops or meetings. Curiosity. a natural inclination to inquire, learn and understand the evolving landscape of both business and technology.

You need you would have to understand your business. You would have to understand the domain that you are in. There is no other way.

It is not expected to be at the level of an engineer. that you definitely need to understand the services or the solutions that you are providing. Leadership every leader should be BA at one point of their time.

Capable of taking charge when necessary in guiding project teams and stakeholders toward achieving business goals. Organizational skills proficient in managing tasks, schedules and documentation. And they often juggle multiple aspects of a project simultaneously.

Customer focused, always considering the impact on the end user and striving to meet or exceed customer satisfaction. Collaborative enjoy working in teams and believes in leveraging collective knowledge and skills. Resilience, the ability to cope with setbacks and maintain focus on goals despite challenges or pressures.

And I have saved the most important for the last. Integrity holds high ethical standards and is trustworthy, ensuring transparency in their work and decisions. These traits combine to help the BA to function effectively, facilitating communication between various stakeholders, analyzing business needs and ensuring that the solutions developed meet the requirement set forth by the business.

Remember that requirement gathering is a journey. Whether you are a technical wizard or a master communicator, your role as a business analyst is to steer the project to success. I think we'll stop here.

Thank you all for listening. Thank you for everybody who reached out to me via LinkedIn or the email. For those who are new, you can reach out to me via LinkedIn or you can always find me uh or email me at the identity navigator@gmail.

com. Happy new year everyone. Party hard, be safe till next year.

This is your host, your identity navigator Rohit.