background · web view2020. 1. 7. · business model canvas67. business rules analysis68....

Kevin – JUNE 2017 to JAN 2018 - ECBA Kevin – NOV 2019 to DEC 2019 – CBAP

BABOK Study NotesBased on BABOK Guide v3.

Table of ContentsBACKGROUND.......................................................................................................................................5

DEFINITIONS..........................................................................................................................................5

Business Analysis Core Concept Model.............................................................................................6

Key Terms..........................................................................................................................................7

Requirement Classification Schema...................................................................................................8

Stakeholder List Example...................................................................................................................9

Knowledge Areas Summary.............................................................................................................11

Knowledge Areas Overview.........................................................................................................11

Knowledge Areas Inputs & Outputs.............................................................................................13

AREA 1: Business Analysis Planning and Monitoring...........................................................................17

Core Concept Model........................................................................................................................17

3.1 Plan Business Analysis Approach...............................................................................................18

3.2 Plan Stakeholder Engagement...................................................................................................19

3.3 Plan Business Analysis Governance...........................................................................................20

3.4 Plan Business Analysis Information Management.....................................................................21

3.5 Identify Business Analysis Performance Improvements............................................................22

AREA 2: Elicitation and Collaboration..................................................................................................23


Diagram...........................................................................................................................................24

4.1 Prepare for Elicitation................................................................................................................25

4.2 Conduct Elicitation.....................................................................................................................25

4.3 Confirm Elicitation Results.........................................................................................................26

4.4 Communicate Business Analysis Information............................................................................26

4.5 Manage Stakeholder Collaboration...........................................................................................27

AREA 3: Requirements Life Cycle Management..................................................................................28


Diagram...........................................................................................................................................29

1 | P a g e

5.1 Trace Requirements...................................................................................................................29

5.2 Maintain Requirements.............................................................................................................31

5.3 Prioritise Requirements.............................................................................................................31

5.4 Assess Requirement Changes....................................................................................................32

5.5 Approve Requirements..............................................................................................................32

AREA 4: Strategy Analysis....................................................................................................................34


6.1 Analyse Current State................................................................................................................35

6.2 Define Future State....................................................................................................................36

6.3 Assess Risks................................................................................................................................37

6.4 Define a Change Strategy...........................................................................................................38

AREA 5: Requirements Analysis & Design Definition (RADD)...............................................................40


7.1 Specify and Model Requirements..............................................................................................41

7.2 Verify Requirements..................................................................................................................42

7.3 Validate Requirements..............................................................................................................42

7.4 Define Requirements Architecture............................................................................................43

7.5 Define Design Options...............................................................................................................44

7.6 Analyse Potential Value and Recommend Solution...................................................................45

AREA 6: Solution Evaluation................................................................................................................47


8.1 Measure Solution Performance.................................................................................................48

8.2 Analyse Performance Measures................................................................................................48

8.3 Assess Solution Limitations........................................................................................................49

8.4 Measure Enterprise Limitations.................................................................................................50

8.5 Recommend Actions to Increase Solution Value.......................................................................50

UNDERLYING COMPETENCIES.............................................................................................................52

COMPETENCY 1: Analytical Thinking and Problem Solving..............................................................52

COMPETENCY 2: Behavioural Characteristics..................................................................................52

COMPETENCY 3: Business Knowledge.............................................................................................53

COMPETENCY 4: Communication Skills...........................................................................................53

COMPETENCY 5: Interaction Skills...................................................................................................53

COMPETENCY 6: Tools & Technology..............................................................................................54

TECHNIQUES........................................................................................................................................55

2 | P a g e

Acceptance and Evaluation Criteria.................................................................................................63

Backlog Management......................................................................................................................63

Balanced Scorecard.........................................................................................................................64

Benchmarking & Market Analysis....................................................................................................65

Brainstorming..................................................................................................................................65

Business Capability Analysis............................................................................................................65

Business Cases.................................................................................................................................66

Business Model Canvas....................................................................................................................67

Business Rules Analysis....................................................................................................................68

Collaborative Games........................................................................................................................68

Concept Modelling..........................................................................................................................69

Data Dictionary................................................................................................................................69

Data Flow Diagram..........................................................................................................................69

Level 0 – the Context Diagram.....................................................................................................69

Level 1…X Diagrams.....................................................................................................................70

Data Mining.....................................................................................................................................70

Data Modelling................................................................................................................................71

Decision Analysis.............................................................................................................................71

Decision Modelling..........................................................................................................................72

Document Analysis..........................................................................................................................73

Estimation........................................................................................................................................73

Financial Analysis.............................................................................................................................74

Focus Group.....................................................................................................................................75

Functional Decomposition...............................................................................................................75

Glossary...........................................................................................................................................75

Interface Analysis............................................................................................................................75

Interviews........................................................................................................................................76

Item Tracking...................................................................................................................................76

Lessons Learned..............................................................................................................................76

KPIs and Indicators..........................................................................................................................76

Mind Mapping.................................................................................................................................77

Non-Functional Requirements Analysis...........................................................................................77

Observation.....................................................................................................................................77

Organisational Modelling................................................................................................................78

3 | P a g e

Prioritisation....................................................................................................................................78

Process Analysis...............................................................................................................................78

Process Modelling...........................................................................................................................79

Prototyping......................................................................................................................................80

Reviews............................................................................................................................................80

Risk Analysis and Management.......................................................................................................81

Role & Permission Matrix................................................................................................................81

Root Cause Analysis.........................................................................................................................82

Scope Modelling..............................................................................................................................82

Sequence Diagrams.........................................................................................................................83

Stakeholder List, Map or Personas..................................................................................................83

State Modelling...............................................................................................................................83

Survey or Questionnaire..................................................................................................................84

SWOT Analysis.................................................................................................................................84

Use Cases & Scenarios.....................................................................................................................84

User Stories.....................................................................................................................................85

Vendor Assessment.........................................................................................................................85

Workshops.......................................................................................................................................85

PERSPECTIVES......................................................................................................................................87

PERSPECTIVE 1: Agile.......................................................................................................................87

PERSPECTIVE 2: Business Intelligence..............................................................................................88

PERSPECTIVE 3: Information Technology.........................................................................................88

PERSPECTIVE 4: Business Architecture............................................................................................88

PERSPECTIVE 5: Business Process Management..............................................................................88

GLOSSARY............................................................................................................................................90

Exam Information / Preparation..........................................................................................................93

4 | P a g e

BACKGROUNDBABOK stands for the Business Analysis Body of Knowledge and is managed by the IIBA, founded in Toronto, Canada in 2003 as an organisation that supports the business analysis community with best practice guidance and certification. This body of knowledge is published in a big orange book (currently at Version 3.0) called the guide.

IIBA’s main competitor – equivalent qualification is IREB – International Requirement Engineering Board. IIBA is more widely recognised however.

The guide is broken in to six “knowledge” areas: -

AREA 1 - Business Analysis Planning and Monitoring AREA 2 - Elicitation and Collaboration AREA 3 - Requirements Lifecycle Management AREA 4 - Strategy Analysis AREA 5 - Requirements Analysis and Design Definition (RADD) AREA 6 - Solution Evaluation

These six areas span the project lifecycle from inception to production and change management. The knowledge areas take inputs, process them through a set of sub-tasks, in to outputs – see .

In addition to these, BABOK speaks about the underlying competencies that a business analyst (BA) needs to possess, the different techniques that are available to conduct the work and examines the work of a BA from five different perspectives, representing the most common scenarios in which analysis work is performed.

DEFINITIONS“Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enabled an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.”

A business analyst is anyone that performs business analysis tasks towards this end – typically eliciting the needs of stakeholders and identifying the fundamental problems that these suggest. A business analyst brings their own core competencies to this work.

5 | P a g e

6 Knowledge Areas

Competencies Techniques Perspectives

https://www.ireb.org/en

https://www.iiba.org/

The guide defines the different types of tasks that a business analyst performs, and the guide has a consistent template for describing each task (purpose, description, inputs etc.) The guide also suggests a non-exhaustive list of techniques for executing tasks.

BABOK has the concept of perspectives, the point of view from which we’re practicing business analysis – are we being Agile, are we looking at Information Technology systems, are we looking at business process? etc. Our perspective sets the scope of what we study. Perspectives are not mutually exclusive, and any one piece of work might need to account for multiple perspectives.

Business Analysis Core Concept ModelBABOK provides a conceptual framework for business analysis work called the Business Analysis Core Concept Model (BACCM). It is structured around six core concepts which provide a common terminology and mechanism for approaching business analysis work. These terms work together and depend on one another.

CONCEPT DESCRIPTIONChange The act of transforming in response to a need to improve an

organisation. Change is deliberate and controlled through business analysis activity.

Need A problem or opportunity to be addressed. Needs can cause changes and changes can also give rise to new need.

Solution A specific way to satisfy a need in a given context. A solution satisfies a need or takes advantage of an opportunity.

Stakeholder A group or a person with a relationship to the need, the change or the solution. Stakeholders are often described in terms of their interest in, impact on and influence over a change.

Value The worth or importance or usefulness of something to a stakeholder in a given context. Value can be tangible (saved money) or intangible (enhances reputation) and it can go down as well as up.

Context The circumstances that influence, are influenced by and provide understanding of the change. A context is everything that is relevant in the environment of the change (beliefs, biases, competitors, culture, attitude, existing processes or infrastructure etc.)

Each of the areas of work that we describe later can be given a description for each of the BACCM concepts.

6 | P a g e

Key TermsBABOK defines the following key terms: -

Business Analysis – the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business can be applied to different initiatives within an enterprise: -

o Strategico Tacticalo Operational

Business Analysis Information – information of any kind used by the business analyst to analyse, transform and report.

Business Analyst – any person who performs the tasks described in the BABOK regardless of job title (consultant, data analyst, system analyst, enterprise analyst, product owner etc.) This individual needs to be both a generalist and a specialist in the ideal world.

Design - a usable representation of a solution – anything that allows us to judge how value might be realised if a solution is built.

Domain – an area undergoing analysis. Enterprise – one or more organisations and the solutions that they use to

pursue a shared set of common goals. The group of solutions is often referred to as the organisational capabilities.

Organisation – a group of people under the management of a single individual or board that work towards common goals and objectives. Organisations have clearly-defined boundaries and work on a continuous basis (as opposed to a time-limited project).

Plan – a proposal for doing or achieving something. Usually via a set of events with dependencies and resources needed.

Project – a temporary initiative with constraints on time, cost and scope. Requirement – a usable representation of a need. They concentrate on

what value will be realised if the requirement is fulfilled.

7 | P a g e

Risk – the effect of an uncertainty on the value of a change, a solution or an enterprise. Risks are always negative in BABOK. The response to a risk includes altering the likelihood of the risk occurring, mitigating the consequences, removing the source of the risk, avoiding the risk, sharing the risk or even increasing the likelihood.

Solution – a set of changes to the current state to enable an organisation to meet a business need, solve a problem or profit from an opportunity.

Remember that requirements are focussed on the needs and designs on the solution. Business analysis work covers both.

Requirement Classification SchemaBABOK defines a requirement as a usable representation of a need i.e. we have written down or otherwise captured an expressed need in a format that can be processed. BABOK proposes a requirement classification schema as follows: -

A business requirement is a higher-level statement of goals, objectives and desired outcomes which explain why a change is to be initiated. Usually written from the point of view of the enterprise and provides justification for a project to be launched.

A stakeholder requirement is the need of a particular person to achieve a business requirement, it drills down from high level statement of need to explain who needs it.

A solution requirement is the capabilities and qualities (attributes) of a solution that will meet a stakeholder’s need. It can be sub-divided into: -

o A functional requirement is the capabilities that a solution must have in terms of behaviour and information handled.

o A non-functional requirement describes the conditions under which the solution must remain effective or qualities that the solution must have.

A transition requirement is the specific needs to transition from one state to another as the change is executed. These are temporary requirements that are only in force during the change.

There will almost certainly be dependencies between requirements in this structure so some traceability from (for example) a functional requirement back to a stakeholder and business requirement should be possible.

We can think of requirements in the rough hierarchy therefore as shown on the left-hand side and as a cycle as shown in the lower diagram.

Note that the distinction between requirements (a usable representation of a need) and design (a usable representation of a solution) is not

8 | P a g e

always clear in an organisation. Requirements are about need and designs are about solutions, but a business analyst is often asked to do both.

A design can lead to new requirements and so the transition from one to the other and back again) can be subtle.

Change is brought about by execution of a project (a temporary endeavour to effect a change from an “as is” to a “to be” state of perceived higher value to the business). Projects should be based on a project charter which formally endorses the work and empowers the project manager.

Non-functional requirements can contain further categories such as capacity, speed, security, certification compliance, availability etc. class 1 is 90% availability, class 2 is 99% availability, class 3 is 99.9% availability, class 4 is 99.99% availability etc.

Stakeholder List ExampleBABOK lists some sample stakeholder types to get us thinking about the different roles with which we interact: -

Business Analyst Customer Domain Subject Matter Expert

(SME) End User Implementation SME

Operational Support Project Manager Regulator Sponsor Supplier Tester

End user is the individual actually using our solution, but the customer could be the final beneficiary. Think about the difference between the bank clerk using the bank software and the customer who walks in off the street for banking services.

9 | P a g e

10 | P a g e

11 | P a g e

Knowledge Areas Summary

Knowledge Areas OverviewThe BABOK knowledge areas with their tasks and inputs and outputs are summarised in the table below: -

Input Tasks OutputBusiness Analysis Planning & MonitoringThis work area is all about defining the appropriate method for conducting business analysis – who we will contact, and how, how we’ll store and manage requirements, what techniques to use and the deliverables that will be produced. It includes the metrics to be used to monitor the quality of the business analysis work itself.

Needs Performance Objectives

1. Plan Business Analysis Approach

2. Plan Stakeholder Engagement

3. Plan Business Analysis Governance

4. Plan Business Analysis Information Management

5. Plan Business Analysis Performance Improvements

Business Analysis Approach Stakeholder Engagement

Approach Governance Approach Information Management

Approach Business Analysis

Performance Assessment

Elicitation and CollaborationThis work area is about engaging with stakeholders to obtain the requirement and then confirm the result to ensure accuracy and consistency with other information.

Needs Business Analysis

Information Stakeholder Engagement



1. Prepare for Elicitation2. Conduct Elicitation3. Confirm Elicitation Results4. Communicate Business

Analysis Information5. Manage Stakeholder

Collaboration

Elicitation Activity Plan Elicitation Results

(Unconfirmed) Elicitation Results

(Confirmed) Business Analysis

Information (Communicated)

Stakeholder EngagementRequirement Lifecycle ManagementThis work area describes all the tasks that the business analyst must perform to maintain the requirements and designs from inception through to retirement. It includes maintenance of the requirements/designs in a suitable repository (if needed), mapping relationships between related requirements/designs and handling changes to requirements/design that arise during the project. It includes the actual approval of requirements.

Needs Business Analysis

Information Stakeholder Engagement



1. Trace Requirements2. Maintain Requirements3. Prioritise Requirements4. Assess Requirement

Changes5. Approve Requirements

Requirements (Traced) Designs (Traced) Requirements (Maintained) Designs (Maintained) Requirements (Prioritised) Designs (Prioritised) Requirements Change

Assessment Design Change Assessment Requirements (Approved) Designs (Approved)

Strategy AnalysisThis work area is about working out the most effective ways to apply the capabilities of an enterprise in order to reach a desired set of goals/objectives. It is about assessing the current state of an enterprise and defining a future state and how to reach it, with a good understanding of the risks involved. Strategy analysis provides context to requirement analysis and design definition.

Needs Influences (Internal,

External) Stakeholder Engagement

1. Analyse Current State2. Define Future State3. Assess Risks4. Define Change Strategy

Current State Description Business Requirements Business Objectives Future State Description

12 | P a g e

Approach Elicitation Results

(Unconfirmed) Elicitation Results

(Confirmed) Requirements (Prioritised) Designs (Prioritised)

Potential Value Risk Analysis Results

Requirement Analysis & Design DefinitionThis work area is about structuring and organising the requirement discovered during elicitation and specifying and modelling requirements/designs to identify solution options. It is essentially the work that transforms requirements/designs in to solution options with a recommendation.

Requirements (any state) Information Management

Approach Elicitation Results (any

state) Potential Value Solution Scope Change Strategy

1. Specify & Model Requirements

2. Verify Requirements3. Validate Requirements4. Define Requirements

Architecture5. Define Design Options6. Analyse Potential Value and

Recommend Solution

Requirements (Specified and Modelled)

Requirements (Verified) Requirements (Validated) Requirements Architecture Design Options Solution Recommendations

Solution EvaluationThis work area is about assessing the value delivered by a solution, or a component of a solution to recommend ways to increase that value.

Implementation Solution (External)

Current State Description Business Objective Potential Value

1. Measure Solution Performance

2. Analyse Performance Measures

3. Assess Solution Limitations4. Assess Enterprise

Limitations5. Recommend Actions to

Increase Solution Value

Solution Performance Measures

Solution Performance Analysis

Solution Limitation Enterprise Limitation Recommended Actions

Note that these knowledge areas do not provide a chronological description of a set of activities that occur in a strict order – although there are dependencies (you plan before you execute elicitation, of course) there are elements that can be brought in whenever appropriate (you might perform strategy analysis, realise that you then need to do solution evaluation and that might lead you to plan and elicit for a new solution, for example).

The way the BABOK book describes it is that tasks can occur in any order but that a task can only begin once the inputs for it are sufficiently mature to allow the task to begin. Some of the inputs to BABOK tasks are generated by other tasks (hence the loose sequencing) but some come from outside the business analysis process and these are marked with the word (external).

When we’re performing Solution Evaluation for instance, the solution itself is an external artefact that comes from outside of business analysis.

13 | P a g e

The relationship between the Knowledge Areas is given above – an inner cycle and an outer one. The internal one is like the lifecycle of a project – strategy analysis, requirement analysis and solution evaluation and you pull in tasks from the three outer boxes in support of this work.

Knowledge Areas Inputs & OutputsBusiness Analysis Planning and Monitoring

NeedsPlan Business Analysis Approach

Business Analysis Approach

NeedsBusiness Analysis Approach

Plan Stakeholder EngagementStakeholder Engagement Approach

Business Analysis Approach Stakeholder Engagement Approach

Plan Business Analysis GovernanceGovernance Approach

Business Analysis Approach Stakeholder Engagement Approach

Governance ApproachPlan Business Analysis Information

ManagementInformation Management Approach

Performance Objectives (external)Business Analysis Approach

Plan Business Analysis Performance Improvements

Business Analysis Performance AssessmentElicitation and Collaboration

NeedsStakeholder Engagement ApproachPrepare for Elicitation

Elicitation Activity Plan

Elicitation Activity PlanConduct Elicitation

Elicitation Results (unconfirmed)

Elicitation Results (unconfirmed)Confirm Elicitation

Elicitation Results (confirmed)

Business Analysis InformationStakeholder Engagement Approach

14 | P a g e

Communicate Business Analysis InformationBusiness Analysis Information (communicated)

Business Analysis Performance AssessmentStakeholder Engagement ApproachManage Stakeholders

Stakeholder EngagementRequirement Lifecycle Management

RequirementsDesigns

Trace RequirementsRequirements (traced)

Designs (traced)

RequirementsDesigns

Maintain RequirementsRequirements (maintained)

Designs (maintained)

RequirementsDesigns

Prioritise RequirementsRequirements (prioritised)

Designs (prioritised)

RequirementsDesigns

Proposed ChangesAssess Changes to Requirements

Requirements Change AssessmentDesign Change Assessment

Requirements (verified)Designs

Approve RequirementsRequirements (approved)

Designs (approved)

Strategy Analysis NeedsElicitation Results (confirmed)

Analyse Current StateCurrent State DescriptionBusiness Requirements

Business RequirementsDefine Future State

Business ObjectivesFuture State Description

Potential Value

Influences (internal and external)Elicitation Results (confirmed)

Designs (prioritised)Requirements (prioritised)

Business ObjectivesPotential Value

Assess RisksRisk Analysis Results

Stakeholder Engagement ApproachCurrent State DescriptionFuture State Description

Risk Analysis ResultsDefine Change Strategy

Change StrategySolution Scope

15 | P a g e

Requirement Analysis & Design Definition

Elicitation Results (any state)Specify & Model Requirements

Requirements (specified and modelled)

Requirements (specified and modelled)Verify Requirements

Requirements (verified)

Requirements (specified and modelled)Validate Requirements

Requirements (validated)

Requirements (any state)Information Management Approach

Solution ScopeDefine Requirement Architecture

Requirements Architecture

Requirements (validated and prioritised)Change Strategy

Requirements ArchitectureDefine Solution Options

Design Options

Potential ValueDesign Options

Assess Potential Value & Recommend SolutionSolution Recommendations

Solution Evaluation Implemented Solution (external)Business Objectives

Measure Solution PerformanceSolution Performance Measures

Potential ValueSolution Performance Measures

Analyse Solution MeasuresSolution Performance Analysis

Implemented Solution (external)Solution Performance Analysis

Assess Solution LimitationsSolution Limitations

Implemented or Constructed Solution (external)Current State Description

Solution Performance AnalysisAssess Enterprise Limitations

Enterprise Limitations

Solution LimitationsEnterprise Limitations

Recommend Actions to Increase Solution Value

Recommended Action

Some interesting facts to note about inputs and outputs: -

1) Requirements are generated in the Specify & Model Requirements task.2) Specified and modelled requirements are used by Trace, Maintain, Prioritise,

Verify and Validate Requirements and an input to the Define Requirement Architecture.

16 | P a g e

3) Requirements must, at least, be verified before we approve them.4) Requirements must, at least, be validated and prioritised for us to begin to

Define Solutions.

17 | P a g e

AREA 1: Business Analysis Planning and MonitoringThis knowledge area is all about organising and coordinating the work of business analysts and other stakeholders. I think of it as the mini “project planning” of conducting business analysis – it is when the business analyst determines which activities are necessary to complete the work required of them.

So, it includes stakeholder identification, selection of techniques to use, definition of the process used to manage requirements and how to assess the progress of the work.

The plans laid down here will govern the execution of all other business analysis tasks.

There are five tasks in this area leading to five deliverables: -

Plan a business analysis approach is about choosing the methodology to use for BA work. It may be dictated by organisation standards or methodology for the overarching project but it is where we decide the HOW of business analysis work – a predictive approach (waterfall, plan up front) will be different from an adaptive (Agile) approach. The approach can change over time.

Planning stakeholder engagement is about knowing who to approach and how to work together with them.

Planning business analysis governance is about knowing what part of BA work will interact with the governance model of the organisation.

Planning business analysis information management is about how the data captured is stored and integrated with other information sources.

Planning business analysis performance improvements is about determining how you will manage and monitor the quality of work and any lessons learned/improvement opportunities.

The following techniques are probably most useful during this area of work: -

Decision Analysis Process Modelling Structured Walkthrough

Core Concept ModelThe core concept model works as follows during the Business Analysis Planning and Monitoring work area: -

CONCEPT During this work area, business analysts…Change Are responsible for determining how changes to business

analysis results will be requested and authorised i.e. the change plan for the business analysis work.

Need Choose a business analysis approach that provides adequate analysis of the need(s) for the change.

18 | P a g e

Solution Evaluate if business analysis performance was a key contributor to the successful implementation of a solution.

Stakeholder Perform a stakeholder analysis to ensure planning and monitoring activities reflect stakeholder needs and account for stakeholder characteristics.

Value Conduct performance analysis to ensure business analysis activities continue to produce sufficient value for the stakeholders.

Context Ensure a complete understanding of the context under analysis in order to develop an efficient approach/plan correctly and appropriately.

Diagram

3.1 Plan Business Analysis Approach INPUT: Needs PROCESS: Plan Business Analysis Approach OUTPUT: Business Analysis Approach

Planning the business analysis approach is all about deciding how we’ll conduct business analysis and whether there are overarching guidelines, standards or organisation-approved methods to follow. If BA is happening within the context of a project, then planning BA will work within the overarching context of the project plan and the chosen project methodology.

19 | P a g e

Planning is also about ensuring that the BA work stays aligned to the overall goals of the change we’re trying to bring about and planning for the risks that are likely to arise.

BABOK makes a distinction between predictive planning and adaptive planning: -

Predictive – minimise uncertainty by spending a lot of time up-front in determining the work and do not begin implementation until this done. So, a typical “detailed analysis” before a project. Works well when needs are well known at the start of a project OR the risk of implementing something wrong is unacceptably high. So, waterfall project methodology would arguably fall into this category. They are plan-driven.

Adaptive – perform BA work in small increments to focus on rapid, frequent delivery of interim project deliverables. Well suited when needs are not known/ill-defined at the start of the project and an exploratory approach can be taken to find the best solution. So Agile methods of software development or continuous improvements projects fall into this category. They are change-driven.

Depending on the approach taken, the planning phase should define what level of formality we plan to achieve with our BA products – do we need formal workshops and detailed documents, or will we have a lighter backlog and frequent reviews and refinement sessions, for example?

The business analysis approach should define how plans are going to be updated as changes arise during the project and what will constitute verification and sign-off of the BA products. So, this is effectively the change management approach for business analysis work.

Finally, the level of risk and complexity associated with the overall business change intended should also be factored in to the BA planning so that the business analyst sensibly assigns their time, their knowledge (mindful also of lack of knowledge) and any additional resources needed to plan for a successful BA effort. By complexity we mean the number of stakeholders, business areas involved, number of requirements etc.

The overall output of this phase of work should be the Business Analysis Approach – the documented/agreed road map for the business analysis work to deliver including the scope, a work breakdown structure, an activity list and consideration of how the plan should be changed if conditions change.

3.2 Plan Stakeholder Engagement INPUT: Needs and the Business Analysis Approach PROCESS: Plan Stakeholder Engagement OUTPUT: Stakeholder Engagement Approach

Planning the stakeholder engagement is about taking the agreed approach and drilling down to the how, when and who of the people that the change will affect and who the business analysis will contact and build a relationship with. This is

20 | P a g e

also about understanding attitudes and expectations so that the BA can manage them accordingly.

Attitudes are things like whether they are receptive or resistant to our work, where the effects of the project be positive or negative to them, do they have reservations or trust issues with the project team, are their political factors, will they be encouraged or discouraged from collaborating with us, by their boss? They might not even see the value in business analysis also, for example.

Stakeholders are more likely to engage if they feel that they have an impact on/input to the final solution.

Stakeholder analysis/mapping is critical to understanding the decision-making authority of individuals and/or the level of influence of a stakeholder on the decision-making process. A stakeholder matrix may be useful in which the lines of communication and influence of stakeholders is documented.

This phase also helps identify if the level of influence that the stakeholders have will be enough to bring about the desired change. If it is not, then this should be documented as a risk – we’re trying to drive ahead a change without the necessary clout!

So, it’s about identifying the right stakeholders and how best to communicate with them to achieve the BA objectives. It may uncover stakeholders with similar needs that were not aware of one another.

It also includes assessing the complexity of our interactions with stakeholders – number and variety of end users for example.

Finally, this task should also help us begin to understand who approves, inspects and requests changes to our requirements, deliverables etc. based on stakeholder’s authority levels to feed into the next task on governance.

The overall output of this phase is a Stakeholder Engagement Approach document or agreement in which the BA is clear about who and how he will approach individuals and any tools that will be used for communication. This can be synthesised in to a Stakeholder Collaboration Plan and/or Stakeholder Communication Plan (this is mentioned in BABOK v3.0 but not formally described as an output – they would both fall under the Engagement Approach).

3.3 Plan Business Analysis Governance INPUT: Business Analysis Approach and the Stakeholder Engagement

Approach PROCESS: Plan Business Analysis Governance OUTPUT: Governance Approach

This activity is all about deciding how decisions are to be made and approved, including authority for prioritisation, approval of requirements and designs, handling changes and any unexpected blocking issues in BA execution.

21 | P a g e

Who should approve requirements, who should accept solution, who should sign-off, who should approve a change to approved requirements? etc.

So, it deals with decision making authority, who has final say if a conflict of opinions arise and if a change arises during the work, who reviews and gives the go/no go for plans to change to accommodate the modification?

A configuration management system might be used to manage and track changes.

The overall output is a Governance Approach document or agreement setting out the approval “chain of command” and change management governance.

3.4 Plan Business Analysis Information Management INPUT: Business Analysis Approach, Stakeholder Engagement Approach

and Governance Approach PROCESS: Plan Business Analysis Information Management OUTPUT: Information Management Approach

This activity is all about planning how the information collected during BA work will be stored, accessed and organised – the information systems (i.e. the tools) and models that will support the work. This includes the level of detail that will be targeted (BABOK speaks about this as the “level of abstraction”) and what level of detail is appropriate for which stakeholders. How will traceability will be maintained in our information store?

It also includes what stakeholders have access to our information store and what they are allowed to access.

Planning information management is also about planning requirement reuse, setting them up in such a way that they can save time for future projects because they describe common features or services – a good example might be a set of standard set of non-functional requirements.

A big part of the work is defining the attributes of the requirements – what are the key sets of information that will define each requirement? (such as complexity, unique ID, author, date, priority, urgency, source, risk, stability, key stakeholder etc.)

The book suggests the following as common requirement attributes: -

Complexity Author Risks Absolute Reference (the

unique identifier) Stability

Status Ownership Urgency Priority Source

22 | P a g e

The mnemonic CARA’s SOUPS is suggested for remembering this! In BABOK v2.0 there were a number of these mnemonic questions but I believe they have been removed from BABOK v3.0.

NOTE THAT: BABOK makes a distinction between a requirement’s relative priority (how important is it when compared to other requirements?) and its urgency (how soon do we need it?)

The overall output of this work is an Information Management Approach either documented or agreed how the BA work will organise and store the information it generates.

3.5 Identify Business Analysis Performance Improvements INPUT: Business Analysis Approach, Performance Objectives (external), PROCESS: Identify Business Analysis Performance Improvements OUTPUT: Business Analysis Performance Assessment

This activity is all about working out how we will build in and improve quality to the BA work that we do over time – what metrics will allow us to assess BA performance and improve this over time? Information can be quantitative (number of review cycles, time between initial engagement and requirement sign off) or qualitative (stakeholder survey, regular quality meetings).

This is usually done during work execution or towards the end.

Any external performance objectives if they exist (such as target performance for the BA themselves, their department or the organisation) will influence how BA performance is measured, analysed and reported.

This activity is not just about planning therefore, it’s about choosing the metrics, collecting the data, analysing it and providing feedback for improvement. Feedback can be in the form of: -

Preventive Action – to minimise the probability that a negative event occurs.

Corrective Action – to establish a way of reducing the impact of a negative event.

Improvement Action – to increase the probability that a positive event occurs.

The work might include existing organisational process assets – information from past work.

So, for example, surveys, project-end interviews and lessons learned debriefs all provide useful feedback to enhance future performance. Or a metric such as number of reviews needed to sign off a requirement, number of change requests during development, etc.

The overall output of the work is a Business Analysis Performance Assessment in which we’re effectively comparing actual performance to the

23 | P a g e

planned performance to identify variances and the lessons learned from them.

24 | P a g e

AREA 2: Elicitation and CollaborationThis knowledge area is all about how the business analyst communicates with stakeholders to obtain and then validate the information that they have. It is an activity that is on-going throughout all BA work (not a separate phase) and BABOK concentrates on what constitutes best practice for efficient exchange of information.

The key point is that the work understands the real underlying need that must be satisfied, not just the stated of superficial desires as expressed by a stakeholder. The business analysis must be ready to challenge and explore stated needs.

Elicitation and collaboration can be: -

Planned – workshops, surveys, template documents that are planned in advance and delivered.

Unplanned – more spontaneous conversations, encounters or “coming across” information that may lead on to more formal, planned investigation.

Or, most commonly, it is a mix of both!

There are five tasks in this area leading to five deliverables: -

Prepare for elicitation involves ensuring that stakeholders understand the interaction that will be demanded of them and that expectations between all parties are set accordingly.

Conduct elicitation is the act of interacting with the stakeholder(s), conducting research or running an experiment to actually gather source information for BA work.

Confirm elicitation results is about ensuring that the stakeholder has a shared understanding of the outcome of the elicitation and that the BA captured the information that they wanted and can compare it to other information to highlight any remaining gaps or inconsistencies.

Communicate business analysis information is about providing the captured details back to stakeholders in an appropriate format.

Manage stakeholder collaboration is about describing how we interact with stakeholders to engage them in the overall business analysis work.

Common elicitation techniques are: -

Document Analysis Interface Analysis Prototyping Observation Focus Groups

Requirements Workshop Interviews Brainstorming Survey/Questionnaire

25 | P a g e

The book suggests the mnemonic DIP OF RIBS for this although mnemonics are a lot less used in BABOK v3.0 (compared to v2.0). Many of these are event-based elicitation exercises and it is always useful to establish ground rules with participants for how these will be conducted – how frequent feedback will be and what will constitute a successful outcome.

Core Concept ModelThe core concept model works as follows during the Elicitation and Collaboration work area: -

CONCEPT During this work area, business analysts…Change Use a variety of techniques to fully identify the change that is

required, including concerns from stakeholders about the change.

Need Elicit, confirm and communicate the expressed needs. The understanding of need evolves over time.

Solution Elicit, confirm and communicate the desired characteristics of the proposed solution.

Stakeholder Manage the collaboration with stakeholders.Value Collaborate with stakeholders to assess the relative value of

the information provided through elicitation and confirm that value.

Context Apply a variety of elicitation techniques to identify the context that may affect the change.

26 | P a g e

Diagram

4.1 Prepare for Elicitation INPUT: Needs and Stakeholder Engagement Approach PROCESS: Prepare for Elicitation OUTPUT: Elicitation Activity Plan

Preparing for elicitation is about understanding the scope of the elicitation activity and using the appropriate techniques and tools with the right supporting material to ensure the success of the interaction. So typically, we’re identifying who to talk to/what to do, what questions to ask, what additional material we need to pull in etc. It’s about assessing our stakeholders (who are they, what are their expectations, where are they located) and planning how we will engage.

Critically it involves setting the objective and outcome for each elicitation – what do we want to learn and how will we know we have learned it?!

BABOK speaks about setting up the logistics of each elicitation, by which it means planning the actual contact, booking rooms, choosing what language to use, where and how we’ll execute a literature search and so on.

27 | P a g e

The work also involves gathering any background/supporting material needed as input to the elicitation.

BAs must be careful that getting a stakeholder to engage in elicitation will be difficult if the stakeholder doesn’t understand the process or feel that the work is not aligned with their own objectives. So, a big part of preparing for elicitation is making sure that the stakeholders themselves are sufficiently briefed and informed. This may mean reading background documentation, agreeing an agenda or even a pre-elicitation workshop on the BA methods to be used so that everyone is aligned and happy to contribute. Preparing the stakeholders in this way (such as teaching/briefing them on the elicitation technique to be used) will be key to the success of the elicitation activity.

4.2 Conduct Elicitation INPUT: Elicitation Activity Plan PROCESS: Conduct Elicitation OUTPUT: Unconfirmed Elicitation Results

After preparing, we actually conduct the elicitation by engaging with stakeholders in one of three modes: -

Collaborative – direct interaction with stakeholders to draw on their experience, expertise and judgement.

Research – discover and study information with (or without) stakeholders. Experiments – discover knowledge that cannot be drawn from

stakeholders or from studying material – for example a proof of concept to test out a concept and see if it works.

During elicitation, the BA has a role to guide discussions/research/experiments to ensure the planned goals are met – keeping discussion to subjects that are in-scope, for instance. The BA also has responsibility for recording the elicitation outcomes, of course and this (unconfirmed) elicitation result is the output of this task. The format of the outcome will vary depending on the nature of the elicitation conducted but (one would imagine) should be captured mindful of the Information Management Approach which mapped out what level of detail we are aiming for as we write up needs as requirements.

4.3 Confirm Elicitation Results INPUT: Unconfirmed Elicitation Results PROCESS: Confirm Elicitation Results OUTPUT: Confirmed Elicitation Results

The elicitation results captured must be confirmed to ensure a) they accurately reflect stakeholder’s need and expectations and b) they are consistent with any other work (confirmed elicitation results) captured to date. This means comparing the elicitation results back to source material or to any other sources to ensure we’re confident that they reflect stakeholder’s expressed needs and to resolve any contradictions and discrepancies at the same time.

28 | P a g e

So, as a simple example, we make minutes summarising our elicitation meeting and send that to stakeholders to confirm that the document is an accurate and complete record. We then compare the information presented in the minutes to the requirements captured elsewhere and see if there are any contradictions.

The aim of this task is to produce confirmed elicitation results.

The BABOK guide also says that this confirm elicitation exercise is much less formal than the verification and validation of requirements that occurs in the Requirements Analysis and Design Definition knowledge area.

4.4 Communicate Business Analysis Information INPUT: Business Analysis Information and Stakeholder Engagement

Approach PROCESS: Confirm Business Analysis Information OUTPUT: Business Analysis Information Communicated

The BA will build up a library of “business analysis information” over time – all information that is used as an input or output to business analysis work. They should be mindful to communicate this information to relevant stakeholders to ensure that all relevant parties are kept informed and aligned and to deal with the flow of feedback that returns – the BA must always act on any disagreements arising when they communicate material.

In the previous step we were confirming the results of one elicitation activity, here we’re distributing out the business analysis information to all relevant stakeholders – so it’s more broadly about keeping everyone informed.

This task includes deciding on the objects and the format of communication (will it be a formal document, informal document or a presentation? Will a collaborative platform be used to exchange information?) Will we use different communication for different stakeholders, for example?

The end goal is to communicate the information so that all stakeholders (including the BA) have a common understanding of the contents and implications of the analysis material. This means that it’s not enough just to push information out, we need to follow up and validate that it’s been received and understood.

4.5 Manage Stakeholder Collaboration INPUT: Business Analysis Performance Assessment & Stakeholder

Engagement Approach PROCESS: Manage Stakeholder Collaboration OUTPUT: Stakeholder Engagement

This task is about encouraging stakeholders to work towards a common goal and as such is an ongoing activity that begins as soon as stakeholders are identified. The BA works to maximise positive outcomes and avoid negative ones, taking into account each stakeholder’s role, responsibilities, influence, attitudes and authority (which may all change over time).

29 | P a g e

It is the BA’s job to build strong, trusting relationships to garner stakeholder support. This is done by gaining agreement with stakeholders on their commitments – how much of their time and energy will be needed and what will they be expected to do? Also, by monitoring how engagement is progressing and adjusting the approach accordingly.

In essence, it is about collaborating effectively so that everyone feels that they are heard and contributed. It is about managing stakeholders to foster a shared purpose and working towards a common, agreed outcome.

30 | P a g e

AREA 3: Requirements Life Cycle ManagementThis knowledge area is about the tasks that the BA must perform to manage and maintain information from inception to retirement. It is the life cycle of a requirement itself (as opposed to the life cycle of a project or business analysis work).

This involves things like managing conflict to ensure that stakeholders and project teams remain aligned.

BABOK’s concept is that a requirement is “alive” until the day on which the solution in which it is implemented is retired. Requirements don’t stop at project sign off as they go on adding business value and can continue to evolve.

So, the life of a requirement is, broadly: -

Representation of a business need as a requirement. Realisation of that requirement in the development of a solution. End with the retirement of the solution and the requirement that it

satisfied.

BABOK speaks about a requirement lifecycle management, separate from the process of business analysis itself – the steps that a requirement goes through (and a requirement may be in multiple states at the same time!) as follows: -

There are five tasks in this area of work which describe what we do with requirements: -

1) Trace Requirements to maintain the relationship between requirements and solution components, documents and any other work products. It should be possible to select a requirement and see all areas of work in which it is involved. A coverage matrix may be used to map requirements to other artefacts such as test plans or delivered modules.

2) Maintain Requirements is about ensuring that the requirement is up to date throughout the lifecycle and expressed in a format which permits re-use.

3) Prioritising Requirements is when the value, urgency and risk associated with requirements is analysed to inform our work planning.

31 | P a g e

4) BA’s must be able to Assess Requirement Changes to handle new and changing needs that arise during the work.

5) The aim is to Approve Requirements with stakeholders to reach agreement on design.

Core Concept ModelThe core concept model works as follows during the Requirements Lifecycle Management work area: -

CONCEPT During this work area, business analysts…Change Manage how proposed changes to requirements and designs

are evaluated.Need Trace, prioritise and maintain requirements.Solution Trace requirements and designs to solution components.Stakeholder Work closely with stakeholders to maintain understanding,

agreement and approval of requirements and designs.Value Maintain requirements for reuse to extend value beyond the

current initiative, if possible.Context Analyse the context to support tracing and prioritisation

activities.

Diagram

32 | P a g e

5.1 Trace Requirements INPUT: Requirements and Designs PROCESS: Trace Requirements OUTPUT: Traced Requirements and Traced Designs

We need to ensure that all requirements and designs (at all the different levels of the work and different states of maturity) are aligned to one another for consistency and to manage the effect of changes. Traceability should allow the BA to describe the lineage (backwards and forwards) through all work products and the relationships between requirements and is essential for finding gaps and inconsistencies and ensuring nothing is missed and that we can justify any requirements present in our system.

Traceability also helps us assess the impact of any later change to the requirements.

Note that this task works with requirements AND designs, it’s not just about stated need but about the design products (solution component, test case, mock up wireframe) that realise requirements.

BABOK draws a parallel between process traceability in which we decompose: -

To requirement traceability in which we might decompose (for a software project): -

Note the little design – code – test sub-processes traced to a solution requirement (functional and non-functional) and applicable in software development.

When tracing requirements, the BA needs to consider: -

1) The level of formality needed – how much detail will be given for each requirement and its place in the network of related requirements?

2) What is the nature of the relationship between two requirements?3) Can a repository be used to store the requirements and assist the BA in

managing the information?

Relationships (and designs) can be defined as: -

Relationship

Description

33 | P a g e

Value Chain

Business Process

Sub-Process Activity Task

Business Need Business Requirement Stakeholder Requirement Solution Requirement

DESIGN > CODE > TEST

Derive One requirement is descended from another, typically because it describes one aspect of the parent in more detail.

Depends There is a strong link between two requirements, either of necessity (we can only implement one requirement if the other is done) or effort (a requirement will be easier to implement if its dependant is implemented).

Satisfy A requirement satisfies the need stated in another – for example, the relationship between a solution component and a functional requirement.

Validate A requirement that confirms that another has been implemented correctly – for example, the relationship between a test case and a functional requirement.

BABOK v2 made a distinction between derivation (backwards traceability) and allocation (forward traceability) which it looks like they refined into the clearer terminology in the table above.

5.2 Maintain Requirements INPUT: Requirements and Designs PROCESS: Maintain Requirements OUTPUT: Maintained Requirements and Maintained Designs

BA’s need to retain requirement accuracy and consistency throughout a project (and beyond) and this task focusses on that need by adhering to a consistent and clear format for representing requirements (well defined attributes for requirements, for example) and ensuring that they stay up to date. Attributes may change even if their parent requirement does not (imagine the stakeholder responsible for a requirement changes), and so maintaining attributes is called out as a separate sub-task from maintaining the requirement.

Maintenance of requirements also facilitates their reuse if a similar project arises or if the requirements express fundamental needs which crop up often. Requirements need to be already identified for reuse so that they can be easily found and are then written in such a way (clear, generic language) that permits reuse.

5.3 Prioritise Requirements INPUT: Requirements and Designs PROCESS: Prioritise Requirements OUTPUT: Prioritised Requirements and Prioritised Designs

Requirements are almost never realised within constraints of time, money and scope and so constant prioritisation to assess (and maintain) the importance of each requirement relative to the rest is essential for planning to achieve maximum value.

Prioritisation criteria must be agreed with stakeholders but usually works with factors such as: -

34 | P a g e

Factor DescriptionBenefit The advantage/value provided to stakeholders by the

realisation of a requirement.Penalty The consequence of not implementing a given requirement.Cost The effort and resources needed to implement the

requirement. Cost to Benefit ratio might be a possible combination factor.

Risk The chance that a given requirement is impossible to achieve or, if possible, will not deliver all the value expected.

Dependencies

As part of the Trace Requirements task, the team will have identified dependent requirements and dependencies on external factors. Dependency can be a basis for prioritisation if we need to implement one requirement before another or validate that a high-risk requirement is possible before spending time and resources on any others.

Time Sensitivity

The “best before” date after which the business need loses value – how urgently does the requirement need to be delivered?

Stability The likelihood that a requirement will change, meaning that it might be desirable to deprioritise it while the need is fully formulated and agreed.

Regulatory or Policy Compliance

Any internal/external legislation or policy which mandates the implementation of the requirement.

Stakeholders usually prioritise based on benefit and technical teams prioritise on the technical challenges or dependencies. There may not always be agreement between (and within) these groups and so the need to continually assess and re-prioritise may arise.

5.4 Assess Requirement Changes INPUT: Requirements, Designs and Proposed Changes PROCESS: Assess Requirement Changes OUTPUT: Requirements Change Assessment and Designs Change

Assessment

Requirements and designs will inevitably change during the lifecycle of a project (or after). BABOK defines this task for assessing and managing such changes when they arise.

BA’s must validate that the proposed change increases the value of a solution, doesn’t conflict with other requirements and whether there is an effect on solution risk. Traceability is maintained so that a requirement/design change can be followed back to a source need and to allow us to quickly see what other business analysis information might be affected by the change.

Any change occurs within the context of the overarching change control approach as defined in the Plan Business Analysis Governance task from the Business Analysis Planning and Monitoring knowledge area.

35 | P a g e

When approaching a change, the BA must assess the level of formality needed to understand the impact of the change correctly (an impact analysis).

The output of the task is the requirement or design assessment with an allied recommendation to approve, modify or deny the change request.

5.5 Approve Requirements INPUT: Verified Requirements and Designs PROCESS: Approve Requirements OUTPUT: Approved Requirements and Approved Designs

The final task in the Requirement Life Cycle knowledge area is to get approval of the requirements/designs to allow work to continue appropriately. The BA ensures communication between all stakeholders (using the Communicate Business Analysis Information task from the Elicitation and Collaboration knowledge area) and documents the approval (which may be formal or informal).

Approval of requirements must, of course, be tracked so we know the approval status of any requirement/design at any point in time.

This facilitation role is based on the BA’s good understanding of stakeholder roles (as defined by the Governance) to know who can approve and the best way to go about building consensus to achieve approval. To get consensus the BA may need to resolve conflicts and issues arising from different points of view among stakeholders.

The output is Approved Requirements and Designs at sufficient detail and maturity that a project team can begin analysing them for implementation.

All approvals must be documented, of course, and we might even maintain an audit log of changes/approvals over time to understand who, what and when.

36 | P a g e

AREA 4: Strategy AnalysisThe next three knowledge areas can be thought of as lying on a line from potential value to actual realised value. Strategy analysis is about assessing where future value can come from and solution evaluation is about assessing actual value.

One key term over the next three knowledge areas is the solution scope.

The Product or Solution Scope is the characteristics, features, or function of the product or service that is to be built. Solution scope is all about the solution to be implemented: how will it look like, how will it function, and other characteristics, etc. Essentially, it’s the set of capabilities that a solution must deliver in order to meet the business need.

This knowledge area is about the most effective way to employ the capabilities of an enterprise, department, team, product, project etc. to achieve its goals and objectives. It provides the overall road-map in which business analysis work occurs.

So, at this point we’re moving from simply documenting and understanding requirements to imagining a future state and about the ability of the enterprise to reach it.

There are four tasks in this area of work which describe how strategy is involved in the work of business analysis: -

1) Analyse Current State is about understanding the business need in the context of how things are done today – this sets a baseline and a context for the change we are trying to bring about.

2) Define Future State is about setting the goals and objectives that will demonstrate that the business need has been met and understanding what part(s) of the business will change.

3) Assess Risks is about understanding the uncertainties accompanying the desired change.

4) Define a Change Strategy is about performing a gap analysis between current and future states and assessing the options for going from one to another with a recommended option.

37 | P a g e

Core Concept ModelThe core concept model works as follows during the Strategy Analysis work area: -

CONCEPT During this work area, business analysts…Change Define the future state and develop a strategy to achieve it.Need Identify the needs within the current state and prioritise them

for satisfaction in the future state.Solution Define the scope of the solution for the change strategy.Stakeholder Understand the business need as expressed by stakeholders

for reaching a future state.Value Examine the potential value of the proposed solution to

assess whether change is justified.Context Consider the context of the enterprise developing the change

strategy.

6.1 Analyse Current State INPUT: Needs and Confirmed Elicitation Results PROCESS: Analyse Current State OUTPUT: Current State Description and Business Requirement

To get where we want to go, we need to know where we are. Understanding the proposed change in respect to the current state of the business is the purpose of this task. This defines why the change is needed, what is wrong/deficient with the way that things currently stand?

The current state is explored in just enough detail to validate the need and help the business identify what needs to change and how the effects of that change will be assessed.

Be wary that the current state is rarely static and may evolve throughout the lifecycle of a requirement.

The current state will be analysed with respect to the business needs driving the whole work.

Needs can be analysed: -

From Top-Down – from a strategic goal that needs to be achieved. From Bottom-Up – from a current state or a process, function or system

that needs to change. From Middle Management – for a middle manager that needs

information to make decisions. From External Drivers – from customer demand or a business

competition in the marketplace.

Defining the needs is probably the single most critical step in a BA’s work. Needs will often be expressed by stakeholders along with a proposed solution and the BA should examine the assumptions and constraints wrapped up in such statements.

38 | P a g e

Assumptions are statements which are considered to be true but have not been proven to be so.

Often, we must understand the organisational structure and culture to properly understand our stakeholders, their context and possible bias.

Business needs should always be expressed from the perspective of the enterprise, and not that of any particular stakeholder.

BA will also look at the current capabilities and processes of an organisation and can use: -

A capability-centric view in which understanding the existing capabilities and how they might be recombined or re-tasked to achieve a new business benefit is the focus.

A process-centric view in which change to business process to make improvement or reduce inefficiencies is the focus.

Other influences on understanding the current state are technology and infrastructure considerations, any policies which inform and guide work, the business architecture that describes how the organisation fits together, internal assets that relate to the change needed and any external influences which are influencing the change (industry practice, competitor activities, customers and supplier behaviour, regulatory environment etc.)

The output of this work is a Current State Description - the “as is” along with the Business Requirements to perform analysis considering the current state knowledge.

6.2 Define Future State INPUT: Business Requirements PROCESS: Define Future State OUTPUT: Business Objectives, Future State Description and Potential

Value

This task is about defining the future set of conditions that will meet the business need – which means having a clear view of what is needed, whether resources are available and that key stakeholders are also aligned with this view.

The “clear view” does not need to be at the level of detail needed for implementation, that is generated in any following project(s), but it does need to be detailed enough to allow different options to be compared including the value of each option, set scope and provide enough detail for stakeholders to reach consensus.

39 | P a g e

The change needed to bring about the future state can affect any aspect of the business – processes, software, people, marketplace in which we work, knowledge and training, infra etc.

To define a future state, a business should proceed from the high-level strategic goals (“Increase employee satisfaction”) that it wants to achieve to a more granular set of objectives (“Improve the bi-monthly satisfaction survey by an average 1.0 point”).

Objectives should be SMART: -

S – Specific to describe something that has an observable outcome. M – Measurable to (ideally) quantify the outcome. A – Achievable or Assignable to ensure that the objective is feasible

with the planned resources. R – Relevant to ensure alignment with the organisation’s vision and

goals. T – Time-bound to ensure delivery within a fixed time frame.

40 | P a g e

BABOK talks about the “solution space” – the range of possible solutions that will be considered to meet the need and how the delivery team and the BA will collaborate to list the options. Note that the scope (all things that must be considered) of the solution space isn’t related to the size of a change – even a small change may require engaging with people, processes across all areas of an organisation.

The solution space for the future state will therefore involve things such as the future relationship between stakeholders, change to an organisation’s culture, new processes, new technologies, new business architecture – all the elements that will be affected to go from “as is” to “to be”.

BA’s must also consider any constraints on the future states – things that cannot change and so will influence the proposed solution such as time restrictions, use of approved technologies only, regulatory constraints etc.

Assumptions on which the “to be” state relies should be understood and it should be clear what potential value the future state delivers.

Meeting the business objective alone is not enough to justify the transition to a future state, meeting the objectives for one stakeholder may actual decrease value for another. The BA should therefore look at potential value of a change across all areas and whether the investment needed to effect the change is worthwhile.

Finally, any unrealised opportunities should be noted to see if they are still of value/of interest after project delivery.

6.3 Assess Risks INPUT: Influences, Elicitations Results, Designs, Requirements, Business

Objectives and Potential Value PROCESS: Assess Risks OUTPUT: Risk Analysis Results

BA’s assess risk to understand any potential undesirable consequences arising, for example, from internal/external forces on an enterprise during the transition to and once in the future state, to recommend a cause of action to reduce/mitigate risk.

Risks are considered in terms of: -

Possible consequence if the risk occurs. What will happen? Impact of the consequence. How serious will it be and for who? Likelihood of the risk. What’s the probability of it occurring? Potential time frame of the risk. When will it occur?

In BABOK, a risk is always an uncertain event with a negative outcome, the methodology does not categorise opportunities as risks with positive outcomes as other methodologies often do.

41 | P a g e

Opportunities instead, can be treated as needs in BABOK.

Even though it will never be possible to know all that will occur as a result of a particular change, it is still possible for the BA to estimate the effect of unknown or uncertain events based on previous lessons learned and experience.

The BA should consider all unknowns as risks.

Constraints, assumptions and dependencies for risks should be understood and can themselves be re-categorised as risks if necessary.

BA’s should have a sense of the overall/aggregate risk and the likely total impact in terms of time, effort or other measures i.e. “in the worst-case scenario that all risks materialise, we will be 3 months over estimate and double the budget.”

The action taken when faced with risks will depend on the risk tolerance of the stakeholders and/or enterprise. Whether they are risk-averse, neutral or actively risk-seeking because of the potential higher value that a riskier approach may deliver.

The BA will work with the stakeholders, mindful of the appetite for risk to recommend how each change should be tackled with respect to its risks, one of: -

Pursue the change regardless of the risk. Make effort to reduce either the likelihood or impact of the risk. Try to increase the benefit of the change to outweigh the risk. Identify way to optimise opportunities to outweigh risks. Acknowledge that risk is too high and do not pursue the change.

6.4 Define a Change Strategy INPUT: Stakeholder Engagement Approach, Current State Description,

Future State Description, Risk Analysis Results. PROCESS: Define a Change Strategy OUTPUT: Change Strategy, Solution Scope

A change strategy is about assessing the different approaches to affecting a change and then recommending an approach. It should detail things such as: -

What is the context of the change? What different strategies exist? Which approach is recommended and why, what is the justification that

makes it the best? What resources are needed to make the change work? How the enterprise will realise value once the change is made? Who are the key stakeholders in the change? What transition states will occur along the way?

42 | P a g e

The new state is described in terms of the solution scope (what will actually change?), so it is clear to stakeholders what the desired end state will be.

Note that this task is about changing the enterprise as a whole, introducing a new solution and/or modifying processes and is different from the change management aspects described in the Plan Business Analysis Approach task of the Business Analysis Planning and Monitoring work area which is about managing changes to the requirements themselves that arise during the business analysis phase.

A gap analysis forms a big part of choosing a change strategy as it will detail the variance between the “as is” and “to be” and therefore the effort that will be required to achieve the change.

An enterprise readiness assessment is a useful means of analysing how ready an enterprise is to achieve a change and then make use of the benefit which the change delivers, this will also feed in to the recommended strategy.

BABOK suggests that all of this work is synthesised in to a Change Strategy, a high-level set of activities and events to bring about a desired change with the business case for each possible option and the justification of why a particular approach has been recommended. The opportunity cost of benefits that are not realised because of those choice of strategy should also be understood/documented as should any transition states through which the organisation must pass between the “as is” and “to be”. The use of transition states may necessitate the use of some release planning to control how changes are rolled out.

43 | P a g e

AREA 5: Requirements Analysis & Design Definition (RADD)This knowledge area is about structuring and organising the information that the BA has discovered during the elicitation process and validating that information so that solution options can be developed, and a recommendation delivered.

It’s usually a process of progressively elaborating stakeholder and solution requirements to a point where a project team can implement a solution based upon them.

This work is still on the continuum from the conceptual to the actual and the figure below gives again, a sense of the work in which a BA is involved along this spectrum. Note that BABOK makes a clear distinction between requirements and designs – the usable expression of a need and the proposed design to satisfy that need.

There are six tasks in this area of work which describe how strategy is involved in the work of business analysis: -

1) Specify and Model Requirements is about describing a set of requirements or designs using structured, analytical techniques.

2) Verify Requirements is about ensuring that the work is in sufficient detail that it can be used by a stakeholder and that requirements are internally consistent i.e. “ready to show to customer”. Effectively a quality control step.

3) Validate Requirements is about ensuring that the requires/designs do deliver value and are aligned with any wider organisation goals.

4) Define Requirements Architecture is about organising all requirements/designs so that work effectively together and are fit for purpose.

5) Define Design Options is about exploring the different ways to achieve the change.

6) Analyse Potential Value and Recommend Solution is about comparing the benefits of different course of action and recommending the solution that represents the best option with justification.

Core Concept ModelThe core concept model works as follows during the Requirements Analysis and Design Definition work area: -

44 | P a g e

CONCEPT During this work area, business analysts…Change Transform elicitation results in to requirements and designs

in order to define a desired change.Need Analyse the needs in order to recommend a solution.Solution Define solution options and recommend one with justification.Stakeholder Tailor the requirements and designs so that they are

understandable to each group of stakeholders.Value Analyse and quantify the potential value of each solution

option.Context Model and describe the context in a format that is

understandable to stakeholders.

7.1 Specify and Model Requirements INPUT: Requirements, Information Management Approach, Elicitation

Results, Potential Value, Solution Scope and Change Strategy PROCESS: Specify and Model Requirements OUTPUT: Requirements (specified and modelled), Requirements Verified,

Requirements Validated, Requirements Architecture, Design Options and Solution Recommendation

The work that we typically think of a business analyst performing falls in to this area, he/she is analysing the results of their elicitation with stakeholders and modelling them in to a structured format – creating both requirements and designs. This includes setting metadata about the requirements/design.

When this analysis is performed on a need the output is a requirement and when it is performed on a solution, the output is a

design.

By “modelling” of requirements, we mean generating any sort of derived product that represents those requirements in a structured way – so process models, use cases, user stories, matrix of needs etc.

The boxed text above is important, the term “design” is used in a specific way in BABOK and is not always the same as what we think of as “design” in the IT world i.e. technical designs created by software developers and architects. Designs for BABOK are the usable representations of a solution i.e. something that describes a solution in enough detail for us to make decisions about it.

When BABOK speaks about “models” it means any descriptive/organised way to represent requirements/designs to communicate them to a specific audience, so we may be creating a matrix, a diagram, a table etc. Models can represent any data that is in scope of our analysis work such as an organigram of people in a team, a root cause analysis, a process flowchart, a data dictionary etc.

Models can then be discussed with stakeholders and analysed to identity any missing, incorrect or superfluous components and reach an agreed description of whatever we are analysing. Models very often highlight the need for further elicitation. Multiple models might be built, and information compared between them.

45 | P a g e

Note that the level of abstraction (the detail to which requirements have been specified) will probably vary based on the type of requirement and the audience for that requirement, we’ll almost certainly want to produce different views of the elicitation results for different stakeholders tailored to their background, context, interest etc.

7.2 Verify Requirements INPUT: Requirements (specified and modelled) PROCESS: Verify Requirements OUTPUT: Requirements (verified)

Verify requirements is a quality control step – a sanity check by the business analyst and key stakeholders that the requirements are fit for purpose and ready to be validated/have a solution built using them. Fitness for use is the critical point – requirements must be internally consistent, described consistently (correct use of meta data such as categorisation and criticality for example), and be presented in a manner appropriate for the audience that will perform validation.

So, you can think of it as a quality audit/review of the requirements. Are the requirements SMART (specific, measurable, achievable or assignable, realistic and time-bound), written consistently, use glossary-defined terms only, no spelling errors 😊 etc.

BABOK lists the following properties of a good quality requirement: -

Atomic – self-contained and easily understood in isolation. Complete – work can continue/be executed based on the requirement,

nothing is missing. Consistent – no conflicts and aligned with stakeholder’s needs. Concise – no unnecessary content, appropriate and precise language. Feasible – reasonable and possible within risk, schedule and budget. Unambiguous – clearly stated with no room for misinterpretation. Testable – it must be possible to verify that the requirement has been

fulfilled. Prioritised – ranked and/or grouped to provide a clear sequence of

important. Understandable – uses common terminology familiar to the intended

audience.

Verification is all about checking compliance with any other standards or guidelines, ensuring correct notation on diagrams, being confident that terminology is consistent and clear etc.

Business analysts can develop checklists for performing their verification quality control with acceptance criteria for the requirement.

7.3 Validate Requirements INPUT: Requirements (specified and modelled)

46 | P a g e

PROCESS: Validate Requirements OUTPUT: Requirements (validated)

Whereas verification is a quality control exercise, validation of requirements is the moment at which we ensure that all requirements and designs are aligned to business need and do support the delivery of value.

If verification was all about quality, validation is all about ensuring business value – that we can justify each thing we’re asking for as it will deliver (an ideally tangible/measurable) improvement.

So, this involves stakeholder review and confirmation that requirements and designs are accurate and correctly represent their need and that the future state suggested by the work delivers the expected value to those that will benefit from it. It’s an ongoing process and is a further “sanity check” that what we are proposing to do makes business sense and is worth doing.

To validate requirements, all parties must be aware of the assumptions on which the work rests and risks arising from these.

Ideally a business analyst develops measurable evaluation criteria to estimate how effective the change proposed by a given (set of) requirements/designs will be – something that allows decision makers to see tangible improvement/justification for moving from current to future state.

Validation is therefore an excellent mechanism for ensuring alignment with solution scope. Have our requirements kept us within the envelope of the change we’re trying to achieve, or have we creeped outside of this?

It’s also a good place to ensure that we have alignment between different levels of our requirements. If we had a solution requirement that said we must be 100% cloud, but we have a stakeholder requirement that tells us that they want a local database on their machine, then we have a contradiction to resolve.

Note that verification and validation of requirements could occur at the same time. One doesn’t block the other starting BUT validation cannot complete until verification is complete i.e. we could start work to validate unverified requirements but we can’t finalise validation until we have verification.

7.4 Define Requirements Architecture INPUT: Requirements (in any state), Information Management Approach,

Solution Scope PROCESS: Define Requirements Architecture OUTPUT: Requirements Architecture

A requirements architecture is the structure of all the requirements, something which ensures that they “fit together” to produce a cohesive whole that is intelligible to stakeholders.

47 | P a g e

The architecture describes what types of models are appropriate for what parts of our analysis work and how they inter-relate i.e. the business analyst decides that he/she will create a spreadsheet of requirements statements mapped to an organigram of roles cross-referenced with a set of mock-up screens. BABOK describes this set of different representations as viewpoints – a set of conventions on how requirements will be described across different formats. Each viewpoint will have its strengths and weaknesses and the business analyst will, most likely, need several viewpoints to describe things fully and efficiently. You wouldn’t model a business process flowchart in an Excel table nor describe a screen mock-up in a long text document. The business analyst must choose the appropriate format and avoid overloading any one viewpoint with too much information.

Describing the requirements from multiple viewpoints helps highlight gaps and ensures completeness.

BABOK refers to the actual requirements and designs for a particular solution as one view taken from a viewpoint. A collection of views therefore makes up the solution architecture.

In summary, viewpoints tell the business analyst what information they should provide for each stakeholder while views extract the

actual requirements and designs.

If a collection of viewpoints is a standard across an industry, sector or organisation then BABOK calls it an “architectural framework” – typically a set of standard templates provided by a Project Management Office (PMO). A set of templates which represent requirements in a consistent way suitable for some pre-defined viewpoints.

A requirements architecture also allows the business analyst to understand the relationship between requirements and to ensure that relationships are always: -

Defined – a relationship exists between two requirements and is well described.

Necessary – a relationship is needed to understand two requirements together. It is not superfluous.

Correct – the requirements do have the relationship described. Unambiguous – as with requirements themselves, the relationship is

described without risk of misinterpretation. Consistent – relationships are described in a coherent way using

standard language as defined in viewpoints.

We might also think of a dependency of effort; one requirement will be easier to implement if we do another first

Finally, the structure of business analysis work is also an information architecture – our tools and systems for recording and storing our viewpoints.

48 | P a g e

7.5 Define Design Options INPUT: Requirements (validated and prioritised), Change Strategy,

Requirements Architecture PROCESS: Define Design Options OUTPUT: Design Options

Once we have validated and organised requirements, the business analyst and team can work on defining the different approaches to a solution, allocate requirements across components of the solution and essentially map the need to the satisfaction of that need.

Design options are a way of decomposing the change strategy (which is a strategic document) into smaller, tactical, elements for actually carrying out and delivering the work.

To formulate a list of design options, the business analyst must: -

1. Consider different solution approaches such as creating a solution, buying a solution or a combination of both.

2. Document the improvements to the business that each design will bring, things such as increase efficiency, increased access to information or additional capabilities that do not exist today.

3. Allocate the requirements to the different solution components to ensure that they are not forgotten/left out.

4. Describe and document the design option including any performance measures to help decide which option is best.

7.6 Analyse Potential Value and Recommend Solution INPUT: Potential Value, Design Options PROCESS: Analyse Potential Value and Recommend Solution OUTPUT: Solution Recommendation

With a list of design options drawn up and an understanding of the potential value that they deliver, the final task in this activity is to review the work and recommend a solution. The analyst must be mindful that some benefits may only be accrued over time and any recommendation is likely to be a weighing up of the pros and cons of the different options.

The analyst must consider not just the benefits, but the expected cost (in terms of time, effort, people, resources, finance etc.) to come up with an overall value. Value can be positive (the benefits exceed the costs) or negative (the costs outweigh the benefits).

Value must be considered from the view of stakeholders and also from the enterprise as a whole. Value to the enterprise is more important than that to a specific individual group. Indeed, an increase of value to the business may mean a decrease for one specific group of stakeholders!

When estimating value in this way, BABOK stresses that we’re talking about potential value, with the assumptions and risks in the mix we don’t know if this

49 | P a g e

value will be fully realised exactly as we imagine or not. Business analysts should be mindful of the uncertainties prevailing at the time that the estimate is made.

To reach a recommendation therefore the team must look at the best benefit to cost ratio while also factoring in other constraints such as the available resources to carry out the work, any restrictions on the solution such as regulatory guidelines and any dependencies between requirements which dictate what needs to be implemented together or in sequence.

50 | P a g e

AREA 6: Solution EvaluationThe final activity in the BABOK pantheon is concerned with assessing the performance of and value delivered by a proposed solution or an already in-use solution to ensure that it is fully realising its potential. Even if only a partial solution has been delivered to date (such as a proof of concept), there may still be interest in engaging a business analyst to ensure that it is delivering as stakeholders expected.

So, this is a critical activity if several solutions are being proposed or if a production system is not meeting its full potential.

In fact, solution evaluation can also be performed on some project artefacts while still during development - things like prototypes or pilot/Beta releases can all be critically examined to validate their fitness for purpose

If we go back to the same diagram presented at the start of Activity 5, these pre-delivery artefacts as well as the operating production release all fall under “Solution Evaluation”.

There are five tasks in this area of work which describe how evaluation should proceed: -

1) Measure Solution Performance is about assessing how best to measure a solution including its alignment with enterprise goals and then performing that assessment.

2) Analyse Performance Measures is about studying the performance information collected and making decisions about the solution’s behaviour.

3) Assess Solution Limitations is about identifying anything within the scope of the solution that is preventing the solution from achieving its full value.

4) Assess Enterprise Limitations is about identifying anything outside the scope of the solution that is preventing the solution from achieving its full value.

5) Recommend Actions to Increase Solution Value is about recommending actions to maximise the value obtained from the solution.

51 | P a g e

Core Concept ModelThe core concept model works as follows during the Solution Evaluation work area: -

CONCEPT During this work area, business analysts…Change Recommend a change to either a solution or the enterprise to

exploit some unrealised potential value of a solution.Need Evaluate how a solution or component of a solution is fulfilling

a need.Solution Assess the performance of a solution and any unrealised

potential value.Stakeholder Elicit information from stakeholders about solution

performance and value delivery.Value Determine any unrealised potential value.Context Consider any context determining measures and anything

limiting value being fully realised.

8.1 Measure Solution Performance INPUT: Implemented Solution (external), Business Objectives PROCESS: Measure Solution Performance OUTPUT: Solution Performance Issues

In this task, the business analyst defines metrics for measuring a solution and then collects data to evaluate the effectiveness of the solution in terms of the value it brings. It can be applied to a newly-developed or existing solution.

Often solutions have their own built-in metrics but without these, the business analyst must work with the stakeholders to determine some meaningful measure of value – usually some sort of Key Performance Indicator (KPI) such as the time taken to achieve something with the tool.

Measures can be: -

Quantitative – numerical and countable/finite to allow precise mathematical use.

Qualitative – subjective such as attitudes and perceptions.

Measures should, ideally, be derived from well-defined goals and objectives. BABOK suggests that this is the best source of measures.

As with requirements and designs, proposed measures should be validated to ensure fit for purpose – also to ensure alignment with any higher-level metrics such as an enterprise-wide target.

Measures should be checked and validated for bias – if we’re measuring work accidents and we only measure at night, we’re likely to get unrealistically low values!

When collecting measurement data, the business analyst must decide on the volume/sample size of data to collect to be representative and the frequency and

52 | P a g e

timing of measurements. More recent data is usually of higher value than older data.

8.2 Analyse Performance Measures INPUT: Potential Value, Solution Performance Measures PROCESS: Analyse Performance Measures OUTPUT: Solution Performance Analysis

Once data is collected, it must be analysed to understand the information it presents. This may require synthesis and interpretation for the analyst to ultimately understand the value that the solution is delivering to the enterprise.

Analysis should be performed against the potential value that stakeholders hoped/hope to achieve with the solution i.e. matching the “as is” value of the solution as described by the measures to stakeholder’s expectations. BABOK calls this solution performance versus desired value.

So, we can think of value in this lifecycle: -

Potential value is the value we hope to achieve with the solution before it is built, mindful of the risks and assumptions on which the assessment of potential value lies.

Actual value is the measured/perceived value of the delivered solution. Desired value is the expectation of stakeholders as to what the solution

delivers.

And difference between potential value and actual value is a variance.

Performance measures may also uncover new risks related to the solution or trends over time that might point to time-sensitive issues.

Analysts can only rely on performance measures if they are of high accuracy. BABOK suggests that a good test of accuracy is whether the results of measurement are repeatable. Once we have accurate measurements, we can look for trends.

Finally, any variance between expected and actual performance represents a potential problem for which root cause analysis is needed.

8.3 Assess Solution Limitations INPUT: Implemented Solution (external), Solution Performance Analysis PROCESS: Assess Solution Limitations OUTPUT: Solution Limitations

The analysis of measures may point to features within the solution itself which are limiting the full realisation of its potential value.

53 | P a g e

Potential Value Actual Value Desired Value

The business analyst will, for example, look for any internal component dependencies since a solution (like an army) will only ever be as good as its weakest element. It may be that by improving one specific component, the whole solution can be improved.

Essentially this task is one of investigating any problems suggested by the measures and understanding their cause from within the solution itself. Problems should be understood in terms of their severity, probability of occurrence and – perhaps most importantly – their impact on the business and the ability to absorb that impact.

The analyst will suggest which problems must be solved, which mitigated, and which accepted.

The example was given of a tablet application delivered to a cold storage facility, the product met all requirements but couldn’t be used (at first) because the workers were wearing gloves.

A lack of training provision might also be a cause of solution uptake limitation. Or my old boss’ famous example of the police station for a city that was built across the river and then never used because the project to build the bridge was cancelled.

8.4 Measure Enterprise Limitations INPUT: Implemented or Constructed Solution (external), Current State

Description, Solution Performance Analysis PROCESS: Measure Enterprise Limitations OUTPUT: Enterprise Limitations

The analysis of measures may point to features external to the solution itself which are limiting the full realisation of its potential value. This may be dependencies on other systems on which the solution relies or contextual factors such as culture, stakeholder interests, business process etc.

BABOK suggests that such external analysis proceeds via four activities: -

1. As assessment of the culture in which the solution is being used, is there anything about the prevailing culture/mindset of the stakeholders which is limiting value?

2. An analysis of the solution’s impact on stakeholders including the functions/processes implemented by the solution, the locations involved in the use of the solution and any concerns that stakeholders themselves raise about the solution.

3. An understanding of whether any aspect of the organisation’s structure has been altered by the solution and the impact of such disruption, for example a change to reporting lines or informal relationships such as friendships or political alliances!

4. Finally, an operational assessment of the enterprise might uncover additional processes and tools that could gain value from the solution.

54 | P a g e

8.5 Recommend Actions to Increase Solution Value INPUT: Solution Limitations, Enterprise Limitations PROCESS: Recommend Actions to Increase Solution Value OUTPUT: Recommended Actions

With an understanding of the gap between potential and actual value and the information collected on the limitations responsible for this gap, the business analyst can recommend corrective actions to increase actual value.

One possible recommendation is to adjust the solution measures to collect new data better aligned with enterprise goals i.e. the measures themselves may be found to be wanting.

A business analyst’s recommendations will be formulated as: -

Do Nothing – if the extra value is outweighed by the effort or if change is impossible.

Organisational Change – modification to the processes/people involved in the solution.

Reduce Complexity of Interfaces – improving the human to machine interface.

Eliminate Redundancy – removal of any duplicate activities/processes. Avoid Waste – remove any activities that don’t add value. Identify Additional Capabilities – find any opportunities to add value

through aspects of the solution that were not covered by original requirements.

Retire the Solution – replace the solution if necessary, after considering things like ongoing cost versus initial investment, the opportunity cost of keeping a defunct system going, obsolescence of a solution and the necessity of replacing it and “sunk cost” – the money and effort already committed to the initiative.

55 | P a g e

UNDERLYING COMPETENCIESBABOK describes the behaviours, characteristics and knowledge that support business analysis which, of course, retains a large amount of person to person interaction. The competencies are fairly self-explanatory so I won’t make extensive notes here but there are six: -

Analytical Thinking and Problem Solving

Behavioural Characteristics

Business Knowledge Communication Skills Interaction Skills Tools and Technology

Each competency is defined with a purpose, a definition and effectiveness measure.

COMPETENCY 1: Analytical Thinking and Problem SolvingThe ability to rapidly assimilate various types of information and choose what is relevant including how best to represent that information for different purposes. This competency includes:

1) Creative Thinking – ability to generate new and alternative solutions often by challenging assumptions.

2) Decision Making – understand the criteria for making a decision and making or facilitating others to make decisions (provide options, rationale, pros and cons etc.) including providing alternatives.

3) Learning – ability to acquire and process new information – particularly learning a new business domain and translating that knowledge into understanding of how to benefit an organisation.

4) Problem Solving – define the problem to be resolved and formulate solution(s) with an approach to determine the optimum solution.

5) Systems Thinking - how the people, processes and technology in an organisation interact to see problems in the context of an overall “system” – what's the overall mix of people, processes and tools which act together?

6) Conceptual Thinking – synthesise large amounts of information into a larger picture to tease out what is important, what is connected etc. Building a thought-model of the information to be handled.

7) Visual Thinking – create graphical representations of the information handled – usually involves some level of abstraction of that material. Visuals communicate better than straight prose text!

We can define measures for each of these areas to assess how well we perform for each aspect of analytical thinking and problem solving.

COMPETENCY 2: Behavioural CharacteristicsCorrect behaviour that earns trust and respect of stakeholders and facilitates elicitation. Includes:

56 | P a g e

1) Ethics – build good relations with stakeholders through correct behaviour and identify ethical issues.

2) Personal Accountability – complete tasks on time and take responsibility for work delivery.

3) Trustworthiness – build trust with stakeholders and engage with their needs, not their desires!

4) Organisation and Time Management – of the analyst’s own activities and those of others

5) Adaptability – adjust your style to the specific context and have the ability to change to rapidly changing environments or new material.

COMPETENCY 3: Business KnowledgeThe business acumen of the analyst relevant to the field in which they are working so that they have the baseline for understanding the stakeholder’s work. Includes:

1) Business Acumen – knowledge of fundamental business principles and best practices to ensure that they get “baked into” any future solutions.

2) Industry Knowledge – practices within an industry and across related industries.

3) Organisation Knowledge – understand the organisation in which we’re practicing our work – what is the chain of command, what's the influence and interest of stakeholders? etc.

4) Solution Knowledge – knowledge of existing internal solutions, environments and technologies.

5) Methodology Knowledge – of the methodologies used by the organisation, to understand the context, dependencies, opportunities and constraints of any business analysis approach.

COMPETENCY 4: Communication SkillsA crucial part of business analysis is communicating effectively, mindful of what your interlocuter does and does not know and to organise information in to a coherent and acceptable format. It includes:

1) Verbal Communication – express ideas that are appropriate to the target audience.

2) Non-Verbal Communication – body language and eye contact.3) Written Communication – adjust out language to different stakeholders.4) Listening – with an open and analytical mind.

Remember that with n people in the room there are n(n-1) / 2 direct interactions possible 😊

COMPETENCY 5: Interaction SkillsThe ability to interact meaningfully with a wide range of stakeholders, particularly to resolve disagreements, it includes:

1) Facilitation – assisting interaction between stakeholders

57 | P a g e

2) Leadership and Influencing – guiding stakeholders and building consensus in formal and informal leadership roles. Are you/is the organisation a Theory X (command and control) or Theory Y (collaborative) operator?

3) Teamwork – business analysis is almost always a team activity. Be able to work closely with others to facilitate moving work forward.

4) Negotiating and Conflict Resolution – remove/resolve blocking issues.5) Teaching – communicate business analysis ideas and techniques and

understand how people learn/different learning styles.

COMPETENCY 6: Tools & TechnologyFamiliarity with tools and techniques for executing business analysis work, both tools to generate BA artefacts and tools for collaboration with stakeholders. Includes:

1) Office Productivity Tools and Technologies - including word processing, presentation and collaboration tools.

2) Business Analysis Tools and Technologies – such as modelling, diagramming, process modelling tools.

3) Communication Tools and Technologies – such as video conferencing, white board, idea sharing tools.

We can also think in terms of generalised tools (office productivity, word processing, spreadsheets, presentations etc.) and specialised tools (diagramming, modelling, requirements management tools etc.)

58 | P a g e

TECHNIQUESBABOK describes a whole set of techniques and tools that are of use to business analysts in their work and explains in detail how to use them. The list is non-exhaustive and will evolve over time as new techniques are added/older ones fall out of favour. BABOK has a list of about 50 non-exhaustive techniques.

You should be able to map tasks to techniques for the BABOK exams.

Here is a summary.

Technique DescriptionAcceptance & Evaluation Criteria

Set the minimum set of criteria that must be met in order for a solution to be acceptable to key stakeholders. BABOK makes a distinction between: -

Acceptance Criteria – single solution using tests, did it pass or fail.

Evaluation Criteria – choose between multiple solutions using measures. Measures give us a value ranking of the solutions.

Backlog Management Organise work items into a working “backlog” of tasks.

Balanced Scorecard Manage the performance of a business model, organisation structure or process by organising around four dimensions: - learning & growth, business process, customer and financial. Measures for these dimensions are created and reported regularly – in fact ideally linked to live data.

Objectives can be measured with either lagging indicators that measure actions already taken or leading indicators that provide information about future performance.

Benchmarking & Market Analysis

Compare organizational practices to best-in-class industry standards or competitors.

Brainstorming Rapid elicitation of ideas and foster innovative thinking. Evaluation criteria for the ideas that

59 | P a g e

arise should be set up front.Business Capability Assessment

Study what a business is able to do to achieve a goal. A capability map visualises abilities in terms of their business and customer value, their performance gap and risk.

Business Cases The justification for a course of action – it assesses a need and the alternative strategies to reach a desired outcome.

The alternatives are explored in terms of their scope, feasibility, assumptions risks and constraints and a financial analysis and value assessment. A business case must recommend a preferred solution.

Business Model Canvas A description of how an organisation creates, delivers and receives values for and from its customers. Organised around nine blocks: partnerships, activities, resources, value propositions (what customers are willing to exchange to have their needs met), customer relationships, channels, customer segments, cost structure and revenue streams.

Business Rules Analysis

Study the rules that shape day-to-day business behaviour and guide operational decision making.

Collaborative Games Shared “play” to achieve a common understanding of a problem or solution. Examples are “fishbowl” – observing others, “affinity map” – Sticky Notes on a wall etc. Imagine a team playing to build a box to come up with new packaging for their product – they mess around and align around the problem to solve, hidden assumptions etc.

Concept Modelling Organise business vocabulary to ensure consistent terminology. It relies on a Glossary.

For example, showing the terms from the glossary with the relations between them.

Data Dictionary Standardised list of data elements and their definitions (and allowable values).

60 | P a g e

Data Flow Diagrams Flowchart of the supplier and consumers of data and operations that transform it i.e. movement/transformation of data between states.

Data Mining Discover useful patterns and insights by analysing data.

Data Modelling Build entities, classes and data objects and their relationships to understand information organisation in a domain i.e. structure of data and its access.

Examples are UML class diagrams and entity relationship models with crow’s foot notation.

Business analysts usually worked on conceptual models rather than low-level database models (for example).

Decision Analysis Examine and model the different likely outcome to decisions in a scenario of high uncertainty. Uses weightings for alternate choices.

Decision Modelling Model how repeatable decisions are made such as an algorithm for deciding if a person is eligible for insurance based on age and gender.

Document Analysis Study available materials to elicit useful business analysis information or to understand the context of work.

Estimation Forecast the cost and effort involved in a given course of action. Potentially involving planning poker and assessing user story size with “story points” or some other arbitrary unit.

Financial Analysis Study the financial aspects of a given investment, solution or approach. Things like cost of change, total cost of ownership, cost-benefit approach.

Focus Groups Elicit business analysis information with a chosen group of participants, guided by a moderator.

Force Field Analysis A graphical method for depicting the forces that support or oppose a change by writing them down on either side of a line with an estimation of their force. Mentioned in the Glossary but not the Techniques section of BABOK v3.

61 | P a g e

Functional Decomposition

Break down a process, system, function or deliverables into smaller components in a tree diagram structure.

A bit like a work breakdown structure on a project, but for processes.

Glossary Document key terms related to a business domain. Gives a common understanding of terms to promote a shared language. So it’s useful to create this early on.

Interface Analysis Understand how, where, what, when, for whom information is shared across solution boundaries.

Interviews Systematic approach to elicitation via one on one structure or unstructured discussions.

Item Tracking Track and assign issues that pose an impact on the solution – so the use of Jira or ServiceNow for item logging and following (bugs, tasks etc.)

Lessons Learned Document issues from a previous project to improve performance for the next project.

Metrics & KPIs Measure the performance of some aspect of a solution.

Mind Mapping Organise thoughts and concepts into an interlinked chart.

62 | P a g e

Non-Functional Requirements Analysis

Criteria used to judge the operation of the system rather than the function of the system itself.

Observation View and understand activities in their context.Organisational Modelling

Understand the roles, responsibilities and reporting structure of an enterprise and how these align with goals.

Prioritisation Understand relative importance of business analysis information, maybe using MoSCoW categorisation (must have, should have, could have, won’t have).

Process Analysis Assess the efficiency and effectiveness of a business process and opportunities for improvement. Includes SIPOC from Six Sigma and Value Stream Mapping (VSM) from Lean methodologies. VSM shows those parts of a process that add value and those that are waste.

Process Modelling Graphical representation of the sequential flow of work (how work is carried out). This is the foundation for process analysis. It includes things like swim-lanes, activity diagrams, using UML or BPML standards etc.

Prototyping Create a model or design or requirements to elicit stakeholder feedback or optimise user experience or explore design options. Prototypes can be throwaway or evolutionary. A horizontal prototype is a shallow implementation across the system whereas a vertical one goes deep in one narrow area.

Reviews Evaluate the context of a work product – usually a team examines the product and comments on any corrections required. Called ‘structured walkthroughs” in BABOK v2.

Risk Analysis & Management

Identify area of uncertainty that could negatively affect value and develop ways to deal with those risks. Understanding an enterprise’s appetite for risk.

Risks might be recorded in a matrix which BABOK calls a risk register.

63 | P a g e

We handle risk by: - avoid, transfer, mitigate, accept or increase.

Roles & Permissions Matrix

Map coverage of activities by denoting responsibilities for execution.

Root Cause Analysis Find the underlying causes of a problem – to solve an issue at source rather than dealing with its effects. A fishbone (or Ishikawa) diagram is used with the ability to map causes back through primary, secondary, tertiary factors.

Scope Modelling Set the nature or one of more boundaries and place elements inside or outside those boundaries as in-scope or out-of-scope. Scope can be applied to control, need, solution or change. So, a Venn diagram, a picture or landscape picture such as the example below.

Sequence Diagrams Model the logic of usage scenarios by showing information passed between objects in the execution of a scenario – for example, sequence of web calls in a typical HTTP request.

Stakeholder List, Map or Personas

Assists in analysing stakeholders and their characteristics to make the best choices for engagement/elicitation. Includes techniques such as RACI diagrams, stakeholder matrix, onion diagram or the invention of fictional personas.

64 | P a g e

Stakeholder matrix rates our interlocuters in terms of their influence/power and impact/interest in the project.

State Modelling Describe and analyse all the different possible states of an entity within a system and how that entity changes from one state to another (what event triggers the change of state?) A state transition diagram can be used.

Survey or Questionnaire

Elicit business analysis information in a question and answer format using either open-ended or close-ended questions.

SWOT Analysis Consideration of strengths, weaknesses, opportunities and threats facing an organisation.

Use Cases and Scenarios

Describe how a person or system interacts with a solution to achieve a goal. Relationships between use cases can be modelled with either “extends” or “includes” logic.

Use cases focus on interaction, they are triggered by a primary actor and describe interactions with the solution and any secondary actors. Primary actors are on the left of use case diagrams and secondary actors are on the right.

65 | P a g e

Use cases have a name, a goal, list of actors, preconditions, triggers, post-conditions etc.

A use case diagram also shows the dependency between the use cases, which ones include others or extend others.

Extend is used when a use case conditionally adds steps to another first self-complete use case. So, it adds new flow building on the original use case.

Include is used to extract use case fragments that are duplicated in multiple use cases. Not called directly by an actor but just pulls out common activities for inclusion elsewhere.

User Stories Small, concise statement of functionality or quality needed to deliver value to a specific stakeholder. In my role as X, I need to achieve Y for the purpose of Z. User stories help us keep focussed on the value and should also include their acceptance criteria.

Vendor Assessment Assess ability of a vendor to meet commitments regarding delivery of products and services.

Workshops Bring stakeholders together to collaborate on achieving a pre-defined and agreed goal.

Often more efficient (cheaper) that separate individual interviews and you can get face-to-face immediate feedback.

Will be highly dependent on a good facilitator and the good experience of the attendees. We should keep attendee list small and focussed.

66 | P a g e

A now a deeper dive on the techniques.

67 | P a g e

Acceptance and Evaluation CriteriaAcceptance criteria are the requirements, outcomes or conditions that must be met for a solution to be considered acceptable to key stakeholders. They can give us the minimum set of requirements that must be met in order for a particular solution to be worth implementing (pass or fail) – usually used when assessing one solution.

Evaluation criteria are the measures used to assess a set of requirements and/or designs to choose between multiple solutions and can therefore be used to rank solutions according to their value to stakeholders. We can rank based on cost, usability, performance etc. For any aspect that can’t be measured and quantified we might rely on expert judgement.

Acceptance criteria and evaluation criteria may be defined using the same attributes such as cost or performance. We call these value attributes – aspects that break down the whole value of a solution into its constituent parts to describe the value to the stakeholders (performance, responsiveness, ability to provide certain info, security, usability etc. whatever is of value).

So, this gives us – for one solution: -

Requirement PASS or FAIL

And for multiple solutions: -

Solution Value Ranking

Because we need to test the single solution, acceptance criteria must be in a testable form to give a clear pass or fail.

Evaluation criteria may use a discrete or continuous scale to fix a quantitative or qualitative value to each measure and develop a ranking.

Acceptance criteria are necessary when there is contractual obligation.

Backlog ManagementBacklog management is used when the number of items to be worked upon exceeds out capacity. It asks us to record and rank the items so that those with the highest business value/priority appear at the top and will usually be selected to be worked upon next.

Backlogs should be reviewed regularly as stakeholder’s needs are usually evolving and the number of items in the backlog over time ay indicate a trend (is it increasing or decreasing?)

Separate backlogs may be used to manage different aspects – one for the whole solution and one for the next sprint (for example).

68 | P a g e

Acceptance Criteria

Value Attributes

Define Requirements

Minimum requirement set

Test

Conduct UAT

Evaluation Criteria

Value Attributes

Define Measures

Criteria used to assess value

Measure

Different solutions

A backlog item can be any item that has work associated with it, so in addition to requirements it might be designs, user stories, risk items, change requests etc.

Backlog items are prioritised relative to one another and this can happen in multiple phases starting with a broad approach (high, medium, low) and continuing with a more detailed ranking.

The detail about a backlog item will evolve over time, it may start out as very vague and then become more detailed. Minimal work is done on items in the backlog – just enough to be able to understand and accurately estimate them.

New items are added to a backlog in the same way, by prioritising them relative to all others already in the backlog. Items are removed when they are complete or when there is agreement to remove them.

Balanced ScorecardA balanced scorecard is used to manage performance in any business model, organisation or business process by going beyond the traditional financial measures to give a “balanced view” based on business objectives and measures.

It is based on the assumption that the underlying drivers of value creation are understood, measured and already optimised and it then maps the business in four dimensions: -

Scorecards can be used at any level of an organisation and place specific measures and targeted outcomes across these four dimensions.

The balanced scorecard must be rooted in the vision and strategy of the organisation. We break down where we want to go in the four dimensions and then come up with measures for those dimensions such as: -

Learning and Growtho Measures of employee training and learningo Measures of product and service innovationo Measures corporate culture

Business Processo Measures of how well the enterprise is operating

Customero Measures of customer satisfactiono Measures of customer experience

Financialo Measures of profitability

69 | P a g e

Learning & Growth

Business Process Customer Financial

o Measures of revenue growth

Two types of indicators – lagging indicators (information about actions already taken) and leading indicators (actions about future performance).

Of course, to be useful, the measures chosen on a balanced scorecard must be quantitative, linked to strategy and understandable by all stakeholders.

A balanced scorecard allows an organisation to measure progress towards objectives using the four dimensions and adapt strategy as needed.

Benchmarking & Market AnalysisBenchmarking compares organisation practice to best-in-class practices. This may be done against competitors and industry associations or against regulations to measure compliance. It gathers data to make organisation changes.

Market analysis conducts research to determine products and services or future value and typically involves customers. It gathers data to support business decision making to enter, change or leave a market.

Benchmarking is about comparing best practice on existing solutions that have worked elsewhere and market analysis is typically about researching a market. Both approaches are time-consuming and expensive however.

BrainstormingFoster numerous creative ideas quickly and derive themes for further analysis around a chosen topic or problem facing a business. The spirit is to look at the issue in new ways and to freely associate to elicit as many ideas as possible. It is best conducted as a group activity to allow individuals to build on one another’s ideas.

Evaluation criteria should be established up front and used to rate the ideas generated at the end.

The three phases in BABOK for Brainstorming are preparation, session and wrap-up.

Business Capability AnalysisThis technique describes what an enterprise, or a part of an enterprise can do – what can they create or transform to achieve a business goal or objective.

Capabilities may be assessed by performance measurements and risks to highlight gaps which would help prioritise investment.

A capability only appears once even if it is performed by multiple departments and a capability describes the purpose or outcome of the performance NOT how it is done. Some capabilities may be about revenue generation, some about reducing cost, improving service etc. Not all capabilities will have the same value to the business.

70 | P a g e

Capabilities can be measured against performance expectations to see if a gap exists.

On their own, a capability dos not have a risk but the execution of that capability carries risk. Risks are categorised by BOTM: -

Business Risk Technology Risk Organisational Risk Market Risk

Business capabilities for the present and future states help set a business strategy and product roadmap.

Business capability analysis can be visualised as a capability map.

Business CasesA business case provides a justification for a particular course of action based on benefits to be realised as opposed to the cost. It can be a formal document or much more informal and the amount of effort invested should be proportional to the business value it hopes to achieve.

It is used to: -

Define the need Determine the desired outcome Assess alternatives including

o scopeo feasibilityo assumptions, risks and constraintso financial analysis and value assessment

Recommend a solution

It needs to contain sufficient details that an approval can be decided but doesn’t need to go into implementation details.

The need must be clearly stated and in line with a given strategy or business objective. The desired outcome must describe the future state with measurable outcomes which will be used to judge the success of the business case.

The assessment of alternatives lays out the scope of each option, whether there is feasibility in terms of business capability, knowledge, skill, tech maturity etc. and all of the assumptions, risks and constraints which feed into our full understanding of that alternative. An analysis of the costs and benefits of each alternative must be present.

The final recommended solution must include is justification and provide sufficient detail (often financial) for confidence to be gained in the decision.

Ideally business cases are revisited during the life of an initiative to ensure we stay aligned to the original intent but often they are not - they are used for

71 | P a g e

approval and then neglected.

Business Model CanvasA business model canvas depicts how an enterprise creates, delivers and captures value for and from its customers by laying out its activities across nine “building blocks”: -

Key Partnerships Key Activities Key Resources Value Proposition Customer Relationships

Channels Customer Segments Cost Structure Revenue Streams

The canvas can be used as: -

1. Diagnostic tool – see the amount of time and energy that is invested in each area of the business an the relationship between areas to describe the current state.

2. Planning tool – help set strategy and initiatives based on the current state.

Key partnerships is about where an enterprise partners to reduce risk and acquire capability that it might not have, concentrating on the value to customers.

Key activities are the things being done to create value and include: -

Value-add – things that the customer is willing to pay for Non-value-add - things that the customer is not willing to pay for Business-non-value-add – things that must be delivered due to

regulatory or other constraints but which the customer is not willing to pay

Key resources are the things that we need to create value and include resources which are physical, financial, intellectual and human!

The value proposition is what a customer is willing to exchange to have their needs met and may focus on a single product or service or a group, bundled together.

Customer relationships are expressed in terms of customer acquisition and customer retention and the methods used will vary widely between businesses.

Channels are the various ways in which an enterprise interacts and delivers value to a customer and may include marketing, product delivery or its partnership channel.

Customer segments explains how the enterprise groups together customers of similar attributes into categories.

The cost structure of the canvas explains where the costs of the enterprise are located and any efforts to reduce or eliminate cost.

72 | P a g e

Revenue streams describes the revenue coming in to an enterprise in exchange for the realisation of a value proposition. BABOK lists two basic ways that revenue is generated: - one-time or recurring purchase of goods or services.

Business Rules AnalysisBusiness rules describe the directives that control the activities and actions of an enterprise and the people within it. They must be practicable, specific and testable and are always set and kept under the control of the business so they are single-sourced.

They can be explicit (such as guidelines and regulatory standards) or can be more tacit (such as business know-how or cultural practice).

Business rules rely on an agreed business vocabulary and should be defined separate from any implementation tools and technology which make use of the rule.

Any exceptions should be treated as additional business rules.

BABOK defines two types of rules: -

1. Definitional Rules – extend some concept of the business by extending its definition such as “a customer is a preferred customer after 10 successful purchases”. Definitional rules can’t be violated but they can be misused. A set of definitional rules may link together to explain a chain of inference, for example “the tax rate is the sum of the annual income multiplied by the local tax rate minus the exemption (if relevant)”. Definitional rules therefore shape knowledge.

2. Behavioural Rules – rules that govern day to day “people” activities – even if that activity is automated – by placing an obligation or prohibition on an action or practice. Behavioural rules can be violated and there may be business-set penalties for doing so or other rules that come into force to mitigate non-compliance.

A behavioural rule without any active enforcement is a guideline.

Collaborative GamesJoint participation in an elicitation activity to encourage joint understanding of a problem or solution and interactions that might not occur through everyday “normal” interaction. Often a neutral facilitator guides the activity which proceeds by an opening step, an interaction step and a closing step.

BABOK gives some examples: -

Product Box – build a packaging to test usability and unrealised value. Affinity Map – write concepts on sticky notes and cluster them by similar

themes to find patterns. Fishbowl – one group speaks while the other listens and observes and

records to look for hidden assumptions.

73 | P a g e

Concept ModellingOrganise business vocabulary to consistently communicate domain knowledge. Concept models must start with a glossary and use rich business-specific vocabulary, independent of solutions and implementation. They differ from data models in that they are not trying to simplify and unify data concepts but to capture subtle and often highly business-technical language.

They start with a glossary (which is a bunch of nouns) but differ from it by adding verbs to describe relationships between the nouns. This fact is critical to understanding the concept model: -

Noun Concept – a noun and its definition. Verb Concept – structural connections between noun concepts. Other connections – since the aim is language-rich description of a

business domain, other aspects such as categorisation, classification, partitive (whole-part) connections and rolees may feature in a concept model.

They are a « business friendly » tool as they speak the same language as business stakeholders.

Data DictionaryA standard definition of data elements to ensure common interpretation including allowable values of each element. In addition to individual primitive data elements, a dictionary can store composite elements explaining how elements are concatenated/repeated to form a new data definition.

Sometimes called a metadata repository.

Elements are often defined by their Name, Alias, Values/Meaning (list of allowable values, minimum characters etc.) and a Description.

It’s a good tool for getting consistency and agreement on data but you have to ensure input from multiple stakeholders so that the dictionary is not too narrowly focussed (only one department’s definitions, for example). A dictionary also takes a lot of effort to maintain.

Data Flow DiagramA visual description of where data comes from, what processes act upon it and where it goes – including feeding to another process or going to/from a data store (also called a terminator). Critically it deals with movement of data to/from external entities and processes and these should appear on the diagram.

BABOK speaks about the different levels of diagram: -

Level 0 – the Context DiagramThe highest level diagram in which the data process is a single, central block and all external agents are shown.

74 | P a g e

Level 1…X DiagramsThe single, central process is broken down to show individual data sub-processes and how they interact, passing a noun-named data element between them, as specified in the data dictionary. We can continue to decompose to the level of detail needed.

BABOK also makes a distinction between: -

Physical Data Models – data stores, printers, devices and other physical manifestations of data.

Logical Data Models – future or essential state of data regardless of the physical constraints.

We can draw these diagrams with either Gane-Sarson or Yourdon notation.

The things we find on a data flow diagram are: -

External (Entity, Source, Sink) - A rectangular box showing an element outside the system with at least one arrow going to or from and named with a noun.

Data Store – Two parallel lines or an open rectangle representing a data repository.

Process – A transformation of data with a verb + noun label and at least one input ad one output.

Data Flow – A noun-named unidirectional flow of data transforming an output into an he input.

Data Flow diagrams can be a discovery technique or a validation for functional decomposition or data models. They do however lack any sequence and timing information.

Data MiningAnalysis of existing data to look for patterns useful to the business. We can perform this in a supervised mode, where we ask questions and make decision on the responses i.e. we know what we’re looking for or unsupervised where we’re purely looking for patterns and don’t know what we’re going to find/what question we’re asking.

BABOK lists three techniques within data mining: -

1. Descriptive – such as clustering data, analysing based on descriptions.2. Diagnostic – such as decision trees or segmentation, discover why

patterns exist.3. Predictive – regressions or neural networks to try to predict future states.

Having the right type and volume of data is critical to this exercise which is usually time intensive.

75 | P a g e

Mining can also be top-down (start with a business decision to make) or bottom-up (start with a specific functional area to get domain-specific analysis).

Typically, we split the data into three groups – a set for performing the analysis and formulating a model/conclusions, a set to confirm our model/conclusions against and a final validation data set.

Modelling techniques include classification and regression trees (CART), C5 decision trees, linear and logistic regression, neural networks etc.

The results from data models need to be deployed to be useful – often they lead to new business rules.

Data ModellingDescribe the entities, classes or data objects relevant to a business domain along with their attributes and relationships. There are a few variations: -

Conceptual Data Model – independent of any solution or implementation, describes how the business see their information.

Logical Data Model – apply normalisation to the conceptual model to begin to design the integrity of data.

Physical Data Model – how a database is actually implemented.

Object diagrams can be created to show specific instances of data from other models and display sample data to make the diagram easier to understand.

Models are made up of: -

1. Entity or class (when appearing on a class diagram which also lists functions)

2. Attribute (allowable values are specified through business rules). Attributes have: -

a. Nameb. Value/Meaningc. Description

3. Relationships

Note that alias does not appear here, it is listed under the Data Dictionary.

When we draw Entity Relationship Diagrams or Class Diagrams we can use Crow’s Foot notation or the UML notation.

Data models can optionally included Meta Data to provide extra information about the entities.

Decision AnalysisFormally assess a problem and the options to determine potential value under conditions of uncertainty, often in a complex situation. The measure of value may vary depending on the situation but financial value, scoring or relative ranking may be used.

76 | P a g e

The steps in decision analysis are to define the problem statement, define alternatives available, evaluate the alternatives, chose the one to implement and then go ahead and implement it.

So, this will involve a problem statement or decision to be made, a decision maker, the alternatives and the decision criteria as core elements.

BABOK goes into detail of two elements: -

1. Decision Matrix – a simple table in which we score one point for each criterion met in each alternate or we can use the same approach with a weighted scoring.

2. Decision Tree – draw out decision nodes, chance nodes and terminator nodes showing the routes to a decision.

When multiple, sometimes competing objectives, are relevant then trade-offs must occur as we can’t simply choose the option that maximises one variable. Techniques for trade-off include:

Elimination of dominated alternatives – get rid of the alternatives which are clearly inferior and “dominated” by their more attractive siblings.

Ranking objectives on a similar scale – attempt to rank all alternatives on the same scale from 0 for worst to best for 100 and see if consensus emerges.

Decision ModellingShow how repeatable business decisions are made by studying and modelling that decision.

So, a decision model would include how data and knowledge are combined to make the decision, what business rules (both definitional and behavioural) are used etc.

Decision tables and decision trees can be used to diagram the decision model but whatever model there are three key elements: -

Decision, Information and Knowledge

A decision table looks a bit like a decision matrix but don’t confuse the two. In the decision table, the columns list the different attributes of making the decision and we then map out the combinations of data and the outcome in the rows so my wife might apply the following when deciding whether to cook me dinner when I come home from work: -

Will Mrs Kev cook me dinner tonight?

Mrs Kev Mood Did I bring a gift home? Dinner Decision

Good Yes Yes

No Yes

77 | P a g e

Bad Yes Yes

No No

We could show the same decision path as a tree with each node being the column heading and the paths between nodes the row options.

A decision requirements diagram is a way of showing a complex network of knowledge, information and decisions to show how they inter-relate/must combine to make a decision possible. In this diagram solid lines show combination of knowledge and information and dotted lines show the “authority requirement” to indicate an authority to make a decision. In this model, rectangles with the corners cut off show Business Knowledge Models to indicate a lower-level decision table, decision tree, predictive model etc. that is involved.

Decision models can simplify discussion with stakeholders as they remove business rules from the picture and concentrate on the decision process.

Document AnalysisThe technique involves examining existing material that describes the business environment or organisational assets to elicit new business analysis information. So, although it covers background reading it might also mean examining an existing solution or industry guidelines.

It is particularly useful when original SMEs for an existing solution are no longer present.

Analysts should choose material that is relevant, current, genuine and credible and potentially use an information management tool to capture the data obtained. Data mining is a type of document analysis.

EstimationForecast the cost and effort involved in pursuing a course of action.

Forecasting often gives a single figure or a minimum and maximum value (a confidence interval) to specify the range into which we think the value will fall.

Methods for estimation include: -

Top-down – examine components from the top of a hierarchy breakdown Bottom-up – examine components from the lowest level in a hierarchy

breakdown and sum across all low-level estimates Parametric – use of a parametric model, usually a model developed from

the organisation’s own history of work Rough Order of Magnitude – high level estimate based on limited data

with large confidence interval. Rolling Wave – repeated estimates through a project for near-term

activities.

78 | P a g e

Delphi – a combination of expert judgement and history. Bring together individual estimates and discuss to reach consensus using three estimates as a minimum.

PERT – give each component of the estimate three values – optimistic value, pessimistic value and most-likely value and calculate

((optimistic + pessimistic + (4 * most likely))/6

The accuracy of an estimate can be determined later by comparing actual to estimated value as a percentage or a ratio of the confidence interval to its mean value.

Common sources of information for estimates include analogous situations, organisational history and expert judgement.

When multiple estimates for the same thing exist, we can compare them to calculate the precision of the estimate (how varied is it?) We can also speak about the reliability of an estimate when we consider its repeatability when calculated using different methods.

Estimation is usually more accurate when done in a team and an organisation may even ask for independent, external validation of their estimate if it is critical.

Financial AnalysisDetermine the financial aspects of an investment, solution or solution approach to determine financial viability, stability and benefits realisation of an investment option.

Financial analysis should be on-going throughout any initiative to ensure that the predicted benefits are still likely, and that the opportunity continues to be worth pursuing.

Analysis might include: -

Initial cost and the time frame during which costs are incurred. Financial benefits and the time frame during which they will be accrued Ongoing costs of using and supporting a solution Risks associated including on-going risks

The key elements are: -

1. Cost of the Change – cost of acquiring the solution and adapting the enterprise to using it

2. Total Cost of Ownership – cost of acquiring, operating and supporting the solution

3. Value Realisation – value accrued over time4. Cost-Benefit Analysis – total benefits minus total cost to yield net

benefit which is the planned business value.

79 | P a g e

5. Return on Investment – the net benefit divided by the cost of the change. So that is: -

(Total Benefits – Total Costs) / Total Costs

6. Discount Rate – a presumed interest rate that represents what the organisation would earn if the money was invested elsewhere.

7. Present Value – since solutions pay off at different rates, bringing them back to a present-day value is often useful for comparison. It is expressed in a currency and the formula is: -

Sum of Net Benefits in a Given Period / (1 + Discount Rate for the Period)

8. Net Present Value – calculate present value and minus the original cost.9. Internal Rate of Return – the investment rate at which an investment

breaks even. It is often compared to a reference interest rate set by the business (called the hurdle rate) to decide if the investment is worthwhile.

10.Payback Period – the period to return a positive financial contribution to the enterprise ignoring discount rate. Calculated differently for different organisations,

Focus GroupElicit impressions and opinions about a specific product, service or opportunity in a group as guided by a moderator. It is a form therefore or qualitative research.

Clear objectives are needed for the group and the activity should be planned with a focus group plan that includes the purpose, location, logistics, participants, budget, timelines and outcome are all well-defined.

Results should be recorded soon after and analysed for trends.

Functional DecompositionManage complexity and reduce uncertainty by breaking down processes, systems, functional areas or deliverables into constituent parts for individual analysis.

So, it's a pretty broad term and the guide suggests that the decomposition objectives closely guide what we decompose and how (are we trying to measure a system better by measuring the individual components or looking for elements for reuse?)

BABOK suggests that we can apply decomposition to: -

Business Outcomes Work to be Done (work

breakdown structure) Business Process Function

Business Unit Solution Component Activity Products and Services Decisions

The business analyst decomposes the problem only to the level required.

80 | P a g e

GlossaryDefinition of key terms relevant to a business domain and their synonyms. A glossary should be created early in an endeavour and be kept up to date.

Interface AnalysisIdentify how information flows between system components or across system boundaries.

An analyst may employ other techniques first to decide what interfaces to study and then must ask questions like what functions the interface provides, how often it is used, wat inputs and outputs are handled and the rules governing the data that they provide etc.

InterviewsA systematic approach to elicit business analysis information from an individual or group which can also build trust between the participants or increase involvement and support for an initiative.

Two types: -

Structured Interview – pre-defined set of questions. Unstructured Interview – more freestyle.

Goals for each interview should be clearly defined and communicated to the interviewee.

Open-ended questions are used to elicit a discussion and follow-up questions, they cannot be answered with a single “yes” or “no” or a number.

Close-ended questions are answered in a brief definite response, “yes”, “no” etc.

Standardised questions may be used when results from multiple interviews will be brought together.

Questions for the interview may be sent in advance when the interviewee needs to gather material or prepare responses.

Item TrackingCapture and assign responsibility for issues and stakeholder concerns that pose an impact on a solution. A tool can be used and potentially shared with stakeholders to give them visibility on issue resolution.

An item can contain attributes like an identifier, summary, category, type, date identified, identified by whom, impact, priority, resolution date, owner, resolver, agreed strategy (accept, pursue, ignore, mitigate, avoid), status, resolution update, escalation matrix.

KPIs for the item tracking process can be developed.

81 | P a g e

Lessons LearnedCompile and document successes, opportunities for improvement, failures and recommendations for the future. Also called a retrospective in Agile terminology.

KPIs and IndicatorsMeasure the performance of solutions, solution components or anything else of interest to stakeholders.

An indicator is a measurement that represents progress towards a goal. A metric is a quantifiable level of an indicator that is measured at a single

point in time. A KPI measures progress towards a strategic goal.

A good indicator should be: -

1. Clear2. Relevant3. Economical

4. Adequate5. Quantifiable6. Trustworthy and Credible

If direct data s not available for an indicator then a proxy may be used such as percentage of contracts renewed standing in for client satisfaction.

A metric can be a specific data point, a threshold or a range and we can set target metrics for values that we wish to achieve.

We’ll need a good structure and set-up for regular quality data collection for indicators and use three factors to assess the quality of indicators and metrics; reliability, validity and timeliness.

Mind MappingArticulate and capture thoughts and ideas.

There is no standard format but a central key topic or idea with branching and linked sub-topics/linked-ideas helps explore the issue under consideration as either an individual or group exercise.

Non-Functional Requirements AnalysisBABOK calls this out as a specific technique; using non-functional requirements to judge the performance of a solution.

Non-functional requirements are sometimes called quality attributes of quality of service requirements.

BABOK lists a long set of common categories such as availability, compatibility, functionality (accuracy, suitability), maintainability etc.

Non-functional requirements should be expressed in quantifiable terms where possible to allow developers to create them correctly in a testable way.

82 | P a g e

The context of non-functional requirements is important – constraints posed by one suet (such as regulatory or security requirements) may degrade others (such as speed).

Observation“Job shadowing” a person at work to record their actions and understand activities in context. The observation can be: -

Active/Noticeable – you are allowed to interrupt to ask questions. Passive/Unnoticeable – you save question to the end to save disrupting

the observation.

The objective of the observation should always be clear and explained and you need to get permission to observe. You should also reassure the participant that their performance is not being judged.

Organisational ModellingDescribe the roles, responsibilities and reporting structures that exist within an organisation to better align those with the organisation’s goals.

There’s several ways that organisations structure themselves: -

Functionally oriented – group staff based on shared skills or expertise so finance department. This helps cost management and avoid duplication but can lead to “silos”.

Market oriented – group by a particular customer segment, geography, project or process to align with the market served. So the “European Team” – work can get duplicated and inconsistencies can arise for the same function in different areas.

Matrix Model – separate managers per functional area and for each product service or customer group so that you end up with a 2D table with line managers for the functional stuff and project, process and product managers for the segmented stuff. Each individual has two managers therefore. Accountability is difficult to maintain in this situation.

Organisations also define themselves in terms of job roles of their people and the interfaces between organisational units.

Organisations are depicted by an org chart but there is not strict standard for this type of diagram.

Org charts are a good way for a business analyst to understand an organisation and the influences and lines of authority which link people together.

PrioritisationA framework to help facilitate stakeholder decisions and understand the relative importance of business analysis information.

To prioritise BA’s must determine the best approach based on value, risk, difficulty of implementation etc. and then select an approach. BABOK

83 | P a g e

categorises four approaches: -

Grouping – classify business analysis information based on a pre-defined category such as high, medium or low.

Ranking – organise business analysis information from least to most important

Time Boxing/Budgeting – when a fixed amount of time or money has been set, rank requirements on what we are able to achieve within those constraints. Used often when development is underway with immovable deadlines.

Negotiation – discuss and achieve consensus among stakeholders on the priorities.

Process AnalysisAssess the effectiveness and efficiency of a process as well as opportunities for change.

Process analysis therefore has value when looking at making processes more efficient, comparing current and future states for gaps, understanding what goes in to contract negotiation, how data and information is used etc!

Various frameworks such as Six Sigma and Lean exist but the core work is to find gaps and recommend improvements, identify root causes of process problems and generate and evaluate options for changing and improving.

Common methods include: -

SIPOC – Supplier, Input, Process, Output and Customer – a technique taken from Six Sigma.

Value Stream Mapping – from Lean methodology diagram the time involved in waiting for inputs and converting those inputs to output to come up with an overall timeline of value-added time and non-value added (dead) time.

Process ModellingA set of standard graphical diagrams for showing how work is carried out and a foundation for process analysis. It maps the sequential flow of work or activities.

Business process model – flow of work across defined tasks and activities in an enterprise.

System process model – flow of control among units in a computer system.

Program process model – flow of execution of statements in a computer program

Process models can look at existing situations or current and future to understand needed change.

BABOK lists the following types of types of notation: -

84 | P a g e

1. Flowcharts and Value Stream Mapping – used in the business domain and mentioned in the previous section.

2. Data Flow Diagrams and UML – IT diagrams of information flow.3. Business Process Model and Notation (BPMN) – industry standard

notation.4. Integrated DEFinition (IDEF) and Input, Guide, Output, Enabler

(IGOE) Diagrams – helps establish scope.

Process models usually contain these elements: -

Activity - a piece of work/a task. Event – a zero-time occurrence which initiates, interrupts or terminates an

activity. Directional Flow – a indication of the sequence of the diagram. Decision Point – a mutually exclusive split in the path. Link – a connection to other process maps. Role -a person involved in the process.

Three examples of process models are given in the BABOK guide:

Flowchart, BPMN and Activity Diagram.

Flowcharts are good for non-technical audiences and can include swimlanes of roles.

BPMN is an industry standard and very flexible (it can be input to business automation technologies). It uses pools and swimlanes, a pool is a free-standing, self-regulating business entity or system. So examples of pools would be the organisation and the customer. Decision points use + and x to indicate merge and split.

Activity diagrams from UML are similar to flowcharts but use bars to show parallel processing and can have multiple exit points.

PrototypingElicit and validate stakeholder needs through an iterative process that creates a model or design of requirements. Also used to evaluate design options and optimise user experience.

We think of prototypes as mocking up an interface or creating a mock product but business rules and data prototypes can also be used to discover flows and help with data cleaning and transformation. Prototypes are more flexible.

BABOK lists tow approaches to prototyping: -

Throw-away – simple, cheap tools to create a prototype that is not maintained and used purely to elicit or validate requirements and designs – sketching out a high-level future process to tease out details might be one such prototype.

Evolutionary or Functional – extend initial requirements into a working solution as those requirements evolve, to grow into a working solution.

85 | P a g e

The following examples are given: -

1. Proof of Principle or Proof of Concept – validate the design of a system without modelling the appearance or anything else used in the final solution.

2. Form Study Prototype – explore the size, look and feel of a product to be manufactured.

3. Usability Prototype – a prototype to test how an end user interacts with a proposed solution.

4. Visual Prototype – test the visual aspects of the solution.5. Functional Prototype – test software functionality with simulated calls

and activities.

Common methods for prototyping include storyboarding, paper prototyping, workflow modelling and simulation.

ReviewsEvaluate the content of a work product.

Reviews make use of three dimensions; objectives (purpose of review), technique (how will we review?) and participants (who will be involved?)

Reviews are focussed on the work product and not the skills or actions of the participants. Objectives must be clear and then techniques include: -

Inspection – formal technique with defined approach to remove defects and improve quality.

Formal Walkthrough (Team Review) – formal technique using individual review and team consolidation. Used for per reviews and stakeholder reviews when we need official review.

Single Issue Review (Technical Review) – formal technique focussing on one issue or standard possibly before a joint review.

Informal Walkthrough – informal run through to solicit feedback. Desk Check – informal verbal or written feedback on someone not involved

in the creation of the work product. Pass Around – informal written or verbal review by multiple people. Ad-Hoc – informal review or assistance from a peer.

Participants for the activity will depend on the technique chosen/level of formality. An author and reviewer will be involved in all techniques and a facilitator and scribe in thee more formal ones.

Risk Analysis and ManagementDefine areas of uncertainty that could negatively affect value and perform analysis and a way to manage the risks.

Risks arise through a combination of expert judgement, stakeholder input, experience, historical analysis etc. Risks can be recorded on a risk register along with the plans for dealing with them.

86 | P a g e

We usually think about risk in terms of its probability of occurrence and impact. Impact should be assigned based on a risk impact scale to standardise the evaluation.

Level of risk is usually calculated as: probability * impact.

BABOK suggested the following responses to a risk: -

Avoid Transfer

Mitigate Accept

Increase

And we should develop a risk response plan when the approach has been decided and assigned to a risk owner. As the plan is put into action, if the risk it not reduced to nil then a residual risk remains and requires reassessment.

Role & Permission MatrixEnsure coverage of activities by denoting responsibility, to identify roles, discover missing roles and communicate results of planned changes.

So image a matrix mapping a set of activities (create new account, create order) with the roles that can perform them.

A business analyst may have to review organisational models, job descriptions, procedure manuals and user guides to tease out all roles involved. They may also need to meet with stakeholders.

Interactions with processes and systems and tasks may be described in a RACI matrix or in CRUD descriptions in IT.

The authority of roles is discovered in this technique also and this is important for business analysis work as it may explain who can delegate authority and any inheritance of authority down through organisation structures.

Root Cause AnalysisDiscover the underlying causes of a problem.

It is a systematic approach to hunt down the cause(s) of a problem, using an iterative analytical approach. It can be used for:

Reactive Analysis – identify the root cause for corrective action Proactive Analysis – identify potential problems for preventative action

There are four main activities for root cause analysis – problem statement definition, data collection, cause identification and action identification.

A Fishbone (or Ishikawa or cause-and-effect) diagram and quickly explores possible ideas of the source of a problem.

Another technique is the 5 Whys which writes up the problem, asks “why did it happen?” and asks more whys to drill deeper – you typically need 5!

87 | P a g e

Scope ModellingDefine the nature of limits and boundaries and organise elements inside or outside of those boundaries.

We can look at these models in-scope (as seen from inside a boundary) or out-scope (as seen from outside a boundary) or both.

Scope models are used to define the boundaries in: -

Scope of Control – what is being analysed, roles and responsibilities and what is internal and external to an organisation.

Scope of Need – stakeholder needs, value to be delivered, functional areas and organisational units to be explored.

Scope of Solution – requirements met, value delivered, impact of change

Scope of Change – action to be taken, stakeholders affected and events to cause or prevent change.

In this spirit scope models usually clarify: -

1. What is the span of control?2. What is thee relevance of elements (are they in or out of scope?)3. Where should effort be applied (we don’t work on out of scope).

Scope modelling also helps us decide the level of detail to which we’ll need to perform business analysis work.

It can also tease out relationships between scope elements with various diagramming techniques such as parent-child, function-responsibility, supplier-consumer, cause-effect, emergent – when several elements interact to cause something to emerge.

At the time of scope modelling, the model is likely to rely heavily on assumptions such as definition of need, impact of changes etc.

Scope models can be the basis for contractual obligations, estimating project effort, justifying in/out scope decisions in requirements analysis and assessing completeness and impact of a solution.

Sequence DiagramsModel the logic of usage scenarios by showing information moving between objects in a system in a scenario.

Activity diagrams have a lifeline of an objects and show when it is “alive”. Unidirectional arrows show the movement of information to and from these objects and calls can be synchronous or asynchronous.

Stakeholder List, Map or PersonasA technique to help the business analyst in analysing stakeholders and their characteristics. Critical for ensuring that we have a complete set of

88 | P a g e

stakeholders and know exactly how to engage with them.

So, we’re thinking about things like level of authority, attitude and interest in the change being undertaken, attitude towards business analysis and decision-making power.

Lists of stakeholders can be developed in brainstorming and interviews.

Maps of stakeholders can be drawn up to show the relationship of the stakeholders to the solution such as a stakeholder matrix (map influence against interest in 4 quadrants) or onion diagram (how involved are the stakeholders with the solution?)

A RACI matrix is another way of defining relationships towards an activity. Remember that only one person/role can be accountable.

Personas are a useful tool in which we create a fictional character as an archetype of the user we are considering.

State ModellingModel all the states an entity can be in and how it changes between those states.

This technique is particularly good for complex behaviours and triggers to map out how things move from state to state.

The model acknowledges a finite list of states and that an entity can be in multiple states at the same time. Complex states can also be decomposed into sub-states! We also record the activities that can happen to the entity when it is in a given state.

Transitions between states are studied and understood to define their triggers and a state diagram may help us visualise the lifecycle of one entity. The same information can also go into a state table for simplicity at the start of an elicitation process.

Survey or QuestionnaireElicit business analysis information from a group of people in a structured way in a relatively short period of time using: -

Close-ended questions answered with yes, no or a number. Open-ended questions allowing more textual and unstructured answers.

The objective must be clear from the start and the target of the survey. We should be careful selecting the recipients to ensure that we have a representative spread of the stakeholders in which we are interested.

SWOT AnalysisA simple tool for mapping out the strengths, weaknesses, opportunities and threats of an organisation, business unit (even an individual).

89 | P a g e

Language should be brief, realistic and supported by evidence and we do the opportunities and threats first before moving on to the strengths and weaknesses.

Use Cases & ScenariosDescribe how a person interacts with the solution being modelled.

A use case described the interactions between a primary actor and a system and the involvement of any secondary actors but is focussed on the primary actor’s goal. They are written from the point of view of the actor and ignore the internal workings of the system. Use cases can document several ways to achieve the same goal and the exceptions that might prevent the goal being achieved.

A scenario describes just one way an actor can achieve a goal. A use case therefore describes many scenarios.

Use Case Diagrams show the relationship between one or more actors and the use cases supported by the solution, these relationships are called associations.

Relationships between the use cases themselves can be categorised as: -

Extends – adds on extra behaviour to an existing use case. The use case being extended must be complete.

Includes – allows a common use case to contribute its information to other use cases. Included use cases are do not need to be complete in which case they can’t be triggered by an actor.

We describe use cases by giving them: -

Name Goal Actors Precondition

Trigger Flow of Events Post-Condition or Guarantees

Post-conditions are things that will be true at the successful or failed outcome of a use case and are also called guarantees.

User StoriesA small concise statement of functionality or quality needed to deliver value.

Typically, a sentence or two - written from the point of view of a single stakeholder to express a need. They are given an optional title and must make a statement of value explaining the who, what and why.

“As a banking clerk, I need to be able to search for customers’ accounts by name to review their balance.”

The story is not a final product, further discussion and refinement based on it delivers the true value.

90 | P a g e

Acceptance criteria may be added to user stories, it’s a best practice.

In general, they are used for short-term capture and prioritisation of requirements and not long-term knowledge retention.

Vendor AssessmentAssess the ability of a vendor to meet commitments regarding delivery and provisions of a product or service. Non-functional requirements are one way to set service levels expected.

Assessments can be more formal and follow an RFI, RFQ, RFT or RFP process or more informal background checking and word of mouth recommendations.

We typical assess vendors based on their: -

Knowledge and Expertise Licensing and Pricing Models Vendor Market Position

Terms and Conditions Experience, Regulation and

Stability

Long-term satisfaction is more likely after a vendor assessment.

WorkshopsWorkshops bring stakeholders together to collaborate on a pre-defined goal.

Workshops are focussed events with key stakeholders and SMEs for a set period of time. We can generate new ideas at a workshop, use it to plan, reach consensus on a topic or review requirements and designs.

Workshops can also promote trust, mutual understanding and good communication. The facilitator can also take part of be a neutral player and a scribe can record decisions and outstanding issues. A BA can take part as participant, but this may confuse stakeholders.

BABOK lists the following workshops roles: -

Sponsor Facilitator Scribe

Timekeeper Participants

Workshops should proceed based on a greed ground rules.

91 | P a g e

PERSPECTIVESPerspectives are used within business analysis work to provide focus to tasks and techniques specific to the context of an initiative i.e. they are the different “approaches” in which we practice analysis work.

BABOK describes five different perspectives but these are not intended to be exhaustive, just a representation of the most common contexts in which we practice business analysis work: -

Agile Business Intelligence Information Technology Business Architecture Business Process Management

Any given initiative may combine one or more of these perspectives i.e. an Agile project that is looking at delivering a new information technology solution which has an impact on some business process change.

Perspectives provide a way to approach business analysis work in a more focussed manner and BABOK suggest a number of tasks that are pertinent to each type of perspective.

So, perspectives are about understanding and interpreting BABOK through the lens of the way we’re currently working.

PERSPECTIVE 1: AgilePracticing business analysis in an Agile environment is all about flexibility and respecting the processes of backlog creation, refining etc. Business analysts help Agile teams answer these questions: -

1) What needs are we trying to satisfy?2) Is that need worth satisfying?3) Should we deliver something to satisfy the need?4) What is the right thing to do to deliver that need?

So business analysis is present throughout the Agile lifecycle and relies heavily on interpersonal skills, facilitation and other collaborative team exercises. The business analyst acts as the proxy of the stakeholder and is responsible ultimately for the constantly evolving scope of the project.

Although Agile is most closely associated with IT projects, it can be applied elsewhere. Also remember that although Agile most agile approaches are iterative, not all iterative approaches are Agile.

Note also that although all Agile approaches acknowledge the business analysis role, it is only explicitly described in some of the approaches.

92 | P a g e

PERSPECTIVE 2: Business IntelligenceThis perspective highlights the unique role of the business analyst in the context of transforming, integrating and enhancing data. It’s about transforming data into information that adds value to an enterprise.

Business intelligence solutions typically rely on a single point of truth for data and analytical tools to transform/interpret the raw data as useful information.

The business analyst acts as interlocuter between business owners/stakeholder and solution delivery teams. For business intelligence, this will probably involve some aspect of data modelling and decision modelling to understand data structures and relationships and workflows.

PERSPECTIVE 3: Information TechnologyThis perspective concentrates on the business analyst’s role when the change relates to information technology systems – our traditional software (or hardware) projects.

The guide states again how “design” in IT context usually means technical design of a final solution, whereas the business analyst “design” is about solution designing (from a functional point of view) with stakeholders. When working on IT projects, BABOK acknowledges that business analysts may like to label their work as “requirements” only, to avoid confusion.

PERSPECTIVE 4: Business ArchitectureThis perspective focuses on the business analyst’s unique role when looking at business architecture, how we model an enterprise to identify opportunities for increasing value/support transformation.

The scope of this work is anything from the whole enterprise to a single functional division therefore with individual projects a component of this. It looks at: -

The information that the business uses. How the business is performed. Who does it and where in the enterprise it is done. When it is done. Why it is done. How well it is done!

Reference models exist for several industries to provide a baseline starting points for business architecture/organisation. For example, for an IT Service Management company we have ITIL.

PERSPECTIVE 5: Business Process ManagementWhen working to improve business processes, this perspective covers the business analyst’s work in detailing, analysing and recommending changes to the way a business executes its work.

93 | P a g e

Business Process Management (BPM) is a management discipline with a set of enabling technologies. BPM determines how manual and automatic processes are created, modified, cancelled and governed. Work can be top-down from the large-scale vision of management or bottom-up proceeding from individual low-level sub-processes to the processes of which they form a constituent part.

94 | P a g e

GLOSSARYBABOK v3 contains an extensive Glossary of terms and familiarity with these to ensure a consistent understanding and use of terminology is considered important. Many are straight-forward so I have listed the ones I think are more problematic and only if they are not already defined somewhere else in these notes such as in the Techniques section.

Adaptive approach – the solution evolves based on a lifecycle of learning and discovery.

Agile Extension to the BABOK – a special Agile-focussed extension of BABOK was published in 2013.

Artifact – any solution-relevant object created as part of business analysis effort.

Behavioural Business Rule – any business rule that place an obligation/constraint on conduct, action, practice or procedure.

Business Analysis Package – a collection of material presented together representing business analysis information.

Business Architecture – the design, structure and behaviour of the current and future states of an enterprise.

Business Goal – a state that an enterprise is striving to reach and maintain.

Business Objective – an objective, measurable result to indicate that a business goal has been achieved.

Business Rule – a specific, testable directive that guides behaviour, shapes how decisions are made.

Change Management – planned activities that address the human side of a change.

COTS – commercial, off the shelf product. Decision Analysis – an approach to decision making that models

possible consequences of different decisions. Definitional Business Rule – a rule that indicates that something is

necessarily true (or not true). Design – a usable representation of a solution. Domain – the sphere of knowledge that defines a set of common

requirements, terminology etc. Dynamics Systems Development Method (DSDM) – a project delivery

framework which focuses on fixing cost, quality and time at the beginning. Enterprise – one or more organisations and the solution they use. Enterprise Architecture – a description of the processes, information

technology, people, operations, information and projects of an enterprise and the relationships between them.

Enterprise Environment Factors (EEFs) - all policies, practices, procedures, and legislation that exist both inside and outside of the organization that will impact the way you manage a project.

Fishbone Diagram – a diagramming technique in root cause analysis.

95 | P a g e

Force Field Analysis – a graphical method for showing the forces that support and oppose a change.

Horizontal Prototype – a prototype that explores requirements at one level of a proposed solution such as the interface or data access layer.

Indicator – a numerical measurement indicating progress towards achieving an impact, output, activity, input.

Inspection – a formal review of work. Interface – a shared boundary between two persons and/or systems. Ishikawa Diagram – same as fishbone diagram. Metric – a quantifiable level of an indicator measured as a specified point

in time. Model – any representation and simplification of reality developed to

convey information to a specific audience. Non-Functional Requirement – a type of requirement that describes

the performance or quality attributes of a solution. OLAP – online analytical processing, a method that allows users to

analyse a large amount of data from different points of view. Organisation – a group of people under the management of a single

person or board that works towards a common goal/objective. Organisational Unit – a recognised association of people within an

organisation or enterprise. Predicative Approach – an approach whereby planning and baselines

are established early in the life cycle to maximise control and reduce risk. Process Model – a set of diagrams and supporting information about a

process and factors that influence the process. Product Backlog – a set of user stories, requirements or features

identified for possible implementation. Prototype – a partial or simulated approximation of a solution used for

eliciting or verifying requirements. Repository – a real or virtual facility where all information on a given

topic is stored. Requirement – a usable representation of a need. Requirements Architecture – the requirements of an initiative with the

inter-relationships between requirements. Requirements Defect – a problem or error in requirements. Requirements Management Plan – a subset of the Business Analysis

Plan for a specific initiative, describing how requirements will be handled. Requirements Model – an abstract (usually graphical) representation of

some aspect of the current or future state. Requirement Validation – work done to ensure that requirements are

within the solution scope. Requirement Verification – work done to ensure requirements are

defined correctly at a sufficient level of quality. Residual Risk – the risk remaining after some action has been taken. Scope – the boundaries of control, change, a solution or a need. Scope Model – a model that defined the boundaries of a business domain

or solution.

96 | P a g e

Stakeholder Proxy – the role a business analyst takes when representing the needs of a stakeholder.

State Diagram – an analysis model showing the life cycle of a data entity or class.

Stated Requirement – a requirement that has not been analysed, verified or validated.

Temporal Event – a time-based event that can trigger the initiation of a process, evaluation, or some other response.

User Story – a small, concise statement of functionality or quality need to deliver value to a specific stakeholder.

Validation – the process of checking that a deliverable is suitable for intended use.

Value Stream Mapping – a complete, fact-based sequence of activities require to deliver a product or service.

Verification - the process of checking that a deliverable is of suitable quality.

Vertical Prototype – a prototype that drills down through one slice of a proposed solution.

Viewpoint – a set of conventions that define how requirements will be represented and how these will be organised and inter-related.

Walkthrough – a review in which participants step through an artefact with the intention of validating requirements/designs.

Work Breakdown Structure – a hierarchical decomposition of work. Work Product – a document or collection of material used by the

business analyst during requirement development.

97 | P a g e

Exam Information / Preparation

There are 6 qualifications – ECBA (Entry Certificate), CCBA (Certification of Capability), CBAP (Practitioner), Agile for Business Analysis and Data Methods for Business Analysis. Each has qualification criteria in the sense of BA hours worked, career development hours and references.

Pass rates are not published but we believe it is 70 - 75%.

CCBA is 130 multiple choice questions with 1 correct answer. 3 hours and no penalties for wrong answers. CCBA is less scenario based and tests BABOK knowledge primarily. CBAP is 120 multiple choice questions and 3.5 hours and has a lot more scenario questions so involve lots of reading (1 to 1.5 pages of description) and a bit more time pressure.

For CBAP you are supposed to have 7,500 hours of experience (5 years – 1 month is about 120 active BA hours), 900 hours in four of the six knowledge areas (see below), 35 hours of training in the previous 4 years and 2 references from career manager or client.

Focus on knowledge areas and techniques, there are fewer questions on competencies.

Occasionally, the IIBA exam might throw in definitions or names from other methodologies so you do need to know the exact names from the BABOK guide.

Questions with generalisations (always, never, mostly etc.) are usually wrong since BABOK is not so prescriptive in its approach. There will be perhaps 20 – 30% synthesis and evaluation type questions on the exam which involve more in-depth analysis of what is being asked and inference. You might even get some formula-type questions which involve some number crunching.

A sample online test (many BABOK v2.0 questions however) of 150 questions can be found at: -

https://www.simplilearn.com/cbap-exam-prep-free-practice-test

A good guide to the exam as follows: -

https://businessanalystlearnings.com/blog/2013/4/18/a-guide-to-passing-your-cbap-exam

Quick aide-memoire on the reason for all tasks: -

Knowledge Area Task ReasonBusiness Analysis Planning & Monitoring

Plan Business Analysis Approach

Plan the work by creating and selecting the methodology and mapping out the tasks and deliverables.

Plan Stakeholder Engagement Understand stakeholders relevant to the work and the best way to engage them to

98 | P a g e

https://businessanalystlearnings.com/blog/2013/4/18/a-guide-to-passing-your-cbap-exam

https://www.simplilearn.com/cbap-exam-prep-free-practice-test

create a good working relationship.

Plan Business Analysis Governance

Describe how governance will work within business analysis work – how will decisions be made?

Plan Business Analysis Information Management

Define how information will be captured, stored, accessed and integrated.

Plan Business Analysis Performance Evaluation

Plan and execute how business analysis work be monitored and measured to promote continuous improvement?

Elicitation & Collaboration Prepare for Elicitation Ensure that all stakeholders are prepared and ready for elicitation.

Conduct Elicitation Execute the work to capture information about stakeholder needs.

Confirm Elicitation Results Ensure information is accurate and consistent with other information.

Communicate Business Analysis Information

Ensure that stakeholders have a shared understanding of the business analysis information.

Manage Stakeholder Collaboration

Work with stakeholders to involve them in the overall process to ensure the desired outcome by encouraging them to work to a common goal.

Requirement Lifecycle Management

Trace Requirements Analyse and maintain relationships between requirements for impact analysis, coverage and allocation.

Maintain Requirements Keep requirements and designs accurate and current and facilitate re-use.

Prioritise Requirements Assess value, urgency and risks associated with requirements to work on the most important ones first.

Assess Requirement Changes Assess new or changed requirements to see if they fall within scope.

Approve Requirements Get sign-off from stakeholders involved in the governance approach.

Strategy Evaluation Analyse Current State Understand why an enterprise needs to change, how it operates and what would be affected by that change.

Define Future State Determine a set of necessary conditions for the business to meet its needs.

Assess Risks Determine undesirable consequences while transitioning to or in the future state.

Define Change Strategy Develop and assess alternatives approaches to the change and recommend an approach.

Requirements Analysis & Specify and Model Analyse, synthesise and refine

99 | P a g e

Design Definition Requirements elicitation results into requirements and designs.

Verify Requirements Ensure that requirements and designs meet quality standards and are usable.

Validate Requirements Ensure all requirements are aligned to business requirements and support delivery of needed value.

Define Requirements Architecture

Ensure all requirements support one another and fully achieve the objectives.

Define Design Options Define the solution approach, allocate resources across the components.

Assess Potential Value and Recommend Solution

Estimate the potential value for each design option and establish which one best meets the enterprise’s needs.

Solution Evaluation Measure Solution Performance Define performance measures and use the data to assess the effectiveness of the solution.

Analyse Performance Measures

Provide insight into the performance of the solution compared to the value it brings.

Assess Solution Limitations Determine internal factors that may limit a solution.

Assess Enterprise Limitations Determine external factors that may limit a solution.

Recommend Actions to Increase Solution Value

Understand any gap between potential and actual value and recommend actions to align.

100 | P a g e

background · web view2020. 1. 7. · business model canvas67. business rules analysis68....

Documents