CHAPTER
2.3 Business use cases
needs, the analyst must hear, instead of presenting fast prebuilt (and often mistaken) solutions. The analyst must motivate the client to detail her requirements and must question those requirements so that the client can decide which are urgent and which are not.
sharing comprehension about the real intention of business actors and workers. Blain4 presents some best practices collected from many sources:
• Good use case names reflect user goals. Names such asAccess systemorOpen main window must be avoided because they reflect technology and not a business goal. Also names without verbs such asInvoicemust be avoided because it is not clear what is going to happen to the invoice. Better names might beGenerate invoice,Cancel invoice,Pay invoice, etc.
• Good use case names are as short as possible. Although some people may propose that a use case name should not have more than two or three words (or any other number), it is unfeasible to define such a limit because there is a risk of losing clarity on the business goal if the name is too short. As Blain points out, which word could be removed from the nameCollect late paymentwithout obscuring its meaning? However, that name is better thanCollect late payment from customers that are past due.
• Good use case names use meaningful verbs.Use case names not only should havestrongverbs, but they must be meaningful. A meaningless verb is one that does not make clear what the use case accomplishes; for example what does a use case such as “Process order” accomplish?
What result does it produce? A name such as “Separate ordered items for dispatch” would be more meaningful in that case.
• Good use case names use active voice. As in general writing, active voice is preferable to passive voice.Pay for orderis better thanThe order is paid.
• Good use case names use present tense. The present tense indicates what the user is trying to do. Past and future tense may sound confusing and unnecessary.
• Good use case names do not identify the actor. As use cases are linked to actors, actors are not part of their names. Thus, a use case name must not identify the actor as inManager creates sales report. Just name the use caseCreate sales reportand link it to a manager or other actors if necessary.
• Good use case names are consistent. The same naming rules and naming conventions should be applied along a project or group of projects. Avoid, for example, naming one use caseGenerate sales reportand anotherProduce reservations report. Chose one verb for that meaning and use it consistently.
Additionally, Probasco (2001) proposes that the list of use case names should resemble ato do list. Thus, instead of writingCash withdrawal,Funds transfer, andATM service, it would be better to writeWithdraw cash,Transfer funds, andService the ATM, respectively.
Probasco also insists that the meaning of a use case name must be precise. For example, isAuction a good use case name? Is it a verb or a noun? If you consider that it is a noun and that a verb must be added, isExecute auctiona good name? The verbExecutewould probably be a programmer’s choice, but it probably has no meaning for an auctioneer (Is theAuctiongoing to be shot to death?). In this case, an idea would be to talk to a domain specialist in order to obtain a better name. On the other hand, even if “auction” is indeed a verb it is not sufficiently clear. Is it the auction of a single item? Is it the auction of a complete set of items? Is it simply an auction participant placing a bid? In that case, names such asAuction items,Auction single item, orPlace bidwould be clearer.
4http://tynerblain.com/blog/2007/01/22/how-to-write-good-use-case-names/
14 CHAPTER 2 Business Modeling
2.3.1 Business actors and business workers
During business modeling there are two kinds of actors that must be addressed (Figure 2.3):
• Business actors: People, organizations, or even systems that perform some activities belonging to the process, but which are not part of the target company. That is, they are not under company control. Business actors could be, for instance, customers, publishers, external auditors, partner companies, or even other automatic systems that the target company could interact with.
• Business workers:5People, organizations, or even systems that perform some activities
belonging to the process and that are part of the target company. They could be the company’s employees, its departments, or even existing software systems belonging to the company.
Graphically, they are distinguished from business actors by the use of the stereotype {workerc.
This differentiation is important because business actors usually cannot be automated, that is, they will not be replaced by computational systems. However, business workers roles can possibly be replaced by automatic systems (English, 2007).
Business actors and business workers are linked to the business use cases they participate in by connecting lines without arrows,6as shown inFigure 2.4.
2.3.2 Automation opportunities
A bookstore that intends to sell through the Internet, like Livir, should produce a business model that identifies its main business use cases, external actors (customers, publishers, etc.), and business workers (managers, clerks, etc.). If we suppose that the bookstore company already exists and has no automation at all or very incipient automation, then the business workers will be, basically, real people. These workers may be candidates for automation if there is interest in increasing the level
Customer <<worker>>
Clerk
FIGURE 2.3
Business actor (left) and business worker (right).
5If we are modeling a company as a whole usually business workers do not appear, as they are internal to the company’s system. But if connections between different subsystems of the company are shown, then business workers must appear.
6Some approaches suggest the use of arrows to indicate whether the actor only receives or sends information to the sys- tem. But that practice, besides not being supported by UML 2, brings practically no useful information at this point of the business analysis, because at the moment it is only important to know which use cases really exist, and which actors are involved with them. The details on the interaction will be given later with the activity diagrams that will describe how a business use case is performed.
15 2.3 Business use cases
of automation of the company. For example, the role of the clerk that currently helps customers find books on the shelves may be replaced in the virtual bookstore by an automatic guidance sys- tem. However, the customer role cannot be replaced by an automatic system.
Every business worker role will usually not be replaced. It will depend on the scope of the proj- ect to be defined. An advantage in making the business use case diagram, then, is to help in visual- izing and making decisions on automation. With the diagram, it is possible to visualize what must stay inside and outside the automation scope, depending on the project’s goals.
Normally, during an automation process within a company, it is useful to replace at least the workers’ roles that correspond to mere proxies, that is, the ones that simply perform actions in the place of an external actor. In the case of the bookstore, the sales clerk role is necessary only to help the customer at the physical store. But, when the sales are moved to virtual space, that role is not necessary anymore, because the customer may easily find her way on the website.
The association of the business use cases with the company’s major business goals helps to identify the scope of the system, that is, the activities that will be effectively automated in the proj- ect that is being initiated. In the example ofFigure 2.5, all use cases are candidates for automation at differing levels of priority. However, the company could be interested only in implementing sales and acquisition at this point, leaving marketing and customer services left to a second project.
The system boundary can be used to identify the set of business use cases and business workers that will be automated, as shown inFigure 2.6.
The business use case diagram shows that the automation project will include the processes of buying and selling books and the role of the clerk. It also shows that the processes of advertisement and gaining client loyalty are outside the scope of the project.
However, a deeper analysis may show that the worker that buys books for the bookstore cannot be easily automated. It might be the case that all books could be automatically bought by an auto- matic process that could analyze potential sales and stock, without the participation of any human being. But, if that is not the case, the best thing to do is to consider that the clerk really has two dif- ferent roles: help the customer (that role will be automated) and buy books for the bookstore (that
<<worker>>
Clerk
Customer
Sell books
FIGURE 2.4
Links between business actors, business workers, and business use cases.
16 CHAPTER 2 Business Modeling
role will not be automated).Figure 2.7shows an evolution of the diagram where part of the respon- sibility of the clerk is reassigned to a worker named “Acquisition manager.” There is no one-to-one equivalence between a role and a person: a person may perform many roles and a role may be per- formed by many different people.
Sell books
<<worker>>
Clerk
Customer <<worker>>
Marketing department Buy books
Sell books
Advertise
Gain client loyalty
FIGURE 2.5
Business use cases: candidates for automation.
Sell books
<<worker>>
Clerk
Automation scope
Customer
<<worker>>
Marketing department Buy books
Advertise
Gain client loyalty
FIGURE 2.6
System boundary being used to indicate the scope of the project.
17 2.3 Business use cases
If the project, on the other hand, consists of a number of subprojects or stages, in which differ- ent parts of the company would be automated, that could also be indicated by the use of different system boundaries in the diagram: one for each subproject or stage.
The next step that leads to the requirements analysis is the detailed study of the business use cases that will be automated. The level of precision and detail depends on the objectives of the project, as already discussed early in this chapter.