Use case naming conventions

See also the ODA Component and Canvas working page https://projects.tmforum.org/wiki/display/TAC/ODA+++Behaviour+Driven+Design(BDD)+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.