Requirements
These notes were taken while studying using Mike Wheeler's Salesforce Courses.
Requirements Knowledge Area Intro (64)
Writing Good Salesforce Requirements (65)
- Requirements are something that someone needs
- Keep requirements simple and concise, get review from stakeholders, as well as their feedback
Requirements vs User Stories (66)
- The Documentation section on Salesforce differentiates between three types of documents:
- Functional Requirements Specification (FRS) - more specific/business
- System Requirements Specification (SRS) - more holistic/technical
- User Stories - multiple user stories may be necessary to capture a single requirement
- “As <who> I want to <what> so that I can <why>”
- Images below from a Salesforce presentation called Weathering the Storm of Change Management
- “Your mileage may vary” with Salesforce Premier - Mike Wheeler
LinkedIn Integration Guide (67)
- Salesforce has an integration to ingest LinkedIn data called LinkedIn Sales Navigator Advanced
Why Stakeholder Alignment is Key to Salesforce Success (68)
- COBIT5 is a business framework standard for the governance and management of enterprise IT
- Framework you can reference when working as a BA
- Important for the team to have One Vision
- From a Salesforce article, Why Stakeholder Alignment is Key to Salesforce Success:
- “The vision should be in business terms and include clear business outcomes that the program wants to achieve. The document also should have a clear set of measurements attached to the project to verify that the business outcomes are being achieved. If possible these KPI’s should have a direct linkage to executive stakeholder KPI’s.”
- From a Salesforce article, Why Stakeholder Alignment is Key to Salesforce Success:
Change Set Development Model (69)
- Trailhead and Developer orgs do not have sandbox creation available
- Change sets should generally only include items that have changed since the last release
- You can use a change set to add new and changed components, but you can’t use change sets to delete or rename components:
- To delete components, use the web interface in the target org
- To rename a component, first delete the component in the target org and then upload the new component in a change set
Profile and Permission Set Considerations with Change Sets (70)
- Make sure to include Profiles and Permission Sets in change sets if you are making access changes to custom fields
Change Set Best Practices (71)
- Salesforce Change Sets Best Practices
- Make sure each outbound change set includes all interdependent components that don’t exist in the target org
Package Development Model (72)
- Package Development is intended for developers, primarily, but the concepts can be helpful for business analysts
- As releases become more and more complex, teams tend to gravitate toward a “Package Development” model
- Especially helpful for orgs with multiple development teams/admins
- A Version Control System is useful to track changes to orgs
- Note scratch orgs are different than sandbox orgs
Git and GitHub Basics (73)
- GitHub easily integrates with SFDX (Salesforce Development Experience)
- Main point of GitHub for a Business Analyst is that it is a tool to let you track changes over time
Salesforce Files for a Version Controlled Repository to Manage Scope (74)
- Using Salesforce Files could be another way to manage version control of scope documents
- Click the down carat then “Upload New Version” to create a new version of the same file
- Past versions are available on the Files object
Requirements Practice Questions on Trailhead (75)
- When using the package development model, which metadata changes need to be tracked manually? Changes made via the Setup UI