One of the most important steps in a Salesforce implementation, whether you’re working with an implementation consultant or configuring the system yourself, is defining your requirements. Without clearly defining what the system needs to do, it’s very likely that important functionality will get missed, or will not be set up correctly. This will leave you with a system that is inefficient, or worse, does not support a core business need.
Defining system requirements and grouping them into a usable format is often a daunting task. Much like cleaning out the basement, it’s something you know needs to be done but can quickly become overwhelming. Where should you start? What level of detail should you go into?
In this blog post you’ll learn how to utilize use cases to capture requirements and some best practices to make requirements documentation less of a chore and more supportive of your implementation.
Imagine your nonprofit has a care center where you answer constituent questions. Maybe in the past when writing system requirements you’ve started with a list that looked something like this:
- The system shall accept cases from constituents submitted via the website
- The system shall route the case to the appropriate team for handling
- Constituents must be able to reopen a closed case
- Constituents must be able to edit and update and existing case
- Constituents must be able to submit attachments with a case
Although this list covers the basics of submitting a case, it also leaves out a lot of critical information about how they are handled. For example, what does a user need to do to submit a case? What information is needed to route it to the appropriate team? Without some additional context about your organization’s case-handling process, you might be in a situation where the requirement has been met, but your organization’s needs have not.
A better way to structure your requirements is through use cases. A use case is a sequence of actions that describes the interaction between a user and the software system to complete a set of steps for an activity you or your constituents need to accomplish. Ideally, a use case should include all of the following:
- A user (which could be either you or a constituent)
- Any data inputs and outputs required for an action
- A clear sequence of the steps that occur
- A specific result or goal (e.g., a successfully submitted case)
So how would we begin to write a use case for some of the requirements in the list above? Let’s start with a constituent submitting a case to the care center:
Use Case: Submit a Case to Customer Care
Brief Description:
This use case covers a constituent submitting a question or issue to the Customer Care team for resolution.
Basic Flow:
- Constituent logs into system. Email and password are used to validate the constituent’s credentials
- Constituent selects the option to create a case
- Constituent provides the information needed to describe their issue and process the case. Required Data: name, email, description of the issue. Optional Data: Phone number, attachment.
- Constituent has the option to submit the case or cancel. The constituent selects submit.
- The system validates that the case has all the required information. The system assigns the case a unique identification number and displays it to the constituent. The system also displays a message stating that the case has been successfully submitted. End of use case.
TIP: Start with a Sunny Day
A sunny day use case is a process flow that represents the most straightforward, successful path for an action. These are important because they help explain how the system should behave and can help you more easily identify what could go wrong. What if a constituent selects cancel? What happens if all the required information isn’t included? Once your sunny day case has been established, you can add supplementary flows for errors, exception cases, or optional steps that might happen only some of the time. This will help you avoid cumbersome, difficult-to-follow flows.
TIP: Keep Your Use Cases Simpler by Avoiding the CRUD
CRUD is a software development acronym for create, read, update, and delete. A user of a system will typically have some combination of these permissions to various records. The requirements list above mentions the need for constituents to be able to edit an existing case, and it is very important that you consider the various types of users you’ll have in Salesforce and what permissions they should have. It can be tempting to add these supplementary flows for edit, delete or read capabilities to a sunny day use case. However, the great thing about Salesforce is that you don’t need to include this information in a use case since Salesforce handles this through Profiles and Permission sets.
Tip: Start by Focusing on the “What” in Order to Identify the Most Efficient “How”
Another common pitfall when developing use cases is to start to specify how something is done, or get into the detail of how you’d like Salesforce to be set up to accomplish a task. In the use case above, we don’t specify how the constituent inputs the required information into a case (for example, selecting information from a drop down, typing into a free text field, etc.). But when you look at the use case, you may notice that the user has already input their email address in order to log into the system. Would it be possible for Salesforce to auto-populate some information on the case so the constituent doesn’t have to re-type it? The answer is yes. By keeping the use case focused on the “what,” it makes it easier to start to identify ways in which you might be able to configure Salesforce to streamline processes for constituents and internal users.
TIP: Circle Back and Update Use Cases to Complete the Picture
Suppose after building the use case for submitting a case, you want to move on to describing the case routing process. Perhaps this is currently something done manually, but since you’ve gotten the hang of writing good use cases, you focus on what data is needed to successfully route a case (not the “how” of your current manual process). A key piece of information is whether the case is related to services you provide or volunteering. A great feature of Salesforce is that you can utilize routing rules to get a case to the appropriate queue. However, you’ll need to document the requirement to collect that information when constituents submit a case. Since you have a use case clearly titled Submit a Support Case to Customer Care, you know where to go to update the information without having to scan through pages of long lists.
In this blog post you learned how to organize requirements into use cases to more easily identify related activities and see gaps in the data or process steps. Hopefully these best practices help you better capture critical information for your Salesforce configuration and make your implementation a success!
Related Posts:
