Business Analysis and The IIBA Business Analysis Body of Knowledge BABOK

Business Analysis and
BABOK (Business Analysis

Book of Knowledge)
Alan McSweeney
Objectives
• To provide an overview of the importance of business

analysis in project success and to introduce the Business
Analysis Body of Knowledge concept and structure
November 26, 2009 2

Agenda
• Business Analysis
• Requirements
• Business Analysis Body of Knowledge (BABOK)
• Establishment of a Business Analysis Function
November 26, 2009 3

Business Analysis
• Business Analysis
− Set of tasks, knowledge and techniques required to identify business needs
and determine solutions to business problems
− Business analysis is the connecting layer between strategy and
systems/technology
• Solutions
− Include a systems development component, but may also consist of process
development or improvement or organisational change
• Business Analyst
− Works as a liaison among stakeholders in order to elicit, analyse, communicate,
and validate requirements for changes to business processes, policies, and
information systems
− Understands business problems and opportunities in the context of the
requirements and recommends solutions that enable the organisation to
achieve its goals
November 26, 2009 4
Business Analysis Skills
• Ability to develop a clear and detailed understanding of:

− The requirements to solve a business problem, often with a
system implementation/solution selection
− How the proposed system or solution will interoperate or
integrate with the existing systems and technology in which the
new system will operate
− How the proposed system or solution fits the existing enterprise
architecture and business strategy
− The business problem from multiple perspectives: business, user,
functional, quality of service, implementation, etc.
November 26, 2009 5

Roles of the Business Analyst
• Gather requirements
• Document processes
• Identify improvement opportunities
• Document business requirements
• Act as the liaison between users and
system/solution/technical architects
November 26, 2009 6

Roles of the Business Analyst
• Gathers data that is unstructured –

comments/information/discussions/interviews from/with users)
• Converts that data into information in a structured format
• Converts that information into knowledge that is structured and
usable
• Develop requirements for change to:
− Business processes
− Information systems
• Understand business problems and opportunities
• Provide recommendations for solutions
• Be an advocate for the business user
• Work as a liaison among stakeholders
November 26, 2009 7

Importance of Business Analysis
• A factor present in every successful project and absent in every unsuccessful project is
sufficient attention to requirements
• Half of all bugs can be traced to requirement errors
• Fixing these errors consumes 75% of project rework costs
• 25%- 40% percent of all spending on projects is wasted as a result of re-work
• 66% of software projects do not finish on time or on budget
• 56% of project defects originate in the requirements phase of the project
• Completed projects have only 52% of proposed functionality
• 75-80% of IT project failures are the result of requirements problems
• The average project exceeds its planned schedule by 120%
• 53% of projects will cost 189% of their original estimate
• 30% of projects are cancelled before completion
• 50% of projects are rolled back out of production
• The typical project expends least effort on analysis where most errors originate and whose
errors cost most to fix
• Requirements errors cost the most and that poor requirements are the main cause of
software failure
November 26, 2009 8

Factors for Project Success
• Effective and targeted project management and systems

engineering processes, tools, and techniques
• Appropriate executive decision making
• Effective project leadership
• High-performing teams
• Collaboration and respect between the business and IT
communities
• Business analysis processes that ensure the development
team will have a clear understanding of the customer’s
overall business and information needs
November 26, 2009 9
IT and Business Analysis
• IT need to possess expertise in multiple domains

• IT must prove it can understand business realities-
industry, core processes, customer bases, regulatory
environment
• Contribute real business value to their enterprise
November 26, 2009 10

Align Business Analysis to Solution Lifecycles
• Business Analysis exists in wider context

Strategy, Business Planning and Business Analysis
Business Initial Requirements Decision to Requirements Management and Change Operations and
Concept Discovery Elicitation Proceed Management Use
Solution Architecture and Design
Solution Solution Solution Specification and

Architecture Design Change Management
Project Management Cycle
Initiate Execute and Control
Plan Close
Solution Delivery - Implementation and Deployment Lifecycle
Setup and Implement

Manage Evolve
Prepare Develop Test Deploy

Business Analysis Challenges
• Lack of advance planning for projects and initiatives

• Lack of formal training for Business Analysts
• Inconsistent approach to business analysis
• Outsourcing and relying on external contractors to
perform major roles in system development
• Impatience with the analysis/design/planning process
• Gap between what Business Analysts are assigned to do
and what they should be assigned to do

Why Projects Fail
• Very significant Business/IT pain point

− All too frequent implementation of IT solutions that fail to meet business requirements
• Look at the general causes of those failures
− Look for solutions whose implementation will address those causes
• Projects fail to deliver solutions that meet requirements because of some
combination of some or all of the following conditions
− Poor understanding of the business need or problem
− Poorly defined and/or stated requirements
− Inadequately explored solution options
− Poor solution design
− Misalignment between requirements and project scope
− Poor project planning/execution
− Poor change management
• Many of these are related to business analysis and related activities
• Cannot separate project management, project portfolio management, business
analysis and solution architecture

Avoiding Project Failures
• Poor understanding of the business need or problem

− Implement effective requirements elicitation processes
− Implement business analysis processes and governance
• Poorly defined and/or stated requirements
− Gather requirements effectively
− Communicate requirements clearly to stakeholders
− Involve all relevant stakeholders appropriately
• Inadequately explored solution options
− Implement solution architecture standards and governance
− Conduct format cost/benefit analyses
− Reuse existing components
• Poor solution design
− Translate requirements into design
− Validate design
− Implement solution design standards and governance

• Misalignment between requirements and project scope

− Requirements drive scope of project, transition and operational aspects of the
proposed solution
− Translate requirements into IT language
• Poor project planning/execution
− Monitor deliverables
− Ensure quality
− Implement effective project management and governance
• Poor change management
− Implement effective change management and governance
− Effective change analysis
− Communicate to the solution team of changes in business requirements
− Communication to the business stakeholders of variations from the project
charter, reflected in an updated business case
Strategy, Business Planning and Business Analysis
Business Initial Requirements Decision to Requirements Management and Change Operations and
Concept Discovery Elicitation Proceed Management Use
Solution Architecture and Design
Solution Solution Solution Specification and

Architecture Design Change Management
Project Management Cycle
Initiate Execute and Control
Plan Close
Solution Delivery - Implementation and Deployment Lifecycle
Setup and Implement

Manage Evolve
Prepare Develop Test Deploy
Poor Misalignment
Inadequately
Understanding Poorly Defined Between Poor Project
Explored Poor Solution Poor Change
Of The And/Or Stated Requirements Planning/
Solution Design Management
Business Need Requirements And Project Execution
Options
Or Problem Scope
Business Solution Project Business

Analysis Architecture Management Analysis
• Ensure adequate and appropriate resources and involvement during

project lifecycle
Aligning the Solutions Being Delivered
• Need more than project management

− Not the complete picture
− Cannot treat project management in isolation
• Need to ensure that the solution being managed meets business
requirements
• Need to ensure business requirements are captured
• Need to ensure that solutions are designed to deliver business
requirements and comply with organisation’s enterprise architecture
• Fundamentally the project exists to manage the delivery of the
solution that has been designed to meet business requirements
that assist with delivery of the business plan

Complete Picture of Project Selection and Delivery
Structured Capture
and Management of
Requirements
Business Analysis Design of

Solutions to
Meet
Requirements
Programme and
Solution
Project
Architecture
Management
Prioritisation
Delivery of of Projects
Projects
Project Portfolio
Management

Frameworks and Methodologies
• Use of a business analysis methodology and framework

can seem to impose an unnecessary burden but it delivers
real benefits
• Benefits of Adoption • Potential Disadvantages
− Consistency − Time to Adopt
− Speed − Cost to Adopt
− Drives Delivery − Suitability
− Ensures Acceptance − Too Comprehensive
− Productivity − Cost of Use
− Reuse − Not Currently In Use Within
− Professionalism − Risk
− Customer Confidence
− Speed
− Accuracy
− Audit Trail
− Cost Saving
− Risk Management and Reduction

Requirements

Requirements
• A condition or capability needed by a stakeholder to solve a problem

or achieve an objective
• 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
• A documented representation of a condition or capability
• Focus on a particular business process or processes
• Describe the business need or problem and address all the functions
associated with their delivery
• In project terms, requirements are the detailed items necessary to
achieve the goals of the project
• Requirements analysis is key to successful project
Requirements
• Objective is to define and describe the characteristics of an

acceptable solution to a business problem, so that the
project team has a clear understanding of how to design
and implement it
• It is all about requirements

Requirements Planning and Management
• Identify team roles: project manager, business analysts, developers, quality

assurance analysts, trainers, application architects, data modeler, database
analyst, infrastructure analyst, information architect, subject matter (functional)
experts, etc.
• Identify stakeholders (who will provide requirements information): executive
sponsor, solution owner (client), end users, functional managers, investors, etc.
• Distribute responsibilities amongst business analysts and other team members
and define coordination, team communication and knowledge sharing
mechanisms and processes
• Define risk monitoring and management approach for each identified risk
• Define the requirements and system development method
• Define the requirements and system development process
• Manage requirements change and scope: requirements creep is a big problem
• Define and collect project metrics and reporting mechanisms
• Other project planning and project management activities

Hierarchy of Requirements – from Enterprise to
Project/Initiative
Solutions delivered by
Business Vision and Re programmes and projects
qu
Goal ire cascade from business vision
me
nts to ultimate operation and
Hie service delivery
Strategy rar
ch
y –f
rom
Bu
Business Plan s in
ess
to
De Sp
liv eci
ery Programmes for fic
an Ini
dO
Strategic Objectives tia
tiv
pera es
Solutions delivered by
programmes and projects
tio Systems and
n
need to be aligned to the Solutions
overarching business
vision and goal
Operation of Solution

Analysis and Design Build Bridge From Business to
Solution
Problem Business Analysis:

Requirement
Elicit Requirements
Analyse
Communicate
Current State Validate
Business
Analysis and
Solution Design
Solution Design: Solution
Translate
Requirements into Desired Future
Solution State

Requirements Team
Business • Need the

Analysis perspectives of all
parties
• Requirements need
Business
Solution to be verified by
Architect
those who are
Initiative contributors in
Sponsor
solution definition
• Is there enough
information in the
requirements to build
Project Lead
Manager Developer a solution that
delivers the business
case?
Requirements Within Solution Lifecycle
Business Operational
Concept Use
Business Acceptance
De
Test
fin
Requirements
eR
eq
System System
uir
Requirements Testing
il
e
nts Fulf
me
me and
Integration
nts
High-Level
Design Testing
an
qu on
dD
Re oluti
ire
es i
Low-Level Component
rS
gn
live
Design Testing
So
De
lut
ion
Install and
Implement

Requirements
• Business requirements drive strategy, architecture and

project/solution implementation
• Capturing requirements is essential
• Define key principles/policies/critical success factors for IT
• Requirements define what is to be delivered
• Getting requirements wrong has a substantial cost and contributes
to the reasons for project failure
• Requirements on their own are not sufficient: solution must be
designed to deliver on requirements
Business
Functional Project/Solution
Requirements Strategy Architecture
Technical Implementation
Implementation

Requirements Specification
• Requirements Specification describes what a system

should do
− Should be produced as early as possible in the
development/delivery cycle
− One of the most difficult aspects of system development/delivery
− One of the most important tasks of system development/delivery
− Should focus on the interactions with the user

Where Do Errors in Projects/Initiatives Arise
Other
Development/
Implementation
Solution
Gaps in Design
Requirements
• Getting requirements right reduce risk of project failure

Relative Cost of Fixing Errors During Project Lifecycle
1000
• Errors/gaps/omissions
become significantly
(Logarithmic Scale)
100
more expensive to fix at
later stages of project
lifecycle 10
t
n
n
g
g
ts
en
tio
sig
tin
in
en
st
m
es
ta
De
m
Te
oy
en
rT
ire
pl
em
em
e
qu
De
Us
st
Re
pl
Sy
Im
t/
en
pm
lo
ve
De
Low Cost Estimate High Cost Estimate

Complete View of Requirements Process
Requirements
Requirements
Enterprise Analysis Planning and
Elicitation
Management
Define the problem Plan the requirements

capture and management Gather the requirements
Define the solution scope process
Requirements Solution
Requirements
Analysis and Assessment and
Communication
Documentation Validation
Present requirements Analyse requirements
Define solution
Agree requirements Identify gaps
Ensure the solution
meets the requirements
Refine requirements Refine requirements

Requirements Capture and Management
STAGES
Requirements Development Requirements Management

e e
tur tur
Cap Cap
Asse
Asse
ACTIVITIES Gather Analyse Review
ss
ss
Cha Cha
nge nge
Stages and Activities of Requirements Capture and Management
Requirements Development Requirements Management

• Gather – Tasks relating to the initial • Capture – Ensure that the new
gathering of requirements (uses numerous requirements or change requests are
techniques). captured and notated.
• Analyse – Analysing and categorising • Assess – Consider whether the changes
requirements. Specifying them. will be actioned. Approve or reject.
• Review – Agreeing (with the stakeholders) • Change – Undertake the changes.
exactly what the requirements are. Modify
if necessary to reach agreement.

Communication and Documentation
• Objective is to develop an accurate understanding of the business

problem and clearly articulate the solution
• Key components
− Communication skills are critical – two ways: not only clearly articulating things
verbally and in writing, but also listening effectively
− Selecting the appropriate models, artifacts and other requirements documents
formats
− Describing models and text artifacts clearly, accurately and concisely
− Key deliverable: “requirements specification” representing the BA’s
“demonstrated understanding” of the business and processes that need to be
handled by the system and its necessary capabilities
− Specifications serve as the foundation for: effort estimation, budgeting,
resource allocation, contractual terms, and implementation planning, etc.
− Preparing effective presentations for clients and stakeholders

Requirements Classification
• Business Requirements
− High-level statements of the goals, objectives, or needs of the enterprise
− Reasons why a project has been initiated, the objectives that the project will achieve
− Metrics that will be used to measure its success.
• Stakeholder Requirements
− Statements of the needs of stakeholders
• Solution Requirements
− Characteristics of a solution that meet business requirements and stakeholder
requirements
− Functional Requirements
• Describe the behaviour and information that the solution will manage
− Non-Functional Requirements
• Describe environmental conditions under which the solution must remain effective or qualities
the solution must have
• Transition and Implementation Requirements
− Capabilities that the solution must have in order to facilitate transition from the current
state of the enterprise to a desired future state, but that will not be needed once that
transition is complete

Business Analysis Body of Knowledge (BABOK)

• Developed by the IIBA (International Institute of Business Analysis) -

http://www.theiiba.org/
• BABOK is the collection of knowledge within the profession of
Business Analysis and reflects generally accepted practice
• Describes business analysis areas of knowledge, their associated
activities and tasks and the skills necessary to be effective in their
execution
• Identifies currently accepted practices
• Recognises business analysis is not the same as software
requirements
• Defined and enhanced by the professionals who apply it
• Captures the knowledge required for the practice of business
analysis as a profession

• Describes in idealised approach to performing the

complete range of business analysis activities
• Can be customised to suit the needs of an organisation
and initiative

BABOK Knowledge Areas and Activity Flow
Business Analysis
Planning and
Monitoring
Solution
Enterprise
Assessment and
Analysis
Validation Requirements
Elicitation Management and
Communication
Requirements
Analysis
Underlying
Competencies
BABOK Knowledge Areas Structure
Knowledge
Area
• Each Knowledge Area
consists of a set of tasks
Inputs 1 Task 1 Outputs 1 • Each task has inputs and
outputs
Stakeholders Techniques • Outputs from earlier tasks
can be inputs to
subsequent tasks
Inputs 2 Task 2 Outputs 2 • Each task has stakeholders
that may potentially
participate
Stakeholders Techniques
• Each task can use one or
… … more generally accepted
techniques that support
Inputs N Task N Outputs N the practice of business
analysis
Stakeholders Techniques

BABOK Knowledge Areas
• Business Analysis Planning and Monitoring

− Determine which activities are necessary in order to complete a business analysis effort
− Identification of stakeholders, selection of business analysis techniques, the process that will be
used to manage requirements, and how to assess the progress of the work
• Elicitation
− Work with stakeholders to identify and understand their needs and concerns and the environment
in which they work
− Ensure that a stakeholder’s actual underlying needs are understood
• Requirements Management and Communication
− Manage conflicts, issues and changes in order to ensure that stakeholders and the project team
remain in agreement on the solution scope
− Communicate requirements to stakeholders
− Knowledge gained by the business analyst is maintained for future use
• Enterprise Analysis
− Identify a business need, refine and clarify the definition of that need, and define a solution scope
that can feasibly be implemented by the business
• Requirements Analysis
− Prioritise and progressively elaborate stakeholder and solution requirements in order to enable the
project team to implement a solution that will meet the needs of the sponsoring organisation and
stakeholders

BABOK Knowledge Areas and Constituent Tasks
BABOK Knowledge
Areas
Business Analysis Requirements Solution

Requirements Underlying
Planning and Elicitation Management and Enterprise Analysis Assessment and
Analysis Competencies
Monitoring Communication Validation
Manage Solution Analytical Thinking

Prepare for Define Business Prioritise Assess Proposed
Plan Business Scope and and Problem
Elicitation Need Requirements Solution
Analysis Approach Requirements Solving
Manage
Conduct Conduct Elicitation Assess Capability Organise Allocate Behavioural
Requirements
Stakeholder Activity Gaps Requirements Requirements Characteristics
Traceability
Analysis
Maintain Assess
Document Determine Specify and Model Business
Plan Business Requirements for Organisational
Elicitation Results Solution Approach Requirements Knowledge
Analysis Activities Re-use Readiness
Prepare Define
Plan Business Confirm Elicitation Define Solution Define Transition Communication
Requirements Assumptions and
Analysis Results Scope Requirements Skills
Package Constraints
Communication
Plan Requirements Communicate Define Business Verify

Management Validate Solution Interaction Skills
Requirements Case Requirements
Process
Manage Business Validate Evaluate Solution Software

Analysis Requirements Performance Applications
Performance

BABOK Techniques
• Acceptance and Evaluation Criteria Definition

• Brainstorming
• Business Rules Analysis
• Data Dictionary and Glossary
• Data Flow Diagrams
• Data Modelling
• Decision Analysis
• Document Analysis
• Interviews
• Metrics and Key Performance Indicators
• Non-functional Requirements Analysis
• Organisation Modelling
• Problem Tracking
• Process Modelling
• Requirements Workshops
• Scenarios and Use Cases

Related Business Analysis Skills, Techniques and
Frameworks
• Agile Development
• Business Intelligence
• Business Process Management
• Business Rules
• Decision Analysis
• Enterprise Architecture
• Governance and Compliance Frameworks
• IT Service Management
• Lean and Six Sigma
• Organisational Change Management
• Project Management
• Quality Management
• Service Oriented Architecture
• Software Engineering (particularly Requirements Engineering)
• Software Process Improvement
• Software Quality Assurance
• Strategic Planning
• Usability and User Experience Design

Business Analysis Planning and Monitoring - Tasks
BABOK Knowledge
Areas


Manage
Requirements
Traceability
Analysis
Maintain Assess
Prepare Define
Package Constraints
Communication

Process

Performance

Business Analysis Planning and Monitoring
Knowledge Area
• Identifying stakeholders
• Defining roles and responsibilities of stakeholders in the business analysis effort
• Developing estimates for business analysis tasks
• Planning how the business analyst will communicate with stakeholders
• Planning how requirements will be approached, traced, and prioritised
• Determining the deliverables that the business analyst will produce
• Defining and determining business analysis processes
• Determining the metrics that will be used for monitoring business analysis work
• Monitoring and reporting on work performed to ensure that the business analysis
effort produces the expected outcomes

Business Analysis Planning and Monitoring - Inputs
and Outputs Outputs
Inputs Tasks
BA
Business Analysis
Communication
Approach
Plan
Business Analysis Conduct

Plan Business
and Performance Business Need Stakeholder
Analysis Approach
Metrics Analysis
BA Performance Business Analysis

Assessment Plan(s)
Enterprise Expert Plan BA

Plan BA Activities
Architecture Judgement Communications
Requirements
BA Process Assets Management
Plan
Plan
Organisational Requirements Manage BA
Process Assets Management Performance
Process
Stakeholder List,
Roles, and
Responsibilities

Task - Plan Business Analysis Approach
Outputs
Inputs Tasks
BA
Business Analysis
Communication
Approach
Plan

Plan Business
Analysis Approach
Metrics Analysis

Assessment Plan(s)

Plan BA Activities
Requirements
Plan
Plan
Process
Stakeholder List,
Roles, and
Responsibilities

Task - Plan Business Analysis Approach
Plan Driven
Spectrum of Options Change Driven
Approach Approach
• Focus on minimising up-front • Focus on rapid delivery of business

uncertainty and ensuring that the value in short iterations in return for
solution is fully defined before acceptance of a higher degree of
implementation begins in order to uncertainty regarding the overall
maximise control and minimise risk delivery of the solution
• Preferred in situations where • Preferred when taking an exploratory
requirements can effectively be approach to finding the best solution
defined in advance of or for incremental improvement of an
implementation, the risk of an existing solution
incorrect implementation is
unacceptably high, or when managing
stakeholder interactions presents
significant challenges

Elements of Task - Plan Business Analysis Approach
(1)
• Timing of Business Analysis Work
− When the business analysis efforts should occur
− When tasks need to be performed
− Will the level of business analysis effort will need to vary over time
− Will enterprise analysis, requirements analysis, and solution assessment and validation
activities will be performed primarily in specific project phases or iteratively over the
course of the initiative
• Formality And Level Of Detail Of Business Analysis Deliverables
− Will requirements be delivered as formal documentation or through informal
communication with stakeholders
− What is appropriate level of detail that should be contained in these documents
− Expected deliverables must be defined as part of the approach
• Requirements Prioritisation
− How will requirements will be prioritised and how those priorities will be used to define
the solution scope
• Change Management
− What is expected likelihood and frequency of change
− Ensure that the change management process is effective for those levels of change
− Effective business analysis practices can significantly reduce the amount of change
required in a stable business environment but cannot eliminate it entirely
Elements of Task - Plan Business Analysis Approach
(2)
• Business Analysis Planning Process
− Determine the process that will be followed to plan the execution of
businesses analysis activities
− Ensure this integrated with the larger project plan
• Communication With Stakeholders
− Decide how communications with regard to project decision-making and
approval of deliverables are to be made
• Requirements Analysis and Management Tools
− Identify any requirements analysis or management tools that will be used.
• Project Complexity
− The complexity of the project, the nature of the deliverables, and the overall
risk to the business needs to be taken into consideration

Project Complexity Factors
• Number of stakeholders
• Number of business areas affected
• Number of business systems affected
• Amount and nature of risk
• Uniqueness of requirements
• Number of technical resources required

Output of Task - Plan Business Analysis Approach
• Definition of the approach that will be taken for business

analysis in a given initiative
• Specify team roles, deliverables, analysis techniques, the
timing and frequency of stakeholder interactions, and
other elements of the business analysis process
• Decision about which organisational process assets will be
applied and any decisions made regarding tailoring of the
process for a specific situation

Task - Conduct Stakeholder Analysis
Outputs
Inputs Tasks
BA
Business Analysis
Communication
Approach
Plan

Plan Business
Analysis Approach
Metrics Analysis

Assessment Plan(s)

Plan BA Activities
Requirements
Plan
Plan
Process
Stakeholder List,
Roles, and
Responsibilities

Task - Conduct Stakeholder Analysis
• Identify stakeholders who may be affected by a proposed

initiative or who share a common business need
• Identify appropriate stakeholders for the project or project
phase
• Determine stakeholder influence and/or authority
regarding the approval of project deliverables

Elements of Task - Conduct Stakeholder Analysis (1)
• Identification
− Who are the stakeholders are and what is the impact of proposed changes on them
− Understand what needs, wants, and expectations must be satisfied by the solution
− Requirements are based on stakeholder needs, wants, and expectations
• Those that are uncovered either late or not at all could require a revision to requirements that
changes or nullifies completed tasks or tasks already in progress, increasing costs and
decreasing stakeholder satisfaction
• Complexity of Stakeholder Group
− Number and variety of direct end users
− Number of interfacing business processes and automated systems
• Authority Levels For Business Analysis Work
− Which stakeholders have authority over business analysis activities for both business
analysis work and product deliverables
• Approve the deliverables
• Inspect and approve the requirements
• Request and approve changes
• Approve the requirements process that will be used
• Review and approve the traceability structure
• Veto proposed requirements or solutions (individually or in a group)
Elements of Task - Conduct Stakeholder Analysis (2)
• Attitude and Influence

− Assess stakeholder attitudes toward and influence over the initiative
− The business goals, objectives, and solution approach
• Do they believe that the solution will benefit the organisation?
• Will the benefits affect them directly?
• Will the benefits be accrued elsewhere?
• Are the possible negative effects of the initiative on this stakeholder greater than
• the rewards?
• Do they believe that the project team can successfully deliver the solution?
− Attitude towards business analysis:
• Do they see value in defining their requirements?
• Do they present solutions and expect the requirements to be contained in
• that solution, and believe that this will enable them to avoid requirements definition?
− Attitude towards collaboration:
• Have they had success on previous collaborative efforts?
• Does the organisation reward collaboration?
• Is the organisation hierarchical in nature, rather than being team-based?
• Are personal agendas the norm?
− Attitude towards the sponsor:
• On cross-functional efforts, do all the subject matter experts support the sponsor?
• Are there subject matter experts who would prefer another sponsor?
− Attitude towards team members:
• Have key members of the project team (including but not limited to the business analyst) built trusting
relationships or have there been prior failed projects or project phases involving those people?

Stakeholder Matrix
High
Work closely with stakeholder
Ensure stakeholder remains to ensure that they are in
satisfied agreement with and support
the change
Influence of
Stakeholder
Keep informed;
Monitor to ensure stakeholder is likely to be
stakeholders interest or very concerned and may
influence do not change feel anxious about lack of
control
Low
Low High
Impact on Stakeholder

Stakeholder Onion Diagram
Customers, suppliers,
regulators, and others
Affected External
Stakeholders Sponsors, executives,
domain SMEs, and
others who interact
with the affected group
Organisation or
Enterprise
End users, help desk,
and others whose work
changes when the
Affected solution is delivered
Organisational Unit
Solution Project team and others

Delivery directly involved with
creating the solution

Output of Task - Conduct Stakeholder Analysis
• Stakeholder List, Roles, and Responsibilities

− List of required roles
− Names and titles of stakeholders
− Category of stakeholder
− Location of stakeholders
− Special needs
− Number of individuals in this stakeholder role
− Description of stakeholder influence and interest
− Documentation of stakeholder authority levels

Task - Plan Business Analysis Activities
Outputs
Inputs Tasks
BA
Business Analysis
Communication
Approach
Plan
Conduct
Business Analysis BA Performance Plan Business
Stakeholder
Approach Assessment Analysis Approach
Analysis

Assessment Plan(s)
Stakeholder List, Plan BA

Organisational Plan BA Activities
Roles, and Communications
Process Assets
Responsibilities
Requirements
Plan
Plan
Requirements Manage BA
Management Performance
Process
Stakeholder List,
Roles, and
Responsibilities

Task - Plan Business Analysis Activities
• Determine the activities that must be performed and the

deliverables that must be produced
• Determine the scope of work for the business analysis
activities
• Estimate the effort required to perform that work
• Identify the management tools required to measure the
progress of those activities and deliverables

Elements of Task - Plan Business Analysis Activities
(1)
• Geographic Distribution of Stakeholders
− Consider the physical location of key stakeholders on the project
− Outsourced development project where the development team is physically located
time zones away
• Type of Project or Initiative
− Type of project or initiative will have a significant impact on the activities that need to
be performed
• Feasibility studies
• Process improvement
• Organisational change
• New software development (in-house)
• Outsourced new software development
• Software maintenance or enhancement
• Software package selection
• Business Analysis Deliverables
− List of deliverables is useful as a basis for activity identification
• Interviews or facilitated sessions with key stakeholders
• Review project documentation
• Review organisational process assets

Elements of Task - Plan Business Analysis Activities
(2)
• Determine Business Analysis Activities
− Define the scope of work and in developing estimates using work
breakdown structure (WBS)
− Activities and tasks creates Activity List

Output of Task - Plan Business Analysis Activities
• Business Analysis Plan

− Description of the scope of work, the deliverable Work
Breakdown Structure
− Activity List
− Estimates for each activity and task
− How the plan should be changed in response to changing
conditions
− Level of detail associated with the plan is determined by the
business analysis approach

Task - Plan Business Analysis Communication
Outputs
Inputs Tasks
BA
Business Analysis
Communication
Approach
Plan
Conduct
Business Analysis Business Analysis Plan Business
Stakeholder
Approach Plan(s) Analysis Approach
Analysis

Assessment Plan(s)
Stakeholder List, Plan BA

Organisational Plan BA Activities
Roles, and Communications
Process Assets
Responsibilities
Requirements
Plan
Plan
Process
Stakeholder List,
Roles, and
Responsibilities

• Business analysis communications plan describes the proposed

structure and schedule for communications regarding business
analysis activities
• Basis for setting expectations for business analysis work, meetings,
walkthroughs, and other communications
• Determine how best to receive, distribute, access, update, and
escalate information from project stakeholders
• Determine how best to communicate with each stakeholder
• Requirements should be presented in formats that are
understandable for the reviewer
• Must be clear, concise, accurate, and at the appropriate level of
detail

• Issues
− What needs to be communicated
− What is the appropriate delivery method
− Who is the appropriate audience
− When the communication should occur
• Needs and constraints relevant to communication
− Physical location/time zone of the stakeholders
− Communication approach for the stakeholder
− What types of communications will be required (e.g. status, anomalies, issues
and their resolution, risks, meeting results, action items, etc.)
− What types of requirements will be elicited (business, stakeholder, solution, or
− transition; high level vs. detailed) and how best to elicit them
− How best to communicate requirements conclusions/packages, including
authority level (signoff authority, veto authority, or review only)
− Time and resource availability constraints

Elements of Task - Plan Business Analysis
Communication (1)
• Geography
− Communications needed for a team that is collocated will be
different from communications required for a project with
geographically dispersed stakeholders
• Culture
− Cultural issues should also be taken into account when planning
communications
• Attitude to time
• Attitude to task completion
• Attitude to contracts
• Attitude to formal and informal authority

Elements of Task - Plan Business Analysis
Communication (2)
• Project Type
− Different projects will necessitate different deliverables
− Extent of documentation needed in a requirements package will vary
depending on the project
• New, customised in-house software development project
• Upgrading the technology or infrastructure of a current system
• Change in a business process or new data for an existing application
• Purchase of a software package
• Short, focused, agile style iterations of software development
• Communication Frequency
− Frequency required by various stakeholders for each type of communication
• Communications Formality
− Level of formality needed
− Varies from stakeholder to stakeholder, project phase to project phase, work
within a project phase, and requirements presentation

Outputs of Task - Plan Business Analysis
Communication
• Business Analysis Communication Plan
− How, when and why the business analyst will work directly with
stakeholders
− Stakeholder communications requirements for business analysis
activities
− Format, content, medium, level of detail
− Responsibility for collecting, distributing, accessing, and updating
information

Task - Plan Requirements Management Process
Outputs
Inputs Tasks
BA
Business Analysis
Communication
Approach
Plan
Conduct
Business Analysis Business Analysis Plan Business
Stakeholder
Approach Plan(s) Analysis Approach
Analysis

Assessment Plan(s)
Organisational Plan BA
Process Assets Plan BA Activities
Communications
Requirements
Plan
Plan
Process
Stakeholder List,
Roles, and
Responsibilities

Task - Plan Requirements Management Process
• Define the process that will be used to approve

requirements for implementation and manage changes to
the solution or requirements scope
• Process for requirements change
− Which stakeholders need to approve change
− Who will be consulted or informed of changes
− Who does not need to be involved
• Assess the need for requirements traceability and
determine which requirements attributes will be captured

Elements of Task - Plan Requirements Management
Process (1)
• Repository
− Method of storing requirements, including those under development, those under review and approved
− Process for adding, changing and deleting requirements should be consistent and clearly understood by all
• Traceability
− Determine whether and how to trace requirements
− Tracing requirements adds considerable overhead to business analysis work and must be done correctly and
consistently to have value
• Select Requirements Attributes
− Attributes provide information about requirements such as source, importance and other metadata
− Assists in efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by
potential changes, and understand the impact of a proposed change
• Reference
• Author
• Complexity
• Ownership
• Priority
• Risks
• Source
• Stability
• Status
• Urgency
• Cost
• Resource assignment
• Revision number
• Traced from
• Traced to

Elements of Task - Plan Requirements Management
Process (2)
• Requirements Prioritisation Process
− Not all requirements deliver the same value to stakeholders
− Prioritisation focuses effort on determining which requirements should be investigated first, based
on the risk, cost to deliver, benefits they will produce or other factors
− Planning requirement prioritisation ensures that stakeholders determine and understand how
requirements will be prioritised throughout and at the end of the business analysis effort
• Change Management
− Process for requesting changes
− Who will authorise changes
− Change analysis
• Tailoring the Requirements Management Process
− Requirements management process may need to be tailored to meet the needs of a specific
initiative or project
• Organisational culture
• Stakeholder preferences
• Complexity of project, project phase, or product
• Number of interfaces, business and/or system impacts or spanning a variety of functional areas
• Many components and subcomponents, have complex interfaces, will be used by a variety and number of
stakeholders or have other complexities
• Organisational maturity
• Availability of resources

Output of Task - Plan Requirements Management
Process
• Requirements Management Plan
− Approach to be taken to structure traceability
− Definition of requirements attributes to be used
− Requirements prioritisation process
− Requirements change process, including how changes will be
requested, analysed, approved, and implemented

Task - Manage Business Analysis Performance
Outputs
Inputs Tasks
BA
Business Analysis
Communication
Approach
Plan

Business Analysis Plan Business
and Performance Stakeholder
Plan(s) Analysis Approach
Metrics Analysis

Assessment Plan(s)
Organisational
Plan BA
Process Assets Plan BA Activities
Communications
Requirements
Plan
Plan
Process
Stakeholder List,
Roles, and
Responsibilities

Task - Manage Business Analysis Performance
• Determine which metrics will be used to measure the work

performed by the business analyst
• How organisational process assets governing business
analysis activities are managed and updated
− Performance metrics or expectations for business analysis work

Elements of Task - Manage Business Analysis
Performance
• Performance Measures
− Used to set expectations regarding what constitutes effective business analysis
− Measures enable the business analyst to determine when problems are
occurring that may affect the performance of business analysis or other
activities or identify opportunities for improvement
• Performance Reporting
− Written or informal and verbal
− Present to various levels of stakeholders and management
• Preventive And Corrective Action
− Assess the performance measures to determine where problems in executing
business analysis activities are occurring
− Identify opportunities for improving the business analysis process exist

Output of Task - Manage Business Analysis
Performance
• Business Analysis Performance Assessment
− Comparison of planned versus actual performance
− Understanding of root cause of variances from the plan
• Business Analysis Process Assets
− Review the process that produced those results
− Recommendations for improvement to the business analysis
process
− Incorporate into Organisational Process Assets

Elicitation - Tasks
BABOK Knowledge
Areas


Manage
Requirements
Traceability
Analysis
Maintain Assess
Prepare Define
Package Constraints
Communication

Process

Performance

Elicitation Knowledge Area
• Key task in business analysis

• Requirements serve as the foundation for the solution to the business
• Essential that the requirements be complete, clear, correct, and consistent
• Need to actively engage the stakeholders in defining requirements
• Requirements are identified throughout the elicitation, analysis, verification and
validation activities
• When initial requirements are used to build and verify model(s), gaps may be
discovered
• Techniques
− Brainstorming
− Document Analysis
− Focus Groups
− Interface Analysis
− Interviews
− Observation/Job Shadowing
− Prototyping
− Requirements Workshops
− Survey/ Questionnaire
Elicitation - Inputs and Outputs
Inputs
Tasks Outputs
Business Case Business Need
Prepare for Conduct Scheduled

Elicitation Results
Elicitation Elicitation Activity Resources
Requirements
Management Solution Scope
Plan
Document Confirm Stakeholder Supporting
Elicitation Results Elicitation Results Concerns Materials
Stakeholder List,
Organisational
Roles, and
Process Assets
Responsibilities

Task - Prepare for Elicitation
Inputs
Tasks Outputs

Elicitation Results
Requirements
Plan
Elicitation Results Elicitation Results Concerns Materials
Stakeholder List,
Organisational
Roles, and
Process Assets
Responsibilities

Task - Prepare for Elicitation
• Ensure all needed resources are organised and scheduled

for conducting the elicitation activities
• Build a detailed schedule for a particular elicitation
activity, defining the specific activities and the planned
dates

Elements of Task - Prepare for Elicitation
• Clarify the specific scope for the selected elicitation

technique and gathers any necessary supporting materials
• Schedule all resources (people, facilities, equipment)
• Notify appropriate parties of the plan
• For event-based elicitation (brainstorming, focus group,
interview, observation, prototyping, requirements
workshop) ground rules must be established
• Agree form and frequency of feedback during the
elicitation process
• Agree mechanism for verifying and signing off on the
elicited results

Output of Task - Prepare for Elicitation
• Scheduled Resources
− Includes the participants, the location in which the elicitation
activity will occur, and any other resources that may be required.
• Supporting Materials
− Materials required to help explain the techniques used or
perform them

Task - Conduct Elicitation Activity
Inputs
Business Case Business Need Tasks Outputs

Requirements Elicitation Results
Plan

Stakeholder List,
Organisational Elicitation Results Elicitation Results Concerns Materials
Roles, and
Process Assets
Responsibilities
Supporting
Materials

Task - Conduct Elicitation Activity
• Meet with stakeholder(s) to elicit information regarding their needs

• Elicitation events takes place - brainstorming, focus groups,
interviews, observation, prototyping, requirements workshops
− Event-based requirements elicitation is highly dependent on the knowledge of
the stakeholders, their willingness to participate in defining requirements, and
the group’s ability to reach consensus
− Ensure stakeholders are heard
− Clarify and possibly restate the requirements to encompass all stakeholders’
perspectives
• Elicitation is performed - document analysis, interface analysis or
distributed (survey/questionnaire)
• Ensure that the business analyst understands what information
should be elicited from the stakeholders

Elements of Task - Conduct Elicitation Activity
• Tracing Requirements
− While eliciting the requirements it is important to guard against
scope creep
− Tracing requirements back to the business goals/objectives helps
to validate whether a requirement should be included
• Capturing Requirement Attributes
− Documenting requirements attributes such as the requirement’s
source, value and priority will aid in managing each requirement
throughout its life cycle
• Metrics
− Tracking the elicitation participants and the actual time spent
eliciting the requirements provides a basis for future planning
Output of Task - Conduct Elicitation Activity
• Elicitation Results
− May include documentation appropriate to the technique and
capture the information provided by the stakeholder

Task - Document Elicitation Results
Tasks
Inputs Outputs
Prepare for Conduct
Elicitation Elicitation Activity
Elicitation Results Requirements Stakeholder

Stated Concerns
Document Confirm
Elicitation Results Elicitation Results

Task - Document Elicitation Results
• Record the information provided by stakeholders for use in

analysis
• For elicitation event (brainstorming, focus groups,
interviews, observation, prototyping, requirements
workshops) a summary of the output from the event,
including issues is produced

Elements of Task - Document Elicitation Results
• Written documents and other material

Output of Task - Document Elicitation Results
• Requirements Stated (Unconfirmed)

− Describe the stakeholder’s need from the stakeholder’s
perspective
• Stakeholder Concerns (Unconfirmed)
− Includes issues identified by the stakeholder, risks, assumptions,
constraints, and other relevant information

Task - Confirm Elicitation Results
Tasks
Inputs Outputs
Prepare for Conduct
Elicitation Elicitation Activity
Requirements Stakeholder Requirements Stakeholder

Stated Concerns Stated Concerns
(Unconfirmed) (Unconfirmed) (Confirmed) (Confirmed)
Document Confirm
Elicitation Results Elicitation Results

Task - Confirm Elicitation Results
• Validate that the stated requirements expressed by the

stakeholder match the stakeholder’s understanding of the
problem and the stakeholder’s needs

Elements of Task - Confirm Elicitation Results
• Review the documented outputs with the stakeholders to

ensure that the analyst’s understanding conforms to the
actual desires or intentions of the stakeholder

Output of Task - Confirm Elicitation Results
• Requirements Stated (Confirmed)

− Describe the stakeholder’s need from the stakeholder’s
perspective
• Stakeholder Concerns (Confirmed)
− Includes issues identified by the stakeholder, risks, assumptions,
constraints, and other relevant information

Requirements Management and Communication -
Tasks BABOK Knowledge
Areas


Manage
Requirements
Traceability
Analysis
Maintain Assess
Prepare Define
Package Constraints
Communication

Process

Performance
November 26, 2009 100

Requirements Management and Communication
Knowledge Area
• Activities and considerations for managing and expressing
requirements to a potentially broad and diverse audience
• Ensure that all stakeholders have a shared understanding of the
nature of a solution
• Ensure that those stakeholders with approval authority are in
agreement as to the requirements that the solution shall meet
• Communicating requirements helps to bring the stakeholders to a
common understanding of the requirements
• Management of requirements assists with understanding the effects
of change and linking business goals and objectives to the actual
solution that is constructed and delivered
• Over the long term, ensures that the knowledge and understanding
of the organisation gained during business analysis is available for
future use
November 26, 2009 101
Requirements Management and Communication -
Inputs and Outputs
Inputs
Tasks Outputs
Business Analysis
Communication Requirements
Plan
Manage Solution Manage
Scope and Requirements Requirements Requirements
Requirements Traceability (Approved) (Communicated)
Requirements
Requirements
Management
Structure
Plan
Maintain Prepare Requirements
Requirements for Requirements Requirements
(Maintained and
Re-use Package (Traced)
Reusable)
Stakeholder List,
Organisational
Roles, and
Process Assets
Responsibilities
Communicate Requirements
Requirements Package
Solution Scope
November 26, 2009 102

Task - Manage Solution Scope and Requirements
Tasks
Inputs Outputs
Scope and Requirements
Requirements Traceability
Requirements Requirements
Assess Proposal
Management Solution Scope (Maintained and
Solution
Plan Reusable)
Maintain Prepare
Requirements for Requirements
Re-use Package
Stakeholder,
Stakeholder List,
Solution and Allocate
Roles, and
Transition Requirements
Responsibilities
Requirements
Communicate
Requirements
November 26, 2009 103

Task - Manage Solution Scope and Requirements
• Secure approval of requirements from those stakeholders who have

the appropriate authority
• Manage issues that emerge during elicitation
• Baseline requirements after approval
• Any changes to requirements after baselining, if changes are
permitted, involves use of a change control process and subsequent
approval
• Solution scope is required as a basis for requirements management
• If business needs change during the lifetime of an initiative, the
solution scope must also change
• Changes to the solution scope may also lead to changes in previously
approved requirements that may not support the revised scope
November 26, 2009 104
Elements of Task - Manage Solution Scope and
Requirements
• Solution Scope Management
− Assess stakeholder and solution requirements to ensure that they fall within the
solution scope
• Conflict and Issue Management
− Conflicts often arise when requirements are developed and reviewed
− Conflicts that affect the requirements must be resolved before formal approval is given
to those requirements
• Presenting Requirements For Review
− Determine how requirements will be presented to various stakeholders and whether
presentations will be formal or informal
− Assess the requirements, audience, and organisational process assets to determine the
level of formality appropriate for business analysis communication
− When presenting requirements for review and approval, there needs to be enough
formality to support the methodology and ensure that the stakeholders will review,
understand, and approve them
• Approval
− Ensure that the stakeholder(s) responsible for approving requirements understands and
accepts the requirements
− Record decisions
November 26, 2009 105

Output of Task - Manage Solution Scope and
Requirements
• Requirements (Approved)
− Requirements which are agreed to by stakeholders and ready for
use in subsequent business analysis or implementation efforts
November 26, 2009 106

Task - Manage Requirements Traceability
Inputs
Tasks Outputs
Requirements
Management
Requirements
Plan
Requirements
Requirements
Management
Structure
Plan
(Maintained and
Reusable)
Stakeholder List,
Organisational
Roles, and
Process Assets
Responsibilities
Solution Scope
November 26, 2009 107

Task - Manage Requirements Traceability
• Create and maintain relationships between business objectives,

requirements and solution components
• Requirements are related to other requirements, to solution
components and to other elements such as test cases
• Tracing links business requirements to stakeholder and solution
requirements, to other artifacts produced by the team and to
solution components
• Traceability is used to help ensure solution conformance to
requirements
• Used to detect missing functionality or to identify if implemented
functionality is not supported by a specific requirement
• When a requirement is changed, the business analyst can easily
review all of the related requirements and software components in
order to understand the impact of the change
November 26, 2009 108
Elements of Task - Manage Requirements
Traceability
• Relationships
− Records the dependencies and relationships for each of the requirements
− Dependencies and relationships between requirements helps when
determining the sequence in which requirements are to be addressed
• Impact Analysis
− Evaluate the impact of a change
− When a requirement changes, its relationships to other requirements or
system components can be reviewed
− Allows decision makers evaluate options with facts
• Configuration Management System
− Requirements management tool is generally needed to trace large numbers of
requirements
November 26, 2009 109

Output of Task - Manage Requirements Traceability
• Requirements traceability matrix showing requirements’

relationships to other requirements within the solution
scope such that it is relatively easy to identify the effects
on other requirements of a change
November 26, 2009 110

Task - Maintain Requirements for Re-use
Inputs
Tasks Outputs
Business Analysis
Plan
Requirements
Requirements
Management
Structure
Plan
(Maintained and
Reusable)
Stakeholder List,
Organisational
Roles, and
Process Assets
Responsibilities
Solution Scope
November 26, 2009 111

Task - Maintain Requirements for Re-use
• Manage knowledge of requirements following their

implementation
• Identify requirements that have the potential for long-
term usage by the organisation
• To facilitate re-use requirements must be clearly named
and defined and easily available
• Maintenance of requirements assists in impact analysis of
changes and reduces analysis time and effort
November 26, 2009 112

Elements of Task - Maintain Requirements for Re-
use
• Ongoing Requirements
− Requirements that an organisational unit is required to be able to
meet on a continuous basis
• Contractual obligations
• Quality standards
• Service level agreements
• Business rules
• Business processes
• Satisfied Requirements
November 26, 2009 113

Output of Task - Maintain Requirements for Re-use
• Requirements expressed in a form that makes them

suitable for long-term use by the organisation
• Unapproved requirements can be maintained for possible
future initiatives
November 26, 2009 114

Task - Prepare Requirements Package
Inputs
Tasks Outputs
Business Analysis
Plan
Requirements
Requirements
Management
Structure
Plan
(Maintained and
Reusable)
Stakeholder List,
Organisational
Roles, and
Process Assets
Responsibilities
Solution Scope
November 26, 2009 115

Task - Prepare Requirements Package
• Primary objective requirements package is to convey information

clearly and in an understandable fashion
• Create set of requirements to ensure that they are effectively
communicated to, understood by, and usable by stakeholders
− Requirements Specification
− Presentation Material
− Process Models and Maps
• Requirements package should support subsequent phases of
initiative activities and deliverables
• Misunderstandings will adversely affect initiative implementation,
leading to re-work and cost overruns, especially if gaps are
discovered late in the process
November 26, 2009 116

Elements of Task - Prepare Requirements Package
• Work Products and Deliverables

− Meeting agendas and minutes
− Interview questions and notes
− Facilitation session agendas and notes
− Issues log
− Work plans
− Status reports
− Presentation slides used during the project
− Traceability matrices
• Format
− Depends on initiatives and requirements
− Select the most appropriate formats to present the material to convey an
effective message to those participating in the requirements review process
− If the purpose of the package is to obtain formal approval, the requirements
documentation should be complete in order to prepare the requirements
package
November 26, 2009 117

Output of Task - Prepare Requirements Package
• A requirements document, presentation or package of

requirements ready to be reviewed by stakeholders
• Package can contain all of the project requirements or can
be broken into several sub-packages
November 26, 2009 118

Task - Communicate Requirements
Tasks Outputs
Inputs
Business Analysis
Plan
(Maintained and
Reusable)
Requirements
Package
November 26, 2009 119

Task - Communicate Requirements
• Communicating requirements is needed to ensure

stakeholders have a common understanding of
requirements
• Includes conversations, notes, documents, presentations,
• and discussions
• Concise, appropriate, effective communication requires
that the business analyst possess hard and soft
communication skills
November 26, 2009 120

Elements of Task - Communicate Requirements
• General Communication
− Requirements communication is performed iteratively
− Requirements communication can lead to elicitation of additional requirements
• Enterprise Analysis Tasks - Business case and solution scoping information is
• communicated
• Elicitation Tasks - Communication of requirements may be useful during elicitation activities to help
stakeholders identify other related requirements
• Requirements Analysis Tasks - Requirements are refined, modified, clarified and finalised through
effective communication
• Solution Assessment and Validation Tasks - Assessments of the solution, allocation of requirements
to solution components, organisational readiness, and transition requirements all must be
communicated
• Presentations
− Formal or informal - based on by the objective of the communication and the audience needs
• Ensure that internal project quality standards have been adhered to
• Ensure cross-functional fit with other business process areas within the same initiative
• Obtain business acceptance and sign-off..
• Obtain delivery team sign-off..
• Obtain testing team sign-off..
• Examine solution options with a delivery team
• Prioritise a set of requirements before proceeding to next project stage
• Make decisions regarding solution scope
November 26, 2009 121

Output of Task - Communicate Requirements
• Communicated requirements understood by stakeholders

- what the requirements are and their current state
November 26, 2009 122

Enterprise Analysis Knowledge Area
BABOK Knowledge
Areas


Manage
Requirements
Traceability
Analysis
Maintain Assess
Prepare Define
Package Constraints
Communication

Process

Performance
November 26, 2009 123

Enterprise Analysis Knowledge Area
• Business analysis activities necessary to identify a business need, problem, or

opportunity, define the nature of a solution that meets that need, and justify the
investment necessary to deliver that solution
• Analyse the business situation in order to fully understand business problems and
opportunities
• Assess the capabilities of the organisation to understand the change needed to
meet business needs and achieve strategic goals
• Determine the most feasible business solution approach
• Define the solution scope and develop the business case for a proposed solution
• Define and document business requirements (including the business need,
required capabilities, solution scope, and business case)
November 26, 2009 124

Enterprise Analysis - Inputs and Outputs
Inputs
Tasks Outputs
Assumptions and Business Goals
Constraints and Objectives
Define Business Assess Capability

Need Gaps Business Case Business Need
Enterprise Organisational
Architecture Process Assets
Determine
Define Solution Required Solution
Solution
Scope Capabilities Approach
Approach
Solution
Requirements
Performance
(Stated)
Assessment
Define Business
Solution Scope
Case
Stakeholder
Concerns
November 26, 2009 125

Task - Define Business Need
Inputs
Tasks Outputs
Assumptions and Business Goals
Constraints and Objectives

Enterprise Organisational
Architecture Process Assets
Determine
Solution
Approach
Solution
Requirements
Performance
(Stated)
Assessment
Define Business
Solution Scope
Case
Stakeholder
Concerns
November 26, 2009 126

Task - Define Business Need
• Business need defines the problem that the business analyst is trying to find a
solution for
• High-level statement of issue
• Used to determine which alternative solutions will be considered, which
stakeholders will be consulted, and which solution approaches will be evaluated
• New business needs can arise in a number of different ways:
− From the top down - the need to achieve a strategic goal
− From the bottom up - a problem with the current state of a process, function or system
− From business management - a manager needs additional information to make sound
decisions or must perform additional functions to meet business objectives
− From external drivers - driven by customer demand or business competition in the
marketplace
• Frequently organisations act to resolve an issue without investigating the
underlying business need
• Question the assumptions and constraints that are generally buried in the
statement of the business need/issue to ensure that the correct problem is being
solved and the widest possible range of alternative solutions are considered
November 26, 2009 127
Elements of Task - Define Business Need (1)
• Business Goals and Objectives

− Describes the ends that the organisation is seeking to achieve
− Longer-term, ongoing, and qualitative statements of a state or condition
that the organisation is seeking to establish and maintain
− Describe briefly
• Specific – describing something that has an observable outcome
• Measurable – tracking and measuring the outcome
• Achievable – testing the feasibility of the effort
• Relevant – in alignment with the organisation’s key vision, mission, goals
• Time-bounded – the objective has a defined timeframe that is consistent with
the business need
• Business Problem or Opportunity
− Adverse impacts the problem is causing
− Define expected benefits from any potential solution
− How quickly the problem could potentially be resolved and the cost of
doing nothing.
− Underlying source of the problem
November 26, 2009 128

Elements of Task - Define Business Need (2)
• Desired Outcome
− Not a complete defined solution
− Describes the business benefits that will result from meeting the
business need and the end state desired by stakeholders
− Proposed solutions must be evaluated against desired outcomes
to ensure that they can deliver those outcomes
− Desired outcomes should address a problem or opportunity and
support the business goals and objectives
November 26, 2009 129

Output of Task - Define Business Need
• Business need describes a problem that the organisation is

(or is likely to) face or an opportunity that it has not taken,
and the desired outcome
• Guides the identification and definition of possible
solutions
November 26, 2009 130

Task - Assess Capability Gaps
Tasks Outputs
Inputs
Enterprise
Business Need
Architecture
Determine
Solution
Approach
Solution
Performance
Assessment
Define Business
Solution Scope
Case
November 26, 2009 131

Task - Assess Capability Gaps
• Identify new capabilities required by the enterprise to meet the business need
• Assess the current capabilities of the organisation and identify the gaps that
prevent it from meeting business needs and achieving desired outcomes
• Determine if the organisation can meet the business need using its existing
structure, people, processes, and technology
• May be needed to launch a project to create capability
• Change may be needed to the organisation
− Business processes
− Functions
− Lines of business
− Organisation structure
− Staff competencies, knowledge and skills, training
− Facilities
− Locations
− Data and information
− Application systems
− Technology infrastructure
November 26, 2009 132
Elements of Task - Assess Capability Gaps
• Current Capability Analysis

− Gather enterprise architecture information about the current state of the
areas of the organisation affected by the business need
− Assess against the desired objectives to determine whether the
organisation currently has the capability to meet the business need
• Assessment of New Capability Requirements
− If current capabilities are insufficient to meet the business need, identify
the capabilities that need to be added
− Develop the models and other descriptive information about the future
vision and describe the future state of the organisation
− Identify gaps in organisational capabilities that need to be filled to support
the business vision, strategy, goals and objectives
• Assumptions
− Can be difficult to prove that the delivery of a new capability will meet a
business need
− Identify assumptions and ensure they are clearly understood so that
appropriate decisions can be made if the assumption later proves invalid
November 26, 2009 133

Output of Task - Assess Capability Gaps
• An understanding of the current capabilities of the

organisation and the new capabilities (processes, staff,
features in an application, etc.) that may be required to
meet the business need
November 26, 2009 134

Task - Determine Solution Approach
Tasks Outputs
Inputs
Organisational
Business Need
Process Assets
Determine
Solution
Approach
Required
Capabilities
Define Business
Solution Scope
Case
November 26, 2009 135

Task - Determine Solution Approach
• Determine the most viable solution approach to meet the business

need in enough detail to allow for definition of solution scope and
prepare the business case
• Describes the general approach that will be taken to create or
acquire the new capabilities required to meet the business need
• Identify possible approaches, determine the means by which the
solution may be delivered (including the methodology and lifecycle
to be used) and assess whether the organisation is capable of
implementing and effectively using a solution
− Utilise additional capabilities of existing software/hardware that already is
available within the organisation
− Purchase or lease software/hardware
− Design and develop custom software
− Add resources to the business or make organisational changes
− Change the business procedures/processes
− Partner with other organisations, or outsource work to suppliers
November 26, 2009 136

Elements of Task - Determine Solution Approach
• Alternative Generation
− Identify potential options as possible to meet the business objectives and
fill identified gaps in capabilities
− Include the option of doing nothing as well as investigating interim
solutions alternatives that may allow the organisation to buy time
• Assumptions and Constraints
− Assumptions may affect the chosen solution should be identified
− Question assumptions and constraints to ensure that they are valid
• Ranking and Selection of Approaches
− Analyse the operational, economic, technical, schedule-based,
organisational, cultural, legal and marketing feasibility
− Capture consistent information for each option to make comparison easier
and review to ensure accuracy and completeness
− Used weighted scoring to reflect relative importance of objectives
November 26, 2009 137

Output of Task - Determine Solution Approach
• Description of the solution approach that will be taken to

implement a new set of capabilities
• Solution approaches describe the types of solution
components that will be delivered (new processes, a new
software application, etc.)
• May also describe the methodology and approach that will
be used to deliver those components
November 26, 2009 138

Task - Define Solution Scope
Tasks Outputs
Inputs
Assumptions and
Business Need
Constraints
Determine
Solution
Approach
Required Solution
Capabilities Approach
Define Business
Solution Scope
Case
November 26, 2009 139

Task - Define Solution Scope
• Define which new capabilities a project or iteration will deliver

• Conceptualise the recommended solution in sufficient detail to
enable stakeholders to understand which new business capabilities
an initiative will deliver
• Solution scope will change throughout a project, based on changes
in the business environment or as the project scope is changed to
meet budget, time, quality, or other constraints
− The scope of analysis (the organisational unit or process for which
requirements are being developed) that provides the context in which the
solution is implemented
− The capabilities supported by solution components, such as business
processes, organisational units, and software applications
− The capabilities to be supported by individual releases or iterations
− The enabling capabilities that are required in order for the organisation to
develop the capabilities required to meet the business need.
November 26, 2009 140

Elements of Task - Define Solution Scope
• Solution Scope Definition

− Describe solution in terms of the major features and functions
− Detail solution interactions with people and systems outside of its scope
− Define the business units that will be involved
− Describe business processes to be improved or redesigned, process
owners, and IT systems and other technology that will likely be affected
• Implementation Approach
− Describe how the chosen solution approach will deliver the solution scope
− Describe the implementation approach
− Provide a roadmap that indicates the timeframe in which a capability can
be expected
• Dependencies
− Define major business and technical dependencies that will impose
constraints to the effort to deploy the solution, including dependencies
that may exist between solution components
November 26, 2009 141
Output of Task - Define Solution Scope
• Solution scope that defines what must be delivered in

order to meet the business need
• The effect of the proposed change initiative on the
business and technology operations and infrastructure
November 26, 2009 142

Task - Define Business Case
Tasks Outputs
Inputs
Assumptions and
Business Need
Constraints
Determine
Solution
Approach
Stakeholder
Solution Scope
Concerns
Define Business
Solution Scope
Case
November 26, 2009 143

Task - Define Business Case
• Determines if the organisation can justify the investment required to

deliver a proposed solution
• Describes the justification for the project in terms of the value to be
added to the organisation as a result of the deployed solution when
compared to the cost to develop and operate the solution
• Defines how the initiative is expected to achieve organisation
objectives
• Lists the constraints associated with the proposed project
• Defines the estimated budget and expected cash flow
• Describes alignment with strategies established by the organisation
• Lists the methods and rationale that were used for quantifying
benefits and costs
• States assumptions
November 26, 2009 144
Elements of Task - Define Business Case
• Benefits
− Estimates the benefits to the organisation of the recommended solution in terms of both
qualitative and quantitative gains
− Non-financial benefits such as improved staff morale, increased flexibility to respond to
change, improved customer satisfaction, or reduced exposure to risk should be stated with
care
− Benefits should relate back to strategic goals and objectives
• Costs
− Estimate of the total net cost of the solution
− Total cost of ownership to support the new solution and consequential costs incurred by
others
• Risk Assessment
− Determine if the proposed initiative carries more risk than the organisation is willing to
tolerate
• Solution feasibility risks
• Technical risks
• Financial risks
• Business change and organisational risks
• Results Measurement
− Defines how those costs and benefits will be assessed and evaluated
November 26, 2009 145

Output of Task - Define Business Case
• Presents the information necessary to support a go/no go

decision to invest and move forward with a proposed
project
November 26, 2009 146

Requirements Analysis Knowledge Area
BABOK Knowledge
Areas


Manage
Requirements
Traceability
Analysis
Maintain Assess
Prepare Define
Package Constraints
Communication

Process

Performance
November 26, 2009 147

Requirements Analysis - Inputs and Outputs
Inputs
Tasks Outputs
Prioritise Organise Assumptions and Requirements

Requirements Requirements Constraints Structure
Organisational
Requirements
Process Assets
Specify and Define Requirements Requirements

Model Assumptions and (Prioritised) (Validated)
Requirements Constraints
Requirements
Stakeholder
Management
Concerns
Plan
Stakeholder,
Verify Validate Requirements Solution and
Requirements Requirements (Verified) Transition
Requirements
Stakeholder List,
Roles and Solution Scope
Responsibilities
November 26, 2009 148

Task - Prioritise Requirements
Inputs
Tasks Outputs

Organisational
Requirements
Process Assets

Requirements
Stakeholder
Management
Concerns
Plan
Stakeholder,
Requirements
Stakeholder List,
Responsibilities
November 26, 2009 149

Task - Prioritise Requirements
• Ensures that analysis and implementation efforts focus on

the most critical requirements
• Decision process used to determine the relative
importance of requirements
• Importance can be based on their relative value, risk,
difficulty of implementation, or on other criteria
• Priorities used to determine which requirements should be
targetted for further analysis and to determine which
requirements should be implemented first
November 26, 2009 150

Elements of Task - Prioritise Requirements (1)
• Basis for Prioritisation

− Business Value - based on cost-benefit analysis of their relative value to the
organisation
− Business or Technical Risk – based on the highest risk of project failure
− Implementation Difficulty - selects requirements that are easiest to
implement first
− Likelihood of Success – focus on the requirements that are likely to
produce quick and relatively certain successes
− Regulatory or Policy Compliance - prioritises requirements that must be
implemented in order to meet regulatory or policy demands imposed on
the organisation
− Relationship to Other Requirements - not of high value but may support
other high-priority requirements and therefore may be a candidate for
early implementation
− Stakeholder Agreement - Consensus on which requirements are most
useful or valuable
− Urgency – prioritise requirements based on time sensitivity
November 26, 2009 151

Elements of Task - Prioritise Requirements (2)
• Challenges
− Non-Negotiable Demands - stakeholders attempt to avoid
difficult choices, fail to recognise the necessity for making
tradeoffs, or desire to rank all requirements as high priority
− Unrealistic Tradeoffs - solution implementation team may
intentionally or unintentionally try to influence the result of
the prioritisation process by overestimating the difficulty or
complexity of implementing certain requirements
November 26, 2009 152

Output of Task - Prioritise Requirements
• Set of prioritised requirements has an attribute that

describes its relative importance to stakeholders and the
organisation
• Each requirement should have an assigned priority. The
priorities may apply to a requirement or to a group or
related requirements
November 26, 2009 153

Task - Organise Requirements
Inputs
Tasks Outputs

Organisational
Requirements
Process Assets

Requirements
Stakeholder
Management
Concerns
Plan
Stakeholder,
Requirements
Stakeholder List,
Responsibilities
November 26, 2009 154

Task - Organise Requirements
• Create a set of views of the requirements for the new

business solution that are comprehensive, complete,
consistent, and understood from all stakeholder
perspectives
• Relationships and interdependencies among requirements
adds complexity
• Organised requirements needs to clearly depict the
inherent relationships between requirements
November 26, 2009 155

Elements of Task - Organise Requirements
• Levels of Abstraction
− Requirements can be articulated at different levels of abstraction
− Described as what needs to be done
− Express at whatever level of abstraction is appropriate for the audience
− Requirements tools can also determine the level of abstraction used when defining
requirements
• Model Selection
− Determine the types of models required to describe the solution scope and meet
the informational needs of stakeholders
− Objective of developing a model is to simplify reality in a way that is useful
− Usually necessary to develop multiple models using different modelling techniques
to completely analyse and document requirements
• User Classes, Profiles, or Roles - categorise and describe the roles that directly interact
with a solution
• Concepts and Relationships - define the objects, entities or facts that are relevant to the
business domain and what relationships they have with other concepts
• Events
• Processes - sequence of repeatable activities executed within an organisation
• Rules - enforce goals and guide decision-making
November 26, 2009 156

Output of Task - Organise Requirements
• Organised structure for the requirements and a

documented set of relationships between them
November 26, 2009 157

Task - Specify and Model Requirements
Tasks Outputs

Inputs
Requirements Requirements Specify and Define Requirements Requirements

(Stated) Structure Model Assumptions and (Prioritised) (Validated)
Stakeholder,
Requirements
November 26, 2009 158

Task - Specify and Model Requirements
• Analyse expressed stakeholder desires and/or the current

state of the organisation using a combination of textual
statements, matrices, diagrams and formal models
• Create specifications and models to analyse the
functioning of an organisation and provide insight into
opportunities for improvement
• Facilitate development and implementation of solutions,
facilitating communication among stakeholders,
supporting training activities and knowledge management,
and ensuring compliance with contracts and regulations
November 26, 2009 159

Elements of Task - Specify and Model Requirements
• Text
− Describe the capabilities of the solution, any conditions that must exist for the requirement
to operate, and any constraints that may prevent the solution from fulfilling the requirement
• Matrix Documentation
− Tabular representation of information in a uniform structure that can be broken down into
elements that applies to every entry in the table
• Models
− Graphical simplified representation of a complex reality
− Formal models use modelling standards (UML)
• Capture Requirements Attributes
− As each requirement is specified and modelled, the required and relevant attributes are
captured
• Improvement Opportunities
− Identify opportunities to improve the operation of the initiative
• Automate Or Simplify The Work
• Improve Access To Information
• Reduce Complexity Of Interfaces
• Increase Consistency Of Behaviour
• Eliminate Redundancy
November 26, 2009 160

Output of Task - Specify and Model Requirements
• Requirements analysed, modelled and specified
November 26, 2009 161

Task - Define Assumptions and Constraints
Inputs
Tasks Outputs

Organisational
Requirements
Process Assets

Requirements
Stakeholder
Management
Concerns
Plan
Stakeholder,
Requirements
Stakeholder List,
Responsibilities
November 26, 2009 162

Task - Define Assumptions and Constraints
• Assumptions are factors that are believed to be true but

have not been confirmed
• Identify and document assumptions, confirm their
accuracy, and identify and manage risks related to the
ability of a solution to meet the business need
• Constraints are defined as restrictions or limitations on
possible solutions - aspects of the current or planned
future state that may not be changed
• Document any restrictions or limitations to the solution
design, construction, testing, validation and deployment
November 26, 2009 163

Elements of Task - Define Assumptions and
Constraints
• Assumptions
− Anything that is believed to be true but that has not actually been verified
− Source of potential project risk
− May also reflect an understanding of how desired outcomes are likely to be
achieved
• Business Constraints
− Limitations on available solutions, or an aspect of the current state that
cannot be changed by the deployment of the new solution
− Examine to ensure that they are accurate and justified
• Technical Constraints
− Architecture decisions and limitations that are made that may impact the
design of the solution
− May create a situation where a requirement cannot be met using the
current solution approach or by a solution component
November 26, 2009 164

Output of Task - Define Assumptions and
Constraints
• Documented and verified assumptions and constraints
• Assumptions and constraints will limit potential solution
options and will be monitored for potential changes
• While they are not technically requirements, they can be
managed and communicated in a similar manner
November 26, 2009 165

Task - Verify Requirements
Inputs
Tasks Outputs

Organisational
Requirements
Process Assets

Requirements
Stakeholder
Management
Concerns
Plan
Stakeholder,
Requirements
Stakeholder List,
Responsibilities
November 26, 2009 166

Task - Verify Requirements
• Ensure that requirements specifications and models meet

the necessary standard of quality to allow them to be used
effectively to guide further work
• Requirements that do not meet quality standards are
defective and must be revised
• Final check by the business analyst and key stakeholders to
determine that the requirements are:
− Ready for formal review and validation
− Provide all the information needed for further work based on the
requirements to be performed
November 26, 2009 167

Elements of Task - Verify Requirements
• Requirements Quality
− Cohesive - support the overall initiative purpose and scope
− Complete - represents all relevant requirements with each requirement self-
contained without any missing information
− Consistent - do not contradict each other or describe the same requirement using
different wording and with the same level of detail
− Correct - defects in requirements will lead to defects in the resulting solution
− Feasible - requirements must be implementable within the existing infrastructure,
with the existing budget, timeline and resources available
− Modifiable - grouped in order to be modifiable
− Unambiguous - must not allow for multiple divergent valid interpretations
− Testable - must be a way to prove that a requirement has been fulfilled
• Verification Activities
− Check for completeness
− Ensure all triggers and outcomes have been accounted for
− Check for consistency across all requirements models and representations
− Ensure the terminology used in expressing the requirement is understandable to
stakeholders and consistent with the use of those terms within the organisation
November 26, 2009 168

Output of Task - Verify Requirements
• Verified requirements are of sufficient quality to allow

further work based on those requirements to be
performed
November 26, 2009 169

Task - Validate Requirements
Tasks Outputs

Inputs
Stakeholder,
Solution and Specify and Define Requirements Requirements
Business Case Model Assumptions and
Transition (Prioritised) (Validated)
Requirements Requirements Constraints
Verify Validate Stakeholder and

Requirements
Requirements Requirements Solution
(Verified)
Requirements
November 26, 2009 170

Task - Validate Requirements
• Ensure all requirements support the delivery of value to

the business, fulfill its goals and objectives, and meet a
stakeholder need
• Ongoing process to ensure that stakeholder, solution, and
transition requirements align to the business requirements
• Stakeholders will have different, conflicting needs and
expectations that may be exposed through the validation
process and will need to be reconciled
November 26, 2009 171

Elements of Task - Validate Requirements (1)
• Identify Assumptions
− May not be possible to prove that implementation of the requirement will result in the
desired benefit
− May be necessary to make assumptions as there are no similar previous experiences to rely
on
− Assumptions need to be identified and defined so that associated risks can be managed
• Define Measurable Evaluation Criteria
− After defining the benefits that will result from the implementation of a requirement, define
the evaluation criteria that will be used to evaluate how successful the resulting change has
been after the solution is deployed
• Determine Business Value
− Assess individual requirements (and associated implementation features) to determine if
they deliver business value
− Requirements that do not deliver direct or indirect value are strong candidates for
elimination
− Business value can be delivered through requirements
− that support compliance with regulatory or other standards, alignment with internal
− standards or policies of the organisation, or increased satisfaction for stakeholders, even
− if those things do not have a direct measurable financial benefit
November 26, 2009 172

Elements of Task - Validate Requirements (2)
• Determine Dependencies for Benefits Realisation

− Not all requirements contribute directly to the end result desired by the
organisation and described in the business case
• Evaluate Alignment with Business Case and Opportunity Cost
− Each requirement must be traceable to the objectives in the business case
and should minimise the opportunity cost of implementation
− Requirement that are not aligned with the business case should be defined
and approved in a separate business case or considered for removal from
the solution scope
− Opportunity cost refers to the benefits that could have been achieved with
an alternative investment
November 26, 2009 173

Output of Task - Validate Requirements
• Validated requirements are those that can be

demonstrated to deliver value to stakeholders and are
aligned with the business goals and objectives
• If a requirement cannot be validated, it does not benefit
the organisation or it does not fall within the solution
scope, or both
November 26, 2009 174

Solution Assessment and Validation Knowledge Area
BABOK Knowledge
Areas


Manage
Requirements
Traceability
Analysis
Maintain Assess
Prepare Define
Package Constraints
Communication

Process

Performance
November 26, 2009 175

Solution Assessment and Validation - Inputs and
Outputs Outputs
Inputs
Tasks
Assessment of
Assumptions and Enterprise
Proposed Identified Defects
Constraints Architecture
Solution
Assess Proposed Allocate
Solution Requirements
Solution
Requirements Organisational
(Constructed, Mitigating
(Prioritised and Readiness
Deployed or Actions
Approved) Assessment
Designed)
Assess
Define Transition
Organisational
Requirements
Readiness
Solution
Solution Requirements Transition
Performance
Options(s) (Allocated) Requirements
Metrics
Evaluate Solution
Validate Solution
Performance
Solution Solution
Stakeholder
Solution Scope Performance Validation
Concerns
Assessment Assessment
November 26, 2009 176

Task - Assess Proposed Solution
Inputs
Tasks
Assessment of
Solution
Solution
(Constructed, Mitigating
Deployed or Actions
Designed)
Assess
Define Transition
Organisational
Requirements
Readiness
Solution
Performance
Metrics
Evaluate Solution
Validate Solution
Performance
Solution Solution
Stakeholder
Concerns
November 26, 2009 177

Task - Assess Proposed Solution
• Assess proposed solutions in order to determine how

closely they meet stakeholder and solution requirements
• Determine if the solution delivers enough business value
to justify its implementation
November 26, 2009 178

Elements of Task - Assess Proposed Solution
• Ranking of Solution Options

− Define solution scoring criteria – simple or complex
− Assess and score solutions against criteria
− Top-rated solution or solutions are then investigated in
greater detail
• Identification of Additional Potential Capabilities
− Solution options may offer capabilities to the organisation
above and beyond those identified in the requirements or
the original business case
− Determine if these capabilities are of immediate value or
have the potential to provide future value
November 26, 2009 179

Output of Task - Assess Proposed Solution
• Assess the value delivered by each proposed solution

• If multiple options are available, a recommendation of the
best solution should be made.
• A recommendation to terminate the initiative may be
given if no solution delivers enough value to justify being
implemented
November 26, 2009 180

Task - Allocate Requirements
Inputs
Tasks
Assessment of
Solution
Solution Mitigating
(Designed) Actions
Assess
Define Transition
Organisational
Requirements
Readiness
Solution
Requirements Transition
Solution Options Performance
(Allocated) Requirements
Metrics
Evaluate Solution
Validate Solution
Performance
Solution Solution
Stakeholder
Concerns
November 26, 2009 181

Task - Allocate Requirements
• Allocate stakeholder and solution requirements among

solution components and releases in order to maximise
the business value given the options and alternatives
generated by the design team
• Allocation is supported by assessing the tradeoffs between
alternatives in order to maximise benefits and minimise
costs
• Business value of a solution changes depending on how
requirements are implemented
November 26, 2009 182

Elements of Task - Allocate Requirements
• Solution Components
− Business solutions generally consist of multiple components
− Each component implements a subset of the requirements
− Allocation of requirements to solution components is a primary driver of
the cost to implement the solution and the benefits delivered by it
• Release Planning
− Plan decisions about which requirements will be included in each
solution release/phase/iteration
− Ensure all parties understand the consequences to the organisation
based on the planned schedule of releases and identify the solution
capabilities that will deliver the greatest business value
− Understand organisational restraints or policies that must be adhered
to in any implementation, including constraints such as freeze periods
for implementation, general company policies, and any phased-in
activities
November 26, 2009 183

Output of Task - Allocate Requirements
• Requirements are allocated and associated with a solution

component that will implement them
November 26, 2009 184

Task - Assess Organisational Readiness
Inputs
Tasks
Assessment of
Solution
Solution Mitigating
(Designed) Actions
Assess
Define Transition
Organisational
Requirements
Readiness
Solution
Performance
Metrics
Evaluate Solution
Validate Solution
Performance
Solution Solution
Stakeholder
Concerns
November 26, 2009 185

Task - Assess Organisational Readiness
• Assess whether the organisation is ready to make effective

use of a new solution
• Describe the effect the new solution will have on an
organisation and whether the organisation is prepared for
the change that the solution implementation will cause
• Understand what changes will occur in the organisation
area, technical infrastructure or processes and how these
affect other organisation units or operations
November 26, 2009 186

Elements of Task - Assess Organisational Readiness
• Cultural Assessment
− Determine whether stakeholder groups genuinely want the change to be successful
− Assess the attitudes of key stakeholder groups and their willingness to accept
change
− Determine if stakeholders understand the reasons that a new solution is being
implemented
− Determine if stakeholders view that solution as something that will be beneficial
and if they understand the reasons why a new solution is required
• Operational or Technical Assessment
− Determine if the organisation is able to take advantage of the capabilities provided
by the new solution
− Evaluate whether stakeholders are prepared to make use of the new solution
− Determine if training has been performed, whether new policies and procedures
have been defined, whether IT systems required to support it are in place, and
whether the solution is capable of performing at a required level
• Stakeholder Impact Analysis
− How change will affect stakeholder groups
November 26, 2009 187

Output of Task - Assess Organisational Readiness
• Organisational readiness assessment specifying whether

stakeholders are prepared to accept the change associated
with a solution and are able to use it effectively
• May lead to revisions in solution or project scope
November 26, 2009 188

Task - Define Transition Requirements
Tasks
Assessment of
Inputs Solution
Organisational
Readiness Mitigating
(Stated) Readiness
Assessment Actions
Assessment
Assess
Define Transition
Organisational
Requirements
Readiness
Solution Solution Requirements Transition
(Deployed) (Designed) (Allocated) Requirements
Evaluate Solution
Validate Solution
Performance
Solution Solution
Performance Validation
November 26, 2009 189

Task - Define Transition Requirements
• Define requirements for capabilities needed to transition

from an existing solution to a new solution
• During the transition period the orgamisation may need to
operate both solutions in parallel
• Transition requirements are elicited, analysed, managed,
and communicated by performing the same tasks as for
other requirements
November 26, 2009 190

Elements of Task - Define Transition Requirements
• Data
− Data used by the old solution may need to be transferred or archived
− Rules for conversion will need to be developed, and business rules may
need to be defined to ensure that the new solution interprets the
converted data correctly
• Ongoing Work
− Will work will be ongoing in the old version of the solution at the time the
new version is implemented
− Evaluate options for managing this ongoing work such as finishing existing
work using the current solution and starting new work in the new solution,
holding the processing of new work for a period of time, or converting all
work at the time of implementation
• Organisational Change
− Process for managing the people side of change related to the solution
November 26, 2009 191
Output of Task - Define Transition Requirements
• Transition requirements define the capabilities that must

be developed in order for the organisation to successfully
transition between solutions
• Transition requirements must be verified, validated,
managed and communicated
November 26, 2009 192

Task - Validate Solution
Inputs
Tasks
Assessment of
Solution
Solution Mitigating
(Constructed) Actions
Assess
Define Transition
Organisational
Requirements
Readiness
Solution
Performance
Metrics
Evaluate Solution
Validate Solution
Performance
Solution Solution
Stakeholder
Concerns
November 26, 2009 193

Task - Validate Solution
• Validate that a solution meets the business need and

determine the most appropriate response to identified
defects
• Ensure the delivered solution meets the business needs on
an ongoing basis
• Problems that are identified through solution validation
will be reported and prioritised for resolution
November 26, 2009 194

Elements of Task - Validate Solution
• Investigate Defective Solution Outputs

− Identify defects in a solution or solution component by
looking at cases where the outputs from the solution are
below an acceptable level of quality
• Assess Defects and Issues
− Identified defects are reviewed to assess the effect that they
will have on the operation of the organisation
− Determine the severity of the defect, the probability of the
occurrence of the defect, the severity of the business impact,
and the capacity of the business to absorb the impact of the
defects
November 26, 2009 195

Output of Task - Validate Solution
• Known problems that exist in the solution
November 26, 2009 196

Task - Evaluate Solution Performance
Inputs
Tasks
Assessment of
Enterprise
Identified Defects Proposed Identified Defects
Architecture
Solution
Solution Mitigating
(Deployed) Actions
Assess
Define Transition
Organisational
Requirements
Readiness
Solution
Performance
Metrics
Evaluate Solution
Validate Solution
Performance
Solution Solution
Stakeholder
Concerns
November 26, 2009 197

Task - Evaluate Solution Performance
• Evaluate functioning solution to understand the value they

deliver and identify opportunities for improvement
• Investigate how a solution is actually used after it is
deployed, and assessing the effect it has had, both positive
and negative
• Post-implementation assessment when performed
immediately following the completion of a project
November 26, 2009 198

Elements of Task - Evaluate Solution Performance
• Understand Value Delivered By Solution

− Gather the metrics that describe the performance of the solution
− Over or under-performance against targets may be investigated to identify
a root cause and determine an appropriate response
− Over-performance may indicate that resources devoted to the solution can
beused elsewhere, or that the value of the solution to the business was
underestimated
• Validate Solution Metrics
− Ensure that business goals and objectives are aligned to the solution
metrics
− Identify and define appropriate metrics
• Solution Replacement or Elimination
− Is it necessary to consider the replacement of a solution or solution
component because:
• Reached the end of its useful life, services are being insourced or outsourced,
the solution is not fulfilling the business goals
November 26, 2009 199

Output of Task - Evaluate Solution Performance
• Solution performance assessment that escribes how the

solution is performing in relation to business goals and
objectives
November 26, 2009 200

BABOK Knowledge Areas and Tasks
BABOK Knowledge
Areas


Manage
Requirements
Traceability
Analysis
Maintain Assess
Prepare Define
Package Constraints
Communication

Process

Performance
November 26, 2009 201

Underlying Competencies
BABOK Knowledge
Areas
Underlying
Competencies
Analytical
Behavioural Business Communication Software
Thinking and Interaction Skills
Characteristics Knowledge Skills Applications
Problem Solving
Business
Verbal Facilitation and General-Purpose
Creative Thinking Ethics Principles and
Communications Negotiation Applications
Practices
Personal Industry Leadership and Specialised

Decision Making Teaching
Organisation Knowledge Influencing Applications
Organisation Written
Learning Trustworthiness Teamwork
Knowledge Communications
Solution
Problem Solving
Knowledge
Systems Thinking
November 26, 2009 202

Analytical Thinking and Problem Solving
• Creative Thinking
− Involves generating new ideas and concepts, as well as finding new associations
between or new applications of existing ideas and concepts
• Decision Making
− Includes gathering information relevant to a decision, breaking down the information
relevant to a decision, making comparisons and tradeoffs between similar and
dissimilar options, and identifying the option that is most desirable
• Learning
− Learning about a domain passes through a set of stages, from initial acquisition and
learning of raw facts, through comprehension of their meaning, to applying the
knowledge in day-to-day work, and finally analysis, synthesis, and evaluation
• Problem Solving
− Defining a problem involves ensuring that the nature of the problem is clearly
understood by all parties and that underlying issues are visible
• Systems Thinking
− Systems theory and systems thinking suggest that the system as a whole will have
properties, behaviors and characteristics that emerge from the interaction of the
components of the system, and which are not predictable from an understanding of
thecomponents alone
November 26, 2009 203

Behavioural Characteristics
• Ethics
− Requires an understanding of the standards that should govern
behaviour and the willingness to act to ensure that behaviour
meets those standards
• Personal Organisation
− Involves the ability to readily find files or information, timeliness,
management of outstanding tasks, and appropriate handling of
priorities
• Trustworthiness
− Stakeholders must trust the business analyst to behave ethically
and to perform business analysis work effectively
November 26, 2009 204

Business Knowledge
• Business Principles and Practices

− Business principles are those characteristics that are common to all
organisations with a similar purpose and structure
• Industry Knowledge
− Understanding of the competitive forces that shape an industry and of major
trends impacting the industry will help shape business requirements
• Organisation Knowledge
− Understanding of the business architecture of the organisation being analysed
• Solution Knowledge
− Familiarity with the workings of solutions will enable easier identification and
recommendation if changes that can be implemented easily while still
providing concrete benefits
November 26, 2009 205

Communication Skills
• Verbal Communications
− Enable business analysts to effectively express ideas in ways that
are appropriate to the target audience
• Teaching
− Required to ensure that business analysts can effectively
communicate issues and requirements and to ensure that the
information communicated is understood and retained
• Written Communications
− Necessary for business analysts to document elicitation results,
requirements, and other information for which medium-to-long
term records are required
November 26, 2009 206

Interaction Skills
• Facilitation and Negotiation

− Facilitate interactions between stakeholders in order to help
them resolve disagreements regarding the priority and nature of
requirements
• Leadership and Influencing
− Be effective in formal and informal leadership roles, in order to
guide others investigating requirements and to help encourage
stakeholder support for a necessary change
• Teamwork
− Be able to work closely with other team members to effectively
support their work so that solutions can be effectively
implemented
November 26, 2009 207

Software Applications
• General-Purpose Applications
− Office productivity applications to document and track
requirements
• Specialised Applications
− Modelling, diagramming and requirements management tools to
support the development of formal models, and in some cases,
their validation and implementation as well
November 26, 2009 208

Establishment of a Business Analysis Function
November 26, 2009 209

Business Analysis
• Business analysis is currently where project management

was ten or more years ago
• We all know of it, we know we need it, but it is often
unclear exactly what a business analyst does or what value
they bring to the business
• The key benefit of adopting a consistent and robust
framework in business analysis is the enablement of
genuine benefits realisation through a solution which
actually meets the business need
• BABOK is a key enabler to implementing effective business
analysis framework and processes
November 26, 2009 210
Business Analysis Centre of Excellence (BACOE)
• Business Analysis Issues

− No methodology or common practices
− Inconsistently defined role of business analyst
− Skill set not sufficient to support implementing a structured business analysis
methodology
− Disparate enterprise knowledge
− Projects being staffed with external consultants
− Unsuccessful attempts in the past
− Inconsistent
− Project failures and problems due to analysis defects
− Short analysis cycles
− Business analyst value hard to measure
• Desired State
− Robust business analysis methodology has become the way to do business across the
organisation
− Business analyst role clearly defined and supported through the Business Analysis
Centre of Excellence
− Business analyst demonstrating proficiency in key competencies
− Requirements defects reduced substantially
− Improved mix of internal Business analyst and external consultants
November 26, 2009 211

Key Benefits
• Establishing enterprise standards, procedures, governance

• Standardising infrastructure, development methods, and
operational procedures
• Increasing business agility to adapt quickly as the
environment changes
• Reducing risk, complexity, redundancy, and support
complexity
• Aligning business and IT
• Enabling re-use and faster time-to-market
• Reduced project failures and problems due to
requirements and analysis defects
November 26, 2009 212
Structure of a BACOE
BACOE Key Functional
Areas
Business Analysis
Business Analysis Business Analysis Business Analysis
Governance and
Standards Development Services
Strategic Alignment
Frameworks,
Skills and
Methodologies, Business Programme
Competency Competitive Analysis
Practices and Analysis
Assessments
Templates
Training and Portfolio

Tools Business Architecture
Education Management
Benefits
Performance Metrics Mentoring Feasibility Studies
Management
Performance Business Case

Career Development Analysis Reviews
Reporting Generation
Continuous
Improvement and Process Modelling
Practice Maturity
November 26, 2009 213
Effective BACOE Function
• Identify and understand the business problem and the impact of the proposed
solution on the organisation’s operations
• Document the complex areas of project scope, objectives, added value or benefit
expectations, using an integrated set of analysis and modeling techniques
• Translate business objectives into system requirements using powerful analysis
and modeling tools
• Evaluate customer business needs, thus contributing to strategic planning of
information systems and technology directions
• Assist in determining the strategic direction of the organisation
• Liaise with major customers during preliminary installation and testing of new
products and services
• Design and develop high quality business solutions
• Select the projects that will give the greatest business benefit and then ensure
project success
• Contribute to overall business growth and development
November 26, 2009 214

Business Analysis and The IIBA Business Analysis Body of Knowledge BABOK

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Analysis and The IIBA Business Analysis Body of Knowledge BABOK

Uploaded by

Copyright:

Available Formats

Business Analysis and

BABOK (Business Analysis

• To provide an overview of the importance of business

November 26, 2009 2

November 26, 2009 3

• Ability to develop a clear and detailed understanding of:

November 26, 2009 5

November 26, 2009 6

• Gathers data that is unstructured –

November 26, 2009 7

November 26, 2009 8

• Effective and targeted project management and systems

• IT need to possess expertise in multiple domains

November 26, 2009 10

• Business Analysis exists in wider context

Solution Architecture and Design

Solution Solution Solution Specification and

Project Management Cycle

Initiate Execute and Control

Solution Delivery - Implementation and Deployment Lifecycle

Setup and Implement

November 26, 2009 11

• Lack of advance planning for projects and initiatives

November 26, 2009 12

• Very significant Business/IT pain point

November 26, 2009 13

• Poor understanding of the business need or problem

November 26, 2009 14

• Misalignment between requirements and project scope

Solution Architecture and Design

Solution Solution Solution Specification and

Project Management Cycle

Initiate Execute and Control

Solution Delivery - Implementation and Deployment Lifecycle

Setup and Implement

Business Solution Project Business

• Ensure adequate and appropriate resources and involvement during

• Need more than project management

November 26, 2009 17

Business Analysis Design of

November 26, 2009 18

• Use of a business analysis methodology and framework

November 26, 2009 19

November 26, 2009 20

• A condition or capability needed by a stakeholder to solve a problem

• Objective is to define and describe the characteristics of an

• It is all about requirements

November 26, 2009 22

• Identify team roles: project manager, business analysts, developers, quality

November 26, 2009 23

November 26, 2009 24

Problem Business Analysis:

Solution Design: Solution

November 26, 2009 25

Business • Need the

November 26, 2009 27

• Business requirements drive strategy, architecture and

November 26, 2009 28

• Requirements Specification describes what a system

November 26, 2009 29

• Getting requirements right reduce risk of project failure

November 26, 2009 30

Low Cost Estimate High Cost Estimate