We (my team and I and a lot of people that contributed from projects) have been working on the concept of smart use cases on and off over the last ten years. I think it was back in 1998 that we coincidentally started modeling use cases at bit different than was custom, in a workflow oriented project. We not only pictured a single use cases with one or more associated actors, but discovered ways to use the use case diagram in a much more visual way, adding supporting use cases and actors, and by using use case relationships to a greater extend. This eventually led to the definition of what we now refer to as smart use cases.

Finally .. the book?

After having trainer over 2.000 people in the past 6 to 7 years, and having seen a growing number of organizations and project use the techniques, it’s probably time to write the book (if I can find the time). Likely the book will cover the following subjects.

User-goal level and sub-function level

Over time we have seen all kinds of new ideas, and extensions to this core thoughts back in 1998. First of all Alistair Cockburn’s model gave the different levels a name; user-goal level use cases and sub-function level use cases. Then we discovered different approaches to identifying smart use cases, from business processes and project scope, but also from existing applications, or functional documentation.

Modeling smart use cases

We quickly gained on tips and tricks on modeling the smart use cases, including splitting diagrams into service consuming and service provision, modeling in colors, how to use include and extend, and when to model supporting actors, and when not. Even further we discovered a lot of patterns in how smart use cases work together.

Testing smart use cases

Testing was always high up on the agenda. During a project for a large pension fund it appeared that a test technique called a project cycle test worked very well on our smart use cases, so we elaborated on that further, and transformed the original technique using UML activity diagram and generated test scenario’s.

Stereotypes

Originally we were modeling smart use cases for “normal” types of projects, such .Net, web applications, PowerBuilder, Java. Later on we found out that modeling smart use cases also appeared to be useful in SharePoint, BI and even SAP projects. From all these projects a growing list of standard types of smart use cases evolved, containing standard types (which we refer to as stereotypes) for data manipulation, reporting, service orientation, BI (ETL), and much more.

Estimating smart use cases

Later on, we added a very useful an pragmatic estimation scale for estimating smart use cases. This scale has proven to be extremely efficient in a wide variety of project types. It was only last week that we have modeled out a service oriented SAP implementation and estimated the project at 276 smart use cases points (SUCP). We call this technique smart estimation. Of course, all of our stereotypes match the scale so we can estimate fairly quick.

We soon picked up agile estimation techniques like smart estimation poker to establish team estimates for smart use cases, but also use a quick estimate spread sheet, to gives reliable results in no-time.

Being smart at agile

Talking of agile, in the same period that smart use cases were defined, an agile methodology saw the light that embeds the above techniques in a mature agile process. This methodology is called Smart (not the acronym) – hence smart use cases. In it’s core the Smart process is smart use case driven.

Smart use cases in code

And last but not least, the most important step of all: transforming smart use cases to code. There are very sensible ways of mapping smart use cases to your software architecture, and we promote having a process layer in your architectures, that hosts your use cases. In our own software architectures and frameworks, we have elaborated on mechanisms and design patterns (more specific the task pattern) to implement our smart use cases directly in code.

Even further, the stereotypes we apply helps us to generate lots of code (and other deliverables) from the model, using a model driven code generator (in our case called Tobago MDA).

So .. next step is the book?

There is so much to tell about smart use cases, that I have to start writing it down, even if it is just to keep my head from exploding. Than there’s only one way to go forwards from here, and that’s to write a book. This blog post is a short outline on the contents of this book-to-be. I would love to receive your examples, thoughts, ideas, annotations and models (e.g. in Enterprise Architect’s EAP format). You will be mentioned.

Pleas e-mail me all your input at: smartusecases@gmail.com. Thanks! For more information check out www.smartusecase.com

Share this post :