Level of detailing use cases

Question

I’m starting to use use use cases to document object-oriented system requirements and I’m having a little doubt about the level of detail of a use case. Basically, I have doubts about "which should be included in the scenario". Let me give you two examples of this: the first is CRUD.

It is common to find system requirements such as "register/read/edit/delete products", or analogously for customers. Anyway, the requirement is basically to "make CRUD of such an entity". I really wonder how much detail a use case of these. I have two possibilities: simply write a use case "Keep Products" with scenario containing a single step "Keep Product Data", for example.

Or I can make a use case for each of the operations, containing all the details, like what fields you have and everything. In the case of CRUD which of these is the most commonly used approach?

There are still other points of the systems that I do not always know very well what really needs to be detailed in a use case. To explain this better I’ll take an example of a system I’m developing now (to control a restaurant). Basically, the restaurant owner at the beginning of each working day needs to go into the program and create a new session, ie "initialize the restaurant activities" within the system.

This use case is not something of CRUD, it is really an operation that an actor (the manager) is interested in doing in the system. But I could only think about one step: "Manager initializes new session" and this seems to be much simpleton.

I do not know if I could explain very well with the example the type of situation I am talking about. They are situations where it seems that the only step really is what the title of the use case itself says and in these cases it becomes difficult to know what really detail

How much do I need to detail in cases like this? Although I have given this example, the question is in general the same, the example is only to have something concrete to facilitate the question.

I once read about it and talked a lot about understanding who will read it, whether it’s the question-and-answer team, or another team, etc. As I work alone, I would like to know how to deal with it in cases like mine, in which there is no such level of formality and use cases are written more to document and organize the requirements.

Answer 1

Do not make CRUD use cases

Imagine the following scenario:

Can the Customer handle the Remove Order use case when he has never created an order? No, he cannot. Nor can you consult, change or update an order.

Use Cases must represent the main needs of the system. In the figure above a scenario was created thinking about functionalities, and this should be avoided because the purpose of use cases is to give context to the project, it should describe the functional requirements, that is, it should describe the system from the perspective of the user. In other words, the Use Cases diagram should provide a summary graphical view of the system operation.

The main intention of the user in the above diagram is Place Order. All remaining elements will become alternative flows in the main use case specification.

Another problem generated in the diagram above is that functional decomposition, which is the act of dismembering a use case into smaller objectives, generating a greater number of use cases that have increasingly specific objectives. This strategy goes against the actual purpose of the system, which should describe the functional part of the system in macro objectives, and when dismembering them, we have several isolated actions that do not represent the actual functionalities of the system.

Naming the use cases

Forget the name "Maintain products", you’re registering products, you don’t maintain products, no one accesses the system to maintain a product. The term "keeps" in this context is completely vague and does not pass the actual intention of the user.

"Initialize new session, "this is a completely misguided supposed use case, it’s actually just a step in the flow of some use case. That is, in no way is it a use case. Use cases are functional requirements of your system.

Think of the use case as something atomic, which you run from start to finish with a well-defined purpose, as something that aims to solve a problem that was the reason why the customer decided to buy your system. As a tip, if you want to identify if the use case has a full flow or not always imagine the customer talking:

I need a system for power [supposed use case]

For the above example, it would be:

I need a system to be able to "Start a new session"

Nobody buys a system to be able to "Start a new session". Would your system exist if your only use case was "Initialize a new session"? No. So it should not be part of your diagram. Your system places an order, closes an account, registers a customer, receives raw materials, etc.. the most banal things are just details that will be specified in some particular document of your project.

If the "Start New Session" stream is used numerous times by other use cases you can create a Use Case of Inclusion for it, which represents a use case without a full flow and consequently will never interact with an Actor, it can only be included by other use cases for reuse, thus avoiding the unnecessary repetition of texts and enabling easy maintenance of use cases that include it.

Naming the actors

Don’t confuse paper with posts or even people.

You said you created an Actor manager to register the products, will only the manager can register? Will no other employee ever be able to register products? Consider giving your Actor a name that represents what role he is taking on when executing the Use Case. How about Maintainer?

Usefulness of use cases

There are 14 types of diagrams that belong to the language UML, 7 structural and 7 behavioral, that is, they are more diagrams than we usually know the existence, each diagram has a specific purpose and well defined, and the applicability of each varies from project to project, from occasion to occasion. Use Case Diagram is no exception.

As you said you work alone I would say that a situation where the Use Case Diagram can be important is when using the ICONIX development methodology. "It can" be important because obviously it all depends on the size and importance of your project.

Detailing Your Use Case

Each Use Case Diagram must be accompanied by a document called specification, this document that will have a much more detailed analysis. An example of topics that a specification addresses:

1. Name of the Use Case
   1.1 Brief Description
2. Flow of Events
   2.1 Basic flow rate
   2.2 Alternative Flows
3. Special Requirements
4. Preconditions
5. Post-conditions
6. Extension Points
7. Scenarios
   7.1 Scenarios of Success
   7.2 Scenarios of Failure

Answer 2

As for the nomenclature "Keep..." for use cases, you use when it will represent a set of operations (CRUD). For, creating a use case for each operation could leave your diagram polluted (difficult to read). It is a pattern followed in representing use cases. There is no problem with using the name "Keep". The operation of the use case is explained in its documentation.