I guess no one would argue for decomposing use cases, that is just wrong. However sometimes it is necessary to specify use cases, which are on lower, more technical level, like for example authetication and authorization, which give the actor value, but are further from his business needs. Cockburn argues for levels when needed and explains how to move use cases from/to different levels and how to determine the right level. On the other hand, e.g. Bittner argues against use case levels, although he uses subflows, requires the vision documents which contain information about the purpose of the system in the business, much like use cases on the higher level, and at the end of his book mentions, that at least two levels are needed most of the time. My questionis, do you find use case levels necessary, helpful or unwanted? What are the reasons? Am I misssing some important arguments?

1 Answer 1


I recommend against levels. The use cases are most useful when they describe what the user wants to accomplish, not the technical details of how to they do things. Making the use cases specific to methods will constrain your choices on how to implement solutions. In your example, the use case should be "check the balance of his account", not "the user can log on with SSL".

That said, make the exception when your requirements contract does have highly specific technical constraints. If your client demands SSL, make the SSL use case.

  • I know technical details, UI, business rules, law etc. are details abstracted from in use cases. For example imagine set of use cases for a system requiring authetication and authorization. You may start with "...his...", but than you will need preconditions which will be repeated everywhere, so you do include and voila, new use case, which is important to the actor, but less than others, e.g. it is on the lower level. Commented Feb 18, 2011 at 4:28
  • I consider authentication and authorisation to be the sort of technical details that are normally not interesting to build use cases. Authentication and authorisation are not things the user wants to do, but a technical detail in the way of the user's final goal.
    – smithco
    Commented Feb 18, 2011 at 4:32
  • e.g. with ATMs people want to perform transaction on their accounts and they want to prevent anyone else from doing that, the technical details on how you do it are unimportant, but the fact that user needs and authentication and authorisation is imho obvious. Commented Feb 18, 2011 at 23:19
  • When a person uses an ATM, the uses cases would be to withdraw money, cash a cheque, check an account balance &c, the security is a technical detail of how to achieve the aforementioned goals. That's not to say security is unimportant to the user, but it is not what the user wants to get done.
    – smithco
    Commented Feb 19, 2011 at 5:33

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.