Requirements List - 2003-07-23 (Revision 1)
===========================================

1. Functional Requirements
--------------------------

FR.SYS.1 The system shall provide the following functions:

1.1  Ingest --------- ING - Recieve and store holdings
1.2  Validate ------- VAL - Validate holdings
1.3  Track ---------- TRK - Track the status of holdings
1.4  Search --------- SCH - Find holdings
1.5  View ----------- VIE - View holdings
1.6  Retrieve ------- RET - Get holdings
1.7  Geometry ------- GEO - Get and use geometric information about holdings
1.8  Correlate ------ COR - Correlate holdings with each other
1.9  Process -------- PRC - Run processes on holdings
1.10 Transfer ------- TRN - Transfer holdings to other systems or media
1.11 Subscribe ------ SUB - Subscribe to notification services 
1.12 Administer ----- ADM - Monitor and update the state of the system

Note that a "holding" is defined as any object held in the system
that is searchable and retrievable.
      
Note also that there are no Distribution or Archive functions because
these are accomplished through combinations of more basic functions.
Distribution is accomplished through a combination of the  View, Search,
Retrieve, Transfer, and Subscribe functions. Data archiving is performed
through the Transfer function, where data are tranferred to long-term 
media and the NSSDC.

1.1 Ingest Requirements
-----------------------

FR.ING.1 [The ingest function] shall provide an online mechanism
for delivering data to the PDS (CN).

FR.ING.2 [The ingest function] shall provide a mechanism for 
delivering data to the PDS on physical media (CN).

FR.ING.3 [The ingest function] shall provide a mechanism for
submitting data set catalog information through catalog files 
that are part of the data delivery (CN).

FR.ING.4 [The ingest function] shall provide an online mechanism 
for submitting data set catalog information, independent of data
delivery (CN, xCR.18.2 and xCR.18.5 - p12).

FR.ING.5 [The ingest function] shall provide an online mechanism 
for submitting changes to the Planetary Science Data Dictionary 
(PSDD), independent of data delivery (CN).

FR.ING.6 [The ingest function] shall provide an online mechanism
for creating and updating local data dictionaries, independent of 
data delivery (OO.1.4, xCR.8.26 - p41).

FR.ING.7 [The ingest function] shall automatically store all data 
delivered to the PDS in an accessible online or nearline repository
(xCR.13.17 - p18).

FR.ING.8 [The ingest function] shall automatically build/update
online data set and product catalogs when new data are delivered
to the PDS (CN).

FR.ING.9 [The ingest function] shall automatically build/update
a default web interface to the data when new data are delivered
to the PDS (xCR.16.2, xCR.8.27 - p30).

FR.ING.10 [The ingest function] shall provide an online mechanism
for updating product catalogs with new or corrected metadata, for
example, when better geometry information becomes available. 
(FR.1.1.2, xCR.18.50.6 - p14 and xCR.8.17 - p15).

FR.ING.11 [The ingest function] shall provide an online mechanism 
for describing resources to the system, adding new resources, and linking
to those resources (xCR.1.3.2 - p35).

FR.ING.12 [The ingest function] shall provide an online mechanism
for associating data and ancillary products with each other and
defining new collections of products (Anne).

1.2 Validate Requirements
-------------------------

FR.VAL.1 [The validation function] shall provide a suite of archive
production tools to help data submitters create PDS-compliant data
releases (FR.1.1.2, xCR.114.2.17 - p10).

FR.VAL.2 The archive production tool suite shall provide the 
following capabilities (FR.1.1.2, xCR.114.2.17 - p10):

  1. Generate index tables from a set of product labels
  2. Generate labels for index tables
  3. Generate catalog files from online catalog information

FR.VAL.3 [The validation function] shall provide a suite of 
validation tools to determine the PDS standards compliance of
every data release (xCR.13.30 - p41, xCR.13.50.5 - p41, FR.1.1.2,
xCR.18.50.4, OO.1.6, xCR.18.3 - p43, xCR.8.10 - p44).

FR.VAL.4 The validation tool suite shall provide the following tests 
(CN, FR.1.1.2, xCR.18.50.4, OO.1.6, xCR.18.3 - p43, xCR.8.10 - p44):

  1. Check that required directories and files are present
  2. Check that every file is pointed to by a PDS label
  3. Check every label for the following:
     A. Valid syntax.
     B. Valid metadata (i.e., all metadata is in the data dictionary)
     C. Correct pointing to one or more files.
     D. Correct description of file properties (e.g., RECORD_BYTES)
  4. Check that ASCII files are properly formed
  5. Check that the index tables are properly formed and correctly
     point to online data
  6. Check catalog files are properly formed and match information
     contained in the data set catalog
  7. Ensure that updated catalog files can be ingested without 
     violating the referential integrity of the data set catalog

FR.VAL.5 [The validation function] shall provide a mechanism to 
augment the validation tool suite with additional tests, for 
example those designed for a particular mission, data set, or 
data type (CN).

FR.VAL.6 [The validate function] shall provide a mechanism for
running the validation tests automatically on a data delivery,
with one of the following results (CN, FR.1.1.2, xCR.18.50.4, 
OO.1.6, xCR.18.3 - p43, xCR.8.10 - p44):

  1. All the tests run successfully, and the data delivery is
     deemed valid, and a summary report is generated.
     
  2. One or more of the tests failed, the data delivery is deemed
     not valid, and a detailed report is generated.
     
FR.VAL.7 [The validate function] shall provide an online mechanism
for running the validation tests interactively from a location
remote from the data (CN).
  

1.3 Track Requirements
----------------------

FR.TRK.1 [The track function] shall keep a record of the status 
and location of every data release as it progresses through the
following phases of mission archive production (CN):

  1. Production
  2. Transfer (i.e., delivery)
  3. Validation
  4. Distribution
  5. Reprocessing
  6. Preservation

FR.TRK.2 [The track function] shall keep a record of the following
properties of every data release (CN, Cassini Tracker, xCR.10.10 - 
p34, xCR.10.2 - p34, xCR.4.1.9 - p35, xCR.10.4 - p34, FR.1.2.6, 
xCR.10.1 - p34, and xCR.10.5 - p35):

  1.  Data Set ID
  2.  Release ID
  3.  Release version ID
  4.  Release description
  5.  Online location (URL)
  6.  Data provider (i.e., instrument team)
  7.  Data distributor (i.e., PDS data or discipline node)
  8.  Release phase (e.g., production, transfer, etc.)
  9.  Expected date of delivery to the PDS
  10. Actual date of delivery to the PDS
  11. Expected date the release will be available to the community
  12. Actual date the release is made available to the community
  13. Number of files in the release
  14. Size of the release in bytes
  15. Product type(s) in the release
  16. Release coverage (e.g., a list of start/stop times)
  17. Whether the data set has been peer reviewed
  18. Whether the release has been validated
  19. Coverage gaps that need to be resolved by the instrument team
  20. Other liens against the release
  21. Other errata of the release

FR.TRK.3 [The track function] shall track the progress of every data
delivery from an instrument team to a PDS data or discipline node, 
through the following phases (Cassini Tracker): 

  1. Data delivered
  2. Delivery acknowledged
  3. Delivery resolved, with one of the following results:
     A. Delivery accepted (by PDS)
     B. Delivery rejected (by PDS)
     C. Delivery withdrawn (by instrument team)

FR.TRK.4 [The track function] shall keep a record of the following 
properties of every data delivery from an instrument team to a PDS
data or discipline node (Cassini Tracker):  

  1.  Delivery ID
  2.  Release ID (For release being transferred or updated)
  3.  Release Version ID (For release being transferred or updated)
  4.  Whether the release is complete following this delivery
  5.  Date the delivery was made (or "N/A" if not delivered yet)
  6.  Date the delivery was acknowledged (or "N/A" if not acknowledged yet)
  7.  Date the delivery was resolved (or "N/A" if not resolved yet)
  8.  Delivery medium
  9.  Size of delivery in bytes
  10. Checksum for delivery
  11. Manifest for all files delivered

FR.TRK.5 [The track function] shall provide an online mechanism to
inform the recipient when a delivery has been made (Cassini Tracker).
  
FR.TRK.6 [The track function] shall provide an online mechanism for
the recipient of a delivery to acknowledge receipt of delivery 
(Cassini Tracker).

FR.TRK.7 [The track function] shall send email reminders to 
instrument teams when their deliveries are late (Cassini Tracker).

FR.TRK.8 [The track function] shall provide an online mechanism 
for generating and posting a list of all expected deliveries that
are late (Cassini Tracker).

FR.TRK.9 [The track function] shall provide an online mechanism for
generating reports showing the status of all releases for a given 
data set, a given instrument, or within a given time frame (Cassini 
Tracker).

1.4 Search Requirements
-----------------------

FR.SCH.1 [The search function] shall provide an online mechanism 
for locating the following kinds of objects stored in the system,
using a set of search parameters (CN):

  1. Data sets
  2. Data products
  3. Ancillary files (e.g., documents, software, or calibration files)
  4. Metadata describing data sets
  5. Metadata describing data products
  6. Metadata describing ancillary files

FR.SCH.2 [The search function] shall provide a mechanism for 
searching for data sets by a set of parameters, including
(xCR.13.8 - p16):

  1.  Target
  2.  Mission
  3.  Instrument host (e.g., spacecraft)
  4.  Instrument name
  5.  Instrument type
  6.  Data type
  7.  Curating node
  8.  Start/stop times
  9.  Ephemeris
  10. Wavelength
  11. Data set ID
  12. Citation ID

FR.SCH.3 [The search function] shall provide a mechanism for 
searching for data products by any set of keywords in the Planetary 
Science Data Dictionary (PSDD) (CN, FR.1, xCR.8.4 - p8 and 
xCR.17.3 - p17).

FR.SCH.4 [The search function] shall provide a master index that
enables searching for products within a data set or group of
correlated data sets (e.g., data sets all belonging to a mission)
(FR.1.1.1, xCR.13.20 - p8).

FR.SCH.5 [The search function] shall provide a hierarchy of keywords 
to support correlative search across the following collections
(OO.2.2, xCR.15.12 - p50, xCR.16.5 - p50):

  1. All data in the PDS
  2. All data for a given target
  3. All data for a given mission
  4. All data for a given instrument
  
FR.SCH.6 [The search function] shall provide the ability to locate
all documentation and software tools distributed by the PDS 
(xCR.32.8 - p3).

FR.SCH.7 [The search function] shall support differing coordinate 
systems for searching (FR.1.2.5, xCR.14.1.1 - p31).

FR.SCH.8 [The search function] shall provide a general method for 
associating products with other products, whether of the same or 
different types. This method shall be capable of assigning 
associations after the data are archived and storing the associations 
for use by the search function, e.g., "find all calibration products 
associated with this data product". (xCR.8.2 - p52).

FR.SCH.9 [The search function] shall enable all search methods that 
apply to data products to apply to other system resource types, 
including software, documentation, calibration, and browse resources
[We have to decide whether to call these products or resources or
both] (OO.2.6, xCR.8.15 and xCR.8.16 - p52).

FR.SCH.10 [The search function] shall enable searching for landing
sites or observational target areas using attributes considered high
priority according to program or mission goals, for example those 
identified by the Mars Exploration Payload Analysis Group (MEPAG)
(xCR.28.13 - p53).

FR.SCH.11 Given a citation from the ADS bibliographic reference 
system, [the search function] shall provide a mechanism for finding 
the data set(s) or product(s) associated with the citation 
(xCR.18.6 - p43).

1.5 View Requirements
---------------------

FR.VIE.1 [The view function] shall provide a mechanism for viewing all
holdings in the PDS (OO.1.6, called "browsing" in xCR.13.24 - p41, 
xCR.8.11 - p44).

FR.VIE.2 [The view function] shall provide a standard way to 
navigate through the directories of a data set stored online and
view individual files, as though viewing a well-organized web site
(xCR.15.17 - p16).

FR.VIE.3 [The view function] shall provide an online mechanism for
previewing a representation of the data in order to determine whether
it is appropriate for further actions, such as downloading (xCR.17.10 - p16).

FR.VIE.4 [The view function] shall provide a mechanism for overlaying
image data with the following (FR.1.22, xCR.1.4.1.3, xCR.14.4):

  1. Textual information
  2. Feature information
  3. Topographic information
  4. Ground tracks of other data
  5. Latitude/longitude grids

[Need node input for viewing data in other representations, e.g.,
plots, graphs, false-color, etc.]

1.7 Retrieve Requirements
-------------------------

FR.RET.1 [The retrieve function] shall support the downloading on 
demand of any online data or ancillary product, given one of the
following (xCR.13.11, OO.2.6, xCR.8.1 - p51):

  1. The online file specification of the product's label
  2. The unique product ID

FR.RET.2 [The retrieve function] shall inform the user of download 
file size and estimated download time prior to committing to the 
actual download (xCR.17.11 - p16, xCR.13.14).

FR.RET.3 [The retrieve function] shall inform the user if the 
download file size is too large for the system to handle (CN).

FR.RET.4 [The retrieve function] shall provide a means of ordering 
collections of products other that cannot be downloaded (CN).

FR.RET.5 [The retrieve function] shall inform the user how long it 
will take to deliver an ordered product (xCR.13.15 - p18).

FR.RET.6 [The retrieve function] shall enable the automated packaging
of selected data with all associated files and supporting information
for download (FR.1.2.2, xCR.13.10 p17).

FR.RET.7 [The retrieve function] shall enable the on-demand packaging
of files for download in TAR or ZIP format (xCR.13.14 - p17).

FR.RET.8 [The retrieve function] shall enable the on-demand building
of PDS compliant volumes, combining the data sought with related 
ancillary files. These volumes may be downloaded or written to 
physical media (see FR.TRN.X1). (xCR.13.9)

FR.RET.9 [The retrieve function] shall enable the downoad of large
data volumes (FR.1.2.2, xCR.14.2.8) through FTP (xCR.14.1.15).

FR.RET.10 [The retrieve function] shall support the distribution of 
large quantities of data (xCR.14.1.2).

FR.RET.11 [The retrieve function] shall enable a user to input a 
unique product ID (e.g., data set ID plus product ID) and recieve the 
product, regardless of its location on the system (xCR.14.1.7).

FR.RET.12 [The retrieve function] shall enable off-line data to be 
tracked, ordered, and retrieved through the same channel as data kept 
on line (FR.1.2.2, xCR.8.19 - p30).

FR.RET.13 [The retrieve function] shall enable the on-demand delivery
of the most recent catalog files (xCR.18.4 - p43).

FR.RET.14 [The retrieve function] shall enable the reformatting of 
data on demand to any of the supported set of formats appropriate to 
that data type (xCR.17.2 - p51). For Radio Science those formats 
include: simple binary tables with fixed length fields, simple ASII 
tables, and simple images (xCR.18.13 - p51).

FR.RET.15 [The retrieve function] shall enable the automatic retrieval 
of all files that are part of a multi-file product (xCR.8.3 - p52).

1.8 Geometry Requirements
-------------------------

FR.GEO.1 [The geometry function] shall provide a mechanism for 
updating all geometry and pointing information in product index
tables using updated SPICE data (OO.2.9, xCR.4.1.11 - p54,
xCR.8.12 - p50, FR.1.2.5, xCR.13.50.1 - p30, xCR.13.6 - p30, and 
xCR.18.11).

FR.GEO.3 Given an observation's START and STOP time, [the geometry
function] shall determine all targets and features that lie within
the instrument's field of view during the observation.  (OO.2.9, 
xCR.4.1.11 - p54, xCR.8.12 - p50).

FR.GEO.4 Given the coordinates of a "footprint" on a planet, [the 
geometry function] shall find all data of a given type within that
footprint (FR.1.2.5, xCR.21.2.3 - p33, xCR.4.1.12).

FR.GEO.5 Given a targeted feature, [the geometry function] shall
find all data in the PDS archive pertaining to that feature. The 
targeted feature may either be static or dynamic, such as Jupiter's
red spot (FR.1.2.5, xCR.21.2.3 - p33, xCR.4.1.12, FR.1.1.1, 
xCR.14.1.5 - p9).

FR.GEO.6 [The geometry function] shall determine the ephemeris or 
time for the following types of events (CN):

  1. Occultations (CN)
  2. Periapsis (CN)

  [Node input is needed to define other events for which users may 
   need to calculate time and ephemeris]

FR.GEO.7 [The geometry function] shall determine when the 
spacecraft falls within the gravitational pull of a given feature 
(xCR.18.50.1 - p32).

FR.GEO.8 [The geometry function] shall determine the pedigree of
the NAIF software used and the geometry information stored in the
label (xCR.14.2.5 - p30).

1.9 Correlate Requirements
--------------------------

FR.COR.1 [The correlate function] shall determine whether a given 
keyword can be used as a correlative keyword between two data sets
(i.e., whether the keyword has the same meaning across the two
data sets) (CN).

FR.COR.2 [The correlate function] shall provide a mechanism for 
registering all geo-referenced data for the same planetary target 
to the same, user-selected coordinate system (xCR.13.7 - p8,
xCR.14.1.6).

FR.COR.3 [The correlate function] shall provide a mechanism for 
registering all geo-referenced data for the same planetary target 
to the same, user-selected map projection (xCR.13.7 - p8, xCR.14.1.6).

FR.COR.4 [The correlate function] shall provide images of surfaces 
for correlation with data used by radio scientists (xCR.18.10 - p9).

2.0 Process Requirements
------------------------

FR.PRC.1 [The process function] shall provide a mechanism for running
local processes on any collection of data products (xCR.31.5 - p38).

FR.PRC.2 [The process function] shall provide a mechanism for running
remote processes as web services on any collection of data prodcts
(CN, xCR.31.5 - p38).

FR.RPC.3 [The process function] shall provide web service interfaces
to the following remote processing systems (xCR.14.1.12, Susie, 
xCR.21.2.1, FR.1.2.2, xCR.14.2.13):

  1. The THEMIS processing server at Arizona State University 
  2. The GRS processing server at the University of Arizona
  3. The Rings Feature Tracker 
  4. The Map-A-Planet service at USGS

FR.PRC.4 [The process function] shall supply local processes for
transforming the following PDS data to the given formats (xCR.14.1.8,
xCR.13.4 - p18).

  1. PDS image and table data to FITS format 
  2. PDS image data to PNG and JPEG formats
  3. Binary tables to ASCII tables

FR.PRC.5 [The process function] shall supply local processes for
transforming PDS image and QUB data as follows (xCR.14.1.16,
FR.1.2.5, xCR.17.7 - p32, xCR.13.21 - p18):

  1. Geometrically correcting images
  2. Radiometrically correcting images
  3. Mapping images to any PDS-supported coordinate system
  4. Re-projecting images to any PDS-supported map projection
  5. Applying transformations available from the ISIS system

R.PRC.6 [The process function] shall supply local processes for 
subsetting the following data types (xCR.31.5 - p38, xCR.8.8 - p44):

  1. Selecting individual bands from spectral QUB data
  2. Selecting rectangular sub-regions of images
  3. Selecting specified rows and columns from tabular data
  4. selecting specified intervals from time series

1.10 Transfer Requirements
--------------------------

FR.TRN.1 [The transfer function] shall provide a mechanism for 
writing any collection of data products and ancillary files on-demand
to physical media (xCR.13.9).

FR.TRN.2 [The transfer function] shall enable generation on-demand
of PDS compliant archive volumes on any sized physical media, from
a single online archive volume (OO.2.13, xCR.16.1 - p49).

FR.TRN.3 [The transfer function] shall provide a mechanism for 
delivering the PDS compliant archive volumes covering each data 
set to the following organizations (CN, FR.1.2.2, xCR.17.5):

  1. Central node
  2. The discipline node curator for that data set
  3. NSSDC

1.11 Subscribe Requirements
---------------------------

FR.SUB.1 [The subscribe function] shall provide an online mechanism
for creating subscriber accounts, with each account requiring the
following attributes:

  1. User full name
  2. User last name
  3. Password
  4. Institution
  5. Work telephone
  6. Email address
  7. Mailing address
  8. Whether user is funded by NASA Code S

FR.SUB.2 [The subscribe function] shall provide an online mechanism 
for users to subscribe to recieve email notifications of the 
following events (CN, xCR.10.3 - p34):

  1. When new data from a user-specified data set are released
  2. When a new version of the PDS standards is released
  3. When a new version of the data dictionary is released
  4. When a new version of the online PDS system is released
  5. When a new version of a PDS software suite is released

FR.SUB.3 [The subscribe function] shall provide an online mechanism
for subscribers to change their account information, change their
notification requests, delete their accounts, and cancel their
subscriptions (CN).

1.12 Administer Requirements
----------------------------

FR.ADM.1 [The administer function] shall provide a mechanism
for monitoring the availability and performance of every server 
on the system (xCR.32.13 - p2).

FR.ADM.2 [The administer function] shall provide a mechanism for 
capturing, displaying, and summarizing the following metrics 
(xCR.32.13 - p2, OO.1.9, xCR.13.28 - p45, xCR.31.6 - p38):

  1. Number of user accesses, per server and time period
  2. Number of data requests, by repository and data set
  3. Number of bytes tranferred, by repository and data set
  4. Transfer performance, by server and time period
  5. Log of all support requests and user comments

FR.ADM.3 [The administer function] shall provide a mechanism for
monitoring changes to any internal structure, such as catalogs or
indices, used by the system (xCR.10.8 - p35, xCR.10.9 - p35).

FR.ADM.4 [The administer function] shall maintain an inventory of all
deep archive volumes (FR.1.2.2, xCR.17.5).

FR.ADM.5 [The administer function] shall enable automatic failovers 
and routing to available systems (xCR.14.1.9).

2. Non-Functional Requirements
------------------------------

NR.SYS.1 The system shall be constrained by the following non-functional
requirements:

2.1  Architectural --- ARC - system architecture
2.2  Interface ------- INT - user interface and look and feel
2.3  Capacity -------- CAP - storage needs
2.4  Performance ----- PER - data access, processing, and transfer
2.5  Availability ---- AVA - uptime requirements
2.6  Security -------- SEC - security requirements
2.7  Compatibility --- CMP - platform support and interoperability
2.8  Standards ------- STD - standards to support system operation
2.9  Policies -------- POL - policies to support system operation
2.10 Documentation --- DOC - documentation required for the system
2.11 Support --------- SUP - technical and user service support
2.12 Development ----- DEV - development and system evolution

2.1 Architectural requirements
------------------------------

NR.ARC.1 [The system] shall have an open architecture, where all
changes and enhancements can be made in a collaborative manner, and
all Application Programming Interfaces (APIs) are fully documented
and shared (xCR.17.13 - p38).

NR.ARC.2 [The system] shall have non-proprietary core components.
This includes all components that enable communication and tranfer
of data from one location to another (xCR.17.14 - p38).

NR.ARC.3 [The system] shall be modular and capable of being built 
incrementally (xCR.17.14 - p38).

NR.ARC.4 [The system] shall be service based, where each service
can be built indipendently of each other and are capable of evolving
independently (xCR.17.15 - p39).

NR.ARC.4 [The system] shall be a distributed system. It shall provide 
the ability to locate data, resources, and services from multiple 
physical locations (xCR.17.12 - p16). 

NR.ARC.5 [The system] shall be peer-to-peer, meaning that each
component shall be capable of interacting with each other, without
an intermediary (xCR.17.16 - p39).

2.2 Interface Requirements
--------------------------

NR.INT.1 [The system] shall provide a web-based interface as the 
primary means through which users interact with the system. A user 
shall be able to access all the functions and services through a 
common web browser (xCR.17.17 - p17, FR 3.1).

NR.INT.2 [The system] shall provide an Application Programming
Interface (API) as a means for developers to access all functions
and services provided by the system (xCR.32.12).

NR.INT.3 [The user interface] shall provide access to online help for 
all functions, as well as easy access to all applicable documentation 
(xCR.14.1.13 - p15).

NR.INT.4 [The user interface] shall provide intuitive interaction 
with the system. This means that most users should be able to figure
out how to use basic system functions without reading further 
documentation (FR.1.2.1, xCR.13.13).

NR.INT.5 [The user interface] shall provide "context sensitive" 
searching for data sets. That is, once the user sets a value for a 
search parameter, the available values for the other parameters 
must be consistent with the first parameter/value pair. For example,
if TARGET is set to "JUPITER", then the interface will not allow 
MISSION to be set to "PATHFINDER", since PATHFINDER did not observe
Jupiter (xCR.14.1.10 - p15).

NR.INT.6 All web form input shall be validated to reduce the
possibility of erroneous results (xCR.10.6 - p35).

NR.INT.7 All web pages and email announcements shall appear neat and 
of professional quality (FR.1.2.1, xCR.15.16 - p16).

2.3 Capacity Requirements
-------------------------

NR.CAP.1 [The system] shall be able to store 300 TB of data products
online and ensure that all data are accessible to all system 
functions and services (xCR.28.16).

2.4 Performance Requirements
----------------------------

NR.PER.1 [The system] shall be able to move 300 GB of data every 
month. At a lower bound, the data are to be shared among at least
50 sites, or 6B per site. At an upper bound, the data are to be 
distributed to all 50 sites, or a total of 15000 GB transfered 
(xCR.28.10 - p24).

NR.PER.2 [The system] must be able to transfer 10GB/day between 
instrument teams for intrateam data analysis (MRO, FR.1.2.2,
xCR.28.17 - p25, xCR.28.8 - p29).

2.5 Availability Requirements
-----------------------------

NR.AVA.1 All servers on the system shall meet the availability
standards of their hosting institution (CN).

NR.AVA.2 Best efforts shall be made to minimize system downtime
(CN).

2.6 Security Requirements
-------------------------

NR.SEC.1 [The system] shall provide unrestricted access to all 
data, documentation, and software released to the public 
(xCR.28.19 - p36).

NR.SEC.2 [The system] shall strive to ensure that institutional 
security requirements do not interfere with unrestricted access
to all data, documentation, and software released to the public
(OO.1.10, xCR.14.2.18 - p37).

NR.SEC.3 [The system] shall provide role-based authentication for 
controlled access to data or system functions and shall recognize
the following roles (FR.1.2.3, xCR.13.29 - p30, xCR.15.6 - p30):

  1. Data provider for a specified mission
  2. Data distributor for a specified mission
  3. Central Node data engineer for a specified mission
  4. Subscriber
  5. Administrator 

NR.SEC.4 [The system] shall restrict access to a mission's
pre-release data to the following roles (xCR.28.19 - p36):

  1. Data provider for the mission
  2. Data distributor for the mission
  3. Central node data engineer for the mission
  4. System administrator
  
NR.SEC.5 [The system] shall restrict the ability to perform
ingest, validate, and transfer functions on a mission's data 
to the following roles (xCR.28.19 - p36):

  1. Data distributor for the mission 
  2. Central node data engineer for the mission 
  3. System administrator
  
NR.SEC.6 [The system] shall restrict access to subscription
information to the subscriber and the system administrator
(FR.1.2.3, xCR.13.29 - p30, xCR.15.6 - p30).
  
NR.SEC.6 [The system] shall restrict the ability to perform
the administer function to the system administrator (CN).

2.7 Compatibility Requirements
------------------------------

NR.CMP.1 Server-side components shall be portable across the 
following platforms (xCR.21.2.1):

  1. Solaris
  2. Linux
  3. Windows
  4. Mac OS X

NR.CMP.2 Client-side tools shall be portable across the following 
platforms (xCR.4.1.10 - p44, xCR.8.10 - p44):

  1. Solaris
  2. Linux
  3. Windows
  4. Mac OS X

NR.CMP.3 File system operations shall be case-insensitive 
(xCR.21.2.1).

NR.CMP.4 [The system] shall support the following bindings for 
APIs to server-side components (CN):

  1. HTTP
  2. Java
  3. IDL

NR.CMP.5 [The system] shall support the following bindings for
APIs to client-side libraries (CN):

  1. C
  2. Perl
  3. Java
  4. IDL
  

2.7 Standards Requirements
--------------------------

NR.STD.1 [The PDS] shall ensure that all system functions are
consistent with PDS standards as documented in the PDS Standards
Reference (CN).

NR.STD.2 [The PDS] shall establish standards for treating all
labeled ancillary files as products (SBN).

NR.STD.3 [The PDS] shall establish standards for associating
any product of any other product (SBN).

NR.STD.4 [The PDS] shall establish standards for applying version
control to metadata and data products (CN, SBN).

NR.STD.5 [The PDS} shall establish standards for enabling the
use of a more sophisticated target model (SBN).

2.8 Policy Requirements
-----------------------

NR.POL.1 [The PDS] shall provide a way of determining a consistent
set of standards that apply to a mission/volume set and do not 
change over the life of the mission/volume set (xCR.14.2.3 - p36).

NR.POL.2 [The PDS] shall provide a policy for enabling instrument
teams to become data nodes (xCR.28.18, p36, xCR.13.32 - p45).

NR.POL.3 [The PDS] shall provide a policy for conducting peer 
reviews (xCR.4.1.4 - p37).

NR.POL.4 [The PDS] shall provide a policy for acceptible means of 
electronic data delivery: where files are delivered, who maintains
the area where files are delivered, how online validation and peer
review are done, what must take place before data are made
available (xCR.4.1.7 - p37).

NR.POL.5 [The PDS] shall provide a policy for delivery of archive 
volumes, whether electronically or on physical media, to the NSSDC 
(xCR.4.1.8 - p37).

NR.POL.6 [The PDS] shall provide a policy for formalizing all
required deliverables from missions (xCR.8.22 - p37).

NR.POL.7 [The PDS] shall provide a security policy that takes into
account security mandates from NASA, the department of Interior,
discipline node home institutions, and other PDS stake-holders
(OO.1.10, xCR.14.2.9 - p38).

NR.POL.8 [The PDS] shall provide a policy for enabling mirror
sites (OO.1.2, xCR.13.22 - p38).

NR.POL.9 [The PDS] shall provide a policy for ensuring backup of data
that has been distributed online but not yet written to permanent
archive (xCR.15.21 - p41).

NR.POL.10 [The PDS] shall not access data from NSSDC unless there has
been a catastrophic failure (OO.1.5, xCR.13.16 - p41).

NR.POL.11 [The PDS] shall provide a backup and security plan 
(xCR.15.21 - p41, xCR.31.3 - p41).

NR.POL.12 [The PDS] shall adopt NASA processing level indicators and
deprecate the CODMAC levels (OO.2.5, xCR.15.13 - p51).

NR.POL.13 [The PDS] shall provide a policy on the scope of its 
holdings that includes highly derived products, such as parameter 
catalogs (OO.2.8, xCR.8.6 - p53).

NR.POL.14 [The PDS] shall provide a policy for responding to requests
for CD/DVD volumes, including those created by the system on demand
(OO.3.1, xCR.14.2.7 - p55).

NR.POL.15 [The PDS] shall establish a canonical coordinate system for
planetary targets, for example, planetocentric, east longitude 
(xCR.14.2.6 - p9).

NR.POL.16 [The PDS] shall provide data dictionary definitions of 
LATITUDE and LONGITUDE keywords consistent with a "cannonical"
coordinate system (xCR.14.1.11).

2.9 Documentation Requirements
------------------------------

NR.DOC.1 [The system] shall provide a document describing the entire
PDS archive lifecycle (xCR.13.50.2 - p36).

NR.DOC.2 [The system] shall provide a Proposers Archive Guide to
help proposers understand and describe how to meet PDS archive
requirements in Announcements of Opportunity (AO) (From March 03 
Management Council).

NR.DOC.3 [The system] shall provide templates and examples of 
the following archive planning and design documents (OO.1.1, 
xCR.13.33 - p36, xCR.13.50.4 - p36, OO.1.8, xCR.13.32 - p45, 
FR.1.1.2, xCR.114.2.17 - p10):

  1. Memorandum of Understanding (MOU) between the mission and the
     PDS, defining roles and responsibilities
  2. Archive Plan
  3. Interface Control Document (ICD), describing the archive data
     products and volumes for a particular instrument
  
NR.DOC.4 [The system] shall provide an Operations Plan, including
information on the the following topics (xCR.15.3 - p38, 
xCR.13.27 - p38):

  1. Running system functions
  2. Maintaining and upgrading system software
  3. Performing system backups
  4. Ingesting, validating, distributing, and archiving data

NR.DOC.5 [The system] shall provide a development plan, including
information on the following topics (xCR.15.14 - p42, OO.1.3,
xCR.15.5 - p38, xCR.31.2 - p38, OO.1.6, xCR.14.2.16 - p42,
xCR.18.1):

  1. Development goals
  2. Technology infusion plans
  3. Tools plan
  4. System evolution
  
NR.DOC.6 The system shall provide complete documentation for tools
and system APIs (OO.1.6, xCR.4.1.10 - p44).

NR.DOC.7 The system shall provide documentation for all interfaces,
data structures and standards used for online as well as hard media
distribution (OO.2.13, xCR.14.2.14 - p48).

2.10 Support
------------

NR.SUP.1 [The PDS] shall provide at least one full-time system
administrator, responsible for the following (CN):

  1. Keeping servers up and running properly
  2. Maintaining and upgrading system software
  3. Peforming system backups
  4. Providing technical support where needed

NR.SUP.1 The PDS shall shall provide a single e-mail address for all
user feedback and requests for technical support (CN).

2.11 Development Requirements
----------------------------

NR.DEV.1 [The PDS] shall use strict configuration control on all
components of the system (OO.1.7, xCR.8.18 - p45).

NR.DEV.2 [The PDS] shall develop the system in accordance with an
iterative phased-development life cycle, with each iteration
including the following steps (CN):

  1. System definition
  2. Requirements analysis
  3. Design
  4. Implementation
  5. Testing
  6. Integration
  7. Deployment

###