# Use case naming conventions
See also the ODA Component and Canvas working page
https://projects.tmforum.org/wiki/display/TAC/ODA+++Behaviour+Driven+Design%28BDD%29+Feature+Guidelines

Here are key guidelines for naming use cases:

1. **Be Descriptive and Specific**: The name should clearly describe the functionality or the goal of the use case. For instance, "Process Order" is more descriptive than just "Order."

2. **(Actor) Verb Noun**: The default name should be *(Actor) Verb Noun*. For example, "Customer Process Order" or "Send Notification". The Actor is optional.

3. **Use Active Verbs**: Use Active Verbs to indicate the action performed. For example, "Calculate Tax" or "Validate User Login."

4. **Avoid Technical Jargon**: Use language that is understandable to all stakeholders, including non-technical ones. Prefer "Send Notification" over "Initiate SMTP Session."

5. **Keep It Concise**: While being descriptive, also keep the name short and to the point. Avoid overly long and complex names.

6. **Reflect User Goals, Not System Functions**: Focus on what the user wants to achieve, like "Book Flight" instead of "Flight Database Update."

7. **Be Consistent**: Use a consistent naming convention throughout the project. If you start with verbs, continue doing so for all use case names.

8. **Avoid Ambiguity**: The name should be distinct and not easily confused with other use cases. Ensure each use case has a unique name.

9. **Use Business Terminology**: Where possible, use terms familiar within the business domain or industry. For example, in a retail application, use "Checkout Cart" instead of "Complete Purchase."

10. **Avoid Implementation Details**: The name should not imply how the use case is implemented technically. Focus on the 'what', not the 'how'.

11. **Regular Review and Update**: Be open to renaming use cases as the understanding of the system evolves during development.