How do you write effective use case descriptions and scenarios for different levels of abstraction?

2 How to write a use case description?

A use case description is a textual document that provides details on a use case. It typically contains a unique and descriptive name and number that identifies the use case, a brief summary of its purpose and scope, a list of actors involved in the use case, a precondition that must be true before the use case can start, a postcondition that must be true after the use case is completed, a step-by-step description of the normal or happy path scenario of the use case from the actor's perspective, possible variations or exceptions to the main flow with their triggers and outcomes, and any additional or non-functional requirements such as performance, security, or usability.

4 How to choose the level of abstraction?

The level of abstraction refers to how detailed or general a use case is. Depending on the purpose and audience of the use case diagram, you may choose to use different levels of abstraction. For example, you may use a high-level use case diagram to show the business processes and goals of a system, or a low-level use case diagram to show the system functions and features. The level of abstraction also affects how you write the use case descriptions and scenarios. For example, a high-level use case description may focus on the business rules and value propositions, while a low-level use case description may focus on the system inputs and outputs.

5 How to use include and extend relationships?

Include and extend relationships are two ways of showing the dependencies or relationships between use cases. They can help you avoid duplication and simplify your use case diagram. An include relationship means that one use case always includes or invokes another use case as part of its flow. For example, a use case called "Make payment" may include a use case called "Verify credit card". An extend relationship means that one use case optionally extends or adds functionality to another use case under certain conditions. For example, a use case called "Print receipt" may extend a use case called "Make payment" if the actor requests a receipt.

6 How to use generalization and specialization?

Generalization and specialization are two ways of showing the inheritance or variation between use cases or actors. They can help you capture the commonalities and differences among different scenarios or roles. A generalization relationship means that one use case or actor is a general or abstract form of another use case or actor. For example, a use case called "Manage account" may be a generalization of two use cases called "Create account" and "Update account". A specialization relationship means that one use case or actor is a specific or concrete form of another use case or actor. For example, an actor called "Customer" may be a specialization of an actor called "User".

7 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?