Apparently some of us are convinced that "legacy" methods like the Unified Process do not properly address the issue of services. What I sometimes hear (and I don't exaggerate) is that a service delivers some reusable piece of functionality that cannot be pinpointed to a specific use case, so use case are useless. The best they can deliver is some flow diagram representing an orchestration of some services and call that a "business process".
Even when I was still clueless about SOA, I already found that hard to believe. What has become so different about user requirements since there is SOA that we cannot capture them as we used to? Has SOA really changed the way we think about requirements similar to how the Star Trek transporter will redefine the concept of transportation in a future near us? Does this question sounds rhetorical to you?
With this article and a couple yet to come, I hope to shed some light on this matter and help you to become aware that the world still turns and it is not you who is spinning around. As an example of this I will try to explain a way (not the but a way) of how you can capture requirements in a business process, and from there go to use case descriptions and finally implement services based on that.
As you might expect from me I will present this in the context of Oracle Unified Method (OUM), but don't let that scare you off. The targeted development environment will be BPEL.
The Case
The case I will use is of moderate complexity. The following activity diagram documents a business process concerning the application of a parking permit by a resident of some municipality.
At this point it is important to point out that this is a true "business process", as it only concerns business level actors like people, or organization units, and totally abstracts from any system supporting it. At this point the whole process could be manual, for all you know.I find that important to point out as too often I have seen the situation in which the "analysis" is limited to a description of how some system is going to be implemented rather than on capturing requirements. You should only skip that latter step when you do it consciously and the risk of missing something that proves to be important later on is relatively small.
What might surprise you, is that the same business flow can be documented as a use case description, typically of the scope "enterprise" (that is cross organization-unit). In this case it also concerns a business use case, as it describes how the resident communicates with Parking Services, which in this context is an organization, rather than how this resident communicates with some system.
The Use Case
Presented as a use case the same business process could look as follows:
Normally a use case will not be created in one blow at this level of detail. It is more likely to be created in a few iterations of which the first one might suffice to document only the stakeholders, goal and main success scenario together with some business rules. In OUM this is what the Business Requirements process is supposed to be limited to. The example use case has been worked out to a greater level of detail, which would typically be done in the Requirements Analysis process.
How Use Cases Add Value
Compared for example with the situation where only a business process diagram is available, adding use cases adds value in that a (detailed) use case description provides the opportunity to specify aspects of the business process that goes beyond that of what you can express with only a diagram.
One of those aspects is stakeholders that are not directly involved in the process. In some cases identifying such stakeholders might give reason to extend the scope of the use case, like identifying the stakeholder Neighbor might have lead to considering to include in the business process a step that notifies them as well.
Other aspects that the diagram does not cover are the goals, the triggers, preconditions, and postconditions of the use case. All of them helping to validate the use case and some of them providing useful input for the next step in which the use case is going to be analyzed.
An advantage of putting it down in writing that may not be so clear at first sight is that by forcing yourself to express the business process in words might help you to discover flaws and omissions in the original process.
The value of putting effort in converting a business process into a use case description is not always easy to determine. It depends on many factors like the ability of people reviewing the business process to identify flaws in it, or how easy it is to correct errors later in the process. Probably the best advice would be: when in doubt, don’t hesitate and just do it. In case of the example the business process has been converted into a use case description in less than half an hour. The total process took much more time, but that was because the business process model needed to be corrected, because of errors found while describing the use case.
To be continued ...
