Joel,  Here are my comments on the initial requirements list.  I read the notes 
from Chuck Acton and strongly agree with them.  In particular, it seems to be 
important to understand the time frame over which these requirements will be 
implemented, thus, helping to establish priorities.  Also, the timeframe would 
be helpful in determining how the system could be built in stages; which 
functions would benefit from future technology development, etc.  Also, I was 
concerned about the amount of data processing in the requirements, particularly 
offering services and links to systems supported outside of PDS.

In addition, the scope of some of the requirements need more description to 
understand what they are requiring.

It would also be helpful to outline the process flow of data from data providers 
into pds and its functions.  For example, during ingest data should not be store 
in operational repositories until it is validated and the interfaces and data 
bases that support that data are updated and ready for use.

Finally, my comments listed below (starting with a >) were based on reading the 
initial requirements lists and not the revised ones below.

Requirements List - 2003-07-03 (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).

>Does this mean delivery of complete datasets or pieces of data sets (e.g. only 
>data products).  The delivery of a data set may be a collaboration between the 
>producer and a PDS node.

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).

>  How automatic?  What catalogs does this mean?

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).

> Why default interface, what about custom ones?

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

> Need tool to generate labels from an index or index-like table.

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

> We need to have tool(s) that checks that labels properly describe the data and 
> that can process large numbers of data files without user input.  I personally 
> have low confidence in NASAview given the repeated and seemly continuous 
> revisions and often having it not do what it is expected to do. It seems to 
> have gone way past its original goals.  Also, need tool to check that label 
> keyword values are consistent across the data products in a data set and the 
> label and keywords are consistent across the data products.  Right now lvtool 
> checks individual files, but there is no tool to check one data product label 
> is consistent with the others in the data set.

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

> These phases should match or trace back to the high level functions listed 
> under 1.0.

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

> Seems overly detailed, not sure whether tracking this much information 
> would become overly burdensome and thus less likely for people to keep the 
> information up-to-date and accurate.  What is really essential here?

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)

> Data does not always come from instrument teams.

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

>  What is the difference between delivery id and release id?


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

> Also product type.  Not always wavelength, could be frequency or energy, for 
> example.

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 

> Could also include instrument type. For example, Mars imaging or Jupiter or 
> Saturn images.

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).

>  Be more specific.

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).

> Given a reference within a data set provide link to that reference in ADS 
> (some ADS references can be accessed on-line).

> Has the unique product id requirement gone away?  I had several issues that 
> that one.

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).

> Be specific as to what viewing means.

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.]

> Seems highly ambitious , particularly for non geo-referenced EDR data.


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)

>  I think this is very high priorty.

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).

> would need to handle data at multiple locations (several pds nodes or pds 
> node and data node).

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).

> have to track geometry file versions and sources.  Latest is not always the 
> best if geometry info is provided by multiple sources(e.g. MGS).

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)

> Probably other parameters important like those in the NAIF orb_num files. 
> For example longitude crossing for a given orbit in polar orbiting missions.

[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 
--------------------------

> not sure what any of these requirements mean.

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

> Have to be careful in providing services by non-PDS supported systems.  Will 
> they always be available and do what PDS expects of them?

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

> See other comments about being ambitious, using systems from outside PDS. 
> Should be more restricted to resources within PDS or provided by data producer 
> to include with the archives.

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).

> Again high priority.

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 
---------------------------

> change name to notification requirements.  Subscribe implies to me that I 
> will automatically get products delivered.

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).

>  Have to set priorities on functions.  How long to implement entire set.

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).

> What does 300 GB refer to?  Ingestion, archiving, delivery to users, all the 
> above?

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).

> last point is very important - refers back to my comment on understanding the 
> process flow and order in which functions are done.


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).

> Great, probably long overdue.  As an aside - it is not clear to me why 
> processing level needs to be in data set id, also the whole data set id scheme 
> could use some updating.

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).

> And PDS shall get rid of the target catalog template and use NAIF kernels 
> for these data - coordinate systems, control nets, etc.

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).

> Need people to provide timely responses.  Have a ticket/tracking system to 
> manage user questions.  Could be used to generate a knowledge base or FAQ 
> system.


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 
###