1

Please help me understand why, in this diagram, "Validate User" is considered a use case.

My understanding is that to qualify as one, a use case must:

  1. Be initiated by an actor;
  2. Represent the actor's goal;
  3. Deliver discernible value to the actor.

The use cases "Withdraw Cash", "Transfer Funds", and "Deposit Funds" all meet these criteria.

The actor might say to herself: "I need to withdraw a bit of cash for tomorrow's taxi ride to the airport.". The value delivered in this case is that the actor now has cash.

It is highly unlikely that the actor would say: "I need to go validate myself as a user at an ATM.". That would be a ridiculous goal with no discernible value.

On top of that, "Validate User" is something that is initiated by the system in response to the actor's actions. So this diagram appears to use the same vocabulary (use case) and shape (ellipse) to represent two different things -- user goals and system goals. I find this very confusing. At the very least the ellipses that represent system goals could use a different shape, like a rectangle, for example.

Could anybody please clarify this point for me? I have a hard time defining what should and what shouldn't be part of a use case diagram. I feel like in the provided example the concerns of the system bleed into the concerns of the user and there is not a clear enough distinction. And in the end the diagram is more confusing than helpful.

Edit 1: What makes things even more confusing is that the phrasing "Validate User" uses the same verb-noun form as the other use cases. For example: "As an actor I want to withdraw cash" makes perfect sense. "As an actor I want to validate user", on the other hand, makes no sense whatsoever.

Source of diagram

Example use case diagram

3 Answers 3

2

It depends on the intent of the use case diagram.

If the use case diagram is meant to serve as a visual index to use cases detailed in a tabular format later on, then a notation like this could indicate that there is a common set of steps known as "Validate User" that is documented with goals, stakeholders, pre-conditions, steps, alternative flows or extensions, and post-conditions. Especially notice that no actor is connected directly to this particular use case but it's only related to other use cases through the include relationship.

However, in most cases, I'd agree that "Validate User" isn't a good use case and shouldn't be expressed on a use case diagram. It adds far more visual clutter than value, although I tend to find that use case diagrams in general are more clutter than value.

0

It may be worth looking at it from a pragmatic point-of-view, rather than a strict definition of what a Use Case should be.

Each use case in the diagram should have some text describing what the scenario is. Each of the three use cases "run" by the Bank Customer will require the customer to validate themselves. You could cut-and-paste the same validation wording into every use case. But that's messy and is a maintenance nightmare if the validation process ever changes.

So instead pull the validation into a separate use case bubble, with it's own text description. Then include that use case into all the others.

Use Case diagrams often end up with this problem. You have common behaviour that many use cases share, and you don't want to keep pasting the same description into every scenario.

0
0

I've found a way to satisfactorily explain to myself the inclusion of this use case on the diagram, albeit with some modifications. Please feel free to disagree.

If the actor's goal is to withdraw cash and withdrawing cash requires authentication, then it doesn't seem too out of place to indicate on the diagram this additional step. It would explicitly show that the use case of withdrawing cash implies another interaction with the system where the actor will have to provide valid login credentials in order to be able to successfully achieve the original goal of obtaining cash.

Framed in this way, the use case satisfies the three guidelines I mentioned in my question:

  1. It is initiated by the actor, although indirectly;
  2. It is part of the actor's goal, strictly by necessity, otherwise the goal simply cannot be accomplished;
  3. It delivers value in the form of being able to obtain cash, along with coincidental value in the form of security, ability to access the account remotely, etc.

My remaining problem with the diagram is in the wording. "Validate User" sounds like we are describing a use case from the point of view of the system, i.e. it is the system that has to validate the user. But the actor doesn't care about the needs of the system. I think renaming the ellipse to "Provide Login Credentials" or "Authenticate Self" would help maintain the point of view of the actor throughout the analysis/design.

Edit 1: But this still feels like a slippery slope. If authentication is required to accomplish the original goal, then, technically, so is inserting a card and so is tapping on the ATM screen. These actions are also required, otherwise the goal cannot be accomplished. And so it is still unclear just where we draw the line between what should and what should not appear on the diagram.

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.