2

I am writing a functional specification for a project and I wish to express the expected system behaviour in Use Cases.

I have read a bunch of opposing opinions on whether "logging in" should be considered a Use Case or not and my conclusion is that there is no consensus, and that it also depends on the context.

My question is this: assuming that authentication is not a standalone Use Case, how should I describe the authentication requirements and interactions if the functional requirements of the system in question are otherwise expressed in Use Cases?

I assume that in this case a login flow should be an integral part of each and every Use Case. That seems like a lot of repetition, so to avoid that I could extract the login part of the flows to some "Common Flow" and reference that in my Use Cases. Is this a valid approach?

Regardless, the approach seems a little awkward to me (just a subjective opinion). Things would seem more natural if being logged in was a precondition to other Use Cases. How/where should I describe the authentication flows in this case?

Improve this question
3
  • Regardless of whether you call it a use case it better be stand alone because I don’t want to see username and password on every freaking use case. I would tolerate replacing “user” with “authenticated user”. – candied_orange Jan 13 at 20:53
  • you def need a usecase or whatever for "how to login" the rest just start "as a logged in user" – Ewan Jan 13 at 21:26
  • Agree with both of you, but I am looking for a formal approach from the proponents of the "login is never a use case" camp. If I am writing a functional spec or a software requirements spec, and I wish to describe the system in Use Cases, where do I (literally) put the description of the login flows. – Avius Jan 13 at 22:29
5

I'm not aware of any good argument for "logging in" to be considered a use case. Looking at Alistair Cockburn's Writing Effective Use Cases, this is the definition of a use case:

A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system's behavior under various conditions as the system responds to a request from one of its stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal.

The very last sentence is key. I'm not aware of any system where the goal is to "log in". Logging in may be necessary to authenticate and/or authorize the individual to perform an action. Logging in may also add some kind of benefit, such as the ability to store configurations or customizations. However, I can't think of a system where a person would log in and be done.

If you are using use cases to capture the requirements of a system, I would recommend capturing the need to log in and be appropriately authenticated as a precondition for any use case that requires such authentication. You can then use the use case format to capture what it means to log in. This includes defining the success guarantee, minimal guarantees, interested stakeholders, the main success scenario, extension scenarios for any kind of errors or alternate flows.

In Writing Effective Use Cases, Cockburn talks about levels of use cases. One of the levels is called "subfunctions" and subfunction-level goals are "required to carry out user goals". Expressing these in a use case format can be useful for communication. By giving them an appropriate name and description, they can be included by reference in the use cases for the system. Instead of specifying the information by copy/paste as a precondition, referring to logging in as a precondition or a step in the scenario or extension can save space and ensure consistency.

If it's helpful, you can tie UML models, such as activity and sequence diagrams, to your use cases. This isn't necessary, however.

Improve this answer
2
  • Looks like subfunctions is what I was looking for. Just a minor (hopefully) clarification - is there any difference between the template/format of a subfunction and a use case? Or can I reason about it in the same way that I'd reason about a use case, except that, well, they're not the same (the big difference, I assume, is in the goal)? – Avius Jan 13 at 23:57
  • 1
    @Avius In the examples, the same format was used for the different levels. There are different templates/formats for use cases, but I'd expect that the same template/format would be used for all of the levels. The only difference between the levels is the level of abstraction. In fact, "log in" is specifically called out as a subfunction goal. – Thomas Owens♦ Jan 14 at 0:21
0

Use-cases

Different viewpoints ont this question are rleated to the understanding of what a use-case should be:

  • UML is agnostic and defines a use-case in very broad scope as:

    A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.

    According to this definition, any interaction between a use and a system could be modelled as a use-case, including a login.

  • Use-case inventor Ivar Jacobson, and a number of authors define use-case with a view of value for the user and user goals. For example:

    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.

    According to this definition, a login is never a use-case, because the login has no value for the user. It's just a constraint required to achieve the true goals of the user.

I'd strongly recommend the second approach, as Jacobson, but also Bittner & Spence, Alisair Cockburn, or Larry Cosntantine. It leads to a high-level design that provides the big-picture of the system and with a real focus on what the user needs. The login is in this universe left as detail for the use-case description that documents further each use-case.

Loggin in

If the use-case say what the system shall offer, there are other means to describe how it shall work in details.

First, behind each use-case you'd have a use-case description. This can take the form of a narrative, of a detailed sequence of interaction steps (that was long the traditional way), or of an intent oriented description of the details (i.e. there's not sequence of actions, but a more detailed description of what a user may intend to do and how the system answers or the contrary - this is called "essential use-case" in the litterature). In such a description you could refer to login as a specific use-case step. Alternatively, you could refer to the logging in in very general terms as a constraint to be autentified.

Another way, is to describe how a use-case works with the help of an activity diagram. Activity diagrams document the flow of control and of objects. The loggin in would be an action in such a diagram.

Improve this answer
5
  • Thanks for the answer, but it is not quite what I asked for as I believe I am familiar with both positions, at least to an extent. What I would like to know is how/where to describe authentication flows/requirements if I can't dedicate a separate Use Case for that, particularly given the complexity, implications and overall importance of authentication. – Avius Jan 13 at 22:24
  • @Avius login makes usually sense with an order: e.g. 1) login, 2) register xxx 3) confirm xxx. But in UC, there is nothing about order. If you have 3 use-cases, UML doesn't allow you to specify an order between them (unless you start to add a lot of constraints to enforce an order, but that's not very readable). If you're interested in order of operations and flow, you'd consider activity diagrams. These are meant exactly for that. I made an edit to detail further. – Christophe Jan 13 at 22:44
  • Hmm, don't feel I've been able to make my problem clear just yet. So first of all, I agree - login could be a step in a specific Use Case. However, I see two problems there. First, every Use Case would start with a LOGIN step, which seems redundant. Secondly, I wish to provide additional requirements to the login step. I would have to add the same details of the LOGIN flow to every Use Case. That does not make sense - see also the two comments on the question. So the big question is - where do I put these more granular requirements in my Use Case document. I am not drawing any UML diagrams. – Avius Jan 13 at 23:03
  • Personally, I’d just document that the need for a login as a pre-condition for the use-case, since the user will probably not perform a use case for each occurence of a use-case if it is executed multiple times in a row. Then use-cases are not a tool meant to describe the user interface. It’s not my statement but Jacobsn, Booch and Rumbaugh’s, the founders of UML, in their book about the unified process. Finally the argument about redundancy can be used elsewhere as well. If you’d go for login use-cases, why wouldn’t you go for error message display use-cases, or date-picker use-cases ? – Christophe Jan 14 at 0:26
  • @Avius You’d then be overwhelmed by details which are not relevant for the user, and models that will be time-consuming to maintain. While use-cases aim to facilitate reuse, reuse alone is not sufficient to make a use-case. Note that I give you here arguments, but in the end, it’s your design and your choice: if you feel such use-case would greatly help you, go for it (and provide some feedback about your experience once your project is completed) – Christophe Jan 14 at 0:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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