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...

  1. can I use something like this:

manager > Display all logged actions made by a user > actions with cases > Log more detailed info which is subject name

(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...)

  1. 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.

  • Should second bubble use "display" wording instead of log? Manager has no interest in an implementation detail which is logging - they just want to spy on people.
    – Basilevs
    Commented May 23 at 8:51
  • @Basilevs You're right, sry for the typo :/
    – M_Ryan
    Commented May 23 at 9:13

1 Answer 1


Use case diagrams don't have much value for any purpose.

I'd point out some words from Martin Fowler:

Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value - the key value of use cases lies in the text which is not standardized in UML. So when you do use cases put your energy into the text.

When capturing use cases in a suitable format for talking about them, I'd recommend one of the tabular formats. There's an entire book dedicated to creating and documenting use cases.

However, I'm not sure that use cases are what you're looking for in this specific example. In this case, you're interested in talking about what gets logged. There are other visual and tabular models for capturing requirements. A data dictionary or report table could better organize the information captured and displayed in this logging and auditing feature. Early in the process, something less structured, like a mind map, could be helpful for requirements elicitation. Still, I suspect it would be less valuable as the work progresses through more detailed design, implementation, and verification activities.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.