Detailed Business Analyst’s Job Description

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 ‘Business Analyst’ is not very self-evident. Many times, people are left wondering what’s a Business Analyst’s job description?

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”.

Business Analyst Job Description

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:

  1. Why do you even need a phone?
  2. Why do you wish to buy a new phone? Can you settle for a used/second-hand phone?
  3. How much money are you willing to spend on the new phone?
  4. How soon you wish to buy the phone?
  5. What are the primary activities you perform on a mobile phone? (calling, texting, surfing internet, social media, games, video playback)
  6. What additional features you would like to have on the new phone? (wireless charging, NFC, HD video recording, QHD screen)
  7. Is there a brand or platform preference (iOS or Android / Apple or Samsung )
  8. 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 and every stakeholder.
  • Develop scope
    The project scope is a collection of all what is required to do to achieve the business objective. A business analyst should assist in the development the project scope, resolve ambiguity and define the boundaries of the project.
    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
  1. Business Requirements Document (BRD) to document high-level requirements
  2. Functional requirement specifications (FRS), Use cases and user stories to capture granular requirements
  3. Functionality Matrix (FM) to list down all the functionalities
  4. Requirement Traceability Matrix (RTM) to track all the requirements

Vertical 2 – Technical

The technical vertical deals with all the activities around the implementation of solution 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 come up with appropriate solutions.
  • Participate in Technical analysis
    Apart from the business perspective, a business analyst should analyze the requirements from the technical view-point 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. All this might involve capturing data, creating metrics, evaluating dependencies and developing options.
  • Develop Data models and process flows
    It is required from a business analyst that he should analyze and create graphical representations of the flow of data 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
    For evaluation and demonstration, a business analyst is required to create the wireframe or mock-up of the product to be developed. 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 following documents or assisting their creation:
  1. Context diagrams – used to show a high-level view of a system and the entities interacting with it.
  2. Class diagrams – a type of static structure diagram that describes the structure of a system.
  3. 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, taking business decisions, 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:
  1. helping everybody understand the project vision
  2. clarifying doubts and questions
  3. resolving any ambiguity around the requirements and attaining clear consensus
  4. keeping everybody in the loop about any changes and amendments
  • Develop plans
    Owing to his exceptional understanding about the project goals, a BA should help the Project Manager develop requirement management plans, scope management plans, quality plans and other important artifacts of the project to ensure they are in line with the business objectives.
  • Manage requirements
    Since a business analysts authors a lot of documents (and requirements!) throughout the project course, it’s their integral job to manage the complete set of project’s requirements artifacts. This involves gaining relevant approvals against the requirements (to avoid future confusions), maintaining latest details within the respective documents and properly storing them in a document repository.
  • Assist testing efforts
    Analysts are expected to ensure that the developed product works exactly as defined in the solution and thus they test the implemented functionality according to the product’s boundaries and also monitor the project’s quality control activities.
  • Support change management
    Changes are unavoidable in the constantly developing ‘agile’ environments and business analysts should be able to manage these changes. 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 project’s ‘change log’ document.

Vertical 4 – Financial

This vertical deals with activities, discussions and decisions around the finances, budget and monetary resources of any project. Analysts (although not very frequently) are expected to help with:

  • Estimation activities
    Business analysts are sometimes required to assist in the estimation of the project’s cost and time. Thus, they should have a sound understanding and implementation knowledge of various estimation techniques like 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 strength and weakness through Cost/benefit analysis. They should, with their domain knowledge, 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.

Business Analyst Documents

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 the various releases in a project, and it’s a vital document to track project scope, requirements, and changes in any project.

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 the intended behavior of a system, including data, operations, input, output, and the properties of the system.

In a BRD, the requirements are high-level, but in an FRS/FSD, they are written in much more detail to capture each and every 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 the business stakeholders of a project.

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 enumerates 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 has 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 has to undergo 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

Comments are closed.