GLOSSARY
Acceptance Criteria. A set of conditions that is required to be met before deliverables are accepted. [Note: In business analysis, acceptance criteria is built to evaluate the product requirements and solution.]
Active Listening. The act of listening completely with all senses so as to pick up all of the information that is being communicated. Active listening entails paraphrasing or reciting back what is heard to ensure accurate understanding of what has been stated.
Activity. A distinct, scheduled portion of work performed during the course of a project.
Adaptive Life Cycle. A project life cycle, also known as change-driven or agile methods, that is intended to facilitate change and requires a high degree of ongoing stakeholder involvement.
Affinity Diagram. A group creativity technique that allows large numbers of ideas to be classified into groups for review and analysis.
Approved Change Request. A change request that has been processed through the integrated change control process and approved.
Architecture. A method to describe an organization by mapping its essential characteristics, such as people, locations, processes, applications, data, and technology.
As-Is Process. A depiction of the current state of a process, representing how a process is currently performed in the organization.
Assumption. A factor that is considered to be true, real, or certain, without proof or demonstration.
Asynchronous Interview. An interview in which the participants are not engaged in the interview at the same time. Asynchronous interviews can be conducted through email or can be prerecorded by the interviewer and provided to the interviewee at a later time.
Backlog. A listing of product requirements and deliverables to be completed, written as stories, and prioritized by the business to manage and organize the project's work.
Baseline. The approved version of a work product that can be changed only through formal change control procedures and is used as a basis for comparison.
Benchmarking. The comparison of actual or planned practices, such as processes and operations, to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance.
Brainstorming. A general data gathering and creativity technique that is used to identify risks, ideas, or solutions to issues by using a group of team members or subject matter experts.
Burndown. A visual chart depicting the number of backlog items remaining at any point in time in a project. Burndown charts are used on projects using an adaptive life cycle.
Business Analysis. The set of activities performed to identify business needs; recommend relevant solutions; and elicit, document, and manage requirements.
Business Analysis Approach. A description of how the business analysis process will be conducted for the project or program. The business analysis approach is documented in the business analysis plan.
Business Analysis Center of Excellence. An organizational structure created whereby business analysts are managed centrally or are provided mentorship centrally for the purpose of improving the business analysis discipline across the organization. Also called Center of Business Analysis Practice.
Business Analysis Documentation. The set of business analysis information produced as an output of the business analysis work conducted on a program or project. Such output may be comprised of business analysis deliverables, business analysis work products, or a combination thereof.
Business Analysis Plan. A subplan of the project management plan that defines the business analysis approach, including the tasks that will be performed, the deliverables that will be produced, the roles required to carry out the process, and process decisions regarding how requirement-related decisions will be made; how requirement priorities will be set; how changes to requirements will be proposed, approved, and managed; how requirements will be validated, verified, monitored, and traced; and how business analysis communication will be performed.
Business Analysis Planning. The domain of business analysis that involves planning all of the business analysis activities and reaching the necessary process decisions required for running an effective business analysis process for a program or project.
Business Architecture. A collection of the business functions, organizational structures, locations, and processes of an organization, including documents and depictions of those elements.
Business Case. A documented economic feasibility study used to establish the validity of the benefits of a selected component lacking sufficient definition and used as a basis for the authorization of further project management activities.
Business Need. The impetus for a change in an organization, based on an existing problem or opportunity. The business need provides the rationale for initiating a project or program.
Business Objectives Model. A business analysis model that relates the business problems, business objectives, and top-level features. This model encompasses the justification for a project.
Business Requirements. Requirements that describe the higher-level needs of the organization, such as the business issues or opportunities, and which provide the rationale for why a project is being undertaken.
Business Rule. Constraints about how the organization wants to operate. These constraints are usually enforced by data and/or processes and are under the jurisdiction of the business.
Business Rules Analysis. A process for evaluating, designing, and implementing the rules that govern the organization, its processes, and its data.
Business Rules Catalog. A business analysis model that details all of the business rules and their related attributes.
Business Value. A concept that is unique to each organization and includes tangible and intangible elements. In business analysis, business value is considered the return, in the form of time, money, goods, or intangibles in return for something exchanged.
Capability. The ability to add value or achieve objectives in an organization through a function, process, service, or other proficiency.
Capability Framework. A collection of an organization's capabilities, organized into manageable pieces, similar to a business architecture.
Capability Table. A table that displays the capabilities needed to solve a problem or seize an opportunity. This tool can show the relationship between a situation, its root causes, and the capabilities needed to address the situation.
Cause-and-Effect Diagram. A decomposition technique that helps trace an undesirable effect back to its root cause. See also fishbone diagram.
Center of Business Analysis Practice. See Business Analysis Center of Excellence.
Change Control. A process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected.
Change Control Board (CCB). A formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project, and for recording and communicating such decisions.
Change Control Tools. Manual or automated tools used to assist with change and/or configuration management. At a minimum, the tools should support the activities of the change control board (CCB).
Change Management Plan. The plan that defines the process for managing change on the project.
Change Request. A formal proposal to modify any document, deliverable, or baseline.
Charter. See project charter.
Closed-Ended Question. A question that calls for a response from a limited list of answer choices. Types of closed-ended questions are forced choice, limited choice, and confirmation.
Communications Management Plan. A component of the project, program, or portfolio management plan that describes how, when, and by whom information about the project will be administered and disseminated.
Configuration Management. A collection of formal documented processes, templates, and documentation used to apply governance to changes to the product, service, result, or subcomponent being developed.
Configuration Management System. A subsystem of the overall project management system. It is a collection of formal documented procedures used to apply technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a product, result, service, or component; control any changes to such characteristics; record and report each change and its implementation status; and support the audit of the products, results, or components to verify conformance to requirements. It includes the documentation, tracking systems, and defined approval levels necessary for authorizing and controlling changes.
Constraint. A limiting factor that affects the execution of a project, program, portfolio, or process.
Context Diagram. A visual depiction of the product scope showing a business system (process, equipment, computer system, etc.) and how people and other systems (actors) interact with it.
Contextual Question. A question that can only be answered as it references the subject at hand; namely, the problem domain or the proposed solutions.
Context-Free Question. A question that can be asked in any situation.
Cost-Benefit Analysis. A financial analysis tool used to determine the benefits provided by a project against its costs.
Cost-Effectiveness Feasibility. The high-level economic feasibility of a potential project or program, taking into account both financial benefits and costs.
Data Dictionary. A business analysis model that catalogs the attributes of specific data objects.
Data Flow Diagram. A business analysis model that combines processes, systems, and data to show how data flows through a solution.
Day in the Life Testing (DITL). A semiformal activity, conducted by someone with in-depth business knowledge. The results obtained from DITL testing enable validation or evaluation of whether or not a product or service or solution provides the functionality for a typical day of usage by a role that interacts with the solution.
Decision Table. An analysis model that uses a tabular format to display complex business rules by representing decision points in the upper rows and outcomes in the bottom rows with the purpose of providing all combinations of choices.
Decision Tree. An analysis model that shows business rules associated with complex branching logic. Rules are depicted by modeling the decisions and their outcomes in a tree structure.
Decomposition Diagrams. See decomposition model.
Decomposition Model. A model that is used to divide and subdivide a high-level concept into lower-level concepts, for example, dividing the project scope and project deliverables into smaller, more manageable parts for the purpose of analysis. Also known as decomposition diagrams.
Defect Repair. An intentional activity to modify a nonconforming product or product component.
Deliverable. Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project.
Dependency Analysis. A technique that is used to discover dependent relationships.
Display-Action-Response Model. A business analysis model that dissects a screen mockup into its display and behavior requirements at the page element level.
Document Analysis. An elicitation technique that analyzes existing documentation and identifies information relevant to the requirements.
Ecosystem Map. A business analysis model that shows the systems involved in a project and how they interrelate with each other.
Elicitation. See requirements elicitation.
Elicitation Plan. An informal device used by a business analyst to prepare for the elicitation work.
Elicitation Session. A session or activity conducted for the purpose of obtaining information from participants. In business analysis, elicitation sessions are conducted in order to obtain the information needed to define the requirements.
Enterprise Architecture. A collection of the business and technology components needed to operate an enterprise. The business architecture is usually a subset of the enterprise architecture and is extended with the applications, information, and supporting technology to form a complete blueprint of an organization.
Entity Relationship Diagram. A business analysis model that shows the business data objects involved in a project and the relationships between those objects, including the cardinality of those relationships.
Estimate. A quantitative assessment of the likely amount or outcome. It is usually applied to project costs, resources, effort, and durations and is usually preceded by a modifier (i.e., preliminary, conceptual, feasibility, order-of-magnitude, definitive). It should always include some indication of accuracy (e.g., ± x %).
Evaluation. See solution evaluation.
Expert Judgment. Judgment provided based upon expertise in an application area, Knowledge Area, discipline, industry, etc., as appropriate for the activity being performed. Such expertise may be provided by any group or person with specialized education, knowledge, skill, experience, or training.
Exploratory Testing. An unscripted, free-form validation or evaluation activity conducted by someone with in-depth business or testing knowledge to validate the product and discover product errors.
Facilitated Workshops. An elicitation technique using focused sessions that bring key cross-functional stakeholders together to define product requirements. In business analysis, facilitated workshops use a structured meeting that is led by a skilled, neutral facilitator, in which a carefully selected group of stakeholders collaborate to explore and evaluate product requirements.
Feasibility Analysis. A study that produces a potential recommendation to address business needs. It examines feasibility using one or more of the following variables: operational, technology/system, cost-effectiveness, and timeliness of the potential solution.
Feature. A set of related requirements typically described as a short phrase.
Feature Model. A business analysis model that shows the first, second, and third level of features involved in a project.
Fishbone Diagram. A version of a cause-and-effect diagram that depicts a problem and its root causes in a visual manner. It uses a fish image, listing the problem at the head, with causes and subcauses of the problem represented as bones of the fish. See also cause-and-effect diagram.
Five Whys. A technique for conducting root cause analysis suggesting anyone trying to understand a problem needs to ask why it is occurring up to five times to thoroughly understand its causes.
Focus Groups. An elicitation technique that brings together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result.
Functional Requirements. Requirements that describe the behaviors of a product.
Gap Analysis. A technique for understanding the gap between current capabilities and needed capabilities. Filling the gap is what comprises a solution recommendation.
Grooming the Backlog. A process used on agile projects where the product team works with the product owner to gain more depth about the user stories in the backlog list. A groomed backlog is an input for sprint planning meetings, which are used to determine which user stories to cover in the next iteration.
Happy Path. See normal flow.
High-Fidelity Prototyping. A method of prototyping that creates a functioning representation of the final finished product to the user. High-fidelity prototyping is performed using a programming language or a pseudo language of the product to be demonstrated.
Impact Analysis. A technique for evaluating a change in relation to how it will affect other requirements, the product, the program, and the project.
Iterative Life Cycle. A project life cycle where iterations develop the product through a series of repeated cycles, while increments successively add to the functionality of the product.
Interrelationship Diagram. A special type of cause-and-effect diagram that depicts related causes and effects for a given situation. Interrelationship diagrams help to uncover the most significant causes and effects involved in a situation. See also cause-and-effect diagram.
Internal Rate of Return (IRR). The projected annual yield of a project investment, incorporating both initial and ongoing costs into an estimated percentage growth rate a given project is expected to have.
Interviews. A formal or informal approach to elicit information from a group of stakeholders by asking questions and documenting the responses provided by the interviewees.
Ishikawa Diagrams. See fishbone diagram and cause-and-effect diagram.
Issue. A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.
Iterative Life Cycle. A project life cycle where the project scope is generally determined early in the project life cycle, but time and cost estimates are routinely modified as the project team's understanding of the product increases. Iterations develop the product through a series of repeated cycles, while increments successively add to the functionality of the product.
Job Analysis. A technique used to identify job requirements and the competencies needed to perform effectively in a specific job.
Kanban. An adaptive life cycle in which project work items are pulled from a backlog and started when other project work items are completed. Kanban also establishes work-in-progress limits to constrain the number of work items that can be in-progress at any point in time.
Kanban Board. A tool used within the continuous improvement method of Kanban to visually depict workflow and capacity and assist team members in seeing the work that is planned, in process or completed. The Kanban board is a variation of the original Kanban cards.
Key Performance Indicator (KPI). Metrics usually defined by an organization's executives that are used to evaluate an organization's progress toward meeting its objectives or goals.
Key Stakeholders. A stakeholder who is identified as having a significant stake in the project or program and who holds key responsibilities such as approving requirements or approving changes to product scope.
Lessons Learned. The knowledge gained during a project, which shows how project events were addressed or should be addressed in the future for the purpose of improving future performance.
Low-Fidelity Prototype. A method of prototyping that provides fixed sketches, diagrams, and notes to provide a visual representation of what a screen will look like. Static prototypes do not demonstrate the operation of the system to the user.
Measure. The quantity of some element at a point in time or during a specific time duration, such as the number of work months spent on a project during a specific time period, the number of defects uncovered, or the number of customers responding to a survey stating that they were extremely satisfied.
Metric. A set of quantifiable measures used to evaluate a solution or business.
Model. A visual representation of information, both abstract and specific, which operates under a set of guidelines in order to efficiently arrange and convey a lot of information in an efficient manner.
Modeling Language. A set of models and their syntax. Examples include Requirements Modeling Language (RML), Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), and System Modeling Language (SysML).
Monitoring. The process of collecting project performance data, producing performance measures, and reporting and disseminating performance information.
MoSCoW. A technique used for establishing requirement priorities. In this technique, the participants divide the requirements into four categories of must haves, should haves, could haves, and won't haves.
Multivoting Process. A technique used to facilitate decision making among a group of stakeholders. Participants are provided with a limited number of votes and are asked to apply those votes to a list of possible options. The option with the most votes is determined to be the most favorable option. Multivoting processes can be used to prioritize requirements, determine the most favorable solution, or to identify the most favorable response to a problem.
Narrative. A story. In business analysis, narratives are written when developing personas.
Needs Assessment. The domain of business analysis concerned with understanding business goals and objectives, issues, and opportunities, and recommending proposals to address them.
Negotiation. The process and activities used to resolve disputes through consultations between involved parties.
Net Present Value (NPV). The future value of expected project benefits expressed in the value those benefits have at the time of investment. NPV takes into account current and future costs and benefits, inflation, and the yield that could be obtained through investing in financial instruments as opposed to a project or program.
Nonfunctional Requirements. Requirements that express properties that the product is required to have, including interface, environment, and quality attribute properties.
Normal Flow. Within the context of use case analysis, the normal flow is the set of steps that are followed through the use case scenario when everything goes as planned or expected.
Objective. Something toward which work is to be directed, a strategic position to be attained, a purpose to be achieved, a result to be obtained, a product to be produced, or a service to be performed. In business analysis, objectives are quantifiable outcomes that are desired from a product, result, or service.
Observation. An elicitation technique that provides a direct way of obtaining information about how a process is performed or a product is used by viewing individuals in their own environment performing their jobs or tasks and carrying out processes.
Open-Ended Question. A question that allows the responder to answer in any way desired.
Operational Feasibility. The extent to which a proposed solution meets operational needs and requirements related to a specific situation. It also includes factors such as sustainability, maintainability, supportability, and reliability.
Opportunity. A risk that would have a positive effect on one or more project objectives.
Opportunity Analysis. A study of the major facets of a potential opportunity to determine the viability of successfully launching a new product or service.
Opportunity Cost. The loss of value that could be realized in other actions or alternatives, if the current action is pursued.
Organizational Modeling. A type of modeling that visually depicts the organizational structure and elements of an organization.
Organizational Chart. A model that depicts the reporting structure within an organization or within a part of an organization. In business analysis, organizational charts can be used to help identify stakeholders who are involved in a project and to understand the reporting structures that exist among those identified.
Organizational Goals. Broad-based translations of corporate goals into expressions that are actionable and measurable. Goals are typically longer in scope than objectives.
Organizational Objectives. Accomplishments that an organization wants to achieve to help enable goals. These are specific and tend to be of shorter duration than goals, often one year or less.
Pair-Matching. A step performed when constructing a weighted ranking matrix. It involves taking each option under analysis and comparing it one by one to all the other options listed.
Participant. One who participates in a group activity, such as focus groups or facilitated workshops.
Payback Period (PBP). The time needed to recover a project investment, usually in months or years.
Persona. An archetype user representing a set of similar end users described with their goals, motivations, and representative personal characteristics.
Policy. A structured pattern of actions adopted by an organization such that the organization's policy can be explained as a set of basic principles that govern the organization's conduct.
Phase. See project phase.
Predictive Life Cycle. A form of project life cycle in which the project scope, and the time and cost required to deliver that scope, are determined as early in the life cycle as possible.
Problem. An internal or external environment of an organization that is causing detriment to the organization, for example, lost revenue, dissatisfied customers, delays in launching new products, or noncompliance with government regulations.
Problem Domain. The area or context surrounding the problem that is currently under analysis.
Procedure. An established method of accomplishing a consistent performance or result. A procedure typically can be described as the sequence of steps that will be used to execute a process.
Process. A systematic series of activities directed towards causing an end result such that one or more inputs will be acted upon to create one or more outputs.
Process Flow. A business analysis model that visually shows the steps taken in a process by a human user as it interacts with an implementation. A set of steps taken by a system can be shown in a similar model, a system flow.
Process Worker. The stakeholder who physically works with or within the business process that is under analysis or the user who works specifically with a system that is part of the business process. Not all process workers are users.
Product. An artifact that is produced, is quantifiable, and can be either an end item in itself or a component item. Products are also referred to as materials or goods. See also deliverable.
Product Backlog. See backlog.
Product Scope. The features and functions that characterize a product, service, or result.
Product Stakeholder. A business stakeholder affected by a problem or opportunity, or impacted by or interested in the solution.
Program. A group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually.
Project. A temporary endeavor undertaken to create a unique product, service, or result.
Project Charter. A document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.
Project Life Cycle. The series of phases that a project passes through from its initiation to its closure.
Project Management Plan. The document that describes how the project will be executed, monitored, and controlled.
Project Manager. The person assigned by the performing organization to lead the team that is responsible for achieving the project objectives.
Project Phase. A collection of logically related project activities that culminates in the completion of one or more deliverables.
Project Schedule. An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources.
Project Scope. The work performed to deliver a product, service, or result with the specified features and functions.
Project Stakeholder Management. Includes the processes required to identify all people or organizations impacted by a project, analyzing stakeholder expectations and impact on the project, and developing appropriate management strategies for effectively engaging stakeholders in project decisions and execution.
Project Team. A set of individuals who support the project manager in performing the work of the project to achieve its objectives.
Prototypes. A method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it.
Questionnaire and Survey. A written set of questions designed to quickly accumulate information from a large number of respondents.
RACI Model. A common type of responsibility assignment matrix that uses responsible, accountable, consult, and inform statuses to define the involvement of stakeholders in project activities.
Regulation. A requirement imposed by a governmental body. These requirements can establish product, process, or service characteristics, including applicable administrative provisions that have government-mandated compliance.
Report Table. A business analysis model that documents in a tabular format all of the requirements necessary to develop a single report.
Requirement. A condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.
Requirements Attribute. A property of a requirement used to store descriptive information about the requirement, such as last change date, author, source, etc.
Requirements Change Process. The process that defines how changes to requirements will be handled across the project.
Requirements Documentation. A description of how individual requirements meet the business need for the project.
Requirements Analysis. The process of examining, breaking down, and synthesizing information to further understand it, complete it, and improve it.
Requirements Elicitation. The activity of drawing out information from stakeholders and other sources for the purpose of further understanding the needs of the business, to address a problem or opportunity and the stakeholder's preferences and conditions for the solution that will address those needs.
Requirements Elicitation and Analysis. The domain of business analysis concerned with the iterative work to plan, prepare, and conduct the elicitation of information from stakeholders and to analyze, model, and document the results of that work with the objective of defining a set of requirements in sufficient detail to enable the purchase or build of the preferred solution or refinement of processes to achieve the business objective.
Requirements Life Cycle. The flow or life of a requirement throughout a project or program. The requirements life cycle is managed by assigning an attribute or qualifier onto the requirement to depict the requirement state at a specified point in time.
Requirements Management Plan. A component of the project or program management plan that describes how requirements will be analyzed, documented, and managed. See also business analysis plan.
Requirement State. An attribute of a requirement that identifies where the requirement falls within the requirements life cycle, for example, in-process, approved, deferred, or rejected.
Requirements Traceability Matrix. A grid that links product requirements from their origin to the deliverables that satisfy them.
Requirements Validation. The process of ensuring that the product satisfies its intended use and anticipated value, ensuring the correct product is delivered.
Requirements Verification. The process of reviewing requirements and models to ensure they meet quality standards. Verification is performed to ensure that requirements are constructed properly and that models conform to the proper use of modeling notation.
Responder. Any participant or person from whom information is gathered by means of elicitation.
Retrospective. A type of meeting in which participants explore their work and outcomes in order to improve both process and product. Retrospectives can occur on a regular basis (e.g., end of iteration or release), at the completion of a milestone, or after a special event (e.g., organizational change, accident).
Return on Investment (ROI). The percent return on an initial project or program investment, calculated by taking the projected average of all net benefits and dividing them by the initial cost.
Risk. An uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.
Risk Analysis. The process of examining a program, project, or process for risk.
Risk Tolerance. The degree, amount, or volume of risk that an organization or individual will withstand.
Role. A defined function to be performed by a project team member, such as testing, filing, inspecting, or coding.
Rolling Wave Planning. An iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level.
Root Cause Analysis. An analytical technique used to determine the basic underlying reason that causes a variance or a defect or a risk. A root cause may underlie more than one variance or defect or risk.
Scenario. A case of usage of a solution often manifested as a concrete example of a use case or user story or several functional requirements specified in the sequence in which they occur.
Schedule. See project schedule.
Scope. The sum of the products, services, and results to be provided as a project. In business analysis, scope is defined as the boundary for the products, services, or results. See also project scope and product scope.
Scope Baseline. The approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed only through formal change control procedures and is used as a basis for comparison.
Scope Creep. The uncontrolled expansion to a product or project scope without adjustments to time, cost, and resources.
Scope Model. A type of model that identifies the boundaries of the project, program, product, and/or system under analysis. A context diagram is one example of a scope model.
Scrum. A type of adaptive life cycle where a product is built in small incremental portions and each cycle of development builds upon the last version of the product.
Situation. A condition which may be an internal problem or external opportunity that forms the basis of a business need and might result in a project or program to address the condition.
Situation Statement. An objective statement of a problem or opportunity that includes the statement itself, the situation's effect on the organization, and the ultimate impact.
SMART Goals. Goals that are well-written to meet the quality criteria of being specific, measurable, achievable, relevant, and time-bounded.
Software Requirements Specification. A type of requirements documentation that includes the functional and nonfunctional requirements of a software system.
Solution Evaluation. The domain of business analysis concerned with the activities to validate a solution that is about to be or that has already been implemented.
Solution Requirement. A requirement that describes the features, functions, and characteristics of a product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements.
Sponsor. A person or group who provides resources and support for the project, program, or portfolio and is accountable for enabling success.
Stakeholder. An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.
Stakeholder Analysis. A technique of systematically gathering and analyzing quantitative and qualitative information to determine whose interests should be taken into account throughout the project.
Stakeholder Characteristics. The qualities and attributes of a stakeholder, which together determine aspects of how the stakeholder behaves.
Stakeholder Identification. The process of determining the stakeholders impacted by a business problem or opportunity.
Stakeholder Groups. A collection of stakeholders who have similar likes, interests, and stakeholder characteristics. Stakeholder groups are used by project managers and business analysts to manage large groups of stakeholders.
Stakeholder Map. A technique used to visually analyze stakeholders and their relationship to each other and to the problem or opportunity under analysis.
Stakeholder Register. A project document including the identification, assessment, and classification of project stakeholders.
Stakeholder Requirement. A requirement that describes the need of a stakeholder or stakeholder group.
State Diagram. A business analysis model that visually shows how an object moves between different states. This model helps to show the life cycle of an object in a solution.
State Table. A business analysis model that shows all of the possible states of an object and all of the valid transitions. This model helps to enumerate all possible states and possible transitions.
Subject Matter Expert (SME). A person who is considered an expert in a particular subject area. In business analysis, SMEs are often involved in providing the requirements for their area of expertise.
Surveys. See questionnaires and surveys.
SWOT Analysis. Analysis of strengths, weaknesses, opportunities, and threats of an organization, project, or option.
Synchronous Interview. An interview conducted where the interviewer and interviewee are involved in the interview at the same time. Synchronous meetings can occur face to face, over the phone, or through web conferencing, etc.; the two parties are not required to be in person with one another, but both need to be active in the interview at the same time.
System Feasibility. See technology feasibility.
System Interface Table. A business analysis model that documents the requirements for the connections between each interfacing system involved in a project, including how they are connected and what information flows between them.
Technique. A defined systematic procedure employed by a human resource to perform an activity that produces a product or result or delivers a service, and that may employ one or more tools.
Technology Feasibility. An analysis to determine the extent to which a technology exists in an organization to support a potential solution and if not present, how feasible it would be to acquire and operate the needed technology.
Templates. A partially completed document in a predefined format that provides a defined structure for collecting, organizing, and presenting information and data.
Threat. A risk that would have a negative effect on one or more project objectives.
Time Feasibility. An analysis to determine how well a proposed solution can be delivered to meet the organization's needed time frame.
To-Be Process. A proposed revision to an existing process that can provide an improvement for an organization over how activities are currently performed, or a revision to a new process when adding products or services.
Traceability. Traceability provides the ability to track product requirements from their origin to the deliverables that satisfy them.
Traceability and Monitoring. The domain of business analysis concerned with building and maintaining the traceability matrix to manage requirements and product scope, baselining the product requirements, assessing impacts of proposed requirement changes, and managing the required updates to the requirements and other business analysis deliverables once proposed changes are approved.
Traceability Matrix. See requirements traceability matrix.
Transition Requirements. Requirements that are the temporary capabilities, such as data conversion and training requirements, needed to transition from the current as-is state to the future state.
Use Case. An analysis model that describes a flow of actor-system interactions and boundaries for those interactions, including trigger, initiating and participating actors, and preconditions and post conditions.
Use Case Diagram. A business analysis model that shows all of the in-scope use cases for a project and which actors have a part in those use cases.
User Class. A group of stakeholders who are users of a software system, product, or service and are grouped together due to the similarity in their requirements and use of the product.
User Experience Analyst. Also referred to as user interface analysts; individuals who are responsible for studying user behavior, preferences, and constraints in order to identify user interface and usability requirements for software applications and other products.
User Interface Flow. A business analysis model that shows the specific pages or screens of an application and how a user can navigate between them.
User Story. A one or two sentence description, written from the viewpoint of the actor, describing what function is needed. A user story usually takes the form of “as an <actor>, I want to <function>, so that I can <benefit>.”
Validation. The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. Contrast with verification.
Verification. The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. It is often an internal process. Contrast with validation.
Velocity. A measure of a team's productivity rate at which the deliverables are produced, validated, and accepted within a predefined interval. Velocity is a capacity planning approach frequently used to forecast future project work.
Version Control. The process of maintaining a history of changes on software or documentation.
Version Control System (VCS). A system that is used to track the history of revisions, often but not always related to software.
Weighted Criteria. A technique used to help support objective decision making. It uses a weighted ranking matrix to compare alternatives and their weighted scores in order to evaluate decision options. See also weighted ranking matrix.
Weighted Ranking Matrix. A table used in decision making that combines pair matching of all alternatives with weighted criteria to add objectivity when formulating a decision or recommendation. Each alternative is compared with every other alternative on the basis of weighted criteria, and the resulting scores are added together to determine the preferred choice.
Work Breakdown Structure (WBS). A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.
Work Product. An output produced as a result of some completion of work that is required for a short-term purpose and not required to be monitored and maintained on an ongoing basis.