A Critique of Use Cases

Related Sites

Use cases seem like a very reasonable way to reach closure with users on what should be developed, but they are hardly object oriented. They are descriptions of interactions between the system and the users, and they say nothing about objects. They represent a functional approach, in that the describe what the system does, rather than the behavior of system elements. In my opinion, use cases are very dangerous; they encourage a functional approach and take the analyst's mind off class behavior. I can see why they are so popular, they are real easy to understand, and they let people continue to do functional design while thinking they are doing something very different. I am inclined to go along with Bertrand Meyer, who is of the opinion (Object Oriented Software Construction, pg. 739) that: "Except with a very experienced design team (having built successful systems of sevearl thousand classes each in a pure O-O language), do noy rely on use cases as a tool for object oriented analysis and design."

I don't think use cases are dangerous in and of themselves. I don't think there is anything particularly wrong with creating a functional decomposition of the problem domain; so long as that functional decomposition is not used as the basis for the structure of the solution. And I think that this is really the point that you and Meyer are making.

However, I think use cases are extremely useful for describing the problem domain in unambiguous terms. And also for communicating with the user.

I'd just like to say that although use cases provide part of a solution to the two problems you mention (describing the problem domain and communicating with the users), they are not enough, by themselves, to solve those problems.

And more importantly, because of the work that people put into the use cases, the more important parts of analysis get pushed into a "non-functional requirements" bucket and tend to be ignored until too late.

The vast majority of my recent work has been in designing and implementing the "non-functional requirements", y'know, things like an application framework, configuration subsystems, the user interface, all those completely unimportant things that don't appear anywhere in a use case anaylsis, but without which the application doesn't work, and without which you can't sell to, or impress customers.

"Analysts" spend months developing their use cases, based on their understanding of the problem domain, and then along come the real workers and immediately point out that use cases assume a sequential flow of control that works great in a green-screen environment, but is anti-thetical to the concept of a GUI application.

Use cases provide what looks to managers (especially those from procedural, mainframe backgrounds) like a great tool for distributing work, and they use them as such, forcing developers to work outside the team and management structure to get any real work done. They also like scheduling by use cases (This week we do use case 1, next week we do use case 2 ), when often the actual UI and object design should be done in one go, up front, (This is not really a complaint about use-cases per se, but just as people claim C encourages bad programming practices, I'm claiming that use cases encourage bad management practices.)

There are functional and non-functional requirements. While use cases are not wholly inadequate, they really are geared to providing functional requirements for software development. Things like "the system will fit in 1MB of RAM, and all screens will refresh in less than 1/2 of a second" don't fit nearly as well into use cases.

It is possible that you could get some functional requirements into it by stating their violation as an error alternative for a use case. For the entry of a transaction, it could say that if the dr [debit -YS] and cr [credit -YS] don't match, an error is presented and the user must either cancel or correct, then resubmit the transaction.

But sometimes it is really good if the overall rules are presented as text. Somethings can easily be said, but are a little harder to present in drawing or use cases. Important things like dr == cr should be stated up front in a requirements document and be maintained all along the way in the use cases.

Edward V. Berard, Be Careful With Use Cases

Donald G. Firesmith, Use Cases: the Pros and Cons

WikiWikiWeb, CritiqueOfUseCases

Alistair Cockburn, Writing Effective Use Cases