I have been modeling with UML since 1995 (when I got my first copy of Rational Rose) and have had too much success with Model Visually to not include it as a best practice in my projects – especially use case modeling. Early on I used use case diagrams to augment traditional requirements specifications for OOAD. I didn’t start writing use case specifications until years later after I was given a set of use cases from hell for analysis and design. I thought, “There has to be a better way.” Well there is and Writing Effective Use Cases by Alistair Cockburn is a wonderful guide to writing excellent use cases. But excellent use case specifications take as much creativity and effort to write as it takes to design software. And… there aren’t many people who are willing and/or able to do it. I don’t mind expending the creative energy to write use case specifications; I actually enjoy it. But all that effort for something that the customer just doesn’t understand? After participating on several use case driven projects, I give up on use case specifications! There has to be a better way.
Well there is… and I am not just talking about replacing use cases with user stories. I am talking about shifting focus from molding words to molding concepts. Yes, when the team models requirements provided by (or gathered from) the Product Owner (or even if the Product Owner does it themselves) they expend creative energy but they also add immeasurable value to the development process. Since models are easy for Product Owners to undertand, the team is able to communicate understanding of the requirements while simultaneously communicating complexity of the proposed system. This has been my greatest success so far .
There is a better way… Model Visually.