Skip to content
The Standard
BABOK Applied
Agile Extension
Business Data Analytics
Product Ownership Analysis
The Standard
BABOK Applied
Agile Extension
Business Data Analytics
Product Ownership Analysis
10. Techniques
Introduction 10.1 Acceptance and Evaluation Criteria 10.2 Backlog Management 10.3 Balanced Scorecard 10.4 Benchmarking and Market Analysis 10.5 Brainstorming 10.6 Business Capability Analysis 10.7 Business Cases 10.8 Business Model Canvas 10.9 Business Rules Analysis 10.10 Collaborative Games 10.11 Concept Modelling 10.12 Data Dictionary 10.13 Data Flow Diagrams 10.14 Data Mining 10.15 Data Modelling 10.16 Decision Analysis 10.17 Decision Modelling 10.18 Document Analysis 10.19 Estimation 10.20 Financial Analysis 10.21 Focus Groups 10.22 Functional Decomposition 10.23 Glossary 10.24 Interface Analysis 10.25 Interviews 10.26 Item Tracking 10.27 Lessons Learned 10.28 Metrics and Key Performance Indicators (KPIs) 10.29 Mind Mapping 10.30 Non-Functional Requirements Analysis 10.31 Observation 10.32 Organizational Modelling 10.33 Prioritization 10.34 Process Analysis 10.35 Process Modelling 10.36 Prototyping 10.37 Reviews 10.38 Risk Analysis and Management 10.39 Roles and Permissions Matrix 10.40 Root Cause Analysis 10.41 Scope Modelling 10.42 Sequence Diagrams 10.43 Stakeholder List, Map, or Personas 10.44 State Modelling 10.45 Survey or Questionnaire 10.46 SWOT Analysis 10.47 Use Cases and Scenarios 10.48 User Stories 10.49 Vendor Assessment 10.50 Workshops


Terms and definitions; a foundational component of the global standards of business analysis.


Acceptance criteria

Criteria associated with requirements, products, or the delivery cycle that must be met in order to achieve stakeholder acceptance.

Acceptance test driven development

Occurs when team members with different perspectives (customer, development, testing) collaborate to identify acceptance criteria and subsequent tests in advance of implementing thecorresponding functionality. These acceptance tests represent the user's point of view and act as a form of requirements to describe how the system will function, as well as serve as a way of verifying that the system functions as intended. In some cases the team automates the acceptance tests.

Actor (business analysis)

A human, device, or system that plays some specified role in interacting with a solution.

Adaptive approach

An approach where the solution evolves based on a cycle of learning and discovery, with feedback loops which encourage making decisions as late as possible.

Adaptive planning

An approach where long-term plans are reviewed and revised to account for new information learned during a project. Refer to the Agile Extension to the BABOK® Guide.

Agile Extension to the BABOK® Guide

A standard on the practice of business analysis in an agile context. The Agile Extension to the BABOK® Guide version 1 was published in 2013 by IIBA®, in partnership with the Agile Alliance.

Agile manifesto

A statement of the values that underpin Agile Software Development. It was drafted from February 11th through 13th, 2001.


See requirements allocation.


A commonly used, yet ineffective, process or practice.


The design, structure, and behaviour of the current and future states of a structure in terms of its components, and the interaction between those components. See also business architecture, enterprise architecture, and requirements architecture.

Artifact (business analysis)

Any solution-relevant object that is created as part of business analysis efforts.


An influencing factor that is believed to be true but has not been confirmed to be accurate, or that could be true now but may not be in the future.


see acceptance test driven development.



An ordered list of options that represent changes to a solution. Various frameworks use backlogs to represent the changes for a given scope.

Backlog item

An element on a backlog that represents a potential change to a product. Backlog items can take the form of user stories, spikes, defects, infrastructure work, refactors, documents or other item types that a team finds useful in their context.


See behaviour driven development.

Behavioural business rule

 A business rule that places an obligation (or prohibition) on conduct, action, practice, or procedure; a business rule whose purpose is to shape (govern) day-to-day business activity. Also known as operative rule.


A comparison of a decision, process, service, or system's cost, time, quality, or other metrics to those of leading peers to identify opportunities for improvement.

Body of knowledge

The aggregated knowledge and generally accepted practices on a topic.


See business process management.


A team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.

Business (business analysis)

See enterprise.

Business (business world)

An economic system where any commercial, industrial, or professional activity is performed for profit.

Business analysis

The practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders.

Business analysis information

Any kind of information at any level of detail that is used as an input to, or is an output of, business analysis work.

Business analysis package

A document, presentation, or other collection of text, matrices, diagrams and models, representing business analysis information.

Business Analysis Professional

Any person who performs business analysis, no matter their job title, organizational role, seniority level, or frequency of performing it.

Business analyst

Any person who performs business analysis, no matter their job title or organizational role.

Business analysis approach

The set of processes, rules, guidelines, heuristics, and activities that are used to perform business analysis in a specific context.

Business Analysis as a Service (BAaS)

The provision of business analysis work as a service, usually to other business units or initiatives from a centralized collection of business analysis professionals.

Business analysis communication plan

A description of the types of communication the business analyst will perform during business analysis, the recipients of those communications, and the form and frequency of those communications.

Business analysis plan

A description of the planned activities the business analyst will execute in order to perform the business analysis work involved in a specific initiative. See also requirements management plan.

Business architecture

The design, structure, and behaviour of the current and future states of an enterprise to provide a common understanding of the organization. It is used to align the enterprise’s strategic objectives and tactical demands.

Business case

A justification for a course of action based on the benefits to be realized by using the proposed solution, as compared to the cost, effort, and other considerations to acquire and live with that solution.

Business decision

A decision that can be made based on strategy, executive judgment, consensus, and business rules, and that is generally made in response to events or at defined points in a business process.

Business domain

See domain.

Business goal

A state or condition that an organization is seeking to establish and maintain, usually expressed qualitatively rather than quantitatively.

Business need

A problem or opportunity of strategic or tactical importance to be addressed.

Business objective

An objective, measurable result to indicate that a business goal has been achieved.

Business policy

A non-practicable directive that controls and influences the actions of an enterprise.

Business problem

An issue of strategic or tactical importance preventing an enterprise or organization from achieving its goals.

Business process

An end-to-end set of activities which collectively responds to an event, and transforms information, materials, and other resources into outputs that deliver value directly to the customers of the process. It may be internal to an organization, or it may span several organizations.

Business process management (BPM)

A management discipline that determines how manual and automated processes are created, modified, cancelled, and governed.

Business process re-engineering

Rethinking and redesigning business processes to generate improvements in performance measures.

Business requirement

A representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed.

Business rule

A specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behaviour, shaping judgments, or making decisions.

Business value

In management, business value is an informal term that includesall forms of value that determine the health and well-being of the firm in the long run. In agile development, an output delivers business value when it increases or protects revenue or reduces or avoids costs for an organization.



The set of activities the enterprise performs, the knowledge it has, the products and services it provides, the functions it supports, and the methods it uses to make decisions.

Cause-and-effect diagram:

See fishbone diagram.

Centre of Excellence (CoE)

A centre of excellence is a team that provides leadership, best practices, research, support, and training for business analysis. Can also be called BACoE, Business Analysis Competency Centre, Business Analysis Solution Centre. 


The act of transformation in response to a need. 

Change agent

One who is a catalyst for change.

Change control

Controlling changes to requirements and designs so that the impact of requested changes is understood and agreed-to before the changes are made.

Change management

Planned activities, tools, and techniques to address the human side of change during a change initiative, primarily addressing the needs of the people who will be most affected by the change.

Change strategy

A plan to move from the current state to the future state to achieve the desired business objectives.

Change team

A cross-functional group of individuals who are mandated to implement a change. This group may be comprised of product owners, business analysts, developers, project managers, implementation subject matter experts (SMEs), or any other individual with the relevant set of skills and competencies required to implement the change.

Checklist (business analysis)

A standard set of quality elements that reviewers use for requirements verification.


The act of two or more people working together towards a common goal.

Commercial off-the-shelf (COTS)

A prepackaged solution available in the marketplace which address all or most of the common needs of a large group of buyers of those solutions. A commercial off-the-shelf solution may require some configuration to meet the specific needs of the enterprise.

Community of Practice (CoP)

A community of practice is a group of people who share a concern or a passion for business analysis and learn how to do it better as they interact on a regular basis.

Competitive analysis

A structured assessment which captures the key characteristics of an industry to predict the long-term profitability prospects and to determine the practices of the most significant competitors.


A uniquely identifiable element of a larger whole that fulfills a clear function.

Concept model

An analysis model that develops the meaning of core concepts for a problem domain, defines their collective structure, and specifies the appropriate vocabulary needed to communicate about it consistently.

Constraint (business analysis)

An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option.


The circumstances that influence, are influenced by, and provide understanding of the change.

Context diagram

The highest level data flow diagram which represents the system in its entirety, as the area under study with external organizations, people, or systems as the source or target of data flows.

Core concept (business analysis)

One of six ideas that are fundamental to the practice of business analysis: Change, Need, Solution, Context, Stakeholder, and Value.

Cost-benefit analysis

An analysis which compares and quantifies the financial and non-financial costs of making a change or implementing a solution compared to the benefits gained.


See commercial off-the-shelf.

Create, read, update, and delete matrix (CRUD matrix)

A two-dimensional matrix showing which user roles have permission to access specific information entities, and to create new records in those entities, view the data in existing records, update or modify the data in existing records, or delete existing records. The same type of matrix can be used to show which processes, instead of users, have the create, read, update and delete rights.

CRUD matrix

See create, read, update, and delete matrix.


A stakeholder who uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet.

Customer representative

an individual who works with the team to represent theperspective of stakeholders who use or may use products or services produced by the enterprise and may have contractual or moral rights that the enterprise is obliged to meet.


Data model

A diagram that describes the entities, classes or data objects relevant to a domain, the attributes that are used to describe them, and the relationships among them to provide a common set of semantics for analysis and implementation.

Decision analysis

An approach to decision making that examines and models the possible consequences of different decisions, and assists in making an optimal decision under conditions of uncertainty.

Decision maker

Person or people responsible for making the final decision.


A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components.


A deficiency in a product or service that reduces its quality or varies from a desired attribute, state, or functionality.

Definitional business rule

A rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge, or information. Also known as a structural rule.

Definition of done

A technique where the team agrees on, and prominently displays, a list of criteria which must be met before a backlog item is considered done.

Definition of ready

A technique where the team agrees on, and prominently displays, a list of criteria which must be met before a backlog item is considered ready for the team to start delivery work.


Any unique and verifiable work product or service that a party has agreed to deliver.

Delivery team

A cross-functional team of skilled individuals who bring a variety of expertise to bear on the process of building a software product.


A usable representation of a solution.


A field of study that is researched and evolves over time.

Document analysis (business analysis)

An examination of the documentation of an existing system in order to elicit requirements.


The sphere of knowledge that defines a set of common requirements, terminology, and functionality for any program or initiative solving a problem.

Domain subject matter expert

A stakeholder with in-depth knowledge of a topic relevant to the business need or solution scope.


See Definition of Done.


See dynamic systems development method.

Dynamic systems development method (DSDM)

A project delivery framework which focuses on fixing cost, quality, and time at the beginning while contingency is managed by varying the features to be delivered.



Iterative derivation and extraction of information from stakeholders or other resources.

End user

A stakeholder who directly interacts with the solution.


A system of one or more organizations and the solutions they use to pursue a shared set of common goals.

Enterprise architecture

A description of the business processes, information technology, people, operations, information, and projects of an enterprise and the relationships between them.

Enterprise readiness assessment

An assessment that describes the enterprise is prepared to accept the change associated with a solution and is able to use it effectively.

Entity-relationship diagram

A graphical representation of the entities relevant to a chosen problem domain and the relationships between them.


A quantitative assessment of a planned outcome, resource requirements, and schedule where uncertainties and unknowns are systematically factored into the assessment.

Ethnographic elicitation techniques

Iterative derivation and extraction of information from stakeholders or other sources by observing users in their work environment and looking at business processes from the perspective of the user.


The systematic and objective assessment of a solution to determine its status and efficacy in meeting objectives over time, and to identify ways to improve the solution to better meet objectives. See also indicator; metric, monitoring.

Event (business analysis)

An occurrence or incident to which an organizational unit, system, or process must respond.

Evolutionary prototype

A prototype that is continuously modified and updated in response to feedback from stakeholders.


An approach to defining the behaviour of a system using realistic examples instead of abstract statements. Examples are often used to further describe user stories and are used both as guidance for development and testing.


Elicitation performed in a controlled manner to make a discovery, test a hypothesis, or demonstrate a known fact.

External interface

An interaction that is outside the proposed solution. It can be another hardware system, software system, or a human interaction with which the proposed solution will interact.



The art of leading and encouraging people through systematic efforts toward agreed-upon objectives in a manner that enhances involvement, collaboration, productivity, and synergy.

Feasibility study

An evaluation of proposed alternatives to determine if they are technically, organizationally, and economically possible within the constraints of the enterprise, and whether they will deliver the desired benefits to the enterprise.


A distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders.

Fibonacci scale

A scale commonly used when sizing user stories that is based on the Fibonacci Sequence – a series of numbers characterized by the fact that every number after the first two is the sum of the two preceding ones. In practice teams use a modified sequence that stops the pattern at larger numbers. Generally, the scale includes the following numbers: 0, 1, 2, 3, 5, 8,13.

Fishbone diagram

A diagramming technique used in root cause analysis to identify underlying causes of an observed problem, and the relationships that exist between those causes. Also known as an Ishikawa or cause-and- effect diagram.

Focus group

A group formed to to elicit ideas and attitudes about a specific product, service, or opportunity in an interactive group environment. The participants share their impressions, preferences, and needs, guided by a moderator.

Force field analysis

A graphical method for depicting the forces that support and oppose a change. Involves identifying the forces, depicting them on opposite sides of a line (supporting and opposing forces) and then estimating the strength of each set of forces.


A collection of specific practices and ideas that have been proven useful in a specific context that teams can use as a basis to create their own methodology.

Functional requirement

A capability that a solution must have in terms of the behaviour and information the solution will manage.


Gap analysis

A comparison of the current state and desired future state of an enterprise in order to identify differences that need to be addressed.


See business goal.

Governance process (change)

A process by which appropriate decision makers use relevant information to make decisions regarding a change or solution, including the means for obtaining approvals and priorities.

Guideline (business analysis)

An instruction or description on why or how to undertake a task.



A view of work within an organization with a level of granularityappropriate to the time frame being planned for and the nature of the feedback loops used.

Horizontal prototype

A prototype that is used to explore requirements and designs at one level of a proposed solution, such as the customer-facing view or the interface to another organization.


Impact analysis

An assessment of the effects a proposed change will have on a stakeholder or stakeholder group, project, or system.

Implementation subject matter expert

A stakeholder who has specialized knowledge regarding the implementation of one or more solution components.


A specific numerical measurement that indicates progress toward achieving an impact, output, activity, or input. See also metric.

Information radiator

A handwritten, drawn, printed, or electronic display which ateam places in a highly visible location, so that all team members as well as passers-by can see the latest information about their work at a glance.


A specific project, program, or action taken to solve some business problem(s) or achieve some specific change objective(s).

Input (business analysis)

Information consumed or transformed to produce an output. An input is the information necessary for a task to begin.


A formal review of a work product by qualified individuals that follows a predefined process, and uses predefined criteria, for defect identification and removal.


A shared boundary between any two persons and/or systems through which information is communicated.


Ability of systems to communicate by exchanging data or services.


Eliciting information from a person or group of people in an informal or formal setting by asking relevant questions and recording the responses.

Ishikawa diagram

See fishbone diagram.

Iteration (business analysis)

A single instance of progressive cycles of analysis, development, testing, or execution.

Iterative planning

An approach to planning that intentionally allows for repeating planning activities, and for potentially revisiting the same plan to update it based on new information. These planning activities are repeated in some agile approaches in regular iterations or time-boxes. Agile Extension to the BABOK® Guide


Knowledge area (business analysis)

An area of expertise that includes several specific business analysis tasks.


Lessons learned process

A process improvement technique used to learn about and improve on a process or project. A lessons learned session involves a special meeting in which the team explores what worked, what didn't work, what could be learned from the just-completed iteration, and how to adapt processes and techniques before continuing or starting a new.

Life cycle

A series of changes an item or object undergoes from inception to retirement



A textual form of modelling used to represent information that can be categorized, cross-referenced, and represented in a table format.


A description of data to help understand how to use that data, either in terms of the structure and specification of the data, or the description of a specific instance of an object.


A body of methods, techniques, procedures, working concepts, and rules used to solve a problem.


A quantifiable level of an indicator measured at a specified point in time. 

Minimal marketable feature

A small, self-contained feature that can be developed quickly and delivers significant value to the user.

Minimum viable product

A concept from Lean Startup that describes the fastestway to get through the Build-Measure-Learn feedback loop with the minimum amount of effort.

Mission statement

A formal declaration of values and goals that expresses the core purpose of the enterprise.


A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication, and understanding.


Collecting data on a continuous basis from a solution in order to determine how well a solution is implemented compared to expected results. See also metric; indicator.


See minimal marketable feature.


See minimum viable product.



A problem or opportunity to be addressed.

Non-functional requirement

A type of requirement that describes the performance or quality attributes a solution must meet. Non-functional requirements are usually measurable and act as constraints on the design of a solution as a whole.



See business objective.

Observation (business analysis)

Studying and analyzing one or more stakeholders in their work environment in order to elicit requirements.


See online analytical processing.

Online analytical processing (OLAP)

A business intelligence approach that allows users to analyze large amounts of data from different points of view.

Operational support

A stakeholder who is responsible for the day-to-day management and maintenance of a system or product.

Operative rule

See behavioural business rule.


An autonomous group of people under the management of a single individual or board, that works towards common goals and objectives.

Organizational capability

A function inside the enterprise, made up of components such as processes, technologies, and information and used by organizations to achieve their goals.

Organizational change management

See change management.

Organization modelling

The analysis technique used to describe roles, responsibilities and reporting structures that exist within an enterprise.

Organizational unit

Any recognized association of people within an organization or enterprise.


The change in the organization and changes in the behaviour ofstakeholders as a result of an initiative.


Anything that your team delivers as part of your initiative. This includes output: software, documentation, processes, and other things that tend to be measured in order to gauge how the initiative is going.


Peer review

A formal or informal review of a work product to identify errors or opportunities for improvement. See also inspection.


Fictional characters or archetypes that exemplify the way that typicalusers will interact with a product.


A detailed scheme for doing or achieving something usually comprising a set of events, dependencies, expected sequence, schedule, results or outcomes, materials and resources needed, and how stakeholders need to be involved.

Planning horizon

See Horizon.


See business policy.


An area of concentration one can become professionally engaged in, perform in, or work at repeatedly.

Predictive approach

An approach where planning and baselines are established early in the life cycle of the initiative in order to maximize control and minimize risk.

Predictive planning

An approach to planning that involves detailed analysis and planning at the beginning of the project for the duration of the project and then acting on that plan. Predictive planning is based on the assumption thatthe later a mistake is found, the more it will cost to fix it. This results in the desire to plan the entire project at the beginning of the project and avoid changes to the plan as much as possible.


Determining the relative importance of a set of items in order to determine the order in which they will be addressed.


A set of activities designed to accomplish a specific objective by taking one or more defined inputs and turning them into defined outputs.

Process model

A set of diagrams and supporting information about a process and factors that could influence the process. Some process models are used to simulate the performance of the process.

Product (business analysis)

A solution or component of a solution that is the result of an initiative.

Product backlog

A set of user stories, requirements, or features that have been identified as candidates for potential implementation, prioritized, and estimated.

Product box

A collaboration framework where a team and customers design a box for their product in order to determine the characteristics of a product that customers want to buy.

Product differentiation statement

An expression of how a given product fills a particular consumer need in a way that its competitors don’t.

Product Owner

The role on the team that represents the interests of all stakeholders, defines the features of the product, and prioritizes the product backlog. Agile Extension to the BABOK® Guide

Product roadmap

A visual representation of how a team plans to implement their product strategy over progressively longer time horizons. The product roadmap is updated frequently, and reflects outcomes the team plans to realize rather than outputs the team plans to deliver.

Product scope

See solution scope.

Product vision statement

A brief statement or paragraph that describes the goals of the solution and how it supports the strategy of the organization or enterprise.

Progressive elaboration

The act of continually defining requirements with successively greater levels of detail as needed through the life of the product or the feature within a product.


A temporary endeavour undertaken to create a unique product, service, or result.

Project manager

A stakeholder who is responsible for managing the work required to deliver a solution that meets a business need, and for ensuring that the project's objectives are met while balancing the project constraints, including scope, budget, schedule, resources, quality, and risk.

Project scope

The work that must be performed to deliver a product, service, or result with the specified features and functions.

Proof of concept

A model created to validate the design of a solution without modelling the appearance, materials used in the creation of work, or processes and workflows ultimately used by the stakeholders.


A partial or simulated approximation of the solution for the purpose of eliciting or verifying requirements with stakeholders.



The degree to which a set of inherent characteristics fulfills needs.

Quality assurance

A set of activities performed to ensure that a process will deliver products that meet an appropriate level of quality.

Quality attributes

A set of measures used to judge the overall quality of a system. See also non-functional requirements.


A set of defined questions, with a choice of answers, used to collect information from respondents.


RACI matrix

See responsible, accountable, consulted,  and informed  matrix.


A stakeholder from outside the organization who is responsible for the definition and enforcement of standards.

Relative estimation

A way of estimating work effort by identifying features/ requirements with stories and then assigning story points to stories. The cumulative story points represent the estimated amount of effort required to deliver the story. The story points are then calculated against the team's velocity to create an estimate on how much the team can deliver in a particular iteration.

Release planning

At the beginning of a project the team will create a high-level release plan. The team cannot possibly know everything upfront so a detailed plan is not necessary. The release plan should address:

- the number and duration of the iterations, 
- how many people or teams should be on this project, 
- the number of releases, the value delivered in each release,
- and the ship date for the releases.


A real or virtual facility where all information on a specific topic is stored and is available for retrieval.

Request for information (RFI)

A formal elicitation method intended to collect information regarding a vendor's capabilities or any other information relevant to a potential upcoming procurement.

Request for proposal (RFP)

A requirements document issued when an organization is seeking a formal proposal from vendors. An RFP typically requires that the proposals be submitted following a specific process and using sealed bids which will be evaluated against a formal evaluation methodology.

Request for quote (RFQ)

A procurement method of soliciting price and solution options from vendors.

Request for tender (RFT)

An open invitation to vendors to submit a proposal for goods or services.


A usable representation of a need.

Requirements attribute

A characteristic or property of a requirement used to assist with requirements management.

Requirements allocation

The process of assigning requirements to be implemented by specific solution components.

Requirements architecture

The requirements of an initiative and the interrelationships between these requirements.

Requirements artifact

A business analysis artifact containing information about requirements such as a diagram, matrix, document or model.

Requirements defect

A problem or error in a requirement. Defects may occur because a requirement is poor quality (see requirements verification) or because it does not describe a need that, if met, would provide value to stakeholders (see requirements validation).

Requirements document

See requirements package.

Requirements life cycle

The stages through which a requirement progresses from inception to retirement.

Requirements management

Planning, executing, monitoring, and controlling any or all of the work associated with requirements elicitation and collaboration, requirements analysis and design, and requirements life cycle management.

Requirements management plan

A subset of the business analysis plan for a specific change initiative, describing specific tools, activities, and roles and responsibilities that will be used on the initiative to manage the requirements. See business analysis plan.

Requirements management tool

Special-purpose software that provides support for any combination of the following capabilities: elicitation and collaboration, requirements modelling and/or specification, requirements traceability, versioning and baselining, attribute definition for tracking and monitoring, document generation, and requirements change control.

Requirements model

An abstract (usually graphical) representation of some aspect of the current or future state.

Requirements package

A specialized form of a business analysis package primarily concerned with requirements. A requirements package may represent a baseline of a collection of requirements.

Requirements traceability

The ability for tracking the relationships between sets of requirements and designs from the original stakeholder need to the actual implemented solution. Traceability supports change control by ensuring that the source of a requirement or design can be identified and other related requirements and designs potentially affected by a change are known.

Requirements validation

Work done to evaluate requirements to ensure they support the delivery of the expected benefits and are within the solution scope.

Requirements verification

Work done to evaluate requirements to ensure they are defined correctly and are at an acceptable level of quality. It ensures the requirements are sufficiently defined and structured so that the solution development team can use them in the design, development, and implementation of the solution.

Requirements workshop

A structured meeting in which a carefully selected group of stakeholders collaborate to define and/or refine requirements under the guidance of a skilled neutral facilitator.

Residual risk

The risk remaining after action has been taken or plans have been put in place to deal with the original risk.

Responsible, accountable, consulted, and informed matrix (RACI matrix)

A tool used to identify the responsibilities of roles or team members and the activities or deliverables in which they will participate, by being responsible (doing the work), accountable (approving the results), consulted (providing input) or informed of the completed item after it has been completed.


See lessons learned process.

Return on investment (ROI) (business analysis)

A measure of the profitability of a project or investment.


See request for information.


See request for proposal.


See request for quote.


See request for tender.

Risk (business analysis)

The effect of uncertainty on the value of a change, a solution, or the enterprise. See also residual risk.

Risk assessment: Identifying, analyzing and evaluating risks. ROI

See return on investment.

Rolling planning

Rolling planning is a technique whereby a team plans for an iteration for only the time period where they have reasonable certainty. As that time comes to an end the team plans out for another time period, determined by their level of certainty.

Root cause analysis

A structured examination of an identified problem to understand the underlying causes.



The boundaries of control, change, a solution, or a need.

Scope model

A model that defines the boundaries of a business domain or solution.

Secondary actor

An actor external to the system under design that supports the execution of a use case.

Sequence diagram

A type of diagram that shows objects participating in interactions and the messages exchanged between them.

Service (business analysis)

The performance of any duties or work for a stakeholder, from the perspective of the stakeholder.

Service level agreements

Formal agreements that contract level of service and performance.


See suppliers, inputs, process, outputs and customers.


See subject matter expert. 


A specific way of satisfying one or more needs in a context.

Solution component

A sub-part of a solution that can be people, infrastructure, hardware, software, equipment, facilities, and process assets or any combination of these sub-parts.

Solution option:

One possible way to satisfy one or more needs in a context. 

Solution requirement

A capability or quality of a solution that meets the stakeholder requirements. Solution requirements can be divided into two sub-categories: functional requirements and non-functional requirements or quality of service requirements.

Solution life cycle

The stages through which a solution progresses from inception to retirement.

Solution scope

The set of capabilities a solution must deliver in order to meet the business need.


See statement of work.


A stakeholder who is responsible for initiating the effort to define a business need and develop a solution that meets that need. They authorize the work to be performed and control the budget and scope for the initiative.


A group or individual with a relationship to the change, the need, or the solution.

Stakeholder analysis

Identifying and analyzing the stakeholders who may be impacted by the change and assess their impact, participation, and needs throughout the business analysis activities.

Stakeholder list

A catalogue of the stakeholders affected by a change, business need, or proposed solution, and a description of their attributes and characteristics related to their involvement in the initiative.

Stakeholder proxy (business analyst)

The role a business analyst takes when representing the needs of a stakeholder or stakeholder group.

Stakeholder requirement

A description of the needs of a particular stakeholder or class of stakeholders that must be met in order to achieve the business requirements. They may serve as a bridge between business requirements and the various categories of solution requirements.

State diagram

An analysis model showing the life cycle of a data entity or class.

Stated requirement

A requirement articulated by a stakeholder that has not been analyzed, verified, or validated. Stated requirements frequently reflect the desires of a stakeholder rather than the actual need.

Statement of work (SOW)

A written description of the services or tasks that are required to be performed.

Story mapping

A technique to facilitate the understanding of product functionality, the flow of usage, and to assist with prioritizing product delivery (such as release planning). The output of the story mapping exercise is a product called a story map, which describes a workflow of user stories. Story maps may break down user stories into tasks for each process and may represent these tasks based on priority.


A description of the chosen approach to apply the capabilities of an enterprise in order to reach a desired set of goals or objectives.

Strengths, weaknesses, opportunities, and threats analysis (SWOT)

An analysis model used to understand influencing factors and how they may affect an initiative. Also known as SWOT analysis.

Structural rule

See definitional business rule.

Subject matter expert (SME)

See domain subject matter expert; implementation subject matter expert.


A stakeholder outside the boundary of a given organization or organizational unit who provides products or services to the organization and may have contractual or moral rights and obligations that must be considered.

Suppliers, inputs, process, outputs, and customers (SIPOC)

A tool used to describe relevant high-level elements of a process. May be used in conjunction with process mapping and ‘in/out of scope’ tools, to provide additional detail.


Collecting and measuring the opinions or experiences of a group of people through a series of questions.


A horizontal or vertical section of a process diagram that shows which activities are performed by a particular actor or role.

SWOT analysis

See strengths, weaknesses, opportunities and threats analysis.


A set of interdependent components that interact in various ways to produce a set of desired outcomes.


Task (business analysis)

A discrete piece of work that may be performed formally or informally as part of business analysis.


A manner, method, or style for conducting a business analysis task or for shaping its output.

Temporal event

An event based on time that can trigger the initiation of a process, evaluation of business rules, or some other response.


An individual responsible for determining how to verify that the solution meets the requirements defined by the business analyst, and conducting the verification process.

Throw-away prototype

A prototype used to quickly uncover and clarify requirements or designs using simple tools, sometimes just paper and pencil. It is intended to be discarded when the final system has been developed.

Three amigos session

A gathering of the people with three primary perspectives to examine an increment of work before, during, and after development. Those perspectives are:

- Business – What problem are we trying to solve?
- Development – How might we build a solution to solve that problem?
- Testing – What about this, what could possibly happen?


An agreed-upon period of time in which an activity is conducted or a defined deliverable is intended to be produced.


See requirements traceability.

Transition requirement

A requirement that describes the capabilities the solution must have and the conditions the solution must meet to facilitate transition from the current state to the future state, but which are not needed once the change is complete. They are differentiated from other requirements types because they are of a temporary nature.



See user acceptance test.


See unified modelling language.

Unified modelling language™

A notation specified by the Object Management Group for describing software application structure, behaviour, and architecture. It can also be used for describing business processes and data structures. The most common UML® diagrams used by business analysts are use case diagrams, activity diagrams, state machine diagrams (also known as state diagrams), and class diagrams.

Use case

A description of the observable interaction between an actor (or actors) and a solution that occurs when the actor uses the system to accomplish a specific goal.

Use case diagram

A type of diagram defined by UML® that captures all actors and use cases involved with a system or product.


See end user.

User acceptance test (UAT)

Assessing whether the delivered solution meets the needs of the stakeholder group that will be using the solution. The assessment is validated against identified acceptance criteria.

User requirement

See stakeholder requirement.

User story

A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.

User story mapping

See story mapping.


Validation (business analysis)

The process of checking that a deliverable is suitable for its intended use. See also requirements validation.

Validated requirement

A requirement that has been reviewed and is determined to support the delivery of the expected benefits, and is within the solution scope.

Value (business analysis)

The worth, importance, or usefulness of something to a stakeholder in a context.

Value stream mapping

A complete, fact-based, time-series representation of the stream of activities required to deliver a product or service.

Verification (business analysis)

The process of determining that a deliverable or artifact meets an acceptable standard of quality. See also requirements verification.

Verified requirement

A requirement that has been reviewed and is determined to be defined correctly, adheres to standards or guidelines, and is at an acceptable level of detail.

Vertical prototype

A prototype that is used to drill down into a proposed solution to uncover requirement and design considerations through multiple layers of a solution that are not easily understood or that are not discernible on the surface. It may include interaction between several solution components.


A set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related.


See value stream mapping.



A facilitated and focused event attended by key stakeholders for the purpose of achieving a defined goal.


See work breakdown structure.


A two-dimensional illustration of a user interface that focuses on space allocation and prioritization of content, functionalities available, and intended behaviours. Wireframes typically do not include any styling, color, or graphics.

Work breakdown structure (WBS)

A deliverable-oriented hierarchical decomposition of the work to be executed to accomplish objectives and create the required deliverables. It organizes and defines the total scope of the project.

Work product (business analysis)

A document or collection of notes or diagrams used by the business analyst during the requirements development process.


A facilitated and focused event attended by key stakeholders for the purpose of achieving a defined goal.

Business Analysis Body of Knowledge® (BABOK® Guide)

The globally recognized standard for the practice of business analysis guiding professionals in their work and adopted by enterprises to achieve better business outcomes.