1

Let's take the example of logging in and add item as two use case of an items management system. the requirements of the client are : (he needs/wants to : )

  1. Gain legitimate access to the resources of the system;
  2. Add Item (create one).

we also know that no unauthenticated user should use the system !

My questions are :

1) Is "Gain Access" a use case ? A precondition to other use-cases ? Or Both ? (knowing that by naming the use-case "Gain Access" and not "Logging in" I wanted to highlight the need rather than the solution to that need.

2) if "Gain Access" is a use-case, does the "Add Item" use-case includes the "Gain Access" use-case ?

Of Use Case Dependencies :

Sequential Dependencies

  • A use case precondition reflects a sequential dependency between use cases.

  • Use case B with precondition C can only start after use case A has produced C as a post-condition. Use case B is executed after use case A; their connection is asynchronous.

Functional Dependencies

  • In contrast, an include relationship reflects a functional dependency between use cases.

  • When use case A has an include relationship to use case B, it means that the functionality of use case B is part of the overall functionality of use case A. Use case B is executed as part of use case A; their connection is synchronous.

https://www.batimes.com/articles/use-case-preconditions-a-best-kept-secret.html

ghassen lassoued
  • 59
  • 10

1 Answers1

4

A Use Case has to generate business value. Is "login" (or gain access etc.) delivering business value in and of itself? Would the user of the system login and then leave it at that? Probably not. Therefore login is not a Use Case itself. It could be documented as a step in a Use Case (if you know enough about the solution and are feeling inclined to say) but be careful not to specify technology solutions in Use Cases. You'd be better to specify that the User must be identified to a certain level of authentication and apply that as a pre-requisite etc.

Business value is the key. Recognising business value is part of the art and science of analysis. For example, the same would be true if you were not using Use Cases to model requirements -- e.g. a User Story of the form "As a (role) in need to (action) so that (business value)" is again business-value focused. Ultimately, business value is the focus of any functional requirement and clear identification of that should be one of the main indicators that your analysis is closing in on its target.

That in mind -- sequential and functional dependencies. Be careful not to decompose functionality of the system into units that don't reflect business value. The oft-quoted example of an ATM: Check Balance is a Use Case, Enter PIN isn't (for the reasons above). However, you might feasibly want to always Check Balance when performing Withdraw Cash. If this was the case, then you could use an include to show that Withdraw Cash includes Check Balance, but note that both Use Cases provide business value in and of themselves.

muszeo
  • 2,312
  • 9
  • 13