Clarity is one of the most fundamental attributes of writing good requirements.
- Clear requirements are less likely to be misunderstood by business stakeholders and technical implementers.
- Clear requirements require fewer review cycles to confirm and validate them.
- Clear requirements lead to insightful questions, that show your power and value as a business analyst.
But what does “clear” really mean? And, more importantly, how do I know if my requirements are clear or not?
In this video, we cover 3 ways you can ensure your requirements are clear.
For those who like to read instead of watch, here’s the full text of the video:
Hello, this is Laura Brandenburg from Bridging the Gap. Today, we’re here to talk about how to write clearer requirements. Writing clear requirements is a foundational business analyst skill and is a foundation of writing good requirements.
When you write requirements in a clear way, you are making sure that they’re going to be properly understood by your business and your technical stakeholders. Clearer requirements tend to have fewer review cycles and validation cycles because you’re focusing less time on, what does this requirement mean instead of what do we want it to mean, and what do we what the requirement to be, which is how we should be investing our time and meetings as business analysts.
This is the important one ̶ when you write clear requirements and you take that time to make sure they’re clear, you’re going to come up with more questions…insightful questions that you can ask your business and technical stakeholders. This is going to showcase your power and your value as a business analyst.
Let’s jump right in. I’m going to share three ways that business analyst can write clear requirements, and how you can avoid mistakes and ambiguity.
Clear Requirements Tip 1 – Use Active Present Tense
The first tip, and the first thing to focus on is to write your requirements in what’s called active present tense. We have a tendency, sometimes, to use passive voice. We use passive voice when we are missing a piece of information that’s critical to the requirement.
For example:
- Job posting details are entered.
- Job posting details are saved.
That “is” and that “are” are indicators of passive voice. We want to avoid those like the plague in our requirements. Because it’s not clear who’s responsible for each step. I’m going to read you the alternative.
If I were putting these in a use case, I would write these two steps:
- Job poster enters job posting details
- The system saves the job posting details.
Now we’ve added a “who” or a “what” that clarifies who’s doing that action, which was missing before in the passive voice. We’ve replaced that “is” or “are” with an action verb that clearly describes the requirement. It’s much clearer as a result.
Clear Requirements Tip 2 – Use Terminology Consistently
The second way that we tend to be unclear about our requirements as business analysts is when we use terminology inconsistently. This can sneak into our requirements just by small variations of terms where when you have a community of people that are all familiar with the domain, they can read between the lines and they kind of know what you’re talking about.
But then, suddenly, you bring in a new developer, or you hire another person on your business team who’s sitting in on the requirements sessions, or you scale your team and some of that work is outsourced, or a new business analyst comes in and they’re trying to pick up the requirements where you left off. Those small variations are all going to create doubts. Are these really the same thing? Is a job poster and a job posting agent the same? Is job posting details the same as job details, or are they different? Somebody who’s really looking at your requirements with a fine-tooth comb could either have questions or they could make assumptions that aren’t actually true.
You want to go through and make sure that you’re using terms consistently. Take the time to define them in a glossary or a business domain model, and then as you write your business processes and your use cases, or however you document your processes and functional requirements. You want to make sure you’re using those terms consistently throughout as well.
Check out this quick video for more tips on using terminology consistently.
Clear Requirements Tip 3 – Avoid Combining Requirements
The final tip I want to share with you today is to avoid combining requirements. Often, words like “and,” “or,” “before,” and “after” mean that you’ve lumped multiple requirements together. It’s easy when you have that kind of lumping together, to focus on one part of the requirement and not the other and have either the business stakeholder miss validating part of the requirement, or the technical stakeholder and tester miss implementing part of that requirement. I’m just going to read you an example and see what you think.
“Job poster enters job posting details and reviews them before saving.”
Is that a clear requirement? There are a lot of active verbs in there. There’s not passive voice, but there are three requirements in that statement. I’m going to read it again. “Job poster enters job posting details and reviews them before saving.”
There’s a requirement for entering the job posting details. There’s a requirement for reviewing them. And there’s a requirement for saving them. Before saving, there’s this whole other requirement that kind of got tagged at the end with those two words.
If you were discussing that for implementation, some of those requirements would be likely to get missed. There’s a lack of clarity in our requirements. When we break it out in separate requirements, it’ll be much clearer.
Make Your Requirements Clearer Using These 3 Simple Checks
What I want you to do as a next step is use these three checks. I want you to go and look at your most recent requirements document, whatever kind of requirements document it was, and see if you can find any corrections to make.
As a bonus step, this is where your career starts to take it to the next level, see if you can find another business analyst in your organization or outside your organization, go to your local chapter meetings and collaborate, connect with another BA, and review each other’s documentation. What’s going to happen as you do that, is you’re going to learn a lot more. It’s harder to see our own mistakes. It’s easier to see other’s mistakes.
This is why we offer instructor reviews as part of our virtual, business analysis training courses because people will go through the courses, go through these detailed checklists we provide, and they still don’t see their own mistakes, and then an instructor can point it out. The switch flips, and they’re able to make that correction.
You can do this on your own by doing peer reviews within your company or outside your company. You’ll learn a lot when you review somebody else’s as well because you’ll see what doesn’t come across as a clear requirement, and what kinds of ways that you need to improve your documentation to make sure it’s clear as well.
I want you to go ahead and do that. Please comment below any aha’s you’ve had from this lesson, any takeaways, any action steps that you’re going to take to review your documentation and share that with others.
Again, my name is Laura Brandenburg from Bridging the Gap. We help you start your business analyst career.
>>Improve Your Requirements Writing Skills
When you join The Business Analyst Blueprint® certification program, you’ll learn all 12 of the industry-standard techniques and the business analysis process framework – to build your confidence in the best practices of business analysis.
>> Click here for more information about The Blueprint <<
