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.
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.
Used interchangeably with the word “process“.
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.
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.
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 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.
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.”
ANSI (American National Standards Institute)
An organization that has a set of standard workflow symbols. For a cheat sheet on the symbols used, see our Unofficial Guide to Process Flow Chart Symbols.
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.
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.
A characteristic that further describes an entity; a data element.
This is the limit of the solution to help establish scope. A use case diagram depicts the automation boundary and defines the solution scope. See “use case diagram”.
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.
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 world)
An economic system where any commercial, industrial, or professional activity is performed for profit.
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 effort
The scope of activities a business analyst is engaged in during the life cycle of an initiative.
business analysis information
Any kind of information at any level of detail that is used as an input to business analysis work or as 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 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”.
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.
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.
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.
The reasons a project is deemed important enough to fund, staff, and spend time on.
This describes a broad range of informal and formal models that are used by enterprises to represent various aspects of business, including its purpose, offerings, strategies, infrastructure, organizational structures, and operational processes and policies.
A problem or opportunity of strategic or tactical importance to be addressed.
An objective, measurable result to indicate that a business goal has been achieved. SMART objectives are specific and measurable results the business wants delivered by the project; long-term operational or strategic goals of the project.
An issue of strategic or tactical importance preventing an enterprise or organization from achieving its goals.
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 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.
A representation of goals, objectives, and outcomes that describes why a change has been initiated and how success will be assessed.
Potential problems that may impact the mission of the business area.
A condition that governs the way work is done; a specific, practicable, and testable directive that is under the control of the business and that serves as a criterion for guiding behavior, shaping judgments, or making decisions.
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”.
A person who works within the business area.
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.
See “fishbone diagram”.
The act of transformation in response to a need.
One who is a catalyst for change.
Controlling changes to requirements and designs so that the impact of requested changes is understood and agreed upon before the changes are made.
A plan to move from the current state to the future state to achieve the desired business objectives.
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, 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.
A process that is a component of another process, its parent.
The act of two or more people working together towards a common goal.
Brainstorming, requirements workshops, and collaborative games.
Structured techniques that are inspired by game-play to facilitate collaboration.
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. See “context data flow diagram“.
concept or conceptual 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.
A constraint describes something in the current or future state that cannot be changed, even if a specific situation or solution would benefit by doing so.
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.
core concept (business analysis)
One of six ideas that are fundamental to the practice of business analysis: change, need, Solution, context, stakeholder, and value.
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”.
CRUD (Create, Read, Update and Delete)
The four basic functions of persistent data storage.
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.
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.
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“.
Uses statistical analysis techniques to discover patterns and relationships in large volumes of data. Can be descriptive, diagnostic, and predictive. Predicting future actions using data analysis.
Data at rest; information that is important to the business area and will be retained or stored for some period of time.
A large store of data accumulated from a wide range of sources within a company and used to guide management decisions. Typically, in organizations they are computerized central repositories of integrated data from one or more disparate sources.
An activity for discussing predetermined options or ideas, especially if there are opposing viewpoints in the overall group.
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.
A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components. See “functional decomposition diagram“.
A deficiency in a product or service that reduces its quality or varies from a desired attribute, state, or functionality.
Any unique and verifiable work product or service that a party has agreed to deliver.
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.
A usable representation of a solution.
Creative problem solving with a human-centered lens through co-creation, collaboration and by experiencing the world instead of talking about experiencing the world.
An examination of the documentation of an existing system in order to elicit requirements. The process of reviewing existing documents or systems related to the project: reports, letters, screen layouts, brochures, etc.
The sphere of knowledge that defines a set of common requirements, terminology, and functionality for any program or initiative solving a problem.
DSDM (dynamic systems development method)
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 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.
**Prepare, identify, gather, conduct, capture, verify, document**
A system of one or more organizations and the solutions they use to pursue a shared set of common goals.
enterprise readiness assessment
An assessment that describes if the enterprise is prepared to accept the change associated with a solution and is able to use it effectively.
A data modeling component that represents a class of things that the business area wants to keep information about. See “ERD (entity-relationship diagram)”.
A large user story; effectively a description of a product feature that cannot be delivered as defined within an iteration and is therefore too large to be estimated.
A quantitative assessment of a planned outcome, resource requirements, and schedule where uncertainties and unknowns are systematically factored into the assessment.
An occurrence or incident to which an organizational unit, system, or process must respond. Requirements can be based on event-driven activities; an occurrence outside the scope of the business area that requires a response from the business area.
A process that is done by the business area in response to an event.
A prototype that is continuously modified and updated in response to feedback from stakeholders.
Elicitation performed in a controlled manner to make a discovery, test a hypothesis, or demonstrate a known fact.
An external agent is a person, organization, or system with whom the business area interacts. See “context data flow diagram”.
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.
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; a product capability that provides value to the customer.
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
Used commonly with non-technical audiences and are good for gaining both alignment with what the process is and context for a solution. A flow chart can be simple, displaying just the sequence of activities, or it can be more comprehensive, using “swimlanes“.
A group formed 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.
A capability that a solution must have in terms of the behavior and information the solution will manage.
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.
high level processes
A high-level summary of key processes; often used to help clarify scope. Also see “capabilities”.
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.
An assessment of the effects a proposed change will have on a stakeholder or stakeholder group, project, or system.
A specific numerical measurement that indicates progress toward achieving an impact, output, activity, or input. Also see “metric”.
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 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; most appropriate for eliciting requirements with one or two individuals at a time.
Increase Revenue, Avoid Costs, Improve Service. This is what the business is trying to achieve through the results of the initiative.
See “fishbone diagram”.
iteration (business analysis)
A single instance of progressive cycles of analysis, development, testing, or execution.
An area of expertise that includes several specific business analysis tasks.
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.
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”.
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 formal declaration of values and goals that expresses the core purpose of the enterprise.
A creative means of recording and organizing thoughts that literally “maps out” an idea in a non-linear diagram.
A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication, and understanding.
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.
A problem or opportunity to be addressed.
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.”
See “business objective”.
Studying and analyzing one or more stakeholders in their work environment in order to elicit requirements; using sight or experience to review an activity or system. There are two ways to observe: active/noticeable and passive/unnoticeable.
OLAP (online analytical processing)
A business intelligence approach that allows users to analyze large amounts of data from different points of view.
A stakeholder who is responsible for the day-to-day management and maintenance of a system or product.
See “behavioral business rule”.
An autonomous group of people, under the management of a single individual or board, that works toward common goals and objectives.
A function inside the enterprise, made up of components such as processes, technologies, and information, used by organizations to achieve their goals.
organizational change management
See “change management”.
Any recognized association of people within an organization or enterprise.
The analysis technique used to describe roles, responsibilities, and reporting structures that exist within an enterprise.
Involves restating to the speaker, in your own words, what you believe is the essence of what has just been said.
A process that is decomposed into two or more child processes. See “functional decomposition diagram“.
A formal or informal review of a work product to identify errors or opportunities for improvement. Also see “inspection”.
A detailed scheme for doing or achieving something; usually comprised of a set of events, dependencies, an expected sequence, a schedule, results or outcomes, materials and resources needed, and how stakeholders need to be involved. A work breakdown structure is typically used.
See “business policy”.
What happens after the process completes (both successful and unsuccessful completions).
What needs to be in place before the process can start.
An approach where planning and baselines are established early in the life cycle of the initiative in order to maximize control and minimize risk.
Determining the relative importance of a set of items in order to determine the order in which they will be addressed.
A clear, concise description of the issue(s) that need(s) to be addressed by a problem-solving team. It is used to center and focus the team at the beginning, keep the team on track during the effort, and is used to validate that the effort delivered an outcome that solves the problem statement.
A detailed, step-by-step description of how a process is accomplished; procedures usually contain a manual (not automated) component.
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.
A process that is performed within the scope of the project; describes the core or essential work being done by the business area; essential processes are described independently of current or future technology. Also referred to as “capability“.
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.
A set of user stories, requirements, or features that have been identified as candidates for potential implementation and have been prioritized and estimated.
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. Can be defined using a vision box or text.
A temporary endeavor undertaken to create a unique product, service, or result.
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.
A stakeholder who is responsible for managing the work required to deliver a solution that meets a business need. He or she is also responsible for ensuring that the project’s objectives are met while balancing the project constraints including scope, budget, schedule, resources, quality, and risk.
An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.
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.
The degree to which a set of inherent characteristics fulfills needs.
A set of activities performed to ensure that a process will deliver products that meet an appropriate level of quality.
A set of measures used to judge the overall quality of a system. Also see “non-functional requirements”.
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.
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.
A stakeholder from outside the organization who is responsible for the definition and enforcement of standards.
As related to use cases, it shows which actors are involved with each use case; shows an association from one entity to another; represents a business rule.
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; 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.
The process of assigning requirements to be implemented by specific solution components.
A business analysis artifact containing information about requirements such as a diagram, a matrix, a document or a model.
A characteristic or property of a requirement used to assist with requirements management.
See “requirements package”.
requirements life cycle
The stages through which a requirement progresses from inception to retirement.
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, 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.
An abstract (usually graphical) representation of some aspect of the current or future state.
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 that other related requirements and designs potentially affected by a change are known.
Work done to evaluate requirements to ensure that 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.
A highly structured, intensive workshop to achieve a goal; a meeting in which a carefully selected group of stakeholders collaborates to define and/or refine requirements under the guidance of a skilled neutral facilitator. Also called a “facilitated session”.
Benchmarking and market analysis, data mining, document analysis, and survey/questionnaire
Can be used to encourage all participants to provide input. Useful in situations where there is a disagreement or conflict in a group.
A meeting that is held at the end of an iteration in an Agile Scrum approach. During the retrospective, the team reflects on what happened in the iteration and how well the team members worked together, and they identify actions for improvement going forward.
Reverse brainstorming takes an opposite viewpoint.
risk (business analysis)
The effect of uncertainty on the value of a change, a solution, or the enterprise. Also see “residual risk”.
Factors of concern with risk: probability, likelihood the event will occur, impact or consequence, and type and extent of ‘pain’ caused.
Identifying, analyzing, and evaluating risks.
See “return on investment”.
The cause of a problem having no deeper cause, usually one of several possible causes.
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.
An actor external to the system under design that supports the execution of a use case.
A type of diagram that shows objects participating in interactions and the messages exchanged between them.
The performance of any duties or work for a stakeholder, from the perspective of the stakeholder.
Refraining from speaking or making noise. Can be a powerful communication tool used for facilitating a group of people. Silence can be used when someone has shared a large amount of information or there is a lot of tension or emotions in a facilitated session.
SIPOC (suppliers, inputs, process, outputs, and customers)
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.
A specific way of satisfying one or more needs in a context.
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.
One possible way to satisfy one or more needs in a context.
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.
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. Sponsors 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.
Identifying and analyzing the stakeholders who may be impacted by the change, and assessing their impact, participation, and needs throughout the business analysis activities.
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.
A state diagram is an analysis model showing the life cycle of a data entity or class.
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.
A description of the chosen approach to apply the capabilities of an enterprise in order to reach a desired set of goals or objectives.
Provides a context for the project. May also provide an initial description of the project, which is necessary for developing scope.
See “definitional business rule”.
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.
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”.
SWOT (strengths, weaknesses, opportunities, and threats) analysis
An analysis model used to understand influencing factors and how they may affect an initiative.
A set of interdependent components that interact in various ways to produce a set of desired outcomes.
systems development life cycle (SDLC)
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.
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 for conducting the verification process.
An aggregation of user stories to show business value delivered, to help with prioritization, and to show planned product delivery at a high level.
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.
An agreed-upon period of time in which an activity is conducted or a defined deliverable is intended to be produced.
See “requirements traceability”.
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.
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.
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 model
Consists of a diagram and a narrative to explain user/software interactions.
See “end user”.
user interface (UI)
Visual part of computer application or operating system through which a use interacts with a computer or software.
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.
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”.
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. Also see “requirements verification”.
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.
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.
See “flow chart“.