Become A Business Analysis Detective

By

Sometimes, figuring out your user’s needs is a mystery. Becoming a business analysis detective allows you to get to the bottom of what your users really need, and why they need it. Let’s explore the basics of what requirements are and why they matter, techniques for gathering requirements, and then finally documenting requirements. Ready to get on the case?

What are requirements?

Requirements, simply put, are something that someone needs. In this case, we’re looking at needs as stated by a stakeholder. To be a requirement, it must be quantifiable and verifiable. This means that your requirement can’t be, for example, to make something prettier or more user-friendly, because there is no way to measure something’s attractiveness or user-friendliness. 
Another important thing to remember about requirements is that even though you, as the Business Analyst or Salesforce Admin, wrote them, you do not own them. The stakeholder owns them. 

Why do we need requirements?

Requirements tell the Salesforce Admin and Test Engineers what problem needs to be solved and what to test. They also give managers an easy way to see the progression of a project. Think of a requirements document as a contract between you and the stakeholder – here are the list of items we agree needs to happen before this project can be marked as “completed”. 

Requirement elicitation

There are several ways to gather your requirements. Each one is different and has its pros and cons. Some methods of requirement elicitation work better depending on how many stakeholders you’re working with and where they’re located, for example. Some methods include interviews, workshops, and using comparable and rival products. Find what works for you but remember it could be different for each group or each project. 

Documenting

So, you have this comprehensive list of requirements. Now what?

The goal of documenting requirements is to have clarity in the project. Putting all the clues together will allow you to crack the case! One of the lessons that I learned the hard way (and after writing many requirements documents) is that more words do not equal better requirements. Try to write each requirement as one short sentence. 

The first thing to remember is that there is no need to get the wording perfect on the first try. Keep the requirements simple and concise. Once you feel the requirements are in a good place, the second step is to send them to the stakeholder(s) and review the requirements with them. Remember, you all want to agree on what you’ve discovered and what a complete project will look like.

Finally, when all of the stakeholders sign off and agree to the written requirements, you can mark this project complete. Don’t forget to note what worked well for you, so you can add it to your #AwesomeAdmin toolbox for next time. 

So now we know what requirements are, why they’re important, how we get them, and how and why we write them. I hope that you take some pieces of information from this and are able to apply it to your next project!

Make Your Sales and Service Reps' Lives Easier with AI.

5 Ways to Make Your Sales and Service Reps’ Lives Easier with AI

Salesforce is ever-expanding its product offerings, and this year, the most fantastic features of the platform are all things artificial intelligence (AI). Have you started exploring capabilities? Are you truly getting the most from the features? In this post, we’ll cover five ways to make your sales and service reps’ lives easier with AI. 1. […]

READ MORE
How to Prepare Your Org for an AI-Driven Future.

How to Prepare Your Org for an AI-Driven Future

This blog post was written by myself and Tom Bassett and is an abbreviated version of the presentation we delivered at Dreamforce ’23, where we explored how you can prepare your Salesforce org for the artificial intelligence (AI) revolution. We invite you to read this post, which outlines the key steps you can take, but […]

READ MORE
How to Use Salesforce to Manage Your Documentation

How to Use Salesforce to Manage Your Documentation

No matter the size of your organization, or how many admins you have on your team (if you have a team!), one of the last things you probably enjoy doing is writing documentation. I hear you—it’s hard to start writing documentation, know what to capture, and figure out where to put it so you’ll actually […]

READ MORE