Salesforce Certified Business Analyst Practice Test - Questions Answers, Page 12

The best practice for managing requested changes to the original requirements is to use a change request log and user stories. A change request log is a document that tracks and records any changes that are requested by stakeholders or identified by the project team during the project lifecycle. A user story is a concise statement that describes what a user wants to do and why they want to do it in Salesforce. The BA should update the change request log with the details of the requested change, such as the description, source, priority, impact, status, and approval. The BA should also draft a new user story that captures the requested change in terms of who, what, and why, and add it to the backlog for prioritization and development.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/business-analysis-change-management/manage-change-requests https://trailhead.salesforce.com/en/content/learn/modules/business-analysis-user-stories/write-user-stories

A functional requirements specification (FRS) is a document that defines what features and functions a system should provide to meet the business needs and objectives. It describes how users will interact with the system and what outcomes they expect from it. An FRS typically includes use cases, user stories, acceptance criteria, data models, business rules, workflows, diagrams, mockups, and other details that describe how the system should work. A BA should create an FRS to define the enhancement features for the current Salesforce CPQ implementation that must be configured in the next phase of the project.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/business-analysis-functional-requirements/understand-functional-requirements

A user story is a type of documentation that describes what functionality a system should provide from a user's perspective. It is written in simple language that anyone can understand and follows a standard format of ''As a [user role], I want [functionality], so that [benefit]''. A user story helps to capture the user's needs and expectations from the system and provides a basis for developing test cases and acceptance criteria. A BA should use user stories to document the functionality that a system should provide so it can be developed into a work item.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/business-analysis-user-stories/write-user-stories

Whiteboarding is a technique that involves using a whiteboard or a similar tool to visually represent a process, problem, or solution. Whiteboarding helps the BA collaborate with multiple stakeholders by building a shared understanding of the current state, creating a space for everyone to contribute since the activity feels shared, and guiding the conversation while maintaining engagement. Whiteboarding also helps to identify issues, gaps, opportunities, and dependencies in the process, and to generate ideas and feedback from stakeholders.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/business-analysis-process-mapping/plan-and-facilitate-a-process-mapping-session

The best practice for preventing a session from being derailed by an off-topic stakeholder is to use a ''parking lot'' technique. A parking lot is a list of topics or issues that are not relevant to the current session but may need further discussion or resolution later. The BA should add the stakeholder's concerns to a parking lot for further discussion, and acknowledge that they are important but out of scope for the current session. This way, the BA can keep the session focused on the onboarding process and avoid wasting time or losing engagement from other stakeholders.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/business-analysis-process-mapping/plan-and-facilitate-a-process-mapping-session

The option that captures this requirement is ''Make the template user-friendly and accessible only by members of the account team.'' This option clearly states what needs to be done (make the template user-friendly and accessible) and who it is for (members of the account team). The other options are either incomplete or irrelevant. Option B does not specify what needs to be done or who it is for. Option C does not specify what needs to be done or why it is important.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/business-analysis-requirements/understand-requirements

This answer provides an example of how to construct the user story for creating a new picklist field called ''Lost Reason'' on the Opportunity object with the goal of improving pipeline reports, using this format: As a , I want <goal>, so that <value>. This answer defines the persona as ''sales leader'', who is likely to be one of the main users or beneficiaries of this feature. It also defines the goal as ''see more details on Closed/Lost Opportunities'', which is what they want to accomplish with this feature. Finally, it defines the value as ''help the sales team improve close rates'', which is why they want to accomplish this goal and how they will measure success.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/salesforce-business-analyst-quick-look/use-user-stories-to-capture-requirements

The best practice for giving all team members access and visibility to the most recent user stories as the project is in motion is to define a common repository to hold all user stories and track changes over time. A common repository is a centralized location where all user stories are stored and managed. It allows all team members to access, view, edit, comment, prioritize, assign, and update user stories as needed. It also tracks changes over time and provides version control and history of user stories. A common repository can be a tool such as Jira, Trello, Asana, or Salesforce Agile Accelerator.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/business-analysis-user-stories/manage-user-stories

This answer states that using who, what, and why is what each user story should include for optimizing a very manual process in its Salesforce org. Who refers to the persona, which is a fictional representation of a typical user or stakeholder who will use or benefit from a feature or a functionality. What refers to the goal, which is what the user or stakeholder wants to accomplish with the feature or functionality. Why refers to the value, which is why the user or stakeholder wants to accomplish the goal, and how they will measure success. Using who, what, and why can help the BA to write effective user stories that capture and prioritize the requirements, and align them with the stakeholder value and expectations.

Reference: https://trailhead.salesforce.com/en/content/learn/modules/salesforce-business-analyst-quick-look/use-user-stories-to-capture-requirements