© 2008 Martin Langlands and Charles Edwards Page 1 of 6Business vs System Use Cases – Part twoAuthor: Martin Langlands and Charles EdwardsVersion: 1.0 Date: 06 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 article seriesis to shed some light on this issue by highlighting the differences between the two, andproposing a diagrammatic way of showing how they are related. This is illustrated using amore detailed and meaningful example than is used many introductory texts.Previously in part oneIn Part One we started to discuss the difference between the terms Business and SystemUse Case, and showed our worked Business Use Case example.The System Use-CasesOK, now we’ve seen what a Business Use-Case looks like, let’s take a look at the relevant System Use-Cases. This will allow us to see clearly the differences between theconcepts, and how they are related.First, let’s make the (perhaps obvious) observation that we are certainly not going to haveone SUC corresponding to this BUC. The scope and nature of one execution of the BUCis not something that we can conceive of being done in a single sitting in front of a computer. The customer may perceive it as being so, but the groceries won’t arrive the moment they finish placing the order!Secondly, in order to illustrate the SUCs here, we’re going to have to be a bit moreimaginative than with the BUC above. At a guess, Figures 2 and (in part one of this series) would just about work for any home-delivery grocery anywhere in the world. However, the SUCs will depend on what systems SupaStores uses, and their functionality. Solet’s assume that they have a not-untypical mix of reasonably up-to-date systems, combined with some older legacy applications, and with some level of integration betweenthem. These will be discussed as we go.Finally before looking at the SUCs themselves, note that in doing this we are now movingfrom the what gets done, to how it’s done, in terms of the specific system support foreach step. From our (invented) knowledge of Supa-Stores’ systems, we can go throughthe business use case and identify the various system use cases that deliver this support.The first step – “Place Order“ – issupported by one system usecase, which has also been calledPlace Order. Figure 4, shows asimple Use-Case diagram forPlace Order.This system use case is implemented in the SupaStores OnlineOrder Processing (SOOP) system,which delivers the order-entrypages to the SupaStores website,supported by an order database.Business vs. System Use Cases – Part two© 2008 Martin Langlands and Charles Edwards Page 2 of 6On the diagram, we’ve used a UML stereotype notation on the SUC to indicate the system, «SOOP», that implements the use-case. This system use case allows the customer– the primary actor – to select products into a virtual shopping trolley and choose a delivery time-slot.Within this SUC, the customer also pays for the order using a payment card. This can’t bedone by SOOP alone; it needs to communicate with the banking payment system, whichtherefore needs to be shown as a separate, supporting, actor. (The primary actor initiatesthe system use case; supporting actors are called on by the system use case.)There are a couple of modelling points to note immediately.Ɣ First, in this case, the system use case name is the same as that of the business usecase step. This is reasonable because this system use case implements pretty muchthe entire business activity.Ɣ While in the Business Use-Case diagram (Fig 1 in Part 1 of this series), we showedthe Bank – a business entity – as a supporting actor, we’re now showing here theBank Payment System as the corresponding supporting actor. This highlights the factthat business use cases are about business concepts, while system use cases areabout systems concepts. “Well, obviously!” you say – but we suspect that a lot of theproblems come from not applying this “obvious” principle.We’ll now go through each step in the business use case and ask: “What system usecases support this business activity?”. Figure 5 shows the result.Business vs. System Use Cases – Part two© 2008 Martin Langlands and Charles Edwards Page 3 of 6This is the same business use case Activity Diagram as Figure 2 (in part one of this series), but now with all the supporting System Use-Cases superimposed. The relationshipbetween each system use case and the relevant elements of the business use case isshown by the associations labelled “supports”.Note that this is a new kind of diagram, which we call a Process / Use-Case Support Diagram, or PUCS Diagram. We’ll come back to discuss this below. In the mean time, let’scontinue with completing the picture.The second activity on the BUC, “Pick Goods”, is performed by the SupaStores warehouse. This uses an older stock-management system called the Warehouse InformationManagement System (WIMS). Among many other things, WIMS allows the warehousestaff to print off a hard-copy pick-list of orders due to be shipped in the next couple ofhours. This is shown by the Print Pick-List SUC. After executing this SUC, the picker continues with the BUC step by going round the warehouse shelves, assembling the order,and marking-up the pick-list by hand as s/he goes to show out-of-stock items, substitutions and so on.However, there’s something else that has to happen first: the order details need to getfrom the SOOP system to the warehouse’s WIMS system. This is done by a batch job inWIMS, scheduled to run twice daily, that queries the SOOP database. The batch job isrepresented by the SUC Upload Completed Orders. This has two actors, both systems,rather than human actors: the primary actor is the Scheduler, and the SOOP Database isa supporting actor. Finally, note that the “supports” association from this SUC is not to anactivity on the BUC; rather the SUC supports the transition between the Place Order andPick Goods activities.Now, going back to where we were at the “Pick Goods” activity: once the warehouse employee has finished picking goods for each order, s/he hands back the marked-up pick-listto the warehouse supervisor who uses a further WIMS System Use-Case, Finalise Orderand Print Delivery Sheet. This allows the supervisor to flag in the system any items thatcouldn’t be found on the shelves, indicate any substitutions, and print a delivery-sheet forthe truck driver. So there are two SUCs that support the same BUC Activity. This mightindicate that the activity needs to be split into two on the diagram (this iterative modellingbetween development of BUC and SUC models is typical), but we’ll leave it as it is fornow.The next three BUC activities – “Load Truck”, “Deliver Order”, and “Confirm Receipt” –have no systems support. Route planning is done by the delivery staff and driver usingtheir local knowledge and a street-map. The delivery sheet printed off by the warehousesupervisor provides all the information the driver needs en route, but reading and signingthe paper can hardly be counted as a “system uses-case”.The final activity in the BUC – “Record Delivery Result” – does have system support. Theclerk in the shipping depot records post-delivery details from the sheet into a third system, used to track completed orders and also to record utilisation of delivery vehicles,called the National Utilisation and Tracking System (NUTS). This accesses delivery datafrom the WIMS database, which is therefore again shown as a supporting actor.Note that the SUCs we’ve listed above as supporting the BUC steps are far from beingthe only set we could imagine. In fact, we’ll look in Part 3 at what a different set could looklike, and how this would affect the overall picture.Inside the System Use-CaseIn Part One, we opened up our example Business Use-Case to see what one looks likeinside. What happens when we do the same thing with a System Use-Case?We’ve taken the “Place Order” SUC as the example to illustrate. Figure 6 shows the firstcut SUC Description. Again, as for the BUC before, we’ve shown only the Main SuccessScenario or Main Flow.Business vs. System Use Cases – Part two© 2008 Martin Langlands and Charles Edwards Page 4 of 6Note that we could have drawn a UML-style Activity Diagram similar to Figure 2 (in thefirst paper of the series) to represent this SUC. However, at this stage, it would not bevery interesting: just a single sequence of activities, more-or-less alternating between Actor and System swimlanes had we chosen to show them. Drawing such a diagram would,however, get much more interesting and valuable once we include alternative and exception flows.Name : PLACE ORDER System Use-caseBrief Description : In this Use-Case, the Actor uses the SOOP system to place a new orderfor delivery. The actor selects the required products, chooses a delivery slot from thoseavailable, and makes a card payment for the order.Principal Actor : Customer (On-line)Precondition : The Actor has successfully logged on to SOOP as a valid and registered customerMain Flow Step NameDescriptionTriggerCustomer chooses to place a new orderDisplay ProductsThe system displays or presents the product offerings to CustomerSelect ProductsCustomer selects as many products as wanted into the “shoppingbasket”, choosing from those offered, and entering the requiredquantity ordered of each.Indicate selectioncompleteCustomer indicates that the product selection is complete.Display total priceThe System calculates the indicative order price, applying multi-buydiscounts, and displays the resulting totalAccept priceCustomer indicates that the price is accepted.Display availabledelivery slotsThe System finds available delivery-slots for scheduled delivery runscovering the address held for the customerChoose delivery slotCustomer selects the desired delivery-slot from those presented.Present storedpayment card detailsThe System displays details of payment cards held for the customerand requests the customer to choose a cardConfirm paymentcardCustomer selects one of the presented cardsValidate card paymentThe System contacts the Bank Payment System which validates thecard paymentPresent order detailsThe System presents full details of the order (shopping-basket withindicative prices; delivery address; selected delivery slot; card payment details) for the customer to print if requiredEmail order detailsThe System sends an email of order details to the email addressheld for the CustomerEndThe Use-case ends Figure 6 : Text Description of System Use-Case“Place Order”Business vs. System Use Cases – Part two© 2008 Martin Langlands and Charles Edwards Page 5 of 6Superficially, Figure 6 is very similar to the Business Use-Case description in Figure 3 inpart one. Both show an interaction, or dialogue, between an actor and the conceptualsystem that implements the Use-Case.However – and this is critical to the central point of this article – the fundamental nature ofthe two Use-Cases is very different.Ɣ In the BUC example, this conceptual system that implements the Use-Case”is the SupaStores business itself, whereas in the SUC it is the SOOP system.Ɣ The nature of the interactions is completely different, too: in the BUC, theyare “real-world” interactions involving physical people, goods, trucks and soon, while in the SUC they are probably1 conducted via a PC screen, mouseand keyboard.Ɣ Clearly, the duration of the BUC and SUC are very different – a few days inthe first case, a few minutes in the second.Note that, in contrast with the BUC in Figure 3, Figure 6 is a black-box view of the SystemUse-Case: it shows only the dialogue between the actor(s) and the system, with no internal implementation details. But this does not affect the fundamental points of difference.The Key DifferencesWe’re ready to summarise the key differences between the two concepts. AspectBusiness Use-CaseSystem Use-CaseWho’s thePrimary actor?Mainly a business actor e.g. customer; maybe other external party(regulator, shareholder) or an internal party (manager, etc)Mainly a human user who initiatessystem behaviour; maybe anothersystem, “scheduler” etc. But bydefinition a system actorWhat’s theuse case for?Something the actor wants to getdone by using the business / organisationSomething the actor wants to getdone by using the system / applicationWho / whatelse may beinvolved?May involve interaction with otherexternal business parties as supporting actorsMay involve interaction with othersystems internal or external to theorganisation.What does itdescribe?Describes an interaction involvingthe primary actor, the relevantparts of the business, and anysupporting actor(s), in terms of theirbusiness behaviourDescribes an interaction involvingthe primary actor, the relevant partsof the system, and any supportingactor(s), in terms of their systembehaviour . In the case of the primary actor, this means only theiractions detectable by the system,such as making selections, supplying data etc.How’s it executed?May involve many organisationunits, systems (or not), technologies, manual / mental proceduresetc.Executed by automated steps inthe systemDurationOf Varying duration – May be verybrief or very long-duration.Typically quite short duration(Cockburn’s “coffee-break” rule) 1We could imagine this done another way – eg. with an interactive TV and a remote control, oreven, at a stretch, via a voice- and keypad-activated phone system. The key point is that theactor is interacting with a computerised system.Business vs. System Use Cases – Part two© 2008 Martin Langlands and Charles Edwards Page 6 of 6Ɣ When faced with a particular modelling task in a real-life project, these differences helps us to decide: “Which one am I modelling here?”.Ɣ Make sure you know the answer, and stick to it. Get yourself into the appropriate mindset, and don’t mix the business and system views in the sameUse-Case. Once you’ve got them sorted out, you can show how they’re related using a Process / Use-case Support (PUCS) Diagram.Requirements or Design?We said above, in starting to discuss the System Use-Cases that support our BusinessUse-Case, that “we are now moving from the what gets done, to how it’s done“. Thisraises an issue that often causes problems, and in doing so typically generates more heatthan light. The question that’s asked is: “If we’re now moving to the how, are we not moving from requirements to design? And if so, isn’t there a conflict in that Use-Case Descriptions are supposed to be a requirements artefact?”.This topic has been discussed extensively (try Googling for “requirements vs design”),and we don’t want to reiterate all the arguments here. But to summarise our view: UseCase Descriptions are both Requirements and Design artefacts.How can this be?Bear in mind that there’s a progression from coarse-grained outline business requirements through to implementation of a software solution. (And no, we’re not advocating awaterfall approach here – it’s OK to iterate back and forth along this progression.) At eachstage, we take stated requirements and apply a range of factors – logical considerations,technical guidelines, best practices, constraints and so on – to come up with a design atthe appropriate level of detail. That design becomes the requirements statement for thenext level of design.This “requirements vs design” issue is closely related to the viewpoints of the variousstakeholders in a project. To a software developer, the Use-Case Description in Figure 6might look very much like a requirements statement, and a fairly un-detailed one at that.To her, it’s just waiting to be tackled with some decent design, covering UI layout and behaviour, object / component design, system integration, performance, security and so on.But to the business manager responsible for the new on-line order service – whose mainconcerns may be doing a deal with the right payments operator, or ensuring that warehouse and delivery people understand the impact of the new service – Figure 6 looks likepretty detailed system design.And the thing is – they’re both right!Next timeƔ In part three we will look again at the Process Use Case Support Diagramand make observations and conclusions about the differences betweenBusiness and System Use-Cases.Contact details[email protected][email protected]www.ProcessWave.com and www.AgileEA.com
