Home/ Questions/Q 679551
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-14T01:16:20+00:00

I am writing a Product requirements specification. In this document I must describe the

  • 0

I am writing a Product requirements specification. In this document I must describe the ways that the user can interact with the system in a very high level. Several of these operations are “Create-Read-Update-Delete” on some objects.

The question is, when writing use cases for these operations, what is the right way to do so? Can I write only one Use Case called “Manage Object x” and then have these operations as included Use Cases? Or do I have to create one use case per operation, per object? The problem I see with the last approach is that I would be writing quite a few pages that I feel do not really contribute to the understanding of the problem.

What is the best practice?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The original concept for use cases was that they, like actors, and class definitions, and — frankly everything — enjoy inheritance, as well as <<uses>> and <<extends>> relationships.

    A Use Case superclass (“CRUD”) makes sense. A lot of use cases are trivial extensions to “CRUD” with an entity type plugged into the use case.

    A few use cases will be interesting extensions to “CRUD” with variant processing scenarios for — maybe — a fancy search as part of Retrieve, or a multi-step process for Create or Update, or a complex confirmation for Delete.

    Feel free to use inheritance to simplify and normalize your use cases. If you use a UML tool, you’ll notice that Use Cases have an “inheritance” arrow available to them.

    • 0