IIBA BABOK v3 Glossary Flashcards
(250 cards)
1
Q
Criteria associated with requirements, products, or the delivery cycle that must be met in order to achieve stakeholder acceptance.
A
Acceptance Criteria
2
Q
A human, device, or system that plays some specified role in interacting with a solution.
A
Actor (Business Analysis)
3
Q
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.
A
Adaptive Approach
4
Q
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.
A
Agile Extension To The Babok® Guide
5
Q
See requirements allocation.
A
Allocation
6
Q
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.
A
Architecture
7
Q
Any solution-relevant object that is created as part of business analysis efforts.
A
Artifact (Business Analysis)
8
Q
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.
A
Assumption
9
Q
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
Behavioural Business Rule
10
Q
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.
A
Benchmarking
11
Q
The aggregated knowledge and generally accepted practices on a topic.
A
Body Of Knowledge
12
Q
See business process management.
A
Bpm
13
Q
A team activity that seeks to produce a broad or diverse set of options through the rapid and uncritical generation of ideas.
A
Brainstorming
14
Q
See enterprise.
A
Business (Business Analysis)
15
Q
An economic system where any commercial, industrial, or professional activity is performed for profit.
A
Business (Business World)
16
Q
The practice of enabling change in the context of an enterprise by defining needs and recommending solutions that deliver value to stakeholders.
A
Business Analysis
17
Q
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.
A
Business Analysis Information
18
Q
A document, presentation, or other collection of text, matrices, diagrams and models, representing business analysis information.
A
Business Analysis Package
19
Q
Any person who performs business analysis, no matter their job title or organizational role. For more information, see Who is a Business Analyst? (p. 2).
A
Business Analyst
20
Q
The set of processes, rules, guidelines, heuristics, and activities that are used to perform business analysis in a specific context.
A
Business Analysis Approach
21
Q
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.
A
Business Analysis Communication Plan
22
Q
The scope of activities a business analyst is engaged in during the life cycle of an initiative.
A
Business Analysis Effort
23
Q
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.
A
Business Analysis Plan
24
Q
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.
A
Business Architecture
25
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 Case
26
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 Decision
27
See domain.
Business Domain
28
A state or condition that an organization is seeking to establish and maintain, usually expressed qualitatively rather than quantitatively.
Business Goal
29
A problem or opportunity of strategic or tactical importance to be addressed.
Business Need
30
An objective, measurable result to indicate that a business goal has been achieved.
Business Objective
31
A non-practicable directive that controls and influences the actions of an enterprise.
Business Policy
32
An issue of strategic or tactical importance preventing an enterprise or organization from achieving its goals.
Business Problem
33
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
34
A management discipline that determines how manual and automated processes are created, modified, cancelled, and governed.
Business Process Management (Bpm)
35
Rethinking and redesigning business processes to generate improvements in performance measures.
Business Process Re-engineering
36
A representation of goals, objectives and outcomes that describe why a change has been initiated and how success will be assessed.
Business Requirement
37
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 Rule
38
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.
Capability
39
See fishbone diagram.
Cause-and-effect Diagram
40
The act of transformation in response to a need.
Change
41
One who is a catalyst for change.
Change Agent
42
Controlling changes to requirements and designs so that the impact of requested changes is understood and agreed-to before the changes are made.
Change Control
43
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 Management
44
A plan to move from the current state to the future state to achieve the desired business objectives.
Change Strategy
45
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.
Change Team
46
A standard set of quality elements that reviewers use for requirements verification.
Checklist (Business Analysis)
47
The act of two or more people working together towards a common goal.
Collaboration
48
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.
Commercial Off-the-shelf (Cots)
49
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.
Competitive Analysis
50
A uniquely identifiable element of a larger whole that fulfills a clear function.
Component
51
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.
Concept Model
52
An influencing factor that cannot be changed, and that places a limit or restriction on a possible solution or solution option.
Constraint (Business Analysis)
53
The circumstances that influence, are influenced by, and provide understanding of the change.
Context
54
One of six ideas that are fundamental to the practice of business analysis: Change, Need, Solution, Context, Stakeholder, and Value.
Core Concept (Business Analysis)
55
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.
Cost-benefit Analysis
56
See commercial off-the-shelf.
Cots
57
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.
Create, Read, Update, And Delete Matrix (Crud Matrix)
58
See create, read, update, and delete matrix.
Crud Matrix
59
A stakeholder who uses or may use products or services produced by the enterprise and may have contractual or moral rights that the enterpriseis obliged to meet.
Customer
60
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 Analysis
61
A technique that subdivides a problem into its component parts in order to facilitate analysis and understanding of those components.
Decomposition
62
A deficiency in a product or service that reduces its quality or varies from a desired attribute, state, or functionality.
Defect
63
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.
Definitional Business Rule
64
Any unique and verifiable work product or service that a party has agreed to deliver.
Deliverable
65
A usable representation of a solution. For more information see Key Terms (p. 14) and Requirements and Designs (p. 19).
Design
66
An examination of the documentation of an existing system in order to elicit requirements.
Document Analysis (Business Analysis)
67
The sphere of knowledge that defines a set of common requirements, terminology, and functionality for any program or initiative solving a problem.
Domain
68
A stakeholder with in-depth knowledge of a topic relevant to the business need or solution scope.
Domain Subject Matter Expert
69
See dynamic systems development method.
Dsdm
70
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.
Dynamic Systems Development Method (Dsdm)
71
Iterative derivation and extraction of information from stakeholders or other sources.
Elicitation
72
A stakeholder who directly interacts with the solution.
End User
73
A system of one or more organizations and the solutions they use to pursue a shared set of common goals.
Enterprise
74
A description of the business processes, information technology, people, operations, information, and projects of an enterprise and the relationships between them.
Enterprise Architecture
75
An assessment that describes the enterprise is prepared to accept the change associated with a solution and is able to use it effectively.
Enterprise Readiness Assessment
76
A graphical representation of the entities relevant to a chosen problem domain and the relationships between them.
Entity-relationship Diagram
77
A quantitative assessment of a planned outcome, resource requirements, and schedule where uncertainties and unknowns are systematically factored into the assessment.
Estimate
78
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.
Evaluation
79
An occurrence or incident to which an organizational unit, system, or process must respond.
Event (Business Analysis)
80
A prototype that is continuously modified and updated in response to feedback from stakeholders.
Evolutionary Prototype
81
Elicitation performed in a controlled manner to make a discovery, test a hypothesis, or demonstrate a known fact.
Experiment
82
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.
External Interface
83
The art of leading and encouraging people through systematic efforts toward agreed-upon objectives in a manner that enhances involvement, collaboration, productivity, and synergy.
Facilitation
84
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.
Feasibility Study
85
A distinguishing characteristic of a solution that implements a cohesive set of requirements and which delivers value for a set of stakeholders.
Feature
86
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-andeffect diagram.
Fishbone Diagram
87
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.
Focus Group
88
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.
Force Field Analysis
89
A capability that a solution must have in terms of the behaviour and information the solution will manage.
Functional Requirement
90
A comparison of the current state and desired future state of an enterprise in order to identify differences that need to be addressed.
Gap Analysis
91
See business goal.
Goal
92
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.
Governance Process (Change)
93
An instruction or description on why or how to undertake a task.
Guideline (Business Analysis)
94
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.
Horizontal Prototype
95
An assessment of the effects a proposed change will have on a stakeholder or stakeholder group, project, or system.
Impact Analysis
96
A stakeholder who has specialized knowledge regarding the implementation of one or more solution components.
Implementation Subject Matter Expert
97
A specific numerical measurement that indicates progress toward achieving an impact, output, activity, or input. See also metric.
Indicator
98
A specific project, program, or action taken to solve some business problem(s) or achieve some specific change objective(s).
Initiative
99
Information consumed or transformed to produce an output. An input is the information necessary for a task to begin.
Input (Business Analysis)
100
A formal review of a work product by qualified individuals that follows a predefined process, and uses predefined criteria, for defect identification and removal.
Inspection
101
A shared boundary between any two persons and/or systems through which information is communicated.
Interface
102
Ability of systems to communicate by exchanging data or services.
Interoperability
103
Eliciting information from a person or group of people in an informal or formal setting by asking relevant questions and recording the responses.
Interview
104
See fishbone diagram.
Ishikawa Diagram
105
A single instance of progressive cycles of analysis, development, testing, or execution.
Iteration (Business Analysis)
106
An area of expertise that includes several specific business analysis tasks.
Knowledge Area (Business Analysis)
107
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 anew.
Lessons Learned Process
108
A series of changes an item or object undergoes from inception to retirement
Life Cycle
109
A textual form of modelling used to represent information that can be categorized, cross-referenced, and represented in a table format.
Matrix
110
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.
Metadata
111
A body of methods, techniques, procedures, working concepts, and rules used to solve a problem
Methodology
112
A quantifiable level of an indicator measured at a specified point in time.
Metric
113
A formal declaration of values and goals that expresses the core purpose of the enterprise.
Mission Statement
114
A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication, and understanding.
Model
115
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.
Monitoring
116
A problem or opportunity to be addressed.
Need
117
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.
Non-functional Requirement
118
See business objective.
Objective
119
Studying and analyzing one or more stakeholders in their work environment in order to elicit requirements.
Observation (Business Analysis)
120
See online analytical processing.
Olap
121
A business intelligence approach that allows users to analyze large amounts of data from different points of view.
Online Analytical Processing (Olap)
122
A stakeholder who is responsible for the day-to-day management and maintenance of a system or product.
Operational Support
123
See behavioural business rule.
Operative Rule
124
An autonomous group of people under the management of a single individual or board, that works towards common goals and objectives.
Organization
125
A function inside the enterprise, made up of components such as processes, technologies, and information and used by organizations to achieve their goals.
Organizational Capability
126
See change management.
Organizational Change Management
127
The analysis technique used to describe roles, responsibilities and reporting structures that exist within an enterprise.
Organization Modelling
128
Any recognized association of people within an organization or enterprise.
Organizational Unit
129
A formal or informal review of a work product to identify errors or opportunities for improvement. See also inspection.
Peer Review
130
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.
Plan
131
See business policy.
Policy
132
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 Approach
133
Determining the relative importance of a set of items in order to determine the order in which they will be addressed.
Prioritization
134
A set of activities designed to accomplish a specific objective by taking one or more defined inputs and turning them into defined outputs.
Process
135
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.
Process Model
136
A solution or component of a solution that is the result of an initiative.
Product (Business Analysis)
137
A set of user stories, requirements, or features that have been identified as candidates for potential implementation, prioritized, and estimated.
Product Backlog
138
See solution scope.
Product Scope
139
A brief statement or paragraph that describes the goals of the solution and how it supports the strategy of the organization or enterprise.
Product Vision Statement
140
A temporary endeavour undertaken to create a unique product, service, or result.
Project
141
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 Manager
142
The work that must be performed to deliver a product, service, or result with the specified features and functions.
Project Scope
143
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.
Proof Of Concept
144
A partial or simulated approximation of the solution for the purpose of eliciting or verifying requirements with stakeholders.
Prototype
145
The degree to which a set of inherent characteristics fulfills needs.
Quality
146
A set of activities performed to ensure that a process will deliver products that meet an appropriate level of quality.
Quality Assurance
147
A set of measures used to judge the overall quality of a system. See also non-functional requirements.
Quality Attributes
148
A set of defined questions, with a choice of answers, used to collect information from respondents.
Questionnaire
149
See responsible, accountable, consulted, and informed matrix.
Raci Matrix
150
A stakeholder from outside the organization who is responsible for the definition and enforcement of standards.
Regulator
151
A real or virtual facility where all information on a specific topic is stored and is available for retrieval.
Repository
152
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 Information (Rfi)
153
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 Proposal (Rfp)
154
A procurement method of soliciting price and solution options from vendors.
Request For Quote (Rfq)
155
An open invitation to vendors to submit a proposal for goods or services.
Request For Tender (Rft)
156
A usable representation of a need.
Requirement
157
A characteristic or property of a requirement used to assist with requirements management.
Requirements Attribute
158
The process of assigning requirements to be implemented by specific solution components.
Requirements Allocation
159
The requirements of an initiative and the interrelationships between these requirements.
Requirements Architecture
160
A business analysis artifact containing information about requirements such as a diagram, matrix, document or model.
Requirements Artifact
161
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 Defect
162
See requirements package.
Requirements Document
163
The stages through which a requirement progresses from inception to retirement.
Requirements Life Cycle
164
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
165
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 Plan
166
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 Management Tool
167
An abstract (usually graphical) representation of some aspect of the current or future state.
Requirements Model
168
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 Package
169
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 Traceability
170
Work done to evaluate requirements to ensure they support the delivery of the expected benefits and are within the solution scope.
Requirements Validation
171
Work done to evaluate requirements to ensure they are development team can use them in the design, development, and implementation of the solution. 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 Verification
172
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.
Requirements Workshop
173
The risk remaining after action has been taken or plans have been put in place to deal with the original risk.
Residual Risk
174
See lessons learned process.
Retrospective
175
A measure of the profitability of a project or investment.
Return On Investment (Roi) (Business Analysis)
176
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.
Responsible, Accountable, Consulted, And Informed Matrix (Raci Matrix)
177
See request for information.
Rfi
178
See request for proposal.
Rfp
179
See request for quote.
Rfq
180
See request for tender.
Rft
181
The effect of uncertainty on the value of a change, a solution, or the enterprise. See also residual risk.
Risk (Business Analysis)
182
Identifying, analyzing and evaluating risks.
Risk Assessment
183
See return on investment.
Roi
184
The cause of a problem having no deeper cause, usually one of several possible causes.
Root Cause
185
A structured examination of an identified problem to understand the underlying causes.
Root Cause Analysis
186
The boundaries of control, change, a solution, or a need.
Scope
187
A model that defines the boundaries of a business domain or solution.
Scope Model
188
An actor external to the system under design that supports the execution of a use case.
Secondary Actor
189
A type of diagram that shows objects participating in interactions and the messages exchanged between them.
Sequence Diagram
190
The performance of any duties or work for a stakeholder, from the perspective of the stakeholder.
Service (Business Analysis)
191
See suppliers, inputs, process, outputs and customers.
Sipoc
192
See subject matter expert.
Sme
193
See developer.
Software Engineer
194
A specific way of satisfying one or more needs in a context.
Solution
195
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 Component
196
One possible way to satisfy one or more needs in a context.
Solution Option
197
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 Requirement
198
The stages through which a solution progresses from inception to retirement.
Solution Life Cycle
199
The set of capabilities a solution must deliver in order to meet the business need.
Solution Scope
200
See statement of work.
Sow
201
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.
Sponsor
202
A group or individual with a relationship to the change, the need, or the solution.
Stakeholder
203
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 Analysis
204
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 List
205
The role a business analyst takes when representing the needs of a stakeholder or stakeholder group.
Stakeholder Proxy (Business Analyst)
206
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.
Stakeholder Requirement
207
An analysis model showing the life cycle of a data entity or class.
State Diagram
208
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.
Stated Requirement
209
A written description of the services or tasks that are required to be performed.
Statement Of Work (Sow)
210
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
211
An analysis model used to understand influencing factors and how they may affect an initiative. Also known as SWOT analysis.
Strengths, Weaknesses, Opportunities, And Threats Analysis (Swot)
212
See definitional business rule.
Structural Rule
213
See domain subject matter expert; implementation subject matter expert.
Subject Matter Expert (Sme)
214
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.
Supplier
215
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.
Suppliers, Inputs, Process, Outputs, And Customers (Sipoc)
216
Collecting and measuring the opinions or experiences of a group of people through a series of questions.
Survey
217
A horizontal or vertical section of a process diagram that shows which activities are performed by a particular actor or role.
Swimlane
218
See strengths, weaknesses, opportunities and threats analysis.
Swot Analysis
219
A set of interdependent components that interact in various ways to produce a set of desired outcomes.
System
220
A discrete piece of work that may be performed formally or informally as part of business analysis.
Task (Business Analysis)
221
A manner, method, or style for conducting a business analysis task or for shaping its output.
Technique
222
An event based on time that can trigger the initiation of a process, evaluation of business rules, or some other response.
Temporal Event
223
An individual responsible for determining how to verify that the solution meets the requirements defined by the business analyst, and conducting the verification process.
Tester
224
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.
Throw-away Prototype
225
An agreed-upon period of time in which an activity is conducted or a defined deliverable is intended to be produced.
Time-box
226
See requirements traceability.
Traceability
227
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.
Transition Requirement
228
See user acceptance test.
Uat
229
See unified modelling language.
Uml®
230
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.
Unified Modelling Language™
231
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
232
A type of diagram defined by UML® that captures all actors and use cases involved with a system or product.
Use Case Diagram
233
See end user.
User
234
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 Acceptance Test (Uat)
235
See stakeholder requirement.
User Requirement
236
A small, concise statement of functionality or quality needed to deliver value to a specific stakeholder.
User Story
237
The process of checking that a deliverable is suitable for its intended use. See also requirements validation.
Validation (Business Analysis)
238
A requirement that has been reviewed and is determined to support the delivery of the expected benefits, and is within the solution scope.
Validated Requirement
239
The worth, importance, or usefulness of something to a stakeholder in a context.
Value (Business Analysis)
240
A complete, fact-based, time-series representation of the stream of activities required to deliver a product or service.
Value Stream Mapping
241
The process of determining that a deliverable or artifact meets an acceptable standard of quality. See also requirements verification.
Verification (Business Analysis)
242
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.
Verified Requirement
243
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.
Vertical Prototype
244
A set of conventions that define how requirements will be represented, how these representations will be organized, and how they will be related.
Viewpoint
245
See value stream mapping.
Vsm
246
A review in which participants step through an artifact or set of artifacts with the intention of validating the requirements or designs, and to identify requirements or design errors, inconsistencies, omissions, inaccuracies, or conflicts.
Walkthrough
247
See work breakdown structure.
Wbs
248
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 Breakdown Structure (Wbs)
249
A document or collection of notes or diagrams used by the business analyst during the requirements development process.
Work Product (Business Analysis)
250
A facilitated and focused event attended by key stakeholders for the purpose of achieving a defined goal.
Workshop
