Book Image

The Salesforce Business Analyst Handbook

By : Srini Munagavalasa
5 (1)
Book Image

The Salesforce Business Analyst Handbook

5 (1)
By: Srini Munagavalasa

Overview of this book

Salesforce business analysis skills are in high demand, and there are scant resources to satisfy this demand. This practical guide for business analysts contains all the tools, techniques, and processes needed to create business value and improve user adoption. The Salesforce Business Analyst Handbook begins with the most crucial element of any business analysis activity: identifying business requirements. You’ll learn how to use tacit business analysis and Salesforce system analysis skills to rank and stack all requirements as well as get buy-in from stakeholders. Once you understand the requirements, you’ll work on transforming them into working software via prototyping, mockups, and wireframing. But what good is a product if the customer cannot use it? To help you achieve that, this book will discuss various testing strategies and show you how to tailor testing scenarios that align with business requirements documents. Toward the end, you’ll find out how to create easy-to-use training material for your customers and focus on post-production support – one of the most critical phases. Your customers will stay with you if you support them when they need it! By the end of this Salesforce book, you’ll be able to successfully navigate every phase of a project and confidently apply your new knowledge in your own Salesforce implementations.
Table of Contents (21 chapters)
1
Part 1: Planning and Analysis – BRD/Prioritized Product Backlog
7
Part 2: Design, Development, and Testing – Iterative Cycles with Prototypes and Conference Room Pilots
13
Part 3: End User Testing, Communication, Training, and Support

Practical tips for success

Listed here are a few practical tips that added value to my own RTMs:

  • RTMs can get very complex. No matter what tool you use, try to keep it simple and extract an Excel or PDF version (at least one daily snapshot) and make it available to all project team members.
  • Certain business rules cannot be traced, and you do not waste project time and effort writing test scripts for those unless they are critical for your organization. For example, a user will use only company domain-specific emails and not personal emails, or users should be on the company network/VPN to access an application.
  • Keep your RTM current. Anytime there are changes to any project artifacts such as BRD, FDD, DDD, and test scripts, make sure the RTM is reviewed and updated.
  • The RTM responsibility should be given to only a few team members so that only they are authorized to make additions or updates to the matrix. Always keep track of the version, even if you manage the...