© 2008 Martin Langlands and Charles Edwards Page 1 of 6Business vs System Use Cases – Part threeAuthor: Martin Langlands and Charles EdwardsVersion: 1.0 Date: 6 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 distinguishingbetween “Business” and “System” Use Cases. The aim of this three part article series is toshed some light on this issue by highlighting the differences between the two, and proposinga diagrammatic way of showing how they are related. This is illustrated using a more detailedand meaningful example than is used many introductory texts.Previously in part one and part twoIn Part One we started to discuss the difference between introduced the terms Business andSystem Use Case, and showed our worked Business Use Case example.Part two showed worked examples of system use cases based upon our business use case.The Process Use Case Support (PUCS) DiagramIn order to fully appreciate the value of the separate Business and Systems Use-Case concepts, we need to understand not only where they differ, but also how they are related. Thefundamental nature of the association is:System Use-Cases support Business Use-Cases– meaning that the System Use-Case provides some automated means of doing part or all ofthe Business Use-Case.We are proposing here a new diagram-type, which we call the Process / Use-Case SupportDiagram, or PUCS Diagram, to provide an immediate visual representation of this support.Figure 5 (discussed in Part 2 of this series, and repeated on the next page) shows an example. It is a simple but effective addition to the UML diagram set, using existing UML concepts,and with additional stereotypes that could easily be implemented in a simple UML profile.Each PUCS Diagram is drawn for one Business Use-Case. The key elements of the diagramare:Ɣ A UML Activity Diagram showing the steps (activities) in the Business Use-Case (BUC)and the transitions between stepsƔ A UML Use-Case Diagram for each “supporting” System Use-Case (SUC)Ɣ An association, named “supports”, from each SUC to each business activity / transitionthat it supports. (Some activities or transitions may have no such SUC support.)The nature and extent of the support will vary from business to business and from one system to another. For example, the support given by a SUC to a business activity can varyƔ … from simple data presentation and / or capture, such as a straightforward data-entryUI with limited validation …Ɣ … through partial decision-support, such as an insurance rating tool …Ɣ … to full implementation of the whole step, such as an automated share-trading system.Business vs. System Use Cases – Part three© 2008 Martin Langlands and Charles Edwards Page 2 of 6These variations could be indicated on the PUCS diagram with stereotyping of the “supports”association, although care needs to be taken not to attempt to show too much on the diagram.What were we doing in the above example?In following the SupaStores “Buy Groceries” example discussed in Parts 1 and 2 of this series, the astute reader may have asked: “Why are we doing this? What’s the ‘project’ here?”.This is a fair point. From what we said, many of the SUCs in question are realised by old legacy systems. When those systems were first developed, there’s a very good chance thatUse-Case Analysis did not figure as a technique. So why are we going back in time now torepresent their functionality as SUCs?Well, apart from the obvious answer “to illustrate this article”, a real-world example would bea project that wanted to improve system support for a part of the process – say, the back-end“delivery” steps. Let’s say that the SupaStores executive in charge of on-line orders has identified a problem that the keying of the delivery-sheet details into the NUTS system (in thestep “Record Delivery Result”) is error-prone and often done late, resulting in poor manageBusiness vs. System Use Cases – Part three© 2008 Martin Langlands and Charles Edwards Page 3 of 6ment information, and incurs extra staff costs to do the data entry. She has sponsored a project for IT to look at the problem and come up with a solution.If we look at the problem in the fairly narrow terms stated by the project sponsor, we arelikely to come up with a narrow solution. If we don’t have the benefit of the BUC model, andjust focus on the use of the NUTS system by the shipping clerk, we might conclude that theproblem lies partly in a poor design of the delivery-sheet, or an unfriendly old characterbased NUTS UI, and tackle these issues. However, this would be missing an opportunity.We can propose a more imaginative solution by taking a wider view to look at the wholeBusiness Use-Case as in the example. Now we can see where the recording of the deliverysheet fits in the bigger picture, and ask: “What opportunities are there to improve the wholeprocess, by enhancing systems support, and / or by other changes?”.We could, for instance, propose giving the delivery-drivers web-enabled hand-held devices whichaccess and display delivery lists, and which are used to capture customer signatures. This would besupported by a new system, SWEET (SupaStores Web-Enabled Enhanced Tracking) that wouldmaintain a database of current deliveries. Now we can completely eliminate the costly and errorprone “Record Delivery Details” step. SWEET realises a new “Confirm Receipt” SUC, in which thecustomer (the SUC actor) uses the handheld screen to record delivery details, which are immediatelyrecorded on the SWEET database. Figure 7 shows the result on a new PUCS Diagram, showing thechanged BUC Diagram and a new set of supporting SUCs.Business vs. System Use Cases – Part three© 2008 Martin Langlands and Charles Edwards Page 4 of 6We can also see opportunities for further improvements – for instance:Ɣ We can help the delivery driver view the deliveries in a delivery run, perhaps displayingthese dynamically on a local-are map on the handheld (SUC “Display Deliveries”)Ɣ If we further add GPS functionality to the handheld, allowing SWEET to track the locationof each delivery truck, we can provide the customer with a “when’s my delivery coming?”function that she can access through her own home PC (this supports a different BUC,so it’s not shown on Fig 7).Of course, all of these ideas, and any others we come up with, need to be subject to a properbusiness case assessment, including a cost / benefit analysis, and not all will necessarily beapproved.But what we have done is to show a straightforward but powerful representation of both theunderlying business process and the current and potential systems support for that process.This representation is readily understood by business and systems people, and is an idealtool for discussing, scoping and planning the systems-development aspects of a businesschange project. Newly-defined system use-cases identified this way can, of course, go onthroughout the project as the basis of detailed specification, design and implementation. Inaddition, the fact that our legacy systems may not have been originally specified or implemented using explicit SUC modelling does not detract from the usefulness of the SystemUse-Case concept for describing the functionality of those systems retrospectively.Three CaveatsWe have attempted in this series of articles to help modellers with the sometimes tricky problem of distinguishing Business Use-Cases from System Use-Cases. However, there are stillsome issues that can lead to possible confusion.“The Business as a System”Sometimes we encounter the view that “there’s no real difference between the two – after all,the business can be viewed as a system, can’t it?”. This is as much a question of definition ofthe terms: yes, we can say this, if by “system” we mean something like “a collection of interacting elements, organised as a whole and collaborating to achieve a purpose”. While defensible – and there is, of course, a whole range of disciplines related to understanding “systems” with this meaning – it seems to us unnecessarily confusing in this context. When wesay “system” here, we specifically mean computer(ised) or automated system, and not “business-as-a-system”, and we urge readers to do the same.“System Boundary = Business Boundary”In many cases, the scope of the System Use-Case is exactly the same as the Business UseCase, and the SUC completely implements the BUC. Another way of saying this is that theboundary of the system across which the SUC interaction takes place is the same as theBUC boundary – they are “coterminous”. Examples include:Ɣ Web sales of downloadable software, music or other contentƔ On-line flight check-inƔ Withdrawing cash from an ATM (but not all possible ATM-based BUCs – for example,“requesting a cheque-book”)Ɣ Making a purchase from a vending machineƔ Connecting a phone-call in an automated exchangeThe key point about these BUCs that makes them completely implementable in a coterminous SUC is that there’s no need for separate steps to make decisions or handle physicalgoods, or any inherent delays between steps. The SUC may need to involve other systems,Business vs. System Use Cases – Part three© 2008 Martin Langlands and Charles Edwards Page 5 of 6as further secondary actors – for instance, to actually retrieve and deliver the software ormusic, check and update account balances and so on; but it’s still the case that one SystemUse-Case implements the complete Business Use-Case.Examples such as these are, of course, common and important, and are likely to becomemore so as digitisation of products, and the world in general, gets wider. They also tend to bebeloved as examples by writers of text books and articles. Unfortunately, this does often obscure the real distinction between BUCs and SUCs – because in these cases there is oftenlittle value in writing descriptions of both.However, there are of course still very many cases, such as the SupaStores example, wherethe SUC is not going to completely implement the BUC (short of a Star Trek transporter device to deliver cereals, steaks and kitchen-roll digitally).“One Level Too Low”A third problem that we sometimes encounter in distinguishing BUCs and SUCs is that modellers misapply the terms. This tends to be more common with technically-oriented people –perhaps developers doing Use-Case modelling – rather than “business analysts”.We’ve observed that they apply the term “Business Use-Case” to what we call a “SystemUse-Case”; so, for example, they’d define “Place Order”, “Print Pick-List” and “Record Delivery” as Business Use-Cases. The terms have been moved “one level down” as shown in Fig8.The thinking seems to be that “these arethings that the business user touches”, sothey must be “business”-things. In thisview, the term “System Use-Case” is thenapplied to things that happen inside thesystem – in effect, the things that (in ourview) would appear once we opened up thedescription of the SUC to the white-boxlevel. They correspond to system design orimplementation artefacts such as components, operations, or APIs that have no direct element of actor interaction or dialogue, and therefore can’t count as UseCases at all. (We might label these mis-usecases.) A problem with this misuse of the terms is,of course, that there’s then no term left forFigure 8: Terms movedone level down what we have called a Business Use-Case. Unfortunately, since this arises from a technically-focused mindset, this isn’t seen as presenting a problem – the true “business” thinkingis way out of sight in any case. What’s needed is to take a step back and appreciate that thesystem solution is there to support, and is intimately related to, a view of what’s going on at atrue business level, before we consider systems issues at all.Revisiting the Original QuestionWe’re finally in a position to discuss our client’s question that we raised at the start of Part 1of this article: “We are generating a Business Use Case Model for a project. The Project ismainly to develop a system which can enable users to be notified by WAP/SMS on their cellphone regarding their preferred stock prices, important Emails, news, weather etc. Nowwhich element shows the ‘Cell Phone’ usage in the diagram? A business actor, a businessWe say … They say …BusinessUse-CaseSystemUse-CaseDesign /implementationArtefactBusinessUse-CaseSystemUse-Case??? Business vs. System Use Cases – Part three© 2008 Martin Langlands and Charles Edwards Page 6 of 6worker, a business entity or a use case? Also, can Business entities be shown in Businessuse case diagrams?”Unfortunately, there’s no single answer to this. What we need is a longer discussion with ourclient. It seems possible that the questioner is suffering from the “one level too low” problem,among others. However, making some guesses, the response would be something like thefollowing.Ɣ Firstly, an important point is that the project team seems to be placing too much relianceon Use-Case Diagramming as a technique. Use-Case diagrams as such show very little;don’t get too hung up on what you can expect to get out of them, and don’t think that bydrawing Use-Case Diagrams you’re “doing Use-Case modelling”. Move on to textual descriptions as soon as you can, initially at the “use-case brief” level and then on to mainscenarios and finally alternative flows.Ɣ To take the last part of the question next – “can Business entities be shown in Businessuse case diagrams?”. The answer is most emphatically “Yes!”. Business entities, such asthe Customer and the Bank in our SupaStores example (see Figure 1 in Part 1), are critical elements of a BUC Diagram. Just don’t start to think of “cell phones” as business entities!Ɣ The key question here is: What is the core Business Use-Case? One possibility is something like “Advise Customer of Notifiable Event”, where the primary actor is internal to“us” (ie. the company offering the service) and the customer – and probably the phonenetwork provider – are supporting actors.Ɣ Having decided this, create a white-box Business Use-Case Description – in both diagrammatic and textual forms; then determine what System Use-Cases are needed tosupport each step. The relationship between the BUC and SUC should be shown with aPUCS Diagram.Ɣ Finally – and to answer the core question as posed: “which element shows the ‘CellPhone’ usage in the diagram?” – we’d say: None of them! The Cell Phone should not appear at all on any of these diagrams – not the Use-Case diagram, nor Activity diagrams,nor PUCS diagrams, at either Business- or System Use-Case levels. The Cell Phone itself is simply the hardware that supports parts of the overall picture. To show it would beas inappropriate as showing the user’s PC on the “Place Order” SUC Diagram, or indeedthe “Warehouse Building” or “Delivery Truck” on the BUC Diagram in the SupaStores example.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/bpmnContact details[email protected][email protected]www.ProcessWave.com and www.AgileEA.com
