tsJensen

A quest for software excellence...

The Case Against Use Cases

I'm currently working on a rather complex ETL system in the medical industry. There are new business rules uncovered daily as development and analysis proceeds in parallel due to overwhelming business urgencies. The use cases in the system are limited pretty much to "Process File." Everything else is buried in a system of business rules more complex than I care to think about very often and a series of events and event handlers which process the file and implement the business rules.

My own approach to this challenge could have been much more organized had I purchased Karl E. Weigers's book More About Software Requirements earlier on in this project. He says, "Use cases are less valuable for projects involving data warehouses, batch processes, hardware projects with embedded control software, and computationally intensive applications. In these softs of systems, the deep complexity doesn't lie in the user-system interactions. It might be might be worthwhile to identify use cases for such a product, but use case analysis will fall short as a technique for defining all the system's behavior."

I could not agree more. Weigers goes on to recommend the use of event-response tables to provide a way of documenting the requirements of such complex systems which have little if any interaction with users. Granted, you could write a use case using the machine or file system or OS or scheduler or some other non-human entity as the actor, but the analogies break down when trying to document the requirements of the complex rules within the case.

The event-response table is a simple approach to organizing these details that in fact works much better than an ad hoc method of writing it all down in sequential paragraphs and then asking developers, in this case that developer being me, to interpret those requirements and design and code a solution that really works.

You simply need a three column table with the following headers: Event, System State, and Response.

Breaking up functional requirements in a complex rules-driven system with minimal human interaction can be a daunting task. You can make it a bit easier by using some simple organizing structures such as the event-response table.