Level of detail of use cases
I'm starting to use use cases to document object-oriented system requirements and I'm a little unsure about the level of detail of a use case. Basically, I have doubts regarding " What should be in Scenario ". I will give two examples of this: the first of them is CRUD.
It is common to find system requirements such as" register/read/edit/delete products", or similarly for customers. In any case, the requirement is basically "make CRUD of such entity". I really doubt how detailed a use case of these. I have two possibilities: simply write a "keep products" use case 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 it has and everything else. In the case of CRUD which of these is the most used approach normally?
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 better explain this I will take an example of a system that I am developing now (to control a restaurant). Basically, the owner of the restaurant at the beginning of each office needs to go into the program and create a new session, that is, "initialize restaurant activities" within the system.
This use case is not something from CRUD, it is really an operation that an actor (the manager) is interested in doing on the system. But I could only think of a Step: "manager initializes new session" and this seems to be much simpler than it should be.
I don't know if I could explain very well with the example the type of situation I'm talking about. These 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 gave this example, the question is generally the same, the example is just to have something concrete to facilitate the question.
I once read about it and there was a lot of talk about understanding who's going to read it, whether it's the Q & A team, or another team, etc. Since I work alone, I would like to know how to deal with it in cases like mine where it doesn't have that level of formality and the use cases are written more to document and organize the requirements.
2 answers
Do not make CRUD use cases
Imagine the following scenario:
Can the customer perform the Remove Order use case since they never created an order? No, you can't. Nor can you query, change, or update an order.
Use Cases should represent the core needs of the system. In the figure above a scenario was created thinking about features, and this should be avoided because the purpose of the use cases is to give context to the design, it should describe the functional requirements, that is, it should describe the system from the user's perspective. In other words, the use case diagram should provide a summary graphical view of the operation of the system.
The main intention of the user in the diagram above is to create Request . All remaining elements will become alternative streams in the main use case specification.
Another problem generated in the diagram above is that the decomposition functional, which is the act of dismembering a use case into smaller goals, generating a larger amount of use cases that have increasingly specific goals. This strategy goes against the real purpose of the system, which should describe the functional part of the system in macro objectives, and by breaking them down, we have several isolated actions that do not represent the real functionalities of the system.
Naming use cases
Forget The Name "keep products", you are registering products, you do not keep the products, no one accesses the system to keep a product. The term "keeps" in this context is completely vague and does not pass the user's real intention.
"initialize new session", this sim is a completely misguided supposed use case, it is actually just a step in a flow of some use case. That is, in no way is it a use case. Use cases are functional requirements of your system.
Think about the use case as something atomic, 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 client talking:
I need a system to power [supposed use case]
For the example above, it would look like:
I need a system to be able "Initialize a new session"
Nobody buys a system to be able to "boot a new session". Would your system exist if your only use case was to "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 certain document of your project.
If the flow "Initialize new session" is used numerous times by other use cases you can create a inclusion use case 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 unnecessary repetition of texts and enabling easy maintenance of the use cases that include it.
Naming actors
Do not confuse paper with positions or even people.
You said You created a manager actor to register the products, can only the manager register? Can never another employee play the role of registering products? Consider giving your actor a name that represents what role he is taking on when running the use case. How about maintainer?
Usefulness of use cases
There are 14 types of diagrams that belong to the UML language, 7 structural and 7 behavioral, that is, they are more diagrams than we usually even know of existence, each diagram has a specific and well-defined purpose, and the applicability of each varies from project to project, from occasion to occasion. The use case diagram is no exception.
As you said you work alone I would say that one situation where the use case diagram can be important is when using the ICONIX development methodology. "Can" be important because obviously everything it depends on the size and importance of your project.
Detailing your use case
Each use case diagram must be accompanied by a document that is called a specification, that document that will have a much more detailed analysis. An example of topics that a specification addresses:
- use case name
1.1 Brief Description- event stream
2.1 Basic Flow
2.2 Alternative Flows- Special Requirements
- preconditions
- post-conditions
- extension points
- scenarios
7.1 success scenarios
7.2 failure scenarios
As for the nomenclature " keep..."for use cases, you use it when you're going to represent a set of operations (CRUD). For, creating a use case for each operation could leave your diagram polluted (hard to read). It is a pattern followed in the representation of use cases. There is no problem with using the name "Keep". The operation of the use case is explained in its documentation.