PDS System Requirements List (2003-09-08) ========================================= 1. Functional Requirements FR.SYS.1 The System shall provide the following functions: 1.1 Ingest ---------------- ING - Receive and store resources 1.2 Validate -------------- VAL - Validate resources 1.3 Track ----------------- TRK - Track the status of resources 1.4 Search ---------------- SCH - Find resources 1.5 Display --------------- DSP - Display resources 1.6 Retrieve -------------- RET - Get resources 1.7 Geometry -------------- GEO - Calculate geometric information 1.8 Data Mining------------ DMG - Extracting information from science data 1.9 Process --------------- PRC - Run processes on resources 1.10 Transfer -------------- TRN - Transfer resources to other systems or media 1.11 Notification----------- NOT - Notify users of changes to resources 1.12 Administer ------------ ADM - Monitor and update the state of the System 1.1 Ingest (ING) Requirements ----------------------------- The Ingest function takes resources into the system and makes them accessible. FR.ING.1 [The ingest function] shall be able to receive resources and resource descriptions submitted electronically (CN). FR.ING.2 [The ingest function] shall be able to receive resources and resource descriptions submitted on hard media (CN). FR.ING.3 [The ingest function] shall make all resources accessible according to policy. (For example, validation periods will be observed, and policy will dictate whether a given resource must be stored online, or whether nearline or offline storage is acceptable) (Edited during workshop). FR.ING.4 [The ingest function] shall catalog all resource descriptions. (xCR.13.17 - p18). FR.ING.5 Descriptions of the following resources shall be incorporated into the Data Set Catalog: data set instrument host (spacecraft/earthbase) mission/campaign reference document software person FR.ING.6 [The ingest function] shall be able to receive and catalog resource descriptions through both traditional catalog files and online forms (Added during workshop). FR.ING.7 [The ingest function] shall allow resource descriptions to be submitted independently of the resource itself. (For example, this allows product indices to be updated after data delivery, when better geometric data become available.) FR.ING.8 [The ingest function] shall be able to receive new data dictionary elements and updates to existing data dictionary elements through traditional data element definition files. FR.ING.9 [The ingest function] shall have an online interface, with interactive help, for the submission of new keywords and standard values. FR.ING.10 [The ingest function] shall have the capability to create and update associations of resources with other resources, e.g., ancillary files, calibration files. FR.ING.11 [The ingest function] will provide a mechanism for incorporating the contents of local data dictionaries into the master Planetary Science Data Dictionary (PSDD). FR.ING.12 [The ingest 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.ING.13 [The ingest function] shall provide an archive production tool suite with the following capabilities (FR.1.1.2, xCR.114.2.17 - p10): 1. Generate index tables from a set of product labels 2. Generate product labels from an index table 3. Generate labels for index tables 4. Generate catalog files from online catalog information 5. Generate a product label from an interactive template, i.e., a label editor 6. Generate product labels using a template and tools that extract values from source files. 1.2 Validate (VAL) Requirements ------------------------------- The validate function determines whether a received resource meets PDS standards for formatting, description, and completeness of contents. A resource that has been validated can cataloged and made accessible. FR.VAL.1 [The validation function] shall provide a comprehensive 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.2 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. Ensure that required directories and files are present 2. Ensure that every file is pointed to by a PDS label 3. Ensure every label has 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. Ensure that ASCII files are properly formed 5. Ensure that the index tables are properly formed and correctly point to data 6. Ensure that every entry in the index table corresponds to a data product. 7. Ensure that every data product has an entry in the index table (NOTE: The issue was raised whether an index table be required to have entries for ALL products, e.g. documents and software, or whether there should there be separate indexes for each type of product.) 8. Ensure that product labels accurately describe file format (e.g. for a binary table, ensure that rows, columns, start-bytes, are correct. See Anne's table analyzer as example) 9. Ensure that catalog files are internally consistent. 10. Ensure that catalog files are consistent with product labels. 11. Ensure that catalog files can be ingested without violating the referential integrity of the data set catalog Note: In this context "ensure" means determine and report. FR.VAL.3 All validation tools shall have an interactive user interface. FR.VAL.4 All validation tools shall have a command-line interface suitable for running in batch mode. FR.VAL.5 All validation tools shall be able to direct reports to a specified destination, e.g. file, email address, web page. FR.VAL.6 [The validate function] shall provide a mechanism to specify the level of detail in a validation report. (For example, whether to provide a detailed summary or simply a pass/fail indication.) FR.VAL.7 [The validate function] shall enable authorized users to invoke validation tools on remote data and have reports returned to their location, and optionally forwarded to other interested parties. [Edited after working group analysis.] FR.VAL.8 [The validate function] shall enable the validation of a subset of data products in a release. FR.VAL.9 All validation tools that use the Planetary Science Data Dictionary (PSDD) shall be able to use local data dictionary resources in conjunction with the PSDD. [Added after working group analysis.] 1.3 Track (TRK) Requirements ---------------------------- The track function determines and reports the status of a resource, starting from the time it is submitted and continuing throughout the life cycle of the resource. DEFINITIONS Delivery = transfer of data from data provider to PDS node Release = making data accessible to the public FR.TRK.1 [The track function] shall keep a record of the status and location of every resource throughout the life cycle of the resource. [Added after working group analysis.] FR.TRK.2 [The track function] shall notify interested parties when a status change has occurred (e.g., inform the PDS node when a delivery has been made, or notify the data provider when a delivery has been acknowledged or accepted). FR.TRK.3 [The track function] shall provide a mechanism for authorized users to update tracking information (e.g., acknowledging the receipt of a delivery or changing schedules). FR.TRK.4 [The track function] shall send notifications to data providers and other interested parties of upcoming or overdue events (e.g., pending deliveries or late deliveries). (Cassini Tracker). FR.TRK.5 [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.6 [The track function] shall provide an online mechanism for generating reports showing the status of all releases for a given mission, data set, instrument, or within a given time frame (Cassini Tracker). FR.TRK.7 [The track function] shall ensure that a user's view into the system is limited according to his or her access rights. FR.TRK.8 [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 22. Release status (e.g., submitted, acknowledged, rejected, accepted, withdrawn, released) FR.TRK.9 [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 (for delivery from data provider to PDS) 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 (optional) 11. Manifest for all files delivered 1.4 Search (SCH) Requirements ----------------------------- The search function supports the location of resources based on their cataloged attributes. The search function may return a set of resources, a set of resource descriptions, or a count of the number of resources matching the search criteria. FR.SCH.1 [The search function] shall provide an online mechanism for locating any resource in the system (e.g., data set, data product, ancillary file, archive volume). FR.SCH.2 [The search function] shall provide a mechanism for searching for resources by any set of indexed attributes. (CN, FR.1, xCR.8.4 - p8 and xCR.17.3 - p17). [Editors note: keywords->attributes] FR.SCH.3 [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 (e.g., image) 7. Curating node 8. Start/stop times 9. Wavelength 10. Data set ID 11. Citation ID FR.SCH.4 [The search function] shall provide the capability to determine whether a search is correlated. That is, the search function will be able to call a utility to determine if an attribute to be used in the search is correlated across all contexts involved in the search. (See the Requirements Glossary for additional details.) [Added after working group analysis.] FR.SCH.5 [The search function] shall support searches across all NAIF-supported coordinate systems. [NOTE: see Geometry requirements.] (FR.1.2.5, xCR.14.1.1 - p31). FR.SCH.6 [The search function] shall provide a method for locating resources that are associated with a selected resource. (For example, "find all calibration products associated with this data product".) [NOTE: see requirements in Ingest function for making associations.] (xCR.8.2 - p52). FR.SCH.7 [The search function] shall have the capability to perform substring searches on values of character keywords. FR.SCH.8 [The search function] will provide a utility associated with a permanent URL to take the identifying information from a published citation and return the resource description(s) corresponding to that citation. For example, the ADS should be able to cite PDS data products by appending the identifying information from the citation description supplied by PDS to a standard URL to create a link for use on their result pages. (xCR.18.6 - p43). ............................................................................ The following requirements are specific to resource type or data submitter (i.e., these are domain-specific searches): FR.SCH.9 [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.10 [The search function] should be able to filter search results on rings for a variety of geometric factors: [Added by Mitch Gordon] 1. Longitude relative to periapse 2. Proximity to the planet's shadow 3. Proximity to the ansa 4. For a specified phase range 5. Separation from a known body FR.SCH.11 [The search function] will provide a standard utility to accept a specific instrument, instrument host, and time window, return a list of data products that fall within the time window. FR.SCH.12 [The search function] will provide a standard utility to accept a specific instrument, instrument host and spatial window on a target body, return a list of data products that fall within the spatial window. 1.5 Display (DSP) Requirements ------------------------------ The display function provides representations of resources in the system, which can be used by user interfaces. FR.DSP.1 [The display function] shall provide a mechanism for viewing a description of all resources. FR.DSP.2 [The display function] shall provide a mechanism for displaying a representation of all resources (e.g., browse version of an image. (OO.1.6, called "browsing" in xCR.13.24 - p41, xCR.8.11 - p44). FR.DSP.3 Where the resource is a repository, [the display function] shall provide a mechanism to navigate through the directories of a repository and display individual files. (xCR.15.17 - p16). FR.DSP.4 [The display 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.DSP.5 [The display function] shall have the capability to generate a default web interface to the data when new data are delivered to the PDS (xCR.16.2, xCR.8.27 - p30). 1.6 Retrieve (RET) Requirements ------------------------------- The retrieve function makes a located resource available to the user locally. FR.RET.1 [The retrieve function] shall provide a mechanism to deliver any resource on the system, to which the user is allowed access (xCR.13.11, OO.2.6, xCR.8.1 - p51). [Edited after workshop.] FR.RET.2 [The retrieve function] shall allow the user to download resources that do not exceed defined system limitations. FR.RET.3 [The retrieve function] shall be capable of informing the user of the estimated size and delivery time prior to committing to the delivery. (xCR.17.11 - p16, xCR.13.14). FR.RET.4 [The retrieve function] shall inform the user if the delivery size exceeds a defined threshold and offer alternative delivery methods (CN). FR.RET.5 [The retrieve function] shall provide a mechanism for ordering resources (CN). FR.RET.6 [The retrieve function] shall enable the automated packaging of a resource and all associated resources for delivery (FR.1.2.2, xCR.13.10 p17). FR.RET.7 [The retrieve function] shall enable the packaging of resources for delivery in TAR or ZIP format (xCR.13.14 - p17). FR.RET.8 [The retrieve function] shall enable the building of PDS compliant volumes, combining the resources sought with related resources for delivery. (see FR.TRN.X1). (xCR.13.9) FR.RET.11 [The retrieve function] shall accept a unique resource identifier and deliver the resource, regardless of its location on the system (xCR.14.1.7). [NOTE: unique resource identifier is not the same as a web-related URI.] FR.RET.12 [The retrieve function] shall enable the delivery of the most recent catalog files (xCR.18.4 - p43). (Note: this corresponds to current information in the data set catalog.) [From Susie] FR.RET.13 [The retrieve function] shall enable the reformatting of a data product to any of the supported set of formats appropriate to that data type (xCR.17.2 - p51). Example formats include: simple binary tables with fixed-length fields, simple ASCII tables, simple images (xCR.18.13 - p51). FR.RET.14 [The retrieve function] shall enable the automatic retrieval of all files that are part of a multi-file resource (xCR.8.3 - p52). (e.g., TES product, software packages). FR.RET.15 [The retrieve function] shall support the delivery of a user defined subset of a data product as a PDS-labelled product. (Eric Eliason - HiRISE). [Edited after working group analysis.] FR.RET.16 [The retrieve function] shall support the delivery of a collection of user-selected resources. (Susie Slavney) 1.7 Geometry (GEO) Requirements ------------------------------- The geometry function refers to the discovery, calculation and use of the geometric relationships between intrument hosts, instruments, and targets of observation. It includes things like illumination angles, coordinate conversion, calculation and recalculation of ephemerides, time calculations as well as basic location, pointing and orientation information. SCOPE: - These requirements apply to those PDS data sets, instruments, instrument hosts and targets that are supported by NAIF SPICE kernels and software. - For the purposes of the following requirements, a "target" may be a body, a feature on a body, or any area or phenomenon of interest for which SPICE support or IAU Gazetteer information (or an equivalent PDS table product) is available. - A spatial window is an area defined on a target body or the celestial sphere. On the target body it is defined in terms of an appropriate surface or host-centered coordinate system. On the celestial sphere it is defined in an appropriate celestial coordinate system. NOTE: All "standard utilities" must have both a web-based and an application programmer interface. FR.GEO.1 [The geometry function] will provide a mechanism for recalculating indexed geometric values produced using archived software when updated SPICE kernels become available. FR.GEO.2 [The geometry function] will provide a standard utility to accept a specific instrument, instrument host, and time window and return a list of known (i.e., NAIF-supported) targets within the instrument field of view. FR.GEO.3 [The geometry function] will provide a standard utility to transform coordinates in any format between any two supported reference frames. FR.GEO.4 [The geometry function] will provide a standard utility to transform a given time between standard time systems. [NOTE: NAIF provides the CHRONOS utility, which does this.] FR.GEO.5 [The geometry function] will provide the capability to accept a specific spacecraft, target body, and minimum value of gravitational acceleration, return the UTC at the spacecraft when the gravitational acceleration due to the named target exceeds the given minimum value. [NOTE: It is not clear to me whether the above requirement is going to remain considering this is based on a misinterpretation of Dick's requirement.] FR.GEO.6 [The geometry function] will provide a standard utility to accept a specific instrument, instrument host, and a three-dimensional range with respect to a specific coordinate system and return the time range(s) when the instrument host is within the specified range. FR.GEO.7 [The geometry function] will provide a standard utility to accept a specific instrument, instrument host, time window and target, return a list of data products for which the target lies within the field of view. [Note from discussion between Anne and Chuck: This is probably not realistic as a general utility. However, the constituent pieces probably are.] ****************************************************************************** NOTE: The Correlate Requirements section has been deleted. All coorelation requirements are now book-kept under other functional headings, typically, the search function, since almost all correlate requirements really pertain to correlative searching. ****************************************************************************** 1.8 Data Mining (DMG) Requirements [Added after working group analysis] ----------------------------------------------------------------------- FR.DMG.1 [The data mining function] shall provide the capability to extract elevation information from MGS MOLA data. [Added after working group analysis. - Tom Stein] 1.9 Process (PRC) Requirements ------------------------------ The process function enables the execution of utilities using resources or resource descriptions as input. [Note: An internal process is a process that is supplied as an integrated part of the PDS System. An external process is a process that is supplied by an external party, to which the PDS may provide an interface.] [Editor's Note: This section needs further work] FR.PRC.1 [The process function] shall provide (internal to the system) standard processes [e.g. OAL conversions] for application to any collection of resources and return the results to the client. FR.PRC.2 [The process function] shall allow the integration of "web services" for performing transformations and manipulations on any collection of resources and return the results to the client. (CN, xCR.31.5 - p38). FR.PRC.3 [The process function] shall provide a web services based "plug-in" capability for utilities to enable transformations and manipulations on any collection of resources and return the results to the client. (CN, xCR.31.5 - p38). FR.PRC.4 [The process function] shall provide web service interfaces. (e.g. http, https, rmi, ... as approved by MC) (xCR.14.1.12, Susie, xCR.21.2.1, FR.1.2.2, xCR.14.2.13) FR.PRC.5 [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.6 [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 FR.PRC.7 [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 FR.PRC.8 [The process function] shall be able to cast results as resources (RSD) FR.PRC.9 Where the resources is an image, the process function shall enable the following image display controls: 1. Contrast stretch 2. Zoom and pan 3. Histogram display 4. Line/sample location and DN value under cursor 5. Whatever NASAView does now [<== Needs better definition!] FR.PRC.10 [The process 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 ***NOTE: [Need node input for viewing data in other representations, e.g., plots, graphs, false-color, etc.] FR.PRC.11 [The process function] shall provide a mechanism for searching and retrieving information necessary 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.PRC.12 [The process function] shall provide a standard utility to take the name of an attribute and indices, and indicate: a) if that attibrute appears in both indices; and b) if the attribute values in both indices be directly compared (i.e. without conversion) (CN) ............................................................................. Domain or mission-specific functions: FR.PRC.13 [The process function] shall provide a standard utility for creating reduced-resolution images, by supplying the appropriate coeficients to JPEG2000 images. (MRO HiRISE) 1.10 Transfer (TRN) Requirements -------------------------------- The transfer function makes located resources available to remote systems or on physical media. (Note the difference between the transfer function, which takes place only on the server tier, and the retrieve function which is restricted to sending resources from the server tier to the user.) FR.TRN.1 [The transfer function] shall provide, on request, a mechanism for writing any collection of data products and ancillary files onto physical media (xCR.13.9). FR.TRN.2 [The transfer function] shall provide, on request, a mechanism for generation of PDS compliant archive volumes onto physical media from a PDS repository. (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 FR.TRN.4 [The retrieve function] shall enable the download of large data volumes (FR.1.2.2, xCR.14.2.8) through FTP (xCR.14.1.15). 1.11 Notification (NOT) Requirements ------------------------------------ The notification function notifies users that resources, to which they have subscribed, have been added or changed. FR.NOT.1 [The notification function] will provide subscribers with their requested information when it becomes available. FR.NOT.2 [The notification 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.NOT.3 [The notification function] shall provide an online mechanism for users to subscribe to receive email notifications of any of the following events (CN, xCR.10.3 - p34): 1. News about a user-specified data set (e.g., released, revised, delayed) 2. News about PDS standards 3. News about the data dictionary 4. News about the PDS system 5. News about a PDS software suite 6. General PDS announcements 7. Internal PDS announcements, e.g., overdue data deliveries (access restricted) FR.NOT.4 [The notification 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). FR.NOT.5 [The notification function] shall maintain a web site to which subscribers may be referred for detailed information. FR.NOT.6 All notifications will be logged and will be accessible for viewing by subscribers. 1.12 Administer (ADM) Requirements ---------------------------------- The administer function enables system administrators to monitor, update, backup, and perform other housekeeping tasks on the system. FR.ADM.1 [The administer function] shall provide a mechanism for monitoring the availability and performance of every software server on the system (xCR.32.13 - p2). FR.ADM.2 [The administer function] shall provide a mechanism for monitoring the availability, health, and performance of every hardware server on the system (xCR.32.13 - p2). FR.ADM.3 [The administer function] shall provide a mechanism for capturing, displaying, and summarizing the following metrics from all possible delivery and feedback mechanisms. (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 3. Number of bytes tranferred, by repository 4. Transfer performance, by server and time period, including bandwidth usage and average load over time 5. Number and type of support requests and user comments FR.ADM.4 [The administer function] shall provide a mechanism for monitoring changes to any internal structure, such as catalogs or indices. (xCR.10.8 - p35, xCR.10.9 - p35). FR.ADM.5 [The administer function] shall maintain an inventory of all deep archive volumes (FR.1.2.2, xCR.17.5). FR.ADM.6 [The administer function] shall provide automatic failovers for the search, view, retrieve, transfer, subscribe functions. (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 (ARC) Requirements ------------------------------------ Architectural requirements cover characteristics and constraints on the overall construction of the system. 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.1 [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.2 [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] will support load balanced/near mirror sites. (xCR.17.16 - p39). 2.2 Interface (INT) Requirements -------------------------------- Interface requirements cover user interface and look-and-feel issues. 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). NR.INT.8 [The system] shall enable the integration of custom web interfaces for searching and retireving data from specific data sets. (CN) [Added after Requirements Workshop... Should be renumbered] 2.3 Capacity (CAP) Requirements ------------------------------- Capacity requirements cover the storage needs of the system. 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 (PER) Requirements ---------------------------------- Performance requirements cover such things as data transfer and throughput needs. 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 6GB 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 (AVA) Requirements ----------------------------------- Availability requirements address the constraints on system uptime and continuity of service. 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 hardware system downtime (CN). (needs to be quantified - suggestion 99.99 - given the load balancing/mirror configuration) NR.AVA.3 Best efforts shall be made to minimize software system downtime (CN). (consider software deployment issues) 2.6 Security (SEC) Requirements ------------------------------- Security requirements address the need to limit system access in order to protect system and data integrity. 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): [Note: This effects current PDS web site redesign.] Authenticated 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 (Science Community member) 5. Administrator Anonymous 1. General Public 2. Educational Community 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.7 [The system] shall restrict the ability to perform the administer function to the system administrator (CN). 2.7 Compatibility (CMP) Requirements ------------------------------------ Compatibility requirements describe the manner in which system componets must be able to interoperate in a heterogeneous computing environment. 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). [Note: This is controversial and should be examined further] 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 (STD) Requirements -------------------------------- Standards requirements describe the standards needed to support system operation. 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 ----------------------- Policy requirements describe the policies needed to support system operation. 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 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.13 [The PDS] shall provide a policy for responding to requests for hard media (such as DVD, external disk, etc), including those created by the system on demand (OO.3.1, xCR.14.2.7 - p55). NR.POL.14 Criteria for prioritization and development of web services. ****************************************************************************** NOTE: The following were deleted after working group analysis per Lyle Huber: NR.POL.xx [The PDS] shall adopt NASA processing level indicators and deprecate the CODMAC levels (OO.2.5, xCR.15.13 - p51). NR.POL.xx [The PDS] shall establish a canonical coordinate system for planetary targets, for example, planetocentric, east longitude (xCR.14.2.6 - p9). NR.POL.xx [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 (DOC) Requirements ------------------------------------ Documentation requirements describe the documentation needed to support system operation. NR.DOC.1 [The system] shall include a document describing the entire PDS archive lifecycle (xCR.13.50.2 - p36). NR.DOC.2 [The system] shall include 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 include 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 include an Operations Plan, including information on the the following topics (xCR.15.3 - p38, xCR.13.27 - p38): 1. Running system functions including failover 2. Maintaining and upgrading system software and hardware 3. Performing system backup and restore 4. Ingesting, validating, distributing, and archiving data 5. Scheduled failover testing NR.DOC.5 [The system] shall include 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 include complete documentation for tools and system APIs (OO.1.6, xCR.4.1.10 - p44). NR.DOC.7 The system shall include documentation for all interfaces, data structures and standards used for online as well as hard media distribution (e.g. DVD and external disk) (OO.2.13, xCR.14.2.14 - p48). 2.10 Support (SUP) Requirements ------------------------------- Support requirements indicate the personnel support needed to maintain the system and provide help to users. 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.2 The PDS shall shall provide a single e-mail address for all user feedback and requests for technical support (HQ). 2.11 Development (DEV) Requirements ----------------------------------- Development requirements describe the characteristics and constraints on the development and evolution of the system. 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 [End of Requirements List]