In Search of All Possible Scenarios

A comprehensive approach to requirements development

Whether a product owner/business analyst develops requirements, a developer implements them, a QA engineer tests them, or a technical writer describes the functionality — we all want detailed and clear descriptions of the expected results.

In this article, I will suggest an approach to work with a requirement to consider all possible scenarios for the feature. We will start with a practical use case and then generalize the method into an algorithm with some useful tips.

Use Case

Imagine you are working on a mobile game. In a new version of the game, we are adding a temporary 14-day event in which Users, distributed by groups of 100, compete with each other in real time (so an internet connection is required).

The competition implies completing game levels and gaining points for them. After 14 days, the top three Users who gained the most points in each group see a reward popup with their medals, and the remaining 97 Users get a reassuring popup message: “Good luck next time.”

There is a requirement that Users see either the reward popup or the popup message only if they open the application within two days (48 hours) after the event is finished. If they open the app 48+ hours after the end of the tournament, we think they don’t remember they participated in the event, and the scenario goes like this:

• if the User took a prize-winning place (1–3), the medal is “silently” added to the collection of the User’s rewards and is available in a separate section of the app’s interface (no popups are shown to the User)
• if the User didn’t take one of the first three places, no popups are shown to the User, and no rewards are added to the collection

The key functionality of this event is processing the case when a User loses the internet connection (offline mode). They can’t see other Users’ progress in the leaderboard, yet they can still complete levels and get points (because the application allows playing in the offline mode). In the application, we want to have a setting trackTournamentProgressWhenOffline with the following possible values:

• 0 — we do not track User’s progress without the internet
• 1 — we track User’s progress without the internet

We want to provide our developers and QA engineers with in-depth requirements on the Offline feature so they have a clear picture of what should happen and when. To do so, we have to consider three factors affecting the logic of the functionality:

• when the connection was lost
• when the connection was restored
• the value of the trackTournamentProgressWhenOffline parameter

How can we describe all possible scenarios for the case of the lost connection and be sure that we’ve indeed covered them all?

A Suggested Approach

1. Let’s figure out the full list of parameters that affect our functionality and, for each parameter, define its possible values:

You may ask why we include the two cases when the internet is lost AFTER the tournament (TIME_LOST = 2 and 3). It’s because, in our case, the internet is lost, and the User hasn’t seen the event's results. So, technically, we are still in the scope of the developed functionality.

2. Let’s calculate the total number of all possible scenarios. According to the multiplication principle in combinatorics, the total number of all possible scenarios is equal to the multiplication of the number of possible values of every parameter:

• TIME_LOST has four possible values
• TIME_RESTORED has four possible values
• trackTournamentProgressWhenOffline has two possible values

So, there are 4 * 4 * 2 = 32 options of possible combinations of the parameters’ values. In other words, we need to cover 32 scenarios for the feature. But how to figure out the exact scenarios?

3. Let’s create an empty table of 32 rows and four columns as follows:

In the first column, we will describe each scenario with words. Columns 2–4 will reflect, for each scenario, the value of the parameters TIME_LOST, TIME_RESTORED, and trackTournamentProgressWhenOffline correspondingly.

And now to the most interesting part — how to fill in the table?

4. In the last column (trackTournamentProgressWhenOffline), we are going to alternate possible values of the parameter trackTournamentProgressWhenOffline (0 and 1):

In the column TIME_RESTORED, we will alternate all possible values of the corresponding parameter (0, 1, 2, 3) so that each possible value of TIME_RESTORED covers one whole range of possible values of the column trackTournamentProgressWhenOffline (one whole range is one set of 0 and 1), and looks like the following:

Finally, in the column TIME_LOST, we will alternate all possible values of the corresponding parameter (0, 1, 2, 3) so that each possible value of TIME_LOST covers one whole range of possible values of the column TIME_RESTORED (one whole range is one set of 0, 1, 2, 3):

5. Now that we have a table with all 32 possible scenarios, we must provide a word description and the expected result for each.

To do so, let’s add a column to the table:

To describe a scenario, we convert the numerical value of each parameter in the corresponding row with its meaning and combine them. For example:

The fourth scenario has the following:

• TIME_LOST = 0
• TIME_RESTORED = 1
• trackTournamentProgressWhenOffline = 1

The description is

"The User had lost the internet before the event started.
The connection was restored after the start and before the end of the event.
We track the User's progress when they play offline."

An expected result can be the following:

"Until the connection is restored, the User sees no UI of the event in the app.
Once the connection is restored, the User starts participating in the event. 
He is allocated to a group of Users and starts gaining points. 
The points he has gained offline DO NOT count because the User got them 
not knowing they were participating in the event."

Some scenarios are going to be logically impossible. For instance:

The 25th scenario has:

• TIME_LOST = 3 — the connection was lost 48+ hours after the end of the event
• TIME_RESTORED = 0 — the connection was restored before the start of the event
• trackTournamentProgressWhenOffline = 1

It’s an impossible situation, so we can mark the row as:

Generalization of the Approach

A general algorithm to use:

1. Figure out all the parameters that affect a feature or functionality you’re describing and all possible values for every parameter.

If the number of parameters exceeds 10, consider decomposing your feature into independent parts (if possible). Then, apply the algorithm to each part.

Put the parameters in such an order that a parameter with the smallest number of possible values goes last, and a parameter with the biggest number of possible values goes first.

You can put numbers 0, 1, 2, … to each possible value within one parameter, making it easier to operate with the values later.

2. Calculate the total number of all possible scenarios by multiplying the number of possible values of all the parameters you’ve established in step 1.

3. Create an empty table with n+1 columns and TOTAL rows. The first column is for a description of the scenarios. The following columns are for each N parameter.

4. Fill in the table with the parameters’ values according to the following schema:

• in the column for the parameter P(n), alternate all possible values of the parameter P(n)
• in the column for the parameter P(n-1), alternate all possible values of the parameter P(n-1) so that each possible value of P(n-1) covers one whole range of possible values of the column P(n) (one whole range is one set of all possible values of P(n))
• in the column for the parameter P(n-2), alternate all possible values of the parameter P(n-2) so that each possible value of P(n-2) covers one whole range of possible values of the column P(n-1) (one whole range is one set of all possible values of P(n-1))
• in the column for the parameter P(1), alternate all possible values of the parameter P(1) so that each possible value of P(1) covers one whole range of possible values of the column P(2) (one whole range is one set of all possible values of P(2))

5. Add the last column, Expected Results, to the table, and fill in the table's first and last columns (Scenario Description and Expected Results).

Mark impossible scenarios (where values of the parameters are logically incompatible) by highlighting them in red.