Foundation Business Analysis - Course description

The lessons in this module will:

• Answer the question, “What is business analysis?”
• Examine how business analysis originated and developed
• Review a life-cycle for managing business change programmes

In this lesson we exam qualities, skills and knowledge required by a business analyst, specifically:

• Personal qualities
• Business knowledge
• Professional techniques

Business analysis concerns identifying business changes that will help the organisation achieve its strategic objectives.

It is essential that a business analyst understands the strategy and direction of the organisation for which they work. This will provide a context for everything that they do.

with their understanding of the organisation’s strategy, the business analyst is well placed to help to align an IT strategy to support the achievement of business objectives. They may help to develop a business architecture to support this.

In this module we explore:

• The concept of business strategy
• Some classic techniques for considering possible strategies
• What is meant by a value proposition
• Business architecture
• Execution of strategy

Whereas some business analysts work in a “Business as usual" (BAU) environment, many will also work on business change programmes.

Any piece of business analysis work may be managed as a project. In a business change programme there are likely to be many projects and the focus for some of them will be business analysis.

Before starting a project, the business analyst needs to clarify the nature of the problem to be solved or the opportunity to be realised. They can then write clear terms of reference for the project.

This lesson explores:

• Techniques for problem solving and for writing terms of reference.
• A framework for managing business analysis projects or indeed any business change project: this is known as the business analysis process model.

Much of the business analyst’s work involves investigating areas of the business in order to qualify and quantify the significance of business problems, opportunities and drivers for change.

We describe a number of popular techniques that are essential for a business analyst to work effectively. Specifically, we cover:

• Interviewing
• Facilitated workshops
• Observation
• Scenarios
• Prototyping
• Questionnaires
• Special purpose records
• Activity sampling
• Document analysis

Having identified the problems it is essential to now identify the owners of those problems. These are the stakeholders, the people in the business with an interest in resolving the problems, avoiding threats and seizing opportunities.

In this module, we examine some popular techniques for working with and successfully managing stakeholders.

• Stakeholder categories
• Stakeholder identification and management
• Soft system methodology
  • Analysis of stakeholder perspectives
  • Business activity models

Business process modelling and management is a vital skill for a business analyst.

Business processes are the means by which an organisation:

• Acquires, creates, sells and delivers its products and services to its customers.
• Manages its internal operations.

They are a major element in a business architecture.

In this module we look at:

• The nature of processes and their link to organisational strategy.
• Techniques for modelling, analysing and improving these business processes.

At this stage, the project team can consider possible options for their approach to a solution.

Module comprises two lessons,

1. Gap analysis
2. Developing options

Gap Analysis

Gap analysis identifies the differences between where an organisation is currently and where it wants to be in the future.

Having identified the differences, the team can,

1. Identify the artifacts in the current system that will need to change
2. Devise an approach to making those changes and so bridging the gaps

This lesson explains the rationale for and approach to gap analysis.

Developing options

As a result of their gap analysis, the team knows,

• The direction it wishes to go in (Where)
• The things that will need to change (What)

They now consider the how.

There can be a number of different ways of performing the how.

Possible options for doing this can be identified.

Each option can be analysed to determine,

• Feasibility
• Cost
• Benefits
• Risks

This lesson explains the process.

The requirements are the basis for the design, development and implementation of the required changes.

A number of approaches to managing software acquisition and implementation are in popular use; these approaches are known as systems (or software) development life cycles (SDLCs).

In this module we examine the following life cycles:

• Linear
  • Waterfall
  • V model
• Iterative
• Incremental

A business analyst must understand that spending on programmes and projects is an investment on behalf of either shareholders or taxpayers.

As initiators of change, we are always spending someone else’s money. This must be done with care. Investments should not normally be undertaken if they will lose money.

Even with change projects performed to implement government legislation, it is essential to be able to manage the money that is spent.

In this module, we look at the creation of business cases and their supporting financial case.

Identifying and managing requirements is at the heart of what a business analyst does.

Every requirement should be framed in the context of the identified business problems or opportunities.

Summarised by Alexander and Beus-Dukic as ‘Simple but not easy’, requirements success eludes many programmes and projects.

In this module, we look at the nature of requirements and categorise them according to well-established schemes.

Requirements are commonly organised as a hierarchy. We examine a particular hierarchy relevant to the syllabus for this course.

We also examine a framework for identifying, analysing, validating, documenting and managing requirements.

Whether formally or informally it is essential to document requirements specifications.

Requirements may be specified by using a combination of text and diagrams; we consider a selection of popular techniques for doing this including:

• Traditional ‘text only’ specifications
• Use cases
• User stories

Requirements specifications frequently refer to the data that is used. Modelling of this data can help to elaborate and refine the requirement specification. We look at two techniques for modelling data:

• UML class model
• Entity relationship diagrams (ERDs)

Following the delivery of the changes to the business, it is essential to track them to assess the extent to which the benefits, as predicted in the business case, are actually achieved.

This module examines the process of assessing the achievement, or realisation, of benefits.

We also consider some of the human aspects of change.

Every module of the course includes exam style questions.

This final section includes,

• Hints and tips for taking the exam
• A complete practice with 40 questions; this is the number of questions that will appear in your actual exam.