Still using outdated use case models?

“When a subject becomes totally obsolete we make it a required course.”

-  Peter Drucker

Why do some people persist in using outmoded expressions in software development?  It is particularly vexing when the organization claims to be agile development shop.  The reasons run from Machiavellian resistance to simple ignorance, but the impact is the same.  They weigh down your agile efforts.  The subject of use case models arose recently.  Using use case models for agile development is rather like putting wooden wheels on a nimble, electric car.  It will defeat the purpose!

Gathering early feedback is crucial to any software development project.  It is one of the basic premises of agile.  Without it you will never meet the expectations of the stakeholders.  Users hate reading voluminous pages of text-only specifications.  Anyone, who has worked with users, knows that a picture is worth a thousand words.

Before dismissing a use case model, let me define it.  A Use Case Model was traditionally used to describe the proposed functionality of a new system.  It is a graphical model that can be composed of multiple instances each representing a discrete unit of interaction between actors (not necessarily human) and the proposed system.  Each interaction is meaningful in business terms. 

Here is a very simple example:

As you can see, this is a simple example of an online purchase.  This example depicts workflow which is often not done in use case models.  I added this, in order to not disadvantage the use case model unfairly in comparison.   Use case models tell us how the user interacts with the application? Technical people like developers and testers like use case models.  To most users, they do not provide sufficient expression for them to visualize the solution.

Wireframes (also referred to as prototypes or mock-ups) on the other hand, go a step further.  They capture how screens of the software system will or could look.  This technique coves everything from “back of the napkin drawings” (yes I have used and implemented these) to sophisticated products that provide either the exact presentation of the proposed screens or a very close representation.   Wireframes not only tell us how the user will interact with the application, but also what elements will be displayed in the user interface, how the elements be organized and how the interface will work.

The following is a simple wireframe example of the previous use case model:

Notice the huge difference in the amount of information that is being communicated?  Wireframes are actually the most effective communication tool for everyone involved in the development process.  Furthermore, the wireframe represents a picture that is concrete enough for a user or stakeholder to wrap their head around.  Users gain a better understanding of the potential solution.  They can see early on whether it adequately addresses their needs.  Scrum masters use wireframes to ensure product owners and sponsors are on the same page with the development team.  Designers use wireframes to explore look and feel possibilities.  Developers use them to gain understanding about the functionality.

So why would you bother to take an interim step and create a use case model?  The answer I receive from specification purists most often is the use case models depict the solution independent of technology.  My response is, “So what!  Why is that a good thing?”  In this age of technology driven, rapidly developed and deployed solutions, you don’t have time to languish over requirements and then pick a technology to deploy them in since it changes so much from the start of the project.  Often technology, in its own right, now sparks new solution possibilities. 

The bottom line is, you cannot afford interleaving steps in developing your requirements that do not produce uniquely valid information for ALL parties.  You have to be as lean[1] with your documentation as you are agile with your development.   So drop your use case models in the obsolete waste basket and move on to wireframing.  You’ll not only save time, but have happier users.

[1] Pun intended.