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. For an example, consider an app for tracking library loan records. Some use cases are: borrow books, borrow magazines, return books, return magazines, renew books, renew magazines, pay fines, get library card, and change address.
The Problem with Doing Use Cases First
It’s a lot of work to prepare use cases. The business staff must carefully explain the desired functionality and the 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. There is no attempt to determine overlaps and contradictions among the use cases. There is no effort to adjust concepts so that they better meet future needs. Rather use cases provide just a rote recording of the 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 should apply their intellect and analyze the imperfect requirements of the user to determine their true needs.
Consider that most apps are information systems that manage data. The orthodoxy is to first prepare use cases and only afterwards address data. 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 agreed-upon names and definitions. Use cases are being 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. Then business users get their desired functionality. The 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 the IT staff to step back and reflect upon the concepts elicited by the use cases. For example, in our library loan example, book and magazine can be replaced by the more general term of library item. The introduction of a library item 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; there is feedback back and forth.
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 how they 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.
See my YouTube videos for a demo that gives the flavor of agile data modeling