In this chapter, we will discuss the role of a Business Analyst and different types of software requirements. Then, we will review some important factors that will help gain project sponsors’ confidence and trust. Finally, we will explore common sources to look out for that help us spot and identify business requirements. We will also touch upon, at a high level, some business analysis lingo that you should be aware of to be able to facilitate business analysis activities. Remember, we wish to identify requirements at a very high level. We will do a deep dive into understanding requirements in more detail and from different perspectives during the elicitation phase, which will be covered in the next chapter.
In this chapter, we will cover the following topics:
By the end of this chapter, you will have a good idea of where and how to find requirements that will help you with requirements gathering. You’ll also know what you should do to understand current processes and observe the inefficiencies, roadblocks, and opportunities surrounding them.
Before we get into details of the business analysis role, let’s quickly review what some common terms mean, which will be helpful in our upcoming discussions:
With this basic understanding, let’s discuss business analysis in detail.
Business analysis work starts with planning – there is no one cookie-cutter approach that works for every project. Business Analysts need to know and understand the context and characteristics of the project to ensure that the planning activities are scoped accordingly. Prior planning and spending time on identifying the user requirement sources will lead to a better understanding of the scope of business analysis work, stakeholders’ expectations, and the amount of analysis work that needs to be done in subsequent phases of the project. We need to create a well-thought-out business analysis roadmap so that the analysis process is effective and successful.
As a Business Analyst, the first and foremost task to focus on is identifying business needs. Business needs are gaps between the current state of a business and its expected goals. Business needs analysis is also referred to as gap analysis – the current “as-is” state versus the desired “to-be” state. Needs are the basic drivers of change. By understanding needs, the Business Analyst can document requirements. This activity happens during the project planning or pre-project phase. As an analyst, you will use this data as a starting point for requirement gathering and elicitation or to create a business plan and provide findings for management decision-making.
Before you get into the requirements, you need to plan and identify where you can get the business needs and requirements. What are the good quality sources and where can you find them? These can be from stakeholders, documents, existing processes, observations, interviews, and so on.
I have worked on multiple global projects where the projects started at different stages. Most of the time, the majority of the functions that are needed are on existing systems – enhancing or adding more capabilities. I got the opportunity to work on a few projects where, as a Business Analyst, it was me who would guide the business, identify requirements, tools, and systems, and provide a system that the business can benefit from and value. This is very stressful as well as rewarding when you have to guide stakeholders and help them understand their requirements and needs. I will touch upon various examples along the way that may benefit you.
There are three possible business requirement scenarios that I would like to cover:
Based on these scenarios, let’s explore our analysis process. Examples for each of these scenarios have been provided with screenshots in the Real-life scenarios with examples section.
Project teams and IT teams most often blame the business users, stating that they do not know what they want. That is the very reason why we have Project Managers, Business Analysts, IT teams, QA teams, training teams, and so on. Business users do not need to know what they want. It is up to the project team, especially the Business Analyst, to identify the right stakeholders, pull ideas out of users, and get agreement from everyone.
Stakeholders, even though they know the problems in most cases, do not know how to articulate their needs. On the other hand, few users can articulate, anticipate, and lay out their needs, wants, and desires, and pretty much want everything their way. You need to be cognizant of both and watchful for the latter.
In reality, only a few requirements are documented in some form. Most of them reside in the heads of stakeholders, end users, and process flows that are yet to be understood and developed.
For a project to be successful, understanding and documenting requirements accurately is one of the key success factors. Failure to understand and capture requirements accurately will lead to project delays, false expectations, broken promises, blame games, and stressful situations. So, let’s focus on learning, understanding, discovering, and getting the right requirements by focusing on extracting the ideas, issues wants, and needs of the users.
Note
I will be covering real-life practical scenarios – successes as well as failures and lessons learned. We will use many existing Business Analyst tools and techniques. As needed, I will explain them at a very high level. I will not be providing definitions or procedures; instead, I will explain the scenarios with practical examples based on my experience.
Let’s delve into what it takes to identify business needs and wants. Our ultimate end goal here is to identify a set of requirements that are consistent, non-redundant, and complete. In this chapter, we shall concentrate only on the extent of learning problems and/or opportunities to sufficiently understand the situation and not perform a complete requirement analysis, which shall be explained in future chapters. Ensure that you’re not subjective and judgmental; you are here to understand business needs, not design solutions. As Business Analysts, we must make every effort to understand business needs and wants, how they align with the vision/strategy, and how this enables us to achieve our strategic end goal.
As Business Analysts, we need to get as much information as possible by exploring all possible avenues and areas. You need to know what information you must get and where to find that information. For that, we need to ask six (5Ws + 1H – Who, What, When, Where, Why, and How) questions iteratively to completely understand the full scope and intent of the business needs. When asking these questions, you should know the rationale for every question and be able to explain to stakeholders why that question is relevant.
By understanding different types of requirements, you will be able to manage the requirements process effectively at all project stages. Remind yourself that we are here to gather information to identify the real problem or opportunity and not to provide our opinions or solutions.
There are four main types of requirements, as listed here:
The most notable requirement is data migration. In the process of ETL, data may be rendered useless if data migration is not done diligently. I have seen many instances in projects, including the one I worked on a few years ago, where, after converting HR data, the team was unable to run the payroll on time. You know what’s going to happen if employees are not paid on time.
Knowing and understanding different requirement types and establishing goals and timelines for identifying requirements will help pave the foundation for the next step of our business analysis. Here, we are trying to understand the current state and the desired future state. Analyzing business needs and wants will help us provide the right solution or address the right problem during our design phase.
In the past 15 years, I have worked on multiple Salesforce implementations: Sales Cloud, Service Cloud, and Partner Relationship Management. I employed more than one method to get to know and understand business needs. It all depends on your implementation methodology, people, culture, IT team maturity, and so on, and you need to tailor and use a combination of the methods discussed in the Common sources where you can identify business requirements section, later in this chapter.
Securing support from a project sponsor is another important factor for any project to succeed. The business analysis process and the Business Analyst play a vital role in securing confidence and trust with the project sponsors. Business analysis involves defining the requirements, designing the solution, communicating, validating the solution, and training activities so that they are well positioned to access and identify project impacts. They can act as the eyes and ears of the project sponsor. The project sponsor often depends on project managers and Business Analysts for all key decision-making. Just like gaining confidence and trust from subject matter experts (SMEs), project team members, and super users, we have to gain the project sponsor’s confidence and trust too. One of the most important activities is to keep the sponsor in the loop at all times.
As a Business Analyst, you can gain project sponsors’ trust and confidence by assisting them with information and the decision-making process. This is possible through good planning and communication. Let’s outline what you should be doing to help the sponsor:
Gaining confidence and trust will help Business Analysts navigate business analysis work smoothly, efficiently, and productively. This will help the project team and you, as a Business Analyst, in areas such as the following:
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 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.
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).
Get to know SMEs, data captains, planning team members who focus on analytics and management dashboards, and a few enthusiastic end users.
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.
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.
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.
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.
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.
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.
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.
Avoid and eliminate all assumptions around requirements. Business needs must be verified and assumptions, if any, need to be confirmed and documented.
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.
Business needs vary from very simple to extremely complex. With the help of three different practical scenarios, I will explain the various needs and discuss how they are addressed and implemented. A strong understanding of business needs will help us in the elicitation phase.
This is a simple scenario where users know what they need. It could be an existing pain point where I am looking for improvements. This case is true when users are already using the system and they can easily point out the gaps, be it defects or enhancements to the application.
For example, in Salesforce, duplicate leads, accounts, and contact records cause multiple issues down the line. These types of requirements are very straightforward. As a Salesforce-savvy Business Analyst, I can provide a quick solution. Here, I could suggest that users use the available duplicate management functionality.
By understanding the business needs, we can fulfill this requirement quickly by using existing out-of-the-box features from Salesforce. We will be able to find a quick solution for the majority of simple requirements. The key is to understand the business needs.
This is an example where elicitation is straightforward as business needs can be articulated easily and clearly.
Note
You may have to do a one-time cleanup of existing data to implement this solution.
Duplicate management functionality on the contact record
Here, we shall implement a rule where the Salesforce system will prevent users from creating duplicate contacts if the last name and email combination match.
A duplicate rule with matching criteria can be quickly implemented. Whenever any users try to create a duplicate contact, the system should prevent the user from creating one. The following screenshot shows a duplication rule being created:
Figure 1.1 – Creating a duplicate rule
In the following screenshot, I tried to create another contact with the same last name and email address. By implementing a simple duplicate rule, the system should prevent duplicate contact records:
Figure 1.2 – Salesforce system preventing users from creating a duplicate contact
You can view the duplicate as shown. Here, users will be able to make any updates as needed to the existing contact record:
Figure 1.3 – Option to view the existing duplicate contact record
You can also propose a more robust solution using AppExchange packages such as Demand Tool, which is an excellent tool for keeping your data clean and relevant. This is a managed package and there is a subscription fee per user. There are many paid and free tools on AppExchange. Do your research and try them in a sandbox before deciding to use them in your production environment.
Users want field attributes defaulted by the system so that they can avoid re-keying the same data again for a specific BU.
For example, the billing address that’s available on the account record shall default when creating contact records for specific country users.
To illustrate this, we will look at another simple example where users can update their billing address with a company billing address. By automating this, the data quality stays accurate, current, and relevant. In Salesforce, this can be achieved via Process Builder. You can do the same with Flow Builder too. Process Builder will replace Flow Builder going forward, so it is advisable to start flows for automation:
Figure 1.4 – Using Process Builder to automate address updates on the contact record
Let’s look at another example. In Salesforce, the Sales team would like to see certain fields from the User record and Account record defaulted on the Opportunity record page. This requirement requires some level of analysis.
To simplify this, let’s look at a simplified requirement. A specific BU user would like to default certain field attributes from the User record (such as Region, Country, Division, and Department) and Account record (such as Account Owner, Industry, Account Type, and Rating). The rationale for this requirement is to have information available on the same Opportunity record and also be able to create list views from the Opportunities tab. To simplify further, let’s assume you, as a Business Analyst, socialized this with other BU stakeholders and got confirmation that they would like to have the same functionality extended to all.
You can have multiple solutions in Salesforce. Here, you can go with flows, but the simplest and easiest solution is to create a formula field. In our case, this is the preferred solution as users need data with view access; any updates that are made to user or account attributes are immediately reflected on the Opportunity record page.
This example helps you elicit unexpressed business needs. By observing or analyzing the ways to improve data quality, you, as a Business Analyst, shall be able to suggest the needs to business users and implement the same. Implementing these unexpressed needs helps in maintaining quality data and also reduces the time it will take the user to create data.
This scenario is more complex than the others. These are instances where, in one of my previous projects when we did Partner Relationship Management (PRM) in Salesforce, the business users needed systems and functions but they did not exactly know how to explain or articulate the requirement. At a high level, the requirement was to have the PRM system migrated from an in-house custom build system to a sales cloud for partner with Account, Contact, Opportunity, Case, Campaign, Quote, and Lead Management, plus Partner Locator, Partner Onboarding, and User Onboarding. This was a hugely complex project that was delivered successfully over 3 years incrementally using agile methodology.
As an example, let me explain a relatively simple scenario. We have low adoption due to duplicate accounts and contacts in the system. Before they approached our project team, data stewards from the planning team tried multiple times to clean the data manually. But within a few months, data quality suffered again. Business users want these recurring dupe issues to be fixed as soon as possible as users may stop using the system.
After analyzing and researching internally and externally, we can identify the right product for our business. This not only enables us to capture good quality data but also enriches the data records by synchronizing the right data at a specific set frequency. This saves a lot of time, and our business can have accurate, complete, and meaningful data. We used a popular tool that is completely integrated with Salesforce. As Business Analysts, we need to be open-minded, understand business needs, and find the right solutions. In this case, rather than developing the Salesforce platform in-house, we found external tools to get the job done with minimal resources. The tool we used was an AppExchange product called D&B Hoover. This has a paid subscription managed package that is seamlessly integrated with Salesforce. Once synced up, the tool updates more than 100 account and contact attributes and adds a D&B identifier:
Figure 1.5 – D&B tool integrated with Salesforce on the Account Management page’s layout
Since this tool is embedded seamlessly into Salesforce Account and Contact Pages, users can access this tool without the need for a separate login. In addition to customer and contact data, sales teams will be able to get innovative analytical features:
Figure 1.6 – Example where users can search for companies and sync them to Salesforce with one click
This example helps us to see that business needs are not always obvious. In this case, the business user did not even state their needs. By analyzing the root cause of low adoption, we interacted with many key stakeholders and SMEs to understand the needs. Then, we explored internal and external tools and found the one that best fits our needs. Sometimes, the end goal will help us with eliciting and drawing forth a business need that can have a positive impact on our business users.
Now, let’s look at some practical tips that I found useful.
I would like to outline a few pointers that you can use when you do business analysis tasks. These are relatively simple tasks that helped me tremendously. The simplest and easy-to-do items are always overlooked. You can avoid common causes of missing out on understanding business needs by taking note of the following pointers:
With this, we have completed this chapter on how to identify sources of requirements.
In this chapter, you learned where to find the sources of business user needs. By doing so, you learned how to get the requirements at a very high level and the key sources where you can plan to elaborate by eliciting more granular details. You also understood the key terms and ways to prepare yourself for the next stage of the requirement elicitations activity by utilizing the skills you learned in this chapter.
In the next chapter, we will discuss various ways to draw out user business needs and wants from various sources that we’ve identified so far. We will cover different techniques and extract information to accurately understand users’ requirements.
3.16.125.26