Raise your level of abstraction

Use (less) Cases

Alex, one of our lecturers wrote this piece on Use Cases that I thought might be of interest to you all. It's taken from our blog, The Technical Diaries.

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.

Alex

Add a Comment

You need to be a member of The Model Driven Software Network to add comments!

Join The Model Driven Software Network

Comment by Derek Russell on January 24, 2011 at 13:12: Hi Andreas,

I hope this year has got off to a good start! We're busy and back in the swing of things and so Alex has had a chance to sit down and write about where he sees Use Cases adding value. Do check it out when you have a moment: http://the-technical-diaries.blogspot.com/2011/01/round-pegs-into-r...

I welcome any further thoughts you have!

With kind regards,

Derek

Comment by Derek Russell on December 14, 2010 at 17:35: Hi Jim and Andreas,

Thanks for your great comments, good to get some discussion going!

Andreas - Your comment has inspired Alex (who wrote Use(less) Cases) to specifically address the development of use cases and when to use them in order to obtain the most benefit in his next blog post, which will be published in the next couple of days. In the blog post, we will discuss both the technical and commercial benefits of developing use cases even when a detailed requirement specification has been provided. I'll post the blog post on here, so keep an eye out!

Jim - Good question.It is not uncommon for engineers who are new to use case development to “view them with suspicion”. This is usually because the benefits of use case modelling have not been accurately demonstrated. During training sessions the use of practical exercises, which provide hands on experience in use case development techniques, typically leads to a “eureka” moment and usually convinces even the most ardent sceptic of the value that can be added. During consulting sessions, the same effect is achieved by guiding the team through the use case process using their own requirements. How use cases techniques are introduced to your team is as important as the techniques themselves. I hope that answers your question?

Thanks

Derek

Comment by Jim Roberts on December 12, 2010 at 19:52: Hi Derek,

I once worked in an organization where the development team saw the use case model with suspicion. They found it hand-cuffing and tedious. They never saw the value in them. It never got off the ground. I was wondering , as a consultant, how you have been able to combat this?

Thanks

Jim

Comment by Andreas Leue on December 9, 2010 at 17:52: Hi Derek,

interesting blog posts. Concerning the previous, I share your view of the relevance, past and future of MD.

I think the problem with use cases is that they contain a lot of information that is redundant between analysis and design (i.e. roles, workflow, static structure etc.), so that a full fledged analysis gets costly since everything is written down twice. In consequence, such analysis is mostly found in inch-thick contractual formal documents. Alternatively, one can apply them sparsely, as an addition to say user stories. But then, most people are not interested in doing this "aesthetically" (I always am :) ).

I think you can really do nice modelling with them, but can't really see too much opportunities when this is oeconomically apt. I'd love to hear stories telling me the opposite.

Andreas

Use (less) Cases

You need to be a member of The Model Driven Software Network to add comments!

Badge