bcs business analysis diploma examination … · bcs business analysis diploma examination...
TRANSCRIPT
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
Module 1: The Business Context
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
Module 1: The Business Context
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.
Module 1: The Business Context
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.
Module 1: The Business Context
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?
Module 1: The Business Context
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.
Module 1: The Business Context
15
Environment Analysis and SWOT
Module 1: The Business Context
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
Module 1: The Business Context
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.
Module 1: The Business Context
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
Module 1: The Business Context
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?
Module 1: The Business Context
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?
Module 1: The Business Context
21
o Explain the technique
• Do you know of a technique for analysing the organisation’s
internal environment and capability?
o Explain the technique
• 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?
Module 1: The Business Context
22
• Notes
Module 1: The Business Context
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
Module 2: Business Analysis Techniques
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.
Module 2: Business Analysis Techniques
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
Module 2: Business Analysis Techniques
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.
Module 2: Business Analysis Techniques
28
Document Existing Business Situation – Mind Map
Module 2: Business Analysis Techniques
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
Module 2: Business Analysis Techniques
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.
Module 2: Business Analysis Techniques
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
Module 2: Business Analysis Techniques
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.
Module 2: Business Analysis Techniques
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
Module 2: Business Analysis Techniques
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
Module 2: Business Analysis Techniques
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.
Module 2: Business Analysis Techniques
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
Module 2: Business Analysis Techniques
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
Module 2: Business Analysis Techniques
38
o Explain the technique
• 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?
Module 2: Business Analysis Techniques
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?
Module 2: Business Analysis Techniques
40
• Who is responsible for carrying out analysis in the other areas?
Module 2: Business Analysis Techniques
41
• Notes
Module 2: Business Analysis Techniques
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
Module 3: Business Case Development
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
Module 3: Business Case Development
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
Module 3: Business Case Development
46
Generic Structure of a Business Case
Module 3: Business Case Development
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
Module 3: Business Case Development
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
Module 3: Business Case Development
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.
Module 3: Business Case Development
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.
Module 3: Business Case Development
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.
Module 3: Business Case Development
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
Module 3: Business Case Development
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
Module 3: Business Case Development
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.
Module 3: Business Case Development
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
Module 3: Business Case Development
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.
Module 3: Business Case Development
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?
Module 3: Business Case Development
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’?
Module 3: Business Case Development
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
Module 3: Business Case Development
60
• Notes
Module 3: Business Case Development
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
Module 4: Requirements
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.
Module 4: Requirements
64
NB: when BCS refer to ‘Requirements’ here they are referring to the Requirements for a piece of Applications Software.
Module 4: Requirements
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
Module 4: Requirements
66
Requirements Engineering Framework (‘elements’)
These are the essential components of Requirements Engineering in accordance with the BCS Business Analysis book.
Module 4: Requirements
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?
Module 4: Requirements
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)
Module 4: Requirements
69
The Hierarchy of Requirements – ‘Types’
Requirements
Business
General
Technical
Solution
Functional
Non-functional
Module 4: Requirements
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.
Module 4: Requirements
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
Module 4: Requirements
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
Module 4: Requirements
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?”
Module 4: Requirements
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
Module 4: Requirements
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
Module 4: Requirements
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
Module 4: Requirements
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
Module 4: Requirements
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 .
Module 4: Requirements
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.
Module 4: Requirements
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.
Module 4: Requirements
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.
Module 4: Requirements
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.
Module 4: Requirements
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?
Module 4: Requirements
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?
Module 4: Requirements
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?
Module 4: Requirements
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
Module 4: Requirements
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
Module 4: Requirements
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?
Module 4: Requirements
89
• Notes
Module 4: Requirements
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
Module 5: Optional Modules
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
Module 5: Optional Modules
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.
Module 5: Optional Modules
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.
Module 5: Optional Modules
95
• “Give an example of (1/2/3) business
domain/personal/professional competencies you would expect
from a Business Analysts”.
Module 5: Optional Modules
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
Module 5: Optional Modules
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)
Module 5: Optional Modules
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:
Module 5: Optional Modules
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.
Module 5: Optional Modules
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