The lessons in this module will:

• Answer the question, “What is business analysis?”
• Examine how business analysis originated and developed
• Explore the different activities and services performed by business analysts
• 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 or enterprise 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

We also include an optional lesson on business architecture.

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 three lessons,

1. Gap analysis
2. Developing options
3. Delivery lifecycles

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.

Delivery lifecycles

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
• Agile

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 cases.

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.

The documentation may be done on paper or on software requirements applications designed for the purpose.

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 see how to model data using the UML class model standard.

Documenting requirements by whatever form involves identifying a number of attributes. The set of attributes can be defined in a template. Completed templates can be collected in a requirements catalogue.

All of the information that has been recorded about the requirements, including the models, diagrams and the completed templates, the requirements catalogue, can be organised in a business requirements document, sometimes known as the BRD.

The completed set of requirements is the basis for the acquisition and delivery of the improved business and IT systems.

In this module, we examine the role of the BA in these activities, e.g. in the design, development and implementation of improved systems.

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.

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.