© 2008 Martin Langlands and Charles Edwards Page 1 of 5Business vs. System Use Cases – Part oneAuthor: Martin Langlands and Charles EdwardsVersion: 1.1 Date: 14 May 2008AbstractUse-cases are now all but universal as the basic concept for specifying requirements ofcommercial information systems. However, one area that causes problems is distinguishing between “Business” and “System” Use Cases. The aim of this three-part series of articles is to shed some light on this issue by highlighting the differences between the two,and proposing a diagrammatic way of showing how they are related. This is illustrated using a more detailed and meaningful example than is used by many introductory texts.IntroductionUse-cases are now all but universal as the basic concept for specifying requirements ofcommercial information systems. However, there is still a huge amount of confusion inhow best to apply the idea. One area that continues to cause particular difficulty is distinguishing so-called “Business” and “System” Use Cases.Why has this confusion arisen? Well, we need look no further than the man who gave theUse-Case idea to the world: Ivar Jacobson. In his 1994 book “The Object Advantage”[JACOBSON94], he introduces the concept of “The Use Case” as: “A use case is our construct for a business process.” (p104) So far, so good. But four lines later, he says: “A usecase is a sequence of transactions in a system …”. No wonder there’s confusion: doesthe concept apply to business processes or computerised systems?A good example of this confusion came up recently when a client asked: “We are generating a Business Use Case Model for a project. The Project is mainly to develop a systemwhich can enable users to be notified by WAP/SMS on their cell phone regarding theirpreferred stock prices, important Emails, news, weather etc. Now which element showsthe ‘Cell Phone’ usage in the diagram? A business actor, a business worker, a businessentity or a use case? Also, can Business entities be shown in Business use case diagrams?”.Now, when faced with such a question, we’re usually tempted to respond: “Read thestandard literature!”. Two of the most popular books on Use-Cases, by Cockburn [COCKBURN01] and Bittner & Spence [BITTNER03], have a lot of useful advice on exactly this.However, it is still surprisingly easy to absorb all that these and other authors have to say,and still be lost when actually starting to work on a real project. The aim of this paper is tohelp those stuck in this bind.We’ll come back to answer this client’s questions directly later in this series. But beforedoing so, we need to do a lot of preparatory work.Two ConceptsOK, so if there’s a possibility of confusion, how should we apply the terms Business UseCase and System Use-Case?Well, first, it’s helpful to note that there is commonality between the two concepts: bothdefine a pattern of repeatable interaction or behaviour that is intended to deliver a resultof value to the Actor.Business vs. System Use Cases – Part one© 2008 Martin Langlands and Charles Edwards Page 2 of 5However, it’s equally important to note there are clearly two useful but distinct conceptshere:Ɣ A Business Use-Case is to do with “using a business”: this recognises that businesses1 are created and organised in order to do things for people – mainly customers, but also other “actors”. So a Business Use-Case is a way in which a customer orsome other interested party can make use of the business to get the result they want– whether it’s to buy an item, to get a new driving licence, to pay an invoice, or whatever. An important point is that a single execution of a Business Use-Case shouldencompass all the activities necessary to do what the customer (or other actor)wants, and also to do any necessary internal tidying-up. (We’ll see a little later an example of what we mean by this last point.) So the duration of a BUC execution canvary greatly, depending on its nature. Some BUCs, like withdrawing cash from anATM, can be done in less than a minute; others, like ordering goods for delivery, orgetting a new phone line installed, can take days, weeks or even longer.Ɣ In contrast, a System Use-Case is a way in which a user of a computer system canmake use of the system to get the result they want. This will typically be somethingwe can readily imagine as being done in a single sitting on a single computer, usuallywith a single UI, or a small number of closely-related screens such as a wizard, andtaking maybe between a couple of minutes and a half-hour at most. Alistair Cockburnsuggests that a useful guideline is the “coffee-break test”: once the user has completed (a single execution of) the System Use-Case, s/he can take a coffee-breakwith a clear conscience. The system use case also avoids all manual issues such as“file the printout” or “phone the customer once the order is confirmed”, etc.A Realistic ExampleLet’s look at an example that allows us to focus on the differences. This example is a littlemore complex than many that are presented at the introductory level, but therein lies theroot of much of the problem: examples used in many books and articles just have insufficient complexity to illustrate the kinds of thing that come up in real life, and often are toosimple to allow us to see the differences between Business and System Use-Cases.So let’s take SupaStores, an imaginary grocery chain that allows customers to place orders on its website, www.supastores.com, and have the orders delivered to the customer’s home. We’ll look at an example Business Use-Case (BUC) and some SystemUse-Cases (SUCs) to highlight the key differences. We’ve assumed a basic familiaritywith UML modelling concepts.The Business Use-CaseWhat Business Use-Cases might be of interest for SupaStores? Let’s focus on the mostobvious:Ɣ Buy groceries, from the customer accessing SupaStores to completion and recording of delivery for that customer.A first-cut Use-Case diagram forthis BUC would look very simple(Fig 1). This shows the principalactor – the Customer – and oneUse-Case. The result of value tothe customer would be the correctGrocery delivery.We also need to show one sup-1Calling these “businesses” can itself be (unintentionally) misleading. A large part of the economies of all countries isconducted by organisations other than commercial businesses – local and central government agencies, charities andother non-profit organisations, etc. Their activities equally fall into this area. Strictly, we should be saying something like“Businesses and other organisations”, or maybe just “Organisations”; but we’ll stick with convention.Business vs. System Use Cases – Part one© 2008 Martin Langlands and Charles Edwards Page 3 of 5porting actor, the Bank, because it is a distinct business entity required to complete thejob: specifically, it needs to approve the customer’s bank-card transaction. Note that wedon’t show on this diagram the “internal actors” in the SupaStores business that performthe use case – neither the employees such as warehouse and delivery staff, nor any systems (computerised or otherwise) involved – because they are “inside” the Use-Case.This Business Use Case Diagram describes “Black Box” behaviour; that is, it shows onlythe business interaction, not the internals of how a Use Case is implemented by SupaStores.One of the most important things to understand about any given BUC is its scope – whattriggers it, and what marks its completion. In this case, the event that starts this BUC isthe customer accessing the SupaStores website to place an order. The event that completes the BUC is recording the details, such as the time and date, of the successful delivery. Note that the duration of this BUC could be from around a day to a week or more.In order to see how BUCs and SUCs differ, and also how they relate to one another, we’llhave to open up this BUC and take a look inside.The first problem we meet is: UML, the modelling language that defines the Use-Caseconcept, says nothing about what the inside of a Business Use-Case (or any Use-Case,for that matter) should look like! However, a sensible approach – and one that is veryuseful, as we’ll see – is to look at the sequence of steps, or activities, that constitute theBUC. Figure 2 illustrates this diagrammatically.We’ve drawn this more-or-less as a UML Activity Diagram, with a very simple drawingpalette:Ɣ rounded rectangles for activities (aka steps)Ɣ simple arrows showing activity sequenceƔ a bullet for the trigger start event, and a bullseye for the end eventƔ swim-lanes representing which roles or organisational units are doing what activity –the Customer and the Bank, as actors external to the organisation, get their ownswimlanes, as does each internal organisational unit involved.Business vs. System Use Cases – Part one© 2008 Martin Langlands and Charles Edwards Page 4 of 5As mentioned, this is a non-trivial example, but one that we hope is readily understandable without having specialised domain knowledge. We’ve deliberately kept this as simpleas possible, without getting into the complexities of different modelling approaches or notations such as Business Process Modelling Notation [BPMN]. Also not shown are the different possible alternate flows or terminations – eg. the BUC could terminate immediatelyafter the first “Place Order” activity if the customer decides to cancel, of if the card payment fails; in “Deliver Order” the driver could be unable to find the address, or the customer could be out; and so on. Showing these would result in a considerably enriched,but more complex, diagramNow, although the diagram sets out the basic steps and their sequence, we can clarifyour understanding further with a textual description. Figure 3 shows the Use-Case description based on Cockburn’s widely-used template.Name : BUY GROCERIES Business Use-caseBrief Description : In this Use-Case, a Customer places a new order for delivery. SupaStores assembles the order, delivers it to the customer, and records the result of thedeliveryPrincipal Actor : CustomerPrecondition : Customer must reside in the country of the business to qualify for delivery.Main Flow StepNameDescriptionPlaceOrderThe Customer contacts SupaStores; selects the required quantities ofproducts from the product catalogue; selects a delivery slot from thoseavailable; offers payment by an approved method; advises deliveryaddress; and confirms all order details.AuthorisePaymentThe Bank confirms that the offered payment is valid, and authorisesthe payment.PickGoodsFor all confirmed orders for a forthcoming delivery run, the SupaStoreswarehouse finds the order items on the shelves; assembles the orders,noting any out-of-stock items or substitutions; packs them for delivery;and prints a Delivery Sheet for each order.LoadTruckFor a particular delivery run, the SupaStores Shipping department determines the planned delivery route, and loads the packed orders (accompanied by their Delivery Sheets) into the assigned truck in the correct order for the route.DeliverGoodsA SupaStores Delivery driver makes a delivery run, following theplanned route; for each order on the run, the driver finds and confirmsthe delivery address, and delivers the order to the recipientConfirmReceiptFor each delivered order, the Customer confirms that the delivered order corresponds to the items on the Delivery Sheet (including any unavailable and substituted items), indicates the delivery time and orderacceptance, and notes any comments.RecordDeliveryResultAfter the completion of a delivery run, the delivery driver returns theDelivery Sheets to SupaStores Shipping department, who record thedetails of each order, including the time of delivery, and any notesmade by the customer. Figure 3 : Text Description of Business Use-Case“Buy Groceries”Business vs. System Use Cases – Part one© 2008 Martin Langlands and Charles Edwards Page 5 of 5This deliberately shows only what Cockburn calls the Main Success Scenario or MainFlow for this Use-Case – ie. it still omits any alternative or exception flows such as thoseleading to the different terminations considered above.The textual description introduces some important subtleties that are not indicated on theactivity diagram, such as the handling of out-of-stock items and substitutions. It also illustrates – in the step Record Delivery Result – an example of the point made earlier about“tidying-up” at the end of the BUC: although the customer has received the goods in thepenultimate step, and the BUC is therefore complete as far as s/he is concerned, wecan’t regard it as finished from SupaStores’ viewpoint until the final step is done.Note that this is, in Cockburn’s terminology, a “white-box” view of the BUC; we’ve gonebeyond describing only the dialogue between the actors, to look behind the scenes andsee how the BUC is implemented within the business. In this view, we’ve given a swimlane in the diagram to each Actor, and also to each internal SupaStores organisation unitinvolved.A black-box view, showing only the interaction across the interface between the primaryactor (the customer) and SupaStores, would be limited to the steps “Place Order”, “Deliver Goods” and “Confirm Receipt”, and on the diagram would need swimlanes (if wechose to show them) only for the Customer and SupaStores.The intention at this stage is to show the activities that constitute the BUC – what getsdone – without (yet) asking how they are done, in particular what computerised systemsdo or could support each activity.Next timeIn Part Two we will show the System Use Case equivalents for this example and highlightthe key differences between the two types of Use Case. In part three we will look furtherat a Process Use Case Support Diagram and make observations and conclusions.References [BITTNER03]Kurt Bittner & Ian Spence, “Use case Modelling”, 2003, Addison-Wesley,ISBN 0-201-70913-9 [COCKBURN01] Alistair Cockburn, “Writing Effective Use Cases”, 2001, Addison-Wesley,ISBN 0-201-70225-8[JACOBSON94] Ivar Jacobson et al, “The Object Advantage”, 1994, Addison-Wesley,ISBN 0-201-42289-1[BPMN] Object Management Group – see http://www.omg.org/bpmn/Contact details[email protected][email protected]www.ProcessWave.com and www.AgileEA.com
