Re: use case <<include>> vs. <<generalize>>

I would start with a single use case, "Process File", with 3 scenarios,
and see if that works. The approach follows the "do the simplest thing
that can possibly work" philosophy.

Keep in mind that a use case is nothing but a requirements document.
What do you gain by splitting the use case into multiple parts? Who's
the intended audience? Which approach do you think would be the easiest
to follow? Will it be easier to jump between multiple documents, or
have everything grouped together in a single document?

IMHO, focusing on producing the world's greatest, most complicated use
case model distracts one from the real goal: capturing clear
requirements that one can then turn into working software. In fact, one
might argue whether use cases are appropriate for such trivial
functions. User Stories might be preferable.

Mark

idob@xxxxxxxxxxxx wrote:
Hi I would like to have your opinion about the following:

I design the use case "Process File".

There are 3 situations of processing the file:
- scan and process
- browse and process
- get mail attachment and process.

What is the best way to describe it in use case model?:

- Use case "Process", in the uc, script with 3 options?
or
- Three use cases: "scan file" "browse" "mail" with <<include>>
relation to 4th use case "Process"?
or
- One use case "Process", with <<generalize>> relation to the 3 use
cases "scan","browse","mail"?

Thank you.

.