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.
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:
Credit goes to the respective owner!