Child pages
  • Searching System Requirements
Skip to end of metadata
Go to start of metadata

User requirements

  1. [Must] Each collection can be searched individually, using fields and vocabularies appropriate to the collection.
  2. [Must] The entire holdings of the DLP can be searched collectively, using appropriately generalized fields.
  3. [Must] All holdings of a certain type (textual documents, photographs) can be searched collectively.
  4. [Must] Each collection can be browsed in a manner that is appropriate to the collection.
  5. [Want] All holdings of the the DLP can be browsed in an integrated system.
  6. [Must] All existing search functionality is retained.
  7. [Want] Searching speed is similar to that of the previous system.

Functional requirements

  1. [Must] The searching system can run an indexing process on a single collection.
  2. [Must] The searching system can run an indexing process on the entire repository.
  3. [Must] The process for indexing a single collection can be configured to index arbitrary lists of fields from arbitrary types of metadata.
  4. [Must] The query processing system uses one or more vocabularies/thesauri to map user's query terms to authoritative terms, and automatically expands terms when necessary.
  5. [Must] The query processing system can automatically suggest broader/narrower/related terms for a query.
  6. [Want] The query processing system refers to a separate set of vocabularies/thesauri for each collection.
  7. [May Want] The query processing system stores each vocabulary/thesaurus only once, even if it is used by multiple collections.
  8. [Must] The results rendering system uses collection-specific stylesheets in Fedora to display search results.
  9. [Want] The browsing system automatically tracks terms that are used in the collection, so only useful terms are displayed.
  10. [Want] Changes in the repository automatically trigger an update of the search index.
  11. [Must] The system can search over metadata only, textual contents only, or a combination of both.
  12. [Must] Search by SRU is supported.
  13. [Want] Search by OpenURL is supported.
  14. [Must] There is a common query syntax across all collections.
  15. [Must] The searching system supports multiple languages (and non-Roman alphabets/scripts).
  16. [Must] Each collection (or each language) has its own set of stopwords and stemming rules.
  17. [Must] In federated search, or search across a collection that includes multiple languages, stopwords and stemming rules are handled "properly" (where the meaning of "properly" may be determined by usability tests).
  18. [Must] The user/GUI can designate that query terms apply to specific fields in the objects' metadata.
  19. [Must] All "standard" search operators are supported, including booleans, phrases, and proximity searches.
  20. [May Want] Partial matches (implicit OR) are supported. This wouldn't be the default behavior, as users typically want implicit AND, but may be useful if no matches are found with the initial search.
  21. [Want] There is support for relevance ranking. The measure that introduces the ranking can be generated from an external source (as in the Variations2 search ordering imposed by the V2V system).
  22. [Must] Searching system is easy to configure for a new collection.

Open questions

  1. Can/should the searching system always assume that MODS metadata is available?
  2. Can each item be indexed a single time, with the single index being used for all types of searches?
  3. Are there any needs that are not met by the current searching systems?
  4. Should we add any requirements from the Cushman requirements document at \\bl-ldlp-euterpe\dlp\projects\Cushman\cushmanRequirements.xls?
  • No labels