The following is a brief description of my journey with Use Cases. I hope it helps in some way.

I was first introduced to Use Cases several years ago. I was given the responsibility to take a collection of requirements, written in a use case like style, and make some sense out of them. This project was a medium sized development project with a team of about 8 developers. I had never written a Use Case before and the Use Case methodology was really quite young at the time. I spent some time reading through the literature of the day and had trouble really understanding exactly what a Use Case was, and how to apply it to the mass of requirements I was given. Every time I tried to apply what I learned to the problem domain, I would come out scratching my head with issues like:

1-How do I capture what happens when things go wrong and how do I manage the proliferation of Use Cases and the various error condition scenarios

2-Every time I started to write a use case, I would oscillate between cases that were either very high level/general issues or very low level and detailed. They were related but I could not seem to group them together in proper use cases.

3-How do I capture some important but very detailed performance requirements

4-How can I organize the use cases and ensure the they are consistently written both in content and presentation if various people were responsible for their creation.

I was getting increasingly frustrated with the literature out there and how simple it made everything seem. The examples were so basic and clean that it made it all seem so easy. When ever I would think, "Now I get it" I would get back to my material and get lost again.

The more time I spent realizing what all the real issues with use case construction were, the more sense one particular article I read made. The article was called , "Structuring Use Cases with Goals". by Alistair Cockburn of Humans and Technology. I must admit that when I first read it I didn't understand it. He seemed to be making something very complex out of the seemingly simple concept of Use Cases. It did not take long to realize that real world Use Cases required a real world solution and that is what Alistair offered in his article.

"Structuring Use Cases with Goals" offered me a solution to the first two of the above four issues. It solves issue 2 above since it talks about the hierarchical nature and scope of use cases and also for issue 1 above since it goes into great detail on dealing with "Extension" Use Cases. So, I decided that I would structure my Use Cases around Alistair's paper. I contacted Alistair, via e-mail, with a few questions and he was gracious enough to e-mentor me on applying his technique.

As I stated going through the requirements and "building" the use cases, I would e-mail Alistair with questions and we would dialog on various concepts and issues. It was very instructional to me. If interested, the transcripts of that dialog are on Alistair's web site (here) (unfortunately some of the links on Alistair's site are broken, if you want this info, e-mail mail me and I will send it to you).

Once I got the hang of writing use cases, I needed to boil it down to the basics and teach it to one of the people on the team so we could both write the use cases. Here is a summary of the use case concepts that I generated: Use Case Basics. (Also available on Alistair Site here).

So, I now had the first two issues solved. But how about managing all the detailed requirements such as "It must not take longer than x milliseconds to do such and such" or "The System must be capable of handling 100 to 500 thousand records". Much of the literature of the time suggested that these requirements be encapsulated in the use cases in various ways, that All requirements can be captured in Use Cases and no other means of capturing requirements is needed. I didn't like that for two reasons. The first being that it seems artificial in a sense. The Use Cases were describing, in user terms, how the system should operate, injecting these core requirements into the system sometimes was easy, for example

"The User enters his ID and his order is presented (should take no more than x ms)."

But to add that the system should handle x thousands of user records seemed out of place. The user in this case could care less about the capacity of the system. In addition, if a developer were to try to find this requirement, it would not be obvious where to look. This leads me to the second reason I didn't want to embed all core/performance requirements in the uses cases...it was too foreign for our organization. Use cases were totally new to them (and Me). My company was used to top down, water fall type of projects with traditional requirements/design documents. They didn't really know what to do with Use Cases. They needed to feel confident that we captured all the requirements and did not have the patience to read through all the use cases (over 70 at this point).

I picked up a copy of Texels book "Use Cases combined with Booch OMT UML" He suggested that use cases were great but not the end all of requirements capture. He suggested that a traditional requirements trace matrix was just the thing to augment use cases. This seemed to be just what I needed. It gave us a place to capture the core/performance requirements as well as a more traditional approach that others in the organization could relate to. Basically we just categorized the requirements and within each requirement we listed the requirements as they were captured, very brief, very specific, no mention of how they system would be used. Just basic performance requirements and simple requirements like "Communication between component A and B need to take place via direct Network connection or via dial-up connection".

This list or matrix of requirements allowed the rest of the organization to quickly read through them and feel confident that we at least knew what the system had to do. If they wanted to know how, they could dig through the use cases. This also served as a good sanity check as development went on. A quick read through the matrix allowed new people on the project to familiarize themselves with the gamut or requirements for the entire project without, again, the detail of how. A quick read through also helped us to keep our eyes on the key performance requirements which sometimes could just get lost.

We went one step more and tied the requirements to the use cases. For each requirement, one or more use cases were specified that satisfied these requirements This served as a first cut means by which we verified that we had captured all the Use Cases needed. Once all requirements had use cases that satisfied them we knew we had our minimum set of use cases.

So, now I had the methodology. The only missing piece was issue 4, how to manage all this information. There are plenty of great use case templates that can be used in which accounted for not much more than using wordpad...a blank sheet of paper. With several people writing the use cases, starting with a blank sheet would have resulted in misc. styles and varying emphasis. Ultimately I ended up making a multi user Access database to enter use cases and manage all the use cases and their hierarchy. Access worked great because it allow us to link the use cases to the requirement trace matrix (also an access database) and generate great reports.

Well, that is my story. I hope it has helped in some way. If you have any questions, please feel free to contact me.