Technical Report NEESgrid-2003-13 www.neesgrid.

org
(Whitepaper Version: 1.0) Last modified: June 24, 2003

NEESgrid Requirements Traceability Matrix

Thomas A. Finholt, Dan Horn, Suzandeise Thom

Collaboratory for Research on Electronic Work, School of Information, University of Michigan

Feedback on this document should be directed to [email protected]

Acknowledgment: This work was supported primarily by the George E. Brown, Jr. Network for Earthquake Engineering Simulation (NEES) Program of the National Science Foundation under Award Number CMS-0117853.

NEESgrid Requirements Traceability Matrix

Page 1

Summary
This document presents the Requirements Traceability Matrix created by the User Requirement team and the methodology used to generate it. The Requirements Traceability Matrix is a representation of user requirements aligned against system functionality. It is used to ensure that all requirements are being met by the system deliverables. The Requirements Traceability Matrix developed for the NEESgrid project indicates that 61.3% of the user requirements are being addressed by the system integration team and will be implemented in the first version of the system. 18.7% of the user requirements are not being addressed by the system integration effort. The remaining 20% of the user requirements need to be discussed further so that a determination can be made on whether user needs are being met.

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix Introduction

Page 2

In the report from the March 2003 Site Visit Team, it was strongly recommended that the NEESgrid project complete a Requirements Traceability Matrix (RTM). This document presents the RTM created by the User Requirement team and the methodology used to generate it. The Requirements Traceability Matrix is a representation of user requirements aligned against system functionality. It is used to ensure that all requirements are being met by the system deliverables. This technique is commonly used in large-scale government software development projects, such as the Center-TRACON Automation System, the National Polar-Orbiting Operational Environmental Satellite System (NPOESS), and the National Integrated Land System (NILS). It is now increasingly being used in commercial software development projects as well.

Methodology
The creation of the NEESgrid Requirements Traceability Matrix involved the following steps, which are explained in more detail in the pages that follow. 1. 2. 3. 4. Identification of user requirements Identification of system components Estimation of effort spent on each system component Mapping of system components to user requirements

1 - Identification of user requirements

The first step in the creation of a Requirements Traceability Matrix was the identification of user requirements. A list of user requirements was generated from the following NEESgrid documents: NSF Program Solicitation (http://www.nsf.gov/pubsys/ods/getpub.cfm?nsf007) NSF Site Visit Reports (from 2001, 2002 and 2003) System Overview (http://neesgrid.org/documents/NEESSystemOverview2_1.pdf) NEESgrid User Requirements Document v2.0 (http://www.neesgrid.org/documents/NEESgrid_UR_Feb15.2002.pdf) NEESgrid User Requirements Document v3.0 (http://neesgrid.org/documents/NEESgrid_User_Requirements_v3_0.pdf) User requirements were then grouped into the following categories: Collect and Store data Search data Manage data Database Administration Hybrid experiments Data Viewing

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix Synchronous collaboration Asynchronous collaboration Other Collaboration Tools - Synchronous and Asynchronous Simulation codes Repository Curation Access to high performance computing resources Security Safety Usability Network Performance System capacity Other system characteristics Support for future user constituents

Page 3

2 - Identification of system components

The second step in the creation of the RTM was the identification of system components. The documents that served as input to the identification of system components are listed below. NEESgrid System Baseline Description v 0.9.5 (http://neesgrid.org/documents/SI_SBD_v09_5_03_03_2003.pdf) NEESgrid System Architecture v1.0 and v1.1 (http://neesgrid.org/documents/NEESgrid_SA_Feb15.2002.pdf, http://neesgrid.org/documents/NEESgrid_SystemArch_v1.1.pdf) The following system components, or functional areas, were identified. Collaboration Tools - CHEF Data repository Data viewer Data streamer Electronic Lab Notebook Telepresence Data acquisition Hybrid experiments Simulation repository Underlying GRID infrastructure

3 - Estimation of effort spent on each system component

An estimate of effort was generated for each system component based on the allocation of budget to different system integration activities for the first three years of the project. The WBS structured presented in the Project Execution Plan (http://neesgrid.org/documents/NEESgrid_PEP_03_03_2003.pdf) was used for this analysis.

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 4

Budget for first 3 years

1 2 3 4 WBS System Components Information Services Components Community Outreach Management Budget $ $ $ $ $ 3,523,000.00 3,120,370.00 1,055,991.00 1,851,301.67 9,550,662.67

The effort estimate included WBS items 1 and 2, but excluded items 1.2 and 2.2.1. Budget considered in Effort Estimate
1 2 1.2 2.2.1 System Components Information Services Components Deployment, Operations & Community Support Prototype Collaborative Environment $ 3,523,000.00 $ 3,120,370.00 $ (1,565,000.00) $ (36,050.00) $ 5,042,320.00

The table below shows the effort estimate for each system component. Certain WBS items, such as 1.1.1-System Requirements Specification, or 1.1.8-Documentation, were spread across several functional areas.

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

System Component Effort Estimate 2.2.3 1 Collaboration Tools CHEF 17% $ 838,306.50 2.2.4 2.4.1 2.4.2 2.4.3 2.4.4 2 Data repository 15% $ 750,000.00 2.4.5 2.2.2 2.2.4 3 Data viewer 8% $ 413,163.50 1.1.2 1.1.4 1.1.2 1.1.1 4 5 Data streamer Electronic Lab Notebook 2.1.1 1.1.2 2.1.2 6 Telepresence 17% $ 867,150.00 2.1.3 1.1.4 1.1.2 1.1.1 7 8 Data acquisition Hybrid experiments 7% 3% $ $ 352,930.00 168,175.00 1.1.8 1.1.7 1.1.1 2.3.1 2.3.2 9 Simulation repository 9% $ 450,000.00 2.3.3 1.1.3 1.1.1 1.1.6 1.1.4 1.1.5 1.1.7 10 Underlying GRID infrastructure 17% 100% $ $ 849,665.00 1.1.8 5,042,320.00 Remote Teleobservation NEESgrid Early Adoption Remote Teleoperation Documentation Access to Experimental Apparatus and Instruments (Labview) NEESgrid Early Adoption System Requirements Specification Documentation Collaboration Support (NCTP) System Requirements Specification Community Simulation Tool Archive Repository of Sample Community Code Results Usability Enhancements for Community Codes NEESgrid Security Enhancements System Requirements Specification Access to data Access to Experimental Apparatus and Instruments Access to simulation codes Collaboration Support Documentation 7% $ 352,930.00 1.1.8 WBS

Page 5
Adaptation of CHEF for Collab. Svcs. on NEESgrid (grid enabling CHEF, Grid FTP portlet) Documentation Recommend standards for data/metadata models Specification for data services architecture APIs for data harvesting, mgmt and access Curated data repository Documentation Visualization support for collaboration tools Documentation NEESgrid Early Adoption Access to Experimental Apparatus and Instruments (NSDS) NEESgrid Early Adoption System Requirements Specification Documentation

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 6

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 7

4 - Mapping of system components to user requirements

Finally, system components were mapped to one more user requirements. The party responsible for each system component was then asked to answer two questions about each user requirement: 1. Are you doing work that satisfies this requirement? (Y/N) 2. Give a brief description of deliverable(s) that result from this work.

Requirement Traceability Matrix

Information about the user requirements and about the system components was compiled to create the Requirement Traceability Matrix. A summarized version of the RTM is shown below and contains the following information: User requirement (category and description) System component that should fulfill the user requirement Budget Status (budgeted/ not budgeted) Assessment of system integrators as to whether the system component indicated addresses the user requirement Brief description of deliverable(s) that result from the work performed by the system integrator to fulfill the user requirement The Requirement Traceability Matrix indicates that 61.3% of the user requirements are being addressed by the system integration team and that 18.7% are not being addressed. The remaining 20% will have to be discussed further in order to determine whether the system integration effort is adequately fulfilling those user requirements.

Assessment of user requirements Y N Need further discussion Total 46 14 15 75 61.3% 18.7% 20.0% 100%

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 8

Requirement Traceability Matrix

Are you doing work that satisfies this requirement? Budget Status (Y/N) budgeted budgeted budgeted Y Y Y

User Requirement Collect and Store data Acquire simulation results Acquire numerical data from laboratory experiment Collect and Store data (automatically) Acquire numerical data from Collect and Store data laboratory experiment (manually)

System Component Data acquisition Data acquisition Data acquisition Labview Labview Labview

Brief description of deliverable(s) that result from this work Probably a custom driver; work in early stages now Zombie DAQ program in released code Example DAQ code in release ADXL and DI-194 drivers and example code, http://www.mcs.anl.gov/neesgrid/adxl.html and http://www.mcs.anl.gov/neesgrid/dataq.html IEEE-1394 (Firewire) code and results, at http://www.mcs.anl.gov/neesgrid/firewire.html

Collect and Store data Acquire data from field investigation Data acquisition Acquire video/photographs from Collect and Store data laboratory experiment Acquire data from other sources (e.g., historical data or non-NEES data) (manually) for Collect and Store data comparison/overlay of data Store simulation and experiment Collect and Store data results Interface allowing researchers to bring along their own data acquisition system, sensors, or Collect and Store data payload experiments Data acquisition

Labview Labview

budgeted budgeted

Y Y

Data acquisition Data repository

Labview Data storage

budgeted budgeted

Y Y

Protocol docs, example non-Labview code, ADXL & DI194 NEES File Management Service to be released in Alpha 2

Data acquisition

Labview Labview

budgeted budgeted

Y Y

Protocol documentation and examples, on http://www.mcs.anl.gov/neesgrid/ NTCP and related control system work in progress the metadata repository will enable the community to characterize their work using metadata objects

Tool for inter-linking related Collect and Store data experimentation sessions Data acquisition Tools for characterizing a community/location/ structure/project (as basis for search and Collect and Store data comparison) Data repository

Metadata generation

budgeted

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 9

User Requirement System Component Easy tool for supplying metainformation as project proceeds Collect and Store data (electronic notebook) Data repository Metadata generation Metadata ingestion tools (.provide the capability to excerpt information from the electronic notebook and use it to populate the metadata Collect and Store data model) Data repository Metadata generation Manual metadata input (human sensor data recording as a specific Collect and Store data metadata acquisition agent) Data repository Metadata generation Collect and Store data Store metadata Common/standard data and Collect and Store data metadata formats Data repository Metadata generation

Are you doing work that satisfies this requirement? Budget Status (Y/N) budgeted Y

Brief description of deliverable(s) that result from this work integration of Nestor's e-notebook with repo (Alpha 2)

budgeted budgeted budgeted

Y Y Y

Alpha 2 - batch uploading in XML format Alpha 1 - CHEF GUI NEES Metadata Service - Alpha 1 Community will develop with guidance from SI. ongoing. Strawman released. data working in Aug 03 framework for format conversion and example implementations will be provided. data repository will support any format for file management capabilities, metadata repository will support XML interchange format and other formats can be translated into that format

Data repository

Metadata generation

budgeted

Collect and Store data Support for multiple data formats

Data repository

Metadata generation

budgeted

Develop a metadata registry which enforces business rules for Collect and Store data specification of metadata elements Data repository Metadata-driven lifecycle Collect and Store data management for objects Collect and Store data Utilize controlled vocabulary Data repository Data repository

Metadata generation Metadata generation Metadata generation

budgeted budgeted budgeted

??? ??? Y

I don't know what "business rules" means. validation will be supported in Alpha 2 I don't know what "lifecycle management" means. The repo supports versioning in Alpha 1 That is validation - will be supported in final release

Data streaming/ automatically archive experimental data to central repository (OR to local archive first Collect and Store data and then to central, after validation) Data streamer

NSDS

budgeted

???

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 10

User Requirement Optimize data compression while Collect and Store data retaining data quality

System Component Data repository Data storage

Are you doing work that satisfies this requirement? Budget Status (Y/N) budgeted N

Brief description of deliverable(s) that result from this work

Search data

Search data and metadata

Data repository

Data discovery

budgeted

Y/N

Metadata search will be supported in final release, but search of data will only be supported in a limited fashion data search will be supported by associating metadata with data objects and searching the metadata. derived data can be linked to raw data with metadata elements a framework for interface with external data resources, and example implementation for external sources of earthquake-related data (e.g., ANSS) will be provided Native Chef WT.NG tool for viewing archived experiment data and common UI to collab tools, but not simulation tools

Search data

Search for raw data and data derivatives

Data repository

Data discovery

budgeted

Search data

Search for historical earthquakerelated data

Data repository

Data discovery

budgeted

Manage data Manage data Manage data

Common interfaces to widely used tools (e.g. Matlab) Data viewer Manipulate experiment data (using tools such as Excel, MathCAD and Mathematica) Data repository "Clean" experiment data Data repository

Stored data viewing

budgeted

NOT budgeted N NOT budgeted N what is meant by "database"? the CHEF interface released in Alpha 1 allows remote management of the repository and the data/metadata in it (at the central repository) -- sites must provide site-specific backup capabilities what kind of integrity?

Database Administration Database Administration Database Administration

Remote database management

Data repository

NOT budgeted ??? NOT budgeted Y NOT budgeted ???

Backup-restore/archive-recovery of data Data repository Assure data integrity Data repository

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 11

User Requirement

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work NSDS, NTCP, NTCP drivers for proxy server and Matlab, Matlab interfaces to NTCP (being done by Erik Johnson) We provide interfaces to support hybrid experiments. However, sites need to design their own experiments, write their own computational simulation code, and provide (in some cases) drivers to interface with their own local equipment.

Hybrid experiments

Hybrid experiments

Hybrid experiments

NTCP

budgeted

Y/N

Data Viewing Data Viewing

Time synchronization of data and video streams

Data viewer

Real-time data viewing Stored data viewing budgeted Real-time data viewing budgeted

Y Y

Options in data viewer for selecting multiple channels of stored data, and displaying the data synchronized with their time stamps. Option on data viewer to display real time experiment data. Providing data viewer which gives access to experiments from multiple sites (but not multiple sites during a single experiment, nor Telepresence) Option in Data Viewer to display multiple channels in one view.

Real time access to visualization of sensor data Data viewer Access to visual, text, and algorithm info from multiple sites during experiment Data viewer Tool for overlaying data 3D visualization tools for analyzing results Data viewer Data viewer

Data Viewing Data Viewing Data Viewing

Real-time data viewing Stored data viewing budgeted Real-time data viewing Stored data viewing budgeted Real-time data viewing Stored data viewing budgeted

Y Y N

Synchronous collaboration

Teleoperation

Telepresence

Remote Teleoperation budgeted

only partially

Teleoperations for remote controlled camera is operational. Teleoperations for instruments is now under the direction of the ISI Team which is defining NTCP and will perform all other remote operations. A remote control interface using the reference implementation of Labview will be written by ANL but it is waiting for NTCP to be completed by ISI.

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 12

User Requirement

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work Observation of the experimental laboratory space using Video Cameras is operational and handled by the TPM thin-www client. Streaming data from sensors is now handled by NSDS and displayed by the CHEF Viewer . A NSDS interface using the reference implementation of Labview has been completed. This is operational in the TPM thin-www client interface. The Video system design operates at a maximum rate of NTSC not "very high speed". Very High Speed video is out of scope. Native Chat tool being developed as part of WT.NG

Synchronous collaboration Synchronous collaboration Synchronous collaboration Synchronous collaboration

Teleobservation Remote control of cameras

Telepresence Telepresence

Remote Teleobservation Remote Teleobservation Remote Teleobservation Chat

budgeted budgeted

only partially Y

Ability to handle very high-speed video in real time (for telepresence) Telepresence Chat Collaboration Tools CHEF

not budgeted budgeted

N Y

Synchronous collaboration Synchronous collaboration Synchronous collaboration Synchronous collaboration Asynchronous collaboration Asynchronous collaboration

Videoconferencing services (discovery of MCUs) Track who else is on Data conferencing (remote sharing of data)

Underlying GRID infra. Collaboration Tools CHEF Collaboration Tools CHEF

Collaboration services budgeted Presence awareness budgeted

N Y

It's not clear that this is still a requirement; however, if it is, the deliverable would be an MDS provider listing MCU resources
User Present list developed as part of standard WT.NG

NOT budgeted N NOT budgeted N NOT budgeted N Synopsis tools showing recent activity, and notification service to let users know of changes being developed as part of WT.NG

Collaboration Tools Shared whiteboard with telepointers CHEF Document version control Notify collaborators about changes or additions to shared work Collaboration Tools CHEF Collaboration Tools CHEF

Resource sharing

budgeted

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 13

User Requirement Other Collaboration Tools - Synchronous and Asynchronous

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work

Threaded discussion tool

Collaboration Tools CHEF

Threaded discussion budgeted

Native Chef tool being developed as part of WT.NG Data acquisition: IEEE-1394 (Firewire) results and code, http://www.mcs.anl.gov/neesgrid/firewire.html Data viewer: We are working on a stored (archived) data viewer, but not on recording audio or video. Native Chat tool being developed as part of WT.NG Native Chef capability being developed as part of WT.NG Native Chat tool for Resources being developed as part of WT.NG Permissions controls being developed as part of Chef, WT.NG

Other Collaboration Tools - Synchronous and Asynchronous Other Collaboration Tools - Synchronous and Asynchronous Other Collaboration Tools - Synchronous and Asynchronous Other Collaboration Tools - Synchronous and Asynchronous Other Collaboration Tools - Synchronous and Asynchronous

Video/audio recording and session playback

Data acquisition Data viewer

Labview Stored data viewing Calendaring and scheduling Workspace policies Resource sharing Workspace policies

budgeted budgeted budgeted budgeted budgeted

Y Y Y Y Y

Scheduling application (people and Collaboration Tools resources) CHEF Individual online workspaces Share files Privacy/Reciprocity Collaboration Tools CHEF Collaboration Tools CHEF Collaboration Tools CHEF

Other Collaboration Tools - Synchronous and Asynchronous

Tools to search for people and their Underlying GRID infra. interests (discover/collaborate)

Security enhancements/CAS

budgeted

???

The description does not match the "system function". Searching for people with common interests is not a security enhancement, and this is not a function of CAS. If this is a requirement, the solution would probably be to deploy LDAP servers using the Internet2 schemas for describing people; most of that work would probably be done by the deployment team.

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 14

User Requirement Simulation codes Simulation codes Simulation codes Simulation codes Simulation codes Simulation codes Repository Curation Repository Curation Store simulation codes (through Portal) Access simulation codes (through Portal) Run data thru simulation codes

System Component Simulation repository Simulation repository Simulation repository

Are you doing work that satisfies this requirement? Budget Status (Y/N) Y Y Y Y Y Y ???

Brief description of deliverable(s) that result from this work Sim tool repository/links (see SA document) Capability to run community code remotely Analysis content portions of repository outline of version history of tools in repository analysis content library showing how sim tools used a portal interface to at least one community code what kind of protocols?

Simulation repository budgeted Simulation repository budgeted Simulation repository budgeted Simulation repository budgeted Simulation repository budgeted Simulation repository budgeted Data storage budgeted

Version control of simulation codes Simulation repository Reference documentation for code repository Design portal interface to common codes Data audit protocols Quality analysis of software (simulation codes) Simulation repository Simulation repository Data repository Simulation repository

Simulation repository budgeted

Yes, to limited repository metadata that will include QA extent metrics

Access to high performance computing resources

Provide access to high performance Underlying GRID infra. computing

Resource discovery

budgeted

Y?

Actually, "access" covers three things -- providing physical resources (i.e., supercomputers), providing tools for discovering those resources, and providing tools to schedule those resources. We're not providing the physical resources, but we are are providing tools to discover them (deliverable is MDS) and schedule them (deliverable is GRAM). Both GRAM and MDS are part of the Globus Toolkit.

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 15

User Requirement

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work

Access to high performance computing resources

Schedule high performance computing resources

Underlying GRID infra.

Resource discovery

budgeted

Access to high performance computing resources

Prioritize allocation of resources

Underlying GRID infra.

Resource discovery Security enhancements/CAS

budgeted

???

Security

Permission controls

Underlying GRID infra.

budgeted

GRAM (part of the Globus Toolkit). However, I wouldn't call this "resource discovery"; it would be "resource scheduling" or "resource management". This is a pretty open-ended requirement. Calling it "resource discovery" makes it sound like the requirement is to provide allocation committees information about resources to aid them in setting priorities -- in this case, the deliverable is MDS. If the requirement is to enforce decisions about what priorities have been decided, then GRAM supports whatever underlying mechanism exists at the computing site. Also, since this is under "access to high performance computing resources", I assume this requirement pertains to high performance computers. For other resources and services, there are mechanisms that allow administrators to specify who can do what, and when (deliverables would be CAS plus many individual services provided as part of NEESgrid). CAS, and all the individual services we're providing (e.g., GRAM, NSDS, NTCP, gridftp, the metadata tools,

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 16

User Requirement

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work

CHEF). No one can guarantee "security of system and data". We have designed the architecture to make the systems and networks no less secure than they would have been without NEESgrid (e.g., we support - and encourage -- isolating the DAQ and control systems behind firewalls). Much of the software we are providing (e.g., the components that are part of the Globus Toolkit) have undergone security reviews and are in broad use in very security-conscious environments. We are providing security features, such as GSI for authentication and message integrity. GSI (part of the Globus Toolkit)
We support having fewer local personnel than you would have to without NSDS and NTCP. "Minimum number" sounds pretty absolute. We're certainly not doing anything, for example, to reduce the number of people required to build an experiment specimen.

Security Security

Security of system and data Single security architecture

Underlying GRID infra. Underlying GRID infra.

Security enhancements/CAS Security enhancements/CAS

budgeted budgeted

??? Y

Safety

Minimum number of local personnel Telepresence required for remote operations Hybrid experiments

Remote Teleoperation NTCP not budgeted

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 17

User Requirement

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work We provide an interface to NTCP to cancel outstanding operations, but it's up to the sites to install drivers that shut things down safely. We also cannot, since NTCP messages travel over the commodity Internet, guarantee how quickly a cancel message will be received. Sites should have local personnel supervising their experiments and should implement their own local "kill switches" for safety. NTCP includes a pluggable interface that supports this, but it's up to the individual sites to install drivers that make the appropriate checks. It's also up to individual sites to set up appropriate (non-software) policies and procedures to protect their equipment and personnel. Style guide to promote and CSS to force tool GUI consistency Tools developed with a common GUI across tools in a web browser environment. CSS being used to provide skinning options. Chef, WT.NG being developed to require a browser only, no additional plugins.

Safety

Provide a kill switch (emergency shutdown of an experiment)

Telepresence Hybrid experiments

Remote Teleoperation NTCP not budgeted

Safety Usability Usability Usability Usability

Enforce guidelines to operate within equipment tolerances Common GUI integrating data, simulation, video and visualization (standard interfaces) Ease of use Reusable layout configuration Platform independence

Telepresence Hybrid experiments Collaboration Tools CHEF Collaboration Tools CHEF Collaboration Tools CHEF Collaboration Tools CHEF

Remote Teleoperation NTCP not budgeted budgeted budgeted budgeted budgeted

N Y Y Y Y

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 18

The table below shows the user requirements that are not being addressed by the system development effort. They correspond to 18.7% of the user requirements.
Are you doing work that satisfies this requirement? Budget Status (Y/N) budgeted N data search will be supported by associating metadata with data objects and searching the metadata. derived data can be linked to raw data with metadata elements Native Chef WT.NG tool for viewing archived experiment data and common UI to collab tools, but not simulation tools

User Requirement Optimize data compression while Collect and Store data retaining data quality

System Component Data repository Data storage

Brief description of deliverable(s) that result from this work

Search data

Search for raw data and data derivatives

Data repository

Data discovery

budgeted

Manage data Manage data Manage data Data Viewing Synchronous collaboration

Common interfaces to widely used tools (e.g. Matlab) Data viewer Manipulate experiment data (using tools such as Excel, MathCAD and Mathematica) Data repository "Clean" experiment data 3D visualization tools for analyzing results Data repository Data viewer

Stored data viewing

budgeted

NOT budgeted N NOT budgeted N Real-time data viewing Stored data viewing budgeted Remote Teleobservation N The Video system design operates at a maximum rate of NTSC not "very high speed". Very High Speed video is out of scope.

Ability to handle very high-speed video in real time (for telepresence) Telepresence

not budgeted

Synchronous collaboration Synchronous collaboration Synchronous collaboration

Videoconferencing services (discovery of MCUs) Data conferencing (remote sharing of data)

Underlying GRID infra. Collaboration Tools CHEF

Collaboration services budgeted

It's not clear that this is still a requirement; however, if it is, the deliverable would be an MDS provider listing MCU resources

NOT budgeted N NOT budgeted N

Collaboration Tools Shared whiteboard with telepointers CHEF

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 19

User Requirement Asynchronous collaboration Document version control

System Component Collaboration Tools CHEF

Are you doing work that satisfies this requirement? Budget Status (Y/N) NOT budgeted N

Brief description of deliverable(s) that result from this work

Safety

Minimum number of local personnel Telepresence required for remote operations Hybrid experiments

Remote Teleoperation NTCP not budgeted

We support having fewer local personnel than you would have to without NSDS and NTCP. "Minimum number" sounds pretty absolute. We're certainly not doing anything, for example, to reduce the number of people required to build an experiment specimen. We provide an interface to NTCP to cancel outstanding operations, but it's up to the sites to install drivers that shut things down safely. We also cannot, since NTCP messages travel over the commodity Internet, guarantee how quickly a cancel message will be received. Sites should have local personnel supervising their experiments and should implement their own local "kill switches" for safety. NTCP includes a pluggable interface that supports this, but it's up to the individual sites to install drivers that make the appropriate checks. It's also up to individual sites to set up appropriate (non-software) policies and procedures to protect their equipment and personnel.

Safety

Provide a kill switch (emergency shutdown of an experiment)

Telepresence Hybrid experiments

Remote Teleoperation NTCP not budgeted

Safety

Enforce guidelines to operate within Telepresence equipment tolerances Hybrid experiments

Remote Teleoperation NTCP not budgeted

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 20

Included in the table below are the user requirements that require further discussion (20% of user requirements).
Are you doing work that satisfies this requirement? Budget Status (Y/N)

User Requirement

System Component

Brief description of deliverable(s) that result from this work

Collect and Store data Collect and Store data

Develop a metadata registry which enforces business rules for specification of metadata elements Data repository Metadata-driven lifecycle management for objects Data repository

Metadata generation Metadata generation

budgeted budgeted

??? ???

I don't know what "business rules" means. validation will be supported in Alpha 2 I don't know what "lifecycle management" means. The repo supports versioning in Alpha 1

Collect and Store data

Data streaming/ automatically archive experimental data to central repository (OR to local archive first and then to central, after validation) Data streamer

NSDS

budgeted

??? what is meant by "database"? the CHEF interface released in Alpha 1 allows remote management of the repository and the data/metadata in it what kind of integrity?

Database Administration Database Administration

Remote database management Assure data integrity

Data repository Data repository

NOT budgeted NOT budgeted

??? ???

Other Collaboration Tools - Synchronous Tools to search for people and their Underlying GRID infra. and Asynchronous interests (discover/collaborate) Repository Curation Data audit protocols Data repository

Security enhancements/CAS Data storage

budgeted budgeted

??? ???

The description does not match the "system function". Searching for people with common interests is not a security enhancement, and this is not a function of CAS. If this is a requirement, the solution would probably be to deploy LDAP servers using the Internet2 schemas for describing people; most of that work would probably be done by the deployment team.
what kind of protocols?

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 21

User Requirement

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work

Access to high performance computing resources

Prioritize allocation of resources

Underlying GRID infra.

Resource discovery

budgeted

???

Security

Security of system and data

Underlying GRID infra.

Security enhancements/CAS

budgeted

???

This is a pretty open-ended requirement. Calling it "resource discovery" makes it sound like the requirement is to provide allocation committees information about resources to aid them in setting priorities -- in this case, the deliverable is MDS. If the requirement is to enforce decisions about what priorities have been decided, then GRAM supports whatever underlying mechanism exists at the computing site. Also, since this is under "access to high performance computing resources", I assume this requirement pertains to high performance computers. For other resources and services, there are mechanisms that allow administrators to specify who can do what, and when (deliverables would be CAS plus many individual services provided as part of NEESgrid). No one can guarantee "security of system and data". We have designed the architecture to make the systems and networks no less secure than they would have been without NEESgrid (e.g., we support - and encourage -- isolating the DAQ and control systems behind

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 22

User Requirement

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work

firewalls). Much of the software we are providing (e.g., the components that are part of the Globus Toolkit) have undergone security reviews and are in broad use in very security-conscious environments. We are providing security features, such as GSI for authentication and message integrity.
Teleoperations for remote controlled camera is operational. Teleoperations for instruments is now under the direction of the ISI Team which is defining NTCP and will perform all other remote operations. A remote control interface using the reference implementation of Labview will be written by ANL but it is waiting for NTCP to be completed by ISI. Observation of the experimental laboratory space using Video Cameras is operational and handled by the TPM thin-www client. Streaming data from sensors is now handled by NSDS and displayed by the CHEF Viewer . A NSDS interface using the reference implementation of Labview has been completed. Metadata search will be supported in final release, but search of data will only be supported in a limited fashion

Synchronous collaboration

Teleoperation

Telepresence

Remote Teleoperation budgeted

only partially

Synchronous collaboration

Teleobservation

Telepresence

Remote Teleobservation

budgeted

only partially

Search data

Search data and metadata

Data repository

Data discovery

budgeted

Y/N

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 23

User Requirement

System Component

Are you doing work that satisfies this requirement? Budget Status (Y/N)

Brief description of deliverable(s) that result from this work NSDS, NTCP, NTCP drivers for proxy server and Matlab, Matlab interfaces to NTCP (being done by Erik Johnson) We provide interfaces to support hybrid experiments. However, sites need to design their own experiments, write their own computational simulation code, and provide (in some cases) drivers to interface with their own local equipment.

Hybrid experiments Hybrid experiments

Hybrid experiments

NTCP

budgeted

Y/N

Access to high performance computing resources

Provide access to high performance Underlying GRID infra. computing Simulation repository

Resource discovery

budgeted

Y? Yes, to limited extent

Actually, "access" covers three things -- providing physical resources (i.e., supercomputers), providing tools for discovering those resources, and providing tools to schedule those resources. We're not providing the physical resources, but we are are providing tools to discover them (deliverable is MDS) and schedule them (deliverable is GRAM). Both GRAM and MDS are part of the Globus Toolkit.
repository metadata that will include QA metrics

Quality analysis of software Repository Curation (simulation codes)

Simulation repository budgeted

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003

NEESgrid Requirements Traceability Matrix

Page 24

Conclusion
The Requirements Traceability Matrix developed for the NEESgrid project indicates that 61.3% of the user requirements are being addressed by the system integration team and will be implemented in the first version of the system. 18.7% of the user requirements are not being addressed by the system integration effort. The remaining 20% of the user requirements need to be discussed further so that a determination can be made on whether user needs are being met. In most instances, discussion will be necessary to clarify what the user requirements mean so that an assessment can be made. These numbers do not represent the effort spent on user requirements relative to each other. Each user requirement was considered as one unit, independently of the amount of system integration effort required for each one. The generation of the Requirements Traceability Matrix was based on project documentation and on conversations with the System Integration team. It required approximately 140 man-hours to be completed. The user requirements included in the matrix represent the points of view of several constituencies involved in the NEESgrid project. It accounts for the requirements documented by NSF in its Program Solicitation. It also accounts for the requirements gathered from users in many occasions, including the Workshop held on October 23-25, 2002 at the Timberline Lodge, Mt. Hood, OR. The matrix includes the perspective of the system integration team as summarized in the System Overview and in the System Architecture documents. In addition, the RTM accounts for the viewpoint of the site review teams as reflected in the site visit reports from March 2001, 2002 and 2003. The Requirements Traceability Matrix is a rich compilation of all of the user requirements surfaced by the NEESgrid project to this date.

Finholt, Horn, Thom

www.neesgrid.org

6/26/2003