[OPEN-ILS-DEV] acq timeline

[Dan Scott]

On 04/09/07, Ed Summers <ehs at pobox.com> wrote:
> At this point I am more interested in seeing a set of stories or use
> cases for how the acq module under design is going to be used, and
> letting the requirements fall out from them. We could start with a
> simple description of what a user will do when creating a Purchase
> Order. I guess this is something I can take a stab at on the wiki
> before the next telecon? If this has already been done and I've
> forgotten to read yet another document please let me know :-)
>
> Does this fit the EG development process? How was system functionality
> divined earlier in EG design? Personally I'm a fan of light weight
> process, not trying to figure out the full dimensions of the system in
> advance, but working with what is known *now* and releasing
> early/often to the people that matter to get feedback asap. Agile
> rah-rah...

Ed:

Well, on "what is known *now*", I thought someone had mentioned a lack
of knowledge about how acquisitions and serials work in libraries
today, and the expectations for what they should be able to achieve.
The point of the problem scenarios are to capture that knowledge about
how things work in systems (people, paper, and computers) today (along
with the domain terminology, etc) and facilitate communication amongst
developers ("So, Ed, will Hazel still get the information she needs?")

The next logical step is to write up how the same goal (creating a
purchase order, in this example) could be accomplished with the new
system. I think those are called interactive design scenarios, but
maybe we call them use cases instead?

Yes, lightweight, agile, blah blah... but if you're staring at code
without knowing what people want from the system, it seems that it
could be pretty frustrating. If you don't think that the problem
scenarios will be helpful in understanding the problem domain, it's
easy for me _not_ to write them :)

-- 
Dan Scott
Laurentian University