Common sources where you can identify business requirements
Now that we understand how to identify requirements and why it is important for a business, let’s review the various sources where we can gather these requirements.
Document analysis
Document analysis involves getting your hands on any relevant documentation: scope documents, project initiation requests, business plans, knowledge transfer artifacts, manuals, presentations, minutes of past meetings, user guides, and so on.
Identify key stakeholders
Who shall be impacted by the change directly or indirectly? You can start with a business sponsor and a program manager. Find out the scope and range of the project implementation in terms of various Business Units (BUs).
Navigate the organization
Get to know SMEs, data captains, planning team members who focus on analytics and management dashboards, and a few enthusiastic end users.
Current system usage
Find out how current systems are used to perform their job and how they are integrated into other systems in the company.
This is a great opportunity for you to observe and find opportunities to enhance and simplify the processes and save time and frustration.
An example would be users struggling to access the system due to login issues (incorrect password or system lockout due to too many incorrect password attempts). This can be easily addressed via enabling Single Sign-On (SSO), which is available out of the box for almost all cloud applications. With SSO, users need to click on one bookmarked URL to access an application.
Identify the key end user
Users who are passionate about the change and who are direct beneficiaries understand existing work practices and existing unaddressed problems. I listed them separately as they are not identified as part of the project stakeholders. They can be your level 1 support or call center representative.
Plan brainstorming sessions by facilitating the conversation and allowing key participants to openly debate and speak out. Take notes and make sure that you let the conversation flow freely; your job is to facilitate the conversation and ask questions as appropriate.
Needs decomposition
Try to get as much information from whatever source possible via decomposition, breaking down needs into smaller needs until they can no longer be decomposed. This way, we are breaking down a complex requirement into multiple small and simplified individual components of the needs.
Get a system walkthrough
Understand firsthand how end users normally use the system regularly. Be an observer and let the user navigate and walk through their process in the system end to end. This user journey helps you understand and identify missed elements and any usability requirements.
Active participation
Listen attentively and actively, acknowledge, ask questions, and rephrase what you heard and understood. This is to ensure an accurate understanding of what has been communicated is agreed by both ends. Also, avoid judging what you heard so that information flows freely. Focus on business needs and do not get into designing the solution.
Most often, the stakeholder assumes that the Business Analyst already knows or is aware of the business needs and provides high-level information only. Business Analysts need to make sure that information is provided in enough detail.
Let the participants debate and let them vent their frustration. You get facts and truth from this kind of conversation and are able to grasp stakeholders’ perspectives of business needs.
Different stakeholders may have different perspectives; it is your job to explore them and resolve any conflicts.
Make sure you keep the discussion aligned to the agenda and manage it so that it doesn’t get out of control.
Existing systems
Find ways to get access to current systems and be able to run some key reports and dashboards. This will help you identify and get reports and stats on end users who use the system.
During one of my first implementations, I was able to run a few reports and find out who the power users were. I ran stats and saw why usage dropped from quarter to quarter (or over a period). By doing this, along with the data and facts I had gathered, I was well prepared to ask the users the right questions.
Note-taking
Take notes, prepare minutes, and share them with the participants on the same day and solicit feedback. Clarify any open queries one on one with specific participants.
When taking notes, make sure that you tag the requirement type as business, stakeholder, solution, or transition. By understanding the requirement type, you can fine-tune and facilitate the conversation effectively and efficiently.
Assumptions
Avoid and eliminate all assumptions around requirements. Business needs must be verified and assumptions, if any, need to be confirmed and documented.
Meeting minutes
Prepare and share a list of simple, clear, consistent, and complete high-level requirements. This will help you provide the steps that must be taken.
Now that we have learned where and how we can identify and gather business requirements, let’s learn how to implement them with some real-world examples. These will be covered in the next section.
