Sunday 7 February 2016

Use cases workshops

I was first introduced to use cases in 2000 while working as Ada engineer in Vancouver for Raytheon Systems Canada. The course was run by Steve Adolph, the author of Patterns for Effective Use Cases. Of course, Use Cases are almost ubiquitous now and I often find engineers capturing them without even knowing their origin or intent from UML. The reason is perhaps because the usage of a system actually remains rather important. That doesn’t make capturing use cases easy though. A use case diagram may have the simplest syntax but are the hardest things in UML/SysML to get right. In the 16 years since my training I come across some recurring themes. People often conflict:

a) Use case steps vs Use Cases (aka functional decomposition)
b) Scenarios vs Use Cases (e.g. forgetting that a use case includes alternative paths)

So, does it matter? Well, one implication of this is that you can’t give different use cases to an engineer or an engineering team and say “build me this”. Another issue is volatility and proliferation. We need to avoid ending up with 100’s of use cases whose names are continuously changing rather than the peaceful high level view of what the main goals of a system are.

So, what’s the solution? First, we accept that use cases will change as our understanding evolves. They are a requirement solicitation technique. Second, we accept that the purpose is not to get them 100% right but rather to get 100% of the people to agree on them.

The best mechanism I’ve found is to actually hold off creating use case diagrams unless you’re in a workshop context. Use case diagram workshops can be a sharing and consensus gathering forum and provide an opportunity for constructive questioning and subtle coaching: Is this a scenario of another use case we’re discussing? Is this an end to end usage or a function in a use case? Does this use case have alternate flows? By starting with a blank page, we have an opportunity for sharing opinions and knowledge of the system we think is needed.

The danger with letting people do use case diagrams on their own is that they will turn meat into mincemeat by over working them. The gold dust is often to have fewer not more use cases. It sometimes requires art not science to everyone on the same page.


  1. Dont you mean "requirement elicitation" instead of "requirement solicitation" on paragraph 3?

  2. Ha ha. A Freudian slip, perhaps? Actually, soliciting could mean something different to different people. As can happen with perfectly written English Language requirements. In the English Dictionary "to ​ask someone for ​money, ​information, or ​help", whereas in America it is probably exclusively negative. Reminds me of a time where I was told that I couldn't use 'Snooker' as an example model, as the word has negative connotations in the US. In the UK, it's a game with balls. Same language, different meaning depending on view port.


Note: only a member of this blog may post a comment.