Salesforce Business Analyst key terms

A visual summary that identifies the people and groups affected by or able to influence a project, along with their roles, interests, and level of influence, so engagement can be planned deliberately.

A simple canvas divided into what a customer says, thinks, does, and feels, used by a team to build a shared, human-centered understanding of a customer's experience and frustrations.

A research-based profile of a representative user group that summarizes typical goals, behaviors, skills, and frustrations, helping the team keep design and requirements focused on real customer needs.

A timeline showing the stages a customer goes through when interacting with an organization, including touchpoints, actions, emotions, and pain points, so improvement opportunities become visible.

The collection of customer opinions, needs, and expectations gathered through interviews, surveys, feedback, and observation, used to guide priorities and confirm that solutions address real demand.

A specific friction, obstacle, or unmet need that a customer experiences and that costs time, money, or satisfaction, often used to justify and prioritize a change.

A structured conversation with a stakeholder or user, conducted early in a project, to uncover goals, current processes, constraints, and frustrations before any solution is defined.

A description of how work is actually performed today, including steps, roles, handoffs, systems, and delays, serving as a baseline for measuring and designing improvement.

A description of how work should flow after the proposed change, showing future steps, roles, decision points, and system interactions, used to confirm the intended design with stakeholders.

A comparison of the current state with the desired future state that identifies missing capabilities, data, or process steps, helping the team justify, scope, and sequence the work.

A table that assigns each task or decision a Responsible party, an Accountable owner, people to be Consulted, and people to be Informed, making ownership explicit and reducing duplicated effort.

A planned group session led by a neutral facilitator who uses structured activities to gather input, resolve differences, and reach shared agreement on requirements or design.

A communication practice of giving full attention, reflecting back what was heard, and asking clarifying questions so the speaker feels understood and misunderstandings are caught early.

A structured approach to handling disagreement among stakeholders by surfacing underlying interests, exploring options, and agreeing on a way forward that the group can support.

A running record of significant decisions, including the date, the rationale, and who made the call, so the team can explain choices later and avoid reopening settled questions.

A single register that tracks Risks, Assumptions, Issues, and Dependencies for a project, reviewed regularly so the team can act early and keep stakeholders informed.

A plan that sets out how each stakeholder or group will be involved and communicated with, including frequency, channel, and level of detail, based on their influence and interest.

A statement of a high-level need, goal, or outcome the organization wants to achieve, expressed without prescribing a particular technical solution.

A description of a specific behavior or capability the solution must provide, such as what a user can do, what data is captured, or what the system must calculate.

A quality or constraint the solution must satisfy, such as performance, security, accessibility, or availability, rather than a particular behavior or feature.

A short statement of a need written from the user's point of view, commonly formatted as who the user is, what they want, and why it matters.

The specific, testable conditions that a user story or feature must meet before the business will accept it as complete and correct.

A large body of related work that delivers a meaningful capability but is too big to build at once, so it is broken into smaller user stories.

A table that links each requirement to its source, related design, test cases, and current status, making it possible to check coverage and assess the impact of changes.

A formal document that records the business problem, objectives, scope, stakeholders, and high-level requirements agreed with the business, serving as a reference throughout delivery.

A description of how an actor interacts with a system to accomplish a goal, including the normal flow of steps and the alternative paths that may occur.

A simplified representation of a proposed screen or workflow, ranging from a sketch to an interactive mock-up, used to confirm understanding and gather feedback before building.

A technique that groups requirements as Must have, Should have, Could have, or Won't have this time, helping stakeholders agree on what is essential when time or budget is limited.

The gradual, unmanaged expansion of project scope through small additions and changes that were never formally approved, which can threaten timeline, budget, and quality.

A document that explains how business analysis will be carried out, including the activities, techniques, deliverables, stakeholders, and schedule for the work.

The deliberate process of drawing information out of stakeholders using techniques such as interviews, workshops, observation, surveys, and document review, rather than waiting for requirements to arrive.

The work of identifying stakeholders and assessing their influence, interest, and impact on the project, so engagement and communication can be tailored to each group.

The activity of measuring how well a delivered solution meets business needs and objectives, using agreed metrics, and recommending improvements or corrective action.

A phase in which business users run realistic scenarios in a test environment to confirm that the solution meets agreed requirements before it is released.

Formal approval from accountable stakeholders that a deliverable, phase, or release meets agreed criteria and can proceed, usually recorded with a date and evidence.

The structured approach to helping people adopt a new process or system, covering communication, training, sponsorship, and support so the change actually sticks.

A technique for identifying the underlying reason a problem occurs instead of treating its symptoms, often by repeatedly asking why and testing the evidence.

A measurable indicator chosen to track progress toward a business objective, used to judge whether a change delivered the intended value.