Oopsla Use Case Panel

At OOPSLA I'm taking part in a panel about use cases, and I'm emailing everyone I know to see for help. Unlike most OOPSLA panels this one is seeking for questions to be submitted in advance, and I'm looking for good questions.I thought Wiki would also be a good place to look, so I'm posting here too.

The format of the panel is that four "gurus" (Ivar Jacobson, Alistair Cockburn, Ian Graham, and Bruce Anderson) will answer and debate various questions on use cases. I expect to cover 8-9 questions during the panel, so that each question will get a good discussion and get into some depth.

Are there any good questions that you feel would make good topics for the panel? It could be a question that you have, or that your colleagues or clients have. It should expose some of the variations and similarities between the panelists approaches.

Please let me know with an email <fowler@acm.org>. You can also post the question here and we can have a pre-panel discussion on what the big questions are about use cases.

--MartinFowler

How do you know you have enough use cases? too many?

When do you start doing something other than collecting use cases?

How much detail should a use case have before it is done?

What do you do if you start getting into too much detail? How do you capture that valuable information in another form and keep going?

When, if ever, should detailed use cases be broken down into multiple use cases?

How should use cases be organized for presentation, discussion, implementation?

Who do you talk to to get the use cases?

Who should write the use cases?

What tools are necessary to support use cases?

How do use cases get linked to the rest of development?

Can use cases be used for non-oo projects?

Use Case descriptions tend to be informal. Should there be more formal Use Case definitions that are derived from the informal ones? What should the relationship be between Use Case descriptions and other requirements artifacts?

What should the relationship be between the artifacts in a Use Case description and the artifacts in a description of a design that implements the Use Case?

Some Use Case detractors claim that they lead to functional decomposition in the wrong hands. Is this true, and if so, how can it be avoided?

How do Use Cases impact the physical architecture of a system? The packaging, modules, etc.,. Is there always an impact?

If users participate in the development of Use Cases, how do they find the notation and concepts? Are they easy to work with?

For Ivar: If you had it all to do over again, would you still have used "extension" and "uses" as the the fundamental relationships among Use Cases?

Wow - a good lot of questions there. I'd be interested in the community's ideas on what the most interesting questions would be. That'll help me select good questions for the panel.

Also the questions are anonymous. If you are going to OOPSLA and would like to ask a question in the panel please let me know.

--MartinFowler