Use Case Statements

Most dis-astisfied customers I encounter are a result of missed expectations and not failed technology.  On the one hand, this is caused by the customer’s own inability to clearly articulate their own needs.  On the other hand, I can never blame the customer as it is my job to help themclearly define their needs, desires, and expectations.

I have spent a considerable amount of time experimenting with ways to help the customer express their needs.  I have tried technical questionnaires, UML, business process languages, and use cases.   All process have their pros and cons and I often find myself using multiple methods.   But for the act of creating a baseline design — I have found use case statements the most effective.

Use case statements are easy to learn.  They can be written in a spoken language.  But the same cannot be said for UML and other languages.  Indeed, when I introduce use cases, even the non-techinical customers become actively involved in designing their systems .  This immediate participation is essential for capturing the excitement that often exists at the beginning of an initiative but quickly disappears.  The final advantage is that the finished document(s) can be shared with everyone not just the people who understand IDEF, UML, or whichever modelling/description standard is used.  

My prefence for use case statements does not omit the other methods.  On the contrary, I still produce UML diagrams and other content but I prepare these for a more technical audience.  I rely on the use case as the starting point for all other design doccumentation.  In turn, I act as a translator between the business and the technical entities.  

Probably the best book I have found on use case statement can be found here

This book is all one would really ever need.  In fact, if it were in my budget, I would hand this book out to all project team members at the beginning of an engagement.

One final note, the key is to remain flexible and not get trapped in a situation where you write too many use case statements.  I guarntee that no one will read a binder full of them– so don’t write too many.  Keep it simple and perhaps you will begin to like use cases as much as I.