The role of business analysis in identifying requirement sources

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:

• Business analysis: Business analysis is a practice that involves understanding the current capabilities and needs of the business users, identifying gaps in the current processes, and enabling desired future capabilities to derive efficiencies, competitive advantage, and business benefits.
• Business Analyst: A Business Analyst is someone who practices business analysis while utilizing various tools, techniques, and resources. The goal is to help businesses move from their current state to a desired future state by understanding business needs, pain points, opportunities and gaps in processes, and providing robust, efficient, and effective solutions that are simple and usable.
• Customer Relationship Management (CRM): CRM is the practice of helping customers manage sales, service, and marketing processes effectively and efficiently so that they can grow their business and provide excellent customer service.
• Salesforce: Salesforce is a cloud-based CRM technology platform that helps organizations serve their customers with CRM functionality.

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:

• The system is already in use and business users would like to request enhancements. Here, you must add additional features to existing functionality. This can be your minor enhancement release or a production support item such as a defect or maintenance item.
• The system is already in use and business users would like new functionality. This can be a brand-new functionality and addressed via a project.
• You must add new capabilities to address usability and adoption issues. This can be a complex requirement where multiple stakeholders are involved.

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.

Types of requirements

There are four main types of requirements, as listed here:

• Business requirements: An example of this is if you are implementing a new system or functionality. These requirements are the most complex to understand, as there are too many unknowns. These requirements describe the high-level functionality that the business needs.
• Stakeholder requirements: Also called user requirements, these are features and functions that the users need and specify how they interact with the system. Getting to know the stakeholders’ needs and wants is critical because, often, they may not be able to articulate them clearly. This is very critical as stakeholder requirements are later translated into system requirements. Any flaws here get amplified at later stages and result in rework.
• System requirements: These requirements describe the characteristics of the solution. There are two types of system requirements:
  • Functional: Describes a specific set of capabilities
  • Non-functional: Describes the characteristics
• Transition requirements: These are transient requirements and are needed for a short period. Make sure that you discuss and get details around transition requirements. They are essential and critical to project success.

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.