Requirements Gathering: A Quick Guide

Explore the intricacies of collecting essential information, understanding the significance of each detail, and mastering the art of effective communication with stakeholders. Let’s delve into the core principles and best practices that pave the way for seamless project execution and client satisfaction. Let’s start our Salesforce Requirements Gathering: A Quick Guide.

What is Requirement Gathering?

Requirement gathering is the first step of the Software Development Life Cycle (SDLC). The project team connects with the client to learn about their needs and how they expect their system to function to address them. The requirement-gathering discussion includes understanding the current business process, the personas involved in the business, the input and output of each phase of the business process, and pain points in their business due to the current technology they are using.

Importance of Requirement Gathering

There are several reasons why requirement gathering is an important phase in software development. Here are a few of them:

The Foundation of the Solution: The solution is the system that developers build aimed to address the client’s issues. Thoroughly collecting information from the client regarding their business process, their problems, and their need is crucial. This comprehensive understanding of the problems and needs forms the base for developing an effective solution.
Understanding the business and personas involved: When the project team learns about their client’s business, they also learn about the various departments and personas involved in the process from end to end. This gives the basic knowledge of the flow of information in the business which can be implemented in the solution in the same or better way. Knowing who are participating in the client’s business enables developers to tailor the system that address user-specific needs.
Comprehending the Pain Points: As the developers gain more knowledge about the client’s existing system or process, they also identify and comprehend the issues within the existing system. This is essential as it opens the door to designing a solution that targets those challenges and raises the solution’s overall efficiency.
The Foundation for Constructing Business Process Flow and User Stories: As requirement gathering is the first phase of SDLC and based on this the subsequent phases in the software development proceed, collecting information as much as possible and confirming the facts with the client is an essential step. Based on the gathered information, the business process flow is prepared, which is then acknowledged by the client. With this, the project team moves forward with the preparation of user stories which has the significant role of outlining the step-by-step processes and interactions within the system. Therefore, requirement gathering serves as the foundation for building business process flow and user stories.

What and How to Gather Requirements?

First, let’s see what information can be gathered during the requirement-gathering phase.

Who is going to use the system? (Collect their name, role, and email ID)
What is the current system they are using?
What are the challenges the stakeholders/employees face with the current system?
From which persona/team/department does their business begin, and how does it proceed?
What are all their Key Performance Indicators (KPIs)? How do they measure their success?
What is the role hierarchy followed? Is there any approval process required?
Does the business process involve any document generation and require the signature of authorities?
What are the countermeasures taken if an unexpected situation arises?
What is the current medium used for communication?
What are all the records do they maintain?
How often are the records updated, and by whom?
Do they require reports to be generated? If so what and when should be generated?
What are all the Salesforce licenses the client is willing to purchase and how many are going to be purchased?
Who is going to have which license?
In what language do they prefer their solution system to be?

The above questions are not the only questions to be asked during requirement gathering. In real-time, if you start with these questions, you might get counter questions (the questions that arise from the answers given to the previous questions). Gather as much information as possible and avoid any assumptions.

How to Gather Requirements

Now let’s know how to gather the requirements.

Set up a meeting with the client, mentioning the purpose of the meeting. This gives an idea for them about what the discussion will be about and gives enough time for them to prepare.
Book a quiet meeting room for the team to work peacefully.
Pen down the important points. Make a note of the documents requested from the client and the documents that are to be sent to them. If there is any confirmation of fact or details to be given by the clients that require time, make a note of it so that one might not forget to get the details in the next meeting.
Never assume things. If any of the details or processes in the business are not clear, then repeat whatever is understood and verify your understanding is correct and that you are on
the right track.
Do not hesitate to ask counter-questions. It is natural to ask counter-questions. So, if anything is vague or requires elaboration of details, go ahead with the questions.
Give clients an idea of how a particular, complex functionality of the system works. During requirement gathering, the client may expect certain things that the Salesforce system might not do or that require some customization, which is not a part of the scope for a particular sprint. So, to make them understand what the system can do by giving them a very short demo of the functionality using sample data. This might make the clients to rephrase their requirements for the current phase or the sprint.
After the meeting, it is advisable to sit with the project team members who attended the call and discuss the points taken down. This is done to ensure that everyone is on the same page in understanding the requirements and the business process of their client.

Best Practices to Gather Requirements

There is no specific way to gather information; it varies from organization to organization, department to department, or even from project to project. However, if certain practices are followed, the requirement gathering can be effective. The following are such practices:

It is always good to enter a meeting with preparation. Prepare certain questions to be asked during the call. This leads to better understanding and information gathering.
Prepare some sample data to show a short demo, not the entire system but one or two functionalities of the system that might confuse or not give a clear picture to the clients. Sometimes, clients may face difficulties in comprehending the consultations provided during the requirement gathering call. So, to make them understand how the system works, it is better to have a sample ready. It may be shown during the call or it may not be.
Gather information topic-wise. For example, if requirements are gathered for account and contact management, have a separate heading as “Account and Contact” and under this make note of the points. Have a separate space in the document for making note of abbreviations and acronyms.
It is recommended to record the meeting so that when the developers need clarification on any detail, they can replay the recording instead of expecting the client to clarify every time. Also, let the clients know that the meeting will be recorded.
Still, if the developers are not good at understanding of requirements or any business process and can’t reach the client immediately, then it is advisable to maintain a separate document, where the developers can write down their questions and expect answers from the client in the next meeting.

Do not use too much of technical terms while gathering requirements. If technical terms are to be used, then give the clients an explanation about it in two or three sentences and resume the discussion.

For instance, it would be better if the speaker talks about what is Salesforce Account (The Account in Salesforce is used to store information regarding the organization with which the client has business. It stores details like the name of the organization, address, contact information, website, etc.) first and then asks about how they track these details currently instead of directly asking the client “How do you keep track of your account details?”.

The clients are new to Salesforce terminologies. So, it is recommended to avoid too much usage of such terms.

If the person leading the meeting is encountering difficulties in explaining certain concepts or ideas to collect information, other team members can take the initiative to explain that. Only one in the team doesn’t need to speak and answer the questions the client asks, but other members in the room can also speak and support the thoughts. Interrupt the conversation politely and share their opinion or suggestions.
Make note of the details either using pen and paper or use note-taking applications such as Quip, Microsoft Word, or Google Docs. Make sure that everyone in the team takes notes in separate files and stores them in a shared location. If one is using pen and paper to take down the points, then digitize it by either typing the contents or scanning the notes and keeping it in editable format.
Take notes in such a way that it is understood by not only the one who takes it but also all the other team members. It is because, if in case this person has to leave the team due to any cause, then someone who replaces them should also understand the project requirements.
Avoid gathering information in paragraphs. Instead use bulletin points, and tables wherever required. Format the text in different colors, make important details bold, or underline it to highlight.

If the requirement from the client’s side is not clear enough, then it is okay to ask them to repeat the statement or explain further. Do not jump to conclusions quickly.
Do not expect the Point of Contact (POC) from the client side to have thorough insight into all the procedures that they follow in their business process. At times, when they might need time for internal discussions or further clarification. It is crucial to exercise patience and wait for them to provide a clear answer, as requirements are subject to change based on their responses.
Remember to provide breaks of 5 – 10 minutes in between the meeting, if the duration is more than 2 hours. This lets the developer team as well as clients to comprehend the discussion that happened so far and concentrate well on the discussion.
Always keep track of the documents requested from clients to enhance understanding of their requirements. Send them a gentle reminder if not received on the specified date. Similarly, keep track of the documents the developers need to send to the client.
Conduct the meeting in a quiet environment. Sometimes, a noisy background either from the developers’ side or the client’s side will lead to loss of data or misunderstanding of the details. So, always choose a peaceful environment for conducting a meeting.
Apart from these, the general advice would be to have good internet connection if you are attending the meeting remotely. Verify if the camera and mic are functioning properly on your computer. It would be better to turn on the camera while speaking to have a better interactive session. Make yourself presentable if the meeting is held in person or when you turn on the camera.

So Far We Learnt…

We have delved into the significance of requirement gathering and the methodologies for collecting vital information during these crucial sessions. Furthermore, we have explored the essential practices to adhere to during requirement-gathering meetings. It is imperative to implement these strategies in your future engagements to ensure a comprehensive and effective requirement-gathering process. By following these guidelines, you can enhance the quality of your interactions and contribute to the success of your projects. Please share your feedback on Requirements Gathering: A Quick Guide.