Specifications by Examples
One of the analyst's key skills is to verify he or she was correctly understood. When discussing complex issues, it may not be easy for attendees to follow the analyst's thoughts and ideas all the time, and they sometimes "switch off". Or they may pretend to understand because they are too shy to confess they got lost. There are a couple of techniques to verify the audience understand what has been said, such as asking verification questions or letting them paraphrase the message using their own words. Another great tool is to provide an example, as it is usually easier to imagine a concrete example than a complex abstract concept.
Each non-trivial statement should be followed by an example.
The same principle is beneficial in the written specifications too. Each description of a complex problem should be complemented with a concrete example to not make the readers doubt about the meaning. The example will not only help them understand the issue faster but also enables them to verify they have understood it correctly.
Similarly, it might be the analysts who struggle to understand the topic. They should not feel ashamed in these situations as it could be the stakeholder who cannot understandably formulate the thought. Don't hesitate to ask for clarification, and even better, ask for an example. Analyst's second most frequent statement after "Thank you!" should be "Can you give me an example, please?"
From Example To Requirements and Tests
Over time, the benefits of verifying information using examples have become so obvious that a whole disciplined based on using examples emerged. It is called Behavior-driven development. The main principle behind it is using concrete examples to formalize a shared understanding of the desired behavior. It is mostly used to specify how the application should behave. However, it could be equally well used to specify high-level abstract requirements that are not yet related to any application. And since every example is effectively also a test, the BDD is a way to specify both requirements and tests.
It is so effective because of the way humans think. Human brains are generally better at deriving abstractions or concepts if given enough concrete examples, in contrast to understanding the problem when exposed just to the abstractions. Therefore, unlike abstract requirements, specification by example illustrates better how exactly the system will behave as it is more natural for people who specify them.
Requirement: "When the user confirms money transfer from the bank account, the system transfers the money and updates user's account balance."
Business rule: "When the transferred amount exceeds $30, a $1 fee is charged"
Test:
" Scenario: User wants to transfer money from the bank account "Given" Account balance is $100 "When" the user confirms to transfer $45 "Then" the application transfers $45 to the selected account And user's account balance is $54 (100-45-1) "
Such an example/test helps stakeholders imagine better exactly how the system will behave under specific conditions and allows them to verify the requirements and the corresponding business rules. Of course, since the test is just one specific instance of the requirement, it is usually needed to write more than one test for each requirement, and the special attention should be paid to "border cases".
In the previous example, the border case is when the transferred amount is $30, as this amount sets whether the fee is charged or not. Therefore, we need to create three tests: the transferred amount is $30, greater than $30, and lower than $30. The convenient way to present these tests are using a decision table, as shown below:
`"
Scenario:
Examples:
| OriginalBalance | TransferAmount | NewBalance |
| 100 | 45 | 54 |
| 100 | 30 | 70 |
| 100 | 20 | 80 |