requirements

system must be able to ingest data
  from a variety of sources, including
    data from partner sites not under MHS control
    data from databases
      that adhere to well defined standards, including
        OAI (desirable)
        EAD (desirable)
        EAC (desirable)
        MARC (desirable)
        DC (desirable)
      and also some that don't adhere to common standards, such as our own "nominal indexes" that hold records about people's names, births, and deaths
    data from websites
      the ability to parse certain pages from the web, like those containing directory information (desirable)
    data from documents
      spreadsheets (desirable)
      PDF
      text documents
      photos (desirable)
      multi-media (desirable)
      XML (desirable)
    support data from feeds (desirable)
  from individuals leaving commentary about items in the system (desirable)
    which would be persistently linked to those items even as the system is updated and reindexed (desirable)
users must be able to query the system
  using full-text searching techniques familiar from experience with Google (describe)
  using fielded techniques critical to searching our nominal indexes (such as birth and death records) (describe)
    results from fielded searches should be sortable by these fields as well
  with the ability to further refine searches by searching again within the result set (desirable)
  results should include navigable facets for refining searches (desirable)
  results must be returned quickly
    no page refresh should take longer than 2 seconds (desirable)
  system should be able to incorporate data from federated searches (searches executed on other remote engines)
    should support the federated z39.50 standard (desirable)
  system should be able to save search queries for the user
system must present results comprehensible to the user
  any single query will return results from a variety of data sources that tell alternative stories to the user, describe how the system would put clear enough boundaries around each of these stories so that the user could choose where to focus for best success (describe)
    for example, the system how would the system sense the context in which the users is searching, and present results appropriate to that contexts, including (describe)
      people finder searches
      history finder searches (desirable)
      place finder searches (desirable)
      site searches
  when appropriate, the system should provide direct viewing of objects in the result set (desirable)
    for example, images should be presented as thumbnails rather than just lists of titles (desirable)
  partners should be able to view results in a view that is "skinned" with their organizational identity
the system should be able to provide web services
  site maps should be available for crawlers (desirable)
  a search API for web developers (desirable)
    provide "raw" results (minus HTML niceties) (desirable)
      XML results (desirable)
      JSON results (desirable)
  the system must be easily integrated into the web ecosystem
    for example, queries should be expressed in the URL so they can be easily turned into deep links on other sites
describe the tools the system would provide (describe)
  for managing workflow tasks
    updating harvest schedules
    testing changes in a test system
    building and modifying filters for different data types
    building and modifying crosswalks for fielded data
  the system should allow partners to initiate certain changes (describe)
    how would partners change the schedule
    how would partners modify the skin used to present results in 3.3
    how would partners suggest modifications in the mapping of their data
system management information must be available to administrators and partners
  site and query statistics
  harvest schedule (desirable)
the system must provide documentation and assistance for administrators and partners
  where would guidelines for data formats be found (describe)
    non-standard data would need particularly clear definitions, where would those be housed (describe)
  where would API documentation be found (describe)
  where would we place documentation for partners (describe)
the system must be sustainable
  describe the costs of maintaining the system (describe)
  describe the maintenance tasks involved in running the system (describe)
    how often are upgrades made available, how hard are they to install (describe)
    how easily can the system be enhanced (describe)
      content
        workflow for content updates (described)
        how much downtime is involved in re-indexing portions of the collection (describe)
        how long would a complete re-indexing take and what circumstances might require this step (describe)
      what would be required to add a new resource into the system (describe)
      what would be required to accommodate evolving standards (describe)
  what support is available for the system (describe)
    professional support (describe)
    user community forums and other gathering spots (describe)
  how open is the architecture of the system (describe)
    under what licenses are components of the system distributed (describe)
    what restrictions would inhibit our sharing the system with partners (describe)