Specifications by Examples

One of the analyst's key skills is to verify that 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 understands 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 scenario than a complex abstract concept.

Each non-trivial statement should be followed by an example.

The same principle is beneficial in written specifications too. Each description of a complex problem should be complemented with a concrete example so readers do not doubt 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. An 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 discipline 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, 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 a problem when exposed just to abstractions. Therefore, unlike abstract requirements, specification by example illustrates better exactly how the system will behave, as it is more natural for the people who specify them.

Requirement: "When the user confirms a money transfer from the bank account, the system transfers the money and updates the 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 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 determines whether the fee is charged or not. Therefore, we need to create three tests: where the transferred amount is $30, greater than $30, and lower than $30. The convenient way to present these tests is by using a decision table, as shown below:

Scenario: <User> wants to transfer money from the bank account
    Given Account balance is <OriginalBalance>
    When user confirms to transfer <TransferAmount>
    Then the application transfers <TransferAmount> to the selected account
    And user's account balance is <NewBalance>

    Examples:
      | OriginalBalance | TransferAmount | NewBalance |
      | 100             | 45             | 54         |
      | 100             | 30             | 70         |
      | 100             | 20             | 80         |