UML Diagrams says:

A use case is a kind of behaviored classifier that specifies a [complete] unit of [useful] functionality performed by [one or more] subjects to which the use case applies in collaboration with one or more actors, and which [for complete use cases] yields an observable result that is of some value to those actors [or other stakeholders] of each subject.

But it is not clear for me in specific small situation. For example in a mobile application I have a list and user can do

  • ''item click'' for
    1. selecting item
    2. deselecting item
  • ''long item click'' for
    changing selection mode (''multiple'' or ''single'')

Now, are usecases ''selecting item'', ''deselecting item'' and ''changing selection mode'' or they are ''item click'' and ''item ling click''?

I think ''item click'' and ''item long click'' are not UC because

  1. Although ''item click'' and ''item long click'' are behaviors of list; but I did not create the application to provide a way for user to do ''click'' and ''long click'' (those are not useful independently)
  2. ''item click'' does not provide unit complete useful functionality (can lead to different useful behaviors with observable output: ''selecting/deselecting item'')

Am I right? I'm in doubt.

2 Answers 2


Nothing you mentioned belongs in a Use-Case. You are describing 'how'; the Use-Case should just talk about 'what'. 'How' the 'What' is accomplished is a matter for design/implementaton, not use-cases.

I have no idea 'what' the goal of your clicking/selecting is but to be more concrete, if selecting/deselecting were done to select who you want to invite to a party....The use-case would be "Invite People To Party".

You'd then describe the scenario as something like:

The operator selects people to invite to party. The operator invites the selected people to the party.

That's it. It may not seem like much, mainly because it is such a simple example but the amount of information that can be generated/gleamed from those 2 simple statements is quite dramatic. For example, you know you'll need an 'Operator' module. That'll likely be your GUI. You also know you'll need 'People' and 'Party/Event' modules. You know you'll need the 'System' to perform an 'Invite' operation.

From that, you'll realize you need Use-Cases to 'Add People', 'Add Events' and 'Add Operators'.

I could keep going if I looked more in depth about the modules...but the key takeaway is that the Use-Case is not supposed to be the design. Don't try to fit the square block in the round hole. Absolutely do not describe the GUI, leave that up to the GUI designer(s). To clarify that a little bit; From this one Use-Case the GUI designers know they'll need to come up with some way for the operator to select people to invite to the party and some way to tell the system to 'Invite' the selected people. How that is accomplished is up to them. It isn't up to the Use-Case creators to tell them how to do it; just tell them what they need to do. Theoretically, the GUI designers are supposed to be the experts on GUI design, not the Use-Case creators; so don't tell the GUI designers how to do their job.

Use-Cases are great for learning and defining 'what' the system should do. They are great for helping to get a start on the system architecture by identifying the necessary modules. They turn into a nightmare if you try to get them to help do the design. Every design change, every code change means changing the use-cases. IOW, a lot of unnecessary work.

  • I think you generally confirm what I copied and added as answer. Although you think I have to use words add people instead of selecting item which its purpose is not clear. Also you emphasize on keeping diagram clear. Do I think right? Commented Jan 17, 2019 at 4:20
  • I agree that 'Add People' is vague without adding a description, which is why Use-Cases also have a description field that goes with the name. Your 'Select Item' is with regards to selecting items for the current operation. My intention for 'Add People' was as a separate use-case in itself. It is to provide a means to add specific people so they end up showing up in that 'selectable item' list. Diagrams should show what you are trying to communicate. That tends to always mean 'clear'. I'm not sure what you mean by that question.
    – Dunk
    Commented Jan 17, 2019 at 14:49

I asked this question in Stackoverflow and this was an useful answer. I added that here:

Yes. The clicks are different behaviors (like different key strokes) you perform to achieve the goal of/trigger the underlying use case (select item etc.). Clicking something might be a use case if you are after some finger training. But you are probably dealing with some business goal to achieve.

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.