Writing good use cases.... what not to do.....

previous installment in this series is part 1

What I think as good use cases.

To be able to write a good use case, we should first know about what not to do. If we avoid these pitfalls, it should not be hard at all to write good use cases.

The TOP 5 use case killers according to Gary K. Evans and William F. Nazzaro are

1. CRUD based use case partitioning
2. Design by use case
3. Actor mis-classification
4. Use Cases for all requirements
5. Use Case normalization

I agree somewhat with the authors. I agree with the causes, but have some reservations about the reasons they present. I will explain what they mean (these points are from their presentation in 2002, but I would explain it in my own way) and then add my own points.

CRUD based use case partitioning

CRUD stands for Create Retrieve Update Delete. We can partition a use case using these database actions. This seems like a very efficient way. And congratulations, you have a technical document, not a use case. The moment you say CRUD, your use case probably has more use for a technical team rather than a business user. And automatically when you partition use cases using CRUD, interaction with database has to be outlined and it does not stop there.

Step back.... look at the big picture...

We are creating a use case for the business user to get an approval of our understanding of the requirements. We are also using the use case to get a very high level LOE (Level Of Effort) from the tech team. The LOE is not binding, at least not yet. This LOE and use cases allow the business user to calculate ROI and gives him a chance to evaluate the project. This also helps to manage the business user's expectations. This also gives the user a chance to call off the project which might reduce the number of failing software projects.

Trust me, when I say over 80% of the projects fail. I could probably give you a lot of references for it, but I will leave the burden to you. Just "googling" should give you some.

Why should we not use CRUD based partitioning

• Although we would achieve discrete partitioning of use cases, it is may not signify discrete business transactions.
• These use cases explain acquiring and processing of data but do not capture the business processes
• You end up with a huge number of use cases doing too little.

So while writing a use case, we need to think like business users and should put the technological background to the backseat. It will not stay in the backseat for long, because Business Requirements and Technical Specifications wouldn't let them stay there for too long. Use Cases ARE NOT technical documents.

I would discuss about the remaining use case killers in future installments.