So why should you write use cases anyhow? Why are they any better than other ways of specifying requirements?

There are many reasons, but two are key: First, use cases guide us toward the more important requirements and second, use cases are more easily understood.

Traditional ways of gathering requirements involve answering the question of what:

What does this system need to do?

While this seems like a reasonable question,  the answer is a typically a long list of shalls lacking much context. For example:

• The system shall route emergency vehicles with high priority.
• The system shall have the capability to perform remote data protection.
• The system shall log all security events.

Lists like these are accurate, but deceptively problematic. Once the list has more than a dozen-or-so items, it becomes difficult to think about how the items relate. On its own, the list gives us little clue as to when the requirements apply. This makes it harder to figure out how these requirements should be designed and tested. Since the list doesn't indicate who each requirement is written for, it's not obvious if we missed any.

Use cases, on the other hand, involve answering the questions of who, why, and how:

• Who needs to use this system?
• Why do they need to use it?
• How will they use it?

The use case-approach is unique in that it is driven by who will use the system. By starting with who will use the system (the actors) and why they will use it (their goals) we're led to towards requirements that are important to the the people who will actually use the system. We can look at the list of goals we've identified for an actor and readily see if we missed any.

Unlike requirements, use cases are not lists. They are stories. A single use case tells the story of how an actor will use the system to achieve one of their goals. And a collection of short stories are easier to understand than a long list of shalls.