Estimating user-goal and sub-function level use cases¶Erwin: Now there’s an opportunity to apply smart use cases in a project. This brings forward some questions. When estimating the complexity of smart use cases, is an estimate only produced based on the sub-function level use cases (at lower granularity), and is the complexity of the user-goal level use case merely the aggregate of these points?
Extracting sub-function level use cases from a user-goal level use case is NOT a functional decomposition. The single user-goal level use case always performs some part of the works. At least it’s responsible for co-ordinating the whole process it implements, but in most cases it also will own part of the user interface, like in the example below where user-goal level use case Site Overview show all information on the managed site.An example smart use case diagram
Thus, it has the same level of granularity as the underlying sub-function level use cases. And it is also estimated using the same scale (1..5, 8, 10) as the sub-function level use cases. The total complexity of the diagram then is the aggregate of the weights of ALL use cases in it.
To follow the presented example, use cases Site Overview is probably rated as a 3 – Average on the smart use case scale. We would estimate the total diagram at 22 smart use case points, including the 3 from Site Overview.
The smart use case life cycleErwin: In the smart use case life cycle all smart use cases go through the same stages (“New”, “In iteration”, “Working”, “Testing”, “Rework”, “Accepted”) from left to right. But, I take it, from “Rework” use cases go back to “Testing”? And, additionally: it’s only the sub-function level use cases (or the user-goal level use cases without sub-function level use cases) that go through the cycle.
The smart use case life cycle identifies a number of stages smart use cases CAN go through. The stages proposed in Smart (the agile methodology the life cycle comes from) are not mandatory, but represent the most used stages. Some projects add stages such as “Design”, or split “Testing” into “Testing Team” and “Testing Customer”.
Having this simple staged smart use case life cycle allows projects to put up an nice dashboard – either on the wall or white board, or online using a dashboarding tool such as our Agile Dashboard, Mingle or VersionOne.Example smart use case dashboard
In fact, ALL smart use cases go through this life cycle, not just the sub-function level ones or the user-goal level ones without additional sub-function level use cases. And indeed, coming from “Rework”, it is likely that the use case needs to go through “Testing” again.
Stereotypes and minimal use case specifications¶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.