I know this question has been asked many times in different forms, but I feel that there is still no definitive answer to it. Some say login is not a valid use case because login does not have any business value, yet others say login is, just like any thing that is part of users expectations, a valid use case. Can we give a definitive answer to this question?
-
Wording of question needs improvement in grammar to improve clarity. – Martin Spamer May 10 '18 at 22:42
-
True. Its better now. – ghassen lassoued May 10 '18 at 23:24
-
"some say" and "others say" - do you have links for either side of this discussion? – HorusKol May 10 '18 at 23:53
-
https://www.quora.com/Is-login-sign-up-a-valid-use-case – ghassen lassoued May 10 '18 at 23:59
-
Quora : wisdom of the crowds. – ghassen lassoued May 11 '18 at 01:15
-
“*Some say login is not a valid use case because login does not have any business value*”. Firstly, it’s a **use case**, not a business case. Secondly, security is something that the business has to take seriously. So I’d argue it most certainly is a business case too. – David Arno May 11 '18 at 07:29
-
When designing a case diagram you have an actor that is a role which implies authenticated. All subsequent actions are an extension of the validity to the use cases provided by the actor. – StackOverFowl May 17 '18 at 02:48
-
Use cases are meant to represent user goals and how the system helps actors to achieve their goal. In this regard, a login is not a goal of a user, but only a constraint for securely using the system. See also: https://stackoverflow.com/questions/35651397/include-login-in-uml-use-case – Christophe Oct 17 '21 at 10:25
2 Answers
First, you need to specifically define what a "use case" is. At the most basic level, a use case is a set of system behaviors that products a result for one or more actors. However, some definitions for a use case add the need for value or achieving an objective.
Although logging in (authentication) is a set of system behaviors that produces a result for an actor, it doesn't often meet the second definition of achieving an objective. That is, rarely does a person log in to a system and then do nothing else. In most cases, the person authenticates into a system as a step in a larger process.
As long as your use case meets the first definition, you can represent the use case on a UML Use Case diagram or in various textual/tabular templates. However, depending on the complexity of your system, you may opt to treat the value-adding or goal-oriented use cases differently than use cases that are only included as parts of other use cases.
The specific representation of any use case depends on how you are capturing or documenting your use cases. Depending on the system and level of documentation, it may not be interesting enough to have any sufficient discussion in design documentation. Or it may have lots of nuances and be discussed in great detail in both requirements and design documentation.

- 79,623
- 18
- 192
- 283
-
2"As an Unauthenticated User, I want to Log In so that I can carry out actions which require Security Permissions." – Robert Harvey May 11 '18 at 00:16
-
I understand your point but this interaction between the actor and the system has no business value. And a use case must have a business value, otherwise its a technical detail . Am I wrong ? – ghassen lassoued May 11 '18 at 00:19
-
2@RobertHarvey That's a user story. In use case format, I would expect that the login use case would require a registration use case and other use cases that need an authenticated user would include the log in use case. – Thomas Owens May 11 '18 at 00:20
-
-
3@ghassenlassoued: Securing your corporate assets has no business value? – Robert Harvey May 11 '18 at 00:20
-
1@ghassenlassoued Isn't the ability to identify the user of a system valuable? Regardless of what you are building, there is value in being able to authenticate a user and record their action. Authorization also requires some type of authentication, so if you want to protect aspects of your system from use, you need to authenticate first. – Thomas Owens May 11 '18 at 00:21
-
I think you are right ! so if I am modeling my system on a level that does not only care about commercial value, but all the possbile business values (commercial, market, efficiency, customer, security, future, etc) then I should consider "logging in" as a use case that has a "security value" which is after all a "business value" . – ghassen lassoued May 11 '18 at 00:54
-
2A business that only cares about so-called "commercial" value will quickly go out of business. – Robert Harvey May 11 '18 at 00:56
-
2that's right, I just want to add this : Authentication is **security matter** and security is not only cost; it is a **strategic investment** in reduction of corporate **risk**, and a positive **contribution** to the realization of **business value**. – ghassen lassoued May 11 '18 at 01:08
-
This answer is way too definite and in general ignoring what a use case is. Use case is not every single interaction between actor and the system or every single possible "click" in the system would have its own use case. On the contrary UC should define a business functionality of the system and in most cases mere log in doesn't fall into that category. I'll try posting an answer countering this one, but I'll have time for that in next few hours only. – Ister May 11 '18 at 04:19
-
I'will be waiting to see how login has no business value . I have searched the web about the business value of security and found some . So if login is considered as a security matter then it should has a business value – ghassen lassoued May 11 '18 at 10:02
-
Good answer but if you add the actor “time” you are not using an actor that logs in but instead how “time” will boot you from the system: example session timeout. – StackOverFowl May 17 '18 at 02:51
-
-
@ThomasOwens We can take this off line but before you do - read this https://stackoverflow.com/questions/855361/is-time-an-actor-in-a-use-case – StackOverFowl May 17 '18 at 13:22
-
@Programmer There are several answers in that question that support the statement that time is not an actor. The UML specification states that an actor "specifies a role played by a user or any other system that interacts with the subject" (UML 2.5.1, section 18.2.1.1). Time is not a role that is played by a user or a system, therefore it should not be represented on a use case diagram. – Thomas Owens May 17 '18 at 13:35
-
-
@Programmer The [specification page is here](https://www.omg.org/spec/UML/2.5.1/). Also, the [direct link to the PDF specification is here - the PDF is about 20MB](https://www.omg.org/spec/UML/2.5.1/PDF). The definition is in section 18.2.11, which is on page 647 of the PDF. – Thomas Owens May 17 '18 at 14:45
-
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/77626/discussion-between-programmer-and-thomas-owens). – StackOverFowl May 17 '18 at 14:53
In short
Use-cases mean different things to different persons. For the Use-Case community it's user goals. For UML, a use case is a behavior with user interactions and observable results of value for someone. From a goal-oriented perspective a login is not a use-case.
More explanation
Login
is not viewed in the use-case community as a use-case, because it's not a user goal:
A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.
- Ivar Jacobson, inventor of use-cases
Of course, Login
has significant business value, since it contributes to the security of information processing. But for a user it's more a constraint than a goal:
When I login to StackOverflow, Twitter or Instagram, I do not see the login as my goal. My goal is answer questions, read and write tweets, or interact with others. The login is just a constraint, and I'm happy when some other secured means let me skip that step.
- Anonymous
Moreover, the login gets more and more hidden. Users are grateful for every login screen that is replaced with an SSO in the background. So the authentication constraint being achieved by other means, what's the sense of emphasising a Login
use-case when it's no longer involving actors and it no longer even gets observable to the user when it succeeds?
For sure, there is a place for a login or an authentication in an UML model. While use case diagrams is not fundamentally wrong (UML definition is purely behavioral), a detailed activity diagram seems a better place.
Additional readings:
- Answer about Login use cases on StackOverflow
- Answer about Login use cases and functional decomposition on StackOverflow
- UML definition: "a UseCase (...) specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject."
- Use-Cases 2.0 by Ivar Jacobson

- 74,672
- 10
- 115
- 187