Use Cases are one of the most commonly used parts of the UML (Unified Modeling Language), for expressing the Requirements of a new piece of software. But here are their flaws, and some suggestions for improvement:
Too low a logical class: this is shown up in the term “Use Case” itself. “Cases” are instances of things. As a software engineer, you don’t want instances of uses, you want the uses themselves. You may have to start with the cases, to get an understanding of the Use they are cases of, but the Business Analyst should end up with Uses, and not cases of Uses.
Conflates Dynamic, Static, and U.I. models (or, in other words, conflates means and ends): Use-Cases were partly intended to be a solution to the common problem of requirements-documents containing too much premature implementation detail mixed in with the description of what the user is meant to be able to do. But they have not gone far enough. Use-Cases mix in information about the U.I. (e.g., information about picking from lists, viewing error messages, confirming actions, etc.), and they don’t differentiate dynamic (about how the software will execute tasks) from static elements (how it will be organized, OO-style, into classes, properties, methods, and events) of the specification. This leads to kind of “impedance mismatch” when the software engineer tries to translate them into software architecture and programming specifications. Plus, the mixing-in of U.I. leads to a lessening of clarity of the core program logic, and a premature design of the user-interface, as well as, perhaps more often and more serious, the overlooking of much of the U.I., which in web applications can be a considerable percentage of the total code. Leading on from that, it encourages the team to think of the Information Architecture and Visual Design as “hanging out loose”, and leads to problems of integration, of how to easily put the whole thing together.
Obscures the holonarchy of vision, objectives, and goals for the software: the Use-Case model is not well integrated with the overall goals of the application. Yet the Use-Cases are meant to be an expression of what Users do to accomplish those goals. They are the means, whereas the goals and objectives are the ends. What this comes down to is a fundamental misunderstanding about what the Requirements phase of the software development process is. What it is typically thought to be is a “gathering” exercise, a compiling exercise, an exercise of interviewing people and finding out what they want. But it isn’t that. It is a PLANNING exercise. Requirements are really the Activity Plan level of the application, by analogy with a traditional plan. And as such, it is part of the Planning Discipline, which has its own sets of criteria for quality that are well-established, and far more sophisticated than anything you’ll find in the Requirements literature of software development.
If the Requirements phase is not understood as planning, and executed as such, many, many things go wrong: the requirements won’t add up to the goals of the application; the goals of the application will be poorly defined and misunderstood, but people won’t know it, or won’t know to know it; it will be much harder to estimate, plan, and divide up the work than it otherwise would be, resulting in project management problems; the software architecture will be worse, because, just as in an organizational structure of a company, such a structure is a mapping of the purposes of the organization onto its resources, its people. In the case of software architecture, the purposes are the Uses, and the resources are the Classes that accomplish those Uses. The architecture is the mapping of those Uses onto those Classes, using sound criteria for effective classification, organization, and nomenclature.
Too declarative: Use-Cases are intended to be declarative only. But the activity level of any plan is by its nature something closer to a flowchart: it has decisions and branches. In moving away from complex flowcharting of traditional specifications, and via a misapplication of the metaphor of Objects to Actions, Use-Cases make it hard to express the essential conditional dynamic of User Actions.
Unnecessarily Object-Oriented: The purpose of OO is to close the gap between the problem domain and the solution domain, by making the solution domain conceptually closer to the problem domain. The Uses of an application are in the problem domain, and therefore do need any gap-closing done to them. That is, if we use the appropriate conceptual framework, that of Planning. Actions roll up to goals, which roll up to objectives… individual actors work for teams that roll up to supervisors, that roll up to managers, that roll up to the organization as a whole. This is inherently object-oriented already.
To apply the methods of OO to Uses is a weird kind of mind-flip, where we take something that can be inherently expressed in the problem domain, and first suck all of that information out of it by construing Uses as objects, and then, we turn around and wonder how we’re going to put all that information back, and so we try to back-engineer it using OO forms of representation that we use in the solution domain (a domain of program classes, methods, properties, and events). This just makes the requirements unnecessarily complicated and hard to understand. It is a mindless application of the OO metaphor, losing sight of what we’re trying to accomplish.
Gives software-engineers too much of the wrong kind of work to do: Another reason for Use-Cases is to make it easier for the software-engineer to derive classes from the Requirements. The reasoning goes that if the requirements are in OO format, then it’ll be much easier to derive classes from Use objects. But this is not really the case: the domain of Uses is completely orthogonal to the domain of Classes. Uses are part of the dynamic aspect of the system. Classes are part of the static aspect of the system. For example, consider the Use-Case “Activates Credit Card.” The software-engineer is going to see that here we have a Method (”Activate”) of the a Class (”Credit Card”). In normal Use-Case representation, every time there is a case of activating a credit card, you will see a reference to “<includes> Activates Credit Card.” This kind of representation misses the point: the point is to give engineers what they need to write good software, and to do that, the Business Analyst must provide both a dynamic and a static model, because it is too hard to express both in one model. The dynamic model is isomorphic with the domain of human of purposes. The static model is isomorphic with the static OO domain of the implementation. So what this means is that instead of a lot of misguided OO information wasted in the Use-Case model, the BA should provide a static model, a logical representation, of high-level Classes, their methods, properties, and events, and that are needed to accomplish the Uses. The BA then x-references those for the software engineer.
Now the engineer is in the position he wants to be, which is to be able simply understand the requirements and now how they will translate into software. He will be able to see, at a glance, that the task “Activates Credit Card” is invoking the Activate Method of the class Credit Card. This will lead to a much more satisfactory breakdown of labor between BA and engineer, and much clearer, more accurate, more implementable requirements.
It will also, very importantly, provide an easy framework for the specification of the U.I. The U.I. is a mapping between the Uses and this static model. The fields in the U.I. are mapped to classes in the static model. Controller logic can easily be expressed verbally, in terms of transformations and conditions that obtain between receiving Input and writing Output. The resulting Requirements therefore would consist of three models: a Use Model (dynamic), a Class Model (static), and a UI Model (mapping between the two for the sake of user-system collaboration.) This is very close to the MVC framework that the application will actually be implemented in, thus making translation much easier.
Inconvenient to Document & Update: My final criticism of Use Cases is a purely practical one, that, even with CASE tools and their ilk, they are unnecessarily complicated to draw, and unnecessarily cumbersome to update. If they were simply expressed as a textual outline goals and actions, and x-referenced to actors and the appropriate class in the static model, life would be a lot simpler.
