Please enable JavaScript.
Coggle requires JavaScript to display documents.
BABOK v3 Guide :no_entry: - Coggle Diagram
BABOK v3 Guide
:no_entry:
:<3:
K2 - Elicitation and Collaboration
:star:
1.Prepare for Elicitation
:question: Understand the scope of elicitation
What is a business domain?
Stakeholders - to understand as much as you can
Outputs - what do we expect as outputs?
Skills of BAs involved
What is the general strategy and approach?
Any idea of the scope?
:question: Select elicitation techniques
What are elicitation technique your company used to apply?
Use multiple elicitation techniques
:question: Set up logistics (meeting organization, etc)
:question: Secure supporting material (organisational point)
:question: Prepare stakeholders (explain the techniques in advance)
:star:
2.Conduct Elicitation
:question: Type of Elicitation
Collaborative (direct interaction)
Reserch (historical data)
Experiments (prototypes, PoCs)
:question: Guide Elicitation Activity
Stick to the agenda
Keep on track the scope of change
How info will be used
:question: Capture Elicitation outcomes
Could be planned/ unplanned sessions
Outcomes > official elicitation materials
:star:
3.Confirm Elicitation Results
:question: Confirm elicitation results against source info
:question: Confirm elicitation results against other elicitation results
:star:
4.Communicate Business Analysis Information
:question: Determine objectives and format communication
Objectives:
Requirements
Alternative options
Approvals/ sign offs
Communication:
Type of audience
What is important information?
:question: Communication the BA Package
Group Collaboration
Individual Collaboration
Email/ other non-verbal methods
:star:
5.Manage Stakeholder Collaboration
:question: Gain agreement on commitments
How much time stakeholder/stakeholder group agreed to dedicate to?
:question: Monitor stakeholder engagement
:question: Collaboration
:<3:
K1 - BA Planning and Monitoring
:star:
1.Plan Business Analysis Approach
:question: Predictive vs Adaptive
:question: Level of documentation details
:question: Time
:question: Complexity & Risk
:star:
2.Plan Stakeholder Engagement
:question: Perform Stakeholder analisys
Technique: Stakeholder Matrix
Technique: Stakeholder Onion Diagram
Technique: RACI Matrix :
:question: Define Stakeholder collaboration
Location
Frequency
Tools to help collaboration
Ways how deliver collaboration
:question: Stakeholder communication needs
How to communication
What is the level of communication?
:star:
3.Plan Business Analysis Governance
:question: Decision Making
Escalation process
:question: Change Control Process
- refer to BABOK
:fire:
:question: Plan Prioritisation Approach
Timelines
Expected Value
Dependencies
Resources Contrains
:question: Plan for Approvals
What needs to be approved?
Who needs to approve?
Process for approvals?
Methods (how formal will it be?)
Plan for approvals
:star:
4.Plan Business Analysis Information Management
:question: Organisation of BA information
:question: Level of Abstraction
:question: Plan Traceability Approach
:question:Plan of Requirement Reuse
:question:Storage and Access
:question: Requirement Attributes
Aubsolute Reference (unique ID)
Author (who is composing the req)
Complexity to implement
Ownership (Sponsor of the req)
Priority
Risks
Source (how asked for this req?)
Stability (how mature is it req?)
Status (ongoing status of the req)
Urgency (how urgent do we need this req to go live?)
5.Identify Business Analysis Performance Improvements
:star:
:question: Performance Analysis
:question: Assessment Measures
Accuracy and Completeness
Knowledge
Effectiveness
Organisational Support
Significance
Strategic
Timeliness
:question: Analyse Results
:question: Recommended Actions for Improvement
:<3:
K5 - Requirements Analysis and Design Definition
:star:
1. Specify and Model Requirements
(analyse, synthesise and refine elicitation results into reqs and design)
:question:
Model Requirements
Matrices
(complex set of reqs)
:pencil2: Data Dictionaries
:pencil2: GAP Analysis
:pencil2: Traceability Matrix
Diagrams
(visual representation of reqs)
:pencil2: Data, process, functional diagrams
People&Roles
( Organizational Modelling)
:pencil2: Roles&Permissions Matrix
:pencil2: Stakeholder List
:pencil2: Map
:pencil2: Personas
Rationale
(Why?)
:pencil2: Decision Modelling
:pencil2: Scope Modelling
:pencil2: Business Model Canvas
:pencil2: Root Cuase Analysis
:pencil2: Business Rules Analysis
Activity Flow
(Sequence of actions)
:pencil2: Process Modelling
:pencil2: Use Cases and Scenarios
:pencil2: User Stories
Capability
:pencil2: Business Capability Analysis
:pencil2: Functional Decomposition
:pencil2: Prototyping
Data and Information
:pencil2: Data Dictionary
:pencil2: Data Flow Diagrams
:pencil2: Data Modelling
:pencil2: Glossary
:pencil2: State Modelling
:pencil2: Interface Analysis
:question:
Analyse Requirements
(when BA info is decomposed into
components to further examination)
Anything that must change
Anything that should stay the same
Anything that might be missing
Unnecessary components
Any constrains/ assumptions that impact the components
:question:
Represent Requirements and Attributes
(BA identifies info for reqs and their attributes as part of elicitation results)
:question:
Implement the Appropriate Levels of Abstraction
(about ensuring reqs are presented at an appropriate level of detail and perspective to serve the needs of the SHs being presented to)
:star:
2. Verify Requirements
(to ensure that reqs/ design specifications and models meet quality standards and are usable for the purpose they serve)
:question:
Characteristics of Reqs and Designs Quality
:warning:
Atomic
Self-contained and can be understood independently of other reqs/ designs
:warning:
Complete
Enough to guide further work (depends on methodology and perspective)
:warning:
Consistent
Aligned with the identified needs of the SHs and not conflicting with other reqs
:warning:
Concise
Contains no extraneous and unnecessary content
:warning:
Feasible
Reasonable and possible within the agreed-upon risk, schedule, budget, or considered feasible enough to investigate further through experiments or prototypes
:warning:
Unambiguous
The reqs must be clearly stated in such a way to make it clear whether a solution does or does not meet the associated need.
:warning:
Testable
Able to verify that the req or design has been fulfilled.
:warning:
Prioritised
Ranked, grouped, or negotiated in terms of importance and value against other reqs.
:warning:
Understandable
Represent using common terminology of the audience
:question:
Verification activities
Checking for compliance with organisational standards (tools, methods)
Checking for correct use of modelling notation, templates or forums
Checking for completeness with each model
Comparing each model against other relevant models. For example, gaps of info between models
Ensuring terminology is expressing the req is understandable by the audience
:question:
Checklists
(used to ensure that items determined to be important are included in the final reqs deliverables, or that steps required for the verification process are followed)
:star:
3. Validate Requirements
(to ensure that all reqs and designs align to the business reqs and support the delivery of needed value)
:question:
Identify Assumptions
(if there is uncertainty or the product/ service is a new domain, it might be required to make some assumptions for work to continue)
:question:
Define Measurable Evaluation Criteria
(BA defines the evaluation criteria that will be used to evaluate how successful the change has been after the solution is implemented)
:question:
Evaluate Alignment with Solution Scope
:check: A req may be delivering a benefit to a SH but may not be a desirable part of a solution
:check: A req however that does not deliver value, is a candidate for elimination
:star:
4. Define Requirements Architecture
(to ensure that the reqs collectively support one another to fully support the objectives)
:question:
Requirements Viewpoints and Views
(A view point is a set of conventions that define how reqs will be represented, how these representations will be organised and how they will be related (model types, attributes, notations, analytical approaches))
:question:
Template Architectures
(architectural framework is a collection of viewpoints that is standard across an industry, sector or organisation)
:question:
Completeness
(Structuring reqs according to different viewpoints helps ensure this completeness. Iterations of elicitations, specifications, analysis activities can help identify gaps)
:question:
Relate and Verify Reqs Relationships
(these are the defined relationships between reqs)
:question:
Business Analysis Information Architecture
(component of the reqs architecture because it describes how all of the business analysis info for a change relates)
:star:
5. Define Design Options
(to define the solution approach, identify opportunities to improve the business, allocate reqs across solution components, and represent design options that achieve the desired future state)
:question:
Define Solution Approaches
:check: Create
:check: Purchase
:check: Combination of both
:question:
Identify Improvement Opportunities
:check: Increase efficiencies
:check: Improve access to information
:check: Identify additional capabilities (for future use)
:question:
Requirements Allocation
:check: is the process of assigning reqs to solution components and releases to best achieve the objectives
:check: reqs may be allocated between organisational units, job functions, solution components or releases of a solution
:check: allocation typically continues through design and implementation of a solution
:question:
Describe Design Options
:check: Design options are investigated and developed while considering the desired future state, and in order to ensure the design options are valid
:check: Solution performance measures are defined for each design solution
:check: A design option usually consists of many design components, each described by a design element
:star:
6. Analyze Potential Value and Recommend Solution
(to estimate the potential value for each design option and to establish which one is most appropriate to meet the enterprise's requirements.)
:question:
Expected Benefit
(a positive value that a solution is intended to deliver to SH (benefits, reduced risks, compliance with regulations, improved UX))
:question:
Expected Costs
(any potential negative value associated with a solution)
:check:
Opportunity costs:
There are alternative results that might have been achieved if the resources, time and funds devoted to one design option had been allocated to another design option.
Opportunity cost = What One Sacrifice/ What One Gain
:question:
Determine Value
(the potential value of solution to a SH is based on the benefits delivered by that solution and the associated costs. Value can be positive or negative)
:question:
Assess Design Option and Recommend Solution
:check: Each design option is assessed based on the potential value it's expected to deliver.
:check: As costs and effort are understood for each solution component, BA assesses each design option to ensure that it represents the most effective trade-offs.
:check: There are several factors to take into consideration:
:warning: Available resources
:warning: Constrains on the solution
:warning: Dependencies between reqs
:<3:
K4 - Strategy Analysis
:star:
1.Analyze Current State
:question:
Business Need
(Problems and opportunities of strategic importance faced by the enterprise)
Top-down:
Strategic goal to be achivied
Bottom-Up:
A problem with a process, function, system
Middle management:
A need for additional information to make sound decisions
External drivers:
A customer demand or business competition
:question:
Organizational Structure and Culture
(the shared beliefs, values and norms and drives actions taken by the organization)
:question:
Capabilities and Processes
(describes the activities the enterprise performs)
Capability Centric View
: of the enterprise when looking for innovative solutions that combine existing capabilities to produce a new outcome.
Process Centric View
: of the enterprise when looking for ways to improve the performance of current activities
:question:
Technology and Infrastructure
:question:
Policies
(define the scope of decision making at different levels of an enterprise)
:question:
Business Architecture
(is about understanding the bigger picture and context of the enterprise, business unit or SH group before finalising the proposed change to the current state)
:question:
Internal Assets
(tangible and intangible assets such as financial resources, patents, reputations and brand names)
:question:
External Influencers
(external factors to the enterprise that could introduce constraints, dependencies or drivers to the current state)
Industry Structure
Competitors
Customers
Suppliers
Political or Regulatory Environment
Technology
Macro-economic Factors
:star:
2.Define Future State
:question:
Business Goal and Objectives
(A
goal
is a longer-term, ongoing, and qualitative statement of a state or condition that the organization is seeking to establish and maintain. As a goal is analyzed and converted into more descriptive, granular, and specific
objectives
, and it's also linked to measures it becomes possible to objectively assess if the objectives have been achieved.)
:question:
Scope of Solution Space
(defines which kind of options will be considered when investigating possible solutions.)
:!: Scope of Solution must be aligned to business objectives.
:!: You may need to compare options of solutions in terms of value, time, and opportunity cost to the organization.
:question:
Constraints
(describes aspects of the current state and planned future state that may not be changed)
Budget Constrains
Time constrains
Technology
Infrastucture
Policy
Skills
Compliance
:question:
Organisational Structure and Culture
(is there a need to change the format and informal working relationships or culture?)
:question:
Capabilities and Processes
(what new or change processes and capabilities will be needed to support the future state?)
:question:
Technology and Infrastructure
(time to update to support a new solution?)
:question:
Policies
(could be impacted by a change)
:question:
Business Architecture
(the elements of the future state must support one another and all contribute to meee the business goals and objectives)
:question:
Internal Assets
(the assessment of needed resources to supported the planned future state is done when performing a feasibility analysis on possible solutions approaches for the change strategy)
:question:
Identify Assumptions
:check: Most strategies are predicated on a set of assumptions that will determine whether or not the strategy can succeed, particularly when operating in a highly uncertain environment
:check: Change strategies in uncertain environments can be structured in order test these assumptions as early as possible to support a redirection or termination of the initiative.
:question:
Potential Value
(net benefit of the solution after operating costs are accounted for)
:star:
3.Assess Risks
:question:
Unknowns
(about accepting that there will be uncertanty in the likelihood of a risk occuring and the impact of the risk when it occurs)
:question:
Constrains, Assumptions and Dependencies
(should be considered there these elements are the risks themselves)
:question:
Negative Impact on Value
(a risk could have a
low
likelihood, but
high
impact on value)
:question:
Risk Tolerance
(amount of uncertainty an enterprise is willing to take on in exchange for potential value. LoVs: Risk-aversion/ Neutrality/ Risk-seeking)
:question:
Recommendation
(BA works with SHs to understand the overall risk level and their tolerance for risk)
:check: Pursue the benefits of a change regardless of the risk
:check: Pursue the benefits of a change while investing in reducing risk
:check: Seek out ways to increase the benefits of a change to outweigh the risk
:check: Identify ways to manage and optimize opportunities
:check: Do not pursue the benefits of a change
:star:
4.Define Change Strategy
:question:
Solution Scope
(outcome of a change that allows an enterprise to satisfy a need)
:question:
Gap Analysis
(identifies the diffrence between current state and future state capabilities)
:question:
Enterprise Readiness Assessment
:check: This is about analyzing the enterprise to assess its capacity to make a change and to sustain the change in the future state.
:check: This also includes assessing the ability to realize value from the solution one it's implemented
:question:
Change Strategy
(a high plan of activities and events that will be used to transform the enterprise from the current state to the future state)
:question:
Transition States and Release Planning
(BA assists in planning the timing of the implementation on order to cause minimal disruption to business activities, and to ensure all parties understand the impact to the organisation)
:<3:
K3 - Requirements Life Cycle Management
:star:
5.Approve Requirements
:question: Understand SH roles (based on BA Governance Plan)
:question: Conflict and Issue Management (to fix - run meeting/ workshop)
:question: Gain Consensus
:question: Track and Communicate Approvals
:star:
4.Assess Requirements Changes
:question: Assessment Formality
Governance Process
Change Control Process
Predictive VS Adaptive
:question: Impact Analysis
Benefit
Cost
Impact
Schedule
Urgency
:question: Impact Resolution (proceed/ deny/ defer)
:star:
3.Prioritize Requirements
:question: Basis (reasons) for Prioritization
Benefit
Penalty
Cost
Risk
Dependency
Time sensitivity
Stability
Regulatory or Policy Compliance
:question: Challenges for Prioritization (different SHs could have different priorities)
:question: Continual Prioritization
Priorities might shirt over time
Level at which prioritization happens will become more granular
:star:
2.Maintain Requirements
:question: Maintain Reqs
Maintain for accuracy
Well named
Accessible to SHs
Maintain relationships and relevant info
:question: Maintain Attributes
Source
Priority
Complexity
:question: Reusing Reqs
Examples:
Regulatory Reqs
Data Privacy Reqs
Policy Reqs
Usability Reqs
Reporting Reqs
:star:
1.Trace Requirements
:question: Traceability Schemes
Process Traceability
(Value Chain > Business Process > Sub-process > Activity > Task)
Software Requirement Traceability
(Business Needs > Business Reqs > Stakeholder Reqs > Solution Reqs (Design > Code . Test))
:question: Elements
Level of Formality (determine the value of particular type of link or trace )
Relationships
Derive
(when one req is derived from another)
Depends
(when one req depends from another)
Satisfy
(relationship between an implementation element and the req it's satisfying)
Validate
(relationship between a req and test case that validates the req has been fullfilled with the solution)
Traceability Repository (JIRA, Excel, etc)
:<3:
K6 - Solution Evaluation
:star:
1. Measure Solution Performance
(to define performance measures and use the data collected to evaluate the effectiveness of a solution in relation to the value it brings )
:question:
Define Performance Solution Measures
Sources of measures
:check: business goals, business processes
:check: 3rd party vendors, government legislation, etc
Types of measures
:check: Quantitative (numerical, countable. For example, amounts, rates)
:check: Qualitative (subjective measures. For example, attitudes, perceptions)
:question:
Validate Performance Measures
(BA ensures that the selected performance measures are valid and agreed upon by all primary SHs)
:question:
Collect Performance Measures
(BA can employ basic statistical sampling concepts)
:star:
2. Analyze Performance Measures
(to provide insights into the performance of a solution in relation to the value it brings)
:question:
Solution Performance vs Desired Value
:question:
Risks
(new risks could be identified when performance measures are analysed)
:question:
Trends
(abount noticing any trends in performance results)
:question:
Accuracy
(ensuring that performance results are accurate)
:question:
Performance Variances
(identify any notable variances between expected and actual performance measure results)
:star:
3. Assess Solution Limitations
(to determine the factors
internal
to the solution that restricts the full realization of value)
:question:
Identify Internal Solution Component Dependencies
(:!:the least effective component of a solution with dependent components will affect the entire solution)
:question:
Investigate Solution Problems
(if a solution is performing below expectations, the BA will embark on Problem Analysis)
:question:
Impact Assessment
(once limitations have been identified, the BA will assess the impact those limitations may have on the solution or the enterprise)
:star:
4. Assess Enterprise Limitations
(to determine the factors
external
to the solution that restricts the full realization of value)
:question:
Enterprise Cultural Assessment
:question:
SH Impact Analysis
:warning:
Functions
(inputs, processes, outputs by SH)
:warning:
Locations
(is SH physical location preventing them from using the solution optimally?)
:warning:
Concerns
(any risks, issues, perceptions held by SH in relation to the solution?)
:question:
Operational Assessment
(is processes and tools adequately equipped to support the solution?)
:warning: Policies & Procedures
:warning: Capabilities and processes that enable other capabilities
:warning: Skill and training needs
:warning: Human Resources practices
:warning: Risk tolerance and management approaches
:warning: Tools and technology that support a solution
:question:
Organisational Structure Changes
:star: 5.
Recommend Actions to Increase Solution Value
(to understand the factors that create differences between potential value and actual value and to recommend a course of actions to align them)
:question:
Adjust Solution Performance Measures
(determine whether solution performance measures are in line with goal that the organisation have set for a solution)
:question:
Recommendations
:check: Do Nothing
:check: Organisational Change
:check: Reduce Complexity of Interfaces
:check: Eliminate Redundancy (identify common needs)
:check: Avoid waste (eliminate activities that adds no value)
:check: Identify additional capabilities (potential future value)
:check: Retire the solution
:!:Ongoing cost vs Initial investment
:!:Opportunity cost
:!:Necessity
:!:Sunk cost (непогашена вартість - The money and effort already committed and spent in relation to an initiative)
:black_flag:
Extended - Underlying Competencies
:star:
1. Analytical Thinking and Problem Solving
:star:
2. Behavioural Characteristics
:star:
3. Business Knowledge
:star:
4. Communication Skills
:star:
5. Interaction Skills
:star:
6. Tools and Technology
:black_flag:
Extended - Techniques
:star:
Workshops
:question: Purpose
Elicitation of reqs
Scoping/ modeling/ idea generation
:question: Elements
Preparation
Goal
Facilitator & Scribe
Participants
Agenda & Outputs
Schedule, invigations, logistics
Roles
Facilitator
Scribe
Sponsor
Timekeeper
Participants
Conducting the workshop
Agree how decisions are done
Respect opinions
Contribute
Issues not people
Off-topic should be time-boxed
Post Workshop Wrap Up
Complete documentation
Close any open items from the workshops
:star:
Interviews
:question: Types of interviews
Structured Interviews (predefined questions)
Unstructured interviews (conversation with free flow)
:question: Elements
Interview Goal
Determine overall purpose of a set of inteviews
Define a specific goal for each planned interview
Communicate the goals for each interview with the interviewees
Interview Questions
Depends on inteview's goal
Open questions VS Closed questions
Interview Guide
Potential Interviewees
Determine who will be suitable stakeholders for interviews
Interview Logistics
Where the interview wiil be hold?
Will it be recorded?
Should the questions be sent in advance?
Will the interview be confidencial? If yes, how the results will be analysed?
Interview Flow
1.
Opening the interview:
1.1 Describe the purpose
1.2 Confirm roles and initial concerns (if any)
1.3 Explane how responses will be recorded and used
2.
During the interview:
2.1 Focus on goals
2.2 Consider inteviewee's willingness to share information
2.3 Multiple session might be required to finish inteview
2.4 Manage concerns
2.5 Take written notes and records
3.
Closing the interview:
3.1 Anything missed?
3.2 Share contact details
3.3 Summarise session and next steps
3.4 Thank you
Interview Follow Up
Document and share the structed interview information with the interviewee for validation
:question:Strengths
Rapport builing and direct approach
Full discussions and explanations
Follow up and probing questions to get to details
Interviewees can freely express opinions that they may be reluctant to do overwise
:question: Limitations
Time consuming and considerable commitment and involvement from SHs
Intepretation by inteviewer could be subjective
Interviewee might be lead towards specific outcomes
You might need to train people to be effective in this technique
:star:
Financial Analysis
:question: Cost of Change
Expected costs of building or acquiring the solution
Expected costs of transitioning the enterprise from the current to future state
Could include costs of changing equipment, software, facilities, staff, other resources
It also includes buing out existing contracts, subsidies, penalties, converting data, trainings, communications about the change and managing the roll out
:question: Total Cost of Ownership (TCO)
The costs associated with acquiring the solution
The costs of using the solution
The cost of supporing that solution into the foreseeable (3-5 years) future
:question: Value Realisation
The expected value to realised over time
Expressed as an annual value OR a cumulative value over a specific period of time
:question: Cost-Benefit Analysis
This is a prediction of the expected total benefits minus the expected total costs, resulting in a NET benefit (planned business value)
This time period of a cost-benefit analysis should look far enough in the future to a time when the solution is in full use
:question: Financial Calculations
Return on Investment (ROI)
Percentage of NET benefits divided by Cost of the Change
ROI = ((Total Benefits - Cost of Investment)/ Cost of Invesment) x 100 %
Discount Rate
This is the assumed interest rate (процентна ставка) used in present value (PV) calculations. This value is determined by the organization and made available for any present value (PV) calculations.
Present Value (PV)
This calculates the present day value of expected benefits (поточнa вартість очікуваних вигод). Present value is expressed in currency format and it does not take the cost of investment into account.
Present Value = Sum of (Net Benefits in that period / (1 + Discount rate of that period)) for all periods in the cost-benefit analysis
Net Present Value (NPV)
The Net Present Value is the Present Value minus the cost of the original investment.
Net Present Value = Present Value - Cost of Investment
Internal Rate of Return (IRR)
This is the interest rate at which an investment breaks even (процентна ставка, за якою інвестиція збивається рівномірно). This assists in determining whether an investment is worth investing in and can be used to compare different solutions against each other.
Net Present Value = ((-1 x Original Investment) + Sum of (Net benefit of that period) / (1 +
IRR
) for all periods) = 0
Payback Period
The payback period shows a projection on the time period that is required to generate enough benefit to recover the original cost of the change irrespective of the discount rate (Період окупності показує прогноз на період часу, необхідний для отримання достатньої вигоди для відновлення первісної вартості зміни незалежно від процентної ставки).
There is no standard formula, it's expressed in years.
:black_flag:
Extended - BA Key Concepts
:star:
1. The BA Core Concept Model
:question: Change
The act of transformation in response to a need.
:question: Need
A problem or opportunity to be addressed.
:question: Solution
A specific way of satisfying one or more needs in a context.
:question: Stakeholder
A group or individual with a relationship to the change, the
need, or the solution.
:question: Value
Value can be seen as potential or realized returns, gains, and improvements.
:question: Context
The circumstances that influence, are influenced by, and provide understanding of the change.
:star:
2. Key Terms
:question: Business Analysis
:question: Business Analysis Information
:question: Design
:question: Enterprise
:question: Organization
:question: Plan
:question: Requirement
:question: Risk
:star:
3. Requirements Classification Schema
:question: Business Requirements
:question: Stakeholder Requirements
:question: Solution Requirements
Functional Requirements
Non Funtional Requirements
:question: Transition Requirements
:star:
4. Stakeholders
:question: Business Analyst
:question: Customer
:question: Domain SME
:question: End User
:question: Implementation SME
:question: Operational Support
:question: Project Manager
:question: Regulator
:question: Sponsor
:question: Supplier
:question: Tester
:star:
5. Requirements and Designs
:black_flag:
Extended - Perspectives
:star:
1. The Agile Perspective
:star:
2. The Business Intelligence Perspective
:star:
3. The Information Technology Perspective
:star:
4. The Business Architecture Perspective
:star:
5. The Business Process Management Perspective