Re: Use Cases - question about the process

["Henning Sprang" <henning_sprang gmx de>]

Hy,

On Sun, Feb 2004, Tim Janik wrote:
> [...]
> > * how should a use case be documented? What questions must the
> > information therein answer? maybe write these rules down here, so it's
> > more clear what is the way we describe our things on this page
> 
> you could try googeling on the issue or simply read up in literature
> on use cases. basically a use case is a short description of valid
> tasks, people should be able to accomplish with a program.

I'm on it and put some links on the UseCases page...

> [...]
>
> > * if i have a UseCase, do i have everything documented that is needed to
> > start writing the code that makes it happen?
> 
> no, not at all. based on the use case, you can try to produce GUI mockups,
> reflecting what you think program interaction may look like to accomplish
> the task at hand. at that point, someone familliar with the overall
> structure of the program (e.g. me) will have to judge how viable a
> mockup/implementation is, what's required on the GUI side (BEAST) to
> realize
> ideas from teh mockup and what functionality of the model is missing (BSE)
> to implement the scenario.
> 
> > * what is the difference between a requirements document, a use case
> 
> a requirements document is usually a bullet
> list of items a program has to fullfill when handed over to the
> customer. we don't have any such relationship and not a formal
> requirements document either.
> 
> > collection and a "storyboard" for sequences of actions users want/need
> > to perform to accomplish their tasks?
> 
> to contrast a story board from a use case, the board more focusses on a
> specific task for a specific user. it then describes the sequence of
> actions necessary for the user to get the task accomplished. this can be
> accompanied by small pictures actually showing the user do things.
> the main purpose of a story board is to get potentiall computer-illiterate
> customers (or employees of a customer) familliar with the plans of the
> programmers and to figure whether the program correctly fits into the
> normal workflow.
> 

So, to get everything a bit ordered we might have or need to build  a chain
that looks like this:

- reuirement/feature (request, if not already implemented)
- UseCase
- story board
- GUI mockup
- implementation plan

got it right?

I think we should do that from the ground up, so everything fits nicely
together, because all of them depend on each other.

Henning