Title Page

1.0 Introduction

2.0 Literature Review

3.0 Model Framework
3.1 Objectives
3.2 Approach
3.3 Requirements
3.4 Design
3.5 Data Exchange Protocol

4.0 Scenarios

5.0 Qualitative Analysis

6.0 Recommendations

7.0 References

Appendix A

3.3 Requirements for the CCEF

To adequately assess the risks associated with chemicals released into the environment, researchers require software tools for accurately estimating human exposure under a variety of exposure scenarios. The design of a software technology system begins with a set of requirements. Requirements are characteristics and behaviors that a piece of software must possess to function adequately for its intended purpose. A requirement is sometimes called an attribute, and a good requirement is testable.

The purpose of these requirements is to state those conditions that define the design associated with the CCEF. To help define and develop requirements that will provide some legacy as the state-of-the-art in software technology advances, the requirements for the design of the CCEF shall initially consider those that have been suggested by experts, including those recently documented and outlined by Whelan and Nicholson (2001). The following requirements are grouped by the categories outlined by the American Chemistry Council for the CCEF.

• Comprehensive
  • Design the input/output and spatial/temporal linkage data-file specifications in the system through an Application Programming Interface, which accounts for units and range checking, and parameter attributes.
  • Allow for models to run on different platforms (e.g., remote computing).
  • Be configured to handle multiple directories for scenario and module files.
  • Ability to link outside frameworks to the system by allowing for icons on the icon palette to describe those outside frameworks.
  • Provide for different database types (e.g., chemical, ecological benchmarks, and human-health benchmarks) by representing each type by separate icons on the icon palette.
  • Allow a set of databases to supply information to a receiving module, establishing data priority on the same information.
  • Account for Graphical Information System connectivity.
• Modular
  • Consist of modules (algorithms and databases), which can be easily updated and exchanged without affecting other parts of the framework.
  • Allow for the functionality of entering the system at specified locations (e.g., import a file, user-specified information).
  • Allow for tiered icons (i.e., primary and secondary icons).
  • Allow for an icon palette to expand including additional icons, when appropriate.
  • Allow for the functionality to add new module icons, if desired.
  • Allow for the linkage of disparate models (e.g., analytical and numerical) in space and time.
• User-friendly
  • Operate on an IBM or compatible personal computer with Microsoft WIN98, or Win2000 platforms with a minimum of 128 MB RAM Pentium or equivalent, and 1 GB free disk space.
  • Support multiple computer languages and compilers.
  • Provide standardized reports, tables, and plots.
  • Contain a print feature.
  • Include on-line help for system-only components.
  • Provide for units conversion.
  • Develop user-friendly, graphically based conceptual site model.
  • Be capable of developing a conceptual site model with the Drag & Drop features.
  • Allow viewing of data requirements for modules chosen to represent icons in the conceptual site model, prior to implementation of the conceptual site model.
• Multi-route, Multi-pathway, & Multi-source for Varying durations
  • Be applicable to exposures via different routes and through multiple pathways, i.e., inhalation, oral, and dermal contact with consumer products.
  • Allow for single or multiple compounds with the same or different target organ.
  • Provide data client editors for system chemical- and lifeform-specific databases, which allow for identifying surrogates for (i.e., aliasing of) chemicals and/or lifeforms associated with each database-type.
  • Be applicable to acute, intermediate, and long-term exposures.
• Accurate
  • Provide the ability to benchmark models and databases.
  • Integrates state-of-the-art estimation methods and databases to estimate or reasonably overestimate the "ground-truth" of the actual exposure.
  • Incorporate lock and key features that allow a user to lock a conceptual site model picture, available models, and/or both.
• Open code
  • Be accessible for inspection and review by users and stakeholders (no proprietary or "black box" code).
  • Allow for the inclusion of commercial off the shelf software.
  • Be capable of documenting assumptions, surrogate names (i.e., aliases), changes in imported data from database, and version-control changes in pop-up or sticky notes, summary file(s), and/or a report generator.
• Probabilistic
  • Provide realistic distribution of exposures within the exposed population based on probabilistic modeling of key exposure factors, and allow for multistage Sensitivity/Uncertainty.
• Dose-response
  • Convert exposure estimates to corresponding dose and risk values, whenever appropriate.
• Mass-conservative
  • Use a mass balance approach whenever feasible to account for fate and transport of pollutant mass, and include, as part of module specifications, mass entering/leaving a module, where appropriate.