Become A Business Analysis Detective

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!