As you might have heard from me before (endlessly), smart use cases are a fairly straightforward reqirements technique that we have introduced in many different types of projects, such as Java, .NET, BI, SOA, SAP projects.
At times I receive question on smart use cases in projects, this time from Ron Kersic of Capgemini. See Ron’s original Dutch statement below.
Ron: If you apply smart use cases and the associated stereotypes, do smart use case specifications become unnecessary? If so, this is a massive unique selling point, and should get much more attention.
Smart use cases have a low and equal granularity. This low granularity (sub-function level) guarantees that use case specifications are never very long, and in general will not consist of more than pages of text, including alternative flows.
Example smart use case specification (in this case 2 pages)
Applying smart use case stereotypes
Additionally we standardize further by adding smart use case stereotypes. There is a growing list of smart use case stereotypes available. We occasionally add new ones, for instance I would like to add a Register stereotype soon.
Using these stereotypes, the scenario’s smart use cases run become very much standardized. Think of one of the most used stereotypes Manage, that is meant to maintain (add, update, delete) single instances of a particular domain object. It is more or less the same for any application, for any domain object in any domain. Why bother writing long use case descriptions for that? So we have templated it, both for documentation purposes, and also for code generation.
During analysis workshops, where we model out smart use cases together with our customers, we tend to model as many of the use cases we can towards using the well-known stereotypes. This saves an enormous amount of time and effort in projects – which yes is also a very good thing for our customers. They too will have less work on the project, and it gets delivered sooner, and better.
Model driven estimation
Moreover, as we apply the stereotypes during these workshops, and use code generation, we simply generate out an estimate (in an Excel spread sheet) for the project at the end of a workshop, using Tobago MDA and a simple template that runs over the use cases in the model. “Dear customer, this project consists of 298 smart use case points. It will take us 14 weeks to build it.”
So, to answer the question, yes smart use cases have some BIG unique selling points, and yes, we should give them more attention.
Ron’s statements
Snel vraagje: maar zijn use case specifications overbodig met smart use cases (en gedefinieerde) stereotypes? Als dat zo is, dan is dat een massieve USP IMHO en dat mag wel wat aandacht hebben. Comment van deze strekking ook aan boek in progress toegevoegd…
Da’s een goeie: constraints over de geassocieerde domain types introduceren (subset aan veldjes e.d.). Dat kan heel mooi met de where-clauses die ik van Oslo M aan het jatten ben! Dit gaat nog eens ergens op lijken 🙂
Zijn er eigenlijk redenen om die stereotypes niet echt heel erg door te trekken dan? Ik heb zo’n hekel aan die use case specs (altijd gezeur, altijd over-specificatie en dat heel vaak door niet-programmeurs), zou er een lief ding voor over hebben om ze te lozen…
Ron Kersic
Capgemini