Module 5: Business Analysis Domains Flashcards
Business Analysis Planning
L(Laying the foundation)
The process of determining how business needs and requirements will be identified, analyzed, and managed throughout a project. It ensures alignment between project goals and business objectives.
Key Aspects:
Defines how requirements will be gathered and documented.
Identifies stakeholders and their roles.
Establishes tools, techniques, and methodologies for analysis.
Plans for risk management and change control.
Ensures business needs are met effectively.
Needs Analysis
(Understanding the problem)
Business analysis work that is conducted to analyze a current problem or opportunity (usually starts with talking to sponsors and reviewing the project charter)
Requirements Elicitation and Analysis
(Gathering and Refining Requirements)
The process of gathering, understanding, refining, and documenting project requirements to ensure they align with business needs and stakeholder expectations.
Traceability and Monitoring
(Tracking Requirements Implementation)
Refers to tracking requirements throughout the project lifecycle to ensure they are met and aligned with business objectives.
Solution Evaluation
(Measuring Success)
The process of assessing whether a delivered solution meets business needs and provides the expected value. It ensures that the implemented system, product, or process achieves its intended objectives
Key Business Analysis Planning Activities
Identifying stakeholders
Understanding and engaging with stakeholders
Requirements management
Evaluation of success
Project approach - predictive, adaptive, or hybrid approach
Business Analysis Plan
Describes how the requirements will be elicited, analyzed, documented, and managed across the project
Requirements Management Plan
Covers planning decisions for both the product and project requirements
Who is consulted during the Needs Analysis?
Sponsor
Product Owner
SMEs
End Users
Solution Team
Situation Statement
A concise description of a business problem, opportunity, or current state that needs to be addressed in a project or initiative. It helps stakeholders understand the context and justification for the project.
“The problem of A has the effect of B with the impact of C”
Benchmarking
The process of comparing metrics or processes from one organization against those of a similar organization
“Sizing Up” the Situation
The process of gathering data to understand the problem or opportunity
Document Analysis (Elicitation Technique)
An elicitation technique used to analyze existing documentation and find relevant information
Pro = fast approach to gather insights
Con = documents may be out of date
Interviews (Elicitation Technique)
Speaking with stakeholders to gather their insights and perspectives
Pro = opportunity to collect info from a small number of people; can reduce confusion seen in larger methods (ie workshops)
Con = since input is limited, perspectives could be biased
Observation (Elicitation Technique)
Observing different habits or occurrences to understand the normal flow to understand how a process/product is performed/used
Types of Observation: passive, active, participatory, simulation
Pro = can collect requirements from a small number of people
Con = since input is limited, perspectives could be biased; can miss information is not discussed and only seen
Questionnaire/Survey (Elicitation Technique)
Written set of questions designed to quickly gather information from many people
Pro = easily quantifies information, rank options, and fast to implement
Con = too many questions can be fatiguing, people may not want to do (need incentive), results may be skewed if the responder is not competent (not as much control)
Tools for Assessing Current States of an Organization (7 tools)
@ Pareto Diagram - bar and line graph that helps identify significant causes of a problem where 800% if issues come from 20% of causes
@ Process Flow - visual representation of a workflow; used to find inefficiencies
@ Value Stream Map - detailed flowchart that visualizes steps, inputs, and outputs of a process to identify insufficiencies
@ Root Cause Analysis - problem-solving method to identify an underlying cause of a problem
@ Ishikawa Diagram - cause and effect diagram (aka fishbone diagram)
@Five Why’s - asking why five times to drill down to the root cause of a problem
@ SWOT Analysis - assesses a business’s strengths, weaknesses, opportunities, and threats
Tools for Defining Future States (7 tools)
@ Affinity Diagram - brainstorming tool that organizes ideas, issues, or data into logical groups based on their relationships
@ Feature Model - visual model showing the hierarchical relationships between core, optional, and alternative features
@ Gap Analysis - comparison between current state and desired future state
@ Kano Analysis - customer satisfaction model that categorizes product features into basic, performance, and excitement attributes
@ Process Flow - step-by-step diagram or chart that outlines how a process works
@ Alignment Model - strategic tool that ensures business goals, processes, and tech are aligned for optimal performance
@ Solution Capability Matrix - matrix that maps solution features or capabilities against business needs
Cost-Benefit Analysis
A financial analysis tool that compares portfolio components, programs, or project benefits to costs
Elicitation
Gathering information from stakeholders, documents, and other sources to understand the requirements for a project
Feature Injection
A process that helps teams identify and prioritize the most valuable features by focusing on business outcomes first and working backwards to determine necessary functionalities
Valuation
Determining the financial value a solution may bring to a company
Determined through:
Internal Rate of Return (IRR) - higher IRR = higher return
Net Present Value (NPV) - higher NPV = greater value is expected
Pay Back Period (PBP) - Longer PBP = greater risk over time
Return on Investment (ROI) - higher ROI = higher value
Product Roadmap
A high-level overview presenting a product’s features and outlines the vision, direction, and key milestones for a product over time
May include:
Strategy information - strategy and how it aligns with business strategy
Portfolio - how the product is tied to the portfolio
Initiatives - how it ties to other projects/initiatives
Product Vision - how this meets customer needs
Success Criteria - metrics determining solution success
Market Focus - analysis of the market
Features - product capabilities
Timeline - timeline to deliver features
Business Case
A document that justifies the need for a project by outlining its benefits, costs, risks, and potential ROI
Components
Executive Summary - overview of project
Problem Statement - the business need
Proposed Solution - recommended approach
Benefits & Value - expected outcomes & advantages
Cost Analysis - estimated budget, resources, and funding requirements
Risk Assessment - potential risks
Implementation Plan - timeline, milestones, key deliverables
Conclusion & Recommendation - final justification for approval
Project Charter
A document that officially authorizes a project, outlining its objectives, scope, stakeholders, and key constraints
Provides a high-level overview and serves as a reference throughout the rest of the project lifecycle
Business Analyst (what & why) works with PM (how & when) to make Solution
(Business + PM = Solution)
How to Prepare for Elicitation
Determine the objective
Determine the participants
Identify resources - existing systems or documents
Identify Questions
Set the Agenda
Schedule when to do the Elicitation Activity (interview, survey, workshop, etc)
Brainstorming (Elicitation Technique)
A group generating novel idea; diverging and converging ideas
Pro = generate numerous ideas
Con = only high level ideas, not as detailed
Workshops
Facilitated, focused sessions that connect stakeholders with one another and capture their needs and define solution scope
Pro = large, structured, and can have lots of people from many departments
Con = can be too long so people do not want to attend
Focus Groups
Structured discussion with a specific group of stakeholders to gather insights, opinions, and requirements
Pro = validate ideas/solutions from experts
Con = only focuses on the problems discussed and not a wider range/high level
Prototyping & Storyboarding (Elicitation Technique)
Prototyping - a working model of the expected product to gain feedback
@ Low-fidelity (low accuracy) - conceptual
@ High-fidelity (high accuracy) - high in details that may be thrown out or further developed over time (evolutionary)
Storyboarding - prototyping technique that shows a sequence through a series of pictures
Pros = makes it easier to gain feedback and understand user requirements clearly
Cons = can be time consuming, scope creep risk, resource intensive, not great for $$$ or complex systems
Analyzing Requirements
Determine analysis approach
Create and analyze models
Define and elaborate on requirements
Define acceptance criteria
Verify requirements
Validate requirements
Prioritize requirements
Scope Model (Business Analysis Model)
Models that define the project scope by structuring and organizing the business domain being analyzed
Ecosystem Map (Scope Model - Business Analysis)
A visual representation of all key entities, relationships, and interactions within a project’s environment
Allows us to understand the scope, dependencies, and external influences
Scope Statement (Scope Model - Business Analysis)
A document specifying the requirements for a project and scribes what features are within or outside of the scope
Context Diagram (Scope Model - Business Analysis)
A high-level visual representation of a system and its interaction with external entities showing the system’s boundaries, inputs, outputs, and key stakeholders
Process Models (Business Analysis Model)
Models that describe the step9by-step movement of data, resources, or documents in the context of the organization
Process Flow Diagram (Process Model - Business Analysis)
A visual representation of a workflow or sequence including the steps people perform when implementing a solution. Shows how the tasks, decisions, and processes flow from start to finish
Narrative Use Case (Process Model - Business Analysis)
A detailed step-by-step description of how a user (actor) interacts with a system to achieve a specific goal
Includes:
Actor
Goal
Preconditions - requirements that must be met before the process begins
Main Flow (Primary Scenario) - sequence of actions leading to success
Alternative Flows - variations of the process
Exceptions (Error Handling) - what happens if something goes wrong
Postconditions - result of successful process completion
User Stories (Process Model & Business Analysis)
A simple, informal description of a feature or requirement from the perspective of an end-user
INVEST:
Independent - not reliant on other stories
Negotiable - flexible and open to discussion
Valuable - provides clear business value
Estimable - able to pull and plan from it
Small - smaller and manageable
Testable - measurable and ale to be validated
Story Map (Process Model & Business Analysis)
Visual representation of user stories by priority and workflow to help teams understand the user journey
X-axis = time
Y-axis = priority (higher = higher priority)
Grouping Stories by Release Stage (Process Model & Business Analysis)
Organizing user stories into planned development phases or product releases. Helps prioritize features and deliver value incrementally.
Rule Models (Business Analysis Models)
Shows business constraints that a proposed solution must enforce
Business Rules Catalog & Business Rules (Rule Models & Business Analysis)
A structured document that lists all the business rules governing an organization, system, or project
Business rule: Constraints, policies, or conditions that govern business operations; these are NOT requirements
(requirements are needs that define what a system/project must do; not as broad as a business rule which is for business procedures)
Decision Trees (Rule Models & Business Analysis)
A visual flowchart that helps in decision making by mapping out different choices, their possible outcomes, and associated risks or rewards
Decision Tables (Rule Models & Business Analysis)
A structured way of representing business rules, conditions, and their corresponding actions in a table format
Data Models (Business Analysis Models)
Models that document data stores and the flow of data
Entity Relationship Diagram (Data Models & Business Analysis)
(aka ERD)
A visual representation of data and its relationships within a system
Cardinality - defines how many instances of one entity to relate to another (e.g. one customer can place multiple orders)
Data Dictionary (Data Models & Business Analysis)
A centralized document that provides detailed definitions and descriptions of data elements within a system, database, or project
Data Flow Diagram (Data Models & Business Analysis)
A visual representation of how data moves through a system showing where data comes from, how it is processed, and where it goes
External entitles can be actors of systems
Interface Models (Business Analysis Models)
Models that present how a user may see or interact with different screens/interfaces and their details
Wireframe (Interface Model & Business Analysis Model)
A two-dimensional representation of an interface to present what it may look like (commonly used for website and app development)
Displace-Action-Response (Interface Models & Business Analysis)
How a system user’s interface (UI) redirects/shifts an action when the original action cannot be completed as intended
Ensures continuity, user guidance, and system stability
User Interface Flows (Interface Models & Business Analysis)
A visual representation of user interfaces and how to navigate between each screen
Report Tables (Interface Models & Business Analysis)
A structured data presentation format that displays key information, metrics, or progress in a clear and organized way
Commonly used in dashboards, project management tools, and business intelligence reports
What needs to be Traced in Traceability and Monitoring?
Goal: to track the relationships between different project elements to ensure alignment, completeness, and control throughout the project
To be Traced:
Business Needs & Objectives
Requirements
Stakeholder Requests & Change Requests
Design & Solution Components
Test Cases & Validation
Development & Implementation
Defects & Issues
Regulatory & Compliance Requirements
Deployment & Releases
Training & Documentation
Requirements Traceability Matrix
A document or tool to track the relationship between requirements and project deliverables throughout the project. Makes sure that every requirement is accounted for, implemented, tested, and verified
Types of Approval - Approval, Sign-Off, Review, Approver, Accountability, Rejection of Requirements, Approval of Changes
@ Approval - when a stakeholder agrees that a requirement meets necessary criteria
@ Sign-Off - formal confirmation that something is approved
@ Review - someone who reviews the deliverable and provides feedback, but may not have decision-making authority
@ Approver - a person with the authority to officially accept/reject an item
@ Accountability - the person responsible for ensuring the project meets business needs (may not have decision-making authority)
@ Rejection of Requirements - when a project does not meet business needs
@ Approval of Changes - formally approving modifications to requirements, scope, budget, or schedule
Solution Evaluation Process
1) Determine a solution evaluation approach (how, when, and by whom?)
2) evaluation solution performance (delivers on intended business value?)
3) evaluate the deployed solution (post-implementation review, identify perform gaps)
4) Evaluate acceptance results and address defects (resolve product problems)
5) Obtain solution acceptance for release (is solution ready for full deployment?)
Test-Driven Approach (TDA)
Development and analysis method where tests are written before implementing the actual solution
Test-Driven Development (Test-Driven Approach)
Development method primarily used in software engineering where unit tests are written before coding
Acceptance Test-Driven Development (Test-Driven Approach)
Development method that focuses on customer or business requirements ensuring solutions align with stakeholder expectations
Behavior-Driven Development (Test-Driven Approach)
Development method that uses natural language to define expected system behavior, improving collaboration between technical and non-technical teams
When is performance measured?
Predictive - at the very end of a project
Adaptive - incrementally throughout the project (whenever an MVP is made)
Who conducts solution evaluation?
Project sponsor
Business Analyst
Other stakeholders
Validation (Solution Evaluation)
Ensuring that the requirements for a product solve the problem (“are we building the right product?”)
Verification & Verification Types (Solution Evaluation)
Ensures that the product adheres to the project specifications and instructions (“are we building the product right?”)
Types of Verification:
Peer reviews
Inspections
