Anybody who is even remotely associated with the field of Information Technology (IT) is sure to have heard the term ‘Business Analysis’ or ‘Business Analyst’. However, unlike the role of a ‘Project Manager’ or ‘Software Developer’, the set of job responsibilities around the role of ‘Business Analyst’ is not very self-evident. People are often left wondering what a Business Analyst’s job description is.
In this article, we are going to demystify the business analysis practice and know who is a Business Analyst, why organizations need one, learn about the job description of a Business Analyst along with the different areas they for.
Definition of Business Analyst
The formal definition of a Business Analyst according to IIBA is “any person who performs business analysis activities, no matter what their job title or organizational role may be” (yes, that simple!).
Also, IIBA defines Business Analysis as “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders”.
I would rather simplify the above definition by re-phrasing Business Analysis as “helping companies resolve their functional/technical challenges by first understanding their problems, clearly defining them and then solving them”.
Since stakeholders belong to different domains (e.g. finance, business, marketing) it’s very important for a business analyst to be able to sort and balance the needs of these stakeholders while fulfilling the business objectives at the same time.
Understanding Business Analyst role (with an example)
To understand the above definition better, I want you to do a bit of a role-play and consider that your existing phone is not working properly and you wish to buy a new mobile phone. However, there are plenty of decent mobiles available in the market and you resort to taking help from your friend, Robin. Below are the questions that are asked by Robin:
- Why do you even need a phone?
- Why do you wish to buy a new phone? Can you settle for a used/second-hand phone?
- How much money are you willing to spend on the new phone?
- How soon you wish to buy the phone?
- What are the primary activities you perform on a mobile phone? (calling, texting, surfing internet, social media, games, video playback)
- What additional features you would like to have on the new phone? (wireless charging, NFC, HD video recording, QHD screen)
- Is there a brand or platform preference (iOS or Android / Apple or Samsung )
- What’s the phone size you are comfortable with?
Based on your answers to the above questions, Robin recommends 4-5 different mobile phone models and you happily choose one amongst them.
You might be wondering where is the Business Analyst here? Well, your friend Robin is the Business Analyst. Let’s see how by taking a look at IIBA’s Business Analysis definition again:
“the practice of enabling change (Robin made it possible for you to change you existing phone to the new one) in an organizational context (you were the organization here who wished to undergo a migration from an old to a new phone), by defining needs (Robin helped define what kind of phone you actually needed by asking a series or relevant and pragmatic questions) and recommending solutions (based on your answer to his questions, Robin suggested a couple of mobile options) that deliver value to stakeholders (you were able to buy a phone that fulfills all you expectations and is well within your budget)”.
Why organizations need a business analyst?
So, we now understand who’s a Business Analyst and with that, we transition to our next question – Why do we need one?
For the sake of better comprehension, let’s take the previous example and make it complex by adding an additional set of conditions – Along with you, now there are 3 of your friends who wish to buy a phone, with the condition that the phone model for all should be same!
This makes the work a lot more difficult for Robin as now he has to – collect individual (phone) feature expectations from all 4 persons, discuss and reach a consensus when the requirements of 2 persons does not match, document each of the expectations so that there is no confusion, assess mobiles ensuring that all expectations of all the people are fulfilled and finally recommend one!
Similarly, when new Information Technology products and softwares are created, a dedicated and skilled professional is required to carry out the activities like –
- gathering/eliciting the features and functionalities of the product/software being built
- assessing and analyzing whether those features are actually needed
- drawing out a consensus amongst stakeholders with diverse expectations from the product
- proposing solutions (and alternatives) to business problems
- documenting product requirements in detail
- constantly coordinating with the various team to ensure everybody shares a common vision
All the above activities (and a lot more) comes under the responsibility set of a business analyst.
Business Analyst Job Description
From our discussion till now, it’s clearly evident that a business analyst acts as a bridge, a connector and helps the complete project teamwork as a tightly integrated unit. The unique job of analysts requires them to wears different hats and fulfill various duties under different areas of the project (as well as an organization).
For a better understanding, I have divided the business analyst’s core job description amongst the different verticals in which they are expected to work in. These are broadly classified as:
- Business
- Technical
- Managerial
- Financial
- Additional areas of expertise
Each one of these verticals is comprehensively elaborated below.
Vertical 1 – Business
Business can be defined as the “section of any organization that focuses on making decisions about the products and deliverables that helps the organization attain its mission”. While working together with the business folks and assisting them, the analyst fulfills the following activities:
- Understand the business case
A ‘business case’ for any project is the reason ‘Why’ (i.e. the reason/problem statement) the project was undertaken. A business analyst should comprehend a project’s business case thoroughly and understand all aspects of it. This involves reading existing documentation regarding the project’s domain, gathering information and talking to different stakeholders.
- Fulfill the business objective
Every project has a unique business objective i.e. ‘What’ the project is expected to accomplish. A business analyst should understand this objective, validate all the requirement of the project with this objective in mind and ensure that the final project solution is able to fulfill this objective.
- Elicit Requirements
One of the integral activity for any analyst, ‘elicit’ means to obtain and extract requirements from all the stakeholders. The requirement gathering process requires a business analyst to be apt with required skills like facilitation, brainstorming, interviewing and observation.
- Analyze requirements
In an effort to recommend a solution to any existing problem/goal, an analyst must examine the current state of a process, learn about its operations, and accordingly analyze the requirements of each stakeholder.
- Develop scope
The project scope is a collection of all that is required to achieve the business objective. A business analyst should assist in developing the project scope, resolve ambiguity, and define the project’s boundaries.
Since stakeholders belong to different domains (e.g. finance, business, marketing) it’s very important for a BA to be able to sort and balance the needs of these stakeholders while fulfilling the business objectives at the same time.
- Business Documentation
Another imperative activity for an analyst is ‘documentation,’ which expects them to structurally and methodically document the project’s requirements by creating.
- Business Requirements Document (BRD) to document high-level requirements
- Functional requirement specifications (FRS), Use cases, and user stories to capture granular requirements
- Functionality Matrix (FM) to list down all the functionalities
- Requirement Traceability Matrix (RTM) to track all the requirements
Vertical 2 – Technical
The technical vertical deals with all the activities around the implementation of solutions using technology/tools/models/techniques. Here, an analyst is expected to:
- Exhibit analytical skills
A business analyst should demonstrate problem-solving, qualitative, quantitative, and visualization skills to resolve business/technical problems and apply logical thinking to devise appropriate solutions.
- Participate in Technical Analysis
Apart from the business perspective, a business analyst should analyze the requirements from the technical viewpoint also (by getting involved in discussions with the tech architects, tech leads and developers) and uncover any technical challenges that might come in fulfilling the requirements. This might involve capturing data, creating metrics, evaluating dependencies and developing options.
- Develop Data models and process flows
A business analyst is required to analyze and create graphical representations of the data flow through the system, modeling its process aspects. The document generated from this exercise is called the data flow diagram (DFD).
- Create wireframes or mock-up interfaces
A business analyst is required to create the wireframe or mock-up of the product to be developed for evaluation and demonstration. This wireframe is a high-level model of the product and assists in the user interface (UI) and user experience (UX) study of the product’s design.
- Technical documentation
A business analyst is required to provide technical support throughout the project lifecycle by either developing the following documents or assisting with their creation:
- Context diagrams – used to show a high-level view of a system and the entities interacting with it.
- Class diagrams – a type of static structure diagram that describes the structure of a system.
- Entity–relationship diagram (ERD) – a model for describing the data or information aspects of a business process.
Vertical 3 – Managerial
The managerial verticals involve being in charge of project tasks/activities, making business decisions, and guiding and leading resources.
- Facilitate implementation
A business analyst must constantly communicate with the management, business stakeholders, vendors, partners, technical team, development teams, and testing team to facilitate the implementation of the product functionality by:
- helping everybody understand the project vision
- clarifying doubts and questions
- resolving any ambiguity around the requirements and attaining a clear consensus
- keeping everybody in the loop about any changes and amendments
- Develop plans
Owing to his exceptional understanding of the project goals, a BA should help the Project Manager develop requirement management plans, scope management plans, quality plans, and other important project artifacts to ensure they align with the business objectives.
- Manage requirements
Since business analysts author many documents (and requirements!) throughout the project, it’s their integral job to manage the complete set of project requirements artifacts. This involves gaining relevant approvals against the requirements (to avoid future confusion), maintaining the latest details within the respective documents, and properly storing them in a document repository.
- Assist testing efforts
Analysts are expected to ensure the developed product works exactly as defined in the solution. Thus, they test the implemented functionality according to the product’s boundaries and monitor the project’s quality control activities. - Support change management
Changes are unavoidable in constantly developing ‘agile’ environments, and business analysts should be able to manage them. They should understand the rationale behind the change, assess its viability against the existing business case, analyze dependencies and impact, assist in prioritizing the implementation of changes, and lastly, document all the discussions around the change in the project’s ‘change log’ document.
Vertical 4 – Financial
This vertical deals with activities, discussions, and decisions around any project’s finances, budget, and monetary resources. Analysts (although not very frequently) are expected to help with:
- Estimation activities
Business analysts are sometimes required to assist in estimating the project’s cost and time. Thus, they should have a sound understanding and implementation knowledge of various estimation techniques, such as function point (FP) estimation, critical path analysis, earned value (EV) techniques, etc. - Cost/benefit analysis
Analysts should be able to assess the viability of a business proposal by estimating its strengths and weaknesses through Cost/benefit analysis. With their domain knowledge, they should measure the positive or negative consequences of a proposal and present their findings through a detailed analysis report.
Additional areas of expertise
Apart from the four verticals discussed above, analysts also have some additional areas of expertise like:
- Domain and SDLC knowledge
The Analyst should have the basic working knowledge of their project’s domain (for e.g., banking, finance, insurance, etc.) along with a good grasp of software engineering concepts and project’s development life cycle (Waterfall, Rapid application development, Agile).
- Leadership skills
Along with excelling in the core analysis activities, BAs should exhibit leadership capabilities like being proactive with the tasks and respecting deadlines, enthusiastic about new concepts and solutions, respecting responsibilities and strong work ethics. - Communication skills
Excellent client facing skills, presentation skills and the ability to communicate (verbal and written) clearly are major contributors towards being a successful business analyst.
Business analysts are the Key resource for any project and are credited with developing the project’s solutions while respecting and acknowledging the needs of all the associated stakeholders. It’s a career choice that utilizes a professional’s skills to the fullest by helping companies attain their business goals and ensures very high visibility (within projects and organization) along with constant recognition of work.
Documentation is one of the integral job functions of business analysts, and they, throughout the course of a project, prepare many documents. These documents are created to fulfill the varied project needs and cater to audiences belonging to different spheres of a project.
PSST… Don’t forget to download your FREE Business Analyst Documents Template Toolkit at the end of this article !!
The type and specifications a business analyst is expected to create in an organization depend upon many parameters, like the organization’s processes and policies, the needs and expectations of the business, and the stakeholder requirements.
Detailed below are the typical documents a business analyst is expected to create, and they are extensively used throughout the course of a project. Each of these documents has a specific template, and it’s part of the overall project documentation.
Here are the key documents prepared by Business Analyst (BA):
- Project Vision Document
- Requirement Management Plan
- User Stories
- Use Cases
- Business Requirement Document
- Requirement Traceability Matrix (RTM)
- Functional Requirement Specification (FRS)/ Functional Specification Document (FSD)
- System Requirement Specification (SRS)/ System Requirement Document (SRD)
- Test Case
Let’s discuss each of these documents in detail.
1. Project Vision Document
Although mainly the client/project manager creates a project vision document, business analysts are also expected to contribute to this document. A Project vision document entails the purpose and intent of the product/software to be developed and describes the ‘what’ business objective will be achieved on a high level.
The Project vision document contains the following sections:
– Introduction
– Description of users in the system
– Project stakeholders
– Product Overview
– Product Features
– Product requirements
– Constraints/Limitations
– Quality/documentation requirements
2. Requirement Management Plan
The Requirements Management plan is used to document the necessary information required to manage project requirements from project initiation to delivery effectively.
The Requirements Management Plan is created during the Planning Phase of the project. Its intended audience is the project manager, project team, project sponsor, and any senior leaders whose support is needed to carry out the plan.
The Requirement Management Plan contains the following sections:
– Purpose of the plan
– Responsibility assignment
– Tools and procedures to be used
– Approach to defining requirements
– Approach toward Requirements Traceability
– Workflows and Activities
– Change Management
3. Use cases
Each project is an endeavor to achieve ‘requirements,’ and the document that defines these requirements is a use case. A use case is a methodology used in system analysis to identify, define, and organize system requirements.
A use case is created from the perspective of a user and achieves the following objectives:
1. Organizes the functional requirements,
2. Iterative in nature and updated throughout the project life-cycle
3. Records scenarios in which a user will interact with the system
4. Defines other aspects like negative flows, UI elements, exceptions, etc.
The Use Case document contains the following:
– Actors
– Description
– Trigger
– Preconditions
– Normal Flow
– Alternative Flows
– Exceptions
– Special Requirements
– Assumptions
– Notes and Issues
Also View: 60+ Business Analyst Interview Question and Answers – Download PDF
4. User stories
In an agile development environment, a user story describes the functionality a business system should provide. It is written from the perspective of an end-user/customer/client.
The user stories are not very descriptive and only capture the ‘who’, ‘what’, and ‘why’ of a requirement in limited detail. If any requirement is too big for a single-user story, it’s broken down into several user stories making it easier for estimation and discussion. In such cases, the primary user story will be an Epic (parent) user story.
Some examples of user stories are:
– The system shall be able to sort the values in ascending and descending order
– The application must allow the user to enter his name, date of birth, and address.
– The system shall verify the user’s login credentials and redirect him to the dashboard in case of a successful login.
5. Business Requirement Document
A Business Requirement Document is created to describe the business requirements of a product/process and the intended end result expected from the product/process. It is one of the most widely accepted project requirement documents and is referred to throughout the development life cycle for any project.
A BRD mainly focuses on answering ‘what is the business solution’ as opposed to ‘how to achieve the business solution,’ and thus, it’s primarily centered around the business requirements.
A BRD is created with the help of the project team (BA, client, subject matter experts, and business partners). It is also a communication tool for other stakeholders/external service providers.
The Business Requirement Document contains the following sections:
– Project Background
– Business goals and objectives
– Stakeholders
– Requirement scope
– Functional requirements
– Data requirements
– Non-functional requirements
– Interface requirements
– Business glossary/Definitions
– Dependencies of existing systems
– Assumptions
6. Requirement traceability matrix (RTM)
A Requirement traceability matrix is used to record and track the relationship of the project requirements to the design, documentation, development, testing, and release of the project/product. This is done by maintaining an Excel sheet that lists the complete user and system requirements for the system (in the form of use cases), which are mapped to the respective documents like Functional Requirement #, Design Document, Software Module, Test Case Number, etc.
An RTM is maintained throughout the lifecycle of a project’s various releases. It’s a vital document for tracking project scope, requirements, and changes.
The Business Requirement Document contains the following:
– Requirement ID
– Requirement Description
– Functional Requirement
– Status
– Architectural/Design Document
– Technical Specification
– Software Module
– Test Case Number
– Tested In
7. Functional requirement specification (FRS)/ Functional Specification Document (FSD)
A Functional requirement specification or Functional Specification Document describes a system’s intended behavior, including data, operations, input, output, and properties.
In a BRD, the requirements are high-level, but in an FRS/FSD, they are written in much more detail to capture each aspect of a requirement. Thus, a functional specification document becomes a more technical, accurate, and descriptive requirement document.
Owing to their technical nature, FRS/FSD are equally used by developers, testers, and project business stakeholders.
The Functional requirement specification (FRS)/Functional Specification Document (FSD) contains the following:
– Product Context
– Assumptions
– Constraints
– Dependencies
– Functional Requirements
– User Interface Requirements
– Usability
– Performance
– Manageability/Maintainability
– System Interface/Integration
– Security
– Requirements Confirmation/sign-off
8. System requirement specification (SRS)/ System Requirement Document (SRD)
A detailed document containing information about ‘how’ the complete system has to function and enumerating the hardware, software, functional, and behavioral requirements of the system.
SRS/BRD elaborates on the requirements from the perspective of observational behavior only and doesn’t consider technical or design bias.
The System requirement specification (SRS)/ System Requirement Document (SRD) contains the following:
– Product Perspective
– Product Functions
– User Characteristics
– General Constraints
– Assumptions and Dependencies
– External Interface Requirements
– Functional Requirements
– Classes / Objects
– Non-Functional Requirements
– Inverse Requirements
– Design Constraints
– Sequence Diagrams
– Data Flow Diagrams (DFD)
– State-Transition Diagrams (STD)
– Change Management Process
9. Test case
Although Business analysts are not explicitly asked to create test cases, they must understand what they constitute and how to create one, as they sometimes have to test functionalities by referring to the test cases.
A test case is a document that contains a set of test data, preconditions, variables, and expected results created to verify and validate whether a particular piece of functionality is behaving as intended (or as documented in the requirement documentation). Thus, a test case becomes a standardized document that should be referred to every time a requirement undergoes testing.
The components of a test case are:
– Test Case ID
– Test Scenario
– Prerequisite
– Test Data
– Test Steps
– Expected Results
– Actual Result
– Status
– Remarks
– Test Environment
A business analyst creates all the above documents, which are part of the project/product documentation. These documents are constantly referred to throughout the project’s life cycle for communication, reference, and revision.
FREE KIT DOWNLOAD: Get BA Documents Template Toolkit!!
Our free Template Toolkit contains the following professional, pre-formatted, and ready-to-use Business Analyst Document templates:
- Use Case Document Template
- Requirement Traceability Matrix (RTM) Template
- Requirement Management Plan Template
- Project Vision Document Template
- Test Case Template