Use cases must be designed in cooperation with future users of the software or database.  Designers will have a theoretical view to some extent, while users have more practical demands.  Theoretical matters are not an end in themselves, so aim for practical solutions.

When designing use cases, start by deciding on the level of detail to be adopted. Endless detail takes endless time and is never complete anyway.  Brief summaries are never enough to make requirements clear.  You may wish to have more than one category of use case spanning different levels of detail.  I would recommend that the most common tasks should be specified in the most detail while still being as simple as possible.  Ambiguity is bad.
At the same time, use cases should avoid making assumptions that constrain flexibility in implementation.  For example, don’t specify a use case in such specific detail that improvements in presentation or method are not possible.  Be careful: decide what requires fine detail and what should be more of a broad-brush specification.
When selecting what use cases are necessary, ask the following questions:
  1. How much detail must be provided and in what areas?  How much freedom can be allowed for innovation during design or implementation?  How formal is the presentation?  How complete is the description?
  2. Can use cases be refined as development progresses?
  3. How can we measure and reward efficiency?
  4. Are there any essential operations for which we do not have use cases?
  5. Are there any common operations for which we do not have use cases?
Ask the following questions for each use case:
  1. Is this a common operation?  The most common operations must be most highly optimised.
  2. How important is this operation?  The most important operations must be most carefully verified.
  3. Are there other use cases very similar to this one that can be specified in the same use case through minor changes or by referring to another use case for most of the detail?
Make sure that the level of detail given in each use case satisfies your goals. As in the story of Goldilocks and the three bears, you want “Not too much, not too little, but j-u-u-ust right”. For example, make sure that use cases are not specified in such a way as to preclude special cases that are less common but still necessary, although those can be less well optimised if they are less frequently done.