[OPEN-ILS-DEV] acq timeline

[Dan Scott]

On 30/08/07, Bill Erickson <erickson at esilibrary.com> wrote:
> I've started a wiki page at
> http://open-ils.org/dokuwiki/doku.php?id=acq:timeline
>
> This is just a skeleton of notes taken from the Acqfest earlier this summer.
>
>
> We have a very large, amorphous set of requirements submitted from different
> organizations.  Ideally, the process of defining, de-duplicating,
> organizing, and prioritizing these requirements would be a community
> process.   Whoever is involved with the initial rounds of this process,
> however, needs to have a decent understanding of ACQ/SER terminoligy and
> workflow to make sense of the free-form documentation.
>
> I'm thinking the data needs several passes:
>
> 1. de duplicate
> 2. organize into functional areas and dependencies
> 3. vote on necessity of requirements
> 4. draw lines in the sand defining which release each block of requirements
> is part of
>
> I would like to open the floor for suggestions on the best way to get people
> involved and the best way to manage this process.
>
> -bill

Hi Bill:

What I would propose (landing somewhere between steps 1 and 2 of your
proposal) is that interested parties with a decent understanding of
ACQ/SER contribute written scenarios that cover the core tasks that an
ACQ/SER system needs to support. A scenario is an end-to-end
description of a particular use case from the user perspective that
acts as a means of sharing understanding and terminology about the
desired problem area and the complex interactions between various
actors in the overall system. (See
http://ldt.stanford.edu/~gimiller/Scenario-Based/scenarioIndex2.htm
for a graphical overview of scenario-based design - although I think
capturing "Problem scenarios" and generating proposed "Evergreen
scenarios" might be enough for our purposes; see also
http://www.island-resort.com/scenario.html for a short textual
description).

In essence, I really like the "abstract -> concrete" shift in
requirements description that scenarios (theoretically) help provide.

Given a good set of scenario artifacts, we almost automatically
accomplish (1) (deduping) and could then derive the requirements for
the functional design (2) of the system. Once the dependencies are
clear, that should provide a suggested path for progressing with the
implementation (e.g. if we determine that generating a purchase order
requires the ordering person to have access to vendor contact
information such as address, telephone, email address, and that
serials claiming also requires the claimer to have access to vendor
contact information, then a vendor contact information table will
probably be a prereq for supporting those tasks).

So that's a lot of blather about process, but I'll also put my money
where my mouth is by contributing some problem scenarios based on the
workflows we use at Laurentian University. Tonight, hopefully.

-- 
Dan Scott
Laurentian University