Business Analysis

Get Started. It's Free
or sign up with your email address
Rocket clouds
Business Analysis by Mind Map: Business Analysis

1. NEEDS ASSESSMENT

1.1. ............................Identify Problem or Opportunity

1.1.1. Identify Stakeholders

1.1.1.1. responsibility assignment matrix (RACI)

1.1.2. Investigate the Problem or Opportunity

1.1.3. Gather Relevant Data to Evaluate the Situation

1.1.4. Draft the Situation Statement

1.1.4.1. •Problem (or opportunity) of “a” • Has the effect of “b” • With the impact of “c”

1.1.5. Obtain Stakeholder Approval for the Situation Statement

1.2. .............Assess Current State of the Organization

1.2.1. Assess Organizational Goals and Objectives

1.2.1.1. Goals and Objectives

1.2.1.2. SMART Goals and Objectives

1.2.2. SWOT Analysis

1.2.3. Relevant Criteria

1.2.4. Perform Root Cause Analysis on the Situation

1.2.4.1. Five Whys

1.2.4.2. Cause-and-Effect Diagrams

1.2.4.2.1. Fishbone Diagrams

1.2.4.2.2. Interrelationship Diagrams

1.2.4.2.3. Process Flows

1.2.5. Determine Required Capabilities Needed to Address the Situation

1.2.5.1. Capability Table

1.2.5.2. Affinity Diagram

1.2.5.3. Benchmarking

1.2.6. Assess Current Capabilities of the Organization

1.2.6.1. Process flows

1.2.6.2. Enterprise and business architectures

1.2.6.3. Capability frameworks

1.2.7. Identify Gaps in Organizational Capabilities

1.3. Recommend Action to Address Business Needs

1.3.1. Include a High-Level Approach for Adding Capabilities

1.3.2. Provide Alternative Options for Satisfying the Business Need

1.3.3. Identify Constraints, Assumptions, and Risks for Each Option

1.3.3.1. Constraints

1.3.3.2. Assumptions

1.3.3.3. Risks

1.3.4. Assess Feasibility and Organizational Impacts of Each Option

1.3.4.1. Operational Feasibility

1.3.4.2. Technology/System Feasibility

1.3.4.3. Cost-Effectiveness Feasibility

1.3.4.4. Time Feasibility

1.3.4.5. Assess Factors

1.3.5. Recommend the Most Viable Option

1.3.5.1. Weighted Ranking

1.3.6. Conduct Cost-Benefit Analysis for Recommended Option

1.3.6.1. Payback Period (PBP)

1.3.6.2. Return on Investment (ROI)

1.3.6.3. Internal Rate of Return (IRR)

1.3.6.4. Net Present Value (NPV)

1.3.7. Assemble the Business Case

1.3.7.1. Value of the Business Case

2. BUSINESS ANALYSIS PLANNING

2.1. Conduct or Refine the Stakeholder Analysis

2.1.1. Techniques for Identifying Stakeholders

2.1.1.1. Brainstorming

2.1.1.2. Organizational Charts

2.1.2. Determine Stakeholder Characteristics

2.1.2.1. Attitude

2.1.2.2. Complexity

2.1.2.3. Culture

2.1.2.4. Experience

2.1.2.5. Level of Influence

2.1.2.6. Location and Availability

2.1.3. Techniques for Grouping or Analyzing Stakeholders

2.1.3.1. Job Analysis

2.1.3.2. Persona Analysis

2.1.4. Assemble the Stakeholder Analysis Results

2.2. Create the Business Analysis Plan......................

2.2.1. Determining the Proper Level of Detail

2.3. Understand the Project Context........................

2.3.1. Understand How the Project Life Cycle Influences Planning Decisions

2.3.1.1. Predictive

2.3.1.2. Iterative/Incremental

2.3.1.3. Adaptive:

2.3.2. Ensure the Team is Trained on the Project Life Cycle

2.3.3. Leverage Past Experiences When Planning

2.3.3.1. Lessons Learned

2.3.3.2. Retrospectives

2.3.4. Plan for Elicitation

2.3.4.1. Strategies for Sequencing Elicitation Activities

2.3.5. Plan for Analysis

2.3.6. Define the Requirements Prioritization Process

2.3.7. Define the Traceability Approach

2.3.8. Define the Communication Approach

2.3.9. Define the Decision-Making Process

2.3.10. Define the Requirements Verification and Validation Processes

2.3.11. Define the Requirements Change Process

2.3.12. Define the Solution Evaluation Process

2.4. Plan the Business Analysis Work

2.4.1. Determine Who Plans the Business Analysis Effort

2.4.2. Build the Business Analysis Work Plan

2.4.2.1. Identify the Deliverables

2.4.2.2. Determine the Tasks and Activities

2.4.2.3. Determine the Timing and Sequencing of Tasks

2.4.2.4. Determine the Roles and Responsibilities

2.4.2.5. Identifying the Resources

2.4.2.6. Estimate the Work

2.4.3. Assemble the Business Analysis Work Plan

2.4.4. Document the Rationale for the Business Analysis Approach

2.4.5. Review the Business Analysis Plan with Key Stakeholders

2.4.6. Obtain Approval of the Business Analysis Plan

3. REQUIREMENTS ELICITATION AND ANALYSIS

3.1. Plan for Elicitation

3.1.1. Develop the Elicitation Plan

3.1.1.1. Finding Information

3.1.1.2. Techniques for Eliciting Information

3.1.1.3. Sequencing the Elicitation Activities

3.2. Prepare for Elicitation

3.2.1. Determine the Objectives

3.2.2. Determine the Participants

3.2.3. Determine the Questions for the Session

3.3. Conduct Elicitation Activities

3.3.1. Introduction

3.3.2. Body

3.3.2.1. Types of Questions

3.3.2.1.1. Open-ended question.

3.3.2.1.2. Closed-ended question

3.3.2.1.3. Contextual question

3.3.2.1.4. Context-free question

3.3.2.2. How to Ask the “Right” Questions

3.3.2.2.1. Listening

3.3.3. Close

3.3.4. Follow-Up

3.3.5. Elicitation Techniques

3.3.5.1. Brainstorming

3.3.5.2. Document Analysis

3.3.5.3. Facilitated Workshops

3.3.5.3.1. Overview.

3.3.5.3.2. Workshop preparation

3.3.5.3.3. Invite participants by roles

3.3.5.3.4. Tips for running a workshop.

3.3.5.4. Focus Groups

3.3.5.5. Interviews

3.3.5.5.1. Structured / Unstructured interviews

3.3.5.5.2. Synchronous / Asynchronous Interviews

3.3.5.6. Observation

3.3.5.6.1. Passive observation

3.3.5.6.2. Active observation

3.3.5.6.3. Participatory observation

3.3.5.6.4. Simulation

3.3.5.7. Prototyping

3.3.5.7.1. Low-fidelity /High-fidelity prototyping

3.3.5.7.2. Techniques: - Storyboarding / Wireframes

3.3.5.8. Questionnaires and Surveys

3.4. Document Outputs from Elicitation Activities

3.4.1. Complete Elicitation

3.4.2. Elicitation Issues and Challenges

3.4.2.1. The business analyst cannot gain access to the right stakeholders

3.4.2.2. Stakeholders do not know what they want

3.4.2.3. Stakeholders are having difficulty defining their requirements

3.4.2.4. Stakeholders are not providing sufficient detail to develop the solution

3.4.3. Analyze Requirements

3.4.3.1. Plan for Analysis

3.4.3.1.1. Analysis Defined

3.4.3.1.2. Thinking Ahead about Analysis

3.4.3.1.3. What to Analyze

3.4.4. Model and Refine Requirements

3.4.4.1. Description of Models

3.4.4.2. Purpose of Models

3.4.4.3. Categories of Models

3.4.4.3.1. Scope models

3.4.4.3.2. Process models

3.4.4.3.3. Rule models

3.4.4.3.4. Data models

3.4.4.3.5. Interface models

3.4.4.4. Selection of Models

3.4.4.4.1. Methodology.

3.4.4.4.2. Characteristics of the project

3.4.4.4.3. Timing within the project life cycle.

3.4.4.4.4. Categories of models

3.4.4.4.5. Level of abstraction

3.4.4.5. Use Models to Refine Requirements

3.4.4.6. Modeling Languages

3.4.4.6.1. Business process modeling notation (BPMN)

3.4.4.6.2. Requirements modeling language (RML)

3.4.4.6.3. System modeling language (SysML)

3.4.4.6.4. Unified modeling language (UML)

3.4.4.6.5. Various other modeling languages

3.4.4.7. Document the Solution Requirements

3.4.4.7.1. Business Requirements Document

3.4.4.7.2. The Solution Documentation

3.4.4.7.3. Requirements Specification

3.4.4.7.4. Guidelines for Writing Requirements

3.4.4.7.5. Prioritizing Requirements

3.4.4.7.6. Technical Requirements Specification

3.4.4.7.7. Documenting with Use Cases

3.4.4.7.8. Documenting with User Stories

3.4.4.7.9. Backlog Items

3.4.4.8. Validate Requirements

3.4.4.8.1. The Concept of Continual Confirmation

3.4.4.8.2. Requirements Walkthrough

3.4.4.8.3. Verify Requirements

3.4.4.8.4. Approval Sessions

3.4.4.8.5. Resolve Requirements-Related Conflicts

4. TRACEABILITY AND MONITORING

4.1. Traceability

4.1.1. What is Traceability?

4.1.2. Benefits of Tracing Requirements

4.1.2.1. Helps to ensure that each requirement adds business value.

4.1.2.2. Helps to meet customer expectations

4.1.2.3. Helps to manage scope

4.1.3. The Traceability Matrix

4.1.3.1. Requirements Attributes

4.1.3.1.1. Requirement ID

4.1.3.1.2. Short textual description of the requirement

4.1.3.1.3. Objectives

4.1.3.1.4. Product development stage

4.1.3.1.5. WBS (work breakdown structure),

4.1.3.1.6. Status, such as active, approved, deferred, canceled, added;

4.1.3.1.7. Rationale for inclusion (why the requirement is important to include);

4.1.3.1.8. Priority (how important the requirement is);

4.1.3.1.9. Owner;

4.1.3.1.10. Source (where the requirement came from);

4.1.3.1.11. Version;

4.1.3.1.12. Date completed

4.1.3.1.13. Stakeholder satisfaction

4.1.3.1.14. Stability;

4.1.3.1.15. Complexity; and

4.1.3.1.16. Acceptance criteria

4.1.3.2. Traceability Matrix Hierarchy

4.2. Relationships and Dependencies

4.2.1. Subsets

4.2.2. Implementation Dependency

4.2.3. Benefit or Value Dependency

4.3. Approving Requirements

4.3.1. Work Authorization System

4.3.1.1. Approval Levels

4.3.1.1.1. Approval vs. signoff

4.3.1.1.2. Reviewer vs. approver

4.3.1.1.3. Approval authority vs. accountability

4.3.1.1.4. Rejection of requirements

4.3.1.1.5. Change Control Board (CCB) and approval of changes

4.3.1.1.6. Expert judgment and the approval process

4.4. Baselining Approved Requirements

4.4.1. What is a Requirements Baseline

4.4.2. Relationship of Requirements Baseline, Product Scope, and Project Scope

4.4.3. Maintaining the Product Backlog

4.5. Monitoring Requirements Using a Traceability Matrix

4.5.1. Benefits of Using Traceability to Monitor Requirements

4.6. The Requirements Life Cycle

4.7. Managing Changes to Requirements

4.7.1. Change Management as it Relates to Business Analysis

4.7.2. Change Control Tools and Techniques

4.7.2.1. Configuration Management System (CMS)

4.7.2.2. Version Control System (VCS)

4.7.3. Impact Analysis

4.7.3.1. Impact on the Requirements Baseline

4.7.3.2. Impact on whether a Proposed Change Conflicts with Other Requirements

4.7.3.3. Impact on Business Analysis

4.7.3.4. Impact on Project Management

4.7.3.5. Recommending a Course of Action

4.7.4. Controlling Changes Related to Defects

5. SOLUTION EVALUATION

5.1. Purpose of Solution Evaluation

5.2. Recommended Mindset for Evaluation

5.2.1. Evaluate Early and Often

5.2.2. Treat Requirements Analysis, Traceability, Testing, and Evaluation as Complementary Activities

5.2.3. Evaluate with the Context of Usage and Value in Mind

5.3. Confirm Expected Values for Software Solutions

5.4. Plan for Evaluation of the Solution

5.4.1. Factors to consider when planning for evaluation

5.4.1.1. What project or organizational goal, objective, or risk does this evaluation activity monitor or track or confirm?

5.4.1.2. Who will cover costs for the time and effort needed to conduct evaluation?

5.4.1.3. Does the solution or its infrastructure have built-in measurement capabilities for the evaluation criteria?

5.4.1.4. Are there already ways to extract measurement data to use in the evaluation?

5.4.1.5. Is the chosen evaluation method effective and relatively inexpensive?

5.4.1.6. Are there already existing ways to report and publish the results of an evaluation?

5.5. Determine What to Evaluate

5.5.1. Consider the Business Goals and Objectives

5.5.2. Consider Key Performance Indicators

5.5.3. Consider Additional Evaluation Metrics and Evaluation Acceptance Criteria

5.5.3.1. Project Metrics as Input to the Evaluation of the Solution

5.5.3.2. Customer Metrics

5.5.3.3. Sales and Marketing Metrics

5.5.3.4. Operational Metrics and Assessments

5.5.3.5. Functionality

5.5.4. Confirm that the Organization Can Continue with Evaluation

5.6. When and How to Validate Solution Results

5.6.1. Evaluation techniques

5.6.1.1. Surveys and focus groups,

5.6.1.2. Results from exploratory testing and user acceptance testing

5.6.1.3. Results from day-in-the-life (DITL) testing,

5.6.1.4. Results from integration testing,

5.6.1.5. Expected vs. actual results for functionality,

5.6.1.6. Expected vs. actual results for nonfunctional requirements, and

5.6.1.7. Outcome measurements and financial calculation of benefits.

5.7. Evaluate Acceptance Criteria and Address Defects

5.7.1. Comparison of Expected vs. Actual Results

5.7.2. Examine Tolerance Ranges and Exact Numbers

5.7.3. Log and Address Defects

5.8. Facilitate the Go/No-Go Decision

5.9. Obtain Signoff of the Solution

5.10. Evaluate the Long-Term Performance of the Solution

5.10.1. Determine Metrics

5.10.2. Obtain Metrics/Measure Performance

5.10.3. Analyze Results

5.10.4. Assess Limitations of the Solution and Organization

5.10.5. Recommend Approach to Improve Solution Performance

5.11. Solution Replacement/Phase out