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?
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.
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”.
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.
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!
In the blink of an eye, Dreamforce 2024 has come and gone! Whether you joined us in person or streamed content on Salesforce+, we hope you discovered new strategies to keep growing your skills and advancing your admin careers. Featuring more than 50 theater and breakout sessions in the Admin Meadow, plus a phenomenal Admin […]
Dreamforce ’24 is just around the corner, and it’s packed with opportunities to help Awesome Admins succeed in their ever-evolving roles. Learn how you can be instrumental in the AI era and continue developing your skills through the admin core responsibilities — at Dreamforce and beyond! You’ll discover how to leverage AI and data, grow […]
As admins, you hold the keys to success for your users and companies to get the most out of Salesforce. You have the unique opportunity to build and manage trusted solutions that drive productivity and innovation through five core admin responsibilities: security, user management, data management, analytics, and a new core responsibility: product management. The […]
