bcs business analysis diploma examination … · bcs business analysis diploma examination...

BCS Business Analysis Diploma Examination Preparation Workshop Delegate Manual

BCS Business Analysis Diploma Examination Preparation Workshop

Delegate Manual

BAORALSPW v3.1

2

Contents

How to use this workbook ........................................................................3 Introduction ..............................................................................................4 Module 1 – The Business Context ...........................................................9 Module 2 – Business Analysis Techniques .......................................... 24 Module 3 – Business Case Development ............................................. 43 Module 4 – Requirements ..................................................................... 62 Module 5 – Optional Modules ............................................................... 91

3

How to use this workbook

This workbook contains all of the slides you will see presented by your instructor.

There are also additional key points and notes under each section, indicated as follows:

Example questions are at the end of each syllabus section. Note that these are not exhaustive and are intended to provide a representative sample of questions to enhance your revision.

Introduction

4

Introduction

Welcome to the Business Analysis Diploma, Oral Examination Preparation Workshop.

This one day course will equip you with the information you need to prepare for the Oral Examination and help you to focus your revision.

Course Administration Before we begin the course, your instructor needs to take you through a number of administrative points as shown below.

Introduction

5

Workshop Objectives

Explain the format of the BCS Business Analysis Oral Examination

• The format of the interview

• How the Examiners complete their report (and what the report

looks like)

Review and prepare for the syllabus areas found in the BCS Business Analysis Oral Examination Syllabus

• We will review the main topics which will provide a focus for your

revision

• We will also provide you with samples of typical ‘Interview-style’

questions, encountered in the Oral Examination

Topics • Overview of the Orals Process

• The Business Context

• Business Analysis Techniques

• Business Case

• Requirements Definition

• Requirements Management

• Knowledge-based Specialism

• Practitioner Specialism

Introduction

6

Resources Along with your QA Course Materials, the following are recommended resources for the Diploma.

1. Business Analysis (2nd Edition), Paul, D., Yeates, D., Cadle, J. (BCS, July 2010)

2. Business Analysis Techniques, Cadle, J., Paul, D., Turner, P. (BCS, Feb 2010)

3. BCS Website: BCS International Diploma in Business Analysis, http://certifications.bcs.org/category/15705

After October 2014

1. Business Analysis (3rd edition), Paul, D., Yeates, D., Cadle, J. (BCS, Oct 2014)

Introduction

7

Diploma Structure

*Organisational Context is also accepted as a module in this

column.

Core Knowledge-based Specialism

Practitioner Specialism

Business Analysis Practice

Commercial Awareness *

Modelling Business Processes

Requirements Engineering

Foundation Certificate in IS Project Management

Systems Modelling Techniques

Foundation Certificate in Business Analysis

Systems Development Essentials

Foundation Certificate in Business Change

Benefits Management and Business Acceptance

Both of the above plus

1 of the above and 1 of the above

Introduction

8

Overview Reference Materials Booklet

The following notes and documents are in the book titled ‘Reference Materials:

• General Description of what to expect from the Orals Process

• There are also Candidate Guidelines

• You can find an example of the Oral Examination Report that the

Examiners will complete (BSD7)

• A list of Acronyms

• The Oral Examination has its own Syllabus

• Finally, there is some additional Self-Study material that you

will find useful as part of your revision.

Module 1: The Business Context

9

Module 1 – The Business Context

In this section of the workshop, we will cover part 1 of the syllabus, the Business Context.

1.1 The rationale for business analysis

1.2 Sectors of the economy

1.3 Business environment analysis

1.4 The legal and regulatory framework for business analysis

1.5 SWOT analysis

1.6 Business performance measurement

1.7 Business analysis within the lifecycle for business change


10

Lifecycle for Business Change (LCBC)

Be prepared to explain the different Stages that a change process may typically go through and why those Stages are desirable. The names of the Stages used above are the ones used in the Business Analysis Practice (BAP) syllabus, elaborated in the Foundation Certificate in Business Change (FCBC) syllabus.

Note that the Business Case should be updated at every Stage (i.e. these are Gateways).

Be prepared to explain the typical role of the Business Analyst in each stage and the involvement of the other roles mentioned in the syllabus:

• Project Manager

• Developer


11

• Tester

Stages 1-3 of the Lifecycle of Business Change

Alignment

• Ensuring the alignment of the organisation with external and

internal influences - basis for strategy and strategic goals

• Includes aligning IS/IT strategy with business goals

• Identifies change opportunities

Definition

• The analysis of business situations and the definition of the

programme of required business improvements

• Conduct of feasibility studies relating to the change opportunity

and the search for options

• Decision to invest in change (or not!)

• Project / Programme initiation

Design

• The design of the inter-related elements comprising the business

changes

These definitions above are based on those found in the FCBC syllabus.

Typically the BA role is not involved directly in the Alignment Stage (although Senior BAs may well be).

Best practice suggests that BAs should intervene early in the change process, beginning at the Definition Stage.


12

BAs continue their involvement with the changes in the Design Stage, especially as far as the IS/IT component is concerned.

Stages 4-5 of the Lifecycle of Business Change

Implementation

• Construction and testing of change products

• The deployment of the business changes, including the

stabilisation of Business as Usual (BaU)

Realisation

• The realisation and review of the predicted business benefits

• Monitoring benefits and reporting on lessons learnt

When it comes to Implementation, the BA is involved again in, for example, the testing of products, data conversion and dealing with issues.

Finally the BA may be required to provide input to the Benefits Realisation process, which may lead into further change completing the cycle.


13

Rationale for Business Analysis

• Business too ‘busy’ with Business as Usual (BaU)

• Dealing with stakeholders and the search for options takes time

and skill

• Holistic, objective approach desirable

o Challenge the status quo

o Consider the context and all the implications

• “Business-focused, IT-literate”

o Liaison with IT providers

o Champion for the sensible use of technology

o Creates a feasible IT solution

Taking into the ‘soft’ issues

Business benefit driven

What else ... ?

Be prepared to explain the rationale for business analysis in the context of the LCBC. Examples of typical questions:

• What benefit does the business get from employing BAs?

• What’s the downside of not having BAs?

• How would you describe the business problem that can be

solved by having BAs?

• How would you convince a sceptical Manager of the virtues of

using Business Analysts?


14

Sectors and Legislation

Sectors of the Economy

• Private, Public and Not-for-Profit

• Drivers for each sector

• Sources of finance for organisations in these sectors

Legislation affecting typical BA work

• Data Protection legislation, covering Personal Data

• Equality and anti-discrimination legislation; disability access

provisions

• Business Compliance (industry specific)

• The effect of this legislation on requirements

Details on the above can be found in the ‘’Reference Materials’ pre-course reading

Be prepared to explain what the different sectors of the economy are and what types of organisation are found within them. Also why this understanding is needed by BAs.

Be prepared to explain the relevance of some examples of legislation to the work of a Business Analyst – high-level, outline knowledge is required only.


15

Environment Analysis and SWOT


16

CSFs, KPIs and Performance Targets

• Areas where the organisation must succeed in order to achieve positive performance and meet objectives

• May be industry-wide or organisation specific

Critical Success Factors:

• The measure(s) to be applied to a CSF • Helps assess how well the organisation

addresses its CSFs

Key Performance Indicators:

• Defined targets for the KPIs that the organisation is currently aiming for

• Represent low level objectives for responsible areas of the business

Performance Targets


17

The Balanced Business Scorecard

• Ensures we consider more than just financial components of a

strategy – components are interlinked

• A framework for identifying and organising CSFs and KPIs

Balanced Business Scorecard is a method and a tool which includes:

• A strategy map where strategic objectives are placed over four

perspectives in order to clarify the strategy and the cause and

effect relationships that exists among them.

• Strategic objectives which are smaller parts of the strategy

interlinked by cause and effect relationships in the strategy map.


18

• Measures directly reflecting strategy. Their prime purpose is to

measure that the desired change or development defined by

strategic objectives actually takes place.

• Strategic initiatives that constitute the actual change as

described by strategic objectives.

The scorecard drives implementation of strategy using the four perspectives shown above.

Specific measures are chosen based upon the organisation's goals. Typically organisations "get what they measure" so care in creating measures and revisiting the measures regularly is recommended by most practitioners.

The method helps separate creation of strategy from strategy implementation, which can push power downwards while making the leaders' jobs easier. It can also help detect correlation between activities. For example, the process objective of implementing a new telephone system can help the customer objective of reducing response time to telephone calls, leading to increased sales from repeat business.

Companies are using the scorecard to:

• Clarify and update budgets

• Identify and align strategic initiatives

• Conduct periodic performance reviews to learn about and

improve strategy


19

Part 1: Typical Questions These examples are provided as illustrations only. Oral Examiners are experienced and knowledgeable consultants, chosen on an individual basis, who may ask any questions they feel appropriate, or adopt any style of questioning, within the confines of the syllabus and examining guidelines.

1.1 Rationale for Business Analysis

• Why is Business Analysis important?

• From where does the work for a Business Analyst originate?

• What problem does it address?

• What benefits does it bring?

• How would you sell it as a role?

• What negative consequences might there be in the absence of

properly conducted business analysis?

• What is meant when we speak of the ‘Lifecycle for Business

Change’ (LCBC)?

o Why is it termed a ‘cycle’?

o What stages are there? What is the focus of each stage?

• Where does the Business Analyst role fit into the Lifecycle of

Business Change?

• Describe the context for Business Analysis work

• Contrast the Business Analysis role with the Systems or

Technical Analyst roles

• Contrast the Business Analysis role with that of the Project

Manager

• Can you name me [3/4/5] deliverables that it is reasonable to

expect from a Business Analyst within this cycle?


20

• A famous Chief Information Officer once said “There’s no such

thing as an ‘IT Project’; only IT-enabled Business Change’”

what’s your view on that?

• Should Business Analysts sit within IT or in the Business?

• Is ‘Business-focused, IT-literate’ an adequate summary of

Business Analysis work?

• Is there a good case for outsourcing Business Analysis work?

1.2 Sectors of the economy

• Please describe the 3 main sectors of the economy

• Describe the motivation of organisations within these sectors

• Describe some of their financing options

• Normal sources of finance?

• Why is it important for the Business Analyst to have an

understanding of these topics?

1.3 Business Environment Analysis

• What’s meant when we talk of the ‘business domain’?

• What do you understand by the term ‘strategy’? What is a

strategy?

• How does strategy differ from tactics?

• How is strategy different from Mission?

• Why is it important for the Business Analyst to have a basic

knowledge of strategy?

• Is the Business Analyst involved in setting strategic direction and

if not whose responsibility is that?

• Do you know of a technique for analysing the organisation’s

external environment?


21

o Explain the technique

• Do you know of a technique for analysing the organisation’s

internal environment and capability?


• Do you know a technique for analysing the possibly positive and

possibly negative elements identified as existing in both the

external and internal environments.

1.4 The legal and regulatory framework for Business Analysis

• Can you name [2/3] pieces of legislation which might have an

impact on Business Analyst work?

• Broadly what is that legislation about?

• Why should the Business Analyst be aware of it?

1.5 Business Performance Measurement

• What is meant by the term CSF? KPI? Performance target? How

are they linked together?

• Explain the idea behind the BBS

o Why is it called ‘balanced’?

o How is it related to CSF/KPI?

o How is it related to strategy?


22

• Notes


23

Notes

Module 2: Business Analysis Techniques

24

Module 2 – Business Analysis Techniques

In this section of the workshop, we will cover part 2 of the syllabus, Business Analysis Techniques.

2.1 Investigating and documenting business situations

2.2 Stakeholder analysis and business perspectives

2.3 Modelling business activities

2.4 Business events

2.5 Business rules

2.6 Gap analysis


25

Investigating and Documenting Business Situations

Examine the list of techniques in the Syllabus bullet 2.1

• Pros and Cons of each

• Where/when applicable

• Which have you used? Why?

• Which would you use if faced with ??? situation?

‘At least 1 technique used to document existing business situations’

• Read the syllabus Note

• In BCS, the suggestion is to use either Rich Pictures or possibly

Mind Maps as a suitable technique

Memorise 5/6 techniques with their pros and cons, where used etc.


26

Document Existing Business Situation – Rich Picture

Checkland recommends a rich picture to represent the current business situation, but mind maps, fishbone diagrams and other tools can be used instead. However, techniques from hard systems such as data flow diagrams or object models are not sufficiently versatile or ‘rich’.

One of the problems with investigating business situations is that they are rarely clear cut.

Although some of the structured modelling techniques provide a clear view of one perspective (e.g. data or process) they are not able to show the range and variety of issues that may be uncovered. Interpersonal, political and cultural issues are rarely documented, even if they are evident. If such issues are no taken into account then recommendations may be rejected and the implementation of


27

solutions may be deeply problematic. Rich pictures provide a free-format approach to allow analysts to document whatever is of interest or significance. This often includes details of processes, stakeholders, issues raised and the culture inherent in the situation.

There is no single way of drawing a rich picture.

An analyst may find different styles useful in different situations. Ideally the rich picture is captured on one page and hence provides a distilled view of all aspects to be considered. This helps the analyst to develop a mental picture of the situation and see how the different aspects relate to each other.


28

Document Existing Business Situation – Mind Map


29

Stakeholder Identification and Analysis

Rich Pictures could provide clues about Stakeholders

• Also RACI/RASCI, based on known activities

Stakeholder Categories are suggested too

• Business and External (See syllabus lists)

Standard Lists are a good idea in practice

• Based on business areas or even major software applications

1 x Stakeholder Classification technique

• Power/Interest Grid (PIG rating). Leads to prioritisation and an

engagement plan.

BA and PM

• Create the stakeholder management plan


30

An Examiner might ask “Why bother with Stakeholders? Why not just do what the Sponsor says she wants done?”

Stakeholder Analysis is a risk mitigation strategy. Missing out important Stakeholders could jeopardise the success of the change.

Senior Management often don’t understand the details of business operations.

There may be important side effects of the proposed change.

Some Stakeholders are key to making the change happen.

It is often important to get Stakeholder buy-in to the change.


31

Business Perspectives

Each Stakeholder has a certain perspective on the business situation

• Modelled using the CATWOE acronym

• The ‘official’ perspective (Sponsor) is

called the Primary Task definition, and

reflects how the ‘business’ officially

sees things

• Other stakeholders may have very different perspectives, based

on their own interests

Modelling a perspective allows us to understand each stakeholder’s requirements

• And why those requirements are important or meaningful to them

Key elements of CATWOE are T and W


32

Modelling Business Activities

Based around the T definition of CATWOE we can model requirements using a BAM structure

• NB: Other parts of CATWOE could have an influence on the

BAM

• 5 Categories of Activity are suggested to help structure the BAM

o Doing

o Enabling

o Planning

o Monitor

o Control

• Each BAM give us a conceptual should-be

model of requirements for the stakeholder,

based on their CATWOE perspective

o A consensus model will include all the

stakeholders’ requirements

For each key stakeholder we would expect there to be a BAM supporting their requirements.

If we were to merge the BAMs we would obtain a consensus model, although we would have to deal with conflicts, overlaps, contradictions etc.


33

Business Events and Rules

BAM Activities are resolved eventually by defining Processes

Business Events trigger Processes

• 3 types: External, Internal and Time

• Events may intervene during the process too (intermediate

events)

• The BA must be aware of Business Events and their effects

Business Rules guide the conduct of the processing

• 3 types: those based on Constraints, those based on Policy and

those based on defined procedures and formulas

• The BA should be prepared to challenge Business Rules


34

• People

• Organisation

• Process

• Information and Technology

Gap Analysis

Many acronyms are useful here, e.g.

• PPT

• POPT/POPIT*

• POLDAT

• McKinsey 7S

Various dimensions of the Business and Systems Architectures may be relevant for Gap Analysis

‘Holistic View’

The consensus BAM will provide us with a good view of what business requirements should be delivered in the business system

O

P

IT

P


35

under investigation. The initial ‘gap’ we will want to look at is between the as-is situation and the should-be situation.

We can then consider the feasibility of ‘closing the gap’; ideally we would want to cover the whole gap, but this may not be feasible for reasons of risk, cost, time, culture etc. Hence the immediate ‘to-be’ proposal may only be a step along the roadmap towards the eventual ‘should-be’ end goal.

We can assess the As-Is situation across various aspects or dimensions of the Business and Systems Architectures, using a variety of models. Some features of the Business and Systems Architectures are shown above, and there are a number of famous acronyms/models that help pinpoint them, e.g.:

• PPT: People, Process, Technology

• POPT/POPIT: People, Organisation, Process, Information,

Technology.

• POLDAT: Process, Organisation, Location, Data, Applications,

Technology

• McKinsey 7S: Systems, Structure, Strategy, Skills, Staff, Style,

Shared Values

Note that depending upon the role definition, not all of these dimensions will be a direct BA concern.


36

Defining Options

There will generally be several ways to ‘close the gap’ between where the business is and where it needs to be

The BA is expected to propose a range of options for change

• E.g. Differing profiles of Cost, Risk, Timescales etc.

• Including an evaluation of the ‘do nothing’ option

Options:

Do nothing

Spend money

Spend more

money


37

Part 2: Typical Questions These examples are provided as illustrations only. Oral Examiners are experienced and knowledgeable consultants, chosen on an individual basis, who may ask any questions they feel appropriate, or adopt any style of questioning, within the confines of the syllabus and examining guidelines.

2.1 Investigating and documenting business situations

(This is also covered in part 4.2 within ‘Typical Oral style questions (parts 4 & 5)’

• What’s the purpose of producing models in Business Analysis

work

• What are models?

• What do models do for us?

• Why do we need models?

• What technique could you use to model and document an

existing business situation, including all the stakeholder

viewpoints?

2.2 Stakeholder Analysis and Business Perspectives

• Why bother with Stakeholders? Why not just do what the

Sponsor wants?

• For Business Analyst work there is a fairly standard list of

stakeholder categories. Can you name some of them?

• Could you give me [2/3/4] techniques for identifying stakeholders

please?

o Explain each technique, how does it work etc.

• Please name a technique for analysing and prioritising

stakeholders


38


• If Power / Interest Grid given then:

o where would expect to see the Sponsor (P/I rating)?

o What would your strategy for communication and involvement

be for each position on the grid?

• Do you know of a technique for describing a stakeholder’s

perspective?

o Explain the technique etc.

o Why is it important to do this? What do we get from it as

Analysts?

2.3 Modelling Business Activities

• How can we go about modelling Business Activities based on a

Stakeholder’s perspective?

• Is this model a model of As-Is, To-Be or what exactly?

• Is this model Conceptual, Logical or Physical?

• What are the usual ‘types’ of Activity modelled?

• What is meant by a doing / enabling / planning / monitoring /

controlling activity?

• What is the meaning of the term dependency in this context?

• How could you deal with conflicts arising among different

perspectives?

• What is meant by the phrase ‘consensus model’ in this context?

• How could the Business Analyst try to resolve conflicts and reach

consensus?

• What would have to happen if compromise was not forthcoming?


39

2.4 Business Events

• What is a business event?

• Why are business events significant for the Business Analyst?

• What types of business events are usually recognised?

• Why is it important to know the event type?

• How are business events related to business processes?

2.5 Business Rules

• What is a business rule?

• Why are business rules significant for the Business Analyst?

• What types of business rule are usually recognised?

• Why is it important to know the rule type?

• How are business rules related to business processes?

2.6 Gap Analysis

• In Gap Analysis, the ‘Gap’ is between what and what?

• How could a Business Activity Model (BAM) lead into a Gap

Analysis?

• Are we always able to ‘close the gap’? Why might we not be able

to ‘close the gap’ immediately?

• Is the To-Be system always the ‘Ideal’ System?

• As a result of Gap Analysis, we often present options to

Management. Why would we want to do this?

• The mantra ‘Process, People and Technology’ is often cited in

relation to gap analysis. What does this phrase imply for the

Business Analyst?

• Which areas of Process, People and Technology’ are a Business

Analyst’s concern?


40

• Who is responsible for carrying out analysis in the other areas?


41

• Notes


42

• Notes

Module 3: Business Case Development

43

Module 3 – Business Case Development

In this section of the workshop, we will cover part 3 of the syllabus, Business Case Development.

3.1 Rationale for making a business case

3.2 Contents of a business case

3.3 Options

3.4 The financial case

3.5 Investment appraisal techniques

3.6 Risk analysis

3.7 Impact analysis

3.8 Lifecycle for the business case


44

Business Case

The Business Case justifies the investment in change

Essentially lays out:

• Problems and what to do about them

• Benefits vs. Costs vs. Risks vs. Impacts

The Business Case is the key document that guides the decision making throughout the process of change

The Sponsor (Senior Responsible Owner) signs up to the story laid out in the Business Case and should make the sought after Benefits happen


45

Business Case Evolution (Lifecycle)

Alignment

• Business Case is probably very sketchy ‘thoughts’ at this stage

Definition

• Outline Business Case is pulled together for every option to be

considered

• Full Business Case created for the chosen option, for each

Project/Programme

Design

• Business Case should be reviewed and updated at the end of

this Stage

Implementation

• Final update once Business as Usual is re-established

Realisation

• Business Case used to assess

Benefits Realisation


46

Generic Structure of a Business Case


47

Full Business Case Contents

Review contents list in the syllabus, try to memorise the list or at least 5/6 items

Costs and Benefits

• Tangible and Intangible: memorise a few examples of each for a

typical IT project

Risk

• What is ‘Risk’?

• Be prepared for questions on the Risk Management process

• Memorise some examples of Risk for a typical IT project

Impact

• e.g. On People, Process and Technology

• e.g. On Organisation, Culture and Behaviour


48

Investment Appraisal Techniques

Cost Benefit Analysis (CBA) – used for tangible Costs and Benefits

• Benefits should normally exceed Costs to establish the case for

change

o One-off up-front Costs (Capex)

o Ongoing operational Costs (Opex)

3 ‘numbers’ represent CBA in the BCS syllabus

1. Payback Period/Break-even point

• The time it takes to get your money back

2. DCF/NPV

• Future Figures discounted to today’s values

3. IRR

• Maximum discount rate that will still allow us to break-even

overall


49

Investment Appraisal Techniques – additional information

Payback Period/Break-even point

• The point at which the expected financial benefits of the project

equal the sum of the expected one-off project costs plus the

expected ongoing operational costs i.e. cumulative cash flows in

equal cumulative cash flows out

Net Present Value

• Describes the time value of money i.e. how much the total future

cash flow is worth today

Discounted Cash Flow

• Future expected cash flows are discounted to give their present

value, the total of which provides the Net Present Value

• NPV and DCF are important factors when evaluating or

comparing long term investments

Internal rate of return (IRR)

• The discount rate that produces a net present value of 0.

• IRR can be used to rank several prospective projects. The ease

of comparison, by using a single measure, can make IRR

attractive.

• However, IRR does not measure the absolute size of the

investment or the return so a project that invests £1K to gain £3K

will have a higher IRR than one that invests £1m to gain £2m.


50

Tangible Costs and Benefits

Tangible costs and benefits are those for which we have a specific basis for measurement, usually financial. For the benefits we would need to have taken a measurement before the project starts so that we have a basis for comparison.


51

Intangible Costs and Benefits

Most of the costs will be tangible, but we must not overlook the ones it is hard to measure. For the benefits, it is important not to overstate the intangibles or put spurious values on them; it is best to identify them and allow the decision makers to place their own value on them.


52

Risk Management

Analyse proposals, identify and document Risks; e.g.

• Project Risk

• Technical (IT) Risk

• Business (BaU) Risk

Evaluate

• Probability

• Impact

Establish Counter-measures: e.g. acceptance, avoidance, mitigation

Assign Ownership

Monitor and update risks at each lifecycle Stage End (Gateway)

Retire when no longer a threat


53

Impact Assessment

• Organisation structure

• Interdepartmental relations

• Working practices

• Management style

• Recruitment policy

• Appraisal and promotion criteria

• Supplier relations

• And ... not forgetting

POPT/POPIT!

In addition to the costs and benefits already mentioned, we need to explore any impacts there may be on the organisation for each of the options in the business case. Some of these impacts may have costs associated with them, but others may not and are simply things that will happen as a result of adopting the proposed course of action.

• We may need to reorganise departments or functional areas to

exploit the new circumstances fully. This will be unsettling for

staff and management involved so a plan must be put in place to

deal with this

• Relationships between departments may change, and there may

be a need to introduce or amend service level agreements to

redefine the relationships

Organisation

People

Technology

Processes


54

• New processes and systems invariably lead to changes in the

way we work, and these must introduced carefully and sensitively

• Management style sometimes has to change too, e.g. if we give

more authority to front line staff, then their managers' roles will

change too

• We may have to recruit different types of people and look for

different skills

• It may be necessary to change people’s targets and incentives

in order to encourage them to display different behaviours

• Supplier relations may have to be redefined

The business case needs to identify all of the impacts so that the decision makers understand what changes will have to be made in order to get the greatest benefits, and the costs involved.


55

Benefits Realisation and Business Case

Who owns the Benefits?

• Business (Sponsor) owns the Benefits

• Signs up to the Business Case

• Must ‘make it happen’

The Programme might supervise the BR activity

• Business conducts the review (PIR), based on the Business

Case

• Input from BA, if required

• Results fed back to the Programme. More change needed?

• Also document lessons learnt: ‘no-blame’ culture!

PIR – Post Implementation Review


56

Realising the Business Benefits

Benefits realisation is about managing change projects and programmes in such a way that they are able to deliver the predicted benefits, checking on progress of the achievement after the project has finished, and taking any necessary actions to support their delivery.

When a business case is being constructed, thought should be given to how the benefits will be measured. The business case should be reviewed during the project to check whether the predicted benefits are still achievable and identify any changes needed to ensure the delivery of the benefits.

The main review takes place sometime after the project has finished to evaluate progress toward the predicted benefits and identify any further actions that are required.


57

Typical Questions – Part 3 These examples are provided as illustrations only. Oral Examiners are experienced and knowledgeable consultants, chosen on an individual basis, who may ask any questions they feel appropriate, or adopt any style of questioning, within the confines of the syllabus and examining guidelines.

3.1 Rationale for making a Business Case

• What is a Business Case and why do we need it?

• Do we always need it?

• Where in the Lifecycle for Business Change would we first

encounter the Business Case?

• Where in the Lifecycle for Business Change would we expect a

formal Business Case?

• Does the Business Case ever change once it is written?

• When might it change?

3.2 Contents of a Business Case

• Can you give me [3/4/5] topics you would expect to see covered

in a Business Case?

• In connection with IT Enabled Business Change (ITEBC), could

you name for me an example of a ...

• Tangible Cost

• Tangible Benefit

• Intangible Cost

• Intangible Benefit

3.3 Options

• Why is it desirable to consider options?


58

• Which option should always be considered?

• Who decides which option to go for?

• What is the Business Analyst’s role in this?

3.4 The financial case

• Does every project need to be justified on purely financial

grounds?

• Is it always a matter of the ‘bottom line’?

• What other justification could there be for a project?

3.5 Investment Appraisal Techniques

• Explain the concept of a Payback Period to me

• Explain the concept of Discounted Cash Flow (DCF) and Net

Present Value (NPV) to me

• Explain the concept of Internal Rate of Return (IRR) to me

• How would investment appraisal techniques be used to assess

the viability of a project?

3.6 Risk Analysis

• What is a risk?

• Take me through typical steps in managing risk

• What areas of risk are there in IT Enabled Business Change in

general?

• How is risk usually evaluated?

• In what ways can risk be mitigated?

3.7 Impact Analysis

• What is meant by ‘impact analysis’?


59

• How could you convey the impact of change for every option?

3.8 Lifecycle for the business case

• Explain how the business case might evolve over the lifecycle of

business change

• Explain the connection between the Business Change and the

Benefits Realisation Process


60

• Notes


61

• Notes

Module 4: Requirements

62

Module 4 – Requirements

In this section of the workshop, we will cover parts 4 and 5 of the syllabus, Requirements Definition and Requirements Management and Documentation.

4. Requirements definition (K Level 4/5)

4.1 Requirements engineering

4.2 Requirements elicitation

4.3 Requirements analysis

4.4 Requirements validation

5. Requirements management and documentation (K Level 4/5)

5.1 Requirements management

5.2 Change control

5.3 Version control

5.4 Tools in requirements management

5.5 Types of requirements

5.6 Documenting requirements

5.7 Requirements modelling


63

Requirements Engineering

Why bother with Requirements?

• Vital step between Problem and Solution

Requirements identify needs in the presence of problems

• Should be solutionless

• Functional Requirements + Non-Functional Requirements (NFR);

also, in BCS, General and Technical categories

Requirements are hierarchical

• Linked to Business Objectives

• Derived from Policy

• Decompose to lower levels (vertical)

• Link across to each other (horizontal)

NB: There is an implicit assumption in this exam that ‘requirements’ specify an IT Application (Software) product

Getting Requirements identified and agreed is the hardest part of change and a key part of the BA role.

Be prepared to spend about 15 minutes of the interview talking about Requirements, especially:

* The nature of Requirements and difficulties they present; how would you deal with these difficulties?

* The Requirements Engineering Framework

* Attributes you would expect to document about a Requirement.

* Management of Requirements and the use of CASE tool support.


64

NB: when BCS refer to ‘Requirements’ here they are referring to the Requirements for a piece of Applications Software.


65

Requirements Planning and Estimating

Requirements can form the basis for planning and estimating, early in the project lifecycle

• The technique known as Function Point Analysis can be used

o Modern variant is Use Case Function Point Analysis

• Technique rates functions (Use Cases) on a scale that includes

difficulty and complexity

o Based on the FP rating estimates can be made about the time

and effort that might be involved

o Scales are adjusted in the light of experience


66

Requirements Engineering Framework (‘elements’)

These are the essential components of Requirements Engineering in accordance with the BCS Business Analysis book.


67

BCS Requirements Lifecycle Elements

Look up and revise the topics shown in the syllabus under Requirements Definition:

Elicitation:

• Techniques listed in the Oral Exam Syllabus, section 2.1

• Tacit vs. Explicit knowledge, relevance of techniques to each

Analysis

• Analysis Tasks, including prioritisation

• Quality Characteristics

Validation

• Process, where the business takes ownership of the specification

• Roles, especially the role of the Sponsor

For example, an Oral Examiner might ask you to:

* Explain the concept of Tacit Knowledge and why is that a problem for the BA? How can that problem be resolved?

* Name some of the tasks involved in Analysis, and why they are important etc.

* Name a few quality characteristics you would be looking for in a candidate Requirement, why are they important etc.

* What does ‘Validation’ mean and why is this necessary?

* What does Volatility mean in this context, and how does the BA deal with that?


68

BCS Requirements Lifecycle Elements

Look up and revise the topics shown in the syllabus under: Requirements Management and Documentation

• Need for and Elements of Requirements Management

• Traceability of Requirements

o ‘Vertical’ – to business objectives

o ‘Horizontal’ – from origin to delivery

• Change and Version Control

• Use of Tools, benefits (like RequisitPro, DOORS)

• Requirements types: General, Technical, FR and NFR

• Documentation (see later slide)


69

The Hierarchy of Requirements – ‘Types’

Requirements

Business

General

Technical

Solution

Functional

Non-functional


70

Enterprise-level Requirements

General Requirements

• Specifications that apply across all projects

• Often at an enterprise level

o Legal, Image, Branding, Compliance, Look and Feel, ...

Technical Requirements

• As above, but of an IT technical infrastructure nature

• Typically Enterprise Architect (EA) concerns

o Permissible DBMS, Operating Systems, Communications etc.

General or Technical Requirements could be a mixture of Functional Requirements and NFR; tend to be NFR in character.

Each project must adapt these requirements to their individual case.


71

Business: General Requirements

Note that in the BCS BA 3rd Edition, Business Continuity has been moved to the NFR category

Business constraints• Budget, timescale,

resources etc.

Business policies• Standards, business

rules

Legal• Legislative and

regulatory constraints

Branding• Image, style guide

Cultural• Vision, approach,

management style etc.

Language• If operating across

international boundaries

Business continuity• Coping with disaster


72

Business: Technical Requirements

Hardware• IT and other hardware

Software• Operating systems,

package applications, networking, communications etc.

Interoperability• Standards for

communicating between systems and devices

Internet• Policies on Internet

use and web services


73

Solution Requirements:

Functional and Non-functional Requirements

Functional Requirements

• What the (IT) system has to do

• Modelled e.g. as Use Cases

Non-functional Requirements (NFR)

• Specifications around how the functionality is delivered

• Very often categorised in standard lists

o Security, Access Control, Performance, Availability, ...

o The ‘ilities’!

Be prepared for questions like:

• “give some examples of typical NFR for an IT system”

• “how can you test NFR like performance, reliability, ...”

• “why differentiate Functional Requirements from NFRs?”


74

Solution: Functional Requirements

Data entry• Gathering and

recording data

Data maintenance• Changes to data,

including data deletion

Procedural• Implementation of

business rules

Retrieval requirements• Reporting, responding

to enquiries


75

Solution: Non-functional Requirements (NFR)

Note that in the BA 3rd edition the category ‘Robustness’ has been replaced with the category ‘Maintainability’ which includes ensuring that the solution is maintainable such as problem investigation, correction and servicing.

Performance• Speed of processing transactions

Security• Security levels for protection of data

Access• Permissions, who has access to which functionality and how

Backup & recovery• Protection against loss of data

Archiving & retention• Duration, methods, eventual deletion

Robustness• Reliability, data integrity, user error

Availability• Timeframe for availability of functionality

Usability• Ease of learning, ease of use

Capacity• Data volumes, transaction volumes, user volumes


76

Requirements Documentation

2 Levels of Documentation

Requirements Document. This documents the collection of requirements applicable to the project in hand, and cross refers to other documents and models

Requirements Catalogue. A Catalogue is a collection of individual requirements, each documented in a template format


77

Introduction and Background – Clarifies objectives, clarifies scope, describes the context and objectives

Business Process Models – to be process, swimlane diagrams

Function Models – Context diagrams, use case diagrams

Data Models – A clear picture of the data used by the requirements, ERD, Class diagrams

Requirements Catalogue – Detailed documentation of each requirement

Glossary – Clear definition of terms, may be for the project only, May be organisation wide


78

Requirements Catalogue Entries

Look up and revise the suggested entries in the syllabus

• This list applies to a Functional Specification approach to

Requirements definition

• A Use Case template would have similar information, but be

scenario based

• User Stories would be an equivalent technique in an Agile

environment

Memorise 5/6 of these typical entries and be prepared to answers questions on their meaning/importance and typical content

The Examiner may ask: “give me 5 or 6 things you would want to document about a Requirement”; “why are these important?” etc .


79

Modelling Requirements

Requirements are defined as sections of text

It is beneficial to do some modelling to illustrate and cross-reference Requirements

• Aids communication with stakeholders

• Reduces ambiguity

• Ensures coherence with other change products

The 2 models suggested are:

• Process/Function Model

o The BCS suggestion in the syllabus corresponds to a Use

Case Diagram

o Know the notation

• Data Model

o ERD type or a UML Class model – know the notation

o In what way does a Data Model help to check requirements?

o How are Business Rules reflected on this type of model?

Look at the syllabus topics under the Function and Data Modelling sections and be prepared to answers questions on this.

Typical questions centre on the components that go into each model and how and to what extent Requirements are reflected in the model.


80

Use Case Diagram for a Lending Library

Actors are roles that interact with the IT application system.

Use Cases are the ‘functions to be delivered by the system’ i.e. they are the Functional Requirements of the application. NFRs are attached to the Use Case descriptions or are specified in a separate document.

The solid lines are Associations connecting Actors with Use Cases.

The Boundary is the ‘square’ boundary line, delineating the Subject Area.


81

Class Diagram for a Lending Library

The Groupings of Data are the ‘Domain Classes’. These should represent important business concepts.

Relationships between Groupings are called Associations. They express the business context that binds 2 groups together.

The degree of the relationships between Data Groupings is the multiplicity.


82

The concept of optional links is expressed by 0 as the minimum degree.

Business Rules are expressed in the associations between classes and the multiplicity of these.

Requirements are sometimes also expressed in the concepts and the data to be captured and stored.


83

Typical Questions for Parts 4 and 5

These examples are provided as illustrations only. Oral Examiners are experienced and knowledgeable consultants, chosen on an individual basis, who may ask any questions they feel appropriate, or adopt any style of questioning, within the confines of the syllabus and examining guidelines.

4. Requirements Definition

4.1 Requirements Engineering

• How could you gather requirements from a large population of

potential users?

• What are Requirements?

o Define the term

o Why are they so important?

• How are Requirements related to Objectives and Solutions?

• Within the context of the Lifecycle for Business Change,

• Walk me briefly through a typical lifecycle of Requirements

Engineering.

• What elements are suggested by the BCS for Requirements

Management?

• We say that requirements are intrinsically hierarchical; what does

this mean?

• Define for me the terms:

o Functional Requirement (FR)

o Non-functional Requirement (NFR)

o General Requirement

o Technical Requirement

• Why make the distinction between Functional and Non-

functional?


84

• Give me [3/4/5] examples of Non-functional requirements for an

IT Application

o What do they mean?

o How would you test for acceptance?

• If we are told the solution is a ‘commercial off-the-shelf’ (COTS)

package, do we still need requirements?

4.2 Requirements Elicitation

• Give me some examples of where requirements come from in a

typical Business Change.

• We tend to prefer the term ‘elicit’ to the term ‘capture’ – why is

that?

• Can you name [3/4/5] popular elicitation techniques?

• In what situation would each one be useful and why?

o Pros and cons

• Given [situation xxx] which technique(s) would you use and why?

• Explain the term ‘tacit knowledge’ to me

• Why is this a problem for the Business Analyst?

• Which elicitation techniques are good at solving this problem?

• Explain what ‘prototyping’ is and when it is used

o Pros and cons

4.3 Requirements Analysis

• What does ‘analysis’ mean in this context?

• What tasks are involved in analysis?

• How could you prioritise requirements?

• Why do we need priorities? Aren’t we going to deliver

everything?


85

o What does MoSCoW stand for?

o What do these priorities mean in practice?

o Who decides on priorities?

• Tell me about [3/4/5] quality checks you would want to carry out

on requirements that have been elicited

• What tactics could you employ to help reduce the ambiguity of

requirements?

• What’s meant by ‘overlapping’ requirements?

• What’s implied by the phrase ‘paralysis by analysis’

o How can you deal with that risk?

• Why is it sometimes necessary to negotiate requirements?

• Does the Business Analyst broker this? With who?

• Why not just do the Sponsor’s requirements?

o Pros and cons?

• Explain the difference between Contradictory and Conflicting

requirements.

4.4 Requirements Validation

• What does Validation mean?

o Why is this important?

o Which roles are involved in Validation?

• Distinguish Validation from Verification in this context

• What could result from the Validation process?

• Is User Acceptance Testing principally a validation or verification

process?

• Is Benefits Realisation principally a validation or verification

process?


86

5. Requirements Management and Documentation

• Tell me about [3/4/5] attributes you would expect to see

documented about an individual requirement

• What does it mean to say requirements are volatile/stable?

• How would you manage this as a Business Analyst?

• Why is it important to put Requirements under change/version

control?

• What does maintaining the traceability of Requirements mean

• Traceable to what?

• What does ‘Vertical Traceability’ mean?

• What does ‘Horizontal Traceability’ mean?

5.2 & 5.3 Change, Configuration and Version Control

• At what point in the requirements lifecycle would it be appropriate

to put requirements under change and version control?

• What does baselining requirements mean?

• When would we do that in the requirements lifecycle?

• What are configuration items?

o Give an example in this context

• How can this be made to work in an Agile environment?

• What problems do you see with requirements in an Agile

approach?

• How can you deal with those problems?

• “Baseline early, freeze late” – a famous mantra. What’s the issue

here?

• If requirements have been validated, why should they change?

5.4 Tools in Requirements Management


87

• Explain how tools could help with the Requirements Engineering

process?

• What sort of features would you expect a Requirements

Engineering tool to provide?

• How would you make the Business Case for acquiring a tool?

5.5 Types of Requirements

(Covered above in 4.1)

5.6 Documenting requirements

• Explain the ‘2 level’ approach to requirements documentation?

• Give [2/3/4] examples of documentation typical at the Catalogue

level

• Give [3/4/5] examples of documentation typical at the Catalogue

Entry level

• Give me [2/3/4] good reasons for wanting to formally document

requirements

• Within the requirements documentation what is needed to be

able to eventually test the requirements?

• Suppose we are working on an Agile team.

o What are the dangers of not fully documenting requirements?

o What is the benefit of using this approach?

5.7 Requirements Modelling

• What is the purpose of cross referencing requirements to other

development models?

• What elements would you expect to see on a:

o Process/Function Model

o Data Model


88

• How do the elements on a Function model relate to

requirements?

• How do the elements on a Data model relate to requirements?

• How are Business Rules expressed in a data model?

• How is Testing involved in Requirements Engineering?

• When in the Lifecycle for Business Change is involvement

appropriate?

• What are Testers looking for?


89

• Notes


90

•

Notes

Module 5: Optional Modules

91

Module 5 – Optional Modules

In this section of the workshop, we will cover parts 6 and 7 of the syllabus, the Knowledge-based and Practitioner specialisms.

6. Knowledge-based specialism (K Level 2/3)

6.1 Relevance of the selected module to business analysis

6.2 The holistic view of a business system

6.4 Professionalism and business analysis

6.5 Projects and business analysis

7. Practitioner specialism (K Level 2/3)

7.1 Relevance to the business analyst role

7.2 Relevance of the module to an organisation

7.3 Description of the module


92

Knowledge-based Options

• Commercial Awareness (or Organisational Context)

• Foundation Certificate in Business Analysis

• Foundation Certificate in Business Change

• Foundation Certificate in IS Project Management

Knowledge level (Bloom’s Taxonomy) level 2/3 only

• In practice this is hard to apply!

For your revision, revise the module’s syllabus document

• Or on the BCS website

NB: This workshop can only deal with this range of subjects in a generic way, as shown in the syllabus

• If there’s time some limited discussion of content may be

possible

• The pre-reading document covers some of the subject matter in

this section


93

Relevance to the Business Analyst

What’s the relevance of your chosen module to the BA roles and responsibilities?

• e.g. Explain how a Project Life Cycle impacts BA work

(Foundation Certificate in Project Management)

Why is it important for a BA to know about your chosen module?

• e.g. Most BAs work in a project environment and so need to

know how projects are supposed to work (Foundation Certificate

in Project Management)

Must be able to discuss techniques in general terms:

• What techniques there are, what they are used for, how do

techniques relate to each other, etc.


94

General Topics

There are a number of topics you are required to study which are independent of your chosen module

Holistic View

• See suggested list in the syllabus

• This is the use of the POPT/POPIT acronym again

Competencies

• See suggested list in the syllabus and contents in the BAFOUND

course material (or in chapter 2 of the BCS Business Analysis

book)

Professionalism

• See pre-course reading on this topic

Projects and Business Analysis

• Where the BA fits into the project and defining the Terms of

Reference

This sort of material is covered in QA’s BAP course.

Examiners might ask:

• “what areas within the Change Life Cycle are covered by

Business Analysis?”

• “Describe what is meant by a holistic view of change”.

These topics will probably have been covered in BSD7 row 1.


95

• “Give an example of (1/2/3) business

domain/personal/professional competencies you would expect

from a Business Analysts”.


96

Practitioner Options

• Modelling Business Processes

• Systems Modelling Techniques (UML or Structured)

• Benefits Management and Business Acceptance

• Systems Development Essentials

Knowledge level (Bloom’s taxonomy) level 2/3 only

Revise using the relevant syllabus


97

Syllabus Practitioner Options

Relevance of the module and its techniques to the BA role

• Where could you see these techniques being used

Relevance of the module and its techniques to the business

• Why would an organisation benefit by using these techniques

and approaches

Technical approach used within the module

• e.g. Unified Modelling Language (UML) (from Systems

Modelling Techniques)

Discussion of Techniques; use, relevance, content etc,

• e.g. State Machine (from Systems Modelling Techniques)


98

Typical Questions Parts 6 and 7

These examples are provided as illustrations only. Oral Examiners are experienced and knowledgeable consultants, chosen on an individual basis, who may ask any questions they feel appropriate, or adopt any style of questioning, within the confines of the syllabus and examining guidelines.

6. Knowledge-based Specialism

This section has some generic topics and makes reference to the specialist subject.

Questions relating to particular specialist subject areas are not included here.

6.1 Relevance of the selected module to business analysis

You may be asked what the relevance is of the particular Knowledge-based Specialism that you took, and the relevance of the techniques involved.

You will be asked some questions on the techniques involved in the module. These should be questions of a fairly general nature, nothing too detailed. E.g. “Explain briefly what the purpose is of Financial and Management Accounting and how these subjects are relevant to Business Analysis.”

6.2 Holistic View

• Explain what is meant by a holistic approach to Business Change

• What are the main topics to focus on when specifying business

change?

6.3 Competencies of a Business Analyst

• What are the recommended competencies of a Business

Analyst?

• Give examples of the need for:


99

• Business Domain Knowledge

• Personal and behavioural skills

• Professional Skills

6.4 Professionalism and Business Analysis

• What benefit does membership of a professional body have:

o For the Business Analyst

o For the Business Analyst’s employer

• Would you consider Business Analysis is a profession at the

moment? Why? Why not?

• What’s the role of the BCS in developing ‘a profession’?

• What aspects of a true profession does Business Analysis work

seem to lack at the moment?

• Name some of the activities you would expect a Professional

Body to be involved in

6.5 Projects and Business Analysis

• Explain the role of the Project Manager and how the Business

Analyst role relates to that

• What is the document called that is used to launch a project?

• What is normally contained in such a document?

• Give me [2/3/4] examples of deliverables expected from the

Business Analyst during a typical IT Enabled Business Change

project

• Distinguish between project objectives and business objectives

7. Practitioner Specialism

This section has some generic topics and makes reference to the specialist subject.


100

Questions relating to particular specialist subject areas are not included here.

7.1 Relevance to the Business Analyst role

You may be asked what the relevance is of the particular Practitioner Specialism that you took, and the relevance of the techniques involved, how they are used etc.

You will be asked some questions on the techniques involved in the module. These should be questions of a fairly general nature, nothing too detailed. E.g. “Explain briefly what you understand by the Value Chain concept and how it is relevant to Business Analysis”

7.2 Relevance of the module to the organisation

This question will seek to test your knowledge of why the subject matter is of importance to the organisation as a whole.

7.3 Description of the module

Again fairly general questions about approaches in the module taken e.g. benefit of an approach to systems modelling using UML.

Also the approach of using single techniques e.g. “what’s the benefit to the development of doing Domain Class Modelling?”

Index

101

Index

Associations, 80 Balanced Business Scorecard,

17 BAM, 32, 33, 34, 39 BAP, 10, 94 Benefits realisation, 56 Boundary, 80 Business Case, 10, 43, 44, 45,

46, 47, 55, 57, 87 Business Events, 33 Business Rules, 82 CATWOE, 31, 32 Checkland, 26 Cost Benefit Analysis, 48 CSFs, 16, 17 Discounted Cash Flow, 49 FCBC, 10, 11

Function Point Analysis, 65 Functional Specification, 78 Gap Analysis, 34 Impact, 47 Internal rate of return (IRR), 49 KPIs, 16, 17 LCBC, 10, 13, 19 Net Present Value, 49 Payback Period/Break-even

point, 49 rich picture, 26 Risk, 47 Sectors of the economy, 9, 20 Stakeholder, 29 SWOT, 9, 15 Use Cases, 80 Validation’, 67

Contact us:0845 757 [email protected]

Must take two core courses Must take oneknowledge-based course

Must take onePractitioner course

Four courses and exams in total

Exam preparation workshop (recommended)

Diploma oral exam

BCS Certificate in Business Analysis Practice

3 days

Exam:1 hour 15 mins

BCS Certificate in Require-ments Engineering

3 days

Exam:1 hour 15 mins

BCS Certificate in Commer-cial Awareness

3 days

Exam:1 hour

BCS Foundation Certificate in Business Analysis

3 days

Exam:1 hour

BCS Foundation Certificate in Project Management

3 days

Exam:1 hour 15 mins

BCS Certificate in Modelling Business Processes

3 days

Exam:1 hour 15 mins

BCS Certificate in Systems Modelling Techniques (Structured)4 days

Exam:1 hour 15 mins

BCS Certificate in Systems Development Essentials

3 days

Exam:1 hour 15 mins

BCS Certificate in Systems Modelling Techniques (UML)4 days

Exam:1 hour 15 mins

BCS Foundation Certificate in Business Change

3 days

Exam:1 hour

bcs business analysis diploma examination … · bcs business analysis diploma examination...

Documents