9
« on: April 25, 2005, 05:07:18 pm »
On a recent project, where we were using UML for the first time at this client site, we adopted the following convention:
1/ A Use Case was a full description of a process that provided some tangible business benefit to the user (such as "Register a Customer", "Do Compliance Check", "Transfer Customer Data to X System"). These were not functional decompositions, but descriptions of full processes.
2/ A Use Case was included in another (the Base Use Case) if the Base Use Case if the Included Use Case described a business process that was required in the Base Use Case. For example, one of the requirements for registering a customer is that a compliance check needed to be performed before the customer could be registered. In this case the Do Compliance Check would be diagrammed as an included use case with Register a Customer.
3/ A Use Case extended another if it added additional functionality to the Base Case. In our case, once a Customer was registered, the data had to be transferred to a lot of individual systems. So, the Transfer Customer Data to X System (all of them) were diagrammed as Extended Use Cases to the Register a Customer Use Case.
4/ The only exception was the Login Use Case, which is traditionally included in those Use Cases where specific credentials were required (Logging into a System does not normally provide a tangible business benefit to the User).
Identify the Use Cases first, making sure that they provide a tangible business value. A Use Case should stand on its own, and so must be written at a relatively high level. Once that is done, then look at the Use Cases to determine if there are relationships (Include or Extend). We found it much easier to do this way, since it kept the Use Cases to a manageable number. More importantly, our Users found it easier.