Glossary

Terms and Definitions for Analysis

Business analysis is the practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Those that perform business analysis are formally called business analysts but can also be referred to as product owners, business systems analysts, product managers, system architects, process engineers, requirements engineers, project managers or any other project team member.

Developing strong analytical skills is an effort that requires experience and training. However, understanding the related language, lingo and abbreviations doesn’t have to be. Use this glossary as your comprehensive, go-to reference of terms that anyone performing business analysis should know.

A

active listening

Listening is one of the most important skills you can possess when performing interviews or other elicitation techniques. Active listening is a communication technique used in elicitation, team exercises, training, and conflict resolution. It requires that the listener fully concentrates, understands, responds, and then remembers what is being said. An active listener must be aware of listening filters and blockers, which are things that cause the listener not to receive the intended message.

activity

Used interchangeably with the word “process“.

actor

Resources that actually interact with the system; a human, a device, or a system that plays some specified role in interacting with a solution; an actor is a UML component that represents a resource that interfaces with software. Actors are represented as stick figures in use-case diagrams.

agile

The ability of an organization to rapidly adapt to market and environmental changes in productive and cost-effective ways; a style of project management wherein a tightly-knit, highly-skilled, collocated, and self-managed team of individuals follows a project from start to finish and delivers the software quickly.

agile manifesto

In 2001, 17 advocates of lightweight processes came together and drafted a document known as the Manifesto for Agile Software Development. According to the Manifesto, “It emphasized the value of individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.”

architecture

The design, structure, and behavior of the current and future states of a structure in terms of its components and the interaction between those components. Also see: “business architecture”, “enterprise architecture”, and “requirements architecture”.

artifact

Tangible product produced by the project. Examples: a model, a document, a source code, a requirement; any solution-relevant object, output, or representation that is created as part of business analysis efforts.

assumption

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

attribute

A characteristic that further describes an entity; a data element.

B

behavioral 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 an operative rule.

benchmarking

A comparison of a decision, a process, a service, or a system’s cost, time, quality, or other metrics to those of leading peers to identify opportunities for improvement; used to review products and/or services that are being delivered by your competitors. Also known as market analysis.

body of knowledge

The aggregated knowledge and generally accepted practices on a topic (i.e. BABOK, PMBOK, SWEBOK).

BPM

See “business process management“.

BPMN

See “business process modeling notation“.

brainstorming

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

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 approach

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

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. Also see “requirements management plan“.

business analyst

Any person who performs business analysis, no matter their job title or organizational role; a person who helps companies determine their objectives for meeting certain opportunities or addressing specific needs and then helps that company determine solutions and ways to meet those needs.

business architecture

The design, structure, and behavior 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 process management (BPM)

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

business process modeling notation (BPMN)

A graphical representation for specifying business processes in a workflow. For a cheat sheet on the symbols used, see our Unofficial Guide to Process Flow Chart Symbols.

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 describes why a change has been initiated and how success will be assessed.

business risks

Potential problems that may impact the mission of the business area.

business use case

A primary purpose of the model of business use cases is to describe how the solution is or will be used by its customers and users. It shows you how the actor will interact with the system. A business use case may only indicate the “actor’s actions” or it may include “the system responses”. When the system responses are included, this is called a “systems use case”.

C

capability or capabilities

Activities that are in scope, describe core or essential work, and are independent of technology; 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.

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.

checklist (business analysis)

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

context

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

context data flow diagram

A scoping diagram used to define the area of study for analysis.

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.

CRUD (Create, Read, Update and Delete)

The four basic functions of persistent data storage.

CRUD matrix

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

customer

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.

D

data flow

A pipeline through which data or information flows. Shows how parties and systems interact with each other; an arrow on a data flow diagram that represents a pipeline or path through which data flows. Also see “context data flow diagram“.

dependencies

Relationships between tasks or projects. Example: Project A may need Project B to be completely or partially performed before Project A can be successfully completed.

E

elicitation

Iterative derivation and extraction of information from stakeholders or other sources. A more intentional set of tasks than simple requirements gathering. Receiving of information from stakeholders or other resources. The main path to discovering requirements and design information.

F

facilitation

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

G

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.

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.

H

high level processes

A high-level summary of key processes; often used to help clarify scope. Also see “capabilities“.

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.

I

IIBA

See “International Institute of Business Analysis“.

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 (SME)

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

interface

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

International Institute of Business Analysis (IIBA)

An association for business analysts.

iterative methodology

Iterative approaches plan and scope the project at the beginning and then iterate the analysis, design, and construction phases until the system is ready for implementation.

K

knowledge area

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

L

lessons learned process

A 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 anew.

life cycle

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

M

manifesto

A public declaration of principles, policies, or intentions, especially of a political nature. It comes from the Latin word manifestus, which means “clear or evident”.

metadata

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.

mind mapping

A creative means of recording and organizing thoughts that literally “maps out” an idea in a non-linear diagram.

model

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

modeling

Complex software designs that would be difficult to describe textually can readily be conveyed through multi-dimensional diagrams, known as models. Modeling provides three key benefits: visualization, complexity management, and clear communication.

N

need

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. Example: “99% of users will be able to log in and view their account balance without requiring assistance.”

O

objective

See “business objective“.

organization

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

P

prioritization

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

process

A business activity that transforms data; it has a distinct beginning and end; a process may be high-level or detailed; an activity performed by the business that transforms information (data); a set of activities designed to accomplish a specific objective by taking one or more defined inputs and turning them into defined outputs.

product backlog

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

project

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

project management

The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. The actual handling of the project which is resultant from the BA’s work of elicitation and clarification of scope. Project management handles the plan, the scope, and the deliverables; the discipline of initiating, planning, executing, controlling, and closing the work of a team to achieve specific goals and meet specific success criteria.

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.

prototype

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

Q

quality

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

quality attributes

A set of measures used to judge the overall quality of a system. Also see “non-functional requirements“.

questionnaire

A set of defined questions with a choice of answers used to collect information from respondents; the use of questions to gather information verbally, on paper, or electronically; often used in surveys.

R

RACI (responsible, accountable, consulted, and informed) 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.

regulator

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

repository

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.

requirement

A usable representation of a need; could be in the form of text, a diagram, a chart, a table, a model or a prototype; a condition or capability needed by a stakeholder to solve a problem or achieve an objective.

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, a matrix, a document or a model.

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.

risk (business analysis)

The effect of uncertainty on the value of a change, a solution, or the enterprise. Also see “residual risk“.

S

scope

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

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

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

SMART objectives

Objectives that are Specific, Measurable, Achievable, Relevant, and Time-bound

SME

Subject matter expert. See “domain subject matter expert” and “implementation subject matter expert“.

solution

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 life cycle

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

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 parts: functional requirements and non-functional or quality of service requirements.

solution scope

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

sponsor

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

stakeholder

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 assessing their impact, participation, and needs throughout the business analysis activities.

stakeholder list

A catalogue of the stakeholders affected by a change, a business need, or a 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

A state diagram is 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.

strategy

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

strategy analysis

Provides a context for the project. May also provide an initial description of the project, which is necessary for developing scope.

subject matter expert (SME)

See “domain subject matter expert” and “implementation subject matter expert“.

survey

Collecting data on a certain topic, typically the opinions or experiences of a group of people. This can be done through multiple data collection methods, including questionnaires, observation, and research. Also see “questionnaire“.

swimlane

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

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

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

system

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

systems development life cycle (SDLC)

See “lifecycle“.

T

task (business analysis)

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

technique

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.

tester

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

theme

An aggregation of user stories to show business value delivered, to help with prioritization, and to show planned product delivery at a high level.

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.

time-box

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.

traceability

See “requirements traceability“.

transition requirement

A requirement that describes the capabilities that the solution must have and the conditions that 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 different from other requirements types because they are of a temporary nature.

U

UML® (unified modelling language™)

A notation specified by the Object Management Group for describing software application structure, behavior, 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. For a cheat sheet on the symbols used, see our Unofficial Guide to Process Flow Chart Symbols.

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. See “use case diagram“.

use case description

Describes in detail the expected software functionality; step-by-step description of how a use case will be accomplished in the automated system.

use case diagram

A type of diagram defined by UML® that captures all actors and use cases involved with a system or product; shows those actors that play a part in the system and what activities they may do.

use case model

Consists of a diagram and a narrative to explain user/software interactions.

user

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 interface (UI)

Visual part of computer application or operating system through which a use interacts with a computer or software.

user requirement

See “stakeholder requirement“.

user story (agile)

A description of a product feature used for planning and scoping purposes. User stories will be decomposed to a level that can be delivered in a single iteration and can provide value; a quick way to understand the desired functionality of a user experience; a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.

V

validated requirement

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

validation (business analysis)

The process of checking that a deliverable is suitable for its intended use. Also see “requirements validation“.

verification (business analysis)

The process of determining that a deliverable or artifact meets an acceptable standard of quality. Also see “requirements verification“.

W

walkthrough

A review in which participants step through an artifact or set of artifacts with the intention of validating the requirements or designs, as well as to identify requirements or design errors, inconsistencies, omissions, inaccuracies, or conflicts.

wireframe

See “prototype“.

work breakdown structure (WBS)

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

work product (business analysis)

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

workflow

See “flow chart“.