Business Analysis basics - Based on BABOK V3.0

@AMoSolo
(Dr. Biz)
By Ali.Morshedsoluk/Aug. 2019

@AMoSolo
It’s not Digital, It’s Business
learn
unlearn relearn
BABOK 3.0 Review (Ch1&2) 2

@AMoSolo
Course Agenda
•2 DaysBABOK Guide V3.0, Basics
•2 DaysCore Competencies & Techniques
•1 DaysVideos and Workshop
•1 DayBehavioral and Cognitive Biases
•1 DayThe Art of Leadership

@AMoSolo
Course Purpose
Having a Common Language
To Fill the knowledge Gap
To Increase Skills and Competencies
To Identify (our) weakness and leap Points
To Challenge ourselves relentlessly (?)
Knowing How to be (Acting as) a Professional
Knowing the World BA Experts Standards

@AMoSolo
BA Basics- outlines
What is Diagnosis?
BABOK Guide V3.0 – An introduction
BA Core Concept Model
BA Key Concepts
BA Knowledge Areas
Requirements LC
Videos, Workshop, Quiz

@AMoSolo
What do you do when you have an illness?
You need to go to a Doctor’s Office!

@AMoSolo
What is Diagnosis ?
• Let's look at a possible scenario that may have happened to you at some point in time.
• You wake up one morning realizing that you don't quite feel like yourself. This feeling persists and gets worse as the
day goes on. By late afternoon, you have decided that you feel bad enough that you want to go see your doctor to
find out what is wrong.
• At the doctor's office, you are asked what is wrong. You tell the doctor that you woke up feeling nauseous with a
bad stomach ache. As the day went on, the aching got worse and you began vomiting. By the afternoon, you then
felt very weak and had diarrhea. The doctor now examines you and decides to run some tests. The doctor gets the
results back and realizes that you have a virus causing the signs and symptoms in your body. The doctor tells you
that you have the stomach flu. What the doctor just gave you was the diagnosis.
• A diagnosis tells the illness or other condition that is affecting the body based on the signs and symptoms.
Diagnoses can only be obtained after you tell the doctor the symptoms, which are the sensations that you feel,
and the doctor examines for the signs, which are the changes in the body that can be detected or measured. Based
on the knowledge that they obtained in medical school, the doctors will then determine the most likely cause of
the syndrome that you are experiencing. The syndrome is the collection of the signs and symptoms that are usually
experienced by a person with a given disease, disorder, or condition. The syndromes have names which we
commonly refer to as the disease, condition, or disorder. In the scenario above, the stomach flu is the disease in
the diagnosis.

@AMoSolo
Doctor Duties & Responsibilities
• Assess symptoms (E&C)
• Diagnose conditions (E&C, RADD)
• Prescribe and administer treatment (SA/RADD/SE)
• Provide follow-up care of patients, refer them to other providers, and
interpret their laboratory results (RLCM/SE)
• Collaborate with physician assistants, nurse practitioners, registered
nurses, and other health professionals (E&C)
• Prescribe medication (RADD)
• Stay current on medical technology and research (competency/Tools
& Techs)

@AMoSolo
Doctor Skills & Competencies
In addition to graduation from medical school and licensure, doctors also
need specific soft skills to succeed in this occupation. These are abilities with
which one is either born or acquired through life experience. Among them
are:
• Problem Solving: After evaluating a patient's symptoms and making a diagnosis,
doctors have to choose an appropriate treatment. To do this, they will need critical
thinking skills to compare available options.
• Communication Skills: Excellent listening skills allow physicians to understand their
patients' symptoms and concerns. They need superior verbal communication skills to
explain diagnoses to patients and their families and convey instructions and information
about treatment to nurses and others on staff.
• Service Orientation: A doctor must want to help people. While there are some paths
available in this field that do not involve working with patients directly, most research is
driven by a desire to help people.
• Monitoring: Doctors need to be attentive to changes in patients' conditions and
respond to them appropriately. This can include anything from long-term changes
in regular patients to short-term changes in patients recovering from a specific
procedure or illness.

@AMoSolo
Some Notes
• Illness, condition or disorder:
• can be simple, complex, or unidentified
• can be in minor organs or in major organs or in multi-organs or nerve system or mind based
• can propagate like a virus to other peoples/can spread over body
• can be Geographically based/Time based/patient’s Age or Sex based (context)
• Can be transient or persistent or chronic (decease progression can have different stages)
• can be treated in a few minutes to a few years, or even may be not treatable just tolerated!
• Can be a not-optimized condition in any organ or whole body
• Doctor’s skill level: Assistant, Basic, professional or expert (competency)
• Treatment: different types like Modern, Traditional or Hybrid/from simple medication to
complex surgery, radiotherapy, logotherapy, XX-therapies,… according to decease stage
(Perspective & Context)
• Illness treatments: takes time, needs costs and other resources, does hurt the patient,
has fear and worry, needs rest & recovery, consist of multiple tasks, needs training,
needs organ change (RLCM, SA, RADD, SE)
• Symptoms and signs: can be common to several illnesses, science still is not complete
• Diagnose needs a detailed root cause analysis (RCA)

@AMoSolo

@AMoSolo
Success or Failure in Diagnose or treatment
• Doctors: may do wrong prescriptions (why?/How?)
• Assistants: may do wrong practice (why?)
• Patients: may do not follow the treatments (why?)
• Patients: may misguide Doctors (How?)
• Illness easily can gets worse and worse, while a simple care was the correct
treat! (Real cases: Toll in nose/Parking remote)
• Not cared or cured or treated Illness: simply can spread over or can cause
to more severe illness or even can bring death!
• Symptoms and signs: can be common to several illnesses, science still is not
complete
Q1: Blood Pressure is an illness or a Sign or a Cause?
Q2: Treats usually Control the Symptom or Cure the Cause?

@AMoSolo
Symptoms
are just the
tip of the
iceberg
Root causes
at the
deepest
level should
be Treated

@AMoSolo
How do you Model patient activities?
‫احساس‬
‫مشکل‬
‫به‬ ‫تصمیم‬
‫درمان‬
‫پذیرش‬
‫معاینه‬
‫انجام‬
‫آزمایشها‬
‫انجام‬
‫تجویزپزشک‬
‫بازخورد‬
‫معالجه‬
Q: How do you Model Doctor activities?BABOK 3.0 Review (Ch1&2) 14

@AMoSolo
A derived Model for a Physician (7‫)ت‬
‫تصمیم‬
‫تحقیق‬
‫تعمیق‬
‫تشخیص‬
‫تجویز‬
‫ترمیم‬
‫تنظیم‬
‫تعهد‬
‫شایستگ‬‫ی‬
‫مهارت‬
‫اخالق‬
‫مسولیت‬
‫پذیر‬

@AMoSolo
Business Analysis
BABOK 3.0 Guide - Basics

@AMoSolo
What about business?
• Business system, like any other system, is similar to human body system
• Complexity of a system, with n number of items interacting, is n^2 (O(n)=n^2),
• Illness in Biz. Can be a disorder, a condition, a failed objective, a wrong goal, a bad strategy, a bad
management, a weak organization, hidden company, a loss of resources, an inefficient process,…
with the symptoms and signs specific to each one
• BA (business analysts) and SA (Solution Architects) can help managers and staff to
do diagnosis and prescribe the treatment
Business analysis is the practice of
enabling change in an enterprise by
defining needs and
recommending solutions that
deliver value to stakeholders
• A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) contains a
description of generally accepted practices in the field of business analysis.
• BABOK is a set of tasks recommended by BAs all around the world and initiated
by a BA to do diagnosis of business based on symptoms and signs and objectives
of the business specified by biz. Stakeholders. (iiba.org)

@AMoSolo
BOK
• PMBOK (Project Mgmt)
• DMBOK (Data Mgmt)
• EABOK (Enterprise Architecture)
• SW BOK (Software)
• BPMBOK (Biz. Process Mgmt)
• BPRBOK
• SEBOK (Solution Engineering)
• SEBOK (system Engineering)
• BABOK (Biz. Analysis)
• Chain
• Manager -> BA -> SE -> PM -> Staff
• Can be a single person
• PBA
• Telecom: eTOM
• IT: ITIL
• Health: HMS
• Logistics: SCOR
• Insurance: ACCORD
• Banking: BIAN
• EA: DODAF/TOGAF/FEAF
• Governance: COBIT
• Best Practices
Industry De Facto Standards

@AMoSolo
BABOK® Guide
• Core product for IIBA®—serves as basis for all IIBA related services including
certification and competency model.
• Globally recognized standard for practice of business analysis: (best practices)
• Development began in 2004
• First Major Release was v1.6 in 2006
• Updated to v2.0 in 2009
• V3.0 was published in 2015
• BABOK Provides a framework for structuring business analysis activities.
• Collective wisdom of many Business Analysis professionals, from all around the
world.
• BABOK® Guide version 3 was developed by a core team of over 150 writers and researchers
from 20 countries. It was reviewed by over 1000 business analysis experts as well as 60 global
thought leaders from all areas of business practice. Over 5500 insights and comments were
received from global business analysis communities.
• The BABOK® Guide describes business analysis knowledge areas, tasks,
underlying competencies, techniques and perspectives on how to approach
business analysis.
• BABoK provides guidelines, it is not a process description

@AMoSolo
Purpose of the BABOK® Guide
Business Analyst in
BABOK Guide
Define BA profession, common
practices
Define skills necessary to perform
BA work
Provide others with understanding
of skills and knowledge they can
expect of a skilled BA

@AMoSolo
What is Business Analysis?
• Business analysis enables an enterprise to articulate needs and the
rationale for change, and to design and describe solutions that can deliver
value.
• Business analysis is performed on a variety of initiatives within an
enterprise. Initiatives may be strategic, tactical, or operational.
• Business analysis may be performed within the boundaries of a project or
throughout enterprise evolution and continuous improvement.
• It can be used to understand the current state, to define the future state,
and to determine the activities required to move from the current to the
future state.
• Business analysis can be performed from a diverse array of perspectives:
agile, business intelligence, information technology, business architecture,
and business process management.
• A perspective can be thought of as a lens through which the business
analysis practitioner views their work activities based on the current
context. One or many perspectives may apply to an initiative.

@AMoSolo
How can BABoK be applied?
BABoK and its Business Analysis
Core Concept Model help
developing a common language
for people from different
corners of the organization who
are involved in Business Analysis
tasks.
Speaking one common language
can help resolving conflicts that
mainly occur due to its
understanding and breakdown
of communication.
By participation and
collaboration during common
language development
individuals gain shared
understanding of Business
Analysis tasks and how they
shall be executed in a given
context.
Shared understanding is about
knowing the rules how to play
the BA game.

@AMoSolo
How can BABoK be applied?

@AMoSolo
Who is a Business Analyst?
• A business analyst is any person who performs business analysis tasks
described in the BABOK® Guide, no matter their job title or
organizational role.
• Business analysts are responsible for discovering, synthesizing, and
analyzing information from a variety of sources within an enterprise,
including tools, processes, documentation, and stakeholders.
• The business analyst is responsible for eliciting the actual needs of
stakeholders—which frequently involves investigating and clarifying
their expressed desires—in order to determine underlying issues and
causes.
• Business analysts play a role in aligning the designed and delivered
solutions with the needs of stakeholders.

@AMoSolo
The main activities BAs perform are

@AMoSolo
Who is a Business Analyst?
Other common job titles for people who perform business analysis
include:
• business architect,
• business systems analyst,
• data analyst,
• enterprise analyst,
• management consultant,
• process analyst,
• product manager,
• product owner,
• requirements engineer, and
• systems analyst.

@AMoSolo
BA Role Overlaps Many other Roles
•‫کار‬ ‫و‬ ‫کسب‬ ‫تحلیلگر‬
•‫کیفیت‬ ‫تضمین‬
•‫سیستمها‬ ‫و‬ ‫روشها‬
•‫مدیریت‬ ‫مشاور‬
•‫سازمانی‬ ‫معماری‬
•‫سازمانی‬ ‫تعالی‬
•‫تحول‬ ‫مدیریت‬

@AMoSolo
Business Analysis is a Team Sport

@AMoSolo
BA Certificates

@AMoSolo
Business Analysis Careers
Business analysis job profiles can be organized into:
Generalists, Specialists or Hybrids

@AMoSolo
Question

@AMoSolo
Moral: long term achievements is like eating an elephant

@AMoSolo
BABOK V3.0 Guide Summary
Elements
Underlying Competencies in 6 Group
Perspectives
Tasks
Knowledge area
Techniques
Pages
5
29
5
30
6
50
514

@AMoSolo
BA and BABOK 3.0 Framework

@AMoSolo
BABOK V3.0 Guide – Summary Numbers
5 Key Elements/5 BA Key Concepts
29 Core Competencies in 6 Group
5 Perspectives
30 Tasks
6 Knowledge Areas
50 Techniques
514 Pages

@AMoSolo

@AMoSolo
Structure of the BABOK® Guide
• Knowledge areas are a collection of logically (but not sequentially) related
tasks.
• Business Analysis Key Concepts: define the key terms needed to
understand all other content, concepts, and ideas.
• Underlying Competencies: provide a description of the behaviours,
characteristics, knowledge, and personal qualities that support the
effective practice of business analysis.
• Techniques: provide a means to perform business analysis tasks. covers the
most common and widespread techniques practiced within the business
analysis community.
• Perspectives: describe various views of business analysis. Perspectives help
business analysts working from various points of view to better perform
business analysis tasks, given the context of the initiative.

@AMoSolo
Key Concepts
• The Business Analysis Key Concepts chapter provides a basic
understanding of the central ideas necessary for understanding the
BABOK® Guide.
• Key Concepts consists of:
 Business Analysis Core Concept Model™ (BACCM™)
 Key Terms
 Requirements Classification Schema
 Stakeholders
 Requirements and Design
• Let’s start with BACCM with 6 Core Concepts

@AMoSolo
BACCM

@AMoSolo
BACCM
• Business Analysis Core concepts
Model (BACCM) is the core
framework integral to BABOK
Guide v3.0
• Core concepts are fundamental to
the practice of business analysis as
defined in BABOK guide.
• is a set of 6 concepts which define
the business analysis practice
• All Core concepts are equal and
necessary
• Each core concept is defined by
the other five core concepts and
cannot be fully understood until
all the concepts are understood.
• No single concept holds greater
importance or significance over
any other concept.
• These concepts are instrumental
to understanding the type of
information elicited, analyzed, or
managed in business analysis
tasks.

@AMoSolo
BACCM
The BACCM can be used to:
• describe the profession and domain of
business analysis
• communicate about business analysis with a
common terminology
• evaluate the relationships of key concepts in
business analysis
• perform better business analysis by holistically
evaluating the relationships among these six
concepts,
• evaluate the impact of these concepts and
relationships at any point during a work effort
in order to establish both a foundation and a
path forward
While planning or performing a task or technique,
business analysts can consider how each core concept is
addressed by asking questions such as:
• What are the kind of changes we are doing?
• What are the needs that we are trying to satisfy?
• What are the solutions that we are creating or changing?
• Who are the stakeholders involved?
• What do stakeholders consider of value?
• What are the contexts that we and the solution are in?

@AMoSolo
Need
Need core concept is defined
by BABOK as:
• A problem, opportunity
or constraint with
potential value to a
stakeholder (s)
• Need can be thought of
as the reason which
starts a project.
• An organization needs a
solution to address a
business problem.
•

@AMoSolo
Solution
Core concept Solution
The BABOK guide refers to this
core concept as:
• A specific way of satisfying
one or more needs in a
context.
• Organizational needs can
only be satisfied or
addressed through a
solution.
• A solution to address the
need can be specific to an
organization as different
organizations or situations
may need different solutions.
•

@AMoSolo
Change
Core Concept Change
IIBA BABOK refers to the this core
concept as
• The act of transformation in
response to a need.
• Once the organization
recognizes it’s need, a
change has to take place in
the organization to address
the need.
• The need is addressed
through a specific solution,
as discussed in the solution
core concept.
•

@AMoSolo
Context
Core Concept Context
Context refers to
• specific background, budget,
timelines, organizational structure,
that may influence the solution
implementation.
• Context may decide the specific
solution to be appropriate for an
organization.
• Example: Extending the CRM
example in the solution section. If
Software as a service (SaaS) CRM
system is suitable for Organization
A, it is possible that a customized
software is more suitable for
Organization B.
• There can be very specialized
business processes for
organization B as compared to the
almost standard business
processes in organization A.
•

@AMoSolo
Value
Core Concept Value
IIBA BABOK refers to “Value” as:
• The worth, importance, or
usefulness of something to a
stakeholder within a context.
• An organization has a need as
it foresees business value by
addressing the need.
• The business value is an
anticipated outcome of
implementing a solution.
• Example By implementing a
CRM solution, a business can
look forward to increase its
revenue or to improve
customer service standards.
This is what is meant by
“Value”.
•

@AMoSolo
Stakeholder
Core Concept Stakeholder
Who is a stakeholder?
• A group or individual with a
relationship to the change, the
need, or the solution.
• A stakeholder is an individual or
group who can influence the
project or can get influenced by
the project as a user.
• The stakeholders can be from the
customer organization, the
solution provider or an external
organization.
• BABOK guide has proposed
specific categories of stakeholders
but does not limit them to only
these categories.
•

@AMoSolo
Stakeholder
The stakeholder’s
categories as per BABOK
are:
• business analyst
• customer
• domain subject matter
expert
• end user
• implementation
subject matter expert
• operational support
• project manager
• regulator
• sponsor
• Supplier
• tester

@AMoSolo
A BACCM example
• The wave of digitization is transforming many traditional industries. A traditional retail business that operated brick and mortar stores for
years must now compete with e-commerce companies that provide the same goods to customers but with additional benefits such as
convenience (shop from home), wide range of products and attractive discounts (due to the lower cost business models of e-commerce
players). In order to respond to this change in market dynamics, a business analysis task can be performed at a traditional brick and mortar
retail store using the BACCM. Here is how the six core concepts may be analyzed in this example:
1) Change: Provide e-commerce solutions to customers who prefer shopping online. This will require completely new business processes and
functions to fulfil online orders.
2) Need: Rising popularity and market share of e-commerce competitors who directly compete in the marketplace with the company, to
attract a growing share of customers, transactions and volume of goods sold.
3) Solution: Depending upon the company’s organizational structure, capabilities and time-sensitive nature of the change, the probable (but
not exhaustive) list of solutions could be to implement an IT project that enables the organization to set up its own e-commerce store, partner
with existing e-commerce players to use their infrastructure for order fulfilment or acquire an existing e-commerce player and merge it with
the company’s existing operations.
4) Stakeholder: The stakeholders, in this case, are almost from all functional areas sales, marketing, IT, HR and Operations within the
organization.
5) Value: The tangible value, in this case, can be increase in sales and increase (or maintaining) the company’s market share. The intangible
value can include transforming the organization to a digital future, introduction of new talent and ideas.
6) Context: The context for this proposed change can be the growing market share and popularity of e-commerce players, changing
demographic profile of the customers, improvements in the digital infrastructure in the country, entry of foreign players in the market and
easier government regulations towards setting up of e-commerce companies.

@AMoSolo
Let’s practice your first BA exercise
Considering BACCM write a few examples in your
enterprise or organization or department and show
the core concepts relation in each example
1. What information you need to finish this
exercise?
2. What steps you realized you need to do
this example? Name them.
3. What skills you realized you need to have
to finish this exercise?
4. Which core concept you think you are
master in? which you are weak in?
5. What do you think you can add to this
model?
6. What are the kind of changes you are
doing?
7. What are the needs that you are trying to
satisfy?
8. What are the solutions that you are
creating or changing?
9. Who are the stakeholders involved?
10. What do stakeholders consider of value?
11. What are the contexts that you and the
solution are in?

@AMoSolo
Business
Analysis
Core
Concept
Model
(BACCM)
Relation
Diagram

@AMoSolo
Questions?
amorshed@icasat.net
Or Telegram Me
+989123443383

@AMoSolo
Key Concepts
BABOK® Guide.
• Business Analysis Core Concept Model™ (BACCM™)
• Key Terms
• Requirements Classification Schema
• Stakeholders
• Requirements and Design

@AMoSolo
Business Analysis The practice of enabling change in an enterprise by defining needs and recommending
solutions that deliver value to stakeholders
BA Information Broad and diverse set of information at any level of detail which are analysed, transformed and
reported by BAs. Eg: elicitation results, requirements, solution options etc.
Design A usable representation of a solution which focuses on understanding how the value might be
realized by a solution if it is built. Generally represented by means of (a set of ) documents
Enterprise A system of one or more organizations and the solutions (=organizational capabilities which can
be processes, tools or information) they use to pursue a shared set of common goals
Organization An autonomous group of people which work towards achieving common goals and objectives.
It is under the management of a single individual or board. often have a clearly defined
boundary and operate on a continuous basis, as opposed to an initiative or project team
Plan Proposal for doing or achieving something. Plans describe a set of events, the dependencies
among the events, the expected sequence, the schedule, the results or outcomes, the
materials and resources needed, and the stakeholders involved.
Requirement Usable representation of a need. Requirements focus on understanding what kind of value
could be delivered if a requirement is fulfilled. Generally represented by means of documents
Risk Effect of uncertainty on the value of a change, solution or enterprise. BAs identify, prioritize
and mitigate risks by collaborating with stakeholders.
Business analysis key terms

@AMoSolo
Key Concepts
BABOK® Guide.
• Key Terms
• Stakeholders

@AMoSolo
Requirements Classification Schema
• Business requirements: statements of goals, objectives, and outcomes that describe why a
change has been initiated. They can apply to the whole of an enterprise, a business area, or a
specific initiative.
• Stakeholder requirements: describe the needs of stakeholders that must be met in order to
achieve the business requirements. They may serve as a bridge between business and
solution requirements.
• Solution requirements: describe the capabilities and qualities of a solution that meets the
stakeholder requirements. They provide the appropriate level of detail to allow for the
development and implementation of the solution. Solution requirements can be divided into
two sub-categories:
• functional requirements: describe the capabilities that a solution must have in terms of the behaviour
and information that the solution will manage, and
• non-functional requirements or quality of service requirements: do not relate directly to the behaviour
of functionality of the solution, but rather describe conditions under which a solution must remain
effective or qualities that a solution must have.
• Transition requirements: describe the capabilities that the solution must have and the
conditions the solution must meet to facilitate transition from the current state to the future
state, but which are not needed once the change is complete. They are differentiated from
other requirements types because they are of a temporary nature. Transition requirements
address topics such as data conversion, training, and business continuity.

@AMoSolo
Requirements Classification Schema

@AMoSolo
NON FUNCTIONAL REQUIREMENTS
• The purpose of non-functional requirements is to describe the required
qualities of a system, such as its usability and performance characteristics.
These supplement the documentation of functional requirements, which
describe the behavior of the system.

@AMoSolo
Workshop
• Define a business requirement in your SBU
• Identify the stakeholders of that requirement
• Identify the stakeholder requirements
• Design the best solution
• Identify the solution requirements
• Identify the functional requirements
• Identify the non-functional requirements
• Identify the transition requirements
• How do you assess the solution?
• How do you be confident the solution meets the requirement?

@AMoSolo
BABOk 3.0 Knowledge Areas (Ch3 to 8) 60

@AMoSolo
Key Concepts
BABOK® Guide.
• Key Terms
• Stakeholders

@AMoSolo
Stakeholders
• A stakeholder is an individual or group that a business analyst is likely to
interact with directly or indirectly.
• Any stakeholder can be a source of requirements, assumptions, or
constraints.
• The generic list of stakeholders includes the following roles:
• business analyst
• customer
• domain subject matter expert (SME)
• end user
• implementation subject matter expert
• operational support
• project manager
• regulator
• sponsor
• supplier
• tester
• EDIC SPORT

@AMoSolo
Stakeholders
• Business Analyst
• The business analyst is inherently a stakeholder in all business analysis activities. The
BABOK Guide presumes that the business analyst is responsible and accountable for
the execution of these activities. In some cases the business analyst may also be
responsible for performing activities that fall under another stakeholder role.
• Customer
• A customer uses or may use products or services produced by the enterprise and
may have contractual or moral rights that the enterprise is obliged to meet.
• Domain Subject Matter Expert
• A domain subject matter expert is any individual with in-depth knowledge of a topic
relevant to the business need or solution scope. This role is often filled by people
who may be end users or people who have in-depth knowledge of the solution such
as managers, process owners, legal staff, consultants, and others.
• End User
• End users are stakeholders who directly interact with the solution. End users can
include all participants in a business process, or who use the product or solution.

@AMoSolo
Stakeholders
• Implementation Subject Matter Expert
• An implementation subject matter expert is any stakeholder who has specialized knowledge
regarding the implementation of one or more solution components.
• While it is not possible to define a listing of implementation subject matter expert roles that are
appropriate for all initiatives, some of the most common roles are: project librarian, change
manager, configuration manager, solution architect, developer, database administrator,
information architect, usability analyst, trainer, and organizational change consultant.
• Operational Support
• Operational support is responsible for the day-to-day management and maintenance of a system
or product.
• While it is not possible to define a listing of operational support roles that are appropriate for all
initiatives, some of the most common roles are: operations analyst, product analyst, help desk,
and release manager.
• Project Manager
• Project managers are responsible for managing the work required to deliver a solution that meets
a business need, and for ensuring that the project's objectives are met while balancing the project
factors including scope, budget, schedule, resources, quality, and risk.
• While it is not possible to completely define a listing of project management roles that are
appropriate for all initiatives, some of the most common roles are: project lead, technical lead,
product manager, and team leader.

@AMoSolo
Stakeholders
• Regulator
• Regulators are responsible for the definition and enforcement of standards. Standards can be
imposed on the solution by regulators through legislation, corporate governance standards,
audit standards, or standards defined by organizational centers of competency. Alternate
roles are government, regulatory bodies, and auditor.
• Sponsor
• Sponsors are responsible for initiating the effort to define a business need and develop a
solution that meets that need. They authorize the work to be performed, and control the
budget and scope for the initiative. Alternate roles are executive and project sponsor.
• Supplier
• A supplier is a stakeholder outside the boundary of a given organization or organizational
unit. Suppliers provide products or services to the organization and may have contractual or
moral rights and obligations that must be considered. Alternate roles are providers, vendors,
and consultants.
• Tester
• Testers are responsible for determining how to verify that the solution meets the
requirements defined by the business analyst, as well as conducting the verification process.
Testers also seek to ensure that the solution meets applicable quality standards, and that the
risk of defects or failures is understood and minimized. An alternate role is quality assurance
analyst.

@AMoSolo
Stakeholders RASCI Diagram

@AMoSolo
Key Concepts
BABOK® Guide.
• Key Terms
• Stakeholders

@AMoSolo
Requirements and Designs
• Eliciting, analyzing, validating, and managing requirements have consistently been recognized as key activities of
business analysis.
• However, it is important to recognize that business analysts are also responsible for the definition of design, at some
level, in an initiative. The level of responsibility for design varies based on the perspective within which a business
analyst is working.
• Requirements are focused on the need; designs are focused on the solution.
• The distinction between requirements and designs is not always clear.
• The same techniques are used to elicit, model, and analyze both. A requirement leads to a design which in turn may
drive the discovery and analysis of more requirements. The shift in focus is often subtle.
•
• The classification as a requirement or a design may become less significant as the business analyst's work progresses
to a greater understanding of and eventual fulfillment of the need. The tasks in the BABOK® Guide such as Trace
Requirements or Specify and Model Requirements may refer to requirements, but the intent is to include designs as
well.
•
• Business analysis can be complex and recursive. A requirement (or set of requirements) may be used to define a
design. That design may then be used to elicit additional requirements that are used to define more detailed designs.
• The business analyst may hand off requirements and designs to other stakeholders who may further elaborate on the
designs. Whether it is the business analyst or some other role that completes the designs, the business analyst often
reviews the final designs to ensure that they align with the requirements.

@AMoSolo
Requirements and Designs
Requirement Design
View six months sales data across multiple
organizational units in a single view.
A sketch of a dashboard.
Reduce amount of time required to pick and
pack a customer order.
Process model.
Record and access a medical patient’s
history.
Screen mock-up showing
specific data fields.
Develop business strategy, goals, and
objectives for a new business.
Business Capability Model.
Provide information in English and Farsi.
Prototype with text displayed in
English and Farsi.

@AMoSolo
Requirements and Designs Cycle
• Stakeholders may present a need or a
solution to an assumed need.
• A business analyst uses activities
found in Elicitation and Collaboration,
Strategy Analysis, Requirements
Analysis and Design Definition, and
Solution Evaluation to transform that
request into a requirement or design.
• Regardless of the focus of the
stakeholder, the importance of the
role of the business analyst lies in
continuously asking the question
‘why?’.
• For example, “Why is either the
requirement or design necessary to
provide value to an enterprise and to
facilitate the realization of an
enterprise’s goals and objectives?”

@AMoSolo
BABOK® Guide Architecture: Five Key Elements

@AMoSolo
The six Core Standard Knowledge Areas
Knowledge areas represent areas of specific business analysis expertise that encompass several
tasks.
• Business Analysis Planning and Monitoring: describes the tasks that business
analysts perform formally or informally to organize and coordinate the efforts of
business analysts and stakeholders. These tasks produce outputs that are used as
key inputs and guidelines for the other tasks throughout the BABOK® Guide.
• Elicitation and Collaboration: describes the tasks that business analysts perform
to prepare for and conduct elicitation activities and confirm the results obtained.
It also describes the communication with stakeholders once the business analysis
information is assembled and the ongoing collaboration with them throughout
the business analysis activities.
• Requirements Life Cycle Management: describes the tasks that business analysts
perform in order to manage and maintain requirements and design information
from inception to retirement. These tasks describe establishing meaningful
relationships between related requirements and designs, and assessing, analyzing
and gaining consensus on proposed changes to requirements and designs.

@AMoSolo
The six Knowledge Areas
• Strategy Analysis: describes the business analysis work that must be performed
to collaborate with stakeholders in order to identify a need of strategic or tactical
importance (the business need), enable the enterprise to address that need, and
align the resulting strategy for the change with higher- and lower-level strategies.
• Requirements Analysis and Design Definition: describes the tasks that business
analysts perform to structure and organize requirements discovered during
elicitation activities, specify and model requirements and designs, validate and
verify information, identify solution options that meet business needs, and
estimate the potential value that could be realized for each solution option. This
knowledge area covers the incremental and iterative activities ranging from the
initial concept and exploration of the need through the transformation of those
needs into a particular recommended solution.
• Solution Evaluation: describes the tasks that business analysts perform to assess
the performance of and value delivered by a solution in use by the enterprise,
and to recommend removal of barriers or constraints that prevent the full
realization of the value.

@AMoSolo
Icons usually used for Knowledge Areas

@AMoSolo
Business Analysis Knowledge Areas
• Business Analysis Planning and Monitoring
• Plan and manage business analysis activities.
• Monitor stakeholder engagement.
• Decompose projects into Features that can be managed delivered independently.
• Strategy Analysis
• Define project vision and solution scope.
• Define clear measurable Business Objectives and a Business Case.
• Identify and manage impacts to business architecture.
• Requirements Analysis and Design Definition
• Define all requirement types as defined in BABOK and PMBOK.
• Analyze and document needed business changes using Impacts.
• Design solutions that address business requirements.
• Provide efficient methods to review and validate requirements.
• Requirements Lifecycle Management
• Trace requirements.
• Manage requirement changes.
• Clone and reuse requirements as needed.
• Elicitation and Collaboration
• Elicit stakeholder requirements using Personas, Scenarios, and Needs.
• Provide efficient mechanisms to enable stakeholders to collaborate on BA activities.
• Keep assignments from falling thought the cracks using action items.
• Solution Evaluation
• Validate that solution is delivering intended value.
• Use Fit/Gap Analysis to verify purchased solutions address requirements.
• Verify that solution deliverables address requirements.

@AMoSolo
Knowledge Areas Description
BA planning and monitoring Tasks BAs perform to organize and coordinate efforts of BAs and stakeholders
Elicitation and Collaboration Tasks BAs carry out to prepare for elicitation, conduct elicitation
activities, confirm results, communicate and collaborate with
stakeholders
Requirements LCM Tasks BAs perform to manage and maintain requirements and design information
from start till end
Strategy Analysis Tasks BAs perform to identify a need of strategic or tactical importance, how to
collaborate and enable stakeholders to address that need etc.
Requirements Analysis and Design
Definition
Tasks BAs carry out to organize elicited requirements, model them, validate and
verify them and identify and estimate potential value of solution options
Solution Evaluation Tasks BAs perform to assess the performance and value delivered by a solution

@AMoSolo
General Components of a Knowledge Area

@AMoSolo

@AMoSolo
Competencies should be in all activities

@AMoSolo
Underlying Competencies
• Underlying competencies reflect
• knowledge,
• skills,
• behaviours,
• characteristics, and
• personal qualities
that help one successfully perform the role of the business analyst.
• These underlying competencies are not unique to the business
analysis profession.
• However, successful execution of tasks and techniques is often
dependent on proficiency in one or more underlying competencies.

@AMoSolo

@AMoSolo
BABOK®3 Knowledge Areas vs
Techniques Matrix
10.1 Acceptance and Evaluation Criteria
10.2 Backlog Management
10.3 Balanced Scorecard
10.4 Benchmarking and Market Analysis
10.5 Brainstorming
10.6 Business Capability Analysis
10.7 Business Model Canvas
10.8 Business Rules Analysis
10.9 Collaborative Games
10.10 Data Dictionary
10.11 Data Flow Diagrams
10.12 Data Modeling
10.13 Decision Analysis
10.14 Decision Modeling
10.15 Document Analysis
10.16 Estimation
10.17 Focus Groups
10.18 Functional Decomposition
10.19 Glossary
10.20 Interface Analysis
10.21 Interviews
10.22 Item Tracking
10.23 Lessons Learned
10.24 Metrics and Key Performance Indicators (KP
10.25 Non-Functional Requirements Analysis
10.26 Observation
Business Analysis Planning & Monitoring
3.1.6 Plan Business Analysis Approach
3.2.6 Plan Stakeholder Engagement
3.3.6 Plan Business Analysis Information Management
3.4.6 Plan Business Analysis Governance
3.5.6 Identify Business Analysis Performance Improvements
Elicitation and Collaboration
4.1.6 Prepare for Elicitation
4.2.6 Conduct Elicitation
4.3.6 Confirm Elicitation Results
4.4.6 Communicate Business Analysis Information
4.5.6 Manage Stakeholder Collaboration
Requirements Life Cycle Management
5.1.6 Trace Requirements
5.2.6 Maintain Requirements
5.3.6 Prioritize Requirements
5.4.6 Assess Requirements Changes
5.5.6 Gain Consensus
Strategy Analysis
6.1.6 Analyze Current State
6.2.6 Define Future State
6.3.6 Assess Risks
6.4.6 Define Change Strategy
Requirements Analysis and Design Definition
7.1.6 Specify and Model Requirements
7.2.6 Verify Requirements
7.3.6 Validate Requirements
7.4.6 Define Requirements Architecture
7.5.6 Define Solution Options
7.6.6 Analyze Potential Value and Recommend Solution
Solution Evaluation
8.1.6 Measure Solution Performance
8.2.6 Analyze Performance Measures
8.3.6 Assess Solution Limitations
8.4.6 Assess Enterprise Limitations
8.5.6 Recommend Actions to Increase Solution Value
10.27 Organizational Modeling
10.28 Priortization
10.29 Process Analysis
10.30 Process Modeling
10.31 Prototyping
10.32 Reviews
10.33 Risk Analysis and Management
10.34 Roles and Permissions Matrix
10.35 Root Cause Analysis
10.36 Scenarios
10.37 Scope Modeling
10.38 Sequence Diagrams
10.39 Stakeholder List, Map, or Personas
10.40 State Modeling
10.41 Survey or Questionnaire
10.42 SWOT Analysis
10.43 Use Cases
10.44 User Stories
10.45 Vendor Assessment
10.46 Workshops

@AMoSolo BABOK V3.0
Techniques
Vs.
Knowledge Areas Tasks

@AMoSolo

@AMoSolo
Perspectives
• Perspectives are used within business analysis work to provide focus to tasks and techniques
specific to the context of the initiative. (I call it “Layers”)
• Most initiatives are likely to engage one or more perspectives. The perspectives included in the
BABOK Guide are:
• Agile
• Business Intelligence
• Information Technology
• Business Architecture
• Business Process Management
• These perspectives do not presume to represent all the possible perspectives from which
business analysis is practiced. The perspectives discussed in the BABOK Guide represent some of
the more common views of business analysis at the time of writing.
• Perspectives are not mutually exclusive, in that a given initiative might employ more than one
perspective.
• Perspectives have the following structure:
• Change Scope
• Business Analysis Scope
• Methodologies, Approaches, and Techniques
• Underlying Competencies
• Impact on Knowledge Areas

@AMoSolo
Perspective Structure
• Change Scope
• The Change Scope section describes what parts of the enterprise the change
encompasses when viewed from this perspective and to what extent it
impacts both the objectives and operations of the enterprise.
• The change scope also identifies the type of problems solved, the nature of
the solutions being sought, and the approach to delivering these solutions
and measuring their value.
• Business Analysis Scope
• The Business Analysis Scope section describes the key stakeholders, including
a profile of the likely types of sponsors, the target stakeholders, and the
business analyst's role within an initiative.
• It also defines likely outcomes that would be expected from business analysis
work in this perspective.

@AMoSolo
Perspective Structure
• Methodologies, Approaches, and Techniques
• The composition of this section is unique to each perspective. In each case it describes the
methodologies, approaches, or techniques that are common and specific to the application
of business analysis in the perspective.
• Methodologies and approaches are specialized ways of undertaking the business analysis
work.
• The techniques included in this section are techniques that are not included in the
Techniques chapter of the BABOK Guide but are especially relevant to the perspective.
• In the Business Architecture perspective, reference models are listed instead of
methodologies or approaches.
• In the Business Process Management perspective, frameworks are listed instead of
approaches.
• Underlying Competencies
• Describes the competencies that are most prevalent in the perspective
• Impact on Knowledge Areas
• The Impact on Knowledge Areas section describes how knowledge areas are applied or
modified. It also explains how specific activities within a perspective are mapped to tasks in
the BABOK Guide.

@AMoSolo

@AMoSolo
Requirements Life Cycle

@AMoSolo
Requirement

@AMoSolo
Requirements 11 States (a funnel)

@AMoSolo
to ensure stakeholders have a
shared understanding of business
analysis information and gain
agreement
Check info for accuracy and
consistency. discover errors,
omissions, conflicts, and ambiguity
Needs
E&C: Conduct
elicitation
stated
E&C: confirm
Elicitation Results
E&C: Stakeholder
Engagement
confirmed E&C: Communicate
BA info
communicated
traced
ApprovedRLCM: Approve Req.
Maintained &
Re-usable
RLCM: Maintain Req.
prioritized
RLCM: Prioritize
Requirements
RADD: Specify and
Model Req. (Design)
Specified &
Modeled
RADD: Verify Req.verifiedRADD: validate req.
validatedRADD: Define
Design Optionsallocated
RLCM: Trace Requirements
(Designs)
BABOK V3.0 Requirements States
Diagram (V1.2/2019)
By Ali Morshedsolouk
Note:
E&C: Elicitation and Collaboration
RLCM: Requirement Life Cycle Management
RADD: Requirement Analysis and Design definition
From Any
State
assumptionconstrainst risk
works with stakeholders involved in
the governance process to obtain
agreement and reach approval and
agreement on requirements and
designs
Authorized Stakeholders
Sign-off
Observe/Interview With
stakeholders
(Get actual desire or intention)
ensures that requirements and
designs are accurate and current
throughout the life cycle and
facilitates reuse in other solutions
where appropriate
analyzes and maintains the relationships between
requirements, designs, solution components, and
other work products for impact analysis, coverage,
and allocation.
to ensure that requirements and designs at different
levels are aligned to one another
riskdifficultyurgencyValue
assesses the value, urgency, and risks
associated with particular requirements
and designs to ensure that analysis and/or
delivery work is done on the most
important ones at any given time
to analyze, synthesize, and
refine elicitation results into
requirements and designs
to ensure that requirements and designs
specifications and models meet quality
standards and are usable for the purpose they
serve (testable), to be used for further
development
to ensure that all requirements and
designs align to the business
requirements and support the
delivery of needed value
Allocation of resources to
designs and implementation
of a solution BABOK 3.0 Review (Ch1&2) 93

@AMoSolo
Requirements Lifecycle according to BABOK®
• 1. Stated (Unconfirmed)
• E&C Conduct Elicitation
• A Requirement starts to live with its first state called Stated (Unconfirmed) after it has been documented as a result of an elicitation activity. Such requirements
describe the stakeholder’s need from the stakeholder’s perspective.
• A Stated (Unconfirmed) requirement can be input for several Tasks like Communicate Requirements, Prioritize Requirements, Specify and Model Requirements,
Manage Requirements Traceability or Maintain Requirements for Re-use.
• But mostly, a Stated (Unconfirmed) requirement needs first to be confirmed in order to validate that the stated requirements expressed by the stakeholder match
the stakeholder’s understanding of the problem and the stakeholder’s needs.
• 2. (Stated) Confirmed
• E&C Confirm Elicitation Results
• By Techniques interviewing or observing the stakeholders, the BA shall confirm whether his or her understanding conforms to the actual desires or intentions of
the stakeholder.
• Stated (Confirmed) requirements can as well be used as input for the same Tasks mentioned above with Stated (Unconfirmed) requirements and furthermore
they can be verified.
• While the Tasks Document Elicitation Results and Confirm Elicitation Results belong to the Knowledge Area Elicitation, the Task Verify Requirements belongs to
Requirements Analysis.
• 3. Communicated
• E&C Communicate BA info and E&C Stakeholder Engagement
• The Task Communicate Requirements is a very essential task which a BA should pay much attention on.
• This Task helps to bring stakeholder to a common understanding of the requirements by having conversations, discussions and presentations, both, formally and
informally.
• Once achieved a common understanding of the requirements, conflicts between stakeholders are less likely, of course.
• Requirements for which a common understanding has been achieved can be considered Communicated.
• Whenever requirements, constraints, assumptions or risk change, Communicate Requirements shall start again, necessary to once again achieve a common
understanding in the light of the changed environment.
• Requirements of any state can be Communicated.

@AMoSolo
• 4. Traced
• RLCM Trace Requirements
• The Task Manage Requirements Traceability helps to trace requirements back to their origin and forward to their implementation.
• Furthermore, it covers the relationships between requirements.
• While performing this task a so called Coverage Matrix will be created, mostly as spreadsheet, in more complex environments often
supported by a requirements database solution.
• 5. Approved
• RLCM Approve Requirements
• The status Approved can only be achieved through sign-off by authorized stakeholders, the related BABOK® task is called RLCM
Approve Requirements.
• A sign-off can be done informally by confirmation/approval mail or more formally by hand-signing a printed representation of the
requirements specification (package), depending on the Organizational Process Assets and/or regulatory reasons.
• It goes without saying that requirements can only be presented for sign-off after they have been communicated sufficiently.
• Furthermore relationships to other requirements must have been clarified and captured as well as backward tracing to Business
requirements, both by utilizing a so-called Coverage Matrix.
• Therefore only requirements which have been Communicated and Traced can undergo a sign-off procedure, i.e., an approval process.
• After approval requirements may be baselined in order to compare later changes against this baseline.

@AMoSolo
• 6. Maintained & Re-usable
• RLCM Maintain Requirements
• This status is completely decoupled from the rest of the requirements lifecycle.
• The related task Maintain Requirements for Re-use can be applied to requirements in any state and it does not influence the development of a
requirement with regards to its implementation or productive operation.
• By somehow “generalizing” requirements for re-use, Business Analysis delivers significant value to the organization.
• Requirements which have been maintained for re-use are ready-to-use for later projects, including all affiliated activities like tests, training or
whatsoever.
• A well documented, re-usable requirement can save lots of money as all Business Analysis processes can be accelerated or shorten and
mitigated in terms of risks that the requirement does not satisfy the Business needs.
• 7. Prioritized
• The task is RLCM Prioritize Requirements
• Depending on the value the requirement delivers to Business, the risk, the difficulty and the urgency a requirement may get a higher or lower
priority.
• The more the majority of the stakeholders agree on the priority of a requirement, the higher the priority automatically gets.
• Common Techniques used to figure out the priorities of requirements are Decision Analysis, Risk Analysis and MoSCoW Analysis.
• MoSCoW divides the requirements in four categories: Must, Should, Could, and Won’t.
• Another criteria prioritizing requirements can be Timeboxing/Budgeting. Here, requirements are prioritized according to the amount of work a
team is able to perform in a given period of time, e.g. releases or other time constraints which may exist.

@AMoSolo
• 8. Analyzed (Specified and Modeled)
• Output of the task RADD Specify and Model Requirements
• In the BABOK®, the analysis of requirements strongly goes along with modeling.
• Therefore the Techniques bound to this Task are manifold.
• Many kinds of modeling like Data Modeling, Organization Modeling, Process Modeling and the commonly used diagram methodologies found
in UML and others are mentioned in the BABOK®.
• Although the BA does not need to know each methodology in detail, he should at least know for what purposes he should use which approach.
• See the word file “Requirement Tips.docx”

@AMoSolo
• 9. Verified
• Output of RADD Verify Requirements task/
• Verify Requirements ensures that requirements are of a sufficient quality to be processed further.
• Requirements which do not provide enough information to be reasonably reviewed and validated by the stakeholders will not be verifiable due
to lack of quality.
• Further processing of such requirements does not make sense that is why they should be refined or dropped, alternatively.
• To mention only one of the quality criteria, I would like to emphasize that a requirement must be testable in order to prove that a require
• 10. Validated
• RADD “Validate Requirements” task/“Define Requirement Architecture”
• The Task Validate Requirements needs Verified requirements as input in order to validate their Business value.
• Validated means that the requirements’ value can be demonstrated to the Business stakeholders and that they aligned with the goals and
objectives of the Business.
• 11. Allocated
• RADD ”Define Design Options”/”Analyze Potential Value and Recommend solution”
• This state can only be reached if the requirement has been Prioritized and Approved beforehand.
• By performing the task Allocate Requirements out of the Knowledge Area Solution Assessment and Validation the implementation and/or
deployment of requirements in terms of point in time is fixed.
• This may depend on release cycles, on available resources or on other constraints

@AMoSolo
Let’s practice
• Name some disorders, undesired conditions or serious needs in your
department, SBU, company
• Sort out them
• Classify them
• Prioritize them
• Document them as a list
• Follow the requirements States in your practice from Stated to
Allocated
• Do the two peoples in the same department give out the same list?

@AMoSolo

@AMoSolo
Business Analysis Risk
• If the maturity of business analysis in your organization is low, then
you have high risk for:
• Increasing the number of failed or challenged projects
• Failing to achieve business benefits
• Delivering solutions that do not meet user needs
• Creating high development rework resulting in budget and schedule overruns
• Having low customer and user satisfaction
• Failing to manage solution scope resulting in delays and budget overruns.

@AMoSolo
Quiz Time
• https://ottawa-outaouais.iiba.org/ecbatm-ccbar-cbapr-study-groups

@AMoSolo
Questions?
amorshed@icasat.net

@AMoSolo
According to BABOK V3.0
amorshed2008@gmail.com

@AMoSolo
BABOK V3.0 Guide - Summary
5 Key Elements with 5 Key Concepts
6 Core Concepts
29 Core Competencies in 6 Group
5 Perspectives
30 Tasks
6 Knowledge Areas
50 Techniques

@AMoSolo

@AMoSolo
Core Concepts Model

@AMoSolo
General relationship between Knowledge Areas

@AMoSolo
Perspectives

@AMoSolo

@AMoSolo
Stakeholders
Context
Perspective
Req 1
Req 2
Req 3
.
.
.
.
Req n
(E&C)
(RLCM)
Design 1
Design 2
Design 3
.
.
.
.
.
.
.
.
.Design n
(RADD)
(SA)
Design
Definition
Stated,
Confirmed,
Communicated,
Approved,
Prioritized,
Modeled,
Verified,
Validated,
Allocated,
Traced,
Maintained,
Strategy
Stakeholders
Context
(company capacity)
Perspective
Business Process,
Business Architecture,
Business Intelligence,
IT/IS,
Agile
Project
Management
to implement
Initiative
Need
Finalize
Solution
Prototype
Change strategy
Stkhld approve
Solution
Evaluation
(SE)
Decision making
(Cognitive biases)
Core Competencies
BACCM (Need, Design, Change, Value, Stakeholder, Context)
Business Analysis Model
(According to BABOK V3.0 )
By Ali Morshedolouk
(BAPM)
Info Analysis
(Req. & Design)
11 states
Risk
Problem
Opportunity
Assumption
Regulation
Constraints

@AMoSolo
to ensure stakeholders have a
shared understanding of business
analysis information and gain
agreement
Check info for accuracy and
consistency. discover errors,
omissions, conflicts, and ambiguity
Needs
E&C: Conduct
elicitation
stated
E&C: confirm
Elicitation Results
E&C: Stakeholder
Engagement
confirmed E&C: Communicate
BA info
communicated
traced
ApprovedRLCM: Approve Req.
Maintained &
Re-usable
RLCM: Maintain Req.
prioritized
RLCM: Prioritize
Requirements
RADD: Specify and
Model Req. (Design)
Specified &
Modeled
RADD: Verify Req.verifiedRADD: validate req.
validatedRADD: Define
Design Optionsallocated
RLCM: Trace Requirements
(Designs)
BABOK V3.0 Requirements States
Diagram (V1.2/2019)
Note:
E&C: Elicitation and Collaboration
RLCM: Requirement Life Cycle Management
RADD: Requirement Analysis and Design definition
From Any
State
From Any
Lower States
assumptionconstrainst risk
works with stakeholders involved in
the governance process to obtain
agreement and reach approval and
agreement on requirements and
designs
Authorized Stakeholders
Sign-off
Observe/Interview With
stakeholders
(Get actual desire or intention)
ensures that requirements and
designs are accurate and current
throughout the life cycle and
facilitates reuse in other solutions
where appropriate
analyzes and maintains the relationships between
requirements, designs, solution components, and
other work products for impact analysis, coverage,
and allocation.
to ensure that requirements and designs at different
levels are aligned to one another
riskdifficultyurgencyValue
assesses the value, urgency, and risks
associated with particular requirements
and designs to ensure that analysis and/or
delivery work is done on the most
important ones at any given time
to analyze, synthesize, and
refine elicitation results into
requirements and designs
Also known as Analyzed
to ensure that requirements and designs
specifications and models meet quality standards
and are usable for the purpose they serve
(testable), to be used for further development
to ensure that all requirements and
designs align to the business
requirements and support the
delivery of needed value
Allocation of resources to
designs and implementation
of a solution BABOK 3.0 Review (Ch1&2) 112

@AMoSolo

@AMoSolo BABOK V3.0
Techniques
Vs.
Knowledge Areas Tasks

@AMoSolo

@AMoSolo
‫گفت‬ ‫مردم‬ ‫به‬‫سخنهاي‬ ‫پاک‬ ‫ای‬ ‫فرزانه‬‫شمارید‬ ‫نیكو‬ ‫مرا‬
‫بكارید‬ ‫خود‬ ‫حیاط‬ ‫اندر‬ ‫برنج‬ ‫دارید‬ ‫ساله‬ ‫یك‬ ‫برنامه‬ ‫اگر‬
‫درخت‬‫باغ‬ ‫در‬ ‫كاشت‬ ‫باید‬ ‫میوه‬‫ساله‬ ‫ده‬ ‫برنامه‬ ‫اگر‬‫دارید‬
‫گمارید‬ ‫همت‬ ‫ساختن‬ ‫انسان‬ ‫به‬ ‫باید‬ ‫صدساله‬ ‫را‬ ‫برنامه‬ ‫اگر‬
‫سپارید‬ ‫او‬ ‫دست‬ ‫به‬ ‫را‬ ‫جهاني‬ ‫شاید‬ ‫كردید‬ ‫تربیت‬ ‫انسان‬ ‫چو‬

Business Analysis basics - Based on BABOK V3.0

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Business Analysis basics - Based on BABOK V3.0

Similar to Business Analysis basics - Based on BABOK V3.0 (20)

Recently uploaded

Recently uploaded (12)

Business Analysis basics - Based on BABOK V3.0