PMI-PBA Final Version
Pareto Analysis (80/20 rule)
80% of one component (such as time) will result in 20% of another component. Used to find the most valuable areas of focus (e.g., problems, requirements, issues). Helps with concentrating on the work with the biggest impact.
Variance analysis
A PM technique for analyzing the results of measurements, and comparing planned to actual performance.
Gap analysis
A comparison of two or more systems or processes to find differences; as-is compared to future-state or ideal state; vendor A vs. vendor B.
Requirements management plan
A component of the project or program management plan that describes how requirements will be analyzed, documented, and managed.
Communications management plan
A component of the project, program, or portfolio management plan that describes how, when, and by whom the information about the project will be administered and disseminated.
Business activity diagram
A diagram showing the flow of business activities using UML notation (may use vertical swim lanes; aka UML activity diagram)
Class diagram
A diagram that includes business concepts such as classes, nouns, or entities, their characteristics, and their behaviors (used in object oriented analysis and design).
User interface flow
A diagram that shows how screens or pages will be connected or navigated.
Cause and effect diagram
A diagram used to break down a problem and find its root causes (aka Fishbone, Ishikawa diagram).
Traceability matrix
A grid that links product or solution objectives to requirements, solution deliverables, and/or test cases from their origin to the deliverables that satisfy them.
Affinity diagram
A group creativity technique where ideas from other requirements gathering techniques are organized by similarities.
Sequence diagram
A modelling technique describing how user or system processes interact with one another across any involved users or systems, includes the order in which the processes or steps are performed.
Business requirements document
A package of requirements to present to an individual or group of stakeholders.
Context diagram
A specialized data flow diagram that shows the scope or context of the area to be studied or the solution.
Business analysis plan
A subplan of the project management plan that defines the business analysis approach, i.e. tasks that will be performed, deliverables that will be produced, roles required to carry out the process, process decisions about 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 rules catalog
A table used to store business rules and their characteristics.
Backward traceability
A technique that establishes the relationship of a requirement to the scope, business goals, or business objectives from which it originated.
Workflow management
A tool that allows organizations to automate business processes.
Goal model
A tool to analyze goals, problems, objectives, success metrics, and high level features (aka business objective model).
Business objective model
A tool used to analyze goals, problems objectives, success metrics, and high-level features (aka goal model)
Capability table
A tool used to examine problems, their root causes, and needed capabilities.
Activity diagram
A type of process model that visually shows the complex flow of use cases. It's similar to process flows in syntax; however, it commonly shows user and system interactions in one diagram and mirror the textual description of use cases (See Process Flow).
Software requirements specification
A type of requirements documentation that includes the functional and nonfunctional requirements of a software system.
Feature model
A visual representation of the features of a solution in a tree or hierarchical structure.
Display action response model
A way to describe the desired behaviors of the components on a wireframe or screen mockup.
Quality requirements (product acceptance criteria)
Acceptance criteria for the solution (i.e., the conditions needed to validate the success of the solution).
Entity relationship diagram
An analysis technique used to elicit and capture the information needs of a business.
Elicitation plan
An informal device used by business analysts to prepare for elicitation work.
Process model or map
Analysis diagram and technique used to better understand a process (aka flowchart, workflow, SIPOC, process map).
Opportunity analysis
Analysis technique to determine the potential viability of successfully launching a new product or service.
Persona analysis
Analyzing a type of user or worker (aka persona) to understand needs for product design. A persona is a fictional character created to represent a user group.
Feasibility analysis
Analyzing the ability of the organization to create the requested solution.
Force field analysis
Analyzing the expected pressures for and against a change or new idea.
Delphi method
Anonymous information gathering technique resulting in consensus of group experts.
Story map
Arrangement of user stories; usually built with lightweight tools like sticky notes, to show release plans, priorities, and dependences between stories.
Business case/business value, cost-benefit analysis
Assessing the value or benefits an organization aims to receive as a result of a project and comparing them to the estimated costs. A business case provides justification for the project.
Allocate requirements
Assigning requirements to specific solution components to verify they are included; or assigning requirements to releases or phases (aka tracing requirements)
Defining and aligning process group
BA processes performed to investigate and evaluate the viability of initiating a new product or changes to or retirement of an existing product. Also, define scope and align products, portfolios, programs, and projects to the overall organizational strategy.
Functional requirements (solution requirement)
Behaviors that the new solution or product will provide as a business improvement. If the solution is a process change, these requirements describe how the process will change. If a new product/solution, these requirements will include features and descriptions of the new product (what it will do and how it will work).
Decomposition model
Breakdown of a component for analysis; can be used for solution scope, functions processes, problems, goals, organizational unites, project work, etc. (e.g., WBS).
Business rules analysis/rule model
Business rules are policies, guidelines, and constraints that guide the work of the business. A rule model is a collection of rules with supporting definitions, relationships, and details.
Rule models
Business rules catalog, Decision tree, Decision table -- Models of concepts and behaviors that define or constrain aspects of a business to enforce established business policies.
Interrelationship diagram
Cause and effect diagram used to visualize complex problems.
Requirements attributes
Characteristics of requirements, e.g., name, unique identifier, date, identified, priority, source, and status.
Control chart
Chart used in project management to show how a process behaves over time to determine whether a process is in control.
Walkthrough/requirements review
Collaborative working review of a set of requirements to ensure the requirements are stated correctly and are valid (aka requirements walkthrough, structured walkthrough).
Configuration management
Collection of formally documented processes, templates, and documentation used to apply governance changes to the solution or subcomponent under development.
Benchmarking
Comparing metrics or processes of two similar organizations (within the same company or competitors) looking for potential improvements.
Characteristics of requirements
Complete, correct, feasible, necessary, prioritized, unambiguous, and verifiable.
Brainstorming
Creative idea generation that focuses on thinking outside of traditional solutions.
Requirements package
Culmination of a set of product information that is used to communicate information about the solution at a specific point in time (e.g., at the end of a phase or iteration). This will be informal for adaptive lifecycles. This can also be established in the requirements management tools.
Use case/use case diagram
Describes a set of scenarios. A series of activities, actions, and reactions that take the primary actor from initiation to successful completion of the goal. Represents functional aspects of a system. Can be useful in creating tests. Helps to identify functional and non-functional requirements. Nonfunctional requirements are usually placed in another document.
Solution (or product) requirements
Describes the features, functions, and characteristics of a product, service, or result that will meet the business and stakeholder requirements; these can be further grouped into functional and nonfunctional requirements.
Business analysis approach
Description of how business analysis processes will be conducted for a portfolio component, program, or project.
Control point
Designated even for the conclusion of a segment of work to evaluate progress against plans and the project charter and business case to determine if the project should be changed, terminated, or continued as planned. Stage gates or phase gates are examples. Evaluation at the end of a sprint, iteration, or release are also examples of this.
Elaboration (progressive)
Developing more details or more clarity within requirements or models.
Decision tree
Diagram showing how a decision is made, including the factors used to make the decision.
Flowchart
Diagram that shows processes or procedures with shapes and arrows (aka process flow, process map, workflow diagram).
Organizational modeling, organizational breakdown, organizational chart
Diagrams or documents describing an organization's people, locations, operating units, products, services, and any other important information about the organization.
RFP, RFQ, RFI
Docs used to get information about possible solutions from vendors, suppliers, or sellers.
State table and state diagram
Documentation options for state analysis; looking at an object from its inception to termination and allowable transitions (aka lifecycle analysis).
Baselining
Documenting or freezing requirements at a particular point in time so you can refer back to them later.
Interface analysis
Elicitation and analysis technique for understanding and designing interactions between people, processes, systems, or equipment.
Joint application development or design
Elicitation technique used to bring a group of stakeholders to consensus about requirements or design (aka facilitated workshop).
Workshop
Elicitation technique used when a group of shareholders share needs and will share the resulting product or process (aka facilitated workshop, requirements workshop).
Facilitated workshop
Elicitation technique used when a group of stakeholders share needs and will share the resulting product or process (aka workshops, requirements workshops).
Data models
Entity relationship diagram, Data flow diagram, data dictionary, State table, State diagram -- Models that document the data used in a process or system and its life cycle.
Risk analysis
Examining and prioritizing risks for a program, project, or business. Risks are assessed for probability and impact; both quant and qual risk analyses are parts of project management.
Net present value (NPV)
Financial calculation that predicts the current value of the proposed project based on estimated future benefits; often used to compare proposals.
Stakeholder identification
Finding all the people and organizations that could impact or be impacted by the project results.
Report table
Format for documenting requirements related to a specific report; usually in conjunction with a report layout mockup.
System interface table
Format for documenting requirements related to an automated interface between two systems.
Exploratory testing
Free-form unscripted testing where the tester makes decisions about what to test. Often used when requirements aren't available. A validation activity used to determine if a solution is working as intended and may include ease of use, functional, and performance evaluations.
Alternative analysis
Generating and evaluating options or alternatives; in PM alternative analysis is used to evaluate ideas about how to conduct the project; in BA this is used to evaluate solution options.
Scope models
Goal and business objectives model, Ecosystem map, Context diagram, Feature model, Org chart, Use case diagram, Decomposition model, Fishbone diagram, Interrelationship diagram, SWOT diagram -- Models that structure and organize the features, functions, and boundaries of the business domain under analysis.
Requirements Traceability Matrix
Grid linking product or solution objectives to requirements solution deliverables, and/or test cases (aka traceability matrix).
Nominal group
Group analysis technique using brainstorming for idea generation and interactive voting to rank the most useful ideas.
Multi-voting
Group decision making technique allowing participants to choose their preferred options from a list, resulting in a final list agreed to by all.
PEST, PESTLE analysis
Group of techniques used to investigate aspects of the global business environment, including political, economic, sociocultural, technological, legal, and environmental.
Peer review
Human based testing; reviewing someone else's work to find inconsistencies, errors, and quality improvements.
Root cause analysis
Includes fishbone, cause and effect, Ishikawa diagrams and the 5 whys; Analytical techniques used to find the underlying or core problem given as set of symptoms, e.g. defects, risks, or variances.
Analysis knowledge area
Includes the processes for examining, breaking down, synthesizing, and clarifying information to further understand it, complete it, and improve it.
Active listening
Intense, focused listening to both verbal and nonverbal communications, paraphrasing back to confirm understanding.
Stakeholder analysis
Learning about each stakeholder's values and needs and determining the best elicitation, communication, and requirements presentation technique.
Glossary
List of business and requirements terms and definitions (important!).
Data dictionary
List of named pieces of information (data elements) along with definitions of their meanings and usage.
Product backlog
List of outstanding features, functions, capabilities, requirements, defects, etc. for a product (aka backlog).
Problem tracking
Logging and resolving problems during a project (aka issue log, defect tracking)
Wireframe
Low fidelity prototype used to elicit design preferences and requirements for business functions (aka prototyping, mockup).
Backlog management
Maintaining a list of requests on an adaptive life cycle project.
Ecosystem map
Map showing relevant systems and the relationships between them to help with scope and interface analysis.
CRUD matrix
Matrix used in data analysis to ensure every data element is supported by processes that perform these activities: Create, Read, Update, Delete.
Retrospective
Meeting in which participants discuss their past work in order to find better processes and ways to produce better products.
Focus group
Meeting with customers or other stakeholders to elicit feedback on existing or new product ideas. Used to gain feedback on completed work or prototypes. Group members are prequalified or prescreened to ensure they meet the desired target group.
Group decision making
Methods used when more than one person is involved in making a decisions; i.e., majority rules, unanimity, consensus, compromise, and autocratic.
Metrics/measurements
Objective, quantitative information used for solution evaluation and as-is/future-state comparisons.
Define acceptance criteria
Obtaining agreement of what constitutes proof that one or more solution aspects have been successfully developed.
Weighted criteria, weighted ranking
Options are ranked by agreed-upon criteria and weighted based on the expectation of adherence to the criteria to facilitate objective decision making.
Expected Monetary Value (EMV)
PM calculation that is an accepted practice to estimate a value for cost-related contingency reserves based on the possible outcomes that might result from threats and/or opportunities.
Change management
Plan that defines the process for managing change on the project.
Interviewing
Planned conversations with stakeholders, resulting in elicitation of documented information or requirements.
Organizational process asset
Plans, processes, policies, procedures, and knowledge bases that are specific to and used by the performing organization.
Impact analysis
Predicting the ramifications of a requested change on requirements, the solution, or the project.
Document system management
Procedures and tools used to store, trach, version, and archive documents.
Process models
Process flow, Use case, User story -- Models that describe business processes and ways in which stakeholders interact with those processes.
Assess business analysis performance
Process of considering effectiveness of the business analysis practices in use across the organization; typically in the context of considering ongoing deliverables and results of portfolio components, programs, or project.
Assess product design options
Process of identifying, analyzing, and comparing solution design options based on the business goals and objectives, expected costs of implementation, feasibility, and associated risks and using the results of this assessment to provide recommendations regarding the design options presented.
Confirm elicitation results
Process of performing follow up activities on the elicitation results. Determining an appropriate level of formality to use, reviewing with stakeholders, and comparing historical information.
Assemble business case
Process of synthesizing well-researched and analyzed information to support the selection of the best portfolio components, programs, or projects to address the business goals and objectives.
Conduct business analysis planning
Process performed to obtain shared agreement regarding business analysis activities the team will perform and the assignment of roles, responsibilities, and skillsets for the tasks require to successfully complete the BA work.
Select and approve requirements
Process that facilitates discussions with stakeholders to negotiate and confirm requirements which should be incorporated within an iteration, release, or product.
Return on Investment (ROI)
Projected % return on an investment calculated by taking the projected average of all net benefits and dividing them by the initial cost; typically based on minimum ROI required (aka hurdle rate).
Internal rate of return (IRR)
Projected annual yield to determine if funding should be invested in a project; typically based on a minimum IRR required (hurdle rate).
Storyboard
Prototyping technique showing navigation through a series of screens, web pages, or other user interfaces.
Integration testing
QA work to ensure solution components work together as designed.
Prioritization of requirements
Recognition that not all requirements will result in the same value to the organization; also, a set of analysis techniques to help a group of stakeholders agree on development priorities.
Data conversion
Reformatting existing business information for use in a new solution (part of transition requirements).
Interface models
Report table, System interface table, User interface flow, Wireframes, Display action response -- Models that assist in understanding specifics systems and their relationships with a solution.
Regulatory requirements
Requirements generated due to legal and/or other industry demands, e.g., SOX, GDPR, etc.
User stories
Requirements technique used to capture brief descriptions of of user needs for estimating and planning adaptive methodologies.
Business requirements
Requirements that describe the higher-level needs of the organization such as business issues or opportunities; provide the rationale for why the project is being undertaken. Usually stated as a business need by stakeholders, stated or diagrammed using business language. Shows how the business gets work done, what information is used, how decisions are made (business rules), and describes the problems/opportunities.
Nonfunctional requirements (solution requirement)
Requirements that express properties that the product is required to have, including interface, environment, and quality attribute properties. Often referred to as the "abilities", e.g., performance needs, volume needs, and technical requirements.
Transition requirements
Requirements that help clarify the training that will be needed for converting existing data into the new system, as well as communications for letting all new stakeholders know about the change and its impact on their work.
RACI
Responsible, Accountable, Consult, Inform
Regression testing
Retesting a unit, subsystem or system that has already been tested and then changed to ensure the change did not negatively impact the existing functionality.
Document analysis/research
Reviewing existing documents, systems, or published or unpublished sources to learn about a business or technology.
Dependency analysis
Reviewing how one requirement is dependent on another requirement; usually done with a traceability matrix.
Day in the Life Testing (DITL)
Semiformal testing that enables evaluation of solution functionality for typical usage.
Data flow diagram
Shows business processes with information needed by each process (inputs) and information created by each process (outputs); also shows where the information or "data" flows.
Confirmed elicitation results
Signify that the product team has reached a common understanding and agrees to the accuracy of the information elicited.
Work breakdown structure
Specialized decomposition diagram used to analyze the scope of the project broken down into manageable deliverables required to be completed by the team to produce the project results.
SMART
Specific, Measurable, Attainable, Realistic, Timely
Project requirements
Specifications needed by the project team to complete the project. Includes budget, time, resources, and skills. Responsibility of the PM (NOT the BA).
Unified Modeling Language (UML)
Standard maintained by the Object Management Group to ensure consistency in diagramming and modeling in object-oriented analysis and design.
Requirements state
Status or condition of a requirement, e.g., deferred, rejected or approved.
Version control system
System used by project team to manage versions of documents, diagrams, product components, or other deliverables. May be part of a configuration management system.
Configuration management system
System used by project team to store and manage project documents, diagrams, product components or other deliverables.
Decision table
Table showing complex business rules by listing conditions and resulting conclusions.
MoSCoW analysis
Technique for documenting requirements prioritization using must, should, could, or won't.
Monte Carlo analysis
Technique used in PM to simulate the outcome of a project based on 3-point estimates for each activity and the network diagram.
SWOT analysis
Technique used to analyze an organization comparing its internal state (strengths and weaknesses) to the external environment (opportunities and threats).
Job analysis
Technique used when creating job descriptions to clearly outline the activities to be performed and the skills needed to perform them well.
Unit testing
Testing small piece of the solution (subprogram, subroutine, or module) referred to as a unit; a small piece that can be tested independently. Typically the first phase of testing because localized problems are easier to fix.
Acceptance criteria
The conditions that must be met for a solution to be considered acceptable to key stakeholders.
Payback period
The length of time that it takes for a project to fully recover its initial cost out of the net cash inflows that it generates.
Validation (requirements)
The process of ensuring a product or deliverable meets the needs of the customer or other stakeholders.
Verification (requirements)
The process of ensuring that a product or deliverable conforms to standards, regulations or a specified requirement.
Stakeholder management plan
The stakeholder management plan is a subsidiary plan of the project management plan that defines the processes, procedures, tools, and techniques to effectively engage stakeholders in project decisions and execution based on the analysis of their needs, interests, and potential impact.
Prototyping
Tools used to present a product idea or model of a final product to a stakeholder for feedback (aka wireframes, storyboards, mockups).
Object diagram
UML diagram showing the structure of a system at a point in time.
Systems thinking
Understanding the linkages and interactions both within and among systems.
User acceptance testing (UAT)
Validation or evaluation testing executed by knowledgeable users prior to implementation to ensure expected business value will be realized.
Inspection
Verifying requirements, a solution component, or the solution, making sure they conform to standards and are without errors (aka review, product review, walkthrough).
Observation
Watching a business worker perform a process to learn more about the work than could be gathered when reading a procedure or listening to a description (aka job shadowing).
Survey or Questionnaire
Written sets of questions designed to quickly accumulate information from a large number of respondents. Beneficial for collecting a large amount of information from a large group over a short period of time at a relatively small expense.
