BAIQ Introductory Certificate in Business Analysis

1.    Introduction

The Introductory Certificate in Business Analysis assesses knowledge and understanding of a range of business analysis activities and techniques. These topics enable anyone new to business analysis to appreciate the rationale for business analysis and understand the key techniques involved in conducting the key activities of requirements elicitation, analysis and definition.

2.    Assessment Objectives

The examination leading to the Introductory Certificate in Business Analysis is based upon the syllabus detailed below and has the following assessment objectives. Candidates must be able to demonstrate that they are able to:

  • Define the terms listed in the syllabus glossary.
  • Explain business drivers with reference to VMOST analysis, Critical Success Factors and Key Performance Indicators.
  • Identify categories of stakeholder defined in the stakeholder wheel.
  • Define the activities identified in the Business Analysis Process Model.
  • State the five sections of the Requirements Engineering Framework.
  • Explain how to apply selected requirements elicitation techniques.
  • Recognise when requirements elicitation techniques are relevant in given situations.
  • Explain the need to link business requirements to business objectives and business requirements to solution requirements.
  • Explain the requirements filters applied in requirements analysis.
  • Distinguish between general, technical, functional and non-functional requirements.
  • Explain the MoSCoW prioritisation technique.
  • Distinguish between the MoSCoW elements.
  • List the quality criteria for a good requirement.
  • State the contents of a business requirements document.
  • List the contents of a requirement catalogue entry.
  • Define the component elements of a simple use case diagram.
  • Explain the rationale, roles and process for requirements validation.
  • Explain the rationale and activities for requirements management.
  • Explain the business change lifecycle.
  • Distinguish between linear and iterative development lifecycles.

3.    Assessment Format

The examination leading to the Introductory Certificate in Business Analysis comprises 40 multiple-choice questions. Candidates must answer 26 questions correctly in order to gain a pass in this examination and be awarded the certification.

The multiple-choice question style is used throughout the examination in order to assess competency at levels 1 and 2 of Bloom’s Taxonomy of Cognitive Domains.

4.    Syllabus Guide

Section 1: The rationale and coverage of business analysis (5%)

Subject Area

Reference Book

Definition of business analysis

Glossary of terms

Business Analysis Maturity Model

Business Analysis, Chapter 1

Business Analysis Maturity Model

Activities undertaken by business analysts

Business Analysis, Chapter 4, BA Process Model

Section 2: The business context for business analysis (5%)

Subject Area

Reference Book Guide

Business drivers

Business Analysis, Chapter 3, MOST analysis

Critical success factors

Business Analysis, Chapter 3, CSFs

Key performance indicators

Business Analysis, Chapter 3, KPIs

Managing stakeholders

Business Analysis, Chapter 6, Stakeholder management in the project lifecycle

Business Analysis, Chapter 6, Stakeholder Wheel

Section 3: The nature of requirements (5%)

Subject Area

Reference Book Guide

Definition of a requirement

Glossary of terms

Problems with requirements

Business Analysis, Chapter 10, problems with requirements

The Requirements Engineering Framework

Business Analysis, Chapter 10, requirements engineering framework

Section 4: Eliciting requirements (25%)

Subject Area

Reference Book Guide

The nature of elicitation

Business Analysis, Chapter 10, requirements engineering framework

Knowledge types

Business Analysis, Chapter 10, tacit and explicit requirements

Elicitation techniques: Interviews, workshops, observation, document analysis, scenarios, prototyping

Business Analysis, Chapter 5, investigation techniques

Section 5: Analysing requirements (20%)

Subject Area

Reference Book Guide

Organising the Business Requirements Document

Business Analysis, Chapter 10, Requirements Analysis – categorisation of the requirements

Hierarchy of requirements

Business Analysis, Chapter 11, hierarchy of requirements

Types of requirement – General and Technical, Functional and Non-functional

Business Analysis, Chapter 11, types of requirement

Prioritising requirements using MoSCoW

Business Analysis, Chapter 11, MoSCoW prioritisation

Requirements filters

Business Analysis, Chapter 10, requirements filters

Quality criteria for good requirements

Business Analysis, Chapter 10, requirements filters

Section 6: Documenting requirements (25%)

Subject Area

Reference Book Guide

The content of a Business Requirements Document

Business Analysis, chapter 11, contents of a requirements document

The content of a requirements catalogue entry

Business Analysis, chapter 11, requirements catalogue entry

Use case modelling – business and system levels

Business Analysis, chapter 12, business use cases – notation and purpose

Section 7: Validating requirements (5%)

Subject Area

Reference Book Guide

Rationale for validating requirements

Business Analysis, Chapter 10, requirements engineering framework

Roles in validating requirements

Business Analysis, Chapter 10, requirements validation

Process for validating requirements

Business Analysis, Chapter 10, requirements engineering framework

Section 8: Managing requirements (5%)

Subject Area

Reference Book Guide

Rationale for managing requirements

Business Analysis, Chapter 11, managing requirements

Activities in managing requirements

Business Analysis, Chapter 11, managing requirements

Section 9: Delivering business and IT solutions (5%)

Subject Area

Reference Book Guide

Business change lifecycle

Business Analysis, Chapter 14, business analysis in the business change lifecycle

Linear software development approach

Business Analysis, Chapter 13, delivery lifecycles

Iterative software development approach

Business Analysis, Chapter 13, delivery lifecycles

5.    References

Business Analysis (Third Edition) by D Paul, J Cadle, D Yeates (eds.), BCS Swindon

6.    Complimentary Reading

Business Analysis Techniques: 99 essential tools for success by James Cadle (Author), Debra Paul (Author), Paul Turner (Author)

7.    Further reading

IIBA BABOK v3.0

8.    Glossary of terms

Term

Definition

AGILE

An approach to software development based upon the Agile Manifesto and using evolutionary development and incremental delivery approaches.

Actor

A role that performs areas of work within a business system. Actors are modelled on swim lane diagrams and use case diagrams. Actors are usually user roles and show the individual or group of individuals responsible for carrying out the work or interacting with a system. An actor may also be an IT system or time.

Balanced Business Scorecard

A Balanced Business Scorecard supports a strategic management system by capturing both financial and non-financial measures of performance. There are usually four quadrants – Financial, Customer, Process, Learning & Growth. The balanced business scorecard was developed by R. S. Kaplan, and D. P. Norton.

Business Actor

Someone who has an interest in a project, either because they have commissioned it, they work within the business system being studied or they will be the users of a proposed new IT system. See STAKEHOLDER.

Business Analysis

An advisory role which has the responsibility for investigating and analysing business situations, identifying and evaluating options for improving business systems, elaborating and defining requirements, and ensuring the effective implementation and use of information systems in line with the needs of the business.

Business Analysis Process

Model

A framework for business analysis assignments that incorporates the business context and has six stages – Investigate Situation, Consider Perspectives, Analyse Needs, Evaluate Options, Define Requirements and Deliver Changes. The framework places standard modelling techniques in context to help analysts determine the most appropriate technique for individual business situations.

Business System

A set of business components working together in order to achieve a defined purpose. The components of a system include people, IT systems, processes and equipment. Each component may be a system in its own right. See IT SYSTEM.

Business User

An individual member of staff working within the business who is involved in a business change project. A business user may adopt a number of business roles including business sponsor, domain expert and end user for a solution.

Change Control

A process whereby changes to requirements are handled in a controlled fashion. The change control process defines the process steps to be carried out when dealing with a proposed change. These steps include documenting the change, analysing the impact of the change, evaluating the impact of the change in order to decide upon the course of action to take, and deciding whether or not to apply the change. The analysis and decisions should be documented in order to provide an audit trail relating to the proposed change.

Critical Success Factors

The areas in which an organisation must succeed in order to achieve positive organisational performance.

Document Analysis

A technique whereby samples of documents are reviewed in order to uncover information about an organisation, process, system or data.

Entity Relationship Diagram

A diagram produced using the entity relationship modelling technique. The diagram provides a representation of the data to be held in the IT system under investigation. See ENTITY RELATIONSHIP MODELLING.

Entity Relationship Modelling

A technique that is used to model the data required within an IT system. The technique models the data required to describe the ‘things’ the system wishes to hold data about – these are known as the ‘entities’ – and the relationships between those entities.

Explicit Knowledge

The knowledge of procedures and data that is foremost in the business users’ minds, and which they can easily articulate. See TACIT KNOWLEDGE.

Functional Requirement

A requirement that is concerned with a function that the system should provide, that is what the system needs to do.

Gap Analysis

The comparison of two views of a business system, the current situation and the desired future. The aim of gap analysis is to determine where the current situation has problems or ‘gaps’ that need to be resolved. This leads to the identification of actions to improve the situation. The business activity modelling technique may be used to provide an ideal future view which can then be compared with a view of the current situation. An alternative, more detailed approach is to use the business process modelling technique, using ‘as is’ and ‘to be’ process models.

Holistic Approach

The consideration of all aspects of a business system and their interactions. This incorporates the people, process and organisational areas, in addition to the information and technology used to support the business system.

Impact Analysis

The consideration of the impact a proposed change will have on a business system and on the people working within it.

Interview

An investigation technique to elicit information from business users. An interview agenda is prepared prior to the interview and distributed to participants. The interview is carried out in an organised manner and a report of the interview is produced once the interview has been concluded.

IT System

A set of automated components hosted on a computer that work together in order to provide services to the system users. See also BUSINESS SYSTEM.

Key Performance Indicators (KPIs)

These are specific areas of performance that are monitored in order to assess the performance of an organisation. Key performance indicators are often identified in order to monitor progress of the critical success factors. Measurable targets are set for KPIs. See CRITICAL SUCCESS FACTORS.

MoSCoW

An approach to prioritising requirements. MoSCoW stands for:

  • Must have – A mandatory requirement without which the system has no value.
  • Should have – An important requirement that must be delivered, but, where time is short, could be delayed for a future delivery. This should be a short term delay.
  • Could have – A requirement that would be beneficial to include if it does not cost too much or take too long to deliver, but it is not central to the project objectives.
  • Want to have (but Won’t have this time) – A requirement that will be needed in the future but is not required for this delivery.

Non-Functional Requirement

A requirement that defines a constraint or performance measure that the system or the functional requirements must comply with.

Questionnaires

See SURVEY.

Requirement

A feature that the business users need the new system (business or IT) to provide.

Requirements Catalogue

An organised set of requirements where each individual requirement is documented using a standard template.

Requirements Elicitation

A proactive approach to investigating requirements required to resolve a business problem or enable a business opportunity. Involves working with the business users and helping them to visualise and articulate their requirements.

Requirements Management

A governance approach that aims to ensure that each requirement is tracked from inception to implementation (or withdrawal) through all of the changes that have been applied to it.

Scenarios

A technique used to elicit, analyse and validate requirements. A scenario will trace the course of a transaction from an initial business trigger through each of the steps needed to achieve a successful outcome. Alternative scenarios, for example, where specific conditions are not met, are also traced.

Shadowing

A technique used to find out what a particular job entails. Shadowing involves following a user as they carry out their job for a period such as a day or two days.

Special Purpose Records

A technique that involves the business users in keeping a record about a specific issue or task. Typically the record is based on a simple structure, for example a five bar gate record.

Stakeholder

An individual, group of individuals or organisation with an interest in the change. Categories of stakeholder include customers, employees, managers, partners, regulators, owners, suppliers and contractors.

Stakeholder Analysis

The analysis of the levels of power and interest of a stakeholder in order to assess the weight that should be attached to their issues. This technique provides a means of categorising stakeholders in order to identify the most appropriate stakeholder management approach.

Stakeholder Management

The definition of the most appropriate means to be adopted in order to engage with different categories of stakeholder. The approach to each stakeholder will be different depending on (a) their level of interest in the project and (b) the amount of power or influence they wield to further or obstruct it.

Strobe

A technique that represents a formal checklist approach to observation, where the analyst is investigating specific issues. STROBE stands for Structured Observation of the Business Environment and is used to appraise a working environment.

Survey

A technique used to obtain quantitative information during an investigation of a business situation. Surveys are useful to obtain a limited amount of information from a large group of people.

Tacit Knowledge

Those aspects of business work that a user is unable, or omits, to articulate or explain. This may be due to a failure to recognise that the information is required or to the assumption that the information is already known to the analyst. See EXPLICIT KNOWLEDGE.

Use Case

A use case is something that an actor wants the IT system to do; it is a “case of use” of the system by a specific actor and describes the interaction between an actor and the system.

Use Case Description

A use case description defines the interaction between an actor and a use case.

Use Case Model

A technique from the Unified Modelling Language (UML). A use case model consists of a diagram showing the actors, the boundary of the system, the use cases and the associations between them, plus a set of use case descriptions.

Workshop

An investigation technique whereby a meeting is held with business actors from a range of business areas in order to elicit, analyse or validate information. An agenda is prepared prior to the workshop and distributed to participants. The workshop is run by a facilitator; actions and decisions are recorded by a scribe.