On 30/08/07, Bill Erickson <[EMAIL PROTECTED]> 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
