Business Analysis Knowledge Areas Explained as per BABoK

The Rise of the Business Analysis Profession and the Emergence of Global Standards

he past decade saw an explosion in demand for Business Analysts, where data-focused companies were still relatively new, analytics were not as commonly used and technology were not advancing at such an exponential rate as it currently is.  Since then, however, there is a need to incorporate data-driven decisions based on human-centred designs.  According to a recent TechCrunch survey, online retail giant Amazon had specifically highlighted business analysis skills as one of its fastest-growing skill demands over the past five years. Based on its own data, Business Analyst vacancies had increased by 160 percent over this time period. As private companies had begun to invest more in business analysis, it became imperative that the global blueprint for this profession is established, whilst providing room for further development in this highly flexible profession.

The International Institute of Business Analysis (IIBA®) had been established to fill this gap by setting global standards, regulations and best practices.  The Business Analysis Body of Knowledge (BABoK) is IIBA’s core publishing that elaborates on key concepts, knowledge areas and techniques which is now in its third edition and is widely used by thousands of professionals globally.  In this article, we will exploring the core knowledge areas and linking these core knowledge areas to the practicalities of the business analysis profession.

BABoK Knowledge Areas Explained

Knowledge areas in the BABoK  highlights elements of specific analysis expertise that encompass several tasks.  The six knowledge areas are:

1.Business Analysis Planning and Monitoring

When starting a project or initiative, a Business Analyst will need an overarching framework on how they will be approaching their objective. This knowledge area highlights the tasks that Business Analysts perform to organise and coordinate the efforts of Business Analysts and their stakeholders. The tasks explained in this knowledge area aims to produce outputs that are used as key inputs, guidelines and tools for the other tasks throughout the BABoK guide. These key tasks are:

Plan Business Analysis Approach

 Business analysis work needs to be planned at the start of each new project, which involves the consideration of methodology (e.g. waterfall, agile, scaled agile etc.), planning individual activities, tasks and deliverables which will be articulated in the overall approach documentation to ensure that the business analysis team are performing such tasks in a consistent manner.

Plan Stakeholder Engagement

Each project will have a unique set of individuals with vested interests.  One needs to understand which stakeholders are relevant to the change, what Business Analysts will need from them, what they need from Business Analysts and the best way to collaborate.  For example, in a virtual project stakeholders based in different locations, it would be worth considering the most appropriate tools to gain qualitative and quantitative information from them as well as online collaboration tools.

Plan Business Analysis Governance

Establishing decision makers and approval frameworks are imperative in any project. This task is focused at a business analysis level and it defines the components of business analysis that are used to support the governance function of the organisation, and follows a process that ensures decision makers have the information that they need. Examples include the approval process for requirements management, business analysis risk management, and allocation of business analysis resources.

Plan Business Analysis Information Management

Business Analysts will, no doubt, accumulate a large volume of information throughout the lifespan of a project. This task defines how information developed by Business Analysts (which includes requirements and designs) are captured, stored and integrated with others for long-term use.  For example, defining how a business function decomposition artefact created by a Business Analyst is stored, updated, approved and integrated to the business after a project.

Identify Business Analysis Performance Improvements

Business analysis work will need to be monitored and assessed throughout a project. This task covers managing and monitoring the ‘how’ of  business analysis work, ensuring that commitments are being met and continuous learning and improvement opportunities are realised. For example, establishing key metrics that would help to maintain high standards and also uncovering any developmental areas that needs to be improved so that the Business Analyst(s) could carry out a task to the standards set by the team lead. 

2.Elicitation and Collaboration

Perhaps the more well known of business analysis skillsets, the Elicitation and Collaboration knowledge area of the BABoK describes the tasks that Business Analysts perform to prepare for and conduct elicitation activities and confirm the results obtained. Most change professionals will relate ‘elicitation’ and ‘collaboration’ back to the use of workshops or interviews with relevant stakeholders, where Business Analysts will typically be the facilitators who will also communicate the key findings of the elicitation exercise.  This knowledge area also covers the communication with relevant stakeholders when the business analysis information is collated, in addition to the ongoing collaboration with them throughout future business analysis activities.  Elicitation and collaboration can be planned and/or unplanned.  For example, informal conversations can also happen alongside other planned activities.  This knowledge area covers five main tasks:

Prepare for Elicitation

For Business Analysts, elicitation involves ensuring that their stakeholders have sufficient information for them to understand what is asked of them and that they understand the nature activities that will be performed during the elicitation activity.  It also sets out a shared set of expectations regarding the outcomes of the activity, which will also need to be shared with the stakeholders. Preparation may also involve planning the logistics of getting a stakeholder from their base location to where the elicitation exercise will be taking place or identifying research sources.

Conduct Elicitation

The elicitation activity aims to understand stakeholder needs and start to discover potential solutions that may fulfil these needs. This could involve direct interaction with stakeholders, researching or by running experiments.  A vast range of techniques can be used for this task, from workshops to collaborative games, depending on the context.

Confirm Elicitation Results

When the initial business analysis information had been collated from the elicitation exercise, a Business Analyst will take measures to ensure that stakeholders have a shared understanding of outcomes of elicitation, that elicited information had been recorded accurately and appropriately, and that the objectives of the elicitation exercise had been met. This task also involves comparing the information received with other supporting information to look for inconsistencies or gaps, for example a Business Analyst may wish to discuss their findings with another Business Analyst in their team as a form of peer review, and for reassurance that the findings are aligned with similar work that their colleagues may be performing.

Communicate Business Analysis Information

When the elicitation results are confirmed, it can be shared with their stakeholders. This task aims to provide stakeholders with the information they need, at the time they need it. The information is presented in a useful format, using their agreed shared terminology and concepts.  For example, the senior stakeholders may gain the most value from presentations packs, where findings are condensed to high-level bullet points, with key messages clearly elaborated upon and statistics clearly illustrated in visual diagrams.

Manage Stakeholder Collaboration

Elicitation and collaboration is an iterative process. This task is included in the knowledge area to cover the need for a Business Analyst to continue working with stakeholders to engage them in the overall business analysis process, maintain relationships and to ensure that the Business Analyst can deliver the outcomes needed.

3. Requirements Life Cycle Management

From inception to retirement, there are a specific tasks Business Analysts perform in order to manage and maintain requirements and design information.  This knowledge area describes these tasks, in addition to emphasising how these task describe meaningful relationships between related requirements and designs, and assessing, analysing and gaining consensus on proposed changes to requirements and designs.  This knowledge area comprises of the following tasks:

Trace Requirements

Requirements traceability involves analysing and maintaining the relationships between requirements, designs, solution components and other work products for impact analysis, coverage and allocation.  Requirements can be traced forwards and backwards.  Forward traceability is the ability to trace a requirement to a design’s component or implementation, whereas backward traceability traces requirements back to its source e.g. defects, legal requirement, amongst others.  Up to date requirements traceability documents are seen as significant artefacts for project customers, sponsors, the Project Management Office as well as Project Assurance teams.

Maintain Requirements

Requirements will need to be maintained in a requirements register to ensure that requirements and designs are accurate and current throughout the project life cycle as well as facilitating reuse where appropriate.  Requirements that had been drafted can be reused to help save time and effort, but if tasks are not fully maintained, there is risk that one could be blindly requirements back to outdated requirements, or those with dependencies that can no longer be matched.  

Prioritise Requirements

It is likely that a requirements register will contain more requirement items than is possible to implement in one deployment window.  By prioritising requirements, Business Analysts can assess the urgency, risk associated with and value of particular requirements  to ensure that analysis and/or delivery work can be done on the most important items at any given time. 

Assess Requirements Changes

Changes to requirements over time is almost inevitable in most settings, therefore Business Analysts will need to evaluate new and changing stakeholder requirements to determine if they need to be acted on within the scope of change.  For example, if the revised stakeholder requirement no longer fits into the scope of the project, depending on scale of the change the project sponsor may need to be consulted.

Approve Requirements

Within this knowledge area, one of Business Analysts’ objectives is to support stakeholders involved in the governance process to reach approval and agreement on requirements and designs. This may mean that, on occasions, they may need to provide clarity on the relevant requirement so that these are clearly understood. 

4.Strategy Analysis

Having a strategy assures that there is a most effective way to apply enterprise capabilities to reach a desired set of goals and objectives. This knowledge area focuses on strategy analysis, which describes the business analysis work performed to collaborate with stakeholders that identifies strategic need of tactical importance, which will then enable the enterprise to address the need as well as aligning the resulting strategy for the change with higher and more granular strategies.  Many will associate this knowledge area with another business analysis skillset, namely the gap analysis. The key tasks within this knowledge area are as follows:

Analyse Current State

Also known as the ‘as is’, this task aims to understand the business need and how it relates to the way the enterprise currently functions. By analysing and understanding the ‘as is’, Business Analysts are able to set a baseline and context for change.

Define Future State

Also known as the ‘to be’, this task aims to define goals and objectives that will demonstrate that the business need has been satisfied and defines what parts of the enterprise will need to change in order to meet these goals and objectives. In reality, the ‘to be’ business process artefacts are unlikely to exist by itself, nor is derived from one-off activities.  Rather, it is one of the by-products of a wider change initiative.

Assess Risks

A Business Analyst will need to understands the uncertainties around a given change, consider the effect those uncertainties may have on the ability to deliver value through a change before recommending actions to address risks where appropriate.  These risks can be captured in a risk register, which is also typically owned by the Project Manager.

Define Change Strategy

Once a Business Analyst had defined the ‘as is’ and ‘to be’, they can then perform a gap analysis between current and future state, be in a position to assess options for achieving future state as well as recommending the approach providing the best value in the future state, including transition states that may be required along the way.

5. Requirements Analysis and Design Definition

To help Business Analysts create representations of elicitation results and how these relate to the solution, they will need to structure and organise requirements discovered during elicitation activities, specify and model requirements and designs, validate and verify collated information, identify solution options that meet business needs and estimate the potential value that could be realised for each solution option.  This knowledge area covers the incremental as well as iterative business analysis activities which ranges from the initial concept and exploration of the need through the transformation of requirements into a particular recommended solution.  Tasks under this knowledge area include:

Specify and Model Requirements

By analysing elicitation results, requirements can be refined into requirements and designs. This task describes a set of requirements or designs in detail using analytical techniques such as data modelling, user stories, use cases and scenarios, among others. The Business Analyst will need to have an understanding of both the information collated and a range of techniques to decide which technique is the best fit for the given context.  

Verify Requirements

To ensure that a set of requirements are usable by a particular stakeholder, a Business Analyst ensures that a set of requirements or designs has been developed in sufficient detail, is internally consistent and of high quality.  Requirements may be peer reviewed, or its quality assessed against a specific set of criteria set by the business analysis team.

Validate Requirements

Requirements will need to be validated by the a list of defined stakeholders to ensure that a set of requirements or designs delivers business value and supports the organisation’s goals and objectives.

Define Requirements Architecture

In order to assure that a set of requirements form part of a cohesive whole, defined structures all requirements and designs are needed so that they support the overall business purpose for a change and meets the organisational objectives.

Define Solution Options

When the set of requirements are verified, validated and its architecture defined, a Business Analyst identifies, explores and describes different possible ways of meeting the need. A range of options will be listed which will be communicated to the relevant stakeholders.

Analyse Potential Value and Recommend Solution

Among the list of options provided by the Business Analyst, further work will be performed to assess the business value associated with a potential solution and compares these different options, including trade-offs, to identify and recommend the solution option to the relevant stakeholder that delivers the greatest overall value.

6. Solution Evaluation

The Solution Evaluation knowledge area focuses on the tasks that Business Analysts perform to assess the performance of and value delivered by a solution selected by the enterprise, and to recommend any removal of barriers or constraints that prevent the full realisation of the value.  Solution evaluation tasks that support the realisation of benefits may occur before a change is initiated, while current value is assessed or after a solution has been implemented.  These tasks include:

Measure Solution Performance

By understanding how the solution operates, a Business Analyst is in an ideal position to determine the most appropriate way to assess the performance of a solution, including how it aligns with enterprise goals and objectives, and performing this assessment.  This could be measured in metrics, or in other qualitative benchmarks against similar solutions or business expectations.

Analyse Performance Measures

Once the solution’s performance measures are determined, a Business Analyst examines information regarding the performance of a solution in order to understand the value the solution delivers to the enterprise and determines whether it is meeting current needs. This is likely to be compiled by the Business Analyst into a report format, which is then discussed with the business.

Assess Solution Limitations

What is it about the solution that is preventing it from performing at its peak?  This is the key question asked by the Business Analyst at this stage, where they investigate issues within the scope of a solution that may prevent it from meeting current business needs.

Assess Enterprise Limitations

What is it about the business/enterprise that is preventing it from performing optimally after implementing the solution?  This is the key question asked by Business Analysts at this stage, and they investigate issues outside the scope of a solution that may be preventing the enterprise from realising the full value that a solution can provide.

Recommend Actions to Increase Solution Value

When the Business Analyst had performed the relevant analysis and assessments, they will be in a prime position to identify and define actions the business can take to increase the value that can be delivered by a solution.

A general relationship of the knowledge areas can be summarised as below.  It is important to note that the starting point for a Business Analyst entering a new project may not be fixed at one knowledge area. By appreciating the malleability between these core knowledge areas, Business Analysts can turn to various knowledge areas to locate information which may support the activities in which they are involved in.

Outlook of Business Analysis Knowledge Areas

The BABoK knowledge areas spans across the wide spectrum of business analysis work, and this spectrum is likely to get wider over time.  Whilst the general business analysis framework is widely accepted and practiced by professionals globally, it is also important for individuals to be continuously aware of emerging industry skills requirements in this highly varied profession.  The emergence of data analytics, cybersecurity initiatives and automation all lead to the organisations requiring skillsets that might previously been considered ‘specialist’ business analysis knowledge.  It is therefore highly recommended that the core skills contained within the knowledge areas are supplemented with these emerging skill demands to become the best Business Analysts that you can be.