Total Articles 55
2009.11.20 13:56:12
3473
P R E F A C E
More and more people are writing use cases to describe business processes and the behavioral
requirements for software systems. It all seems easy enough - just write about using the system.
Faced with writing, however, one suddenly asks, "Exactly what am I supposed to write - how
much, how little, what details?" That is a difficult question to answer. The problem is that writing
use cases is fundamentally an exercise in writing prose essays, with all the difficulties in articulating
good that comes with prose writing in general. It is hard enough to say what a good use case
looks like, but we really want to know something harder: how to write them so they will come out
being good.
These pages contain the guidelines I use in writing and in coaching: how a person might think,
what they might observe, to end up with a better use case and use case set.
I include examples of good and bad use cases, plausible ways of writing differently, and best of
all, the good news that a use case need not be best to be useful. Even mediocre use cases are useful,
more useful than many of the competing requirements files being written. So relax, write
something readable, and you will have done your organization a service already.
More and more people are writing use cases to describe business processes and the behavioral
requirements for software systems. It all seems easy enough - just write about using the system.
Faced with writing, however, one suddenly asks, "Exactly what am I supposed to write - how
much, how little, what details?" That is a difficult question to answer. The problem is that writing
use cases is fundamentally an exercise in writing prose essays, with all the difficulties in articulating
good that comes with prose writing in general. It is hard enough to say what a good use case
looks like, but we really want to know something harder: how to write them so they will come out
being good.
These pages contain the guidelines I use in writing and in coaching: how a person might think,
what they might observe, to end up with a better use case and use case set.
I include examples of good and bad use cases, plausible ways of writing differently, and best of
all, the good news that a use case need not be best to be useful. Even mediocre use cases are useful,
more useful than many of the competing requirements files being written. So relax, write
something readable, and you will have done your organization a service already.

 
 




srimon
hatcatal

