Another quick email thread I thought I'd let everyone in on... this one concerns Use Cases - and what are they good for? This was started after a discussion on the relationship between Business Use Cases, System Use Cases and Services in an SOA, and whether use cases have a meaningful role when so many projects now tend to start with a business process model not a use case model.
While I still believe that use cases are the most divisive topic in software methodology they still have a place as long as you treat them far more formally than most Rational (RUP) die-hards would ever do. The Use Case is not a panacea, no silver bullets here, it is a tool and can be used and misused, underused and overused. In my mind -- and yes I like use cases and advocate them where I can -- the Use Case as a tool has two benefits:
- In the separation of Use Case and Realization we get a Black Box and White Box view, so the use case description and associated scenarios are written from the external point of view and so focus squarely on the WHAT, the realization on the other hand is focused on the HOW.
- The use of scenarios to illustrate a system using stories or flows or whatever-you-call-them; these allow a system to be described as a series of particular cases rather than the traditional approach of trying to describe all possible behaviors of a system in a single model. For a Use Case the complete behavior is the union of the behaviors indicated by the different scenarios.
Now, back to modeling, the stick-figure and oval diagram is completely and utterly useless, yep useless, as anything other than a map to the descriptions held within. To my mind use cases and scenarios are far better described in text, though the odd picture often helps. The realization is where modeling provides value as the HOW should be described more formally and of course using a model allows for refinement that is hard in other forms.[Read More]