BA Methodology & Standards

BABOK (Business Analysis Body of Knowledge)

The global standard for business analysis practice, published by the International Institute of Business Analysis (IIBA). Defines the knowledge areas, tasks, techniques, and competencies that constitute the BA discipline. The current edition (v3) covers six knowledge areas: Business Analysis Planning and Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management, Strategy Analysis, Requirements Analysis and Design Definition, and Solution Evaluation.

IIBA (International Institute of Business Analysis)

The professional association for business analysis practitioners worldwide, with over 30,000 members across 120 chapters. Publishes the BABOK Guide, administers BA certifications (ECBA, CCBA, CBAP, CCA, CBDA), and produces the annual Global State of Business Analysis report.

CBAP (Certified Business Analysis Professional)

The senior-level professional certification for business analysts, administered by IIBA. Requires a minimum of 7,500 hours of BA work experience in the last 10 years, 900 hours across at least two knowledge areas, 21 hours of professional development, and two references. Recognized as the industry benchmark for experienced BA practitioners.

PMI-PBA (Professional in Business Analysis)

Business analysis certification offered by the Project Management Institute. Requires 4,500–7,500 hours of BA experience depending on education level, plus 2,000 hours working on project teams. Emphasizes the intersection of project management and business analysis disciplines.

Business Analysis Planning

The knowledge area covering how BA work is organized and coordinated. Includes stakeholder analysis, governance planning, information management approach, and performance improvement planning. Produces the BA approach document that guides all subsequent analysis activities on a project.

Solution Evaluation

The BABOK knowledge area focused on assessing the performance of a delivered solution against the business need it was designed to address. Covers performance analysis, solution limitations assessment, and recommendations for improvement. The analytical discipline that turns post-launch reviews from opinions into evidence-based assessments.

Requirements Engineering

BRD (Business Requirements Document)

A formal document that describes the business need, scope, and high-level requirements for a project or initiative. Defines what the organization needs at a strategic level before functional or technical requirements are specified. Typically produced during the Discovery & Strategy or early Analysis & Design phase.

FRS (Functional Requirements Specification)

A detailed document that defines what a system must do — specific behaviours, functions, and capabilities. Describes inputs, outputs, business rules, data handling, and user interactions in sufficient detail for development teams to build from. Distinguished from non-functional requirements (NFRs) which address how the system performs.

User Story

A short, plain-language description of a desired feature or capability from the perspective of the user, following the pattern: “As a [role], I want [capability] so that [benefit].” Used primarily in Agile methodologies. Effective user stories include defined acceptance criteria that developers can estimate against and testers can validate.

Acceptance Criteria

Specific, testable conditions that a deliverable must satisfy to be accepted by stakeholders. Defined during requirements analysis and used during UAT to verify that what was built matches what was specified. The single most important artifact for preventing the “that’s not what we asked for” moment during delivery.

RTM (Requirements Traceability Matrix)

A document that maps each requirement from its origin (business objective) through its specification (functional requirement or user story) to its validation (test case and acceptance criterion). Ensures nothing gets lost between what was asked for and what gets tested. The backbone of requirements management across the delivery lifecycle.

Elicitation

The process of drawing out, uncovering, and gathering requirements from stakeholders and other sources. Techniques include interviews, workshops, observation, document analysis, prototyping, surveys, and focus groups. Effective elicitation goes beyond recording what stakeholders say to uncovering what the project actually needs.

MoSCoW Prioritization

A technique for categorizing requirements into four priority levels: Must have (non-negotiable for go-live), Should have (important but not critical), Could have (desirable if time/budget allows), and Won’t have (explicitly out of scope for this release). Widely used in Agile and DSDM methodologies for scope negotiation.

NFR (Non-Functional Requirement)

Requirements that define how a system performs rather than what it does. Covers performance, scalability, security, availability, accessibility, usability, and compliance characteristics. Often overlooked during analysis and discovered during testing or production — when they are most expensive to address.

Gap Analysis

A comparison of current-state capabilities against desired future-state requirements to identify what is missing. Produces a list of functional, technical, or process gaps that the solution must address. Used during vendor evaluation, platform selection, and migration planning.

Decision Table

A tabular representation of complex business rules showing the relationship between conditions (inputs) and actions (outputs). Each column represents a unique combination of conditions and the corresponding action. Used to validate business logic completeness and eliminate contradictions before development begins.

Process Modelling & Design

BPMN (Business Process Model and Notation)

The international standard (ISO 19510) for business process modelling. Uses a standardized set of graphical elements — events, activities, gateways, and flows — to represent business processes in a way that is understandable to both business stakeholders and technical teams. The common language between process owners and system designers.

Swimlane Diagram

A process flow diagram that divides activities into horizontal or vertical lanes, with each lane representing a role, department, or system responsible for those activities. Makes handoffs, responsibilities, and process ownership visually explicit. Essential for identifying where processes break down at organizational boundaries.

Current-State Analysis (As-Is)

Documentation and modelling of how a process, system, or workflow currently operates before any changes are made. Establishes the baseline against which the future state is designed and measured. Without an accurate as-is model, the to-be design risks encoding existing inefficiencies or missing critical dependencies.

Future-State Design (To-Be)

The target model of how a process, system, or workflow should operate after the solution is implemented. Designed against validated requirements and constrained by technical feasibility, organizational capacity, and regulatory requirements. The bridge between what stakeholders want and what gets built.

Use Case

A description of how a user (actor) interacts with a system to achieve a specific goal. Documents the main success scenario, alternative paths, and exception handling. More detailed than a user story and typically used in systems analysis to specify complex interaction sequences.

Value Stream Mapping

A lean management technique that visualizes the end-to-end flow of materials and information required to deliver a product or service. Identifies value-adding steps, non-value-adding steps, and wait times. Used in business analysis to identify process optimization opportunities before automation or system changes.

DFD (Data Flow Diagram)

A graphical representation of how data moves through a system or process. Shows data sources, destinations, storage points, and transformations. Used in systems analysis to understand information flows before designing technical solutions. Levels range from context diagrams (Level 0) to detailed process decomposition (Level 2+).

Data & Integration

ERD (Entity-Relationship Diagram)

A data modelling diagram that represents the logical structure of a database or data domain. Shows entities (objects), their attributes, and the relationships between them. Used during Analysis & Design to define data requirements before database design begins.

Data Dictionary

A structured catalogue of all data elements in a system or domain, including field names, data types, allowed values, validation rules, and business definitions. Ensures that business stakeholders and technical teams share the same understanding of what each piece of data means and how it is constrained.

API (Application Programming Interface)

A set of defined protocols and tools that allow different software systems to communicate with each other. APIs specify what data can be exchanged, in what format, and under what authentication and authorization rules. The integration contracts that make multi-system environments function.

ETL (Extract, Transform, Load)

The process of extracting data from source systems, transforming it to meet target format and quality requirements, and loading it into a destination system. Central to data migration, data warehouse population, and integration projects. The transformation logic is where most data quality issues surface — and where BA analysis adds the most value.

Data Lineage

The documented path of a data element from its point of origin through all transformations, storage locations, and consumption points. Critical for regulatory compliance, data quality troubleshooting, and impact analysis when source systems change.

Middleware

Software that acts as a bridge between different applications or systems, enabling them to exchange data and communicate without direct point-to-point connections. Examples include message brokers, ESBs (Enterprise Service Buses), and iPaaS (Integration Platform as a Service) solutions. The plumbing that makes enterprise integration work.

Data Quality Assessment

A systematic evaluation of data against defined quality dimensions: accuracy, completeness, consistency, timeliness, validity, and uniqueness. Performed before data migration, BI implementation, or any initiative that depends on data being correct. The BA deliverable that prevents building analytics on unreliable foundations.

Semantic Layer

An abstraction layer between raw data storage and end-user reporting tools that translates technical database structures into business-friendly terminology. Defines standard calculations, hierarchies, and relationships so that all reports produce consistent answers regardless of who builds them. The missing layer in most failed BI implementations.

Agile & Delivery

Agile

A family of iterative delivery methodologies that prioritize working software, customer collaboration, and responsiveness to change over comprehensive upfront planning. Common frameworks include Scrum, Kanban, and SAFe. Requires business analysis discipline to prevent “agile” from becoming “no requirements.”

Scrum

An Agile framework organized around fixed-length iterations (sprints, typically 2 weeks), with defined roles (Product Owner, Scrum Master, Development Team) and ceremonies (sprint planning, daily standup, sprint review, retrospective). The Product Owner role carries BA responsibilities for backlog management and acceptance criteria definition.

SAFe (Scaled Agile Framework)

An enterprise framework for scaling Agile practices across large organizations with multiple teams, programs, and portfolios. Defines roles, events, and artifacts at team, program, and portfolio levels. Requires business analysis capability at every level to maintain requirements coherence across scale.

Sprint

A fixed-duration iteration (typically 1–4 weeks) in which a development team delivers a potentially shippable product increment. Each sprint begins with planning (selecting stories from the backlog) and ends with review (demonstrating completed work) and retrospective (process improvement).

Product Backlog

An ordered list of everything that might be needed in a product, maintained by the Product Owner. Contains user stories, defects, technical debt, and enablers. The single authoritative source for what the team will work on. Effective backlogs reflect analytical rigour in story definition, not just a list of feature requests.

Definition of Done (DoD)

The shared understanding within an Agile team of what criteria must be met before a product backlog item or sprint increment is considered complete. Typically includes code complete, unit tested, peer reviewed, acceptance criteria met, documentation updated, and deployed to staging environment.

UAT (User Acceptance Testing)

The final testing phase where business stakeholders validate that the delivered solution meets their requirements and is fit for purpose. Success depends on clearly defined acceptance criteria established during analysis. When UAT fails repeatedly, the root cause is almost always in the requirements, not the build.

Story Mapping

A technique for organizing user stories into a two-dimensional grid that shows the user journey (horizontal) and implementation priority (vertical). Helps teams visualize the complete user experience, identify gaps, and plan releases that deliver coherent user value rather than disconnected features.

Change Management & Adoption

ADKAR Model

A change management framework developed by Prosci that describes the five sequential outcomes individuals must achieve for change to succeed: Awareness of the need for change, Desire to participate, Knowledge of how to change, Ability to implement new skills, and Reinforcement to sustain the change. Used to diagnose where resistance is occurring and design targeted interventions.

Change Impact Analysis

A systematic assessment of how a proposed change affects each role, team, process, and system in the organization. Documents what changes for whom, how significantly, and what support is needed. The analytical foundation for training design, communication targeting, and resistance management.

Stakeholder Analysis

The process of identifying all individuals and groups affected by or capable of influencing a project, assessing their interest, influence, and likely disposition toward the change. Produces stakeholder maps, influence diagrams, and engagement strategies. The BA deliverable that determines whether the right people are in the right conversations.

Adoption Rate

A metric measuring the percentage of target users who are actively using a new system or process as intended. Distinguished from login frequency (which measures access) and feature utilization (which measures depth of use). The outcome metric that determines whether a system implementation actually delivered its business case.

RACI Matrix

A responsibility assignment chart that defines who is Responsible (does the work), Accountable (owns the decision), Consulted (provides input), and Informed (receives updates) for each task, deliverable, or decision in a project. Prevents the two most common governance failures: nobody owning a decision, and everybody thinking somebody else owns it.

Readiness Assessment

A structured evaluation of an organization’s preparedness for a specific change, covering awareness, capability, capacity, and willingness dimensions. Performed before go-live to identify groups that need additional support and predict where adoption barriers will emerge.

Business Intelligence & Analytics

KPI (Key Performance Indicator)

A quantifiable measure used to evaluate the success of an organization, project, or process in meeting defined objectives. Effective KPIs include a clear calculation method, data source, measurement frequency, target value, and owner. The difference between a useful KPI and a vanity metric is whether it drives a decision.

Dashboard

A visual display of the most important information needed to achieve one or more objectives, consolidated on a single screen. Designed around the decisions it must support, not the data that is available. The most common failure mode is building dashboards that show data without informing decisions.

Data Visualization

The graphical representation of data and information using charts, graphs, maps, and other visual elements. Effective visualization makes patterns, trends, and outliers immediately apparent. The BA contribution to visualization is ensuring the right question is being answered before the right chart is chosen.

BI (Business Intelligence)

The technologies, practices, and strategies used to collect, integrate, analyse, and present business data to support better decision-making. Includes data warehousing, reporting, dashboarding, ad-hoc analysis, and embedded analytics. The technology layer is only as good as the requirements and data model underneath it.

Data Warehouse

A centralized repository that stores integrated data from multiple sources, optimized for query and analysis rather than transaction processing. Designed around a dimensional model (fact and dimension tables) that supports the reporting and analytics requirements defined during BI analysis.

Power BI / Tableau / Zoho Analytics

The three BI platforms most frequently encountered in mid-market and enterprise BA engagements. Power BI integrates with the Microsoft ecosystem. Tableau leads in data visualization flexibility. Zoho Analytics serves organizations using the Zoho platform. Platform selection should follow requirements analysis, not precede it.

Technology & Platforms

ERP (Enterprise Resource Planning)

An integrated software platform that manages core business processes including finance, HR, supply chain, manufacturing, and operations. Examples: SAP, Oracle, Microsoft Dynamics 365, Infor, Acumatica. ERP implementations are among the most requirements-intensive IT projects, with the highest penalty for getting the analysis wrong.

CRM (Customer Relationship Management)

Software that manages an organization’s interactions with customers and prospects. Covers sales pipeline management, marketing automation, customer service, and analytics. Examples: Salesforce, Dynamics 365, HubSpot, Zoho CRM. BA involvement focuses on process alignment, data migration, integration requirements, and user adoption.

Low-Code Platform

A development environment that enables application creation through visual interfaces and configuration rather than traditional hand-coding. Examples: Microsoft Power Apps, OutSystems, Mendix. Accelerates delivery but requires the same requirements discipline as any other platform — building the wrong thing faster is not an improvement.

RPA (Robotic Process Automation)

Software bots that automate repetitive, rule-based tasks across existing systems without modifying the underlying applications. Examples: UiPath, Blue Prism, Automation Anywhere, Microsoft Power Automate. BA involvement focuses on process documentation, automation candidate identification, bot specification, and exception handling rules.

iPaaS (Integration Platform as a Service)

A cloud-based platform for building, deploying, and managing integrations between applications and data sources. Examples: MuleSoft, Boomi, Workato, Microsoft Azure Integration Services. The middleware layer that connects enterprise systems without point-to-point spaghetti.

Headless CMS

A content management system that separates content creation and storage (the back end) from content presentation (the front end). Content is delivered via APIs to any channel — web, mobile, IoT, digital signage. Requires BA involvement to define content models, workflow requirements, and integration specifications.

SaaS (Software as a Service)

Software delivered as a cloud-hosted service on a subscription basis, rather than installed on-premise. Most modern business applications are SaaS. BA involvement shifts from implementation to configuration: defining how the platform’s existing capabilities map to business requirements and where customization or integration is needed.

Project Management & Governance

SDLC (Software Development Life Cycle)

The structured process for planning, creating, testing, and deploying a software system. Common models include waterfall (sequential), Agile (iterative), and hybrid approaches. Business analysis activities span the entire SDLC, with the heaviest concentration in the planning and early build phases.

Scope Creep

The uncontrolled expansion of project scope without corresponding adjustments to timeline, budget, or resources. Typically caused by incomplete requirements, unclear acceptance criteria, or poor change control processes. The single most preventable cause of IT project failure, and the primary reason dedicated analysis exists.

Change Control

The formal process for evaluating, approving, and tracking changes to project scope, requirements, or deliverables after the baseline has been established. Requires a change request, impact analysis, approval authority, and traceability update. Without change control, every scope discussion is a negotiation without ground rules.

Business Case

A document that justifies the investment in a project by comparing the expected costs against the projected benefits. Includes problem statement, proposed solution, cost-benefit analysis, risk assessment, and success criteria. The analytical foundation that determines whether a project should exist at all.

Waterfall

A sequential project management methodology where each phase (requirements, design, build, test, deploy) must be completed before the next begins. Appropriate for projects with well-understood, stable requirements and regulatory documentation needs. Requires the most rigorous upfront analysis of any methodology.

Hybrid Methodology

An approach that combines elements of waterfall and Agile to suit the project context. Common pattern: waterfall for governance, compliance, and high-level planning; Agile for delivery within defined phases. Reflects the reality that most enterprise projects do not fit neatly into a single methodology.

PDD (Process Design Document)

A detailed document that specifies how a process, workflow, or automated bot should function. Includes step-by-step logic, decision rules, exception handling, inputs, outputs, and system interactions. Commonly used in RPA projects to define bot specifications and in BPM initiatives to document redesigned processes.