IQBBA Exam Preparation Handbook
IQBBA Exam Preparation Handbook
IQBBA Exam Preparation Handbook
Version 1.0
Copyright Notice
This document may be copied in its entirety, or extracts made, if the source is acknowledged.
Copyright Notice © International Qualifications Board for Business Analysis (hereinafter called
IQBBA®)
IQBBA is a registered trademark of GASQ Service GmbH.
The authors for version 2.0, released in October 2017 hereby provide their copyright rights to IQBBA
for this 2019 version
All rights reserved.
Table of Contents
Modeling .................................................................................................................................... 85
4.1.4 Specification .................................................................................................................. 90
4.1.5 Verification and Validation ............................................................................................. 98
4.2 Requirements Management ................................................................................................ 101
4.2.1 Introduction .................................................................................................................. 101
4.2.2 Information Architecture .............................................................................................. 101
4.2.3 Requirements Communication .................................................................................... 104
4.2.4 Traceability .................................................................................................................. 106
4.2.5 Configuration Management ......................................................................................... 110
Configuration Management ..................................................................................................... 110
Change Management .............................................................................................................. 112
4.2.6 Solution Scope Management ...................................................................................... 114
4.2.7 Quality Assurance ....................................................................................................... 115
4.3 Tools and Techniques ......................................................................................................... 116
4.3.1 Tools and Techniques ................................................................................................. 116
Brainstorming, Persona, User story, Use case, User scenario, Survey (questionnaire),
Workshop................................................................................................................................. 116
Prototyping, Decomposition, Story mapping ........................................................................... 116
5 Whys ..................................................................................................................................... 116
4.3.2 Notations ...................................................................................................................... 116
4.4 Sample Exam Questions ..................................................................................................... 120
4.4.1 Question 4.1 ................................................................................................................ 120
4.4.2 Question 4.2 ................................................................................................................ 120
4.4.3 Question 4.3 ................................................................................................................ 120
4.4.4 Question 4.4 ................................................................................................................ 121
4.4.5 Question 4.5 ................................................................................................................ 121
4.4.6 Question 4.6 ................................................................................................................ 121
4.4.7 Question 4.7 ................................................................................................................ 121
4.4.8 Question 4.8 ................................................................................................................ 122
4.4.9 Question 4.9 ................................................................................................................ 122
4.4.10 Question 4.10 .............................................................................................................. 123
4.4.11 Question 4.11 .............................................................................................................. 123
4.4.12 Question 4.12 .............................................................................................................. 123
4.4.13 Question 4.13 .............................................................................................................. 124
4.4.14 Question 4.14 .............................................................................................................. 124
4.4.15 Question 4.15 .............................................................................................................. 124
4.4.16 Question 4.16 .............................................................................................................. 125
4.4.17 Question 4.17 .............................................................................................................. 125
Business Analysis – the practice of enabling change in an enterprise by defining needs and
recommending solutions that deliver value to stakeholders. Business Analysis enables an enterprise to
articulate needs and the rationale for change, and to design and describe solutions that can deliver
value [BABOK].
Specific activities of Business Analysis are collected within knowledge areas (KA). IQBBA proposes
the following KAs:
• Strategy definition
• Management of Business Analysis process
• Requirements Engineering in Business Analysis
• Solution evaluation and optimization
These KAs are supported by specific methods, tools, and techniques, and require specific skills and
competencies.
The activities of the Business Analyst may vary depending on his role and scope of responsibility. A
Business Analyst working at the organization level is typically responsible for collecting insights and
business needs and/or opportunities from the business environment (customers, competitors,
organization’s assets) and proposing new, often innovative, business solutions. A Business Analyst
working at the program/project level will instead be in charge of delivering the agreed business
solution – in this context the role can be compared to the Product Owner in Agile.
Business Analysis tasks may differ depending on the product life cycle. During initial phases of a
product life cycle, a Business Analyst is typically responsible for establishing business needs and
proposing a solution, later – during solution development – a BA’s activities are concerned with
helping the team to build the right solution. When the product is released and working in production,
typical BA tasks include monitoring and improving its efficiency, and introducing changes where
necessary.
Solution – the implementation of the requirement or a design idea which, if implemented, is expected
to lead to the partial or full satisfaction of a set of attribute requirements; to solve a (defined) problem
[Tgilb].
Solutions are built based on requirements. A requirement can be defined as the documented
representation of a need of specific stakeholders or organization, bringing a value to the business
[BABOK][IEEE 610].
Requirement:
(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.
Requirements are the foundation of solution scope and design. Requirements are typically classified
into categories to allow better management. BABOK Guide proposes the following classification,
representing the abstraction levels for requirements:
• Business requirements
• Stakeholder’s requirements
• Transition requirements
• Solution requirements
o Functional requirements
o Non-functional requirements
Business requirement – a high level type of requirement expressing needs of the business.
Functional requirement – a requirement that specifies a function that a component or system must
perform [IEEE 610].
Non-functional requirement – a requirement that does not relate to functionality, but to attributes
such as reliability, efficiency, usability, maintainability and portability.
© International Qualifications Board for Business Analysis page 9 of 148
Certified Business Analyst Foundation Level Handbook
Business Requirements
WHAT the business is trying to achieve
WHY a project should be undertaken or a solution implemented
Metrics that will be used to measure success
Stakeholder Requirements
WHAT each specific stakeholder/group needs from a solution
Use cases of a solution
Bridge between business requirements and solution requirements
Solution Requirements
WHAT characteristics the solution will support
HOW are the stakeholders’ needs are satisfied
Examples
Business requirement Reduce errors in processing customer orders by 30% by the end
of the next year
IQBBA extends the above classification to add information supporting solution design and
requirements management:
• Business constraints
• Solution constraints
• Business assumptions
• Technical assumptions
Business constraint – the limitations on the project’s flexibility to implement the requested solution
[BABOK].
Solution constraint – any restrictions that are related to the design and architecture of the solution
such as hardware and software platforms, programming language or technology, and software that
must be used [BABOK].
Assumption – an influencing factor or condition that is believed to be true at given moment but has
not been confirmed to be accurate.
When working with different levels of abstraction of requirements, it is important to maintain traceability
(see: 4.2.4 Traceability ) supporting scope management, coverage analysis and change impact
analysis.
Questions
Recall the definition of a requirement, Business Analysis, and solution
Explain how requirements can be classified
Explain the role of Business Analysis in an organization, program and project
Provide examples of objectives of Business Analysis in the different phases of a product life cycle
Recall main knowledge areas in Business Analysis
Business Analyst – a person responsible for identifying the business needs of their clients and
stakeholders, to determine solutions to business problems [BABOK].
The Business Analyst often acts as a bridge between business stakeholders and the solution delivery
team, identifying, negotiating, and achieving a consensus between the needs of the various
representative individuals and groups.
As one of the main work products of Business Analysis are business needs and business
requirements, BAs play an important role in the success of both organization-level programs and in
specific change or development work.
Problems with requirements can cause change or development work to fail. In most cases these
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 but are not restricted to:
• Unclear business objectives of the initiative
• Missing business requirements, often the result of lack of analysis of the stakeholders
• Instability of the requirements (frequent and uncontrolled changes in requirements)
• Poor translation of the business needs to requirements (incomplete, inconsistent, or not
measurable requirements)
• Communication problems and knowledge barriers
The above issues may result in problems later, such as during solution proposal scope definition,
solution realization planning, implementation or testing. Unclear business requirements, or a low
quality business design of the solution, can lead to confusion and to questions regarding the intended
business solution. If no actions are taken to correct this state, the risk of the failure increases.
The impact of improper Business Analysis on change or development work is already known, but still
very often neglected.
The major reasons for neglecting Business Analysis are time pressure, focus on fast results without
proper analysis of the needs, opportunities, and risk, and characterizing Business Analysis processes
as a cost, not an added value.
Mature organizations normally have defined a generic approach to Business Analysis. This approach
covers definition of activities together with their goals, the tools and techniques supporting specific
tasks, and the roles and responsibilities of people involved in the BA’s work and products. It is
important to remember that different environments and approaches to management or solution
development and/or maintenance may require specific approaches to Business Analysis. Therefore
the BA must work together with stakeholders to determine which tasks and techniques defined in the
general Business Analysis process are appropriate for the specific situation.
Questions
Explain the role and responsibilities of a Business Analyst in terms of an organization and a project
Provide examples of common pitfalls in Business Analysis
Provide examples of cooperation between a Business Analyst and other roles within an organization
and the program/project's stakeholders
Provide examples of the consequences of neglecting Business Analysis
Product Example
Business goals Generate 25% of annual revenues from new products
Reduce inventory cost by 5% by the end of 2020
Business needs Need more new products
Need increased product portfolio visibility
Need information about current inventory costs
Limitations New process must be introduced before end of 2020
Assumptions New process will not require any special user training
1.4 Competencies
The main goal of a BA is to provide business solutions which add value to the business. 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 are necessary conditions for effective and valuable Business Analysis.
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 competencies to effectively understand and work within
the defined environment:
• Analytical thinking and problem-solving skills
• Behavioral characteristics
• Business knowledge
• Basic technical knowledge
• Interaction skills
• Communication skills
• Negotiation skills and diplomacy
• Some level of managerial skills
• Creativity
Communication skills are particularly important for the success of Business Analyst. Typically they
include:
• Ability to communicate with all levels of management
• Ability to communicate with stakeholders of various knowledge levels
• Precision in articulating ideas and thoughts
• Ability to relate with line workers
• Good technical writing skills
• Strong communication skills in all forms (verbal, non-verbal, written)
In addition, the Business Analyst should be an effective facilitator to enable groups to work
cooperatively and effectively [Bens].
Facilitator – a person or group who assists others in carrying out a work process, such as quality
control or setting objectives; by virtue of their being especially trained, qualified, and knowledgeable in
that process [TGilb].
In the context of Business Analysis, facilitation requires the following skills:
• Leading
• Solving issues
• Building team and community
• Empowering people
• Resolving conflicts
• Transforming (introducing change)
• Evoking wise-democracy
• Building personal effectiveness
Effective Business Analysts use facilitation to support working with a group of stakeholders to elicit,
document, analyze, verify and achieve consensus on requirements.
A good facilitator demonstrates the following competencies:
• Connects with the group quickly
• Communicates and listens well
• Processes ideas from people
• Shows a natural interest
• Negotiates between parties
• Understands group dynamics and empowers the group
• Focuses on the business not on personal solutions
• Helps the group to listen and draw logical conclusions
Some of the tools used in facilitation include:
• Gap analysis
• Flipcharts
• Checklists
• Multi-voting
• Root cause analysis
• Brainstorming
• Focus group framework
Many Business Analysts lack formal training and experience as facilitators, and sometimes have
difficulty running a facilitation session. For Business Analysis, facilitation techniques focus on the
skills necessary to elicit and analyze business needs, requirements, and stakeholders’ expectations.
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.
Within the Business Analyst role, there can be a defined career path that reflects the progress of
developing skills and competencies. Some sample classifications include:
Based on the specialization profile:
• Generalist practitioner
• Specialist practitioner [IIBA Competency].
Justification
B – Correct. This refers to the need perceived by a specific stakeholder (user representative)
A – Incorrect. Business requirements express needs of a business, not a specific stakeholder.
C and D – Incorrect. These refer to the solution itself.
Question 1.2 – answer C
Justification
C – Correct. This is the main task of BA, as explained in the IQBBA syllabus, section 1.2.
A – Incorrect. The term “stakeholder” refers to a project/initiative, therefore using it in the context of an
organization is not correct.
B – Incorrect. The main task of a BA is “identifying the business needs of their clients and
stakeholders, to determine solutions to business problems” detailing business requirements into
solition requiremnts is not considered as a key activity.
C – Incorrect. This statement would be true only in some cases (like Agile methods), as it refers to the
role of Product Owner.
Question 1.3 – answer D
Justification
D – Correct – as explained in the IQBBA syllabus, section 1.2.
A – Incorrect. It is more about project manager’s responsibilities.
B – Incorrect. As stated in the IQBBA syllabus, section 1.2., the BA “is a person responsible for
identifying business needs of stakeholders and for determining solutions to business problems with the
aim of introducing change which adds value to the business.” BA should therefore help to
define/express needs related to business problems, not specific systems.
C – Incorrect. Understanding of AS-IS should not aim to change the current state just for the sake of
changing it. Every change should add some value and should be driven by a specific goal.
2. Strategy Definition
Terms
Business Case, Business Goal, Business Need, Business Process, Cost-Benefit Analysis, Feasibility
Study, Gap Analysis, Innovation, Market Research, Mission, Process Owner, SMART, Solution
Approach, Solution Proposal, Solution Scope, Stakeholder, SWOT, Vision
2.1 Introduction
Strategy definition is a set of activities and tasks aimed at establishing a way to reach a specific future
state of an organization. Specific activities of strategy analysis include, but are not limited to:
• Analysis of the current situation of the organization
• Establishing business needs on the basis of external and internal influences, including
stakeholders expectations and demands
• Analysis of the vision, mission and goals and establishing means to attain the stated
objectives
• Defining the strategy for change
The Mission defines the ongoing operational activities of the organization which will allow the Vision to
become a reality.
The Mission is planned and realized by a strategy, which can be understood as the approach to
achieve Business Goals considering the given environment and business context.
Name Example
Vision Be a professional, trusted provider of goods and services
Mission Provide products and services across Europe and North America for both
business and personal customers
Business Goal By January 1, 2020, 95% on-time order delivery
Within six months, 10% increase in product sales
Business Goals amplify the Vision – they define what must be satisfied to attain the Vision.
• S – Specific
• M – Measurable
SMART • A – Attainable (or Achievable*)
• R – Relevant
• T – Timely (or Time-bound*)
* BABOK Guide
It is important to note that the ability of achieving Business Goals may be influenced by risks and
limitations. Therefore establishing goals and objectives also typically includes risk management
activities [ISO 31000].
All the mentioned elements influence Business Analysis activities as they define future state and high
level direction for the organization.
Questions
Recall the definition of a Vision, Mission and Business Goal
Explain relationships between Vision, Mission and Business Goals
Explain how Vision, Mission and Business Goals can influence Business Analysis activities
Explain the basic principles of building proper Business Goals
Business Process – a collection of activities designed to produce a specific output for a particular
customer or market.
Each process should have a Process Owner defined. According to ITIL, the Process Owner is the
person responsible for ensuring that a process is fit for purpose. The Process Owner’s responsibilities
include sponsorship, design, and continual improvement of the process and its metrics.
Process Owner – a role responsible for overseeing that a process realizes its measurable objectives.
Identification of current business processes performed within the organization allows the Business
Analyst to understand the organization’s goals and 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 necessary for the execution of the activities that produce the desired results.
Identification of business processes helps uncover gaps and ineffective parts of the process, which
may then be improved via process optimization. If business processes are not established and
understood, then measuring and controlling them may be very difficult due to the organization’s level
of maturity. In addition, there are likely to be significant problems with the definition of the business
goals and needs.
Business processes may be modeled using a technique such as BPMN (Business Process Modeling
Notation). This technique 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.
Business Process Modeling Notation (BPMN) – a graphical notation that depicts the steps in a
business process. BPMN depicts the end to end flow of a business process. The notation has been
specifically designed to coordinate the sequence of processes and the messages that flow between
different process participants in a related set of activities [BPMN].
Questions
Recall the definition of Business Process and Process Owner
Provide examples of benefits and the application of identification of Business Processes
Business Need – definition of the business problem or opportunity, which BAs have to understand in
order to recommend appropriate solutions.
Typically, Business Needs address new market or technical opportunities, collected feedback from
users/customers, including complaints, or business stakeholders’ insights.
Approaches to establish Business Needs include the following [BABOK]:
• Top down analysis of the Business Goals leading to identification of the Business Needs
required to achieve a goal
• Bottom up analysis of the current (“AS-IS”) state of the organization, department, business
process or business function, or already deployed solution (e.g., software supporting
operations) leading to the identification of the Business Needs required to create value
Business Needs may also result from expectations, wishes or requirements of stakeholders (e.g., a
need for providing information allowing management to make smart decisions) and/or from external
sources such as market demand or competition.
Questions
Recall the definition of a Business Need
Explain how Business Needs can be identified
Gap Analysis – a process of comparing the current state (AS-IS) and desired future state (TO-BE) of
organization, process etc. in order to identify gaps to be addressed [BABOK].
The starting point for Gap Analysis is establishing the current state of the organization (AS-IS),
including understanding the business, vision, mission and goals, business processes, business,
technology and cultural conditions that determine and shape the operations of the organization.
The next step is establishing desired future state (TO-BE) of the organization. Current capabilities of
the organization must be then evaluated against the desired Business Goals and Needs. The result of
evaluation will determine if the organization currently has the capability to satisfy the defined Business
Needs. If the current capabilities do not meet the stated goals, changes must be identified and
introduced to the organization (business, technology, people etc.) to move it to the future state.
Example of Gap Analysis
Investigating the customer satisfaction of customers who return faulty equipment to a
company within warranty for repair.
Gap Analysis
Area under consideration: We are investigating the customer satisfaction when returning faulty
goods within warranty. We are not considering customer satisfaction
outside of warranty, nor the satisfaction of customers at the point of sale.
All the assumptions done during the Gap Analysis should be properly documented as they may impact
the solution approach or delivery scope.
An important element of Gap Analysis is the identification of risks related to the proposed change. A
Risk Management process is necessary to ensure all important risks, especially business risks, are
considered when planning the desired future state of the organization.
Questions
Recall the definition of a Gap Analysis
Explain how Gap Analysis impacts Business Analysis works
Innovation – the process turning an idea into value for the customer and resulting in sustainable profit
for the enterprise [Carlson, Wilmot].
Innovation is the process of looking at something in a different way, or coming up with a different or
novel approach to solving an existing or perceived problem. This process requires people to change
the way they make decisions; to do things differently and make choices outside of their norm.
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:
One of most effective means for achieving competitive advantage is market analysis and research.
Business Analysts should be familiar with these and should be able to use them in planning new
products or improvements in organization process or production.
Market Research – an organized effort to gather information about target markets or customers.
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). 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 to be a key factor in gaining advantage over competitors. It provides
important information to identify and analyze the market’s needs, the market size and the competition.
Market Research clarifies 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.
Common techniques for Market Research include:
• Qualitative and quantitative research
• Mail questionnaires
• Telephone or personal interview surveys
• Observation
• Using technical solutions for collecting data (e.g., Google Analytics)
Market Analysis is a structured and documented investigation of a market helping to determine if there
is a need or audience for a product or service. It is a great help when new products or an expansion of
the business is planned.
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
• 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).
Questions
Recall the definition of innovation, market research and analysis
Explain the role of innovation as a tool for achieving competitive advantage
Explain the role of a Business Analyst in innovation efforts
Explain the role of market research and analysis in Business Analysis
Provide examples of market research and analysis methods and techniques
Stakeholder – any person who has an interest in an IT project. Project stakeholders are individuals
and organizations that are actively involved in the project, or whose interests may be affected as a
result of project execution or project completion.
The process of identifying key stakeholders and collecting their requirements and expectations is one
of the key activities in the Strategy Definition, as it determines the initial scope and requirements for
the solution. However, this activity is often skipped or performed only partially, usually leading to
problems as the solution delivery work progresses.
Solution Approach – alternatives that solve the business problem by using specific solution options.
Solution Proposal – a design option which meets the stated business requirements and business
need under given conditions.
A Feasibility Study allows different solution alternatives to be analyzed and compared to understand
how each option addresses the Business Need as well as how the business value will be delivered.
Feasibility Study – analysis and evaluation of a proposed project to determine if it (1) is technically
feasible, (2) is feasible within the estimated cost, and (3) will be profitable. Feasibility studies are
almost always conducted where large sums of money are at stake. Also called Feasibility Analysis.
In some cases, it is necessary to evaluate the benefits, costs and risks related with a specific solution
delivery initiative before the initiative starts.
Business Case – a document that captures the reasoning for initiating a project or task. It 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.
A Business Case provides the reasoning and justification for the initiative in terms of the value added
to the business as a result of the initiative outcomes, in comparison to the cost of implementing the
proposed solution. A part of a Business Case is cost-benefit analysis explaing the value of the solution
proposal with respect to the cost of solution delivery and maintenance.
A properly built Business Case allows the organization to achieve the following:
• Understand and apply a way of thinking that allows decision makers to analyze the value, risk
and priority of an initiative 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 initiative proposal is of value to the business and is achievable in comparison to
alternative proposals
• Track and measure the progress of the solution’s development
• Ensure that initiatives with inter-dependencies are undertaken in the proper order
Usually, a Business Case is presented in the form of a structured document but 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
• 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 initiative on the business operations or business process
• The impact of the proposed initiative on the technology infrastructure
• Constraints associated with the proposed change or development work
• Risks related with the proposed change or development work
• Alignment with priorities established by the business
Resources Risks
Timescales Initial analysis shows that the system will take approximately 3-4 months
to implement.
Costs IVR software = $35,000
Project management = $30,000
Software team of 3 for 3 months - $90,000
Questions
Recall the definition of a solution proposal, feasibility study, Business Case and solution approach
Provide examples of different solution approaches
Explain benefits and meaning of a Business Case
Recall the content of a typical Business case
Business documentation, provided as output from Strategy Analysis activities, serves as important
input to the development of the PID and summarizes the delivery scope and key business
expectations and conditions. This creates a basis for establishing project scope. An important
element of change or development project initiation is the identification of risks and preparing a
mitigation plan [ISO 31000].
Questions
Recall the definition of project initiation and project scope
Provide examples of different project initiation activities
Explain the concept and content of PID
Answer set
[A] X – P; Y – Q; Z – R.
[B] X – S; Y – T; Z – U.
[C] X – P; Y – S; Z – T.
[D] X – U; Y – P; Z – P.
Terms
Agile, Communication Plan, Maturity Model, RACI
3.1 Introduction
The purpose of this chapter is to explain the main elements of planning and managing Business
Analysis processes in a given context. Planning should consider the following factors:
• Development/maintenance method or culture of organization (e.g., traditional vs. Agile)
• Necessity for interdisciplinary approach
• Communication requirements and participants
• Definition of products from Business Analysis
• Organizational assets such as tools and techniques
In addition, planning the Business Analysis approach should also include the planning approach to
Requirements Engineering (see: 4 Requirements Engineering in Business Analysis ).
The generic model for Business Analysis used in a given organization should be adjusted to the
current context. In many cases it is necessary to consider consequences resulting from different
approaches to development or maintenance efforts.
Process Model:
(1) A framework wherein processes of the same nature are classified into an overall model, e.g. a test
improvement model.
Figure 33 V-Model
Agile is based on the concept of incremental and iterative development with minimal planning. Agile
recognizes the fact that business context and requirements may change and provides special
practices to support these changes. The main ideas behind Agile:
• “Just in time”
• Adaptability
• Customer involvement during all development/maintenance
• Frequent communication
Currently many organizations and teams are transforming from a traditional to an Agile approach. This
impacts not only processes, but also role definitions. In a traditional approach a Business Analyst was
responsible for elicitation of needs and requirements, upfront planning and proposing solution options.
Communication with delivery team was rather limited to interactions necessary in a given context.
In Agile, this way of working changes; the Business Analyst should follow the principle of “fit-for-
purpose” or “just enough”. Stakeholders should be empowered to articulate their needs and assist the
delivery team on a daily basis. An important consequence of an Agile transformation is rejecting
formalities such as collecting and confirming all requirements before starting development or creating
detailed requirements documents. In Agile, the Business Analyst will work with the customers,
stakeholders and the development team in order to create a high-level requirements list. The
requirements will be detailed and implemented in priority order – they will be refined only when it is a
time for developers to start working on them.
In many organizations, the main challenge in an Agile transformation is not the process change, but
the mindset change.
Adapting Business Analysis to Agile environments requires some changes in the process and work
organization. However, the main tasks and responsibilities of Business Analysts remain the same:
• Providing expert knowledge in the business and/or product
• Defining the business goals, business context, risks and potential impacts of the solution on
the organization and stakeholders
• Defining change, which is understood as the gap between AS-IS and TO-BE
• Supporting communication between business stakeholders and delivery team
Possible solutions for Business Analysis in Agile environments are:
• Business Analyst as a Product Owner, responsible for definition and realization of the product
• Business Analyst supporting the Product Owner in more technical tasks, when the Product
Owner provides only business knowledge
• Business Analyst competencies in the development team, when the team supports the
Product Owner with transforming high-level requirements into specific development tasks
In Agile, some specific tools and techniques will be used. Examples include: backlog, user story, story
mapping, Kanban.
Questions
Recall the different approach to development and maintenance
Explain the difference between Business Analysis in Agile and non-Agile environments
Explain the different solutions for Business Analysis in Agile environments
Provide examples of methods and techniques specific to a given development approach
User Experience (UX) – a person's perceptions and responses that result from the use or anticipated
use of a product, system or service [ISO 9241-210].
Design Thinking – a 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. In
short, design thinking converts need into demand. The process is described in three major phases:
inspiration, ideation, and implementation.
Digital Design
“Digital designers design and optimize by communicating and leading. A digital designer is someone
who thinks about the future, someone who is capable of creating a vision for digital products,
processes, services, business models, or even entire systems, free from technical or organizational
obstacles as well as apparent reservations (outside-in thinking). Digital designers are also capable of
ultimately turning this vision into reality. They transfer (technological) possibilities into (new)
product/process/service/business model/system design. To do all of this, digital designers must be
skilled in design and the available technologies and be capable of interacting with all stakeholders.
The difference to previous approaches lies in the simultaneous and holistic consideration of all
components and their design. Just like an architect has to think about the materiality, environment,
and economic efficiency of a building as well as the actual layout, a digital designer will have to think
about the same things for their product. This means that not only software and the associated
interface design, but also the physical product design and aspects such as economic efficiency,
psychology, cognitive sciences, social sciences, occupational sciences, ergonomics, marketing, and
communication design and many other aspects must be understood and considered to the extent that,
in case of doubt, corresponding expertise can be engaged constructively.“ [DD Manifesto]
In addition, the following concepts may support effective Business Analysis:
• Multidisciplinary Teams (teams which members represent different backgound, skills and
experience)
• Enlightened Trial and Error (a method invented by IDEO based on the following principle:
learning from experience, and then trying again, using lessons learned)
• Lean startup
3.3 Communication
The main purpose of planning Business Analysis communication is to define how to receive, distribute,
access, update and escalate information to and from the stakeholders, as well as how to organize the
schedule and structure of the communication within a change or development program/project.
Business Analysis activities and deliverables can be communicated in both formal and informal ways.
Communication
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.
There are many different factors which should be considered when planning Business Analysis
communication. These factors include:
• Type of initiative or business problem
o Formal communication in case of safety critical projects
o Less formal and direct communication in case of Agile projects
• Stakeholders’ requirements
o Stakeholders who expect direct communication
o Stakeholders who expect written communication and formal channels of
communication
• Required level of communication formality
o Formal communication in case of communicating requirements, changes, risks, etc.
o Less formal communication for daily team communication
• Communication frequency
o More frequent communication with business stakeholders in the beginning of a
project/initiative
o More frequent communication with the team during solution development
• Geographical location
o Different time zones may make the communication difficult
o Face to face meetings may be difficult to organize and quite expensive
• Culture
o Culture of an organization, including maturity level, may impact communication style
and rules
o Different cultures have different communication styles
Different types of initiatives require varying amounts of documentation, and often have diverse
processes and different deliverables. Communication formality varies between initiatives, phases and
stakeholders. Communication tends to be more formal when the initiative is large, is considered to be
critical or strategic, is dependent on legislation, sector standards, or agreements, or if the business
domain is complex. Some stakeholders may require formal communication regardless of other
conditions. Communication frequency may vary among stakeholders for every form of communication.
Geographic disparity can also be a factor that limits communication options, especially when
stakeholders live in different time zones.
Communication plan – a plan formally defining the audience of given, specific information, the
timetable for information delivery and communication channels to be used.
The communication plan explains rules of communication with the key stakeholders.
The communication plan is often supported by a RACI matrix – a responsibility assignment matrix –
allowing the definition of responsibilities of the different roles involved in completing tasks or
deliverables for a given initiative.
Questions
Explain the role of communication in Business Analysis
Provide examples of factors influencing communication
Recall the definition of a communication plan
Explain the meaning of a communication plan
Recall the content of a typical communication plan
Provide examples of different roles involved in Business Analysis activities and explain their
responsibilities
3.4 Products
The typical work products of Business Analysis activities are:
• Strategy definition
o List of stakeholders
o Business processes
o Gaps
o Market research results
o Business needs
o Business requirements
o Solution options
o List of business risks
o Opportunities
o Business constraints
o Business case
• Management of the Business Analysis process
o Business Analysis approach
o Communication plan
o Business Analysis assets (templates, etc.)
o Quality gates for requirements and/or solution design
• Requirements Engineering in Business Analysis
o Stakeholders requirements
o Solution/product requirements
o Solution constraints
o Solution design options
o RTM (Requirements Traceability Matrix)
o Requirements configuration
• Solution evaluation and optimization
o Solution performance assessment
o Improvement plan
These deliverables support the understanding of the vision and mission of the organization, as well as
the goals and desired future state together with factors influencing the ability to achieve this future
state.
Figure 48 Sample Business Analysis approach – Project initiation and requirements elicitation
One of the most important Business Analysis deliverables is the identified requirements, especially the
business and stakeholder requirements. From the organizational point of view, business requirements
express the major needs required to achieve the stated mission and goals (see: 2.2.1 Vision, Mission
and Business Goals). From a project/program perspective, requirements define the scope of delivery
and facilitate planning.
Questions
Explain the role of a requirement and other key Business Analysis deliverables for an organization and
a program/ project
Provide examples of typical Business Analysis products
SWOT Analysis
Figure 51 SWOT
Ishikawa diagram
© International Qualifications Board for Business Analysis page 61 of 148
Certified Business Analyst Foundation Level Handbook
Some Business Analysis products use tools, techniques and notations that also are used for
Requirements Engineering (see: 3.5 Tools and Techniques )
Questions
Provide examples of different types of tools supporting Business Analysis activities and explain their
application
Provide examples of different types of techniques supporting Business Analysis activities and explain
their application
3.5.2 Notations
BPMN (Business Process Modeling Notation) is a standard language for expressing business
procedures, workflows and communication between business participants. BPMN uses graphical
notation to facilitate communication between stakeholders and provides a means to model and
understand the business and its participants (see: 2.2.2 Business Process Analysis). Elements of the
notation are quite intuitive, however they also are able to represent complex process semantics.
Business Process Modeling Notation (BPMN) – a graphical notation that depicts the steps in a
business process. BPMN depicts the end to end flow of a business process. The notation has been
specifically designed to coordinate the sequence of processes and the messages that flow between
different process participants in a related set of activities [BPMN].
BPMN notation is based on a flowcharting technique and is dedicated to support modeling and
communication for both technical users and business users.
Answer set
[A] Nothing – the responsibilities of the Business Analyst may remain the same.
[B] The Business Analyst must take over the role of the Product Owner, because this role
corresponds to the responsibilities of Business Analyst in Scrum.
[C] The Business Analyst should move to a more technical position supporting the Product
Owner, as the Scrum team prefers technical team members.
[D] The Business Analyst becomes the owner of the Kanban-related processes.
Question
Which of the following statements most likely describes products of strategy definition only?
Answer set
[A] Communication plan, stakeholder descriptions, business solution options, business case
[B] Definition of business processes, business needs, gap analysis, solution options
[C] Business risks, stakeholders’ requirements, solution performance assessment
[D] Business Analysis tools and techniques, business analysis documentation templates, quality
requirements for the process, improvement plan, RTM
A, C and D – Incorrect. These answers contain characteristics of non- Agile approach (upfront
planning, scope definition). D can be present in both Agile and non-Agile approaches.
Question 3.2 – answer D
Justification
D – Correct. As stated in the IQBBA syllabus, section 3.2.1:
Concepts related to Agile:
• Fit for purpose
• Just enough
• Clear product/project vision
• Frequent communication
• Empowering stakeholders to express needs
• Prioritization of requirements
Non-Agile concepts:
• Upfront planning
• Monitoring and control
• Clear product/project vision
• High level of formality
• Detailed requirements documents
A – Incorrect. Agile does not value upfront planning.
B – Incorrect. Business analysis in non-Agile projects can be done in an iterative and incremental way
(eg. RUP).
C – Incorrect. “Fit for purpose” concept is typical for Agile.
Question 3.3 – answer A
Justification
A – Correct. Some key responsibilities are the same.
B – Incorrect. PO is not the same as BA. The BA does not always become a PO – the scenario
contains no information about the need of transforming the BA into the role of PO (no info about
responsibility for the product).
C – Incorrect. There is a place for a BA in Agile, non-technical people are also needed.
D – Incorrect. There is nothing in the scenario suggesting there is a Kanban process that a BA should
take care of. In addition, there is no rule that a BA should manage the Kanban-related process.
Question 3.4 – answer B
Justification
B – Correct. OCL, as a language used to define constraints for UML elements, would be useful for an
architect or system analyst, but will not likely be used by a business analyst.
A, C and D – Incorrect. All these disciplines may support BA work
A, B and D– Incorrect. There is nothing in the scenario suggesting the factors mentioned in the
answers can influence communication.
Question 3.6 – answer A
Justification
A – Correct. SWOT “is a strategic planning technique used to help a person or organization identify
strengths, weaknesses, opportunities, and threats related to business competition or project planning“
(https://en.wikipedia.org/wiki/SWOT_analysis)
B, C and D – Incorrect. These are typical contents of a communication plan, as explained in the
IQBBA syllabus, section 3.3.
Question 3.7 – answer B
Justification
B – Correct. You need to create a communication plan explaining all the aspects of communication:
• Subject of communication (work product, task, etc.)
• Stakeholders involved (audience)
• Frequency of communication
• Medium of communication
• Person responsible for communication
(IQBBA syllabus, section 3.3.)
A – Incorrect. There is no need to involve the representative in ALL stages and activities of the
solution development process. The level of involvement should be adjusted to the real needs and
established in a form of a communication plan.
C – Incorrect. Involving the customer representatives in solution validation activities only will not
ensure that the expectations and needs of the representatives are correctly collected and delivered.
The level of involvement should be adjusted to the real needs and established in a form of a
communication plan. In addition, this approach would not work in Agile environments.
D – Incorrect. See C.
Question 3.8 – answer C
Justification
C – Correct. Solution architect is a technically oriented role.
A, B and D – Incorrect. Key characteristic of PO is representing business. User representatives
represent business perspective. Domain expert can represent either business or other point of view –
this is not specified here.
Question 3.9 – answer C
Justification
C – Correct. It refers to project point of view, as explained in the IQBBA syllabus, section 3.4.
A – Incorrect. Business requirements express needs of a business, they do not focus on software
functions.
B – Incorrect. It refers to organization point of view, as explained in the IQBBA syllabus, section 3.4.
D – Incorrect. It is a definition of a vision.
Question 3.10 – answer B
Justification
B – Correct – as explained in the IQBBA syllabus, section 3.4.
A, C and D – Incorrect. These answers contain products belonging to other areas.
Terms
Assumption, Baseline, CCB (Change/Configuration Control Board), Change Management, Change
Request, Configuration Item, Configuration Management, Conflict, Conflict Management, Constraint,
Elicitation, Information Architecture, Quality Assurance, Requirements Development, Requirements
Document, Requirements Engineering, Requirements Management, Requirements Modeling,
Traceability
Questions
Recall the definition of Requirements Development
Explain the main activities, products and methods used in Requirements Development
4.1.2 Elicitation
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.
Elicitation – the act of obtaining information from other people. In the context of Requirements
Engineering, elicitation is the process of gathering requirements from stakeholders.
Requirements source – the source from which requirements have been derived. Requirements
sources can be stakeholders, documents, business processes, existing systems, market, etc.
• Stakeholders
• Business context
• Business documents
• Business policies
Requirements
• Standards and regulatory statutes
sources
• Previous architectural design decisions
• Systems/solutions in use
• Technology
• Legacy products or product components
These sources can influence the chosen technique for Requirements Elicitation. Requirements
Elicitation is not only collecting stakeholders’ needs by asking questions – very often the information
collected has to be interpreted, analyzed, modeled and validated before a complete set of
requirements for a solution can be established. The elicitation techniques and tools to be used are
sometimes driven by the choice of the modeling diagrams or the general analysis approach. Many
modeling techniques imply the use of a particular kind of elicitation technique as well.
The following techniques are used during Requirements Elicitation:
Questionnaire
A questionnaire consists of a several questions to be answered by the respondent. These can be
open-ended or closed-ended questions. An open-ended question requires from the respondent to
formulate his own answer. In case of a closed-ended question the respondent is asked to choose an
answer from a number of possible options. These options should be mutually exclusive.
The following are the principles of constructing a questionnaire:
• Using clear and easily understandable wording
• Formulating questions and answers in an unambiguous way to avoid misinterpretation
• Avoiding assumptions about the respondent’s opinions and personality
• Ensuring one question is asking about only one problem
• Ensuring that answers to a specific question are clearly different
Prepare questionnaire
Sample question
About how many books are there in your home?
(Do not count newspaper or magazines)
❑ None
❑ 1-10
❑ 11-50
❑ 51-100
❑ 101-200
❑ More than 200
Interview
An Interview is a conversational technique where the interviewer is asking the responder questions to
obtain information on specified topic. This technique is interactive and permits the interviewr to modify
the order in which previously prepared questions are asked depending on the responder’s answers
and the situation.
The following are three primary forms of an interview:
• Structured interview (standardized interview) – interview consists of a set of exactly the same
questions which are asked in the same order
• Semi-structured interview – new questions can be brought up during the interview as a result
of what the responder says
• Unstructured interview – questions do not include a predefined and limited set of answers to
be chosen by the respondent and can be changed during the interview
Persona and user story
Creating personas can help to understand users and their characteristcs. A persona represents a
group of users of the planned solution and is one of user-centered design methods.
User stories express requirements from a user’s point of view in the following form: As a [role], I want
[feature] so that [benefit]. Persona, user stories and user scenarios are often used together.
See also: 4.1.4 Specification
Use case
A use case is a form of expressing functional requirements perceived from an actor perspective. A use
case specification contains a list of actions or event steps defining the interactions between a role
(actor) and a system to achieve a given goal. See also: 4.1.3 Analysis and Modeling
Use Case: <number> <the name should be the goal as a short active verb phrase>
•CHARACTERISTIC INFORMATION
•Goal in Context: <a longer statement of the goal, if needed>
•Scope: <what system is being considered black-box under design>
•Level: <one of: Summary, Primary task, Sub function>
•Preconditions: <what we expect is already the state of the world>
•Success End Condition: <the state of the world upon successful completion>
•Failed End Condition: <the state of the world if goal abandoned>
•Primary Actor: <a role name for the primary actor, or description>
•Trigger: <the action upon the system that starts the use case, may be time event>
•MAIN SUCCESS SCENARIO
•<put here the steps of the scenario from trigger to goal delivery, and any cleanup after>
•<step #> <action description>
•EXTENSIONS
•<put here there extensions, one at a time, each referring to the step of the main scenario>
•<step altered> <condition> : <action or sub.use case>
•<step altered> <condition> : <action or sub.use case>
•SUB-VARIATIONS
•<put here the sub-variations that will cause eventual bifurcation in the scenario>
•<step or variation # > <list of sub-variations>
•<step or variation # > <list of sub-variations>
User scenario
A user scenario is a description of user-system interaction in the form of a realistic example. Scenarios
are created based on the high-level requirements. Scenario covers a specific task to be done by a
user and is written in a narrative form.
Self-recording
A stakeholder (end user, business representative) documents his activities performed to complete a
specific task or process. The procedure may require documenting all steps, inputs and resources
needed to complete a given task.
A recommended practice is to document not only “AS-IS” activities but also changes, desires and
needs.
The main disadvantage of this technique is that automated activities may be forgotten or neglected
and therefore not documented and considered as requirements.
Consultancy
Elicitation driven by a representative of the end user, SME, business stakeholder, etc. A
representative does the following:
• Provides user-centered requirements
• Monitors the progress
• Validates correctness of the design
• Provides quick feedback and additional information wherever necessary
This technique allows close cooperation and direct communication with the customer and is one of the
most effective requirements identification (and validation) methods.
Analysis of existing business documents
This technique is used when there is existing documentation that can help in identifying requirements
within an organization.
The basis for analysis can be:
• Process models and maps
• Process descriptions
• Organization structure
• Product specification
• Work procedures
• Standards and instructions
Such documents may serve as a basis for requirements identification for a new solution.
The requirements identified are the basis for further requirements analysis and needs to be detailed
and extended with other, related and linked requirements.
Brainstorming
Brainstorming is a creativity technique used to collect requirements related to areas of the
organization’s activity or planned solution functionality that are not well known or are new . The
technique is used to collect many ideas from various stakeholders in a short time and with low cost.
During the brainstorming session the participants submit ideas and concepts regarding a given
problem. These ideas are noted down and then analyzed in order to select those most appropriate
and feasibile.
Preparation
•Develop a clear definition of the area of interest.
•Determine a time limit for the group to generate ideas.
•Identify facilitator and participants for the session.
•Establish criteria for evaluating and rating the ideas.
Session
•Share new ideas without any discussion, criticism or evaluation.
•Visibly record all ideas.
•Encourage participants to be creative, share exaggerated ideas, and build on
the ideas of others.
Wrap-up
•Create a condensed list of ideas, combine ideas where appropriate, and
eliminate duplicates.
•Rate the ideas. Distribute the final list of ideas to appropriate parties.
Field observation
Field observation is a technique used to conduct an observation of the target work environment and
recognize and understand processes to be improved or supported by the solution.
Variations on observation:
• Participating in the actual work as an end user
• Becoming a temporary apprentice for someone
• Watching a demonstration of what should be done
Observe
•Introduce yourself to the person being observed
•Conduct observation, take notes
Apprenticing
Apprenticing is a process of learning from a given person (end user, customer) his job. The person
who knows the process, teaches the Business Analyst – this approach is also known as “Master and
student”. The “student” is sitting down and watching the “master” working, asking questions in case of
problems, and explaining the tasks being performed.
Workshops with stakeholders
Conducting workshops is a structured way to discuss and make decisions and can involve
stakeholders representing different areas and/or domains.
Workshops may be used to:
• Identify requirements
• Uncover hidden requirements
• Develop requirements in a newly identified area
• Prioritize requirements
• Reach consensus on requirements when it comes to requirements agreement (sign off)
• Review results of a specified process or activity and resolve issues that might have appeared
Elicitation results – requirements – should be properly documented to allow further tracking and
Requirements Analysis. It is important to remember that common language has some limitations and
disadvantages. This may cause the description of the requirements to be unclear and ambiguous.
Therefore, proper standards and templates should be used wherever possible. In addition to
standards and templates, using published vocabularies is an important tool to facilitate communication
between different stakeholders and to introduce some control over the natural language's ambiguity.
Questions
Recall the definition of elicitation
Explain the role of business needs and business requirements in elicitation and solution planning
Provide examples of different techniques for elicitation and explain their application
A common technique for requiremenets organization and grouping in Agile is Story mapping.
During analysis, additional information impacting the solution, such as constraints and assumptions,
may be identified.
Requirements Analysis – a set of tasks, activities and tools to determine whether the stated (elicited)
requirements are unclear, incomplete, ambiguous, or contradictory, and then documenting the
requirements in a form of a consistent model.
Element Example
System must be built in Java
Constraint
Product must go live before the start of the next business year
Users have experience with similar products
Assumption
Integration with CRM should be ready on time
Conflict management
During Requirements Analysis, conflicts may be discovered. A conflict is when two or more values,
perspectives or opinions are contradictory in nature and have not yet been agreed or aligned.
Conflict – a situation appearing when different values, perspectives or opinions are contradictory in
nature.
Conflict Management – the process of limiting the negative aspects of conflict while increasing the
positive aspects of conflict.
One of the most popular models of Conflict Management suggests the following techniques to deal
with a conflict:
• Collaborating: win/win
• Compromising: win some/lose some
• Accommodating: lose/win
• Competing: win/lose
• Avoiding: no winners/no losers
Conflict identification
Conflict analysis
Conflict resolution
Figure 71 Conflict Management process
It is recommended that key information related to conflicts, their sources, methods for resolution and
results be documented. This information may help in further process improvement.
Modeling
Analysis often includes modeling activities. Modeling is a way of expressing real objects 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 the case of large and complex solutions,
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 in 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.
Solution Modeling can use several types of models, but in general three basic levels of models exist.
Different model perspectives may be used for the above levels depending on the point of view to be
presented via the specific model. Common perspectives applicable to modeling the problem or
solution domain include the following:
Different levels of modeling and different views of the solution can be described by different diagrams.
To get a full picture of the solution, usually a combination of different views is used. This results in
using different diagrams describing the solution model from specific perspectives.
Prototype – an early sample or model built to test a concept or process or to act as something that
can be replicated or learned from. In Requirements Engineering, prototypes can be used for
requirements elicitation and validation.
• Card sorting
• Wireframe
• Screen layout
• Programmed prototype
During modeling activities, especially when modeling data content and structure, practices derived
from Information Architecture are often applied (see: 4.2.2 Information Architecture ).
Questions
Recall the definition of requirements analysis and modeling
Explain the process of prioritization and its application in terms of solution design and development
Recall the definition of an assumption and limitation
Explain the impact of assumptions and limitations on solution scope and design
Provide examples of different solution modeling methods
Provide examples of the different views of requirements/solution modeling
Explain the concept, elements and application of UML activity, use case and state machine diagrams
Recall the definition of a conflict, conflict management and conflict resolution
Explain the role of conflict management in requirements analysis and negotiation
4.1.4 Specification
Requirements Specification describes the problem area of interest (a business solution proposal for a
given business problem, need, or objective, etc.) and contains at least the following information:
• Business requirements together with their acceptance criteria
• Limitations and assumptions
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 on the solution scope and capabilities, and provides input
information for the other members of the solution delivery or maintenance team.
Depending on the abstraction level, requirements can be described with more or less detail. In some
development models, business requirements can be written in the form of high-level use cases (for
example, Rational Unified Process), or user stories (Agile approaches).
Figure 80 Different approaches to specification (IREB Certified Professional for Requirements Engineering-
RE@Agile Primer - Syllabus and Study Guide, Version 1.0, March 15, 2017)
In general, the typical structure of a business requirement statement should cover the following
aspects:
• The user – who would need and/or use this requirement?
• The result – what is the result the stakeholders are looking for?
• The object – what is the object the requirement addresses?
• The qualifier – what is the qualifier that is measurable?
Another type of a specification is a User Story. User Stories are often used with Agile development
methodologies. User Stories are a quick way of handling customer/user requirements. The intention of
the User Story is to be able to respond faster and with less overhead to rapidly changing real-world
requirements.
User Story – a short, simple description of a feature told from the perspective of the person who
desires the new capability, usually a user or customer of the system.
User Story
As a [role], I want [feature] so that [benefit]
A User Story describes the functionality that will be valuable to the customer. It is composed of three
aspects [Cohn]:
• A written description of the story used for planning and as a reminder (usually in a form of a
statement “As a [role], I want [feature] so that [benefit]”)
• Conversations about the story that serve to flesh out the details of the story
• Tests that convey and document details and are used to determine when a story is complete
User Stories are often used together with Personas (i.e., archetype characters) representing a specific
type of end user role.
Persona – a fictional character, an archetype description, which represents 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, attitude, behavior or expectations towards the product.
When documenting particular requirements, the Business Analyst should follow common standards
and guidelines [ISO/IEC/IEEE 29148]. Some examples of these are shown below.
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
When creating a requirements document, the Business Analyst should remember that requirements
specifications must be complete, consistent, modifiable, and traceable [Wiegers].
A requirements specification does not have to be a formal “specification” document. For example, it
could be a sprint backlog or a set of requirements maintained in a requirements management tool.
Questions
Recall the definition of requirements specification
Explain the meaning and application of requirements documentation
Provide examples of different requirements specification templates and methods
Validation – confirmation by examination and through provision of objective evidence that the
requirements for a specific intended use or application have been fulfilled [ISO 9000].
Verification – confirmation by examination and through provision of objective evidence that specified
requirements have been fulfilled [ISO 9000].
Requirements validation and verification should be done continuously during the development of the
solution to ensure that the product being developed meets the quality criteria and will satisfy the
stakeholders’ needs. The best practice is to plan and perform validation and verification of
requirements from the early phases of solution development – ideally starting with requirements
elicitation.
Walkthrough
Prototyping Inspection
V&V techniques
Presentation
Evaluation of
quality criteria
Figure 90 V&V techniques
Common techniques for validation and verification include different types of reviews and/or prototyping
or presentations of the proposed solutions or requirements to the stakeholders with the goal of
receiving feedback. Validation and verification activities should also include ensuring that the
requirements and/or requirements/solution specifications conform to company standards (templates)
and are documented and then tested against the quality criteria.
• Completeness
• Consistency
• Correctness
Quality • Abstraction (not determining the solution)
criteria for • Feasibility
requirements • Measurability
• Necessity
• Traceability (to source)
• Unambiguity
reqFigure
Requirements
91 Quality Checklist
criteria for requirements
RequirementsChecklist1
Atomic
Attainable
Cohesive
Complete
Current
Independent
Modifiable
Traceable
Unambiguous
Verifiable
It is also important to validate the models developed during the requirements analysis and
specification activities. As requirements are the basis for solution development and testing, their
quality is crucial for the success of the change or development. As they help define the appropriate
levels and coverage of testing, clear, complete, consistent and testable requirements reduce the risk
of product (or even more importantly, project) failure. It is therefore recommended to involve testers in
reviews of requirements, as they can significantly help improve the quality of the requirements and/or
solution specifications by identifying weak points and possible defects.
Testability of requirements is supported by acceptance criteria. Acceptance criteria describe criteria
that must be met to approve the solution and should be agreed on by stakeholders before starting
solution realization. Every high-level requirement must have at least one acceptance criterion and
each of the criterion must be measurable by a realistic and agreed upon means. Such criteria often
create the basis for the quality plan and acceptance testing.
Questions
Recall the definitions of validation and verification
Explain the role of validation and verification in assuring quality of Business Analysis work products
Provide examples of different validation and verification methods and techniques
Provide examples of quality criteria for requirements
This discipline is often considered as part of designing the structure of information on web pages [Web
Style Guide], however its main principles should be applied to build a structure for the Business
Analysis information (deliverables and work products) as well.
The main components of IA are [Rosenfeld, Morville]:
• Organization schemes and structures – method of categorizing and structuring information
• Labeling systems – method of representing information
• Navigation systems – specification of how to browse and move through the information
• Search systems – methods allowing to search for information
Creating a useful architecture of information requires understanding some aspects such as those
shown in the diagram below.
In the context of Business Analysis and Requirements Management, IA can be applied to understand
and structure information collected in a way that would be accessible and understandable for all key
stakeholders and users of this information. Sample applications of IA include:
• Defining appropriate levels of information (e.g., strategy analysis, business requirements,
solution requirements, design options)
• Defining relevant deliverables for specific activities
• Defining required content and structure for analysis deliverables and work products (e.g.,
templates, available methods of representing information)
• Establishing communication methods for accessing, browsing and navigation through the
information
Questions
Recall the definition of information management
Explain the concept, purpose and methods of establishing an information architecture
Provide examples of elements of an effective information architecture
Analyst as his/her responsibility is to not only identify and document the business and stakeholders’
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 levels and represent different domains. The role of a Business Analyst is to
communicate requirements in such 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.
Questions
Recall the definition of communication
Explain the concept, purpose and methods for requirements approval
Provide examples of activities of requirements communication
4.2.4 Traceability
Traceability is the association existing between artifacts on different abstraction levels. In the context
of Business Analysis, traceability can exist between high level Business Needs, and business
requirements, then between business requirements and solution requirements, etc.
Traceability – the ability to identify related items in documentation and software, such as
requirements, with associated tests
Requirements traceability – the ability to define, capture and follow the tracing left by requirements
on other elements of the software development environment and the trace left by those elements on
requirements [Pinheiro F.A.C. and Goguen J.A].
Tracing allows proper management of artifacts, especially in the areas of managing evolution,
changes and coverage analysis. Traceability between requirements, and other solution delivery
artifacts (such as design elements to test cases), allows the Business Analyst to ensure all
requirements have been fulfilled.
Example
Consider online shopping system allowing customers to search for products, place orders
and make payments.
The following diagrams show different applications of traceability.
Scope
management
Figure 102 Traceability and scope management – UC Modify product may be out of
scope
Coverage
analysis
Figure 103 Traceability and coverage analysis – FR Order products is covered by two use
cases
Impact
analysis
Figure 104 Traceability and impact analysis - impact of change in FR Order products
Use of
requirement
Figure 105 Traceability and usage analysis - UC Search product is used twice in the
system model
Traceability is often supported by tools used to manage requirements or managed via a Requirements
Traceability Matrix (RTM).
Questions
Recall the definition of traceability and RTM
Provide examples of theapplications of traceability
Configuration – the composition of a component or system as defined by the number, nature, and
interconnections of its constituent parts.
The purpose of Configuration Management is to establish and maintain the integrity of the products
(components, data, and documentation) and the system artifacts, throughout the development and
product life cycle. Configuration Management makes use of technical and administrative tools and
techniques.
Configuration Auditing – the function to check on the contents of libraries of configuration items,
e.g., for standards compliance [IEEE 610].
Business Analysis activities produce many work products, and typically all of them must be identified
as configuration items, baselined and controlled. Sample Configuration Items for Business Analysis
include:
• Single requirements (business requirements, solution requirements)
• Business Needs
• Requirements specifications and other documents
• Business models
In the context of 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 items (e.g., development artifacts) so that traceability can be maintained
throughout the realization or maintenance process.
Configuration Management procedures and infrastructure (tools) should be defined and documented
at both the organizational and initiative level.
Change Management
Change Management can be considered as a sub-discipline of Configuration Management, and
supports managing changes of the requirements in an effective way.
Change Management:
(1) A structured approach to transitioning individuals, teams, and organizations from a current state to
a desired future state.
(2) A controlled way to effect a change, or a proposed change, to a product or service.
Changes can result from:
• New or changing business requirements (resulting from new regulations, changes within the
business domain, new capabilities requested by stakeholders, etc.)
• Solution improvement efforts
• Business process improvement initiatives
• A defect found in the code, documentation or requirements
• External changes (regulatory, legal, etc.)
Evaluating and
Realization of the Planning the change
estimating the
change realization
change
Reviewing and
closing the Change
Request
When the need for a change appears, there should be a Change Request raised by the stakeholder
requesting the modification. Requested changes are analyzed by Change Control Board.
Configuration (Change) Control Board (CCB) – a group of people responsible for evaluating and
approving or disapproving proposed changes to configuration items, and for ensuring implementation
of approved changes [IEEE 610].
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.
Questions
Recall the definition of configuration, configuration item, Configuration Management and baseline
Explain the process of Configuration Management and its main outputs
Provide examples of configuration items
Recall the definition of version, change management and change request
Explain the typical content of a change request
Explain the process of Change Management and its main outputs
Scope – the extent of influence of something. Scope can apply to anything, like a specification, or a
specified system or project [TGilb].
Solution scope – definition of the set of capabilities a solution must deliver in order to meet stated
business requirements and business needs.
Quality – the degree to which a component, system or process meets specified requirements and/or
user/customer needs and expectations [IEEE 610].
Quality Assurance – part of quality management focused on providing confidence that quality
requirements will be fulfilled [ISO 9000].
Quality Assurance is defined as “all the planned and systematic activities implemented within the
quality system, and demonstrated as needed, to provide adequate confidence that an entity will fulfill
requirements for quality” [ISO 9000]. This definition implies that the actions taken are “planned and
systematic” and they “provide adequate confidence” that the desired level of quality will be achieved.
These actions include operational techniques and activities used to fulfill the requirements for quality.
To achieve the required level of quality, Quality Control is needed as well. The main goal of Quality
Control is to steer and control the quality of products or services through use of operative methods so
that they meet specified standards. The operative methods involved in Requirements Engineering
include Project Management, Risk Management, Change Management, Verification and Validation,
reviews, and Configuration Management and Tracing of Requirements.
In the context of Requirements Engineering, Quality Control may also focus on verifying whether the
produced requirements documentation meets relevant quality criteria.
In order to ensure the required level of quality, verification and validation should be planned and
executed from the beginning of the initiative.
Quality Assurance and Quality Control of requirements and related work products may be supported
by the following means:
• Standards and templates
• Traceability to manage scope
• Different types of reviews
4.3.2 Notations
One common method of solution modeling is UML (Unified Modeling Language). UML is a unified
notation for the analysis and design of systems. The notation provides several types of diagrams to
describe different views of the solution. These diagrams are divided into behavior and structure
diagrams, where behavior diagrams depict behavioral features of a system or business process, and
structure diagrams depict the structural elements composing a system or function.
To model more complex solutions, especially in System Engineering, another unified modeling
notation can be used – SysML (System Modeling Language). SysML allows for modeling a wide range
of systems which include hardware, software, information, processes, personnel and facilities.
SysML reuses seven of UML’s diagrams and provides two new diagrams: a requirement diagram
which captures functional, performance and interface requirements and a parametric diagram to define
performance and quantitative constraints.
Questions
Explain the purpose and application of formal modeling notations (UML and SysML)
Explain basic elements of UML diagrams: activity, use case, state machine, and class diagram
[D] Workshops with randomly selected customers in order to collect information about target
business process, personas and user story defined by the lead of the development team,
interviews with all outstanding business stakeholders
You are modeling requirements for an ATM. Your model should cover the process of entering the PIN
by the customer. The following state machine diagram represents the results of your work.
Answer set
[A] Solution requirements
[B] Main scenarios for system use cases
[C] Limitations and assumptions impacting the project
[D] Structured business requirements
The client decided to change the Business Need 3. How many test cases are needed to be analyzed
in this situation?
Answer set
[A] 3
[B] 4
[C] 5
[D] It is impossible to answer, because the test cases are not traced back to the business needs.
Which of the following statements best explains the meaning of QA in building the right approach to
Business Analysis?
Answer set
[A] QA covers all activities and task required to evaluate the solution against market demands.
[B] QA provides a means for ensuring that the selected approach to Business Analysis will fulfill
specified requirements for quality.
[C] QA povides a means to control the quality of products in terms of meeting specified quality
criteria.
[D] QA provides a set of tools and techniques ensuring the solution meets the specified business
requirements.
D – Incorrect. Risk management is not a main activity of requirements engineering process, in addition
the scenario does not mention risk management.
Question 4.5 – answer C
Justification
C – Correct – as explained in the IQBBA syllabus, section 4.1.3
A – Incorrect. Requirements models “describe the problem area”.
B – Incorrect. Conceptual models “represent concepts (entities) and relationships between them”
(IQBBA syllabus, section 4.1.3)
D – Incorrect. Solution models “describe the solution area from different points of views and determine
the shape of implementation of the functional and non-functional requirements” (IQBBA syllabus,
section 4.1.3)
Question 4.6 – answer A
Justification
A – Correct – as explained in the IQBBA syllabus, section 4.1.2
B, C and D – Incorrect. Not compliant with the IQBBA syllabus, section 4.1.2
Question 4.7 – answer A
Justification
A – Correct. The case of entering PIN incorrectly 4 times is modeled. Only after entering wrong PIN 4
time the card is blocked.
A and B – Incorrect. These answers refer to a solution document rather than a standard business
requirements document and are not mentioned in the IQBBA syllabus, section 4.4.1
C – Incorrect. This refers rather to project plan.
Question 4.10 – answer B
Justification
B – Correct – as explained in the IQBBA syllabus, section 4.1.5
A – Incorrect. Validation and verification have different goals. Approaches used for validation and
verification may be similar.
C – Incorrect. V&V can be done before specification – on single requirements or business concepts
too. Recommended practice is: “The best practice is to plan and perform validation and verification of
requirements from the early phases of solution development – ideally from the requirements
elicitation”, IQBBA syllabus, section 4.1.5
D – Incorrect. Validation and verification involves relevant stakeholders, not all of them.
Question 4.11 – answer B
Justification
B – Correct. This statement refers to decomposition or requirements analysis rather than IA.
A, C and D – Incorrect. All these statement refers to the purpose of IA, as explained in the IQBBA
syllabus, section 4.2.2.
Question 4.12 – answer A
Justification
A – Correct. Business need is covered by Requirement 3 and 4. Requirement 3 is covered by three
test cases (4, 5, and 6), Requirement 4 is covered by Test case 5. Therefore 3 test cases should be
analyzed.
B, C and D – Incorrect. See A.
Question 4.13 – answer C
Justification
C – Correct, as explained in the IQBBA syllabus, section 4.2.5.
A – Incorrect. The statement itself it true, but it does not answer the question (objective of
configuration management)
B – Incorrect. This statement refers to traceability.
D – Incorrect. CM does not focus only on version management. In addition, versions should be
managed during the whole lifecycle.
Question 4.14 – answer D
Justification
D – Correct. Feasibility study is used to evaluate feasibility of a solution proposal, it is not a typical QA
mean.
A, B and C – Incorrect. All the mentioned methods support QA for Business Analysis, as explained in
the IQBBA syllabus, section 4.2.7.
Question 4.15 – answer B
Justification
B – Correct. This is a definition of QA, explaining the idea behind QA and goals of this discipline, as
explained in the IQBBA syllabus, section 4.2.7.
Terms
Evaluation, Optimization
5.1 Evaluation
Solution Evaluation covers a set of activities that are performed in order to ensure that the capabilities
provided by the solution proposalfulfill the stated Business Need(s), and satisfy business, stakeholder
and solution requirements.
Solution Evaluation is typically based on agreed requirements. During evaluation, the solution
proposal is examined against compliance with the requirements and the Business Case. It is
necessary to consider both business and technical assumptions and constraints as well, as they may
determine the choice of solution. Solution Evaluation may result in discovering additional capabilities
provided by the solution that had not been previously considered.
In the case of evaluating a released (operating) solution, the main focus is on checking if the solution
successfully satisfies the Business Needs and Goals described in the Business Case (as defined
during Strategy Analysis). In case of defects, weaknesses or an identified need for new capabilities,
the Business Analyst should determine the most appropriate response to the identified problems and
opportunities for solution or process improvement.
5.2 Optimization
Optimization aims to introduce controlled change into the current solution or process in order to add
value. Optimization may reduce the cost of operation, improve quality, allow alignment with other
solutions, etc.
Optimization – the process of identification of an alternative with the most cost effective or highest
achievable performance, under the given constraints, by maximizing desired factors and minimizing
undesired ones.
Supporting optimization efforts is one of the tasks of a Business Analyst. The Business Analyst
analyzes solutions and business processes used within an organization in order to discover ineffective
elements and areas for improvement. With this knowledge, the Business Analyst is able to refine the
solution and improve it by adding more value.
Common approaches to optimization include:
• Manual re-design of the solution or processes on the basis of experience and domain
knowledge
• Re-design of the solution or processes based on Solution Evaluation activities
• Introducing means for optimizing performance of solutions or business processes in the
organization (e.g., SAP, ERP, CRM software)
• BPR (Business Process Reingineering)
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. Optimization of business
processes can be supported by methods such as Business Process Improvement (BPI). BPI is a
systematic approach used to optimize an organization’s processes to achieve more efficient results
and significantly change the performance of an organization [Harrington].
BPI is conducted in three steps [Harrington]:
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
BPI Phases
Phase 1. Organizing for improvement
Objective To ensure success by building leadership, understanding and
commitment
Activities • Establishing Efficiency Improvement Tool
• Appointing a BPI champion
• Providing executive training
• Developing an improvement model
• Communicating goals to employees
• Reviewing business strategy and customer requirements
• Selecting the critical processes
• Appointing process owners
• Selecting team members
Phase 3. Streamlining
Objective To improve the efficiency, effectiveness and adaptability of the
business process
Activities • Providing team training
• Identifying improvement opportunities (errors and rework,
poor quality, high cost, delays)
• Eliminating bureaucracy
• Eliminating no-value-added activities
• Simplifying the process
• Reducing process time
Optimization efforts can be also supported by following specific methodologies or strategies, including:
• ISO 9000 or other standards aiming to improve performance of an organization
• Capability Maturity Model Integration/Capability Maturity Model (CMMI/CMM)
• Benchmarking
• Total Quality Management (TQM)
• Six Sigma
Typical results of optimization work are suggestions for improvements, new requirements and/or
modifications to existing requirements or solutions.
Questions
Recall the definition of solution optimization
Explain the purpose, activities, methods and results of solution optimization
Provide examples of common approaches to optimization
Provide examples of methodologies or strategies supporting optimization
6. References
[Bens] Bens, Ingrid, Facilitation at a Glance! 4th Edition, Goal/QPC; 4th edition, 2016, ISBN-10:
1576811832
[BABOK] International Institute of Business Analysis, A Guide to the Business Analysis Body of
Knowledge, Version 2.0 and 3.0
[Brown] Brown Tim, Change by Design: How Design Thinking Transforms Organizations and
Inspires Innovation, HarperCollins, 2009, ISBN 978-0061766084
[Carlson, Wilmot] Carlson C.C., Wilmot, W.W., Innovation: The five disciplines for creating what
customers want, New York: Crown Business, 2006, ISBN: 0307336697
[Hass] Hass Kathleen and Associates, Project Management and Business Analysis Maturity
Assessments, http://www.kathleenhass.com/Whitepapers-
docs/BA%20and%20PM%20Assessments.pdf, retrieved 01.08.
[Harrington] Harrington H. James, Business Process Improvement: The Breakthrough Strategy for
Total Quality, Productivity, and Competitiveness , 1991
[IIBA Competency] IIBA® Business Analysis Competency Model Version 3.0, 2011, http://iiba.ru/wp-
content/uploads/2013/04/IIBA_Competency_Model_v3_Final.pdf, retrieved 01.08.2017
[IQBBA Glossary] Standard glossary of terms used in Software Engineering Version 2.0
[Pinheiro F.A.C. and Goguen J.A] F.A.C. Pinheiro and J.A. Goguen, An object-oriented tool for tracing
requirements, in: IEEE Software 1996, 13(2), pp. 52-64
[PRINCE2] Axelos, Managing Successful Projects with PRINCE2® 2017 Edition, Axelos, 2017 ISBN:
9780113315338
[Rosenfeld, Morville] Morville, Peter and Rosenfeld, Louis, Information Architecture for the World Wide
Web: Designing Large-Scale Web Sites, O'Reilly Media; 3rd edition, 2006, ISBN: 0596527349
[Rubin] Rubin K., Essential Scrum: A Practical Guide to the Most Popular Agile Process, Addison-
Wesley Professional; 1 edition (August 5, 2012)
[SparxEA]
https://sparxsystems.com/enterprise_architect_user_guide/14.0/guidebooks/tech_stakeholder_list_ma
p_or_personas.html, retireved 10.09.2019
[Web Style Guide] LynchPatrick J., Horton Sarah, Web Style Guide 3rd Edition,
http://webstyleguide.com/wsg3/3-information-architecture/index.html, retrieved 01.08.2017
[Wiegers, Beatty] ]Wiegers, Karl E., Beatty, Joy, Software Requirements (3rd Edition), Microsoft Press;
3 edition, 2013, ISBN-10: 0735679665
5.6 Standards
[CMMI] Capability Maturity Model Integration
https://cmmiinstitute.com/resources?searchtext=ResourceType:%22model%22
[IEEE 610] IEEE 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
[ISO/IEC/IEEE 29148] ISO/IEC/IEEE 29148:2011 Systems and software engineering -- Life cycle
processes -- Requirements engineering
[ISO 9241-210] ISO 9241-210:2010 Ergonomics of human-system interaction — Part 210: Human-
centred design for interactive systems
[ISO 9000] ISO 9000 Quality management:
• ISO 9000:2015 Quality management systems. Fundamentals and vocabulary
• ISO 9001:2015 Quality management systems. Requirements
• ISO/IEC 90003 – Software engineering
[ISO 31000] ISO 31000 Risk Management - Principles and Guidelines on Implementation
7. Figures
Figure 1 Overview on Business Analysis areas ...................................................................................... 8
Figure 2 Business Analysis and Requirements Engineering .................................................................. 9
Figure 3 Levels of requirements ............................................................................................................ 10
Figure 4 Alternative roles for a Business Analyst .................................................................................. 12
Figure 5 The role of a Business Analyst ................................................................................................ 13
Figure 6 Business Analysis areas ......................................................................................................... 15
Figure 7 Sample stakeholders map with communication direction {SparxEA]...................................... 16
Figure 8 Sample Business Analysis skills ............................................................................................. 17
Figure 9 Business Analysis roles (IIBA Competency Model V3) .......................................................... 19
Figure 10 Vision, Mission and Business Goal ....................................................................................... 23
Figure 11 Eriksson-Penker notation ...................................................................................................... 24
Figure 12 SIPOC method for business process description ................................................................. 25
Figure 13 Basic elements of BPMN notation ........................................................................................ 25
Figure 14 Sample BPMN model [Mleczko]............................................................................................ 26
Figure 15 Top down analysis of Business Goal .................................................................................... 27
Figure 16 Bottom up analysis of the current („AS-IS”) state ................................................................. 27
Figure 17 The concept of a capability gap ............................................................................................ 28
Figure 18 Sample Gap Analysis [EPM] ................................................................................................. 29
Figure 19 Sample innovation process ................................................................................................... 30
Figure 20 Market Research and Analysis ............................................................................................. 31
Figure 21 User Needs Identification (source: https://insightpd.com/condensed_poster-2/) ................. 32
Figure 22 Examples of Generic Stakeholders [BABOK] ....................................................................... 33
Figure 23 Stakeholders Power-Interest Matrix ...................................................................................... 34
Figure 24 Sample Power-Interest Matrix ............................................................................................... 34
Figure 25 Product Vision [Pichler] ......................................................................................................... 36
Figure 26 Sample Product Vision [Pichler] ............................................................................................ 36
Figure 27 Elements of a Business Case ............................................................................................... 37
Figure 28 Sample structure of a Business Case ................................................................................... 38
Figure 29 Sample Business Case (https://expertprogrammanagement.com/2017/06/project-business-
case/) ..................................................................................................................................................... 39
Figure 30 Elements of PID .................................................................................................................... 40
Figure 31 Sample maturity model [Haas] .............................................................................................. 45
Figure 32 Waterfall model ..................................................................................................................... 46
Figure 33 V model ................................................................................................................................. 46
Figure 34 Scrum framework [Rubin] ...................................................................................................... 47
8. Tables
Table 1 Examples of requirements ........................................................................................................ 11
Table 2 Consequences of neglecting Business Analysis ...................................................................... 14
Table 3 Sample Business Analysis products ........................................................................................ 16
Table 4 Examples of Vision, Mission and Goals ................................................................................... 22
Table 5 Sample configuration of a requirement .................................................................................. 111
Table 6 Sample Change Request ....................................................................................................... 114
Table 7 BPI Phases [Harrington] ......................................................................................................... 136