|
REQUIREMENTS TRACEABILITY MATRIX |
||
|
PDM TRACED TO SRD |
||
|
PROJECT : ISO Post Mission Archive |
||
|
SRD Identifier |
PDM Identifier |
SOFTWARE REQUIREMENT |
|
USER INTERFACE / BROWSE CATALOG |
||
|
General interface description |
||
|
S2.1.39 |
See ADD [RD-1]. |
The following data items will be held on-line as non-queriable browse data through the ICSA: POFs ICSFs COBs APF .... |
|
S2.1.40 |
See ADD [RD-1]. |
The following data items will be held on-line in a library format and be accessible through the ISO PMA user interface: SCC Report CAL Q MPS/RAM Patches ... |
|
S1.1.1 |
See ADD [RD-1]. |
The primary user interface to the ISO Post Mission Archive will consist of a set of documents on the WWW. |
|
S1.1.2 |
See ADD [RD-1]. |
This web interface will also provide access to certain resources which are not incorporated into the ICSA but which are part of the ISO Post Mission Archive. |
|
S1.1.3 |
See ADD [RD-1]. |
A secondary interface to the archive will be SPEVAL which will remain available for use by expert users. |
|
S1.1.4 |
See ADD [RD-1]. |
The primary query interface will allow searches for matches in the Observation Catalogue, according to constraints on both observation and non-observation parameters. |
|
S1.1.5 |
See ADD [RD-1]. |
Means will be also be provided to perform searches for entries other than observations in the Queriable part of the ICSA.HouseKeeping and Trend table data can be searched. |
|
S1.1.6 |
See ADD [RD-1]. |
When searching for observations the user will be able to conduct a sequence of separate queries adding the results of each to a single list. He will then be able to request datasets from that list. |
|
S1.1.7 |
See ADD [RD-1]. |
The user can create a "shopping basket" from the results of a query. This "shopping basket" can be modified by adding entries from new queries or by deleting entries. |
|
S1.1.8 |
See ADD [RD-1]. |
The user will be able to revise/refine previous searches by accessing and modifying the previously submitted filled-in query page. |
|
S1.1.9 |
See ADD [RD-1]. |
Where possible the interface will be constructed so as to be self explanatory to a user from the astronomical community. |
|
S1.1.10 |
See ADD [RD-1]. |
When the interface can not be made self-explanatory on line help will be provided. |
|
S1.1.11 |
See ADD [RD-1]. |
The number of actions demanded of the user between the point when he accesses the archive and the point when his query is answered should approach the minimum possible. |
|
Possible constraints on searches |
||
|
S1.1.12 |
See ADD [RD-1]. |
When possible the interface will be configurable by the user. |
|
S1.1.13 |
See ADD [RD-1]. |
When searching for observations the user will not be restricted to specifying fields in the primary observation catalogue. |
|
S1.1.14 |
See ADD [RD-1]. |
The user can constrain a query by specifying restrictions on the parameters initially used to specify the observation (including proposal parameters such as keywords). |
|
S1.1.15 |
See ADD [RD-1]. |
The user can constrain a query by specifying restrictions on a number of other parameters (Target Type, Data Quality,...). |
|
S1.1.16 |
See ADD [RD-1]. |
For searches restricted to a single instrument it will be possible to specify times in ITK. |
|
S1.1.17 |
See ADD [RD-1]. |
The user can constrain a query by specifying the sky position using a number of different coordinates. |
|
S1.1.18 |
See ADD [RD-1]. |
The user can specify a query using a target name instead of the coordinates. |
|
S1.1.19 |
See ADD [RD-1]. |
The interface will check if the target name is a recognised SSO if not SIMBAD/NED will be used. |
|
S1.1.20 |
See ADD [RD-1]. |
The user will be able to specify a list of targets to be used in a query.One means for him to do this will be to upload a file containing such list in a predefined format. |
|
S1.1.21 |
See ADD [RD-1]. |
A sky position will be considered to match any observation whose FOV it intersects/overlaps. |
|
S1.1.22 |
See ADD [RD-1]. |
The user will be able to constraint a search by specifying a wavelength or range of wavelengths. |
|
S1.1.23 |
See ADD [RD-1]. |
The user will be able to search on flux characteristics of the objects observed by ISO. |
|
S1.1.24 |
See ADD [RD-1]. |
The user will be able to search on color characteristics of the objects observed by ISO. |
|
S1.1.25 |
See ADD [RD-1]. |
The user will be able to constrain a search by selecting from a number of categories which characterise the nature of the observation, these characteristics will map onto different Instrument/AOT/filter combinations. |
|
S1.1.26 |
See ADD [RD-1]. |
The user will be able to constrain a search by selecting from the following categories: engineering data, activation sequence data,... |
|
S1.1.27 |
See ADD [RD-1]. |
Specification of a Wavelength being used to constrain filters rather than use filters directly. |
|
S1.1.28 |
See ADD [RD-1]. |
It will be the interface responsibility to resolve the user input into database values. |
|
S1.1.29 |
See ADD [RD-1]. |
Where the use of ISO-specific terms might be more convenient for an informed user such mechanism will be provided. |
|
S1.1.30 |
See ADD [RD-1]. |
Where the use of ISO-specific terms are used definitions/brief explanations will be provided. |
|
S1.1.31 |
See ADD [RD-1]. |
The user will be able to constrain a search by specifying constraints on housekeeping and trend data. |
|
S1.1.32 |
See ADD [RD-1]. |
The user will be able to constrain a search by specifying the version of the uplink installation used to schedule that observation. |
|
S1.1.33 |
See ADD [RD-1]. |
A range will be allowed as a constraint for any numerical parameter. |
|
S1.1.34 |
See ADD [RD-1]. |
Where an allowed parameter can only take one of a fixed set of discreet values then the user will be able to specify any subset of those values as a search constraint. |
|
The nature of constraints |
||
|
S1.1.35 |
See ADD [RD-1]. |
By default searches on the observation catalogue will only return good data, where this means that processing was good to at least the raw data level. |
|
S1.1.36 |
See ADD [RD-1]. |
The query will be done comparing against the "real data used" rather than the one intended by the proposer when those are different. |
|
S1.1.37 |
See ADD [RD-1]. |
|
|
S1.1.38 |
See ADD [RD-1]. |
The user will be allowed to combine freely constraints on independent parameters. |
|
S1.1.39 |
See ADD [RD-1]. |
The user will be allowed to combine freely constraints on non-independent characteristics of observations where such constraints are not contradictory. |
|
S1.1.40 |
See ADD [RD-1]. |
By default searches will not be restricted to observations corresponding to AOTs, nor to any subset deemed to be "standard". |
|
Query submission |
||
|
S1.1.41 |
See ADD [RD-1]. |
Where possible it will be checked that the user’s input makes sense before submitting a query. |
|
S1.1.42 |
See ADD [RD-1]. |
Users will be able to submit queries in batch mode. |
|
S1.1.43 |
See ADD [RD-1]. |
The interface will prompt the user for his e-mail address at the appropriate point. |
|
S1.1.44 |
See ADD [RD-1]. |
When doing interactive queries the engine may decide that the query is going to take too long and the interface will inform the user and give him the option to submit in batch mode. |
|
Presentation of results |
||
|
S1.1.45 |
See ADD [RD-1]. |
On completion of a query the user will be presented with the total number of matches found. |
|
S1.1.46 |
See ADD [RD-1]. |
Where observations can be deemed to have matched a query to a lesser or greater degree they will be sorted. |
|
S1.1.47 |
See ADD [RD-1]. |
The interface will present the user means to access the matches found up to the maximum number of results buffered. |
|
S1.1.48 |
See ADD [RD-1]. |
The user will have the option to specify the number of matches that he will be presented with at a time. |
|
S1.1.49 |
See ADD [RD-1]. |
The user will be able to elect to see every Nth match where N is a number chosen by him. |
|
S1.1.50 |
See ADD [RD-1]. |
Where possible the display of the next batch of matching records will not require the repeat of an inherently slow query. |
|
S1.1.51 |
See ADD [RD-1]. |
The matches displayed as a single batch will be displayed as a series of rows. |
|
S1.1.52 |
See ADD [RD-1]. |
Each row will include a brief description of the observation, where an observation is proprietary no postage stamp nor flux information will be displayed. |
|
S1.1.53 |
See ADD [RD-1]. |
It will be made clear to the users than only the owners can download proprietary data. |
|
S1.1.54 |
See ADD [RD-1]. |
The description will include quality information as held in the observation catalogue. |
|
S1.1.55 |
See ADD [RD-1]. |
The description will identify non-standard products as such. |
|
S1.1.56 |
See ADD [RD-1]. |
When the product is composed of data that can meaningfully be represented graphically and where the data is still not proprietary, a postage stamp will be added. |
|
S1.1.57 |
See ADD [RD-1]. |
Where that postage stamp can be made small it will be included in the row, if not a hyperlink will be provided. |
|
S1.1.58 |
See ADD [RD-1]. |
The user will be able to scroll and zoom around the postage stamp image using his browser. |
|
S1.1.59 |
See ADD [RD-1]. |
The default view in the postage stamp should be an image showing a line in the spectrum matching the user wavelength requirement if any was given. |
|
S1.1.60 |
See ADD [RD-1]. |
Each row will include a hyperlink to a full description of the observation. |
|
S1.1.61 |
See ADD [RD-1]. |
Each row corresponding to still proprietary data will include the release date for the observation. |
|
S1.1.62 |
See ADD [RD-1]. |
Where an observation is part of a concatenated chain or a linked sequence a hyperlink will be included to a page containing the full chain. |
|
S1.1.63 |
See ADD [RD-1]. |
A caveat cautioning users about the scientific use of postage stamp will be presented. |
|
S1.1.64 |
See ADD [RD-1]. |
When displaying a list of observations, BC should display the quality of the observations of the baseline products as well as the OFPR observation (if any) and the OLP version. |
|
Miscellaneous |
||
|
S1.1.65 |
See ADD [RD-1]. |
The interface will provide for the direct input of an SQL query and the presentation of the results. |
|
S1.1.66 |
See ADD [RD-1]. |
The web interface will provide sufficient details of the archive database as to allow expert users to enter the SQL queries. |
|
S1.1.67 |
See ADD [RD-1]. |
The interface will provide easy access to logic and uplink calibration file version given an uplink version number. |
|
USER INTERFACE / DOWNLOAD PRODUCTS |
||
|
Retrieval |
||
|
S1.2.1 |
See ADD [RD-1]. |
In order to download products the user has to be registered. |
|
S1.2.2 |
See ADD [RD-1]. |
The user will be able to elect baseline product or OFRP product. |
|
S1.2.3 |
See ADD [RD-1]. |
For user wishing no special privileges to access proprietary data a facility will be provided to register on line. |
|
S1.2.4 |
See ADD [RD-1]. |
The interface will provide a facility to change the user password. |
|
S1.2.5 |
See ADD [RD-1]. |
Two methods of data retrieval will be available. |
|
S1.2.6 |
See ADD [RD-1]. |
When possible, estimates will be given of the expected ftp download time. |
|
S1.2.7 |
See ADD [RD-1]. |
The first method will be direct ftp download. |
|
S1.2.8 |
See ADD [RD-1]. |
The second method will be snail-mail delivery on a CD-ROM. |
|
S1.2.9 |
See ADD [RD-1]. |
For every observation the user can specify what level of products they want. |
|
S1.2.10 |
See ADD [RD-1]. |
The facility will be provided to browse any of the relevant auxiliary data files defined as being available in an appropriate form in the Data Model. |
|
S1.2.11 |
See ADD [RD-1]. |
All ftp should be by default of compressed data.The standard compression formats and uncompressed data should be available as options. |
|
S1.2.12 |
See ADD [RD-1]. |
For whatever transfer the user will be allowed to elect CD-ROM delivery or ftp transfer. |
|
S1.2.13 |
See ADD [RD-1]. |
Where a user elects to request CD-ROM he will be told to expect that delivery in the post, where he elects ftp transfer he will be told to expect an e-mail informing him when the data is ready. |
|
S1.2.14 |
See ADD [RD-1]. |
The interface will present the users id and password to the DE so his registration and proprietary data can be checked. |
|
S1.2.15 |
See ADD [RD-1]. |
For all requests for > 100MB the default transfer method will be CD-ROM.For all transfers of < 10MB the default method will be ftp. |
|
USER INTERFACE / SPEVAL INTERFACE |
||
|
S1.3.1 |
See ADD [RD-1]. |
No attemp will be made to integrate the SPEVAL interface with the primary WWW based one. |
|
S1.3.2 |
See ADD [RD-1]. |
SPEVAL Users will be registered and given appropriate accounts. |
|
ARCHIVE ENGINE / DATA ENGINE (DE) |
||
|
Requirements related to DE functionality |
||
|
S2.1.1 |
See ADD [RD-1]. |
Use of underlying DBMS to ensure syntactic correctness. |
|
S2.1.2 |
User Access Users See ADD [RD-1]. |
Storing of User names, passwords and access rights. |
|
S2.1.3 |
Users See ADD [RD-1]. |
Allow change of password. |
|
S2.1.4 |
User Access See ADD [RD-1]. |
Users should have access to all public data. |
|
S2.1.5 |
User Access See ADD [RD-1]. |
Owner of data has access to own data. |
|
S2.1.6 |
User Access See ADD [RD-1]. |
Some users have access to all data. |
|
S2.1.7 |
See ADD [RD-1]. |
Performance shall be optimized during operational phase. |
|
S2.1.8 |
Batch Details Batch Results Batch Request See ADD [RD-1]. |
Identification of long queries and provision of batch facilities. |
|
S2.1.9 |
See ADD [RD-1]. |
Priority scheduling. |
|
S2.1.10 |
See ADD [RD-1]. |
Complex SQL queries allowed. |
|
S2.1.11 |
See ADD [RD-1]. |
Results shall order search results self-evidently. |
|
S2.1.12 |
TBD. |
Store information on product size, time to download, time to process. |
|
S2.1.13 |
See ADD [RD-1]. |
Asses connection speeds for registered users. |
|
S2.1.14 |
See ADD [RD-1]. |
Information on CDROM distribution stored. |
|
Requirements related to DE searchable content |
||
|
S2.1.15 |
TBD. |
Information about OLP processing time for each observation stored. |
|
S2.1.16 |
Product Catalogue |
Locations of all standard products on the CDROM jukeboxes stored. |
|
S2.1.17 |
Pointing Slewing Aid |
Positional information for every observation stored. |
|
S2.1.18 |
Pointing Slewing Aid |
Identification of observations based upon search area. |
|
S2.1.19 |
Observations |
Possible to distinguish between SSO and non-SSO observations. |
|
S2.1.20 |
Overlapping Observation List Linked Observation Information |
Cross-reference of observations which cover the same region. |
|
S2.1.21 |
Linked Observation Information. |
Access to linked or concatenated observations for any selected observation. |
|
S2.1.22 |
Simbad Ned Targets |
SIMBAD/NED source types stored. |
|
S2.1.23 |
Keywords |
Keywords for each proposal stored. |
|
S2.1.24 |
Wavelength Ranges |
Wavelength range for each observation stored. |
|
S2.1.25 |
TBW. |
Flux and color characteristics for each observation stored. |
|
S2.1.26 |
Planning Info |
Planned observational parameters stored. |
|
S2.1.27 |
Observations |
Quality ratings for BKRP and OFRP products stored. |
|
S2.1.28 |
Observations |
Access to engineering window and activation/deactivation sequence data. |
|
S2.1.29 |
TBW. |
Times in UTC, UTK and ITK. |
|
S2.1.30 |
Observations |
Access to phase in orbit. |
|
S2.1.31 |
Uplink |
Uplink and associate component version numbers available for each revolution. |
|
S2.1.32 |
Postcards Icons |
Postage stamps to be introduced. |
|
S2.1.33 |
Aperture Pointing History CAM Compact Status CAM Diagnostics CAM Glitch Rates CAM LW Detector EOI Reset Values CAM LW Detecror Reset Values CAM SW Detector EOI Reset Values CAM SW Detector Reset Values LWS Compact Status PHT C Detector Responsivities PHT Compact Status PHT P Detector Responsivities Product Catalogue Sources Detected By CAM SWS Compact Status SWS Dark Current SWS Glitch Rate SWS Photometric Flux Check |
ICSA shall contain all data from current IPA databases. |
|
S2.1.34 |
Products Product Catalogue |
All products of OLP Archive accessible. |
|
S2.1.35 |
Range of OLP products easily modifiable. |
|
|
S2.1.36 |
Keywords Proposals |
User specified information w.r.t. an observation shall be searchable. |
|
S2.1.37 |
Duplication of information kept to a minimum. |
|
|
Requirements related to queriable data |
||
|
S2.1.38 |
Aperture Pointing History CAL G BKRP Validity CAL G OFRP Validity CAM Common CAM Compact Status CAM Diagnostics CAM Glitch Rates CAM LW Detector EOI Reset Values CAM LW Detector Reset Values CAM Measurement Details CAM Reference Coordinates CAM SW Detector EOI Reset Values CAM SW Detector Reset Values Co Investigators Failed Command History Fixed Time Criteria General LWS Header Information Guide Star ICS Extract Institutes Instrument Instantaneous Pointing- History Header Kernal Log Keywords Linked Observation Information LWS Automatic Analysis Results LWS Automatic Analysis Results -Header LWS Common LWS Compact Status LWS Edited Raw Data Header LWS Housekeeping ERD LWS Illuminator Results LWS Measurement Details LWS Product Sizes LWS Scan Group Information LWS Scan Summary LWS Standard Processed Data LWS Standard Processed Data Header Observations Observers Orbit Data PHT C Detector Responsivities PHT Calibration Details PHT Chopper Details PHT Common PHT Compact Status PHT Geometry PHT Measurement Details PHT P Detector Responsivities PHT PCS Planning Info POF Extract Processing Times Product Catalogue Proposals Raster Map Details Revolutions RTA QLA Solar Weather Sources Detected By CAM SPEVAL Parameters SPEVAL Values Sun Earth SWS Common SWS Compact Status SWS Dark Current SWS General House Keeping SWS Glitch Rate SWS Measurement Details SWS Photometric Flux Check SWS Standard Processed Data Header Telemetry Drop Log Time References Uplink |
Queriable browse data items. |
|
Requirements related to linked and viewable data |
||
|
S2.1.39 |
Calibration Details CALQ CAM CALQ PHT CALQ SWS CALU Files CAM Calibration Details CCS COB COIF CUS4 CUS4 Validity External Information ICS Definition Templates ICSF IDB Definition IFPG IFPG Values Instrument Station Reports ISR Events IS Reports LWS Calibration Details Non Standard Commanding NSO Events NSOS OLP Report PCS PCS Validity PCSS PHOT Monitor Log PHT Calibration Details POF Realtime Revolution Reports SCC Calibration Data SCREW SOAR SPR SWS Calibration Details |
Non-queriable browse data items. |
|
Requirements related to On-Line library |
||
|
S2.1.40 |
See ADD [RD-1]. |
Linked on-line library data items. |
|
Requirements related to internal On-Line library |
||
|
S2.1.41 |
See ADD [RD-1]. |
Off-line library data items. |
|
Requirements related to Paper library |
||
|
S2.1.42 |
See ADD [RD-1]. |
Paper document data items. |
|
Requirements related to Off-Line Storage |
||
|
S2.1.43 |
See ADD [RD-1]. |
Data items archived to DAT. |
|
Requirements related to Downloadable software |
||
|
S2.1.44 |
See ADD [RD-1]. |
Downloadable software. |
|
Requirements related to user accessable software |
||
|
S2.1.45 |
See ADD [RD-1]. |
User-accessible software. |
|
Requirements related to direclty accessable software |
||
|
S2.1.46 |
See ADD [RD-1]. |
Accessible software. |
|
Requirements related to locally accessable software |
||
|
S2.1.47 |
See ADD [RD-1]. |
Indirectly accessible software. |
|
Requirements related to Off-Line archive software |
||
|
S2.1.48 |
See ADD [RD-1]. |
Software archived to DAT. |
|
ARCHIVE ENGINE / RETRIEVE PRODUCTS |
||
|
S2.2.1 |
See ADD [RD-1]. |
Filenames for FTP should be 4 letters uppercase |
|
S2.2.2 |
See ADD [RD-1]. |
Baseline products copied directly to FTP + Email |
|
S2.2.3 |
See ADD [RD-1]. |
Medium and reprocessed requests within 72 hours |
|
S2.2.4 |
See ADD [RD-1]. |
Write to a CD holding area if CD requested |
|
S2.2.5 |
See ADD [RD-1]. |
OFRP performed if requested |
|
S2.2.6 |
See ADD [RD-1]. |
Data compressed if requested |
|
S2.2.7 |
Product Level See ADD [RD-1]. |
RP to allow part or all of an obs to be retrieved |
|
S2.2.8 |
See ADD [RD-1]. |
Proprietary rights will be respected |
|
PIPELINE PROCESSING |
||
|
S3.1 |
Processing Times See ADD [RD-1]. |
BKRP will be performed on every observation to produce all baseline products. |
|
S3.2 |
See ADD [RD-1]. |
The pipeline should produce a survey product for all instruments (BKRP). |
|
S3.3 |
See ADD [RD-1]. |
OFRP should complete in <24 hours or <72 hours at peak times. |
|
S3.4 |
See ADD [RD-1]. |
BKRP will generate baseline products to produce the baseline observation datasets. |
|
S3.5 |
See ADD [RD-1]. |
BKRP shall be automatic and shall minimize human intervention. |
|
S3.6 |
See ADD [RD-1]. |
BKRP and OFRP will not perform systematic Quality Control. |
|
S3.7 |
See ADD [RD-1]. |
Quality Control will be performed independently either as part of OLP integration or by an operator. |
|
S3.8 |
See ADD [RD-1]. |
OFRP shall be able to detect and report errors during processing. |
|
S3.9 |
See ADD [RD-1]. |
BKRP and OFRP shall be able to be monitored by the OLP operator. |
|
S3.10 |
See ADD [RD-1]. |
The raw data (TDF, OH, IS reports, AH) will be accessible on-line for BKRP and OFRP. |
|
S3.11 |
See ADD [RD-1]. |
BKRP will leave shape-2 products on-line for future access for OFRP purposes. |
|
S3.12 |
See ADD [RD-1]. |
OFRP will start from TDF FS results. |
|
S3.13 |
See ADD [RD-1]. |
BKRP and OFRP shall calculate the processing time for each OLP step (Derive_ERD, Derive_SPD, Auto-Analysis) for each observation. |
|
S3.14 |
See ADD [RD-1]. |
BKRP and OFRP shall be able to be conducted at the same time. |
|
CDROM DISTRIBUTION |
||
|
S4.1 |
See ADD [RD-1]. |
CDROM distributed at a given owner/address |
|
S4.2 |
See ADD [RD-1]. |
Filenames with ISO-9660 standard |
|
S4.3 |
See ADD [RD-1]. |
CDROM up to 2 weeks to be shipped |
|
UPDATE ARCHIVE |
||
|
S5.1 |
See ADD [RD-1]. |
UA imports products from BKRP |
|
S5.2 |
See ADD [RD-1]. |
UA ingests or create postage stamps |
|
PERFORMANCE REQUIREMENTS |
||
|
SP.1 |
See ADD [RD-1]. |
Result of small search within 5 minutes |
|
SP.2 |
See ADD [RD-1]. |
1 to 5 baseline obs datasets available within 1 hour |
|
SP.3 |
See ADD [RD-1]. |
10 to 25 obs dataset (from OFRP) available within 24 hours (72 during peak time) |
|
SP.4 |
See ADD [RD-1]. |
BKRP for all mission within 3 months |
|
INTERFACE REQUIREMENTS |
||
|
SI.1 |
See ADD [RD-1]. |
ISO PMA User I/F on WWW |
|
SI.2 |
See ADD [RD-1]. |
Interface to SIMBAD/NED |
|
SI.3 |
See ADD [RD-1]. |
Tool to retrieve TDF group file by time key |
|
OPERATIONAL REQUIREMENTS |
||
|
SO.1 |
See ADD [RD-1]. |
IPA available until ICSA available |
|
SO.2 |
See ADD [RD-1]. |
BKRP and OFRP minimize operator intervention |
|
SO.3 |
See ADD [RD-1]. |
BKRP and OFRP can be used simultaneously |
|
RESOURCE REQUIREMENTS |
||
|
SRes.1 |
See ADD [RD-1]. |
ICSA with necessary disk storage |
|
SRes.2 |
See ADD [RD-1]. |
ICSA with necessary CPU and memory |
|
SRes.3 |
See ADD [RD-1]. |
OLP under OpenVMS using FORTRAN and IDL |
|
SRes.4 |
See ADD [RD-1]. |
ICSA with SYBASE RDMS |
|
SRes.5 |
See ADD [RD-1]. |
User I/F, Update Archive and Archive Engine under SUN/SOLARIS |
|
SRes.6 |
See ADD [RD-1]. |
CDROM distribution under SUN/SOLARIS and PC |
|
SRes.7 |
See ADD [RD-1]. |
Baseline products hold on CDROM attached to AE SUN platform |
|
SECURITY REQUIREMENTS |
||
|
SS.1 |
See ADD [RD-1]. |
ICSA protect proprietary rights |
|
SS.2 |
See ADD [RD-1]. |
ICSA accessible from external world |
|
SS.3 |
See ADD [RD-1]. |
Retrieval from ICSA will require user registration |
|
SS.4 |
See ADD [RD-1]. |
ICSA will protect people name and address |
|
RELIABILITY REQUIREMENTS |
||
|
SRel.1 |
See ADD [RD-1]. |
Raw Data on DAT in different building |
|
SRel.2 |
See ADD [RD-1]. |
All other data needed on DAT in different building |