Requirements Gathering Outline for Salesforce Projects

This post was last updated on 11/17/23.

Overview

Before you can begin building or improving Salesforce, or a related system, it’s critical that you define your requirements. We often see admins jump directly into building before spending time understanding the “why” behind a project. Unfortunately, the project almost always suffers for it.

In this post, we’ll help you understand how to break projects down into four separate categories, and identify what questions you should ask for each of those categories. This will help you identify a solution that will 1) solve the problem you face today and 2) allow you to scale.

IF I HAD EIGHT HOURS TO CHOP DOWN A TREE, I’D SPEND SIX SHARPENING MY AXE.

– Abraham Lincoln

How Kicksaw Works

At Kicksaw, we take opaque business requirements and turn them into technical projects.

We frequently hear complaints such as, “Our opportunity process is broken,” from clients who have partnered with us for help transforming their Salesforce operations.

Vague statements such that require deep questioning on our end to understand how things are operating today (if they are at all) and how they ought to work. Business leaders frequently don’t understand how systems work from a technical perspective. From our perspective, though, it’s critical to first define what business leaders are looking to accomplish, and from there, dig into the following four key categories.

Business Requirements

When scoping business requirements, you ultimately need to understand what the business is trying to accomplish with the project.

Naive project managers will often jump straight into developing a solution. However, we believe the best approach is to first learn all we can about the why.

QUESTIONS

• What business opportunity or problem led to this initiative?
• What is the business vision?
• What are the key business issues faced today?
• What is the purpose of the business area?
• Can you describe what the current process entails?
• What is the project team expected to implement or deliver?
• What are the goals for the project?
• What are the business objectives needed to reach the goals?
• What could prevent this project from meeting the business objectives?
• What are the benefits of doing this project?
• What are the critical success factors?
• What are the specific measurable benefits anticipated?
• What are the success metrics/KPIs?
• What business processes support the business purpose?
• Who will benefit from this product or system?
• Who may be opposed to this product or system?
• Who are the experts in this business process?
• What internal and external entities are affected by the scope of this project?

User Requirements

We don’t build systems for the sake of building systems. We build systems to help users operate more efficiently. It’s critical that you take into consideration who and how your users will be using the system, how experienced they are, and what sort of training/coaching will be needed.

Pushing an update straight to SFDC without thinking about how users are impacted is a surefire way to kill adoption right out of the gate.

QUESTIONS

• Who will use the system under development?
• Who performs tasks or activities in the business processes?
• What department or business area is impacted by this system function?
• What areas of the business are affected by changes to the system?
• Who benefits most from this project?
• Who does this system interface with?
• What is the source of information that is input into the system?
• Who is the recipient of information from the system?
• What external organizations interact with the system?
• Who needs to access the system?
• What role(s) might be alleviated if this process is automated?
• What work does the system help the business unit perform?
• Which user roles interact with the system?
• What are the goals of each user role?
• What other systems need data from this system?

Functional Requirements

These questions should answer, in detail, what the system does and how the system does it. In other words, they should describe how the system is expected to function.

QUESTIONS

• What does the system have to do to support each end-user?
• When the user does “x,” the system does what?
• What data must be received? (Input processing)
• What data must be produced? (Output processing)
• What data must be retrieved, stored, and transferred?
• What calculations must be performed?
• What data must be edited?
• What data must be validated?
• What errors will the system be expected to handle?
• What business expectations must the system handle?
• What business rules need to be enforced by the system?
• What audits must the system conduct?
• What counters, tallies, triggers, timers, and schedules does the system have to maintain?
• What tasks and activities does the system automate?
• What inputs will the system process?
• What outputs will the system prepare?
• What features are expected by the user?
• What functions does the system help the user to perform?

Non-Functional Requirements

Think of non-functional requirements as the qualitative aspects of a build.

QUESTIONS

• How well is the system guarded against unauthorized access? (Access security)
• How dependable is the system during normal operations? (Availability)
• What are the system’s capabilities regarding capacity, throughput, and response time? (Efficiency)
• How accurate and authentic is the data captured by the system? (Integrity)
• How immune is the system from failure? (Reliability)
• How resilient is the system from failure?
• How easy is it to learn and operate the system? (Usability)
• How easy is it to modify the system to work in different environments? (Flexibility)
• How easy is it to upkeep and repair the system? (Maintainability)
• How easy is it to expand or upgrade the system’s capabilities? (Scalability)
• How easy is it to show that the system performs its functions?
• How easy is it to interface with another system?
• How easy is it to convert the solution for use in other business functions?

Set Yourself up for Success

We find that breaking down requirements gathering into these four distinct categories simplifies the entire process and helps pull your go-live dates forward while, at the same time, preventing issues. They set you up for success, and we wish you the best of luck with them!