“Build the right product and build it right.”

This has become a mission of so many engineering teams. How do we do it, though?

It has two parts: building the right product and building it right. Let’s start dissecting it and tackle the first part of it: building the right product.

I often see quality analysts bridging that gap and promoting building the right product which increases the productivity of the teams enormously. For that, we’d need to look into requirements and do the requirement analysis with the QA in mind.

Best Books to Read Collage for Techies in 2022
Simplified workflow visual: Analysis with QA includes requirement analysis

We’ve touched on a good user story in the work items article in Quality Foundations. We’ve also discussed what it means that the story is ready for pick-up in Definition of Ready which is a concept that can help guide our journey towards better requirements. Now let’s take a deeper look into what the requirement analysis is, why it’s useful, and questions to ask when you get to work on requirements.

Disclaimer: this may not be something that works for every team - if your team is comfortable with lots of uncertainty and risk, it is possible that the team may not choose to do a thorough requirement analysis.

Table of Contents

What is requirement analysis?

Requirement analysis is an activity of studying, providing feedback, and (if needed) changing the expectations on how the product should work.

Who should be involved?

In the first round of requirement analysis, I’d recommend preparing the stories in the approach of Three Amigos.

Three Amigos is an approach where the business analyst (who wrote the story) meets up with the quality analyst, and the developer to go through requirements. They analyze the story together.

Some teams I’ve worked in also included a designer if there are design decisions that were made. In the later stages, you will also involve the whole team when presenting the story in a story refinement session (about this a bit below).

Why should we do requirement analysis?

The business analyst wrote the story - isn’t that enough? Well… People make mistakes. Also, no one on the team knows everything about the product. Working on a product means collaborating with various roles. Having well-analyzed requirements means:

Ok, but how is it different from just having a story refinement session?

You may already have a user story refinement or grooming session where a business analyst presents the work items to be developed to the team and asks for feedback. If the stories are not with well-analyzed requirements already, these meetings are a bit of a… waste of time.

Story refinement sessions are for the whole team. They are super useful if done right, yet they often have way too many people in a condensed amount of time, so respecting everyone’s time we should come prepared. This is why the prior refinement session thought-through requirement analysis with QA and a developer are so beneficial.

The worst refinement sessions I have seen did not even have user stories! It was just product documentation being presented. Most developers could not even comprehend what it means for them. If the user stories were shown instead - everyone can understand much better. In addition, if they’re already analyzed by a few people before - there likely be way fewer questions and comments, and the team will have deeper insights, not just pointing out the trivial gaps in the requirements. This again can save time for everyone and make us develop faster.

If most requirements have to be clear, isn’t that waterfall?

A common misconception about Agile ways of work is that it’s ad-hoc and has no planning. It does have planning, though! Things may change, too.

When I talk about requirement analysis, I talk about looking at a small work item like a user story. It’s already a small piece of work that is releasable, when we start working on it likely it will not take too much of time, so the requirements should be ready before picking it up - this just sets us for success. It’s a small piece of work, not the whole project plan.

How to do requirement analysis?

As a first step, I’d recommend starting with a small group of people checking out the requirements.

In many companies, this does not take place. It may sound foreign, yet let me share my experience and how it can be beneficial.

As a QA I work very closely with business analysts and often have been the first person the business analyst shared the user story to. Sometimes we also would pair writing acceptance criteria together.
Tip: you can even do this asynchronously. Just ask the business analyst to share the user story once they write it.

Now… the main part. Questions! It may depend on your context and domain knowledge, but these are the questions that are popping into my head when it comes to requirement analysis:

1. Is the acceptance criteria clear?
2. What could be misunderstood in the phrasing?
3. Is the story covering both positive and negative paths? Are there any paths that should be described still?
4. As a part of this user story, do you need to implement extra tests or monitoring?
5. Is this user story releasable and testable on its own?
This question addresses slicing, good slicing of a user story means that it can be released on its own, this is what we’re aiming for.
6. What are our success metrics?
7. Is it technically feasible? Are tech notes that should be added included?
8. Are there dependencies on other teams? If yes, what do we need from them?
9. Are the design mocks final (for now), clear, and attached to the user story?
10. Do we know the motivation for building this story? Is the main persona clear?

There are so many more questions that you can ask. Some more suggestions could be found in the article I wrote with my colleague Steve Upton: Asking questions to improve.

Discussing requirements can be challenging. Quality analysts may bring in a lot of edge cases and quality requirements. Developers may include a lot of tech work, too. It’s important to have respectful discussions evaluating the risks and trade-offs you’re willing to make.

For more on this, I recommend watching The Business Value of Quality by Finn Lorbeer and Nina Hillekum.

Once you think you’re done with requirement analysis, ask yourself: are we meeting our Definition of Ready? If yes, congratulations! You likely prepared a very good user story which will make development much smoother.

Storytime on the importance of requirement analysis

How did I learn of the importance of requirement analysis? Let me tell you a story. Pairing with business analysts was quite new to me. I’ve recently joined a team and was excited to try it out. I loved the idea of preventing defects, but how do you actually do it in practice?

Me and my business analyst sat down to go through the user story they wrote. This resulted in an hour (!!!) long discussion on one sentence. The acceptance criteria said “The user logs in…”. Sounds straightforward, no? Well, not if you do not have a working product at all, and the concept of a user is fluffy, or, how they are logging in.

You could use your google account, for example. You could login as an admin. You could also just have basic credentials to log in. What about logging in with the website’s account?

When the business analyst wrote it, it seemed obvious to them: “Of course you login with the website’s account!”

Even if we had a long discussion, we ended up leaving the way it was phrased. I felt that maybe I should not “nitpick” (the professional illness of QAs, no?).

In the end, the developers implemented a login with their set credentials. It was not clear, and also not technically feasible to do it otherwise. This is when I learned: if you have doubts about phrasing and feel the requirements could be misunderstood, tell them and better write more than less to avoid misunderstandings.

Examples of requirement analysis

Case 1

Imagine that the business analyst shares this user story with you:

The Initial User Story
The initial user story

Do you think this is a good user story? Why?

I don’t think it’s a good user story. There are way too many questions that pop into my head when I read this:

Example of questioning the initial user story
Example of questioning the initial user story

After this feedback, we can sit down with the business analyst and create a much better user story (you may find it familiar as we included it in the work items article where you can read more about different work item types):

Improved user story
Improved user story

This story still could be improved with more specifics. For example, “thorough monitoring” is not descriptive enough. We could specify what exactly metrics we’d like to track, or what dashboard we expect to see after implementation.

Case 2

Let’s look at another questioning example. Imagine you get this requirement:

When a new user is created, we want to store their information in a new user data storage.

What would you ask?

I’d ask this:

Example of questioning a requirement
Example of questioning a requirement

Requirement Analysis in a Nutshell

This is what the requirement analysis is in a nutshell:

Remember that you don’t need to have answers to the questions you ask. Likely someone else on the team can answer it. What you do is advocate for building a quality product, so all the points mentioned matter: testing, cross-functional requirements, or phrasing.

Summary

Requirement analysis done well saves us so much time and effort. In the short term, it may seem it adds more work to do: you need to collaborate, rephrase, raise all your concerns, and it can get uncomfortable. However, we will develop so much faster avoiding rework and misunderstandings.