Let’s image that I have a requirement from a user about logging. He wants to log and then display to manager every action made by a user in the system. And for specific actions e.g. opening a case he wants to log more detailed info (like name of the customer). If I want to interpret it in a graphical way using UML…
- can I use something like this:
(I think it is methodicaly wrong – e.g. the relation between use cases should be include or generalization – but I assume it is not right to have only one “include” of a use case. Plus I am missing “user” as an actor…)
- Do you think using UML Use case diagram is a good idea how to confirm understanding of a requirement with a client?
I do not want to exclude information about logging the subjects name even if its methodically wrong simply because it helps me to confirm with my client “yes, it is also covered as a part of logging… and btw don’t you want to log more? Are there any other special object like this… blah blah”.
Using graphical way of interpreting things suits me and its good basis for explaining things and discussions. My colleague is using Use case diagrams for this, but I am afraid that they are not intended for this and they can be sometimes confusing for the client (and all the more, the more “methodically correct” they are).
I am just thinking if it’s not better to just make a mind map which I use for discussion with a client and then I can make the use case – but only as a basis for me during the further analysis.
M_Ryan is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.