Certified Business Analyst Foundation Level Syllabus: International Business Analysis Qualifications Board

Certified Business Analyst
Foundation Level Syllabus
Version 1.0
7 June 2011
International Business Analysis Qualifications Board

Copyright Notice
This document may be copied in its entirety, or extracts made, if the source is acknowledged.
Copyright Notice © International Business Analysis Qualifications Board (hereinafter called

IBAQB®)
IBAQB is a registered trademark of the International Business Analysis Qualifications Board.
Copyright © 2011 the authors for the version 7 June 2011 (Karolina Zmitrowicz (chair), Eric Riou du
Cosquer, Maureen Dening, Michał Figarski, Beata Karpińska, Ingvar Nordström, Alain Ribault,
Dariusz Paczewski, Dmitry Parilov, Robert Treffny)
All rights reserved.
The authors hereby transfer the copyright to the International Business Analysis Qualifications
Board (IBAQB). The authors (as current copyright holders) and IBAQB (as the future copyright
holder) have agreed to the following conditions of use:
1) Any individual or training company may use this syllabus as the basis for a training course if
the authors and the IBAQB are acknowledged as the source and copyright owners of the syllabus
and provided that any advertisement of such a training course may mention the syllabus only after
submission for official accreditation of the training materials to an IBAQB-recognized National
Board.
2) Any individual or group of individuals may use this syllabus as the basis for articles, books,
or other derivative writings if the authors and the IBAQB are acknowledged as the source and
copyright owners of the syllabus.
3) Any IBAQB-recognized National Board may translate this syllabus and license the syllabus
(or its translation) to other parties.
Version 2011 Page 2 of 104 7. June 2011

© International Business Analysis Qualifications Board
Revision History
Version Date Remarks
1.0 07.06.2011 First version of the Certified Business Analyst

Version 2011 Page 3 of 104

Table of Contents
Acknowledgements.................................................................................................................................. 5
Introduction to this Syllabus ..................................................................................................................... 5
Purpose of this Document ................................................................................................................... 5
Examination ......................................................................................................................................... 5
Accreditation ........................................................................................................................................ 5
Internationality ..................................................................................................................................... 5
Knowledge (K) Levels ......................................................................................................................... 6
Level of Detail ...................................................................................................................................... 6
How this Syllabus is Organized ........................................................................................................... 6
1. Fundamentals of Business Analysis (K2) ....................................................................................... 7
2. Enterprise Analysis (K3) ............................................................................................................... 18
3. Business Analysis Process Planning (K3) .................................................................................... 31
4. Elicitation (K3) ............................................................................................................................... 41
5. Requirements Analysis (K3) ......................................................................................................... 52
6. Solution Validation (K3) ................................................................................................................ 62
7. Tools and Techniques (K3) ........................................................................................................... 65
8. Competencies (K2) ....................................................................................................................... 70
9. Process Improvement (K2) ........................................................................................................... 76
10. Innovation, Design and the Customer (K2) .............................................................................. 81
11. References ............................................................................................................................... 96
Standards .......................................................................................................................................... 96
Books and Other Publications ........................................................................................................... 96
12. Appendix A – Learning Objectives/Cognitive Level of Knowledge ........................................... 98
Level 1: Remember (K1) ................................................................................................................... 98
Level 2: Understand (K2) .................................................................................................................. 98
Level 3: Apply (K3) ............................................................................................................................ 98
13. Appendix B – Rules Applied to the IBAQB ............................................................................... 99
Foundation Syllabus .......................................................................................................................... 99
14. References ............................................................................................................................. 101
Sources of Information .................................................................................................................... 101
15. Appendix C – Notice to Training Providers ............................................................................ 102
Index .................................................................................................................................................... 103

Acknowledgements
International Business Analysis Qualifications Board Working Party Foundation Level (Edition
2011): Karolina Zmitrowicz (chair), Eric Riou du Cosquer, Maureen Dening, Michał Figarski, Beata
Karpińska, Ingvar Nordström, Alain Ribault, Dariusz Paczewski, Dmitry Parilov, Robert Treffny) and
all National Boards for the suggestions for the current version of the syllabus.
Introduction to this Syllabus
Purpose of this Document

This syllabus defines the basic level (Foundation Level) of the training program to become an
IBAQB Certified Business Analyst (CBA). IBAQB developed this syllabus in cooperation with the
Global Association for Software Quality (GASQ).
The syllabus serves as a foundation for training providers who are seeking accreditation. All areas
of this syllabus must be incorporated in the training documents. The syllabus should, however, also
serve as the guideline for preparing for certification. All the areas listed here are relevant for the
examination.
Examination
The examination to become a Certified Business Analyst is based on this syllabus. All sections of
this syllabus are subject to examination. The examination questions are not necessarily confined to
an individual section. A question may refer to information in several sections.
The format of the examination is single choice (one correct answer out of four options).
Examinations can be taken after having attended accredited courses, or in an open examination
without a previous course. You will find detailed information regarding examination times on the
GASQ website (www.gasq.org) and on IBAQB website (www.ibaqb.org).
Accreditation
Providers of an IBAQB Certified Business Analyst course must be accredited. IBAQB accreditation
is granted after an expert panel reviews the training provider's documentation. An accredited course
is one that is determined to conform to the syllabus. When an accredited course is given, an official
Certified Business Analyst examination (CBA exam) may be administered. An exam may also be
administered by an independent certification institute (according to ISO 17024 rules).
Internationality
This syllabus was developed by a group of international experts.
The content of this syllabus can therefore be seen as an international standard. The syllabus makes
it possible to train and conduct examinations internationally at the same level.

Knowledge (K) Levels

The syllabus has been divided into three different Knowledge (K) levels. This division enables the
candidate to recognize the "knowledge level" that is required for each topic.
The three K-levels used in the current syllabus are:
 K1 - remember, recognize, recall
 K2 - understand, explain, give reasons, compare, classify, summarize
 K3 - apply in a specific context
Level of Detail
The level of detail in this syllabus allows internationally consistent teaching and examination. In
order to achieve this goal, the syllabus consists of the following items:
 General instructional objectives that describe the intention of the Foundation Level
certification.
 A list of information to teach that includes a description and references to additional sources
if required.
 Learning objectives for each knowledge area that describe the cognitive learning outcome,
and the mindset to be achieved.
 A list of terms that students must be able to recall and understand.
 A description of the key concepts to teach that includes sources such as accepted literature
or standards.
The syllabus content is not a description of the entire knowledge area of Business Analysis; it does
reflect the level of detail to be covered in Foundation Level training courses.
How this Syllabus is Organized

The syllabus contains ten major chapters. The top-level heading of each chapter shows the highest
level of the learning objectives that is covered within the chapter, and specifies the minimum time to
be spent for training in the chapter.

1. Fundamentals of Business Analysis (K2) 100 minutes
Terms:
Artifact, business analysis, business analyst, requirement, requirements classification, requirements
types, standard, traceability
Learning Objectives for Fundamentals of Business Analysis

The following objectives identify what you will be able to do after the completion of each module.
1.1 Why is Business Analysis Necessary (K2)

LO-1.1.1 Describe, with examples, the way in which missing or incomplete Business
Analysis can result in failure of a project. (K2)
LO-1.1.2 Explain why Business Analysis is necessary by providing examples. (K2)
1.2 What is Business Analysis (K2)

LO-1.2.1 Define Business Analysis and Business Analyst. (K1)
LO-1.2.2 Recall the common objectives of Business Analysis. (K1)
LO-1.2.3 Provide examples of the Business Analysis objectives, in the different phases of the
software life cycle. (K2)
LO-1.2.4 Recall the relationship to the solutions life cycle. (K1)
1.3 Core Concepts of Business Analysis (K2)

LO-1.3.1 Explain the core concepts in Business Analysis. (K2)
1.4 Knowledge Areas (K1)

LO-1.4.1 Recall the knowledge areas in Business Analysis. (K1)
1.5 Tasks and Responsibilities (K2)

LO-1.5.1 Recall the major tasks of a Business Analyst. (K1)
LO-1.5.2 Explain the role and responsibilities of a Business Analyst in the different phases of
the project. (K2)

1.1. Why is Business Analysis Necessary? (K2) 20 minutes
Section Learning Objectives
Problems with requirements can cause projects to fail. In most cases those problems are caused by
poor or incorrectly conducted Business Analysis (especially Requirements Engineering, a part of
the Business Analysis knowledge area).
Common pitfalls in Business Analysis include (K2):
 Ambiguous, under-specified, unclear, impossible, contradictory business requirements
 Instability of the requirements (frequent and uncontrolled changes in requirements)
 Poor translation of the business needs to requirements (incomplete, inconsistent, or not
measurable requirements)
 Unclear objectives of the initiative
 Communication problems
 Language barriers
 Knowledge barriers
 Vague wording
 Overly formal wording
 Redundancy
 Gold plating (adding unnecessary scope)
 Insufficient user involvement
 Overlooked user classes
 Minimal specification
The above issues may result in problems later, during scope definition, planning, implementation
and testing. Unclear requirements, or low quality business design of the solution, can lead to
confusion and questions regarding the intended software product or process solution. If no actions
are taken to correct this state, the risk of the project‟s failure increases.
The impact of improper Business Analysis on the project is already known, but still very often
neglected. The major reasons for neglecting Business Analysis are (K2):
 Time pressure
 Exclusive focus on fast results
 Exclusive fixation on costs
 Perceiving documentation or the analysis and understanding of the business processes
within an organization as a cost, not an added value
Possible consequences of neglecting Business Analysis (K2) are:
 Some business processes within an organization are not known or understood, which may
cause the following effects:
o Requirements are imprecise

o Requirements are ambiguous (can be interpreted differently)
o Requirements are contradictory
o Requirements do not fulfill the agreed criteria (i.e., quality criteria)
o Requirements are missing
 Business processes and artifacts are not covered by requirements or are described
incompletely.
 All stakeholders are not identified.
 Business goals or needs are not identified causing the designed solution to fail to meet the
organization‟s needs and not achieve the business goals.

1.2. What is Business Analysis? (K2) 20 minutes
1.2.1. Business Analysis (K1)

Business Analysis is the set of tasks, knowledge, tools and techniques required to identify business
needs and determine solutions to business problems [BABOK]. Solutions may include:
 Development of software systems
 Development of software components
 Extensions of existing software
 Improvements to the business process
 Changes to the organization
1.2.2. Business Analyst (K1)

A Business Analyst (BA) is a person responsible for identifying the business needs of the customer
(external or internal) and other stakeholders and for determining solutions to business problems
[BABOK]. Specific activities of the Business Analyst include identifying, analyzing, developing and
managing the requirements.
It is important to remember that a Business Analyst is not responsible for determining the solution
implementation (creating the product‟s design). The solution implementation is a result from the
information provided by the Business Analyst‟s work but it is not a BA role to determine the solution
implementation.
Implementation often includes software development, but may also consist of process
improvements or organizational changes.
The Business Analyst acts as a bridge between the customer and other stakeholders (e.g., the
project team), identifying, negotiating and achieving a consensus between the needs of the various
representative individuals and groups.
1.2.3. Common Objectives of Business Analysis (K1)

Common objectives of Business Analysis are the following:
 Collect and document the requirements (business level)
 Design business solutions to resolve the business problems
 Assist in the timely completion of the project by providing accurate requirements
identification and analysis
 Improve efficiency by increasing the quality of requirements identification and analysis and
therefore reducing the need for rework and fixes in the later stages of the project

1.2.4. Business Analysis in Different Phases of the Software Life Cycle (K2)
Business Analysis on the customer side (i.e., the recipient of the solution) begins as soon as a need
for a new solution appears. On the vendor side (i.e., the creator of the solution), Business Analysis
is usually initiated by establishing a budget, agreement, assignment or project.
For example, when the business requires new or modified functionality to improve a business
process, the first step should be an analysis of the needs and requirements.
In traditional approaches, the initial phase of the project is called the analysis phase. In this phase
of the project the purpose of the Business Analysis process may be:
 Identifying and evaluating the current business processes in an organization (“as is”
analysis)
 Gathering initial requirements for the needed business solution (“to be” analysis)
 Creating and analyzing the business case
 Conducting a feasibility study
 Preparing ideas for the business solution
During the next phase, the specification phase, a Business Analyst is responsible for:
 Identifying and documenting business requirements on a more detailed level
 Supporting the Systems Analyst in preparing the detailed system specifications (e.g.,
covering such items as data, mapping, integration issues, user interfaces)
 Validating the proposed software design with the customer and other stakeholders
 Managing any requirements changes
During the next phase, the development phase, the tasks of the Business Analyst include:
 Supporting the development team during implementation (e.g., clarifying issues related to
the requirements, validating business rules to be applied in the code)
 Validating the evolving solution according to the intended requirements and needs (when
possible)
 Supporting testers in preparing test cases and test scripts at the business level and
validating the resulting work products
 Managing any required changes to the requirements (resulting from detected defects,
regulatory or legal changes, needs for new or extended functionality, etc.)
During the testing phase, the role of Business Analysis may vary. For example, during system test,
the BA role may be limited to verifying test results and resolving issues related to defects or gaps in
the requirements. During test levels involving the customer, BA effort should be increased, and
often includes the following items:
 Participating in the preparation of test cases for User Acceptance Testing
 Supporting the acceptance testers by answering questions during test execution

1.2.5. Relationship to the Solutions Lifecycle (K1)

Different projects or approaches (to management or product development) may require producing
requirements in a specific format and with different levels of detail. The level of detail, and
requirements format, may also be determined by the business area and any external regulatory
requirements.
A Business Analyst must work together with the project team, and other stakeholders, to determine
which tasks and techniques defined in the general Business Analysis process are appropriate for
the organization and for a specific project. For example, Enterprise Analysis will not be conducted in
every case; in some projects the initial requirements and business processes within an organization
are already known and understood.

1.3. Core Concepts of Business Analysis (K2) 30 minutes
1.3.1. Business Analyst Role (K1)

A Business Analyst is a liaison between stakeholders, responsible for identification, analysis,
communication and validation of requirements for changes to business processes, policies and/or
information systems [BABOK].
1.3.2. Business Analyst and Systems Analyst (K2)

The Business Analyst is responsible for documenting and gathering the business requirements.
This information is then provided to the Systems Analyst, who is responsible for writing technical
requirements from the business requirements. The Systems Analyst role provides a bridge between
the business requirements and the technical definition of the IT solution. The Systems Analyst may
be required to be familiar with programming technologies and should have knowledge of the
existing IT infrastructure to be able to match the planned solution to the context.
The two roles are complementary and both are needed for a successful IT project.
1.3.3. Requirement (K1)

A requirement is defined in [IEEE Std 610.12-1990] as:
1. A condition or capability needed by a stakeholder to solve a problem, or achieve an
objective.
2. A condition or capability that must be met or possessed by a system or system component,
to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in 1 or 2.
Requirements are the foundation of systems, or system components. They can be obligatory
(required functions, constraints, etc.), essential for the software to perform its functions, and meet
the expectations and needs of the intended stakeholders.
To ensure clarity, requirements should be placed into one of the following categories:
 Business requirements
 User requirements
 Functional requirements
 Non-functional requirements
The meaning and purpose of requirements is defined as follows (K2):
 Provide a foundation for assessment, planning, execution and monitoring of the project
activities
 Define customer expectations (expressed as real requirements and stakeholder‟s value of
those requirements)
 Serve as a component of agreements, orders, project plans
 Establish system boundaries, scope of delivery, and the services classification of the
requirements [Ebert05]
1.3.4. Classification of Requirements (K2)

Requirements consist of process requirements and product requirements [Ebert05]:
 Process requirements describe needs and limitations of the business processes (e.g.,
management or production processes) including costs, marketing, processing time, sales
and distribution, organization, and documentation.
 Product requirements consist of functional and non-functional product requirements. Both
can be regarded from the point of view of the customer (external), and from the point of
view of the vendor team (internal).
1.3.5. Types of Requirements (K1)

The following is a categorization of the types of requirements:
 Customer requirements (business requirements)
 Solution or system requirements
 Product or component requirements
1.3.6. Requirements Elicitation (K1)

Requirements Elicitation is the collection of activities, approaches, tools and techniques for
capturing the requirements for a planned software system (or other business solution) from the
stakeholders.
1.3.7. Traceability (K2)

Traceability is an association that exists between different types of requirements and the following
items:
 Requirements (mapping the higher level requirements that defined the needs and features
to the more detailed requirements)
 Detailed requirements to design models
 Detailed requirements to test cases (e.g., for system testing)
 High level requirements to test cases (e.g., for acceptance test)
 Requirements to release/code branch/version
When dealing with medical compliance (e.g., the FDA, the MDD), in most cases traceability is also
used for determining Risk.
Traceability between requirements and other project artifacts allows a Business Analyst to ensure
all business requirements have been met. For the testers and developers, traceability ensures that
the requirements coverage has been achieved. Traceability is also important from the change
management perspective, to determine the impact of a change on the system or process.

1.3.8. Artifact (K1)

Artifacts are either final or intermediate work products that are produced and used during a project.
Some artifacts (for example use cases and other UML diagrams, requirements and design
documents) describe the function, architecture, and design of software. Other artifacts are
concerned with the process of development itself, such as project plans, business cases and risk
assessments [RUP]. It is necessary to ensure that all artifacts important to the project are under
version control and correctly traced to their origin.

1.4. Knowledge Areas (K1) 10 minutes
Business Analysis consists of the following knowledge areas:

 Enterprise Analysis
 Requirements Planning and Management
 Requirements Elicitation (Identification)
 Requirements Communication
 Requirements Analysis and Documentation
 Solution Assessment and Validation
Business Analysis can influence other areas of the project. It has a significant impact on project
management (especially scope and time management) and also to the following areas:
 Design – Business Analysis determines the required business architecture and scope of the
solution.
 Development – The Systems Analyst (who determines detailed requirement specifications)
uses the Business Analysis to determine what has to be implemented.
 Testing and other Quality Assurance activities – Products of Business and Systems
Analysis are a basis for testing (i.e., the requirements specification is a basis for test case
preparation and execution) and have to be tested themselves (i.e., the requirements
specification has to be tested for consistency, completeness, and compliance with
standards).

1.5. Tasks and Responsibilities (K2) 20 minutes
1.5.1. Major Tasks (K1)

The following are the major tasks of a Business Analyst:
 Requirements elicitation (identification)
 Requirements analysis and modeling
 Requirements realization planning
 Requirements communication
 Requirements documentation
 Requirements validation
 Requirements configuration management
 Business solution proposal
1.5.2. Role of Business Analyst in Different Phases of the Project (K2)

The work of a Business Analyst does not end with completion of the initial analysis and design
phases of the project. A Business Analyst supports other activities performed during the next stages
of the project; in fact the BA should be involved during the whole software life cycle, including the
maintenance phase. The reasons for this involvement include:
 Supporting implementation work in order to ensure developers understand and implement
the requirements properly
 Supporting testing, for example by validating test cases in order to ensure that testing will
adequately cover all the requirements
 Analyzing and documenting change requests for the requirements
 Processing new requirements (new regulations, standards, etc.)
 Processing the requests to fulfill new needs requested by the customer or user
All the issues above require involvement of the Business Analyst, and in many cases also the
Systems Analyst.
Therefore, a Business Analyst supports the project from the beginning through the system
deployment (and sometimes to the system retirement).

2. Enterprise Analysis (K3) 150 minutes
Terms:
Business case, business goal, business needs, business process, enterprise analysis, S.M.A.R.T.,
solution scope, stakeholder, stakeholder‟s value
Learning Objectives for Enterprise Analysis

The objectives identify what you will be able to do after the completion of each module.
2.1 Stakeholder Identification and Analysis (K2)

LO-2.1.1 Explain who can be a stakeholder in a project. (K2)
LO-2.1.2 Explain, with examples, how stakeholders can be identified. (K2)
LO-2.1.3 Describe how the needs of different stakeholders can affect the product. (K2)
2.2 Enterprise Analysis - Identifying Business Processes (K2)

LO-2.2.1 Recall what Enterprise Analysis is and why it is necessary. (K1)
LO-2.2.2 Recall the definition of a business process. (K1)
LO-2.2.3 Explain, with examples, the reasons why identification of business processes is
necessary. (K2)
LO-2.2.4 Explain the techniques for identifying business processes. (K2)
2.3 Business Needs and Goal Definition (K3)

LO-2.3.1 Recall what business needs and goals are. (K1)
LO-2.3.2 Explain the basic principles of building proper business goals. (K2)
LO-2.3.3 For a given scenario, identify the business needs and goals. (K3)
2.4 Business Case Definition (K3)

LO-2.4.1 Recall what a Business Case is. (K1)
LO-2.4.2 Explain the basic principles of building a proper Business Case. (K2)
LO-2.4.3 Explain when the building of a Business Case is necessary. (K2)
LO-2.4.4 For a given scenario, define the Business Case. (K3)

2.5 Determining Solution Scope and Approach (K3)

LO-2.5.1 Explain why determining solution scope is necessary. (K2)
LO-2.5.2 For a given scenario, determine the solution scope. (K3)

2.1. Stakeholder Identification and Analysis (K2) 20 minutes
One of the key activities to be completed when starting work on a new system is the identification
and analysis of the stakeholders. It is important to analyze and understand the system
requirements, and to be able to deliver a proposed design of the business solution. A Business
Analyst should, therefore, know all the individuals and organizations affected by the planned
solution and, from the other side, those that will be affecting the solution.
2.1.1. Stakeholder (K1)

A Stakeholder is any person involved in, or with an interest in, a project. They may be individuals
and/or organizations actively involved in the project, or those whose interests may be affected as a
result of the project execution or project completion. Stakeholders may also influence the project‟s
objectives and outcomes.
Stakeholders come from the vendor‟s organization, the customer‟s organization, and from external
parties.
Stakeholders on the vendor side (i.e., the organization that will be creating the solution) may be:
 Project Managers
 Business and System Analysts
 Developers and Architects
 Database designers
 GUI designers
 Technical writers
 Testers and Quality Assurance staff
 Installation and Operations personnel
Stakeholders on the customer side (i.e., the organization that will receive the solution) may be:
 Customer representatives (i.e., “Business”)
 Project sponsors
 End users (from the customer company)
 Installation and Operations personnel
External stakeholders may be:
 End users who are not a part of the customer‟s organization (e.g., clients of the customer)
 Other organizations (e.g., regulatory entities)
2.1.2. Stakeholder Identification (K2)

Stakeholders can be identified using the following techniques:
 Investigating the business domain

 Identifying owners of the business processes

 Analyzing the structure of the customer‟s organization
 Exploring the target market of the customer‟s organization
 Analyzing relationships with external organizations (suppliers, etc.)
2.1.3. Stakeholders’ Needs and Expectations (K2)

Different stakeholders may have different needs and expectations regarding the planned solution. It
is very important to identify all the stakeholders and their needs, and to find a common
understanding of the purpose of a solution, in order to avoid the situation where the final product
may meet the requirements of only a selected group of stakeholders. It is also important to ensure
that the features to be implemented will not conflict with the requirement of other stakeholders. For
example, a software product designed only for a knowledgeable customer representative may not
be satisfactory for the end users since end users may have different needs regarding the software,
such as a user friendly GUI, intuitive navigation, and an extended help system.
One of the responsibilities of a Business Analyst is to identify all the stakeholders and define their
requirements and expectations. This process is one of the key activities in the Enterprise Analysis,
as it determines the initial scope and requirements of the system. However, this activity is often
skipped or performed only partially, usually leading to problems as the project progresses.
2.1.4. Stakeholder Identification Problems (K2)

The main problems with identifying stakeholders include:
 A lack of understanding of the real operators of the business processes in the organization
 Unclear definition of responsibilities within the customer‟s organization
 Excluding stakeholders who are not clearly and directly related to the process (e.g., the end
customers)
 Incomplete analysis resulting in missing processes and activities, and the related
stakeholders

2.2. Enterprise Analysis - Identifying Business 30 minutes

Processes (K2)
2.2.1. Enterprise Analysis (K1)

Enterprise Analysis is defined as the strategic part of the project lifecycle and an initial phase of
Business Analysis [BABOK].
Enterprise Analysis consists of the following activities:
 Determining business opportunities
 Developing strategic goals to be achieved by the organization, and a strategic plan for
planning and executing the goals
 Understanding and developing the business architecture
 Determining the optimum project investment path for the organization, including
implementation of new business and technical system solutions, as well as process or
organizational changes
 Choosing the most suitable solution approaches for projects, and developing their business
cases
 Initiating projects, and ensuring they deliver value to the stakeholders
In other words, Enterprise Analysis consists of the collection of pre-project activities that captures
the future view of the business, in order to provide context to the project requirements identification
and solution design for a given initiative or for long-term strategic planning.
In large and complex organizations, Enterprise Analysis may be conducted as a stand-alone
project. In smaller ones, Enterprise Analysis is performed by the customer organization before
involving the vendor, and the results are provided to the vendor as part of the initial requirements. In
some cases, Enterprise Analysis is not conducted at all, for example, when the goal of the project is
clear and defined in measurable way.
The goal of Enterprise Analysis is to identify and describe business requirements for the future
investments. Those requirements are defined at a high level as business goals, needs, and
expectations of the organization.
It is important for the Business Analyst to have a complete understanding of the strategic goals of
the customer‟s organization and to ensure new initiatives fit in its long term strategy or mission.
Even if the Business Analyst is not directly involved in the Enterprise Analysis activities (as it may
be conducted only on the customer side); they should have knowledge about the goals of the
organization.
2.2.2. Enterprise Analysis Activities (K1)

The Enterprise Analysis activities include [BABOK]:
 Identifying business processes performed in the organization
 Creating and maintaining the Business Architecture
 Conducting feasibility studies to determine the optimum business solution
 Defining the scope of the new business opportunity

 Preparing the Business Case
 Conducting the initial Risk Assessment
 Preparing the Decision Package
2.2.3. Business Processes (K1)

A business process is a set of activities aimed at producing a specific output for a particular
customer or market. A business process focuses on how the work is done within an organization,
the way of organizing work, activities, relationships and the dependencies between them. A process
can be considered as the ordering of work activities across time and place, with a beginning, an
end, and clearly defined inputs and outputs [Sparx].
A business process must have the following characteristics [Sparx]:
 Has a goal
 Has specific inputs
 Has specific outputs
 Uses resources
 Has a number of activities that are performed in some order
 Affects at least one organizational unit
 Creates value for the customer (both internal and external)
Identification of current business processes performed within the organization, allows the Business
Analyst to understand the organization‟s goals, and also to determine the activities and the flow
required to achieve future planned business and strategic goals. This identification helps establish
all the activities and roles that are responsible for the execution of the activities that produce the
desired outputs.
Identification of business processes helps find possible gaps and ineffective parts of the process,
which may then be improved via process optimization.
If business processes are not established and understood, then the organization may have a low
maturity level, which makes measuring and controlling processes very difficult. In addition, there are
likely to be significant problems with the definition of the business goals and needs.

2.3. Business Needs and Goals Definition (K3) 30 minutes
2.3.1. Business Goal (K1)

A Business Goal is a short- or long-term objective of an organization. Business Goals should be
characterized by the following qualities:
 Specificity
 Optimism
 Realism
 Both short- and long-term scope
2.3.2. The Meaning of Business Goal (K2)

Setting Business Goals is important for the following four reasons:
1. The organization needs to have a vision of what it wants to accomplish. This is facilitated
by having clearly stated goals, along with establishing time periods in which they need to be
achieved.
2. It keeps a clear picture of what the organization is trying to do with the business, and helps
focus motivation.
3. It allows the organization to understand and maintain a commitment to the business‟ main
objectives.
4. It provides a metric against which to measure the organization‟s progress.
2.3.3. SMART (K2)

SMART is a system and a tool that is used to establish goals and define their quality objectives.
SMART requires that all goals have the following characteristics:
 S – Specific
 M – Measurable
 A – Attainable
 R – Relevant
 T – Timely
2.3.4. Business Need (K1)

A Business Need describes the business problem or opportunity which the Business Analyst must
understand and analyze in order to recommend appropriate solutions.
It is important to note that before a project starts, the Business Need (understood as a problem or
an opportunity) and Business Case (understood as costs vs. benefits) are defined, either formally or
informally. These definitions should be done to ensure proper project selection, and to establish

proper priorities for the projects that help the organization reach its vision, strategic goals, and
business objectives.
The Business Need should be defined by the person or group requesting the project, which may
include the following person or group:
 Sponsor
 Steering Committee
 Regulatory or compliance body
 High-level Subject Matter Expert (SME) [Pyzdek, Thomas and Paul A. Keller]
Business Analysts are often supported by Project Managers and Product Managers in defining
Business Needs. However, the results of their work are most effective when they are neutral
facilitators, not owners. Project/Product Managers and Business Analysts need to make
recommendations regarding which projects the requesting organization should undertake to achieve
specific business goals, but they should not be the only decision-makers; the customer‟s involvement
is necessary.
Therefore, one of the responsibilities of a Business Analyst is to cooperate with the person or group
requesting the project, including users or proxy users, and to help them articulate the real need.
2.3.5. Stakeholder Value (K1)

Accurately determining stakeholders‟ value is one of the key factors of a project‟s success. The
main goal of a project always should be achieving “realized value” (also known as “benefits”) for the
stakeholders. A value can be understood as „”the benefit we think we get from something” [Gilb,
Competitive Engineering].

2.4. Business Case Definition (K3) 30 minutes
A Business Case provides the reasoning for initiating a project (i.e., initiative). The case describes a
justification for the project in terms of the value added to the business as a result of the project
outcomes, in comparison to the cost of developing the new solution (K1).
Usually, a Business Case is presented in the form of a structured document; however, it may be
expressed as a short argument or presentation. For example, consider the case in which a software
upgrade might improve system usability; the Business Case here is that better usability would improve
customer satisfaction, require less task processing time, or reduce training costs.
A Business Case may cover the following topics:
 Information about the opportunity (market trends, competitors)
 Qualitative and quantitative benefits
 Estimates of cost and time to breakeven
 Profit expectations
 Follow-on opportunities
 Cash flow consequences of the action, over time, and the methods used for quantifying
benefits and costs
 The impact of the proposed project on the business operations or business process
 The impact of the proposed project on the technology infrastructure
 Constraints associated with the proposed project
 Estimated budget
 Alignment with priorities established by the business
2.4.1. Basic Principles of Building a Proper Business Case (K2)

Building the Business Case should be done with care. A Business Case must demonstrate that the
solution proposal has been analyzed properly, that the full benefits will be realized over time, and
any technical aspects have been thoroughly evaluated.
Depending on the size and availability of information, a Business Case should cover some or all of
the following topics:
 Reference
o Project name/reference
o Background
 Context
o Business objectives and opportunities
o Business priority
 Value Proposition

o Desired business outcomes

o Business benefits (by outcome)
o Quantified benefits value
o Costs
o ROI financial scenarios
o Risks and costs of not proceeding
o Project risks (to project, benefits and business)
 Focus
o Problem/solution scope
o Assumptions
o Constraints
o Identified and evaluated options
o Size and scale assessment
o Complexity assessment
 Deliverables
o Planned products and benefits
o Organizational areas impacted (internally and externally)
o Key stakeholders
o Dependencies
 Workload
o Approach
o Definitions of phases
o Project activities
o Technical delivery activities
o Workload estimate
o Project plan
o Project schedule
 Required resources
o Project leadership team
o Project governance team
o Team resources
o Funding
 Commitments
o Project control
o Reporting processes
o Deliverables schedule
o Financial budget and schedule
2.4.2. Quality Attributes of a Business Case (K1)

The Business Case process should be characterized by the following qualities:
 Adaptable – Adjusted to the size and risk of the proposal.
 Consistent – Every project addresses the same basic business issues.
 Business-oriented – Focused on the business capabilities and impact.
 Comprehensive – Considers all factors relevant to a complete evaluation.
 Understandable – The content is clear and logical.
 Measurable – Key aspects can be quantified.
 Transparent – Key elements can be directly justified.
 Accountable – Commitments for the delivery of benefits and management of costs are
clear.
2.4.3. Procedure of Building the Business Case (K1)

Building the Business Case is performed in four steps:
 Identify and quantify the benefits
 Identify and quantify the costs
 Prepare the Business Case
 Define the procedures that will be used to measure the costs and benefits
2.4.4. Purpose for Building the Business Case (K2)

A properly built business case allows the organization to:
 Understand and apply a way of thinking that allows decision makers to analyze the value,
risk and priority of a project proposal.
 Justify the value of the proposals to the organization and to reject any proposals that do not
have proven and measurable value.
 Decide if the proposal is of value to the business and is achievable in comparison to
alternative proposals.
 Track and measure the progress and achievements of the business case (helping proper
project management).
 Ensure that projects with inter-dependencies are undertaken in the optimum sequence.
A sample Business Case contains the following elements:
1. Executive summary
2. Introduction and summary
 Project rationale for the preferred option
 Current business process

 Description of the problem

 Opportunity
 Project objectives
 Project scope
 Business benefits
 Project costs
 Assumptions
 Potential business and staff impact analysis
 Potential technology impact analysis
 Other issues
 Implementation plan
3. Approach
 Financial metrics
 Privacy impact assessment (as well as regulatory, legal, etc.)
 Alternative evaluation criterion
4. Key selection criterion
 Weighting
 Constraints and limitations
5. Preferred alternative
 Business benefits
 Alternative costs
 Assumptions
 Potential business and staff impact analysis
 Other issues
6. Risk Management Plan
 Risk assessment
 Risk response
 Benefit realization
7. Conclusion and recommendations

2.5. Determining Solution Scope and Approach 40 minutes

(K3)
Defining solution scope is a basis for establishing the scope of the project (project planning), and for
developing further detailed requirements. The cost and time is usually determined by the project
manager. The estimation is based on the project scope or the scope of the solution to the problem
(e.g., using functional decomposition of the planned solution to establish the total work effort to be
done within the project). Planning the scope of the project a different way may increase the risk of
project failure by causing any of the following:
 Delays
 Budget overruns
 Incomplete delivery
Defining the project scope is one of the responsibilities of the Business Analyst. Project scope is
initially defined by the business requirements, and is further detailed during the requirements
development, which is one phase of a typical project development life cycle.
Solution scope may be determined using the following techniques (K2):
 Work Breakdown Structure (WBS) - a decomposition of the work that is required to
complete a project, and accomplish the business objectives
 Product Breakdown Structure (PBS) - a decomposition of the components of the product
 System Interface Analysis - a definition of the work required to integrate the new solution
into the existing business and technical environments

3. Business Analysis Process Planning 180 minutes

(K3)
Terms:
CCB (Change Control Board), change life cycle, change management, change request,
communication, configuration item, configuration management, requirements engineering process
Learning Objectives for Business Analysis Process Planning

The objectives identify what you will be able to do following the completion of each module.
3.1 Business Analysis Communication Planning (K2)

LO-3.1.1 Recall project roles and activities are affected by the results of Business Analysis
activities. (K1)
LO-3.1.2 Recall the common Business Analysis deliverables. (K1)
LO-3.1.3 Explain why communication is an important part of the work of a Business Analyst,
and define what factors need to be considered in establishing a communication
plan. (K2)
LO-3.1.4 Describe, with examples, ways of communicating Business Analysis activities and
deliverables. (K2)
3.2 Requirements Management Process Planning (K2)

LO-3.2.1 Describe the process of Requirements Management. (K2)
LO-3.2.2 Describe the additional elements to be included in Requirements Management
process planning. (K2)
LO-3.2.3 Describe factors to be included in planning. (K2)
3.3 Configuration and Change Management Process (K3)

LO-3.3.1 Explain the concept of Change Management and Configuration Management. (K2)
LO-3.3.2 Explain the difference between Change and Configuration Management. (K2)
LO-3.3.3 For a given scenario, implement a Change Management process. (K3)
LO-3.3.4 Explain the role of the CCB. (K2)
3.4 Tools and Techniques Selection (K1)

LO-3.4.1 Recall the types of tools that can be used to support Business Analysis activities.
(K1)
LO-3.4.2 Recall the common Business Analysis techniques. (K1)

3.1. Business Analysis Communication Planning 50 minutes

(K2)
Business Analysis is the starting point for designing and implementing a software solution. Its
deliverables are inputs to many other project phases and processes, such as establishing the
system architecture that will allow meeting the business goals, creating detailed functional and non-
functional system specifications, and planning and executing QA activities. Outputs from the
Business Analysis are also inputs to system acceptance testing, which is the final check before the
production release. System acceptance testing is conducted to verify that the software is working
as expected, and is needed in order to realize its goals (i.e., improving efficiency of performing the
business process).
Business Analysis provides information to the following processes:
 Project management (scope planning, scheduling, and estimating development and testing)
 Systems analysis
 Design (system specification and architecture)
 Implementation
 Testing
The following roles are affected by the results of Business Analysis activities:
 Project manager (controlling the project schedule and scope)
 System analysts and developers (planning and designing the implementation)
 Architects (planning the system architecture, integration, etc.)
 QA staff
 Testers
3.1.1. Business Analysis Deliverables (K1)

The most important deliverables of the Business Analysis phase are:
 Business requirements
 A list of the stakeholders of the project
 Limitations and assumptions
 Business process flow definition
 Definition of business process products
The main purpose of planning the Business Analysis communication is to define how to receive,
distribute, access, update and escalate information to and from the project stakeholders, as well as
how to organize the schedule and structure of the communication within a project.
Business Analysis activities and deliverables can be communicated in both formal and informal
ways. Common methods of communication include:
 Workshops
 Presentations (formal or informal)

 Reviews (formal or informal)
Any communication activity should take into consideration the focus of the communication (e.g.,
needs, information, and consequences). Having this information, the Business Analyst can decide
what the appropriate delivery method is, the appropriate audience, and how to present the
information. For each communication, the Business Analyst must decide the most effective form of
communication for both the topic and the stakeholder.
3.1.2. Factors to be Considered in Planning (K2)

There are many different factors which should be considered when planning Business Analysis
communication. These factors include:
 Type of project
 Communication formality
 Communication frequency
 Geographical location
 Culture
Different types of projects require varying amounts of documentation, and often have diverse
processes and different deliverables.
Communication formality varies between projects, project phases and stakeholders.
Communication tends to be more formal when the project is large, or its domain is complex, or the
project itself is considered to be critical or strategic, or dependent on legislation, sector standards,
or agreements. Some stakeholders may require formal communication regardless of the project
type.
Communication frequency may vary among stakeholders for every form of communication.
Geographic disparity can also be a factor that limits communication possibilities, especially when
stakeholders live in different time zones.

3.2. Requirements Management Process 70 minutes

Planning (K2)
This step is to define the appropriate Requirements Engineering strategy, including planning and
estimation of the work for a specific project or organization. This strategy determines the main
activities and roles used in the process. It also includes defining the process of handling Change
Requests (described in the next chapter).
3.2.1. The Requirements Management Process (K2)

The most important inputs for the Requirements Management process phase are:
 Business Analysis approach
 Business Analysis plan
 Organizational process assets
The Business Analysis approach is the overall approach used by the organization to derive the
Business Analysis processes, and may include a definition of the Requirements Management
process.
The Business Analysis plan defines what deliverables (i.e., the requirements specification for a
selected area of the solution) will be produced and when.
The organizational process assets are a set of standard templates or guidelines for the processes
existing in the organization. These assets may greatly affect the process of requirements
management.
The process of Requirements Management is a non-core process (not a key activity adding primary
value to an output), which affects all disciplines of systems development including (K2):
 Identification of requirements (recording)
 Analysis of requirements
 Specification of requirements (documenting)
 Changes of requirements (tracking and updating)
 Quality assurance (ensuring adherence to process)
One of the important parts of Requirements Management is the communication planning,
particularly regarding change management and tracking. The main factors included in these
activities are (K2):
 Organizational culture
 Organizational standards
 Stakeholder preference
 Complexity (of product, project)
 Organizational maturity

Organizational culture has to be considered when determining the formality of communication.

There is a risk that communication that is too informal may be a threat to project success when
agreements are not adequately documented and not communicated well to all stakeholders.
Likewise, communication that is overly formal may impede the efficient flow of information.
Formality of communication can also be a choice of individual stakeholders. Some of them require
more formal communication, while others consider formal documentation as an unnecessary
overhead.
3.2.2. Additional Aspects of Requirements Management (K2)

The Requirements Management process should also include provisions for methods of storing,
tracking, and updating requirements.
A repository should be used to store all requirements and their respective status. The state of each
requirement should be tracked in this repository (e.g., under development, under review, approved,
changed). The repository can be a single tool or a set of tools (e.g., word processors, diagram
designers, wikis, management tools). For better effectiveness the repository should have a proper
workflow for the requirements as they move through the life cycle. Appropriate stakeholders should
be able to add, delete, update or view a requirement.
A Business Analyst must define a process for tracing requirements from their source. This process
has to be tailored to the complexity of the project domain, the stakeholder‟s needs, the potential
risks, and the available resources.
Each requirement should be assigned attributes. Custom requirement attributes allow the Business
Analyst to include more detailed classification information for the requirements, and allows reporting
and analysis based on those attributes. The attributes need to be planned and defined in the
Requirements Elicitation phase.
Not all requirements are equal in importance to the stakeholders, and they do not have the same
value for project success. Priority, as a factor of importance and impact, should be determined by
the Business Analyst, along with the proper stakeholders, during the Requirements Elicitation
phase. This priority may be updated throughout the life of the project as new information surfaces.
A formal Change Management process is also required for the requirements. Change Management
is a process designed to track, identify and manage changes. Refer to Configuration and Change
Management Process (K3).

3.3. Configuration and Change Management 60 minutes

Process (K3)
To ensure proper Requirements Management, a Configuration Management process must be

implemented. In many cases requirements are not stable, and the subsequent changes may affect
other related project artifacts. The Business Analyst must manage changes in the requirements,
and ensure that all affected items have been properly adjusted. The approach for resolving such
issues must also be included in the Business Analysis process planning.
3.3.1. Configuration Management (K1)

Configuration Management is a discipline that applies technical and administrative tools and
techniques for the following reasons:
 Identify and document the functional and physical characteristics of a configuration item
 Control changes to those characteristics
 Record and report change processing and implementation status
 Verify compliance with specified requirements [IEEE 610]
A Configuration Item is an artifact, document, product (hardware and/or software) that has an end-
user purpose and is treated as a single entity in the Configuration Management Process. [after
IEEE 610] (K1)
In Business Analysis, configuration items include:
 Single requirements
 Business needs
 Requirements specifications
 Business cases
 Models
The purpose of Configuration Management is to establish and maintain the integrity of the products
(components, data, and documentation) and the software artifacts, throughout the project and
product life cycle.
For Business Analysis, Configuration Management ensures that all work products (outcomes) of
Business Analysis are identified, version controlled, tracked for changes, related to each other, and
related to other projects items (e.g., development and test artifacts) so that traceability can be
maintained throughout the production process.
When planning the project, Configuration Management procedures and infrastructure (tools) should
be chosen, documented and implemented. This is due to the fact that configuration items should be
defined and brought under change control as soon as possible. The Business Analysis phase
produces many work products (e.g., requirements, specifications), and all of them must be identified
as configuration items, baselined and controlled.

The process of Configuration Management includes the following activities [IEEE 1042] (K2):
1. Configuration Identification - The purpose of Configuration Identification is to determine the
attributes that describe every aspect of a configuration item. These attributes are recorded
in configuration documentation and baselined.
2. Configuration Change Control - Configuration Change Control is a set of processes, and
approval stages that are required to change a configuration item's attributes, and to
establish a new baseline for the changed item.
3. Configuration Status Accounting - Configuration Status Accounting is the ability to record
and report on the configuration baselines that are associated with each configuration item
at any moment of time.
4. Configuration Audits - There are two types of Configuration Audits:
 Functional Configuration Audits
 Physical Configuration Audits
A Functional Configuration Audit ensures that functional and performance attributes of a
configuration item are achieved, while a Physical Configuration Audit ensures that a
configuration item is installed in accordance with the requirements of its detailed design
documentation.
3.3.2. Change Management Process (K3)

Change Management can be considered as a sub-discipline of Configuration Management, and
allows managing changes of the requirements in an effective way.
The Change Management process includes the following elements:
 Identifying a potential change
 Requesting new functionality
 Analyzing the change request
 Evaluating the change
 Planning the change
 Implementing the change
 Reviewing and closing the change request
Potential changes can be identified as a result of:
 A defect found in the code, documentation or requirements
 System improvement efforts
 External changes (regulatory, legal, etc.)
 New or changing requirements (resulting from new regulations, changes within the
business domain, new features requested by the users, etc.)
 Business process improvement initiatives
When the need for a change appears, there should be a Change Request raised by a stakeholder
requesting new or modified functionality. Important elements of a change request are a unique
identifier, the author, the deadline (if applicable), an indication whether the change is required or
optional, the change type, and an abstract, or description, of the proposed change.

The originator of a change may be any stakeholder on either the customer or vendor side of the
project; this includes users, customers, Project Managers, Business Analysts, developers, testers,
architects, etc. It is important to ensure that the change is submitted in a formal way and is properly
managed. All changes should be tracked in a Change Log or Change List. This document must be
baselined, and owned and updated by one person (usually the Change Manager). The other
stakeholders should be aware of this document and should be able to view it.
Changes should be managed by the Change Control Board (CCB). The CCB is not allowed to
submit, approve, reject, or implement changes without discussion with the other stakeholders. A
change may have significant impact on other elements of the system, such as components,
interfaces, functionality, etc. Therefore, each change should be analyzed, and the impact of change
implementation determined. Impact analysis includes analysis of the changes needed in the project
schedule or budget that would be necessitated if the change were to be implemented. The result of
the impact analysis should be one of the main drivers in making decisions about approving or
rejecting a change request.
As the impact analysis is done, the CCB makes a decision regarding approving, rejecting, or
deferring the change. A decision to reject or defer the change is communicated to the change
originator with relevant justification. Approved changes must be planned for implementation.
The planning of change implementation includes:
 Updating plans as needed depending on the phase of the project (e.g., Project Plan,
Development Plan, and Test Plan)
 Updating business and system documentation (e.g., specifications, architecture design,
user manuals)
 Updating test cases and test scripts
 Implementing the change (coding)
 Testing by vendor or/and customer test team
 Deploying the change to the production environment (if applicable)
After the change has been implemented, it must follow the usual path to be tested. It is important to
ensure the implementation is correct and that it complies with the needs of the stakeholders,
without causing any negative effects. If testing discovers any issues, changes should be returned to
the development team for corrections.
If the implemented change is determined to be correct and stable, it may be moved to the target
environment, and the Change Request may be closed.
3.3.3. Change Life Cycle (K2)

The status of a change will vary based on the stage in the Change Management process. Examples
of possible status values include:
 Submitted
 Open
 Approved
 Rejected
 Deferred
 In implementation
 Implemented
 In testing
 Tested
 Closed
The life cycle of a change is very similar to that of a defect. Similarly, the procedures for Change
Management and Defect Management are very similar. In fact, the same management tools are
often used for these two processes.
3.3.4. Change Control Board (CCB) (K1)

The CCB is a group of people responsible for evaluating and approving or rejecting proposed
changes to configuration items, and for ensuring implementation of approved changes. [IEEE 610]
The Change Control Board (CCB) usually includes (K1):
 Project manager
 Business Analysts
 Development team
 Quality assurance team
 Business manager, if applicable
 Customer, if applicable

3.4. Tools and Techniques Selection (K1) 10 minutes
Each type of Business Analysis activity has its own set of supporting tools. In general, tools can be
divided into the following categories based on their functionality (K1):
 Text processing tools
 Table calculation tools
 Modeling tools
 Requirements Management tools
 Process simulation tools
 Configuration Management tools
 Change Management tools
There are numerous techniques designed to aid Business Analysis activities. Techniques change
the way in which Business Analysis tasks are performed, and determine outputs for those tasks. In
this section only a few of the common techniques are listed.
Common Business Analysis techniques include (K1):
 Brainstorming
 CATWOE
 Data Flow Diagrams
 Five Why‟s
 Functional decomposition
 Interviews
 MoSCoW
 MOST
 PESTLE
 Prototyping
 Requirements Workshops
 Risk Analysis
 Scenarios and Use Cases
 SWOT
 User stories

4. Elicitation (K3) 180 minutes
Terms:
Apprenticing, baseline, brainstorming, change management, field observation, interview, quality
criteria, questionnaire, requirements acceptance, requirements elicitation, reuse, RTM, scope, self-
recording, specification, standards, traceability
Learning Objectives for Elicitation

4.1 The Concept of Requirements Elicitation (K3)

LO-4.1.1 Define Requirements Elicitation. (K1)
LO-4.1.2 Explain how Requirements Elicitation is a key task in Business Analysis. (K2)
LO-4.1.3 Describe the goals of the identification of requirements. (K2)
LO-4.1.4 Describe and apply standard techniques used to collect the requirements of the
system. (K3)
LO-4.1.5 Describe the characteristics of functional and non-functional requirements. (K2)
4.2 Requirements Scope Management (K2)

LO-4.2.1 Understand and explain the concept of requirements scope. (K2)
LO-4.2.2 Explain the role of requirements in defining the scope of the solution. (K2)
4.3 Requirements Traceability (K2)

LO-4.3.1 Define Requirements Traceability. (K1)
LO-4.3.2 Explain why Requirements Traceability is important. (K2)
LO-4.3.3 Describe the techniques and tools that are used to trace requirements. (K2)
4.4 Requirements Documentation (K3)

LO-4.4.1 Define the standard contents of a requirements document. (K1)
LO-4.4.2 Explain the process of constructing a requirement. (K2)
LO-4.4.3 Apply several common techniques used in Requirements Documentation. (K3)
LO-4.4.4 Describe, with examples, the most common mistakes in requirements documents.
(K2)

4.5 Communication (K2)

LO-4.5.1 Explain the process of requirements communication. (K2)
LO-4.5.2 Explain the purpose of requirements acceptance. (K2)
4.6 Standards (K2)

LO-4.6.1 Recall the standards and norms that apply to Requirements Engineering. (K1)
LO-4.6.2 Explain, with examples, the quality criteria for requirements. (K2)

4.1. The Concept of Requirements Elicitation 70 minutes

(K3)
Business Requirements Elicitation is defined as a set of approaches, techniques, activities, and

tasks used to capture the business requirements of a planned solution from the stakeholders and
other available sources. (K1)
Business Requirements Elicitation has several purposes, including: (K2)
 Identifying the desired functions, characteristics, limitations, and expectations of the
planned solution
 Establishing the final scope and business design of the solution
 Orienting the requirements toward the project vision
 Excluding functions that the customer does not want and need
The following techniques are used during Requirements Elicitation: (K3)
 Questionnaires
 Interviews
 Self-recording
 Hosting representatives of the customer at the vendor‟s site
 Reviewing existing documents
 Reusing a specification from a previous project
 Brainstorming
 Field observation
 Apprenticing
 Conducting workshops to refine the requirements after each iteration
Requirements Elicitation should apply to enterprise requirements as well as user or customer
requirements.
Identification of requirements should include expressing them using the following quality
characteristics [ISO 25000, previously ISO/IEC 9126] (K2):
 Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability

4.2. Requirements Scope Management (K2) 20 minutes
4.2.1. Requirements Scope (K1)

Requirements may cover any of the following areas:
 System or component development
 Process improvement
 Organizational change
4.2.2. Requirements Scope Management (K2)

Requirements Scope Management involves the following activities:
1. Establishing the requirements baseline
2. Creating a requirements structure for traceability
3. Identifying impact to external systems and other areas of the project
4. Identifying changes in the scope resulting from requirements changes
5. Maintaining scope approval by the stakeholders
Establishing the Requirements Baseline

All requirements identified and approved by stakeholders must be baselined. The baseline is a base
for the next phase of development and will serve as a point of reference for any changes in the
content of the requirements or scope.
Creating a Requirements Structure for Traceability

Requirements traceability is necessary for the process of managing changes to the requirements
that will occur after the requirements are baselined. Traceability establishes the origin of the
requirement and defines all related components.
Identifying Impact to External Systems and Other Areas of the Project

In order to ensure that there is no work outside the baselined list of requirements, it is necessary to
identify and document all possible impact to external systems and other areas of the project. This
confines the project to the defined requirements.
Changes in requirements scope may affect:
 Project schedule
 Project cost
 Project and product risk
 Project resources
 External interfaces to other systems or hardware
Identifying Changes in the Scope that Result from Requirements Changes

Change Management is the process of controlling changes to the requirements of the systems
development component, process improvement and/or organizational change project, in a
controlled manner [BABOK]. (K1)
In most cases, customer requirements are not constant throughout the project‟s lifecycle. They are
changeable and very often not fully complete until the end of the implementation phase. Changes in
requirements may have various impacts on the project; if the change is minor, it may have no
impact on the project scope, time or cost; if the change is major (such as changing business logic or
process flow for critical functionality) it may have a drastic effect.
Maintaining Scope Approval

Having the list of requirements is not sufficient to be able to manage the scope properly. The list
must be approved and baselined and must reflect stakeholders‟ expectations for the project. The
approved list of requirements is considered as a mutual understanding between the customer and
the vendor team about the requirements. Any changes in the approved list of requirements should
be managed via change management procedures.
4.2.3. Baseline (K1)

A system baseline is any set of system attribute specifications that formally define the state of a
system under specified conditions [TGilb].
The Baseline is considered to be an official list of the requirements, and can be treated as an
internal agreement. Proposed changes are compared to the baseline to determine the overall
impact.

4.3. Requirements Traceability (K2) 20 minutes
Traceability is an association existing between high level requirements (needs and features) and
the more detailed requirements. Traceability may be established between detailed requirements,
and both design models and test cases. Traceability between requirements, and other project
artifacts (such as test cases), allows a Business Analyst to ensure all requirements have been
fulfilled. (K1)
Tracing of requirements is necessary to ensure all requirements are properly managed within the
project life cycle, especially in the area of managing changes to the requirements. When changing
any requirement, traceability association allows a determination of what other requirements are
affected by the change and what other artifacts should be properly adjusted. When a change is
made to a traced requirement, verification can be made to determine the necessary changes and
updates required for any affected requirements and artifacts.
Traceability affects the organization in the following areas (K2):
 Scope management
 Impact analysis
 Coverage analysis
 Use-of-potential analysis
 Proof of implementation
 Use of the requirement
 Defect reports
Requirements Management tools are used for storing the requirements of all specifications of a
technical system under development. These requirements are usually arranged in a specification
“tree”, and are linked to their "parent" requirement in the higher-level specification. This parent/child
relationship is a form of traceability.
Requirements are implemented as design artifacts, code, test cases, etc. Each of these artifacts
should be traced back to the requirement(s) from which they originated. This is typically done via a
Requirements Traceability Matrix (RTM).

4.4. Requirements Documentation (K3) 40 minutes
In some cases, in addition to documenting requirements, the Business Analyst also documents
business processes that are performed within an organization. Business processes may be
documented using process flow diagrams such as Business Process Modeling Notation (BPMN) or
Domain Specific Language (DSL). Processes may also be described in more detail via written text.
This is helpful in complex and large projects, when understanding the overall project scope requires
knowledge of the exact flow of the processes, inputs, outcomes, and dependencies between
separate activities.
4.4.1. Documenting the Requirements (K2)

When documenting particular requirements, the Business Analyst should follow common standards
and guidelines. Using standardized documentation increases quality and readability, and helps
ensure that all readers will have a similar understanding of the content.
In the specification, requirements are described in a structured way and are modeled separately.
The specification serves to track and manage the individual requirements. An approved
requirements specification serves as a formal agreement and scope definition, and provides input
information for the other members of the project team (e.g., systems analysts, developers, testers
etc.).
Important guidelines for the creation of the requirements document include the following:
 Each requirement must be unambiguous, precise, and understandable.
 Superfluous information should be avoided.
 Templates should be used as an aid.
 Models and diagrams should be used to make the specification document clear and more
understandable for readers.
 Formal graphical notation should be used as a method for presenting complex
requirements, dependencies, and relationships.
The standard contents of a requirements document include (K1):
 Introduction
 Secrecy clause
 Regulations
 Standards
 Stakeholders
 Purpose of the product
 Overall description
 Functional requirements
 Non-functional requirements
 Assumptions
 Dependencies
 Risks
 Safety requirements
 Document acceptance
When creating a requirements document, the Business Analyst should remember that requirements
specifications must be complete, consistent, modifiable, and traceable [Wiegers].
4.4.2. Common Mistakes in Requirements Documentation (K2)

In practice, there are often many issues affecting the quality of such documentation. Some of the
most common mistakes are [T. Simon, J. Streit, and M. Pizka]:
 Trivialities - Lengthy descriptions of commonly known issues should not be included.
 Information out of scope - Information that does not add any value to the description of the
solution to be built should not be included into documentation.
 Thinking in solutions - In many cases, the author of the requirements documentation
provides a description of solutions (such as technical details that would drive the
implementation). The requirements specification should discuss the problem to be solved
not the technical design of the solution.
 Redundant details - Details that unnecessarily complicate the implementation should not be
included. This problem is related to “Thinking in solutions” as the author (frequently having
some implementation experience) suggests desired implementation details and goes into a
detailed description.
 Lacking rationale - Requirements documents should describe what shall be achieved with
the software system, and component or particular features. The concrete requirements may
be described at an appropriate level of detail (including concrete numbers and metrics).

4.5. Communication (K2) 20 minutes
Requirements Communication includes activities for expressing the output of the requirements
analysis, and documentation to the stakeholders. Communication of requirements is an ongoing
and iterative activity, including presenting, communicating, verifying, and obtaining approval of the
requirements from the project stakeholders.
Communicating requirements is one of the major tasks of the Business Analyst; their responsibility
is to not only identify and document the customer‟s requirements, but also to bring the stakeholders
to a common understanding of the requirements and resulting solution.
Clear and effective communication is essential, as the stakeholders may have different knowledge
and represent different domains. The role of a Business Analyst is to communicate requirements in
a way that allows all stakeholders to gain the same understanding of a particular requirement. To
ensure this, the Business Analyst must consider what communication approach is appropriate in a
given situation.
4.5.1. Requirements Communication Process (K2)

The Requirements Communication Process includes the following activities:
 Preparing the requirements communication plan
 Managing requirements conflicts
 Establishing the most appropriate requirements format
 Creating the requirements package
 Conducting requirements presentations
 Performing formal requirements reviews
 Obtaining requirements approvals (Sign-off)
4.5.2. Requirements Acceptance (K2)

Requirements should be agreed to and accepted by all stakeholders that are responsible and
dedicated to this task. It is extremely important to ensure that all requirements are formally
approved since the formal agreement is a starting point for a further detailed system specification,
designing the architecture, and other aspects of the planned system.
Requirements usually are accepted by the following stakeholders:
 Project Manager
 Business Analyst
 Business Analyst on customer side
 Architects (on both sides)
 Test/QA Manager

The list of requirements is binding for both the vendor and the customer. This means that once the
requirements are agreed and accepted, the baseline requirements then define the design of the
system. Any changes in the scope or content of the requirements must be managed via Change
Management.

4.6. Standards (K2) 10 minutes
The following standards are applicable to the Business Analysis process:

ISO 25000 (previously ISO/IEC 9126) defines a quality model with the following six quality
characteristics:
 Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability
IEEE 830:
Recommended Practice for Software Requirements Specifications
IEEE 1233:
Guide for Developing of System Requirements Specifications
IEEE 1362:
Guide for Information Technology – System Definition

5. Requirements Analysis (K3) 240 minutes
Terms:
Assumption, BPMN, checklist, constraint, decomposition, goal, goal decomposition, feature list
decomposition, functional decomposition, modeling, quality assurance, review, specification,
structuring, UML, verification, validation
Learning Objectives for Requirements Analysis

5.1 Requirements Organization (K2)

LO-5.1.1 Explain the reasons for organizing requirements. (K2)
LO-5.1.2 Describe how requirements can be organized. (K2)
LO-5.1.3 Recall the common types of decomposition. (K1)
5.2 Modeling and Specification (K3)

LO-5.2.1 Describe, with examples, how requirements can be modeled. (K2)
LO-5.2.2 Apply common techniques that are used for requirements modeling (BPMN, UML).
(K3)
LO-5.2.3 Explain the purpose of GUI prototyping. (K1)
5.3 Defining Assumptions and Constraints (K2)

LO-5.3.1 Define assumptions and constraints. (K1)
LO-5.3.2 Explain how assumptions and constraints may affect Business Analysis. (K2)
5.4 Verification and Validation (K1)

LO-5.4.1 Explain the difference between verification and validation. (K1)
5.5 Quality Assurance (K2)

LO-5.5.1 Explain the importance of high-quality requirements in the solution lifecycle. (K2)
LO-5.5.2 Explain how reviews can help improve the quality of requirements. (K2)

5.1. Requirements Organization (K2) 40 minutes
Requirements can be organized (structured) into packages. This packaging conforms to the
boundaries (limitations) and solution scope established during Enterprise Analysis and helps to
further define those boundaries.
The Business Analyst decomposes the problem model to make each requirement more detailed
and to ensure that the model correctly reflects the boundaries for the business problem.
Decomposition allows the Business Analyst to clarify the requirements (functional and non-
functional as well as supplemental requirements) and ensures the proper level of detail is achieved.
5.1.1. Decomposition (K2)

Common types of decomposition used to define the structure of requirements and the scope
boundaries are:
 Goal decomposition
 Goals are business requirements. (K1)
 Goal decomposition helps to ensure the solution will satisfy stakeholder‟s needs.
 Feature list decomposition
 A feature is a service that the solution provides to fulfill one or more stakeholder need.
(K1)
 A feature is understood as an abstraction of the solution of the problem expressed at a
high-level. A feature is developed into completely described functional and
supplemental requirements.
 Functional decomposition
 Functional decomposition is a breakdown of a list of items into classifications or groups
based on the function each item performs or the use it provides. (K1)
 Functional decomposition identifies the high-level functions of the proposed solution, or
the organization itself, and then breaks them down into sub-processes and activities.
 The purpose of functional decomposition is to break functions down into smaller pieces
to analyze the processes in detail and to ensure proper coverage of all major
processes.
 Functional decomposition is usually performed by a Systems Analyst.
 Functional decomposition can be used to hierarchically decompose a system into
functional components.
 Functional decomposition can be used to hierarchically decompose a business process
into sub-processes.
 Functional decomposition provides a definition of all the business functions and sub-
functions identified as system requirements.

5.1.2. Levels of Detail for Functional Decomposition (K2)

There are several levels of detail that are used during functional decomposition. These are:
 Enterprise Level of Detail - In this approach, the root of the decomposition diagram may
contain the name of the organization or a major function within an organization. The second
level typically represents major business functions (e.g., Planning, Execution, Control).
 Conceptual Level of Detail - The conceptual level identifies the major business processes
needed to accomplish each function that was defined at the lowest level of the Enterprise
Level of Detail. Processes identified at this level typically reflect application systems or
sub-systems (e.g., Marketing, Sales, Finance).
 Logical Level of Detail - At the logical level, the decomposition diagram decomposes
processes into the lowest level of detail. At this level all the processes within the scope of
the project are identified.

5.2. Modeling and Specification (K3) 80 minutes
5.2.1. The Concept of Modeling (K1)

Modeling is a way of expressing requirements by representing parts, or the whole, of the proposed
solutions. Models may contain textual elements, matrices and diagrams, and are used to reflect the
relationships and dependencies between the requirements that fulfill the identified business needs.
In case of large and complex software systems requirements, modeling is helpful in expressing the
overall structure of the solution. In addition, presenting complex requirements and relationships in
the form of a model, especially some graphical form such as diagrams, helps ensure the solution is
understood by other stakeholders. Models are often easier to read and comprehend than written
text.
Expressing requirements in the form of models may be helpful in the process of requirements
specification; however, it is not required and may be omitted in some cases. The decision to
perform requirements modeling should be driven by the scope and complexity of the solution and
by the vendor and/or customer‟s organizational standards and applied approach. The organization
may skip modeling in the following situations:
 The solution is fully understood by the stakeholders and is easy to implement.
 The requirements are mostly non-functional and difficult to express in the form of a model.
 The problem domain is well known.
 The solution is dedicated to use by very few people.
 The scope is declared as constant and there is a low probability of changes in the scope
resulting from future requirements or needs.
 It is established that the model representation would be less understandable by the key
stakeholders than written text (e.g., no knowledge or experience with UML).
The benefits of using requirements modeling are:
 Models are perceived as a simplified expression of real processes and allow the Business
Analyst and other stakeholders to focus on the important aspects and areas of the solution.
 Models describe a complex system in the most clear and unambiguous way.
 Models are more readable than written text.
 Models present the whole system and its context in a single diagram and therefore help to
look at the problem from the overall perspective.
Common techniques of modeling requirements include (K3):
 Using UML notation to express requirements as use case diagrams, activity diagrams,
component diagrams, state machine diagrams, etc.
 Using BPMN notation to express business processes.
 Using DSL, a specification language dedicated to a particular problem domain, a particular
problem representation technique, and/or a particular solution technique.

 Using SysML notation to develop specifications, analysis, design, verification and validation
documentation for systems and systems-of-systems. The specifications may include
hardware, software, information, processes, personnel and facilities.
 Using prototyping as a technique of GUI modeling.
5.2.2. Business Processes Modeling (K2)

Business processes may be modeled using a technique such as BPMN. This modeling provides a
view into the various processes performed within an organization. It helps the reader to understand
the organization‟s processes and supports effective requirements analysis and modeling to ensure
the proposed solution meets the needs of the current business processes.
As the complexity of business processes continues to increase, it needs to be properly managed.
There are six main quality criteria for business process models [Becker J., Kugeler M., and
Rosemann M.]:
 Correctness (syntactic and semantic correctness)
 Relevance (no irrelevant details)
 Economic efficiency (designed for a particular purpose)
 Clarity (understandable by the audience)
 Comparability (based on the same modeling conventions within and between models)
 Systematic design (contains well-defined interfaces to other types of models)
Business Process Modeling is a part of Business Process Management (BPM) (K1).
5.2.3. GUI Prototyping (K2)

Prototyping allows the visualization of the interface requirements before the application is designed
or developed.
The purpose of prototyping is to create “mock ups” of the screens or report layouts for an
application. Prototyping assists in identifying, describing and verifying GUI interface needs,
especially in the case when users, or other stakeholders, are not able to articulate their
expectations and requirements without seeing the proposed versions of the GUI interface.
There are two types of GUI prototypes (K1):
 Static – Screens or layouts without any business logic running behind the visualization, only
“mock ups”.
 Dynamic – Application prototypes that allow navigation through the screens and simulate
real business processes. This kind of prototyping can be used to perform some usability
testing.
5.2.4. Ten Key Principles for Successful Requirements (K2)

There are ten key principles that have been defined to help ensure the success of the requirements
[Gilb and Brodie RQNG]. They are:
1. Understand the top level critical objectives.
2. Think stakeholders, not just users and customers.
3. Focus on the required system quality, not just its functionality.

4. Quantify quality requirements as a basis for software engineering.

5. Don‟t mix ends and means.
6. Capture explicit information about value.
7. Ensure there is “rich specification”; requirement specifications need much more information
than just the requirement itself.
8. Carry out specification quality control (SQC).
9. Consider the total lifecycle and apply systems-thinking, not just a focus on software.
10. Recognize that requirements change; use feedback and update requirements as
necessary.

5.3. Defining Assumptions and Constraints (K2) 30 minutes
5.3.1. Constraint (K1)

A constraint is a requirement that explicitly and intentionally tries directly to restrict any system or
process. Constraints include limitations on the engineering process, a system‟s operation or its
lifecycle [TGilb].
The purpose of defining constraints is to inform the stakeholders that options they would normally
be allowed to consider are not available.
There are two types of constraints, as follows (K2):
 Business constraints - Business constraints describe the limitations on the project‟s
flexibility to implement the requested solution. They may reflect financial or time restrictions,
limits on the number of resources available, skills of the project team, or other
organizational restrictions.
 Technical constraints - Technical constraints are any restrictions that are related to the
architecture of the solution such as hardware and software platforms, programming
language or technology, and software that must be used. Technical constraints also include
restrictions such as database size, resource utilization, message size and timing, software
size, maximum number of and size of files, records and data elements.
5.3.2. Assumption (K1)

Assumptions are conditions that are believed to be true, but have not yet been confirmed.
Assumptions can be defined as unproven conditions, which, if proven to be untrue at some defined
point in time, would have a negative effect and might impair the ability to achieve the proposed
solution [TGilb].
There are two types of assumptions related to Business Analysis:
 Business assumptions
 Requirements assumptions
The purpose of defining business assumptions is to inform the project team of key stakeholder
expectations.
The purpose of defining requirements assumptions is to transfer business domain knowledge to the
project team.
It is important to notice that assumptions are used to document two types of issues:
 Issues identified by the Business Analyst as likely to be true, but impossible to verify
 Issues identified by the Business Analyst as true in the current situation, but subject to
change that could have a negative or even a destructive impact on the project
Assumptions and constraints identify aspects of the problem domain that can limit or impact the
design of the solution, but are not functional requirements.
In some cases assumptions become constraints of the solution.

5.4. Verification and Validation (K1) 40 minutes
5.4.1. Validation (K1)

Validation is an activity of confirmation by examination and through the provision of objective
evidence that the requirements for a specific intended use or application have been fulfilled [ISO
9000].
The goal of validation is to ensure that the stated requirements correctly and fully implement the
business requirements that are determined in the Enterprise Analysis and Requirements
Identification phases.
Validation techniques include (K1):
 Workshops with key stakeholders
 Demonstrations of the solution
 Reviews of the requirements documentation
5.4.2. Verification (K1)

Verification is a confirmation by examination and through the provision of objective evidence that
specified requirements have been fulfilled [ISO 9000].
Verification ensures that requirements are defined clearly enough to allow solution design,
implementation and test preparation to begin. To complete the verification process, it is required to
involve and cooperate closely with the customer, users and the project team.
Requirements can be stated as verified only if:
 Project stakeholders have agreed that the requirements are correctly understood.
 A Business Analyst has validated the requirements with the customer and user, and has
confirmed that the requirements completely describe what has to be implemented and that
they are of high quality.
A common technique for solution verification is testing (K1). Testing may involve software
components and/or documentation, or any other work product from the Business Analysis.

5.5. Quality Assurance (K2) 50 minutes
Quality Assurance is a process of systematic monitoring and evaluation of the various aspects of a
project or solution. The goal is to maximize the probability that the solution has achieved a desired
standard of quality.
5.5.1. Quality Criteria for Requirements (K1)

The quality criteria for requirements include the following items:
 Allocatable
 Complete
 Consistent
 Correct
 Does not determine solution
 Feasible
 Measurable
 Necessary
 Prioritized
 Testable
 Traceable
 Unambiguous
 Understandable
5.5.2. Checklists (K1)

One of the most common techniques for requirements‟ quality control is the use of checklists.
Checklists may include a standard set of quality elements, or customized (adjusted to the specific
project) quality elements that the Business Analyst will use to validate the Requirements
Specification.
The following shows two sample checklists for different types of projects.
General Checklist:
 Is a functional overview of the system provided?
 Are software and hardware environments specified?
 Are there any assumptions that affect implementation? Are they documented?
 Is the functionality of hardware/software interacting with the system specified?
 Has every acronym been defined in the Dictionary?
 Are all the requirements, interfaces, constraints, etc., listed in the appropriate sections?
Interface Checklist:
 Are all inputs to the system specified?
 Are all outputs from the system specified?
 Are all screen formats specified?
 Are all report formats specified?
 Are all interface requirements between hardware, software and procedures included?
5.5.3. Reviews (K1)

Other common techniques for requirements quality assurance are reviews. A Business Analyst
should ensure that outcomes of their work have been reviewed, and any major issues identified and
resolved as a post-review follow up activity.
A review is an evaluation of a product, or project status, to ascertain discrepancies from planned
results and to recommend improvements. There are several types of reviews: management
reviews, informal reviews, technical reviews, inspections, walkthroughs and audits [IEEE 1028].
In particular, the following review types are commonly used to verify the work products from
Business Analysis:
 Peer review – A review of a work product by colleagues of the author of the product for the
purpose of identifying defects and improvements.
 Technical review – A group discussion focused on achieving consensus on the technical
approach to be taken.
 Walkthrough – A step-by-step presentation of a document in order to gather information,
and to establish a common understanding of its content [Freedman and Weinberg, IEEE
1028]. A walkthrough is conducted by the author of the document.
 Inspection – A type of formal review that relies on visual examination of documents to detect
defects (e.g., non-conformance to higher level documentation, or to development standards).

6. Solution Validation (K3) 70 minutes
Terms:
Solution assessment, validation
Learning Objectives for Solution Validation

6.1 Assessment (K2)

LO-6.1.1 Explain reasons for solution assessment. (K2)
LO-6.1.2 Provide examples of solution assessment techniques. (K2)
6.2 Validation (K3)

LO-6.2.1 Recall common validation techniques and methods. (K1)
LO-6.2.2 Explain when validation should be performed. (K2)
LO-6.2.3 Plan basic activities for solution validation. (K3)

6.1. Assessment (K2) 30 minutes
The goal of the solution assessment is to evaluate its appropriateness and compliance with the
requirements (K2).
After handing over the requirements to the development team, the Business Analyst is expected to
assess the design and the implementation increments that are returned to the project team. The
Business Analyst is usually the best person to assess the appropriateness of the solution design, in
terms of its alignment with the stated requirements. Others, such as the sponsor and project
manager, may have more ability to assess the value provided for the money spent. The Business
Analyst will check the solution for compliance with the agreed requirements and will provide
feedback to the development team.
The following tools may be used to assess the solution‟s comprehensiveness:
 Requirements Traceability Matrix (RTM)
 Tracing features to Use Cases
 Requirements specifications documents
 Demonstrating the software (prototype) to the customer
 Getting the customer feedback
RTM is a document that correlates two baselined documents that require a many to many
relationship (a type of cardinality that refers to the relationship between two entities) to determine
the completeness of the relationship. RTM often correlates high-level requirements and detailed
requirements of the software product with the matching parts of the high-level design, detailed
design, test plan, and test cases. RTM is usually presented in the form of a table.

6.2. Validation (K3) 40 minutes
Solution validation is the activity of demonstrating, explaining and confirming the solution's
appropriateness to stakeholders and sponsors. This often involves explaining technical concepts to
stakeholders who have only business knowledge.
The role of the Business Analyst is to ensure that all involved people have a common
understanding of the proposed solution, and to validate if the solution meets the stakeholder‟s
needs and expectations.
In some cases, the validation process must be followed by a written approval.
Solution validation also involves managing test activities. The test strategy and test plan govern the
test activities. The Business Analyst provides information that is used for test planning and creating
test specifications, and also supports the work related to preparing tests cases that will cover the
requirements.
Once the solution design has been agreed upon, the Business Analyst should support the
development team during the detailed design of the application. This includes performing the
following tasks:
 Supporting functional specification creation
 Helping to build usability
 Reviewing the technical design deliverables
In order to ensure the most effective system development and testing, the Business Analyst should
also participate in planning the development of particular parts (e.g., components, modules) of the
software system. Because the Business Analyst has the best knowledge about the process(es)
being implemented, and knows the dependencies and relationships between specific parts of the
process, they may be able to provide advice regarding an effective and logical way of splitting the
whole functionality into increments.
In the case of COTS (Commercial-Off-The-Shelf) systems or components, the Business Analyst
should provide advice on required customization work, as well as helping define the interface
requirements.
Once the solution or a component of the solution is implemented and delivered for testing, the
Business Analyst supports the testing team. The Business Analyst should understand the activities
performed by the testing team and their objectives, and should be available to give advice on the
testing of the solution. The Business Analyst may be requested to review test deliverables (e.g., test
plans, test cases, test scenarios, test data) to ensure that the requirements and business risks are
covered by testing. In some cases the role of the BA is to review and verify test results.
One of the Business Analyst‟s responsibilities is to support business stakeholders with user
acceptance testing, defect reporting and resolution. In fact the Business Analyst often prepares or
participates in the preparation of the UAT (User Acceptance Test) test cases.
Due to changes requested for the system (resulting from change requests including new
requirements, next phase issues, and any other post implementation support), the system
development may not end with releasing the system to production. The Business Analyst is involved
in identifying and managing all changes to the requirements, and should make sure that the
production rollout of any change is completed as smoothly as possible.

7. Tools and Techniques (K3) 80 minutes
Terms:
Five Why‟s, CATWOE, GUI prototyping tools, modeling tools, MoSCoW, MOST, tools, PESTLE,
process simulation tools, requirements management tools, SWOT
Learning Objectives for Tools and Techniques

7.1 Business Analysis Tools (K2)

LO-7.1.1 Explain the purpose of Requirements Management tools and provide proper
examples. (K2)
LO-7.1.2 Explain the purpose of Modeling tools and provide proper examples. (K2)
LO-7.1.3 Explain the purpose of Supporting tools and provide proper examples. (K2)
LO-7.1.4 Explain the purpose of Process Simulation tools and provide proper examples. (K2)
7.2 Business Analysis Techniques (K3)

LO-7.2.1 Recall common Business Analysis techniques. (K1)
LO-7.2.2 Given a specific scenario, apply the appropriate Business Analysis techniques. (K3)
LO-7.2.3 Explain when using a specific technique would be helpful. (K2)

7.1. Business Analysis Tools (K2) 30 minutes
Requirements Management activities may be supported by various tools, methods and techniques.
The simplest tools are the spreadsheets and word processors that store the information related to
the requirements. However, in most cases, managing and maintaining requirements in such form
may be ineffective and too time-consuming. Especially in the case of large and complex projects
that contain a huge number of requirements, often with many dependencies, this approach is not
effective and does not ensure the quality of Requirements Management or the requirements
themselves. (K2)
7.1.1. Requirements Management Tools (K2)

A Requirements Management tool is a tool that supports the following activities:
 Recording requirements
 Defining requirement attributes (e.g., priority, responsibility) and annotations
 Traceability through layers of requirements
 Traceability to other system and development tools
 Requirements Change Management
 Static analysis (e.g., consistency checking and violations to pre-defined requirements rules)
 Approval history tracking
7.1.2. Modeling Tools (K2)

Apart from Requirements Management tools, which collect and store requirements, there are also
Modeling tools. Modeling tools provide the capability to:
 Link requirements together in models presenting their relationships and dependencies, and
representing the business structure of the software system
 Create graphical representations of the requirements
 Represent relationships between requirements, and between requirements and other
artifacts
 Establish and maintain traceability
 Design the overall structure of the system including hardware, software, people, etc.
(SysML)
7.1.3. Other Tools (K2)

In addition to Requirements Management and modeling tools, the Business Analyst may use
several supporting tools such as GUI design tools.
GUI prototyping is a helpful technique that allows demonstration of the system design to the
stakeholders; it also serves as an aid to implementation. Elements of the GUI may be designed in
the form of static screens or dynamic (“working”) prototypes of the application. The second solution

allows the user to navigate through particulate system screens and may be used to conduct initial
usability verification.
Prototyping, either static or dynamic, is very helpful when the requirements are not clear and the
software purchaser (customer) is not able to articulate his needs and expectations. Presenting such
demonstrations to the stakeholders can help them to determine the desired functionality, navigation
and the appearance of the application.
Other helpful techniques for the Business Analyst are:
 Mind mapping
 Ishikawa diagrams
Mind Mapping
A mind map is a diagram used to represent ideas, tasks or other items that are linked to, and
arranged around, a central key word or idea. Mind maps generate, visualize, structure, and classify
ideas, and are a great aid for studying and organizing information, solving problems, making and
documenting decisions. Mind mapping can be used to identify and analyze requirements.
Ishikawa Diagrams
Ishikawa diagrams (also called fishbone diagrams or cause-and-effect diagrams) show the causes
of a certain event. The Ishikawa diagram is often used in product design and quality defect
prevention, and identifies potential factors causing an overall effect. Each cause or reason for a
defect is a source of variation. Causes are grouped into major categories to identify these sources
of variation. Ishikawa diagrams may be used to identify the causes of problems detected in an
organization, thus helping to determine and implement solutions for the problem [Ishikawa].
An Ishikawa diagram may be created on a simple piece of paper or by using software applications.
7.1.4. Process Simulation Tools (K2)

Process simulation is model-based software that represents various processes and unit operations
performed within an organization. Basic prerequisites for using these tools include a thorough
knowledge of the processes and their associated attributes. This information is used by the
software to discover the weak points in the process flow. By changing various parameters (such as
resource allocation), the process can be optimized.
Process simulation requires creating a model of the processes in the organization and configuring
their parameters (e.g., duration of particular activities or processes, resource usage). Such models
can be designed using BPMN or other forms of business process modeling. By running the
simulation, the Business Analyst can watch the sequence of the different activities, and can
determine weak and strong points in the current process.
Process simulation can be used to discover the optimal conditions for a specific process or set of
processes.

7.2. Business Analysis Techniques (K3) 50 minutes
There are a number of techniques that a Business Analyst can use to increase the effectiveness of
the work. These range from workshop facilitation techniques, used to elicit requirements, to different
techniques for analyzing and organizing requirements.
Two techniques that are used to perform external and internal environmental analysis are PESTLE
and MOST.
The PESTLE technique is used to perform an external environmental analysis by examining
external factors that affect an organization. PESTLE analyzes the following six attributes:
 Political
 Economic
 Sociological
 Technological
 Legal
 Environmental
The MOST technique is used to perform an internal environmental analysis to ensure that the
project is aligned to each of the following four attributes:
 Mission
 Objectives
 Strategies
 Tactics
In addition to MOST and PESTLE, other analysis techniques are used to define the environment
and general requirements of a project or set of projects. These are discussed below.
SWOT
SWOT analysis is used to determine the strengths and weaknesses of the organization, and to
identify opportunities and dangers in the form of both internal and external threats. Using SWOT
analysis, the organization may focus its efforts on areas of strength and capitalize on opportunities.
The four attributes of SWOT are:
 Strengths
 Weaknesses
 Opportunities
 Threats

CATWOE
CATWOE is a technique that helps identify and analyze what the business is trying to achieve. This
business perspective helps the Business Analyst understand the impact of any proposed solution
on the people involved. The six elements of CATWOE are the following:
 Customers
 Actors
 Transformation Process
 World View
 Owner
 Environmental Constraints
Five Why's (5 x Why)

The 5 x Why technique is used to get at the root of what is really happening in a situation. For each
answer given, a further “why” is asked. This technique can help to identify additional requirements
and analyze requirements more deeply.
MoSCoW
The MoSCoW technique prioritizes requirements by allocating an appropriate priority expressed in
the following terms:
 Must have
 Should have
 Could have
 Would like to have in the future
Requirements defined as “Must have” and “Should have” should be implemented correctly or the
solution will be rejected. “Could have” requirements are not necessary to satisfy the business needs
established for the project, but increase delivery satisfaction. Requirements marked as “Would like
to have” are less important, and considered as non-crucial needs that can be planned in the future
and are not necessary now.
Other Techniques
Other common Business Analysis techniques are:
 Six Thinking Hats – This technique is often used in a brainstorming session to generate and
analyze various ideas and options. It restricts the members of the working group by forcing
them to think in specific ways - giving ideas and analysis in the “mood” of the time.
 VPEC-T – This technique is used when analyzing the expectations of multiple parties that
have different views of a system (e.g., different priorities, different responsibilities), but in
which they all have a common interest. VPEC stands for: Values, Policies, Events,
Content.

8. Competencies (K2) 90 minutes
Terms:
Domain, facilitation, facilitator, soft skills
Learning Objectives for Competencies

8.1 Domain Knowledge (K2)

LO-8.1.1 Explain why business and domain knowledge is necessary. (K2)
LO-8.1.2 Provide examples for business knowledge required for different areas of the
Business Analyst‟s work. (K2)
8.2 Soft Skills (K2)

LO-8.2.1 Recall common soft skills required in the work of the Business Analyst. (K1)
LO-8.2.2 Explain why soft skills are necessary to achieve success as a Business Analyst.
(K2)
8.3 Facilitation Skills (K2)

LO-8.3.1 Explain facilitation, using examples. (K2)
LO-8.3.2 Recall common facilitation techniques and tools. (K1)
LO-8.3.3 Explain when facilitation may support a Business Analyst‟s work. (K2)

8.1. Domain Knowledge (K2) 20 minutes
The goal of a Business Analyst is to provide business solutions (with or without involving
technology) to business issues by assessing business problems, and identifying and analyzing root
causes. The success of Business Analysis is determined by the benefit that the solution provides to
the business either in terms of savings in costs, improvement in productivity, and/or increase in
customer satisfaction.
To be able to provide a business solution that provides a measurable benefit to the organization,
the Business Analyst must have knowledge of the business domain. Understanding the business,
its rules, processes, risks and context, is a necessary condition for effective and valuable Business
Analysis.
Some of the reasons why domain knowledge is important include:
 Domain knowledge makes it easier for the Business Analyst to connect and communicate
with Business Users.
 Domain knowledge makes understanding and analyzing business issues easier.
 Lack of domain knowledge may lead to delays in providing the solution, since the business
process and business rules must first be understood.
Domain knowledge is not a replacement for Business Analysis methods. Both domain knowledge
and methods knowledge are needed to be a good Business Analyst.
Related to domain knowledge, the Business Analyst must also understand the domain environment.
The Business Analyst needs the following skills to effectively understand and work within the
defined environment (K1):
 Analytical skills
 Financial analysis
 Statistical analysis
 Operations research
 Requirements analysis
 Systems analysis
 Technical skills
 Working knowledge of technology
 Understanding of engineering principles
 Ability to apply financial principles to feasibility studies
 Managerial skills
 Project management capabilities
 Understanding of organizational behavior

8.2. Soft Skills (K2) 20 minutes
Business domain knowledge, analytical skills, and experience are not the only factors that
determine the success of an individual as a Business Analyst. In addition to business and technical
competencies, the Business Analyst needs to possess a minimum set of soft skills. This is because
the work of a Business Analyst is closely related to effectively communicating and cooperating with
various people. Common Business Analysis activities include negotiating, discussing and resolving
conflicts.
The Business Analyst should possess the following soft skills:
 Negotiation skills:
o Ability to negotiate to obtain data
o Ability to negotiate with stakeholders to implement projects
 Communication and writing skills:
o Ability to communicate with all levels of management
o Ability to communicate with stakeholders of various knowledge levels
o Precision in articulating ideas and thoughts
o Ability to relate with line workers
o Good technical writing skills
o Strong communication skills in all forms (verbal, non-verbal, written, etc.)
o Public speaking skills
In addition, the Business Analyst must be an effective facilitator. Facilitation skills are discussed in
the next section.

8.3. Facilitation Skills (K2) 50 minutes
8.3.1. Facilitation (K2)

Facilitation can be defined as a process of enabling groups to work cooperatively and effectively.
Facilitation provides leadership [I. Bens].
Facilitation serves to improve the following skills:
 Leading
 Solving issues
 Building team and community
 Empowering
 Resolving conflicts
 Transforming
 Evoking wise democracy
 Building personal effectiveness
8.3.2. Facilitator (K1)

A facilitator is a person who contributes structure and process to interactions so that groups are
able to function effectively and make high-quality decisions. The facilitator‟s goal is to support
others and enable them to achieve high performance [I. Bens].
Some of the facilitator‟s tasks and activities are:
 Helping the group to define its goals and objectives
 Providing processes to support members of the group to help them use their time effectively
and to make high-quality decisions
 Guiding group discussions to ensure objectives are met, and noting any ideas and concepts
raised by members during the discussion
 Supporting members of the group in assessing their current skills and building new skills
 Using consensus to enable the group to make decisions
 Managing conflicts using a collaborative approach
 Helping the group to communicate effectively and to access resources needed to make
decisions
The facilitator must always stay neutral, listen actively and ask questions that allow the group to
identify and collect ideas and concepts. One of the facilitator‟s tasks is to note and summarize all
ideas raised by the members of the group.

A key competency of the Business Analyst is effective facilitation. This competency is composed of
an essential set of skills necessary for working with a group of stakeholders to elicit, document,
analyze, verify and achieve consensus on requirements.
In order to be effective, a Business Analyst must also be a good facilitator. A good facilitator
demonstrates the following competencies (K1):
 Communicates well
 Processes ideas from people
 Shows a natural interest
 Listens well
 Maintains control
 Empowers the group
 Handles uncertainty
 Connects with the group quickly
 Focuses on the business not on personal solutions
 Negotiates between parties
 Understands group dynamics
 Helps the group to listen and draw logical conclusions
 Runs meetings
 Manages people‟s expectations
 Understands and explains the process
Many Business Analysts lack formal training and experience as facilitators, and sometimes have
difficulty running a facilitation session. In the context of Requirements Development, facilitation
techniques focus on the skills necessary to elicit and analyze the requirements for a project.
Knowing what to ask, how to ask, and how to help the stakeholders discover their requirements, are
all critical skills for the Business Analyst role.
8.3.3. Tools and Techniques of Facilitation (K1)

There are a number of techniques that are commonly used for facilitation. These techniques
include:
 Applying engagement strategies
 Creating participation
 Generating and organizing data
 Initiating reflection
 Mobilizing energy
 Igniting action
 Recording information
 Applying SWOT analysis

Some of the tools used in facilitation include:

 Gap analysis
 Flipcharts
 Checklists
 Multi-voting
 Root cause analysis
 Brainstorming
 Managing conflicts tips sheet
 Focus group framework

9. Process Improvement (K2) 80 minutes
Terms:
Business Process Improvement (BPI), Business Process Simulation (BPS), optimization, process
improvement, process simulation
Learning Objectives for Process Improvement

9.1 Process Improvement (K2)

LO-9.1.1 Explain Process Improvement and its purpose and possible applications. (K2)
LO-9.1.2 Recall common methodologies and strategies that are useful for Process
Improvement. (K1)
LO-9.1.3 Explain the concept of BPI. (K2)
9.2 Process Simulation and Re-design (K2)

LO-9.2.1 Explain process simulation. (K2)
LO-9.2.2 Explain the role of process simulation and re-design in Business Analysis. (K2)

9.1. Process Improvement (K2) 30 minutes
9.1.1. Process Improvement (K1)

Process Improvement supports the introduction of change into the current process in order to
improve quality, reduce costs and/or accelerate schedules.
Supporting Process Improvement is one of the tasks of a Business Analyst. The Business Analyst
models and analyzes business processes used within an organization in order to discover any
ineffective elements. Such analysis focuses on finding any bottlenecks, elements with excessive
resource usage, or activities that take too much time. With this knowledge, the Business Analyst is
able to refine the process and improve it.
Improving business processes may be accomplished in the following ways:
 Manually re-design processes on the basis of experience and domain knowledge with the
goal of eliminating bottlenecks and making the execution times shorter and more efficient
 Introduce tools, including software, to optimize the business processes in the organization
(e.g., SAP, ERP, CRM software)
 Simulate and optimize processes
 Adopt a selected methodology or strategy
Process Improvement is a set of actions taken by a Process Owner to identify, analyze and improve
existing processes within an organization to meet new goals and objectives.
Process Improvement efforts often follow a specific methodology or strategy such as (K1):
 Benchmarking
 Business process improvement
 Business process reengineering
 Capability Maturity Model Integration/Capability Maturity Model (CMMI/CMM)
 ISO 9000
 IT Governance
 Just In Time manufacturing
 Lean manufacturing
 Performance improvement
 Process management
 Process Improvement and Management (PI&M)
 Six Sigma
 Total Quality Management (TQM)

9.1.2. Business Process Improvement (K1)

Business Process Improvement (BPI) is defined as a systematic approach to optimize an
organization‟s processes to achieve more efficient results. The goal of Business Process
Improvement is to significantly change the performance of an organization.
BPI is conducted in three steps (K2):
1. Define the organization's strategic goals and purposes together with the existing structure
and processes (define the “as-is”)
2. Determine the organization's customers or stakeholders, identify what outcomes would add
value to the organization's objectives and determine what would be the best way to align its
processes to achieve those outcomes (define the “to-be”)
3. Re-organize the business processes to realize the goals and meet the new objectives,
using the tools available within the BPI methodology
There are four roles within the BPI (K2):
 Business Leader - The Business Leader is responsible for developing business plans
(including strategic plans) and resource plans needed to make the organization successful.
 Process Owner - The Process Owner is responsible for designing the processes necessary
to achieve the objectives of the business plans created by the Business Leaders. The
Process Owner creates, approves and maintains the documents (e.g., procedures, work
instructions/protocols) that support the process.
 Operational Manager - The Operational Manager is responsible for organizing the
resources and processes that achieve the objectives of the business plans created by the
Business Leaders. The Operational Manager instructs and teaches the Process Operators
how to perform the processes.
 Process Operator - The Process Operator learns and performs the processes necessary to
achieve the objectives of the business plans that are created by the Business Leaders. The
Process Operator ensures that the processes are performed to meet the process
performance objectives and to produce a product which meets the specifications.
Each of the roles has different responsibilities but they work together.

9.2. Process Simulation and Re-design (K2) 50 minutes
Business Process Simulation (BPS) is a part of Business Process Management (BPM), specifically
focused on evaluating designed and re-designed business processes.
Business Process Simulation is a technique that simulates the execution of business processes and
their parameters over time, based on process models. Such models must represent not only the
specific elements of the business process, but its attributes as well (e.g., execution time, resource
usage, costs). Running such simulations provides a way to check how the process is performed, to
determine the resource usage at every step of the process, and to find the potential bottlenecks and
areas of instability.
Business Process Simulation allows the Business Analyst to understand, analyze and design (or re-
design) business process models with respect to performance metrics such as throughput time,
cost or resource utilization. Using simulation allows the Business Analyst to evaluate and compare
the re-designed processes and to determine the best choice to implement within the organization.
Simulation may be used whenever there is a need for optimizing the business processes in an
organization. As processes become more and more complex, optimization is an important element for
increasing the organization‟s performance. Changing the existing processes, in an intuitive way, may
lead to unanticipated negative results and actually lower process performance instead of reaching the
designer‟s goals. Simulation provides quantitative estimates of the impact that a new process design
is likely to have on process performance. These quantitative estimates provide a basis for the
comparison of the proposed process(es) to help with the selection of the optimal solution.
The simulation of business processes is performed in several steps (K2):

 Mapping the business process onto a process model
 Identifying the sub processes and activities
 Creating the control flow definition (determining and describing the connectors linking the
different parts of the process)
 Identifying the resources and assigning them to the activities
 Defining performance characteristics (realization time, resource utilization, etc.)
After completing these activities, the simulation may be run. To ensure better and more reliable
results, the simulation should be executed several times. Each execution should be of sufficient run
length to produce valid results.
A simulation is run in a specific tool. Most tools show an animated picture of the process flow or
real-time fluctuations in the key performance measures.
Simulation tools may be selected from the following areas:
 Business Process Modeling
 Business Process Management
 General simulation tools

After finishing the simulation exercise, the results can be analyzed. When areas of low performance
are identified, the Business Analyst may re-design the process flow or manipulate resources to
increase the performance and optimize the process.
Simulation is not limited to re-designing and optimizing existing processes within the organization,
but can also be used when planning to introduce new processes (such as new product
development), and integrating them into the current business structure.

10. Innovation, Design and the Customer 60 minutes

(K2)
Terms:
Innovation, continuous innovation, innovation types, innovation areas, design, design thinking,
insight, commoditization, multidimensional analysis, persona, trial and error
Learning Objectives for Innovation, Design and the Customer

10.1 Role of the Innovation (K2)

LO-10.1.1 Define the basic aspects of innovation. (K1)
LO-10.1.2 Explain the role of the design for the company. (K2)
LO-10.1.3 Explain the role of innovation as a tool for achieving competitive advantage. (K2)
LO-10.1.4 Explain the role of Business Analysis in innovation. (K2)
10.2 Competition and Market Research (K2)

LO-10.2.1 Explain how competition and market analysis are used as regular tools for a
Business Analyst. (K2)
LO-10.2.2 Explain the process of Market Analysis. (K2)
LO-10.2.3 Recall common techniques for market data collection. (K1)
LO-10.2.4 Recall basic information about trends and their influence on the requirements. (K1)
10.3 Design Thinking (K1)

LO-10.3.1 Define design thinking. (K1)
LO-10.3.2 Define the fundamental design thinking process. (K1)
LO-10.3.3 Recall key attributes of the design thinking process. (K1)
LO-10.3.4 List sample participants of the design thinking process. (K1)
10.4 Basic Methods, Tools and Techniques (K1)

LO-10.4.1 Define multi-disciplinary teams. (K1)
LO-10.4.2 Define multi-vector research. (K1)
LO-10.4.3 Define persona. (K1)

LO-10.4.4 Define insights. (K1)

LO-10.4.5 Define brainstorming. (K1)
LO-10.4.6 Define prototyping. (K1)
LO-10.4.7 Define enlightened trial and error. (K1)
LO-10.4.8 Define storytelling. (K1)
LO-10.4.9 List sample personas in the innovation process. (K1)
10.5 Working with the Final User (K2)

LO-10.5.1 Explain why working with the final user is mandatory. (K2)
LO-10.5.2 Recall different techniques used for user research. (K1)

10.1. Role of the Innovation (K2) 30 minutes
Today it is more and more difficult for an organization to achieve a competitive advantage over
other companies. Traditional products and services do not ensure that an organization will achieve
success in the market. More is needed to convince customers that the products or services
delivered by a given organization are better than others.
10.1.1. Triggers for Innovation (K2)

The key factors that define the need to change the approach of how to design software and
business solutions are [A. Richardson]:
 No clear boundaries of the business. External conditions, new competitors and
sophisticated customer expectations force organizations to extend the business area
(extending the offer) and the geographic area of activity (chapters and branches all over the
world), and to use other communication and distributions channels. Very often expansion is
happening in multiple new areas simultaneously.
 More demanding customers. Today‟s customers not only need a product; they require a
product with high usability and with the ability to communicate with other products (also
produced by other companies). They want a product that makes them feel comfortable and
fits into their lives. Satisfying such needs is a big challenge for many organizations.
 Customer needs and expectations must come first. Organizations understand that customer
satisfaction is one of the most important success factors. There is much more effort
allocated to meet the customer‟s requirements, both direct and hidden. To be competitive,
the organization must not only satisfy the customer, but it must make them surprised, in a
positive way, and willing to come back to buy more products and services.
 More interest in integrated systems of products, software and/or services working as a
whole. These integrated systems are often the keys to expansion beyond the core areas of
the organization‟s business. It is also a way to meet customer expectations that couldn‟t be
achieved by more isolated offerings.
 There are many questions without any answer; there are many problems without a solution.
Whoever finds the right answers or working solution first, can achieve a competitive
advantage over the competitors and get a chance to bring the organization to the top on the
market.
Innovation is one of the tools that help the organization achieve a competitive advantage.
The Business Analyst, the person familiar with all the business processes within the organization
and who knows the best of all outcomes and products of the processes, can be the right person to
introduce innovation. Based on feedback from customers, market research, analysis of competitors
and personal observations, the Business Analyst, together with the support of other teams, is able
to identify the following items:
 Areas that require enhancements
 Potential new products that can be delivered by the existing processes
 Changes that will increase customer satisfaction and potential profits

10.1.2. Innovation (K2)

Innovation is the process of renewing something that exists. To allow this renewal, people need to
change the way they make decisions; they have to do things differently and make choices outside
of their norm. Innovation changes the values on which the system is based [J. Schumpeter].
Innovation is not the introduction of something new; it is not invention, but rather the changing of
something already existing by adding value into it.
The best world-wide recognized definition of innovation, so far, says: “people implementing ideas
that create new value” [Innovation Network]. This approach clearly underlines the most important
elements of innovation:
 There is no idea and no implementation without people.
 An idea without implementation is just an idea.
 Implementation of something that does not create new value is not an innovation.
There are the following types of innovation:
 Radical (breakthrough, destructive) – Using or introducing a new technology that changes
an existing market, or creates a new one, that is most likely destructive for the competition
or ensures competitive advantage
 Incremental (conservative, sustaining) – Introducing small changes, based upon existing
knowledge and technology, which allow existing products to remain competitive, enabling
short-term competitive advantage
Innovation can be applied in the following areas:
 Products (i.e., introducing a new product or service to the market)
 Processes (i.e., introducing a new, more effective way of achieving something)
 Behavior (i.e., changing how people perceive reality or achieve their goals)
10.1.3. Categories of Innovation (K1)

Innovation can be applied to many areas and can be perceived from various perspectives. Some of
categories of innovation are:
 Degree
o Disruptive innovation
o Line extension innovation
 Scope
o Application innovation
o Enhancement innovation
 Business area
o Product innovation
o Process innovation
 Source
o Organic innovation
o Acquisition innovation
These categories are not exclusive; for example, a process innovation can accompany an
acquisition innovation.
10.1.4. User Innovation (K2)

A specific type of innovation is the User Innovation. It refers to innovation by consumer users
(individual end-users or groups). In this case, the author of the innovation is the end user who
develops or refines acquired products and services at the site of use. This happens because most
products or services are designed to meet the widest possible needs. When individual users need
more features or face problems, they have to either buy a new product or introduce their own
modifications to an existing product. Users often share their ideas and solutions with the producer
to suggest implementing these ideas in the product (this is called “free revealing”) [M. Bogers, A.
Afuah, B. Bettina] [E. von Hippel].
10.1.5. Design and Innovation

Design is a term often linked with innovation. Similar to innovation there is no generally-accepted
definition of design [Ralph, Wand]. It can be considered in terms of the specification of an object
intended to accomplish goals in a particular environment, or in terms of a process that produces
such specifications. Depending on the context, the word “design” is often considered to be
ambiguous.
From a business perspective, design should be considered as the process which allows the
company to achieve a competitive advantage in the different stages of the company‟s life by:
 Solving user or customer problems in the creative way
 Creating unique value and an unforgettable (positive) user experience
 Joining functionality, aesthetics, ergonomics and user experience with the form
 Distinguishing the company from the competitors
Design methods and techniques can be applied to all possible aspects and disciplines of human
life, from new product design through process or service design, to fashion, urban and industrial
design.
How do innovation and design relate to Business Analysis? The world and business environment
are changing in a fast way. In a competitive environment, simply gathering or meeting the business
requirements might not be enough. Companies now realize that they need to focus on the design,
innovation and the customer (who is placed in the heart of both of these disciplines), if they want to
leave the competition behind. In addition what one day seems to be “most wanted” can turn into a
common good very quickly, due to commoditization. In order to preserve a leading position,
companies should not only use innovation and design, but should develop the innovation and
design culture to achieve continuous innovation.
Does it mean that Business Analysis is not needed anymore? Not at all. Business Analysis is
important and should always be done in the best possible way, but it is now often considered to be
something obvious, regular and expected due to the commoditization process. Proper
Requirements Elicitation, Analysis and Documentation are still crucial for a project‟s success but
according to a large Boston Consulting Group survey, nine out of ten senior executives believe that
long-term company growth, and its survival in the challenging market, depends on innovations [Ten
faces of innovation].

10.2. Competition and Market Research (K2) 30 minutes
One of most effective tools for achieving competitive advantage is market analysis and research.
Business Analysts should be familiar with these tools and be able to use them in planning new
products, or improvements in organization process or production.
10.2.1. Market Research (K2)

Market Research is a structured activity with the purpose of gathering information about markets or
customers. Market Research is a very important component of a business strategy (being a part of
a Business Analyst‟s areas of interest) [E. McQuarrie].
According to ICC/ESOMAR International Code on Market and Social Research, Market Research
provides a systematic way to gather and interpret information about individuals or organizations,
using statistical analytical methods and techniques. This information supports making decisions
about the future course of the organization [ICC/ESOMAR].
Market Research is considered the key factor to gain advantage over competitors. It provides
important information to identify and analyze the market‟s needs, the market size and the
competition. Market Research discovers what people (not only the customers of a given
organization) need and how they act. Some of the instruments for Market Research are
questionnaires and focus group discussion surveys.
Once that research is completed, the results, such as discovered trends, may be used to determine
the future course of the Business Strategy.
10.2.2. Market Analysis (K2)

Market Analysis is a structured and documented investigation of a market. It is a great help when
new products or an expansion of the business is planned. It determines if there is a need or
audience for a product or service. Market Analysis provides information about the market's needs
and how those needs are currently serviced. This is essential for planning and developing new
products or services.
The goal of a Market Analysis is to determine the attractiveness of a market, both now and in the
future. In this way the organization may discover and understand evolving opportunities and trends,
and match them with the organization's strengths and weaknesses.
Market Analysis can be used to:
 Prepare to enter a new market (expansion)
 Determine if there is a market for new products or services, and evaluate the chance for the
success of introducing a new product or service, or introducing changes (innovations) into
existing ones
 Plan to start a new business
 Establish the need for developing a marketing plan
 Obtain market information that will assist in the sale of the product or service
There are several dimensions of a Market Analysis; each may be used for different purposes (e.g.,
evaluating market profitability or determining market trends). These dimensions are [D.A. Aaker]:
 Market size (current and future)

 Market growth rate
 Market profitability
 Industry cost structure
 Distribution channels
 Market trends
 Key success factors
10.2.3. Market Research and Analysis Process (K2)

The Market Research and Analysis process specifies the following steps:
 Define the problem
 Analyze the situation
 Obtain data and information specific to the problem
 Analyze and interpret the information
 Formulate ideas and solutions for problem
 Design a plan
It is very important for the Business Analyst to correctly define the problem, and to obtain reliable
and useful data about the given issue. Only then can further analysis give adequate and usable
results that help in decision making.
Many approaches may be used to collect data. The goal of such research is to determine what
customers think about some topics (for example, about the usability of a product), or to define
usage patterns. The research can be done in person or through a survey, depending on the area
and scope of the stated problem and the current needs and opportunities of the organization.
Questioning can be qualitative or quantitative.
An effective approach to conducting market research is to use observation of customers and their
purchases or utilization of a product or service.
10.2.4. Techniques for Collecting Market Data (K2)

Some techniques for collecting market data are:
 Qualitative research (open-ended questions to obtain in-depth answers)
 Quantitative research
 Mail questionnaires
 Telephone surveys
 Personal interview surveys
 Observation
Results from the Market Research and Analysis processes may be used to determine market
trends.

10.2.5. Trends (K1)

A trend is a tendency of a market, or specific product or service, to move in a particular direction
over time [G. Fontanills and T. Gentile]. These trends are classified as:
 Long term trend
 Medium term trend
 Short term trend
 Global trend
By analyzing the identified trends, the Business Analyst is able to predict the desired future
solutions and plan their production and implementation. Therefore, trends affect business
requirements as they may determine the future extensions of a projected solution. Future trends
may also affect the current solution in order to prepare it for later enhancements.

10.3. Design Thinking (K1) 30 minutes
The combination of design and innovation is Design Thinking. It is a methodology for practical,
creative resolution of problems or issues for an improved future result [Simon Herbert]. Another
definition describes Design Thinking as the collaborative process by which the designer‟s
sensibilities and methods are employed to match people‟s needs with what is technically feasible
and a viable business strategy. Design Thinking converts needs into demands [Change by design].
Design Thinking is a team-oriented discipline, and is based on the idea that it is better to have five
people working together for one day than one person working alone for five days.
The success of the Design Thinking methodology depends on several factors, including simplicity,
proven effectiveness, reasonable costs, and adaptability for different types of organizations. The
process can be described in three major phases: inspiration, ideation and implementation.
10.3.1. Design Thinking – Inspiration (K1)

It‟s hard to come up with creative and innovative ideas while sitting at a desk; that‟s why designers
are encouraged to look for inspiration in all available places. It is important that the inspiration
phase is performed from the user and customer perspective, without business constraints. The
main goal of the inspiration phase is to gather insights from customers. These insights are later
used as the basis for inspirations and, after that, for innovation which will result in a competitive
advantage for the company.
The purpose of gathering insights is to enable inspiration and innovation; therefore, encouraging
creativity and discouraging criticism among the team members are desired.
By the end of the inspiration phase the team should:
 Be clear on who, or what, is the target of the project
 Have a deep understanding of the problem from the organization and customer perspective
 Have gathered insights that will be used in the later phases of the process
 Have knowledge about the opportunities and constraints
 Have documentation of their research (e.g., pictures, movies)
10.3.2. Design Thinking – Ideation (K1)

The goal of the ideation phase is to take the insights from the first phase, analyze them and
produce ideas which later become a part of the solution to the problem at hand. The solution should
satisfy the needs of the customer and the organization (competitive advantage). Team members
are encouraged to propose as many ideas as possible (i.e., during a brainstorming session). It is
crucial during the ideation phase to restrain from judgment when new ideas emerge. Even when
one idea seems to be in contradiction to another, infeasible, or even silly, it should not be rejected.
The team can use these questionable ideas as a source for further inspiration. Designers often
employ tools that can be used to support their ideas (e.g., stories, sketches, prototypes). At the end
of the ideation phase, the decision is made regarding which ideas will become part of the final
solution. This is often done by having the team members vote on the various ideas.
The primary tool of the ideation phase is prototyping, which is used to prototype the best ideas and
solutions.
10.3.3. Design Thinking – Implementation (K1)

In the implementation phase the prototypes should be stable and be ready for further testing and
verification by the users. The goal of the implementation phase is to convince the organization and
stakeholders that the proposed solutions meet their expectations, and ensure success after release
to the market. The best way to achieve this goal is to use storytelling; a persuasive technique
crucial to achieving stakeholder understanding.
Design Thinking is sometimes broken into seven stages: define, research, ideate, prototype,
choose, implement and learn. For the purpose of the Foundation Level syllabus the three-stage
approach is assumed.

10.4. Basic Methods, Tools and Techniques (K1) 30 minutes
10.4.1. Multidisciplinary Teams (K1)

Multidisciplinary Teams are one of the critical factors that enable innovation. As the name says, the
team should consist of people from various, most likely completely different, functional areas (e.g.,
engineering, legal, finance, art, marketing, chemistry, sociology). This diversity of viewpoints is
beneficial when the observations are made, insights are gathered, and ideas are generated. It is
also common to organize the teams around the explicit problem rather than a leader. Since
leadership often is fluent and depends on the given situation, all of the team members should be
independent in their tasks and able to proceed with minimal guidance. To ensure the most effective
collaboration, team members should be able to communicate clearly with each other (e.g., avoid
technical jargon), play by the same rules (e.g., no judgment or criticism when the ideas are
generated, take others‟ ideas and build on them), and enter the project with the same approach
(e.g., enthusiasm, optimism, excitement). Multidisciplinary teams work best with clear, but not
narrow, goals and challenging terms.
10.4.2. Multi-Vector Research (K1)

While gathering data that is needed to propose the best solution which would have a chance to
ensure competitive advantage, it is important to consider all available points of view and sources of
information. The best way to gain a 360-degree point of view is to use a Multi-Vector Research tool.
The idea behind the tool is simple: create a number of vectors which allow you to research the
problem at hand from several directions, and then synthesize those vectors to uncover insights.
When using multi-vector research it is important to pursue all the vectors at the same time with the
same team and with a mixture of qualitative and quantitative tools. In this way, the true potential of
this method can be realized.
A set of typical vectors used in Multi-Vector Research includes:
 Customers
 Competitors
 Comparatives
 Brands
 Organization toolbox
 Technology
 Sales and Retail
 Trends
The best way to do the multi-vector research is to use multidisciplinary teams, where a person who
is an expert with one vector does the analysis of the vector that is outside of his or her specialty.
This tool has been widely described in [A. Richardson].

10.4.3. Personas (K1)

Personas are yet another powerful tool used to get a better view of the problem from the customer‟s
perspective. According to the definition, a persona is a fictional character (an archetype
description), which represents one of the different types of users who will be using the final product
or solution. A persona should represent a group of people with the same needs, attitudes,
behaviors or expectations toward the product.
Personas should be defined and employed in the very beginning of the project. Defined personas
help with such tasks as knowing the types of people to hire for interviews, how to design the
research areas and methods, and how to properly set priorities for the requirements.
Each organization can define the personas in the way it finds suitable for the current project or
problem at hand. Once the appropriate personas are defined, it is important that they be used and
not left in the corner to gather dust [Inspired].
10.4.4. Insights (K1)

Customer insights are the basis for inspiration and innovation. The first rule regarding insight
gathering is to always examine from the customer‟s point of view. The best way to gather insights is
to enter the anthropologist‟s shoes and submerge into the customer‟s world, embrace the
customer‟s needs, fears, emotions and problems. This is the best way, and actually the only
reasonable way, because only by experiencing the given event first hand, and by looking at it with
fresh eyes, can the anthropologist be truly sure that they have solid material for further analysis,
untainted with common knowledge, assumptions or speculations.
There are many sources of insights available: customers and their feelings, needs, values and
problems, extreme users and outliers, children, youngsters, the elderly, mega trends and all kinds of
general trends, competition, technology, complementing and comparable organizations and many
more.
The most valuable insight is one that is relevant for the customer and the company, and that yields
unique information.
10.4.5. Brainstorming (K1)

Brainstorming is a widely adopted technique used for generating a large number of ideas for the
solution of defined problems. There are three important rules for brainstorming sessions:
 Refrain from judgment and criticism towards ideas presented by team members.
 Build new ideas on the ideas provided by others, while refraining from criticizing. Wild and
crazy ideas are welcome and encouraged.
 Brainstorming sessions are more about quantity than quality. The bigger the number of
generated ideas, the better the brainstorming session.
Brainstorming sessions are more likely to be facilitated than moderated.
10.4.6. Prototyping (K1)

A Chinese proverb says that “one picture is worth a thousand words”; the same rule can be applied
to prototyping. Using prototypes can better explain and present ideas or solutions to others, come
up with new ideas (during the prototyping), test the solution, gather the feedback from the
stakeholders and customers, etc. The advantages of prototyping are obvious. In most cases the
designers will need to create dozens if not hundreds of prototypes before achieving satisfying
results, therefore, the prototypes should be easy, quick and cheap to create (paper prototyping is a
powerful tool). It should be remembered that in the concept phase, the goal of the prototyping is not
to create a final prototype but to create something that can be easily tested, evaluated and most
probably destroyed afterwards. Creating and destroying a large number of prototypes does not
mean failure, rather it means that the team is learning about the strengths and weaknesses of an
idea, with each subsequent prototype being better than its predecessor as the team approaches the
final solution.
Prototyping encourages an iterative approach to the problem solution.
10.4.7. Enlightened Trial and Error (K1)

Usually the best solution doesn‟t come first. James Dyson created 5127 prototypes of his vacuum
cleaner before he was satisfied with the result. Trial and Error is the process of obtaining knowledge
by generating/prototyping solutions, testing them and learning from the mistakes. The testing of the
solution is performed using the disposable prototypes. One of the slogans explaining the idea of
Trial and Error says “fail often in order to succeed sooner” and is based on the assumption that a
quick verification of the solution, even if unsuccessful, brings better results than trusting in the plans
of the lone genius. [IDEO]
10.4.8. Storytelling (K1)

Storytelling is a persuasive technique used to convince the listener to support the arguments of the
storyteller. Stories are based on assumptions or the real situations that were experienced during the
research phase. The stories are wrapped around the product, the user and the user‟s experience.
Using the motto “show, don‟t tell”, the storyteller employs pictures, videos, sketches, etc. to “tell” the
story. The goal of a good story is to sell an idea to the others, motivate them to do work, and
encourage them to make hard decisions.
10.4.9. Sample Personas in the Innovation Process (K1)

Although there is no single world-recognized innovation process, some of the elements are
consistent regardless of the approach to innovation. Basing on 27 years of experience IDEO
defined ten roles, or so called “personas”, that seem to continuously emerge on innovation projects.
These ten innovation personas are broken into three groups:
 The learning personas:
o The Anthropologist – One who is a true observer of human nature, gathering
insights by getting into the shoes of the person to be observed and actually living
their lives for a while.
o The Experimenter – One who adds some flesh and bones to the ethereal ideas. His
job is to prototype, experiment and improve the solution using the trial and error
process.
o The Cross-Pollinator – One who takes a dive into other industries and cultures to
return with findings that can be used to benefit the enterprise.
 The organizing personas:
o The Hurdler – One who understands that keeping innovation alive is not an easy
task and uses all means available to remove the obstacles that could delay or stop
the innovation process.
o The Collaborator – One who is able to organize, support and coach the project
team and is often involved in removing the danger of skepticism flowing from the
organization.
o The Director – One who sheds the light of innovation in the organization, builds the
innovation culture in the organization, and encourages people and leads them
toward his vision.
 The building personas:
o The Experience Architect – One who is responsible for delivering the product to the
customer and creates a unique experience that stays in the customer‟s mind even
after the product itself is long gone.
o The Set Designer – One who provides the physical stage with the best conditions
for creative work and creates places where innovation can come to life.
o The Caregiver – One who gives special care to the customer‟s needs, keeps the
focus on the customer, anticipates his needs, and always puts him first.
o The Storyteller – One who provides the good story that helps to open the sealed
door, convinces others of the idea, launches a project or builds a vision and
increases the morale of the team.
These are not all of the personas that can appear in the areas related to innovation. However, they
give an idea of what is needed for innovation to happen. The detailed description of each persona
can be found in [Ten faces of innovation].

10.5. Working with the Final User (K2) 20 minutes
One of the main tasks of a Business Analyst is to provide a business design of a solution that will
satisfy the customer‟s needs and expectations. To be able to do so, the Business Analyst must
know these needs. This includes not only those articulated directly but also the hidden expectations
of which the customer may not be aware. The role of a Business Analyst is to work with the end
users to identify and explore their requirements and provide support for formulating their various
needs. For example, working with the end users may help to identify usability requirements that
were not determined in the initial requirements collecting phase.
User research may be done using the same techniques as Market Research. Particularly these are
(K1):
 Customer feedback
 Qualitative research
 Quantitative research
 Mail questionnaires
 Telephone surveys
 Personal interview surveys
 Observation
 Direct work with the end users on site (assisting in operating or using the solution)

11. References
Standards
[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process Integration
and Product Improvement, Addison Wesley: Reading, MA
See Section 2.1
[IEEE 1028] IEEE Std. 1028, IEEE Standard for Software Reviews and Audits
See Section 3.2
[IEEE 12207] IEEE 12207/ISO/IEC 12207-2008, Software Life Cycle Processes

See Section 2.1
[IEEE 1042] IEEE Std. 1042-1987 IEEE Guide to Software Configuration Management
[ISO 25000] ISO 25000 (ISO/IEC 9126-1:2001), Software Engineering – Software Product Quality
See Section 2.3
[BS 7000] BS 7000-1:1999 Guide to managing innovation
Books and Other Publications

[IBAQB Glossary] Standard glossary of terms used in Software Engineering Version 1.0
[ISTQB Glossary] ISTQB Glossary of Testing Terms 2.1
[A. Richardson] A. Richardson (2010), Innovation X. Why a company's toughest problems are its
greatest advantage, Jossey-Bass
[Becker J., Kugeler M. , and Rosemann M.] J. Becker, M. Kugeler, and M. Rosemann (2003),
Process Management - A guide for the design of business processes. Springer-Verlag: Berlin
[BABOK] International Institute of Business Analysis (2006), A guide to the Business Analysis Body
of Knowledge, version 1.6
[Change by design] T. Brown, Change by Design: How Design Thinking Transforms Organizations
and Inspires Innovation, HarperCollins, 2009, ISBN 978-0061766084
[D.A. Aaker] D.A. Aaker (2007), Strategic Market Management, ISBN 978-0470056233
[E. McQuarrie] E. McQuarrie (2005), The market research toolbox: a concise guide for beginners
(2nd ed.), SAGE, ISBN 9781412913195
[E. von Hippel] E. von Hippel (1986), Lead users: a source of novel product concepts, Management
Science 32: 791–805
[Freedman and Weinberg] D. Freedman and G. Weinberg, Walkthroughs, Inspections, and
Technical Reviews, Dorset House Publishing, 1990, ISBN 0-932633-19-6.

[G. Fontanills and T. Gentile] G. Fontanills and T. Gentile (2001), Start Market Course, George
Fontanills, Tom Gentile, John Wiley and Sons Inc.
[Gilb and Brodie RQNG] T. Gilb and L. Brodie (2010), What’s fundamentally wrong? Improving our
approach towards capturing value in requirements specification
[Gilb, Competitive Engineering] T. Gilb (2005), Competitive Engineering: A Handbook for Systems
Engineering, Requirements Engineering, and Software Engineering using Planguage, Elsevier
Butterworth-Heinemann
[Gilb, Real] T. Gilb, Real Requirements, see http://www.gilb.com/tiki-download_file.php?fileId=28
[ICC/ESOMAR] ICC/ESOMAR (2008), International Code on Market and Social Research.
ICC/ESOMAR Amsterdam, the Netherlands, 4th ed. See:
http://www.esomar.org/uploads/pdf/professional-standards/ICCESOMAR_Code_English_.pdf
nd
[I. Bens] I. Bens, Facilitation at a Glance, 2 edition, 2008
[Inspired] M. Cagan, Inspired: How to create products customers love, SVPG Press, 2008, 978-0-
9816904-0-7
[J. Schumpeter] J. Schumpeter (1934). The Theory of Economic Development. Cambridge, MA:
Harvard University Press
[K. Ishikawa] K. Ishikawa (1990), Introduction to Quality Control, ISBN 4-906224-61-X OCLC
61341428
[M. Bogers, A. Afuah, B. Bettina] M. Bogers, A. Afuah, B. Bettina (2010), Users as innovators: A
review, critique, and future research directions, Journal of Management 36 (4): 857–875
[Ralph, Wand] P. Ralph and Y. Wand, A Proposal for a Formal Definition of the Design Concept,
Springer Berlin Heidelberg, 2009, ISBN 978-3-540-92965-9
[Simon Herbert] S. Herbert, The Sciences of the Artificial, Cambridge: MIT Press, 1969, ISBN 0-
262-19374-4
[Sparx] The Business Process Model, see:
http://www.sparxsystems.com.au/downloads/whitepapers/The_Business_Process_Model.pdf
[T. Pyzdek and P. A. Keller] T. Pyzdek and P. A. Keller (2009), The Six Sigma Handbook, Third
Edition, New York, NY: McGraw-Hill, ISBN 0071623388.
[T. Simon, J. Streit, and M. Pizka] T. Simon, J. Streit, and M. Pizka, Practically Relevant Quality
Criteria for Requirements Documents, itestra GmbH, Ludwigstr. 35, 86916 Kaufering, Germany
[TGilb] see: http://gilb.com, Planguage Concept Glossary
[Ten faces of innovation] T. Kelly and J. Littman, The Ten Faces of Innovation: IDEO's Strategies
for Defeating the Devil's Advocate and Driving Creativity Throughout Your Organization, Doubleday,
ISBN 978-0385512077

12. Appendix A – Learning Objectives/Cognitive Level of

Knowledge
The following learning objectives are defined as applying to this syllabus. Each topic in the syllabus
will be examined according to the learning objective for it.
Level 1: Remember (K1)

The candidate will recognize, remember and recall a term or concept.
Keywords: Remember, retrieve, recall, recognize, know
Level 2: Understand (K2)

The candidate can select the reasons or explanations for statements related to the topic, and can
summarize, compare, classify, categorize and give examples for the testing concept.
Keywords: Summarize, generalize, abstract, classify, compare, map, contrast, exemplify, interpret,
translate, represent, infer, conclude, categorize, construct models
Level 3: Apply (K3)

The candidate can select the correct application of a concept or technique and apply it to a given
context.
Keywords: Implement, execute, use, follow a procedure, apply a procedure
Reference
(For the cognitive levels of learning objectives)
Anderson, L. W. and Krathwohl, D. R. (eds) (2001) A Taxonomy for Learning, Teaching, and
Assessing: A Revision of Bloom's Taxonomy of Educational Objectives, Allyn & Bacon

13. Appendix B – Rules Applied to the IBAQB
Foundation Syllabus
The rules listed here were used in the development and review of this syllabus. (A “TAG” is shown
after each rule as a shorthand abbreviation of the rule.)
General Rules
SG1. The syllabus should be understandable and absorbable by people with zero to six months (or
more) experience in Business Analysis. (6-MONTH)
SG2. The syllabus should be practical rather than theoretical. (PRACTICAL)
SG3. The syllabus should be clear and unambiguous to its intended readers. (CLEAR)
SG4. The syllabus should be understandable to people from different countries, and easily
translatable into different languages. (TRANSLATABLE)
SG5. The syllabus should use American English. (AMERICAN-ENGLISH)
Current Content
SC1. The syllabus should include recent Business Analysis concepts and should reflect current
best practices in Business Analysis where this is generally agreed. The syllabus is subject to review
every two to five years. (RECENT)
SC2. The syllabus should minimize time-related issues, such as current market conditions, to
enable it to have a shelf life of two to five years. (SHELF-LIFE).
Learning Objectives
LO1. Learning objectives should distinguish between items to be recognized/remembered
(cognitive level K1), items the candidate should understand conceptually (K2), and items the
candidate should be able to practice/use (K3. (KNOWLEDGE-LEVEL),
LO2. The description of the content should be consistent with the learning objectives. (LO-
CONSISTENT)
LO3. To illustrate the learning objectives, sample exam questions for each major section should be
issued along with the syllabus. (LO-EXAM)
Overall Structure
ST1. The structure of the syllabus should be clear and allow cross-referencing to and from other
parts, from exam questions and from other relevant documents. (CROSS-REF)
ST2. Overlap between sections of the syllabus should be minimized. (OVERLAP)
ST3. Each section of the syllabus should have the same structure. (STRUCTURE-CONSISTENT)
ST4. The syllabus should contain version, date of issue and page number on every page.
(VERSION)
ST5. The syllabus should include a guideline for the amount of time to be spent in each section (to
reflect the relative importance of each topic). (TIME-SPENT)

14. References
SR1. Sources and references will be given for concepts in the syllabus to help training providers
find out more information about the topic. (REFS)
SR2. Where there are not readily identified and clear sources, more detail should be provided in the
syllabus. For example, definitions are in the Glossary, so only the terms are listed in the syllabus.
(NON-REF DETAIL)
Sources of Information
Terms used in the syllabus are defined in Standard Glossary of Terms used in Software
Engineering. A version of the Glossary is available from IBAQB.
A list of recommended books on Business Analysis is also issued in parallel with this syllabus. The
main book list is part of the References section.

15. Appendix C – Notice to Training Providers

Each major subject heading in the syllabus is assigned an allocated time in minutes. The purpose
of this is both to give guidance on the relative proportion of time to be allocated to each section of
an accredited course, and to give an approximate minimum time for the teaching of each section.
Training providers may spend more time than is indicated and candidates may spend more time
again in reading and research. A course curriculum does not have to follow the same order as the
syllabus.
The syllabus contains references to established standards, which must be used in the preparation
of training material. Each standard used must be the version quoted in the current version of this
syllabus. Other publications, templates or standards not referenced in this syllabus may also be
used and referenced, but will not be examined.
The specific areas of the syllabus requiring practical exercises are as follows:
 2. Enterprise Analysis
o 2.5 Determining Solution Scope and Approach
 3. Business Analysis Process Planning
o 3.2 Requirements Management Process Planning
o 3.3 Configuration and Change Management Process
 4. Elicitation
o 4.1 The Concept of Requirements Elicitation
o 4.4 Requirements Documentation
 5. Requirements Analysis
o 5.2 Modeling and Specification
 7. Tools and Techniques
o 7.2 Business Analysis Techniques
 8. Competencies
o 8.3 Facilitation skills
 9. Process Improvement
o 9.2 Process Simulation and Re-design
 10. Innovation, Design and the Customer
o 10.2 Competition and Market Research

Index
Assessment, 18, 25, 31, 64, 65 IEEE 830, 53
Baseline, 46, 47 Innovation, 85, 86, 87, 98
BPM, 58, 81 Insights, 84, 94
BPS, 81 ISO 25000, 45, 53
Brainstorming, 42, 43, 45, 77, 84, 94 ISO 9126, 53, 98
Business Analysis, 1, 2, 7, 9, 10, 12, 13, 14, learning objective, 8, 9, 20, 33, 43, 54, 64,
15, 18, 24, 33, 34, 42, 43, 54, 67, 68, 70, 67, 72, 78, 83, 100, 101
71, 73, 74, 83, 103
Market Analysis, 83, 88
Business Analysis techniques, 42, 67, 71
Market Research, 88, 89
Business Analyst, 1, 3, 7, 9, 12, 13, 14, 15,
Mind mapping, 69
16, 19, 24, 27, 32, 33, 37, 38, 40, 48, 49,
50, 51, 55, 57, 60, 61, 62, 63, 66, 68, 69, Modeling tools, 42, 67, 68
70, 71, 72, 73, 74, 76, 79, 82, 85, 88, 89,
MoSCoW, 71
90
MOST, 70
Business Case, 25, 28, 30
Multidisciplinary Teams, 93
Business Goal, 26
Multi-Vector Research, 93
Business Need, 26, 27
Persona, 83, 94
Business needs, 12, 20
PESTLE, 67, 70
business process, 20, 25, 34
Product Breakdown Structure, 32
Business Process Management, 58, 81
Prototyping, 42, 58, 69, 84, 94, 95
Business Process Simulation, 81
Quality assurance, 22, 36, 54, 62
CATWOE, 71
Quality criteria, 62
Change Control Board, 33, 40, 41
Requirement, 15, 43, 44, 48, 51, 67, 68
Change List, 40
Requirement acceptance, 44, 51
Change Log, 40
Requirement Management, 68
Change Management, 33, 37, 38, 39, 47, 52
Requirement management tools, 67
Change Request, 39, 40
Requirements Analysis and Documentation,
Configuration Management, 33, 38, 39, 98
18
defect, 9
Requirements Communication, 18, 19, 51
Design Thinking, 83, 91, 92, 98
Requirements documentation, 43, 49
Enterprise Analysis, 14, 18, 20, 24
Requirements Elicitation, 16, 18, 43, 45
Facilitation, 72, 75
Requirements Engineering, 10, 33, 36
Five Why's, 71
Requirements Planning and Management,
IEEE 1233, 53 18
IEEE 1362, 53 Requirements scope, 43, 46

review, 101 SWOT, 42, 70, 76

RTM, 48, 65 System Interface Analysis, 32
Six Thinking Hats, 71 Traceability, 16, 48, 65
SMART, 26 Trend, 90
solution scope, 20, 21, 29, 32 Trial and Error, 83, 95
Stakeholder, 20, 22, 49 Validation, 18, 61, 64, 66
Stakeholders, 11, 22, 23, 34 Verification, 54, 61
Standards, 44, 49, 53, 98 Work Breakdown Structure, 32
Storytelling, 84, 95


Certified Business Analyst Foundation Level Syllabus: International Business Analysis Qualifications Board

Uploaded by

Copyright:

Available Formats

Certified Business Analyst Foundation Level Syllabus: International Business Analysis Qualifications Board

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Certified Business Analyst Foundation Level Syllabus: International Business Analysis Qualifications Board

Uploaded by

Copyright:

Available Formats

Certified Business Analyst

Foundation Level Syllabus

International Business Analysis Qualifications Board

Copyright Notice © International Business Analysis Qualifications Board (hereinafter called

All rights reserved.

Version 2011 Page 2 of 104 7. June 2011

Version Date Remarks

1.0 07.06.2011 First version of the Certified Business Analyst

Version 2011 Page 3 of 104

Version 2011 Page 4 of 104

Introduction to this Syllabus

Purpose of this Document

Version 2011 Page 5 of 104

Knowledge (K) Levels

How this Syllabus is Organized

Version 2011 Page 6 of 104

1. Fundamentals of Business Analysis (K2) 100 minutes

Learning Objectives for Fundamentals of Business Analysis

1.1 Why is Business Analysis Necessary (K2)

1.2 What is Business Analysis (K2)

1.3 Core Concepts of Business Analysis (K2)

1.4 Knowledge Areas (K1)

1.5 Tasks and Responsibilities (K2)

Version 2011 Page 7 of 104

1.1. Why is Business Analysis Necessary? (K2) 20 minutes

Section Learning Objectives

o Requirements are imprecise

Version 2011 Page 9 of 104

1.2. What is Business Analysis? (K2) 20 minutes

Section Learning Objectives

1.2.1. Business Analysis (K1)

1.2.2. Business Analyst (K1)

1.2.3. Common Objectives of Business Analysis (K1)

Version 2011 Page 10 of 104

Version 2011 Page 11 of 104

1.2.5. Relationship to the Solutions Lifecycle (K1)

Version 2011 Page 12 of 104

1.3. Core Concepts of Business Analysis (K2) 30 minutes

Section Learning Objectives

1.3.1. Business Analyst Role (K1)

1.3.2. Business Analyst and Systems Analyst (K2)

1.3.3. Requirement (K1)

1.3.4. Classification of Requirements (K2)

1.3.5. Types of Requirements (K1)

1.3.6. Requirements Elicitation (K1)

1.3.7. Traceability (K2)

Version 2011 Page 14 of 104

1.3.8. Artifact (K1)

Version 2011 Page 15 of 104

1.4. Knowledge Areas (K1) 10 minutes

Section Learning Objectives

Business Analysis consists of the following knowledge areas:

Version 2011 Page 16 of 104

1.5. Tasks and Responsibilities (K2) 20 minutes

Section Learning Objectives

1.5.1. Major Tasks (K1)

1.5.2. Role of Business Analyst in Different Phases of the Project (K2)

Version 2011 Page 17 of 104

2. Enterprise Analysis (K3) 150 minutes