Requirements Gathering Outline for Salesforce Projects

Home     /     Blog     /     Requirements Gathering Outline for Salesforce Projects

Before you can begin building or improving Salesforce, or a related system, it's critical that you first define requirements. We often see admins jumping directly into building, before really spending time understanding the Why behind a project.

This blog post will help you understand how to break projects down into four separate categories and what questions to ask for each. From there, you should have what you need to 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. Often, you'll get requests like: Our opportunity process is broken.

Vague statements like that require deep questioning to understand how things are operating today(if at all) and how they ought to work. Often, you'll find that business leaders don't understand how systems work from a technical perspective. In our mind, it's critical that you first define what you're looking to accomplish and from there dig into four key categories.

Business Requirements

When scoping business requirements you ultimately need to understand: What is the business trying to accomplish with this project?

Naive project managers will often jump straight into solutioning, however, we think the best way to scope is to first learn about the why.

  • 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?
  • Describe “What” is done currently.
  • What is the project team expected to implement or deliver?
  • What the goals would be for the project?
  • What are the objectives needed to reach the goals?
  • What could prevent this project from meeting its business objectives?
  • What are the benefits of doing this project?
  • What are the critical success factors?
  • What are the specific measurable benefits for doing the project?
  • What are your 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're not building systems for the sake of building systems. We're building systems to help users operate more efficiently. It's critical that you take into consideration who and how your users will be using it; 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.

  • 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 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?
  • What user roles interact with the system?
  • What are the goals of each user role?
  • What other systems need data from this system?

Functional Requirements

Functional requirements are really how the system will function. These questions should answer, in detail, what the system does and how the system does it.


Functional requirements are really how the system will function. These questions should answer, in detail, what the system does and how the system does it.

  • 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 do 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

You can think of non-functional requirements as the qualitative aspects of a build.

  • 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?

How These Move the Needle

We find that breaking down requirements gathering into four distinct categories simplifies the process and helps pull your go-live dates forward while, at the same time, preventing issues.

Related Articles