Needed by whom and when
UCJEPS: Needed probably from day one. The following notes should be translated into user stories and prioritized.
Dick Moe says: We currently wand barcodes into accession_id fields
in SMASH. We try never to type accession_ids in.
The trigger on accession_ids checks for duplicates, but does not restrict anything else.
The smasch pages all open with the focus on the accession_id field,
so they are ready for wanding directly.
The wands are settable for appending a character or string to what they scan, so it is possible to
program in a character that will cause the page focus to hop to the next field, if desired.
Outside of smasch we wand ids into text files to provide input for bulk upload scripts.
I presume we'd want something analogous in CS.
We keep track of outgoing loans by wanding into a field one by one (Susan Stone made this).
We don't have now, but it would be useful eventually, to have a loan return check-in
form where returned specimens would be wanded in (with a check made against
the outgoing loan, since it sometimes happens that people mix up loans when they return them).
Andrew Doran says: Not that i have any experience with SMASCH but we would want it to be
wanded into the field and may want for CollectionSpace to check that the
barcode fits our institutional pattern.
Other areas where they would be needed would be when processing a loan. We
would have a loan of say 300 specimens and wand them in.
Also bacodes would be a good way of physically linking specimens mounted
on the same sheet or 'sheet 2 of 3' being a specimen in alcohol.
Overview
We know we will need to build custom reports locally.
Note: Fields that have been renamed in the user interface or added as custom fields need to show up on reports (canned, custom, or ad hoc) with the titles that make sense to the museum user.
Question: For scope clarification, list questions here.
User stories for definition
Please feel to rewrite these or eliminate completely! Then move to the prioritized headings below.
Custom reports: Developer can create a custom report and run it, producing a printed file or PDF that can be given to museum.
Custom reports: Developer can create a simple custom report and add it to the user interface so museum staff can run it themselves. Report requires no input (e.g., acquisitions in last 7 days).
Custom reports: Developer can create a complex custom report (e.g., requires user input to specify a value used in the report) and add it to the user interface so museum staff can run it themselves. Report requires input from user (e.g., acquisitions in last variable number of days).
Custom reports: User can run ad hoc report against their CollectionSpace instance.
Custom reports: User can develop a custom report and save it for later use.
Custom reports: User can develop and save a custom report and share it with other users.
Prioritization of user stories
As definitions and priorities are clarified, the user stories above should be moved into relative order below.
Must have for 1.x-MUSEUM (when they go live in system)
Placeholder for required functionality. As a general rule, functionality that you need and use now should go here or where you have existing data. However, this is up to the museum. We will have to balance requirements against resources and timelines.
Placeholder
MUSEUM could wait six to twelve months
What could wait? These will be re-prioritized at a later date.
Placeholder
MUSEUM would like to have this eventually
These are nice to have but not a near term requirement.
Placeholder