Jan Kettenis has written a long and eloquent post defending Use Cases as a method of describing Business Requirements: About Business Processes, Use Cases and SOA (1). "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." Jan clearly thinks this is wrong, and constructs a moderately complex example to illustrate how use cases can be useful.
I do agree that use cases can be useful - but my own view is that they are mainly useful for describing a solution (however abstract) rather than a pure requirement. In Jan's example, use cases help to specify the behaviour of an entity called Parking Services. (According to Jan, this entity is an organization rather than a system, but I don't think it makes a difference to my argument.)
But how do you decide that there should be a single entity called Parking Services in the first place? It is a design decision (business design, not software design) to cluster this behaviour together rather than distribute it across multiple entities. Because I want my description of the requirements to leave such design decisions open, I prefer to describe the requirements purely in terms of some set of outcomes for some set of stakeholders. I think there are usually many different solutions to requirements like these, and each solution can be described in terms of some collaboration between a number of entities behaving in certain ways.
Thus I accept that use cases have a place in the requirements and design process, but I think it is often a good idea to defer the production of use cases until the solution space has been adequately explored.
I think Jan actually concedes this point. "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."
There is another problem with a use-case-driven approach to business requirements, and that relates to reuse/repurposing. If I start my service design from a set of use cases for the "Parking Services" entity, then there is no reason to expect these services to be of any use in any other context. Yes, a service is supposed to deliver a "reusable piece of functionality" - and so we probably don't want to restrict the use of a given service to a single use case. (Is this what Jan means by "pinpointed"?)
When I analyse business requirements, I want to think about flexibility: that means thinking about supporting not a single interaction but a range of possible interactions. For example, what are all the ways that a doctor can interact with a drug company, what are all the channels (direct and indirect) that a doctor might use to get information about a drug company's products, and how can we build rich services that support as many of these interactions as possible?
Jan ends his post by highlighting one of the most valuable consequences of documenting use cases - exposing questions and issues about the business process, which arise from the rigour of use case analysis. Rgorous analysis is always praiseworthy, but sometimes it requires just as much discipline to avoid preempting design decisions.
Thanks for starting this discussion!
ReplyDeleteAre you challenging the business process / use case approach as a whole, or just the creation of user-goal business use cases? I assume the latter, as otherwise I wonder how you would get a grip on the big picture and address issues like end-to-end coverage of business processes in terms of completeness and testing (just to mention two problems I see with that).
Let's assume that you "only" propose not to detail the user-goal level nodes of a business process with a use case description. I find it interesting to know what you use to capture user requirements in a way that an end-user can recognize them without getting confused by a lack of context. How would you prevent the risk that the requirements of a specific actor in a specific context gets blurred by generalization?
I also wonder if we have the same notion of "requirements". This wondering is triggered by your statement that you think use cases are more useful for describing a solution. Although I recognize that they can be used for that, I only see added value in specific situations where there is a need to describe a solution in words.
Granted, specific situations like that typically are in the SOA-space. I create service descriptions of reusable (business) services to capture the goal, input and output and any transformation or other business logic in there of a specific service to build.
I classify such service descriptions as a user-goal/sub-function system (instead of a business) use case. /User-goal/ if the service covers exactly one specific goal of some actor, sub-function if it is generic and supports more that one goal, or more specific and together with some other functionality supports part of such a goal. And /system/ because it describes how a system supports that goal, rather than abstracting from that and just stick to the requirements.
Finally I wonder how you prevent over-designing, but also under-designing the service if you do not have captured the specific usages in different contexts.
In my opinion, use cases are too weak for describing a solution (even if abstract), but for that very reason they're great to capture what the stakeholders would want to do with a system, standing from their own viewpoint. We are (dramatically) short of tools for capturing the very essence of WHAT we are being asked to do. We don't need another technique for describing solutions, I think.
ReplyDelete