Monday, 8 November 2010

Use (less) Cases

Alex travels around the world teaching organisations about creating systems and how to use Use Case diagrams effectively. A huge percentage of people are sceptical about Use Case Diagrams but in this new series of posts he is going to be teaching us how to use them to make a difference in our work...

I love use cases. I love teaching them, writing them; in fact I love everything about use cases, well almost. What I really don’t like about use cases is the frequent way in which they are poorly introduced into an organisation. 

At Objektum Solutions we talk about the “use case hoax”; the fact that many people focus on the “stick men and bubbles” while failing to understand the underlying concepts of use case development. For us use cases are not about the notation but about the thought processes that are employed in their development.

One of the problems that I often encounter is the inability of engineers (particularly those who have spent years at the detailed design or implementation level) to abstract their thinking in order to express how the systems they develop will be used in the real world. All too often I find use cases that are developed purely to “tick” the relevant boxes and therefore add little or no value.

As with any new technique (and by new I am speaking from the relevant point of view of the deploying organisation as use cases have become an old friend to many of us), careful consideration has to be given to how to introduce use case driven development.
In order to successfully apply use case modelling to a project, engineers must first be taught why they are doing it and what the expected result is. For me use cases offer more than just an understanding of how the system under development will be used. They are a means of discovering what questions need to be asked of the stakeholders in order to ensure that a project is suitably equipped to move the development effort forward.

Over the years I have taught many aspects of software and systems engineering but there’s still nothing more gratifying that the look, at the end of a use case course, which clearly says “wow, I never realised how powerful this technique is”.

As a consultant it is my job to teach people modelling languages but as an engineer it is my mission to teach people how to model.

No comments :

Post a Comment