Home > Work > Business and System Use Cases – what’s the difference?

Business and System Use Cases – what’s the difference?

On my last project, the team was confused at first by the difference between Business and System Use Cases, and their purpose.

This issue appears in an article Vague and Ambiguous use cases by Matt Stephens in The Register, where he gives two examples of use cases covering the same subject. The first example, which he knocks as too vague to be any use, is actually a Business Use Case, whereas the second one is a more detailed System Use Case developed from it. Oddly he doesn’t use either term. This reflects the problem – people don’t understand the difference!

The most succinct definition I have found is Alistair Cockburn’s (in Writing Effective Use Cases), in the reminders section rather than the main part of the book.

A Business Use Case is one in which the design scope is business operations. It is about an actor outside the organisation achieving a goal with respect to the organisation. The business use case often contains no mention of technology, since it is concerned with how the business operates.

A System Use Case is one in which the design scope is the computer system to be designed. It is about an actor achieving a goal with the computer system; it is about technology. (Reminder 13, p216)

In fact Cockburn tends not to use the term Business Use Case, sometime preferring ‘enterprise use case’. The difference between the two is scope; for a Business Use Case it is the enterprise, whereas for a System Use Case it is a computer system.

By ‘enterprise’ we may also mean a department, especially in a large organisation. So for as well as the obviously external actors like Customers, we can also consider other departments such as Finance as being outside the organisation in question.

Business Use Cases form part of the user requirements specification, and define the scope of User Acceptance Testing. It should theoretically be possible to implement Business Use Cases with a paper-based system. It should also be possible to draw out a Business Process Model containing the same information (often a Business Use Case might cover one or more of the activities in the model) but to do both is probably overkill.

System Use Cases should focus on the part of the process to be implemented by the system in question. They should normally be written at a level of detail equivalent to a detailed functional specification. In fact some of our later use cases were detailed enough for developers to work from directly, and were able to serve as technical documentation in their own right.

It may be worth defining a set of high level System Use Cases to help identify the process flow, and then decompose them into a set of more detailed ones reflecting system design. In my current project we currently have nearly 200 use cases; without the higher level we wouldn’t be able to see the wood for the trees.

Our client’s standard was to model business processes using BPMN, rendering Business Use Cases superfluous, but they defined “Business” Use Cases for the part of the business process to be implemented – confusingly – by the system. So in fact at our cllient the “Business Use Cases” were actually (very) high level System Use Cases, even if they don’t call them that. So it’s not surprising that people become confused, as confusion is common.

Some questions

Do we need both? Possibly, but it’s not essential to define System Use Cases if Business Use Cases exist, nor should the absence of Business Use Cases prevent designers from writing System Use Cases.

Should coverage be comprehensive? If Business Use Cases are used, they should define the full scope of the system, at least at the highest level. There are almost certainly parts of the system, however, where System Use Cases add little value, e.g. around reporting, and needn’t be modelled.

Should both sets of use cases join up? Trying to get a fully comprehensive match between both use case models is futile, as the different perspectives of each set will provide instances where System Use Cases cut across multiple Business Use Cases, or vice versa. However, all System Use Cases should trace back to a requirement in one or more Business Use Cases

Above all, don’t worry too much about the distinction, just remember that they may be written at different levels and for different purposes. Just keep scope in mind, and you will find your level.

Categories: Work Tags: ,
  1. Lucia Dupard
    February 1, 2012 at 3:33 pm

    I found this article right on time. The clarity in the explanation will greatly help me understand the new enterprise direction that adds value to the business side without jeopardizing the added value in IT brought by wirting the system use cases.

  2. August 1, 2012 at 5:39 pm

    Thank you for the wonderful post.

    When you say Business Use Case as typically interaction of external actor with the enterprise. If I consider that true than what about the internal actors? Won’t we miss the use case belonging to them? I believe to come about Business Use cases, we need to consider all the actors whether internal or external. For example if there is an online retailer having a business process “ORDER FULLFILLMENT”. This process will involve a couple of business uses cases including: a) Customer Ordering Product b) Warehouse Packing the Order c) Logistics delivering the Order

    If above, only customer is external actor while warehouse and logistics are internal actors. So, ignoring internal actor will result in missing out some business use cases. YOUR COMMENTS ARE INVITED ON THIS.

    So summarizing things, can we conclude following flow of any enterprise-wide IT product:

    1) You determine Business Processes
    2) You derive Business Use Cases from the Business Processes determined
    3) You elaborate Business Use Case to come about steps involved
    4) Elaborating business use cases give you set of steps/ task that may or may not be automated
    5) The set of steps/ tasks that may be automated may be converted in to System Use cases and hence taken further for implementation in the system.

    Looking forward to your comments.


    • August 23, 2012 at 8:39 pm


      Thank you for finding this post useful and sorry I have taken a while to reply.

      I would expect that normally Business Use Cases between them would fully encapsulate all System Use Cases. What would the point be of a System Use Case that served no ultimate business purpose? In your example Warehouse Packing the Order is a necessary response to Customer Ordering Product and so at the highest level I see it as one of the steps in a high level business use case such as ‘Sell Merchandise’.

      Cockburn does say that ‘the organisation’ in the context of a Business Use Case might be a department so external actors may be from other departments – like HR or Finance in a manufacturing company, for example.

      I agree with your summary of steps.

      • August 24, 2012 at 3:56 pm

        Thank you for your response. I would like to ask one more question: “How do you differentiate between Business Processes and Business Use Cases?”

        A few articles that I have read over last few days take both as the same. Moreover, if we take Business Process = Business Use case then the issue of unexplored internal actors/ activities that I pointed out earlier will be addressed because while exploring business process, we will come to identify all internal activities/ steps involved.

        Once the processes are explored and modelling is completed, we may then proceed further to determine System Use Case. However, identifying System Use Case from Business Processes will require decomposition of business processes into significant level of detail.

        For a project we am currently working on, we have started with Major business processes and decomposed those into a good no. of sub-processes. Now, I intend to explore those sub-processes with the stakeholders in order to determine user’s functional requirements and system use case.

        Looking forward to your comments.

  3. August 31, 2012 at 9:27 pm

    I have come at this from a technical angle so i wouldn’t claim to be an expert by my view is that whether you have Business Processes or Business Use Cases depends on your methodology. With UML you would have Use Cases, with BPMN (and probably others) Business Processes. I think they are roughly equivalent and to have both is overkill, but a recent large project I worked on had both – and duplicated a lot of effort.

  4. October 22, 2012 at 9:18 pm

    Thanks for such an elaborate post. It makes many things clear and at the same time raises some questions in my head ( I am an analyst). I understand the high level use cases Mr. cockburn refers to. but I am not sure what is the need of business use case when we have business process model. Business process model definitely encompass all the advantage but does not have limitation of business use cases ( interaction among activities or intruppts to over all process). So why would i document a use case ( in textual form) when i can actually have business process model in visual form.

    Only thing that comes to my mind is could be the difference that business use case should document the whole process in scope of implementation. There could be other steps in the business process model that are manual or at a program level not in domain of one technology. NEED comments on this………….Another thing I noted in the BUC is that it does not necessarily be one actor involved where as SUCs need to be system and actor communication.

    If somebody can comment on above and remove my unclarity , it would be great.

    Thanks for a great post….

  5. January 20, 2013 at 5:58 am

    AA: There is NO NEED to bring up the distinction of “business” and “system” Use Cases. Alistaire Cockburn, who has written an excellent book on Use Cases, perhaps did not foresee the multiple confusing interpretations that readers make. His use of the term “design scope”, IMO is NOT appropriate. It should be “scope of the System under Development (SuD)”

    BB1: The use of the terms “business or enterprise” at times to mean the entire organization and sometimes to mean only a department is highly confusing.

    BB2: If he had used a term like “business unit” and define what it is for a given discussion there would have been no confusion.

    CC1: Now, the SuD can be a “business unit” or “a computer system” (here again it could be a combination of hardware and software or only software (this is what a BA or RE normally deals with).

    CC2: If the SuD is a business unit then the UC is business UC and if the SuD is system, then the UC is System UC. So, there is NO NEED to classify UCs as long as the SuD is properly defined and maintained consistently throughout the discussion / documentation.

    CC3: With this interpretation many of the examples and conclusions given above can be uniformly resolved.

    DD1: Regarding Use Cases and Business Processes, there is “a distinction” but it is NOT well defined in OOAD or UML. If both were the same, there would have been NO NEED to evolve the concept of UC and UC Modeling which is NOT Process Modeling.

    DD2: Use Case is a DIALOG but NOT a PROCESS. I am writing a proposal on “Redefining UC as SERVICE DIALOG”. I would be glad to share with those who may be interested.


  6. Cyril
    March 24, 2013 at 7:07 pm

    Excellent article. Synthetic clear and targets a crucial point of misunderstanding. Thanks Pjhobday.

  1. March 21, 2014 at 11:50 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: