I am fond of System Use Cases as a tool for documenting functional requirements, but I am not a big fan of use case specifications.
I find the textual specifications result in the kind of weighty documents that everyone hates reviewing and I continue to be amazed that so many analysts start documenting a SUC by writing out a textual specification instead of modelling visually.
Indeed, there are still some analysts who don’t bother to produce a visual model of the SUCs at all!
People relate better to pictures than they do to text, that is why the Rational Unified Process tells us to model visually.
Those who are not familiar with SUCs do need to be taught how to read an Activity Diagram, but take a look at this SUC specification and then at the corresponding Activity Diagram and tell me which you think is easier to follow. Now imagine a much more complex use case.
My approach is to dispose of the textual description of the paths altogether, since it says nothing that is not said more concisely and more clearly in the diagram, and to move the “Characteristic Information” section into the diagram itself. The result is a set of SUCs that are easier and quicker to review.
You will notice that in neither the specification nor the diagram do I provide details of the business rules or data requirements. I will explain why in a later post.
Kind regards,
Declan Chellar
Related Posts
Great stuff, Declan. Visual modelling is so powerful, it’s a shame that people retain their attachment to voluminous text specifications. It’s interesting to note that the use of visual modelling is becoming popular in the realm of business planning also – see http://bmdesigner.com
Thanks for the link, Paraic. It looks interesting and I will have a good delve into it shortly.
Good thoughts here. I think good specifications start with considering the audience and what they need to get their job done. Often that’s a combination of visual models in the form of rough UI sketches, activity diagrams to illustrate essential workflows, use cases that model true user-valued goals, and sufficient requirements to document what business rules apply. I’m not a huge fan of use case diagrams because the content is pretty low, but they can help to set context. UML models are great if you and your developers know how to work with ’em. The objective is to communicate, not to generate a bunch of stuff that no one will read. Write for your audience, not your ego.
Ron, I agree wholeheartedly that you should write for your audience.
As for use case diagrams, I find they can be useful in giving a quick overview of the functional scope of the project. Hmmm… I think I just paraphrased what you said.