Use Case First Approach is an Inferior Way to Build Software

In this special guest feature,  Dr. Michael Blaha from Modelsoft Consulting Group writes about how it is better to address functionality and data together when developing software. Michael Blaha is a consultant and trainer who specializes in conceiving, architecting, modeling, designing and tuning databases. He has worked with dozens of organizations around the world. Blaha has authored seven U.S. patents, many articles and seven books, the most recent of which is the “UML Database Modeling Workbook.” He received his doctorate from Washington University in St. Louis, and is an alumnus of GE Global Research in Schenectady, New York.

A use case is a piece of functionality that an app can perform. Each app has many use cases, and the use cases taken collectively specify the app’s functionality. Consider an app for tracking library loan records, for example. Some use cases for this app are: borrowing, returning and renewing books and magazines; paying fines; getting a library card; and changing address.

The problem with doing use cases first

It’s a lot of work to prepare use cases. Business staff must carefully explain the desired functionality, and IT staff must systematically record these thoughts. This effort being devoted to use cases is misplaced.

With use cases there is little attention to reflection, and no attempt to determine overlaps and contradictions. There is no effort to adjust concepts so that they better meet future needs. Consequently, use cases provide just a rote recording of business dialog.

Something is wrong with this picture.

The job of the IT person is not to be an automaton and produce literal code. Rather, IT staff members should apply their intellect, analyzing the users’ imperfect requirements to determine their true needs.

Most apps are information systems that manage data. The orthodoxy is to prepare use cases first and address data second. However, it makes no sense to specify functionality alone without data. The model of data provides the nouns – the domain of discourse – to which the use cases should refer. Often, IT staff are creating use cases that involve concepts without agreeing upon names and definitions. As such, use cases are often constructed without understanding the totality of data.

The bottom line is that use cases have been badly overhyped. The use case first approach is an inferior way to build software.

Use cases and data modeling in tandem

A better approach to developing apps is to address functionality and data together. This way, business users get their desired functionality, and IT staff gets a robust infrastructure that supports current business needs and has flexibility for the future.

The business staff prepares use cases based on data modeling concepts. The IT staff prepares a data model seeded with use case ideas. The use cases provide grist for constructing the data model and test needed access paths.

A data model helps IT staff to step back and reflect upon concepts elicited by the use cases. For example, in our library loan example, “books and magazines” can be replaced by the more general term of “library items.” The introduction of library items increases future flexibility in that it can also encompass movies and audio CDs. The notion of a library item can be fed back to the use cases to sharpen their specification. As you can see, construction of use cases and the data model should occur in tandem; that way, there is feedback between the two.

My approach

I have further refined my software development process with agile data modeling. I schedule data modeling sessions with stakeholders (business staff, IT staff and line management) all in the same room. As the participants explain their needs and articulate use cases, I listen to what they say and construct the data model in real time. This lets business users see that their use cases are being understood, and helps them realize how their use cases manifest in the data infrastructure that will enable functionality.

The evolving data model provides terminology for specifying use cases. And the use cases exercise the data model revealing flaws and missing content. In my sessions, I only record difficult use cases, as most are simple and implicit in the data model. If a customer wants to record additional use cases, then one of the participants can serve as a scribe.

For more information, see Michael’s video series for a flavor of agile data modeling.

Sign up for the free insideBIGDATA newsletter.