Spec By Example on the example of one requirement

Hello! I continue the topic of posts about the approach to collecting requirements called Spec By Example. I have already done a webinar about the general values ​​of this approach (about it below), but today I want to show how it works on the example of a fairly simple, first look at the requirements. The requirement itself sounds very simple:

The system should display the stock occupancy level by displaying the number of products of each type. When shipping / receiving goods value must be updated.

In principle, nothing complicated, but let's see what surprises are hidden inside!

Let's go in order, as the methodology suggests. And you should start with

Definitions

If there is no common understanding of terminology, then perhaps this is a sign that the parties concerned have not really agreed on other things? These can be business goals, business processes, or functions that are required by the system. A simple check of terminology can reveal serious flaws in the very understanding of a project.
')
Therefore, we must begin with the fact that we consider our vocabulary and where the definitions come from. These may be ordinary dictionaries, any books, corporate standards, and so on. Ask yourself, do you understand the meaning of nouns and verbs? Be sure to remember where you take this definition from. Notice whether it does not cause any contradictions with what you already know.
And most importantly, ask your customer to check with you that this is all true.

As for our case, it will be useful to know:

• what will be stored in general?
• Are there any special goods zones, for example, a refrigerator?
• how is the shipment / receiving process?

Features

When we talk about requirements, you need to think with features and visualize them, and not abstract UML in a vacuum. And visualization allows you to understand this much more clearly, because each process is displayed through its steps and each step becomes a feature. Due to this method Story Mapping and gives such a cool result.
So, when you read the requirements, pay attention to the following things, which are separate features:

• Named features - users and analysts may have already decided what functions they would like to see in the system. Examples include Order Entry, Search Screen, Status Report.
• Phrases like: “The system will be {verb} {object} '. Typical verbs: add, update, delete, process and so on. An object can be any entity or process in a system, for example, a customer, an order, a product, a person, invoices, and so on.

For our case, the following features are explicitly highlighted:

• shipment of goods from the warehouse
• taking goods to the warehouse
• registration of goods in stock

Results (Outcomes)

More than anything else, requirements must describe the results of the work. Results are what we want from the system. Usually in the text of the requirements, the results are easily distinguished by the following patterns:

• active manifestation - “system will be”
• passive manifestation - “the correct result of the work is ...” or “the wrong result of the work is ...”

Accordingly, the results of the work of the system can link to web pages where results, reports and so on are displayed. They can also relate to the behavior of the system, which we see as users through the interface or in the form of media output (video, for example).
Often the result, which is not clearly not visible, is observed by a message that informs the user about what happened. Accordingly, the result of the system can be "nothing." A typical example here is the system's response to attempts at hacking or selecting a password.
Coming back to our requirements. It would be useful for us to see:

• stock percentage
• information that the place ends

Scenarios (Scenarios)

We finally came to the scenarios (but this is not the end of our work), and now we can combine all that we dug out in the previous stages. In this case, we pay attention to the following things:

• there is no branch within the script
• all exceptions are a separate scenario
• the script begins with a description of the starting situation
• the script contains only specific parameter values

(By the way, all this makes the script a great test case).
For example,
Initially, the warehouse is empty and can store 100 bags of potatoes, when we add 1 bag of potatoes, we see that the percentage of the warehouse is 1%.
Go ahead.

Forecast (Prediction)

We start to check our scripts for logic. It is always clear how much we get exactly the result that is described in the script. If not, it most often means that one or another step is missed, or even not all conditions are described. This brings us back to the stage of visualization of the process as a whole.

Ambiguity

(My favorite stage) For this stage it is useful to present the scenarios in the form of a table, which then also finds its application.

Customer type	Cart contents	Delivery
VIP	1 book	Free
VIP	10 books	Free
VIP	11 books	Standard
Regular	10 books	Standard
VIP	5 washing machines	Standard
VIP	1 washing machine	5 books Standard

And we start after this to look at the following things:

• Whether there are cases when the data do not differ or differ slightly, and the result is radically different
• if the case when different data lead to the same result

At this stage, things like:

• different definitions of the same functional
• hidden steps
• ambiguous understanding of terminology
• and so on

Spaces (Missing)

In fact, this stage has slipped implicitly already several times, but it is worth mentioning it again. For example, also because after we received cool scripts, we forgot to update the glossaries, source documents, and so on.
At this stage it is also useful to see the table of scenarios, as it allows you to quickly navigate them and find spaces.

What's next?

Next we take the BDD framework and start writing code! I will tell you about this, or rather show how it is done in the nearest webinar. Follow the news!

By the way, here is the webinar about the general theory of the approach. Spec By Example