Automated documentation generator for advanced protein crystal growth
NASA Technical Reports Server (NTRS)
Maddux, Gary A.; Provancha, Anna; Chattam, David
1994-01-01
To achieve an environment less dependent on the flow of paper, automated techniques of data storage and retrieval must be utilized. This software system, 'Automated Payload Experiment Tool,' seeks to provide a knowledge-based, hypertext environment for the development of NASA documentation. Once developed, the final system should be able to guide a Principal Investigator through the documentation process in a more timely and efficient manner, while supplying more accurate information to the NASA payload developer. The current system is designed for the development of the Science Requirements Document (SRD), the Experiment Requirements Document (ERD), the Project Plan, and the Safety Requirements Document.
Basic Hitchhiker Payload Requirements
NASA Technical Reports Server (NTRS)
Horan, Stephen
1999-01-01
This document lists the requirements for the NMSU Hitchhiker experiment payload that were developed as part of the EE 498/499 Capstone Design class during the 1999-2000 academic year. This document is used to describe the system needs as described in the mission document. The requirements listed here are those primarily used to generate the basic electronic and data processing requirements developed in the class design document. The needs of the experiment components are more fully described in the draft NASA hitchhiker customer requirements document. Many of the details for the overall payload are given in full detail in the NASA hitchhiker documentation.
24 CFR 5.502 - Requirements concerning documents.
Code of Federal Regulations, 2010 CFR
2010-04-01
... 24 Housing and Urban Development 1 2010-04-01 2010-04-01 false Requirements concerning documents... § 5.502 Requirements concerning documents. For any notice or document (decision, declaration, consent... regulations for requirements concerning communications with persons with disabilities.) ...
The Requirements Generation System: A tool for managing mission requirements
NASA Technical Reports Server (NTRS)
Sheppard, Sylvia B.
1994-01-01
Historically, NASA's cost for developing mission requirements has been a significant part of a mission's budget. Large amounts of time have been allocated in mission schedules for the development and review of requirements by the many groups who are associated with a mission. Additionally, tracing requirements from a current document to a parent document has been time-consuming and costly. The Requirements Generation System (RGS) is a computer-supported cooperative-work tool that assists mission developers in the online creation, review, editing, tracing, and approval of mission requirements as well as in the production of requirements documents. This paper describes the RGS and discusses some lessons learned during its development.
Transit safety retrofit package development : applications requirements document.
DOT National Transportation Integrated Search
2014-05-01
This Application Requirements Document for the Transit Safety Retrofit Package (TRP) Development captures the system, hardware and software requirements towards fulfilling the technical objectives stated within the contract. To achieve the objective ...
48 CFR 11.101 - Order of precedence for requirements documents.
Code of Federal Regulations, 2011 CFR
2011-10-01
.... (2) Performance-oriented documents (e.g., a PWS or SOO). (See 2.101.) (3) Detailed design-oriented... requirements documents. 11.101 Section 11.101 Federal Acquisition Regulations System FEDERAL ACQUISITION REGULATION ACQUISITION PLANNING DESCRIBING AGENCY NEEDS Selecting and Developing Requirements Documents 11...
Consolidated Development Objectives Document (CDOD) For MB-60
NASA Technical Reports Server (NTRS)
Greene, William D.
2013-01-01
This document defines the objectives related to liquid rocket engine system development to be undertaken by JAXA in support of the Space Launch System (SLS) Program managed out of the NASA Marshall Space Flight Center (MSFC). These objectives include furnishing the necessary management, labor, facilities, tools, equipment, and materials required to execute the specified activities. 1.1 Project Scope: The scope of this effort is to develop a rocket engine and associated products per the objectives and technical requirements established in this document. This engine, minus the engine controller, designated here as MB ]60, is to be developed through to a prequalification point of maturity. It is assumed that should JCNE ]1 development proceed beyond this maturity point towards actual flight qualification, the engine controller will be supplied and integrated by NASA. 1.2 Document Structure: The structure of this Consolidated Development Objectives Document (CDOD) includes a traditional description of objectives in a SOO, plus the associated Data Products Document (DPD) in an attached appendix, and then Engine Requirements Document (ERD) as another attached appendix. It is the intent that this document, in conjunction with the cited applicable documents, should constitute a complete programmatic and technical description of the development effort to be pursued.
Open Source Patient-Controlled Analgesic Pump Requirements Documentation
Larson, Brian R.; Hatcliff, John; Chalin, Patrice
2014-01-01
The dynamic nature of the medical domain is driving a need for continuous innovation and improvement in techniques for developing and assuring medical devices. Unfortunately, research in academia and communication between academics, industrial engineers, and regulatory authorities is hampered by the lack of realistic non-proprietary development artifacts for medical devices. In this paper, we give an overview of a detailed requirements document for a Patient-Controlled Analgesic (PCA) pump developed under the US NSF’s Food and Drug Administration (FDA) Scholar-in-Residence (SIR) program. This 60+ page document follows the methodology outlined in the US Federal Aviation Administrations (FAA) Requirements Engineering Management Handbook (REMH) and includes a domain overview, use cases, statements of safety & security requirements, and formal top-level system architectural description. Based on previous experience with release of a requirements document for a cardiac pacemaker that spawned a number of research and pedagogical activities, we believe that the described PCA requirements document can be an important research enabler within the formal methods and software engineering communities. PMID:24931440
Tank waste remediation system functions and requirements document
DOE Office of Scientific and Technical Information (OSTI.GOV)
Carpenter, K.E
1996-10-03
This is the Tank Waste Remediation System (TWRS) Functions and Requirements Document derived from the TWRS Technical Baseline. The document consists of several text sections that provide the purpose, scope, background information, and an explanation of how this document assists the application of Systems Engineering to the TWRS. The primary functions identified in the TWRS Functions and Requirements Document are identified in Figure 4.1 (Section 4.0) Currently, this document is part of the overall effort to develop the TWRS Functional Requirements Baseline, and contains the functions and requirements needed to properly define the top three TWRS function levels. TWRS Technicalmore » Baseline information (RDD-100 database) included in the appendices of the attached document contain the TWRS functions, requirements, and architecture necessary to define the TWRS Functional Requirements Baseline. Document organization and user directions are provided in the introductory text. This document will continue to be modified during the TWRS life-cycle.« less
AEDT Software Requirements Documents - Draft
DOT National Transportation Integrated Search
2007-01-25
This software requirements document serves as the basis for designing and testing the Aviation Environmental Design Tool (AEDT) software. The intended audience for this document consists of the following groups: the AEDT designers, developers, and te...
An Object-Based Requirements Modeling Method.
ERIC Educational Resources Information Center
Cordes, David W.; Carver, Doris L.
1992-01-01
Discusses system modeling and specification as it relates to object-based information systems development and software development. An automated system model based on the objects in the initial requirements document is described, the requirements document translator is explained, and a sample application of the technique is provided. (12…
Electron/proton spectrometer certification documentation analyses
NASA Technical Reports Server (NTRS)
Gleeson, P.
1972-01-01
A compilation of analyses generated during the development of the electron-proton spectrometer for the Skylab program is presented. The data documents the analyses required by the electron-proton spectrometer verification plan. The verification plan was generated to satisfy the ancillary hardware requirements of the Apollo Applications program. The certification of the spectrometer requires that various tests, inspections, and analyses be documented, approved, and accepted by reliability and quality control personnel of the spectrometer development program.
Microgravity Experiments Safety and Integration Requirements Document Tree
NASA Technical Reports Server (NTRS)
Hogan, Jean M.
1995-01-01
This report is a document tree of the safety and integration documents required to develop a space experiment. Pertinent document information for each of the top level (tier one) safety and integration documents, and their applicable and reference (tier two) documents has been identified. This information includes: document title, revision level, configuration management, electronic availability, listed applicable and reference documents, source for obtaining the document, and document owner. One of the main conclusions of this report is that no single document tree exists for all safety and integration documents, regardless of the Shuttle carrier. This document also identifies the need for a single point of contact for customers wishing to access documents. The data in this report serves as a valuable information source for the NASA Lewis Research Center Project Documentation Center, as well as for all developers of space experiments.
NASA Software Documentation Standard
NASA Technical Reports Server (NTRS)
1991-01-01
The NASA Software Documentation Standard (hereinafter referred to as "Standard") is designed to support the documentation of all software developed for NASA; its goal is to provide a framework and model for recording the essential information needed throughout the development life cycle and maintenance of a software system. The NASA Software Documentation Standard can be applied to the documentation of all NASA software. The Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. The basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.
Automated payload experiment tool feasibility study
NASA Technical Reports Server (NTRS)
Maddux, Gary A.; Clark, James; Delugach, Harry; Hammons, Charles; Logan, Julie; Provancha, Anna
1991-01-01
To achieve an environment less dependent on the flow of paper, automated techniques of data storage and retrieval must be utilized. The prototype under development seeks to demonstrate the ability of a knowledge-based, hypertext computer system. This prototype is concerned with the logical links between two primary NASA support documents, the Science Requirements Document (SRD) and the Engineering Requirements Document (ERD). Once developed, the final system should have the ability to guide a principal investigator through the documentation process in a more timely and efficient manner, while supplying more accurate information to the NASA payload developer.
TOPEX Project Radar Altimeter Development Requirements and Specifications, Version 6.0
NASA Technical Reports Server (NTRS)
Rossi, Laurence C.
2003-01-01
This document provides the guidelines by which the TOPEX Radar Altimeter hardware development effort for the TOPEX flight project shall be implemented and conducted. The conduct of this activity shall take maximum advantage of the efforts expended during the TOPEX Radar Altimeter Advanced Technology Model development program and other related Radar Altimeter development efforts. This document complies with the TOPEX Project Office document 633-420 (D-2218), entitled, "TOPEX Project Requirements and Constraints for the NASA Radar Altimeter" dated December 1987.
A nursing-specific model of EPR documentation: organizational and professional requirements.
von Krogh, Gunn; Nåden, Dagfinn
2008-01-01
To present the Norwegian documentation KPO model (quality assurance, problem solving, and caring). To present the requirements and multiple electronic patient record (EPR) functions the model is designed to address. The model's professional substance, a conceptual framework for nursing practice is developed by examining, reorganizing, and completing existing frameworks. The model's methodology, an information management system, is developed using an expert group. Both model elements were clinically tested over a period of 1 year. The model is designed for nursing documentation in step with statutory, organizational, and professional requirements. Complete documentation is arranged for by incorporating the Nursing Minimum Data Set. A systematic and comprehensive documentation is arranged for by establishing categories as provided in the model's framework domains. Consistent documentation is arranged for by incorporating NANDA-I Nursing Diagnoses, Nursing Intervention Classification, and Nursing Outcome Classification. The model can be used as a tool in cooperation with vendors to ensure the interests of the nursing profession is met when developing EPR solutions in healthcare. The model can provide clinicians with a framework for documentation in step with legal and organizational requirements and at the same time retain the ability to record all aspects of clinical nursing.
Automated personnel data base system specifications, Task V. Final report
DOE Office of Scientific and Technical Information (OSTI.GOV)
Bartley, H.J.; Bocast, A.K.; Deppner, F.O.
1978-11-01
The full title of this study is 'Development of Qualification Requirements, Training Programs, Career Plans, and Methodologies for Effective Management and Training of Inspection and Enforcement Personnel.' Task V required the development of an automated personnel data base system for NRC/IE. This system is identified as the NRC/IE Personnel, Assignment, Qualifications, and Training System (PAQTS). This Task V report provides the documentation for PAQTS including the Functional Requirements Document (FRD), the Data Requirements Document (DRD), the Hardware and Software Capabilities Assessment, and the Detailed Implementation Schedule. Specific recommendations to facilitate implementation of PAQTS are also included.
24 CFR 2004.22 - Filing requirements for demands or requests for documents or testimony.
Code of Federal Regulations, 2010 CFR
2010-04-01
... 24 Housing and Urban Development 5 2010-04-01 2010-04-01 false Filing requirements for demands or... AND URBAN DEVELOPMENT SUBPOENAS AND PRODUCTION IN RESPONSE TO SUBPOENAS OR DEMANDS OF COURTS OR OTHER AUTHORITIES Requests for Testimony and Production of Documents § 2004.22 Filing requirements for demands or...
24 CFR 2004.22 - Filing requirements for demands or requests for documents or testimony.
Code of Federal Regulations, 2011 CFR
2011-04-01
... 24 Housing and Urban Development 5 2011-04-01 2011-04-01 false Filing requirements for demands or... AND URBAN DEVELOPMENT SUBPOENAS AND PRODUCTION IN RESPONSE TO SUBPOENAS OR DEMANDS OF COURTS OR OTHER AUTHORITIES Requests for Testimony and Production of Documents § 2004.22 Filing requirements for demands or...
Repository-based software engineering program: Concept document
NASA Technical Reports Server (NTRS)
1992-01-01
This document provides the context for Repository-Based Software Engineering's (RBSE's) evolving functional and operational product requirements, and it is the parent document for development of detailed technical and management plans. When furnished, requirements documents will serve as the governing RBSE product specification. The RBSE Program Management Plan will define resources, schedules, and technical and organizational approaches to fulfilling the goals and objectives of this concept. The purpose of this document is to provide a concise overview of RBSE, describe the rationale for the RBSE Program, and define a clear, common vision for RBSE team members and customers. The document also provides the foundation for developing RBSE user and system requirements and a corresponding Program Management Plan. The concept is used to express the program mission to RBSE users and managers and to provide an exhibit for community review.
XML and its impact on content and structure in electronic health care documents.
Sokolowski, R.; Dudeck, J.
1999-01-01
Worldwide information networks have the requirement that electronic documents must be easily accessible, portable, flexible and system-independent. With the development of XML (eXtensible Markup Language), the future of electronic documents, health care informatics and the Web itself are about to change. The intent of the recently formed ASTM E31.25 subcommittee, "XML DTDs for Health Care", is to develop standard electronic document representations of paper-based health care documents and forms. A goal of the subcommittee is to work together to enhance existing levels of interoperability among the various XML/SGML standardization efforts, products and systems in health care. The ASTM E31.25 subcommittee uses common practices and software standards to develop the implementation recommendations for XML documents in health care. The implementation recommendations are being developed to standardize the many different structures of documents. These recommendations are in the form of a set of standard DTDs, or document type definitions that match the electronic document requirements in the health care industry. This paper discusses recent efforts of the ASTM E31.25 subcommittee. PMID:10566338
DOT National Transportation Integrated Search
1996-08-01
The purpose of this document is to provide trustees with general guidance to develop restoration plans under OPA that comply with NEPA's procedural requirements. The focus of this document is to more fully describe the processes and products required...
Satellite Instrument Development and Data Analysis
1987-09-30
Document (ICD)), the Investigation Requir ments Document (IRD), and the Polici (-; and Requirements (PAR) documents were revised and ,!pdated to reflect the...6 anenhncemnt f snglyionzed Josetyn. I. A., and J. F. Bryson. Jr.. Magalert: August 27, 1978. Synsp. cncd b th shck:and(6)an nhacemnt f sngl ioize
DOT National Transportation Integrated Search
2014-01-01
This document provides the high-level functional and performance requirements for the Prototype Development and Demonstration of a R.E.S.C.U.M.E. system. The requirements included in this document are based upon those that can be found in previous R....
NASA Technical Reports Server (NTRS)
1989-01-01
This document establishes electrical, electronic, and electromechanical (EEE) parts management and control requirements for contractors providing and maintaining space flight and mission-essential or critical ground support equipment for NASA space flight programs. Although the text is worded 'the contractor shall,' the requirements are also to be used by NASA Headquarters and field installations for developing program/project parts management and control requirements for in-house and contracted efforts. This document places increased emphasis on parts programs to ensure that reliability and quality are considered through adequate consideration of the selection, control, and application of parts. It is the intent of this document to identify disciplines that can be implemented to obtain reliable parts which meet mission needs. The parts management and control requirements described in this document are to be selectively applied, based on equipment class and mission needs. Individual equipment needs should be evaluated to determine the extent to which each requirement should be implemented on a procurement. Utilization of this document does not preclude the usage of other documents. The entire process of developing and implementing requirements is referred to as 'tailoring' the program for a specific project. Some factors that should be considered in this tailoring process include program phase, equipment category and criticality, equipment complexity, and mission requirements. Parts management and control requirements advocated by this document directly support the concept of 'reliability by design' and are an integral part of system reliability and maintainability. Achieving the required availability and mission success objectives during operation depends on the attention given reliability and maintainability in the design phase. Consequently, it is intended that the requirements described in this document are consistent with those of NASA publications, 'Reliability Program Requirements for Aeronautical and Space System Contractors,' NHB 5300.4(1A-l); 'Maintainability Program Requirements for Space Systems,' NHB 5300.4(1E); and 'Quality Program Provisions for Aeronautical and Space System Contractors,' NHB 5300.4(1B).
ERIC Educational Resources Information Center
Berghella, Tina; Molenaar, John; Wyse, Linda
2006-01-01
This support document was produced by the authors based on their research for the report, "The Professional Development Requirements of Workplace English Language and Literacy Programme Practitioners," [ED495200] and is an added resource for further information. The original report examines the extent and nature of professional development…
Guideline for Software Documentation Management.
ERIC Educational Resources Information Center
National Bureau of Standards (DOC), Washington, DC.
Designed as a basic reference for federal personnel concerned with the development, maintenance, enhancement, control, and management of computer-based systems, this manual provides a general overview of the software development process and software documentation issues so that managers can assess their own documentation requirements. Reference is…
Concept document of the repository-based software engineering program: A constructive appraisal
NASA Technical Reports Server (NTRS)
1992-01-01
A constructive appraisal of the Concept Document of the Repository-Based Software Engineering Program is provided. The Concept Document is designed to provide an overview of the Repository-Based Software Engineering (RBSE) Program. The Document should be brief and provide the context for reading subsequent requirements and product specifications. That is, all requirements to be developed should be traceable to the Concept Document. Applied Expertise's analysis of the Document was directed toward assuring that: (1) the Executive Summary provides a clear, concise, and comprehensive overview of the Concept (rewrite as necessary); (2) the sections of the Document make best use of the NASA 'Data Item Description' for concept documents; (3) the information contained in the Document provides a foundation for subsequent requirements; and (4) the document adequately: identifies the problem being addressed; articulates RBSE's specific role; specifies the unique aspects of the program; and identifies the nature and extent of the program's users.
Peterson, Erin L; Carlson, Susan A; Schmid, Thomas L; Brown, David R; Galuska, Deborah A
2018-01-01
The purpose of this study was to examine the association between the presence of supportive community planning documents in US municipalities with design standards and requirements supportive of active living. Cross-sectional study using data from the 2014 National Survey of Community-Based Policy and Environmental Supports for Healthy Eating and Active Living. Nationally representative sample of US municipalities. Respondents are 2005 local officials. Assessed: (1) The presence of design standards and feature requirements and (2) the association between planning documents and design standards and feature requirements supportive of active living in policies for development. Using logistic regression, significant trends were identified in the presence of design standards and feature requirements by plan and number of supportive objectives present. Prevalence of design standards ranged from 19% (developer dedicated right-of-way for bicycle infrastructure development) to 50% (traffic-calming features in areas with high pedestrian and bicycle volume). Features required in policies for development ranged from 14% (short/medium pedestrian-scale block sizes) to 44% (minimum sidewalk widths of 5 feet) of municipalities. As the number of objectives in municipal plans increased, there was a significant and positive trend ( P < .05) in the prevalence of each design standard and requirement. Municipal planning documents containing objectives supportive of physical activity are associated with design standards and feature requirements supportive of activity-friendly communities.
Standardization of a Safing and Arming Device for Artillery Ammunition
1976-10-01
designated by other author- ized documents. UNCLASSIFIED SECURITY CLASSIFICATION OF THIS PAGE (When Dala Entered) REPORT DOCUMENTATION PAGE READ...establish the physical and military requirements. Design studies were initiated on the current S&A devices. • DD FOR’* •’*• 1 JAN 73 1473...A developer. In the design of any mechanism, a precise definition of S&A requirements for all fuze applications is required prior to development
Automated personnel data base system specifications, Task V. Final report
DOE Office of Scientific and Technical Information (OSTI.GOV)
Bartley, H.J.; Bocast, A.K.; Deppner, F.O.
1978-09-01
This document is the General Research Corporation report on Task V of a study for the Office of Inspection and Enforcement of the Nuclear Regulatory Commission (NRC/IE). The full title of this study is ''Development of Qualification Requirements, Training Programs, Career Plans, and Methodologies for Effective Management and Training of Inspection and Enforcement Personnel.'' Task V required the development of an automated personnel data base system for NRC/IE. This system is identified as the NRC/IE Personnel, Assignment, Qualifications, and Training System (PAQTS). This Task V report provides the documentation for PAQTS including the Functional Requirements Document (FRD), the Data Requirementsmore » Document (DRD), the Hardware and Software Capabilities Assessment, and the Detailed Implementation Schedule. Specific recommendations to facilitate implementation of PAQTS are also included.« less
Documentation: Records and Reports.
Akers, Michael J
2017-01-01
This article deals with documentation to include the beginning of documentation, the requirements of Good Manufacturing Practice reports and records, and the steps that can be taken to minimize Good Manufacturing Practice documentation problems. It is important to remember that documentation for 503a compounding involves the Formulation Record, Compounding Record, Standard Operating Procedures, Safety Data Sheets, etc. For 503b outsourcing facilities, compliance with Current Good Manufacturing Practices is required, so this article is applicable to them. For 503a pharmacies, one can see the development and modification of Good Manufacturing Practice and even observe changes as they are occurring in 503a documentation requirements and anticipate that changes will probably continue to occur. Copyright© by International Journal of Pharmaceutical Compounding, Inc.
Experiment Document for 01-E077 Microgravity Investigation of Crew Reactions in 0-G (MICRO-G)
NASA Technical Reports Server (NTRS)
Newman, Dava J.
2003-01-01
The Experiment Document (ED) serves the following purposes: a) It provides a vehicle for Principal Investigators (PIS) to formally specify the requirements for performing their experiments. b) It provides a technical Statement of Work (SOW). c) It provides experiment investigators and hardware developers with a convenient source of information about Human Life Sciences (HLS) requirements for the development and/or integration of flight experiment projects. d) It is the primary source of experiment specifications for the HLS Research Program Office (RPO). Inputs from this document will be placed into a controlled database that will be used to generate other documents.
NASA Technical Reports Server (NTRS)
Lowman, Douglas S.; Withers, B. Edward; Shagnea, Anita M.; Dent, Leslie A.; Hayhurst, Kelly J.
1990-01-01
A variety of instructions to be used in the development of implementations of software for the Guidance and Control Software (GCS) project is described. This document fulfills the Radio Technical Commission for Aeronautics RTCA/DO-178A guidelines, 'Software Considerations in Airborne Systems and Equipment Certification' requirements for document No. 4, which specifies the information necessary for understanding and programming the host computer, and document No. 12, which specifies the software design and implementation standards that are applicable to the software development and testing process. Information on the following subjects is contained: activity recording, communication protocol, coding standards, change management, error handling, design standards, problem reporting, module testing logs, documentation formats, accuracy requirements, and programmer responsibilities.
Theater Blood Application Was Not Effectively Developed and Implemented
2015-07-17
blood product by unit; and • monitor non- Food and Drug Administration Blood Product Testing. The CONOPS document also identified over 400 specific...time of a transfusion. However, this requirement was not identified in the CONOPS document. Further, PEO DHCS officials provided a traceability ...the CONOPS document, requirements management database, and the traceability matrix increased the risk that the Theater Blood Application
Medical Grade Water Generation for Intravenous Fluid Production on Exploration Missions
NASA Technical Reports Server (NTRS)
Niederhaus, Charles E.; Barlow, Karen L.; Griffin, DeVon W.; Miller, Fletcher J.
2008-01-01
This document describes the intravenous (IV) fluids requirements for medical care during NASA s future Exploration class missions. It further discusses potential methods for generating such fluids and the challenges associated with different fluid generation technologies. The current Exploration baseline mission profiles are introduced, potential medical conditions described and evaluated for fluidic needs, and operational issues assessed. Conclusions on the fluid volume requirements are presented, and the feasibility of various fluid generation options are discussed. A separate report will document a more complete trade study on the options to provide the required fluids.At the time this document was developed, NASA had not yet determined requirements for medical care during Exploration missions. As a result, this study was based on the current requirements for care onboard the International Space Station (ISS). While we expect that medical requirements will be different for Exploration missions, this document will provide a useful baseline for not only developing hardware to generate medical water for injection (WFI), but as a foundation for meeting future requirements. As a final note, we expect WFI requirements for Exploration will be higher than for ISS care, and system capacity may well need to be higher than currently specified.
TOPEX Software Document Series. Volume 5; Rev. 1; TOPEX GDR Processing
NASA Technical Reports Server (NTRS)
Lee, Jeffrey; Lockwood, Dennis; Hancock, David W., III
2003-01-01
This document is a compendium of the WFF TOPEX Software Development Team's knowledge regarding Geophysical Data Record (GDR) Processing. It includes many elements of a requirements document, a software specification document, a software design document, and a user's manual. In the more technical sections, this document assumes the reader is familiar with TOPEX and instrument files.
Maintainability Program Requirements for Space Systems
NASA Technical Reports Server (NTRS)
1987-01-01
This document is established to provide common general requirements for all NASA programs to: design maintainability into all systems where maintenance is a factor in system operation and mission success; and ensure that maintainability characteristics are developed through the systems engineering process. These requirements are not new. Design for ease of maintenance and minimization of repair time have always been fundamental requirements of the systems engineering process. However, new or reusable orbital manned and in-flight maintainable unmanned space systems demand special emphasis on maintainability, and this document has been prepared to meet that need. Maintainability requirements on many NASA programs differ in phasing and task emphasis from requirements promulgated by other Government agencies. This difference is due to the research and development nature of NASA programs where quantities produced are generally small; therefore, the depth of logistics support typical of many programs is generally not warranted. The cost of excessive maintenance is very high due to the logistics problems associated with the space environment. The ability to provide timely maintenance often involves safety considerations for manned space flight applications. This document represents a basic set of requirements that will achieve a design for maintenance. These requirements are directed primarily at manned and unmanned orbital space systems. To be effective, maintainability requirements should be tailored to meet specific NASA program and project needs and constraints. NASA activities shall invoke the requirements of this document consistent with program planning in procurements or on inhouse development efforts.
Space Telecommunications Radio System (STRS) Architecture Goals/Objectives and Level 1 Requirements
NASA Technical Reports Server (NTRS)
Briones, Janette C.; Johnson, Sandra K.; VanDerAar, Lisa
2007-01-01
The Space Telecommunications Radio System (STRS) Architecture Requirements Document provides the basis for the development of an open architecture for NASA Software Defined Radios (SDRs) for space use. The main objective of this document is to evaluate the goals and objectives and high level (Level 1) requirements that have bearing on the design of the architecture. The goals and objectives will provide broad, fundamental direction and purpose. The high level requirements (Level 1) intend to guide the broader and longer term aspects aspects of the SDR Architecture and provide guidance for the development of level 2 requirements.
Structured representation for requirements and specifications
NASA Technical Reports Server (NTRS)
Cohen, Gerald C.; Fisher, Gene; Frincke, Deborah; Wolber, Dave
1991-01-01
This document was generated in support of NASA contract NAS1-18586, Design and Validation of Digital Flight Control Systems suitable for Fly-By-Wire Applications, Task Assignment 2. Task 2 is associated with a formal representation of requirements and specifications. In particular, this document contains results associated with the development of a Wide-Spectrum Requirements Specification Language (WSRSL) that can be used to express system requirements and specifications in both stylized and formal forms. Included with this development are prototype tools to support the specification language. In addition a preliminary requirements specification methodology based on the WSRSL has been developed. Lastly, the methodology has been applied to an Advanced Subsonic Civil Transport Flight Control System.
NASA Technical Reports Server (NTRS)
Parsons, C. L. (Editor)
1989-01-01
The Multimode Airborne Radar Altimeter (MARA), a flexible airborne radar remote sensing facility developed by NASA's Goddard Space Flight Center, is discussed. This volume describes the scientific justification for the development of the instrument and the translation of these scientific requirements into instrument design goals. Values for key instrument parameters are derived to accommodate these goals, and simulations and analytical models are used to estimate the developed system's performance.
NASA Technical Reports Server (NTRS)
1985-01-01
The study was conducted in 3 parts over a 3 year period. The study schedule and the documentation associated with each study part is given. This document summarized selected study results from the conceptual design and programmatics segment of the effort. The objectives were: (1) to update requirements and tradeoffs and develop a detailed design and mission requirements document; (2) to develop conceptual designs and mission descriptions; and (3) to develop programmatic, i.e., work breakdown structure and work breakdown structure dictionary, estimated cost, and implementing plans and schedules.
Oak Ridge Environmental Information System (OREIS) functional system design document
DOE Office of Scientific and Technical Information (OSTI.GOV)
Birchfield, T.E.; Brown, M.O.; Coleman, P.R.
1994-03-01
The OREIS Functional System Design document provides a detailed functional description of the Oak Ridge Environmental Information System (OREIS). It expands the system requirements defined in the OREIS Phase 1-System Definition Document (ES/ER/TM-34). Documentation of OREIS development is based on the Automated Data Processing System Development Methodology, a Martin Marietta Energy Systems, Inc., procedure written to assist in developing scientific and technical computer systems. This document focuses on the development of the functional design of the user interface, which includes the integration of commercial applications software. The data model and data dictionary are summarized briefly; however, the Data Management Planmore » for OREIS (ES/ER/TM-39), a companion document to the Functional System Design document, provides the complete data dictionary and detailed descriptions of the requirements for the data base structure. The OREIS system will provide the following functions, which are executed from a Menu Manager: (1) preferences, (2) view manager, (3) macro manager, (4) data analysis (assisted analysis and unassisted analysis), and (5) spatial analysis/map generation (assisted ARC/INFO and unassisted ARC/INFO). Additional functionality includes interprocess communications, which handle background operations of OREIS.« less
NASA software documentation standard software engineering program
NASA Technical Reports Server (NTRS)
1991-01-01
The NASA Software Documentation Standard (hereinafter referred to as Standard) can be applied to the documentation of all NASA software. This Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. This basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.
TOPEX SDR Processing, October 1998. Volume 4
NASA Technical Reports Server (NTRS)
Lee, Jeffrey E.; Lockwood, Dennis W.
2003-01-01
This document is a compendium of the WFF TOPEX Software Development Team's knowledge regarding Sensor Data Record (SDR) Processing. It includes many elements of a requirements document, a software specification document, a software design document, and a user's manual. In the more technical sections, this document assumes the reader is familiar with TOPEX and instrument files.
cited in applicable qualitative materiel requirements, small development requirements, technical characteristics, and other requirements and documentation that pertain to automatic chemical agent alarms.
WFF TOPEX Software Documentation Altimeter Instrument File (AIF) Processing, October 1998. Volume 3
NASA Technical Reports Server (NTRS)
Lee, Jeffrey; Lockwood, Dennis
2003-01-01
This document is a compendium of the WFF TOPEX Software Development Team's knowledge regarding Sensor Data Record (SDR) Processing. It includes many elements of a requirements document, a software specification document, a software design document, and a user's manual. In the more technical sections, this document assumes the reader is familiar with TOPEX and instrument files.
High-Speed Maglev Trains; German Safety Requirements
DOT National Transportation Integrated Search
1991-12-31
This document is a translation of technology-specific safety requirements developed : for the German Transrapid Maglev technology. These requirements were developed by a : working group composed of representatives of German Federal Railways (DB), Tes...
Federal Register 2010, 2011, 2012, 2013, 2014
2013-04-16
... documents at either http://www.fda.gov/Drugs/DevelopmentApprovalProcess/FormsSubmissionRequirements...Vaccines/GuidanceComplianceRegulatoryInformation/Guidances/default.htm . Dated: April 10, 2013. Leslie Kux...
Information System Life-Cycle And Documentation Standards (SMAP DIDS)
NASA Technical Reports Server (NTRS)
1990-01-01
Although not computer program, SMAP DIDS written to provide systematic, NASA-wide structure for documenting information system development projects. Each DID (data item description) outlines document required for top-quality software development. When combined with management, assurance, and life cycle standards, Standards protect all parties who participate in design and operation of new information system.
Loads and Structural Dynamics Requirements for Spaceflight Hardware
NASA Technical Reports Server (NTRS)
Schultz, Kenneth P.
2011-01-01
The purpose of this document is to establish requirements relating to the loads and structural dynamics technical discipline for NASA and commercial spaceflight launch vehicle and spacecraft hardware. Requirements are defined for the development of structural design loads and recommendations regarding methodologies and practices for the conduct of load analyses are provided. As such, this document represents an implementation of NASA STD-5002. Requirements are also defined for structural mathematical model development and verification to ensure sufficient accuracy of predicted responses. Finally, requirements for model/data delivery and exchange are specified to facilitate interactions between Launch Vehicle Providers (LVPs), Spacecraft Providers (SCPs), and the NASA Technical Authority (TA) providing insight/oversight and serving in the Independent Verification and Validation role. In addition to the analysis-related requirements described above, a set of requirements are established concerning coupling phenomena or other interaction between structural dynamics and aerodynamic environments or control or propulsion system elements. Such requirements may reasonably be considered structure or control system design criteria, since good engineering practice dictates consideration of and/or elimination of the identified conditions in the development of those subsystems. The requirements are included here, however, to ensure that such considerations are captured in the design space for launch vehicles (LV), spacecraft (SC) and the Launch Abort Vehicle (LAV). The requirements in this document are focused on analyses to be performed to develop data needed to support structural verification. As described in JSC 65828, Structural Design Requirements and Factors of Safety for Spaceflight Hardware, implementation of the structural verification requirements is expected to be described in a Structural Verification Plan (SVP), which should describe the verification of each structural item for the applicable requirements. The requirement for and expected contents of the SVP are defined in JSC 65828. The SVP may also document unique verifications that meet or exceed these requirements with Technical Authority approval.
Teaching home care electronic documentation skills to undergraduate nursing students.
Nokes, Kathleen M; Aponte, Judith; Nickitas, Donna M; Mahon, Pamela Y; Rodgers, Betsy; Reyes, Nancy; Chaya, Joan; Dornbaum, Martin
2012-01-01
Although there is general consensus that nursing students need knowledge and significant skill to document clinical findings electronically, nursing faculty face many barriers in ensuring that undergraduate students can practice on electronic health record systems (EHRS). External funding supported the development of an educational innovation through a partnership between a home care agency staff and nursing faculty. Modules were developed to teach EHRS skills using a case study of a homebound person requiring wound care and the Medicare-required OASIS documentation system. This article describes the development and implementation of the module for an upper-level baccalaureate nursing program located in New York City. Nursing faculty are being challenged to develop creative and economical solutions to expose nursing students to EHRSs in nonclinical settings.
Basic Electronic Design for Proposed NMSU Hitchhiker Payload
NASA Technical Reports Server (NTRS)
Horan, Stephen
2000-01-01
This document presents the bas'c hardware design developed by the EE 499 class during the spring semester of the 1999-2000 academic year. This design covers the electrical components to supply power to the experiments, the computer software and interfaces to control the experiments, and the ground data processing to provide an operator interface. This document is a follow-on to the Payload Mission description document and the System Requirements document developed during the EE 498 class during the fall semester. The design activities are broken down by functional area within the structure. For each area, we give the requirements that need to be met and the design to meet the requirements. For each of these areas, a prototype selection of hardware and/or software was done by the class and the components assembled as part of the class to verify that they worked as intended.
Alvarado Flood Risk Management Modifications to Existing Project Section 408 Review. Review Plan
2012-12-26
Digital Flood Insurance Rate Maps) through the Nationa l Flood Insurance Program ( NFIP ). In order to obtain FEMA accreditation, the levee owner...compliance documentation for meeting NFIP requirements. Barr conducted a thorough review of relevant documents to gain a better understanding of...compliance documentation for meeting NFIP requirements. Barr Engineering has prepared a Phase I Engineer’s Report and is developing plans and
Bridge, Heather; Smolskis, Mary; Bianchine, Peter; Dixon, Dennis O; Kelly, Grace; Herpin, Betsey; Tavel, Jorge
2009-08-01
A clinical research protocol document must reflect both sound scientific rationale as well as local, national and, when applicable, international regulatory and human subject protections requirements. These requirements originate from a variety of sources, undergo frequent revision and are subject to interpretation. Tools to assist clinical investigators in the production of clinical protocols could facilitate navigating these requirements and ultimately increase the efficiency of clinical research. The National Institute of Allergy and Infectious Diseases (NIAID) developed templates for investigators to serve as the foundation for protocol development. These protocol templates are designed as tools to support investigators in developing clinical protocols. NIAID established a series of working groups to determine how to improve its capacity to conduct clinical research more efficiently and effectively. The Protocol Template Working Group was convened to determine what protocol templates currently existed within NIAID and whether standard NIAID protocol templates should be produced. After review and assessment of existing protocol documents and requirements, the group reached consensus about required and optional content, determined the format and identified methods for distribution as well as education of investigators in the use of these templates. The templates were approved by the NIAID Executive Committee in 2006 and posted as part of the NIAID Clinical Research Toolkit [1] website for broad access. These documents require scheduled revisions to stay current with regulatory and policy changes. The structure of any clinical protocol template, whether comprehensive or specific to a particular study phase, setting or design, affects how it is used by investigators. Each structure presents its own set of advantages and disadvantages. While useful, protocol templates are not stand-alone tools for creating an optimal protocol document, but must be complemented by institutional resources and support. Education and guidance of investigators in the appropriate use of templates is necessary to ensure a complete yet concise protocol document. Due to changing regulatory requirements, clinical protocol templates cannot become static, but require frequent revisions.
Department of Defense Enterprise Requirements and Acquisition Model
2011-06-01
Laboratories’ Center for Reengineering and Enabling Technology ( CRET ) to develop the APM. The APM is a compilation of policy, instructions, and...CDD Capabilities Development Document CBA Capabilities-Based Assessment CPD Capability Production Document CRET Center for Re-engineering
Development of Integrated Programs for Aerospace-Vehicle Design (IPAD)
NASA Technical Reports Server (NTRS)
Anderson, O. L.; Calvery, A. L.; Davis, D. A.; Dickmann, L.; Folger, D. H.; Jochem, E. N.; Kitto, C. M.; Vonlimbach, G.
1977-01-01
Integrated Programs for Aerospace Vehicle Design (IPAD) system design requirements are given. The information is based on the IPAD User Requirements Document (D6-IPAD-70013-D) and the Integrated Information Processing Requirements Document (D6-IPAD-70012-D). General information about IPAD and a list of the system design requirements that are to be satisfied by the IPAD system are given. The system design requirements definition is to be considered as a baseline definition of the IPAD system design requirements.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Gilliam, T.M.
1991-05-01
This Project Quality Assurance Plan (PQAP) sets forth the quality assurance (QA) requirements that are applied to those elements of the Westinghouse Materials Company of Ohio (WMCO) Operable Unit 1 support at Oak Ridge National Laboratory (ORNL) project that involve research and development (R D) performed at ORNL. This is in compliance with the applicable criteria of 10 CFR Part 50, Appendix B, ANSI/ASME NQA-1, as specified by Department of Energy (DOE) Oak Ridge Operations (ORO) Order 5700.6B. For this application, NQA-1 is the core QA Program requirements document. QA policy, normally found in the requirements document, is contained herein.more » The requirements of this PQAP apply to project activities that affect the quality and reliability/credibility of research, development, and investigative data and documentation. These activities include the functions of attaining quality objectives and assuring that an appropriate QA program scope is established. The scope of activities affecting quality includes organization; personnel training and qualifications; design control; procurement; material handling and storage; operating procedures; testing, surveillance, and auditing; R D investigative activities and documentation; deficiencies; corrective actions; and QA record keeping. 12 figs.« less
Airport Surface Traffic Control Visual Ground Aids Engineering and Development Plan
DOT National Transportation Integrated Search
1977-01-01
The plan described in this document supports the overall program at the Transportation Systems Center to define, design, develop, and evaluate systems that meet the requirements of airport surface traffic control. This plan is part of documentation s...
Electronic availability of microgravity experiments safety and integration requirements documents
NASA Technical Reports Server (NTRS)
Hogan, Jean M.
1995-01-01
This follow-on to NASA Contractor Report 195447, Microgravity Experiments Safety and Integration Requirements Document Tree, provides the details for accessing the systems that contain the official, electronic versions of the documents initially researched in NASA Contractor Report 195447. The data in this report serves as a valuable information source for the NASA Lewis Research Center Project Documentation Center (PDC), as well as for all developers of space experiments. The PDC has acquired the hardware, software, ID's, and passwords necessary to access most of these systems and is now able to provide customers with current document information as well as immediate delivery of available documents in either electronic or hard copy format.
NASA Docking System (NDS) Users Guide: International Space Station Program. Type 4
NASA Technical Reports Server (NTRS)
Tabakman, Alexander
2010-01-01
The NASA Docking System (NDS) Users Guide provides an overview of the basic information needed to integrate the NDS onto a Host Vehicle (HV). This Users Guide is intended to provide a vehicle developer with a fundamental understanding of the NDS technical and operations information to support their program and engineering integration planning. The Users Guide identifies the NDS Specification, Interface Definition or Requirement Documents that contain the complete technical details and requirements that a vehicle developer must use to design, develop and verify their systems will interface with NDS. This Guide is an initial reference and must not be used as a design document. In the event of conflict between this Users Guide and other applicable interface definition or requirements documents; the applicable document will take precedence. This Users Guide is organized in three main sections. Chapter 1 provides an overview of the NDS and CDA hardware and the operations concepts for the NDS. Chapter 2 provides information for Host Vehicle Program integration with the NDS Project Office. Chapter 2 describes the NDS Project organization, integration and verification processes, user responsibilities, and specification and interface requirement documents. Chapter 3 provides a summary of basic technical information for the NDS design. Chapter 3 includes NDS hardware component descriptions, physical size and weight characteristics, and summary of the capabilities and constraints for the various NDS sub-systems.
Requirements for an Advanced Ocean Radiometer
NASA Technical Reports Server (NTRS)
Meister, Gerhard; McClain, Charles R.; Ahmad, Ziauddin; Bailey, Sean W.; Barnes, Robert A.; Brown, Steven; Eplee, Robert E.; Franz, Bryan; Holmes, Alan; Monosmith, W. Bryan;
2011-01-01
This document suggests requirements for an advanced ocean radiometer, such as e.g. the ACE (Aerosol/Cloud/Ecosystem) ocean radiometer. The ACE ocean biology mission objectives have been defined in the ACE Ocean Biology white paper. The general requirements presented therein were chosen as the basis for the requirements provided in this document, which have been transformed into specific, testable requirements. The overall accuracy goal for the advanced ocean radiometer is that the total radiometric uncertainties are 0.5% or smaller for all bands. Specific mission requirements of SeaWiFS, MODIS, and VIIRS were often used as a model for the requirements presented here, which are in most cases more demanding than the heritage requirements. Experience with on-orbit performance and calibration (from SeaWiFS and MODIS) and prelaunch testing (from SeaWiFS, MODIS, and VIIRS) were important considerations when formulating the requirements. This document describes requirements in terms of the science data products, with a focus on qualities that can be verified by prelaunch radiometric characterization. It is expected that a more comprehensive requirements document will be developed during mission formulation
Furlan, Giovanni
2012-08-01
Current regulations require a description of the overall safety profile or the specific risks of a drug in multiple documents such as the Periodic and Development Safety Update Reports, Risk Management Plans (RMPs) and Signal Detection Reports. In a resource-constrained world, the need for preparing multiple documents reporting the same information results in shifting the focus from a thorough scientific and medical evaluation of the available data to maintaining compliance with regulatory timelines. Since the aim of drug safety is to understand and characterize product issues to take adequate risk minimization measures rather than to comply with bureaucratic requirements, there is the need to avoid redundancy. In order to identify core drug safety activities that need to be undertaken to protect patient safety and reduce the number of documents reporting the results of these activities, the author has reviewed the main topics included in the drug safety guidelines and templates. The topics and sources that need to be taken into account in the main regulatory documents have been found to greatly overlap and, in the future, as a result of the new Periodic Safety Update Report structure and requirements, in the author's opinion this overlap is likely to further increase. Many of the identified inter-document differences seemed to be substantially formal. The Development Safety Update Report, for example, requires separate presentation of the safety issues emerging from different sources followed by an overall evaluation of each safety issue. The RMP, instead, requires a detailed description of the safety issues without separate presentation of the evidence derived from each source. To some extent, however, the individual documents require an in-depth analysis of different aspects; the RMP, for example, requires an epidemiological description of the indication for which the drug is used and its risks. At the time of writing this article, this is not specifically required by other documents. The author has identified signal detection (intended not only as adverse event disproportionate reporting, but including non-clinical, laboratory, clinical analysis data and literature screening) and characterization as the basis for the preparation of all drug safety documents, which can be viewed as different ways of presenting the results of this activity. Therefore, the author proposes to merge all the aggregate reports required by current regulations into a single document - the Drug Safety Master File. This report should contain all the available information, from any source, regarding the potential and identified risks of a drug. It should be a living document updated and submitted to regulatory authorities on an ongoing basis.
NASA Technical Reports Server (NTRS)
Lockwood, Dennis W.; Conger, A. M.
2003-01-01
This document is a compendium of the WFF GFO Software Development Team's knowledge regarding of GDO CAL/VAL Data. It includes many elements of a requirements document, a software specification document, a software design document, and a user's guide. In the more technical sections, this document assumes the reader is familiar with GFO and its CAL/VAL Data.
Cf-252 Characterization Documents
DOE Office of Scientific and Technical Information (OSTI.GOV)
Feldman, Alexander
2014-03-14
Six documents were written by Vance and Associates under contract to the Off-Site Source Recovery Project of Los Alamos National Laboratory. These Six documents provided the basis for characterization of Californium-252 sealed sources and for the packaging and manifesting of this material for disposal at the Waste Isolation Pilot Project. The Six documents are: 1. VA-OSR-10, Development of radionuclide distributions for Cf-252 sealed sources. 2. VA-OSR-11, Uncertainty analysis for Cf-252 sealed sources. 3. VA-OSR-12, To determine the radionuclides in the waste drums containing Cf-252 sealed source waste that are required to be reported under the requirements of the WIPP WACmore » and the TRAMPAC. 4. VA-OSR-13, Development of the spreadsheet for the radiological calculations for the characterization of Cf-252 sources. 5. VA-OSR-14, Relative importance of neutron-induced fission in Cf-252 sources. 6. VA-OSR-15, Determine upper bound of decay product inventories from a drum of Cf-252 sources. These six documents provide the technical basis for the characterization of Cf-252 sources and will be part of the AK documentation required for submittal to the Central Characterization Project (CCP) of WIPP.« less
Seismology software: state of the practice
NASA Astrophysics Data System (ADS)
Smith, W. Spencer; Zeng, Zheng; Carette, Jacques
2018-05-01
We analyzed the state of practice for software development in the seismology domain by comparing 30 software packages on four aspects: product, implementation, design, and process. We found room for improvement in most seismology software packages. The principal areas of concern include a lack of adequate requirements and design specification documents, a lack of test data to assess reliability, a lack of examples to get new users started, and a lack of technological tools to assist with managing the development process. To assist going forward, we provide recommendations for a document-driven development process that includes a problem statement, development plan, requirement specification, verification and validation (V&V) plan, design specification, code, V&V report, and a user manual. We also provide advice on tool use, including issue tracking, version control, code documentation, and testing tools.
Seismology software: state of the practice
NASA Astrophysics Data System (ADS)
Smith, W. Spencer; Zeng, Zheng; Carette, Jacques
2018-02-01
We analyzed the state of practice for software development in the seismology domain by comparing 30 software packages on four aspects: product, implementation, design, and process. We found room for improvement in most seismology software packages. The principal areas of concern include a lack of adequate requirements and design specification documents, a lack of test data to assess reliability, a lack of examples to get new users started, and a lack of technological tools to assist with managing the development process. To assist going forward, we provide recommendations for a document-driven development process that includes a problem statement, development plan, requirement specification, verification and validation (V&V) plan, design specification, code, V&V report, and a user manual. We also provide advice on tool use, including issue tracking, version control, code documentation, and testing tools.
Robust Requirements Tracing via Internet Search Technology: Improving an IV and V Technique. Phase 2
NASA Technical Reports Server (NTRS)
Hayes, Jane; Dekhtyar, Alex
2004-01-01
There are three major objectives to this phase of the work. (1) Improvement of Information Retrieval (IR) methods for Independent Verification and Validation (IV&V) requirements tracing. Information Retrieval methods are typically developed for very large (order of millions - tens of millions and more documents) document collections and therefore, most successfully used methods somewhat sacrifice precision and recall in order to achieve efficiency. At the same time typical IR systems treat all user queries as independent of each other and assume that relevance of documents to queries is subjective for each user. The IV&V requirements tracing problem has a much smaller data set to operate on, even for large software development projects; the set of queries is predetermined by the high-level specification document and individual requirements considered as query input to IR methods are not necessarily independent from each other. Namely, knowledge about the links for one requirement may be helpful in determining the links of another requirement. Finally, while the final decision on the exact form of the traceability matrix still belongs to the IV&V analyst, his/her decisions are much less arbitrary than those of an Internet search engine user. All this suggests that the information available to us in the framework of the IV&V tracing problem can be successfully leveraged to enhance standard IR techniques, which in turn would lead to increased recall and precision. We developed several new methods during Phase II; (2) IV&V requirements tracing IR toolkit. Based on the methods developed in Phase I and their improvements developed in Phase II, we built a toolkit of IR methods for IV&V requirements tracing. The toolkit has been integrated, at the data level, with SAIC's SuperTracePlus (STP) tool; (3) Toolkit testing. We tested the methods included in the IV&V requirements tracing IR toolkit on a number of projects.
Use of a structured template to facilitate practice-based learning and improvement projects.
McClain, Elizabeth K; Babbott, Stewart F; Tsue, Terance T; Girod, Douglas A; Clements, Debora; Gilmer, Lisa; Persons, Diane; Unruh, Greg
2012-06-01
The Accreditation Council for Graduate Medical Education (ACGME) requires residency programs to meet and demonstrate outcomes across 6 competencies. Measuring residents' competency in practice-based learning and improvement (PBLI) is particularly challenging. We developed an educational tool to meet ACGME requirements for PBLI. The PBLI template helped programs document quality improvement (QI) projects and supported increased scholarly activity surrounding PBLI learning. We reviewed program requirements for 43 residency and fellowship programs and identified specific PBLI requirements for QI activities. We also examined ACGME Program Information Form responses on PBLI core competency questions surrounding QI projects for program sites visited in 2008-2009. Data were integrated by a multidisciplinary committee to develop a peer-protected PBLI template guiding programs through process, documentation, and evaluation of QI projects. All steps were reviewed and approved through our GME Committee structure. An electronic template, companion checklist, and evaluation form were developed using identified project characteristics to guide programs through the PBLI process and facilitate documentation and evaluation of the process. During a 24 month period, 27 programs have completed PBLI projects, and 15 have reviewed the template with their education committees, but have not initiated projects using the template. The development of the tool generated program leaders' support because the tool enhanced the ability to meet program-specific objectives. The peer-protected status of this document for confidentiality and from discovery has been beneficial for program usage. The document aggregates data on PBLI and QI initiatives, offers opportunities to increase scholarship in QI, and meets the ACGME goal of linking measures to outcomes important to meeting accreditation requirements at the program and institutional level.
Use of a Structured Template to Facilitate Practice-Based Learning and Improvement Projects
McClain, Elizabeth K.; Babbott, Stewart F.; Tsue, Terance T.; Girod, Douglas A.; Clements, Debora; Gilmer, Lisa; Persons, Diane; Unruh, Greg
2012-01-01
Background The Accreditation Council for Graduate Medical Education (ACGME) requires residency programs to meet and demonstrate outcomes across 6 competencies. Measuring residents' competency in practice-based learning and improvement (PBLI) is particularly challenging. Purpose We developed an educational tool to meet ACGME requirements for PBLI. The PBLI template helped programs document quality improvement (QI) projects and supported increased scholarly activity surrounding PBLI learning. Methods We reviewed program requirements for 43 residency and fellowship programs and identified specific PBLI requirements for QI activities. We also examined ACGME Program Information Form responses on PBLI core competency questions surrounding QI projects for program sites visited in 2008–2009. Data were integrated by a multidisciplinary committee to develop a peer-protected PBLI template guiding programs through process, documentation, and evaluation of QI projects. All steps were reviewed and approved through our GME Committee structure. Results An electronic template, companion checklist, and evaluation form were developed using identified project characteristics to guide programs through the PBLI process and facilitate documentation and evaluation of the process. During a 24 month period, 27 programs have completed PBLI projects, and 15 have reviewed the template with their education committees, but have not initiated projects using the template. Discussion The development of the tool generated program leaders' support because the tool enhanced the ability to meet program-specific objectives. The peer-protected status of this document for confidentiality and from discovery has been beneficial for program usage. The document aggregates data on PBLI and QI initiatives, offers opportunities to increase scholarship in QI, and meets the ACGME goal of linking measures to outcomes important to meeting accreditation requirements at the program and institutional level. PMID:23730444
DOE Office of Scientific and Technical Information (OSTI.GOV)
BEVINS, R.R.
This study is a requirements document that presents analysis for the functional description for the master pump shutdown system. This document identifies the sources of the requirements and/or how these were derived. Each requirement is validated either by quoting the source or an analysis process involving the required functionality, performance characteristics, operations input or engineering judgment. The requirements in this study apply to the first phase of the W314 Project. This document has been updated during the definitive design portion of the first phase of the W314 Project to capture additional software requirements and is planned to be updated duringmore » the second phase of the W314 Project to cover the second phase of the project's scope.« less
Advanced Marketing/Coop Course Outline.
ERIC Educational Resources Information Center
Dixon, Bobby
This document contains the information required to present a 1-year school course that is the capstone class of a 2-year marketing major and is designed for high school students wishing to develop the skills required for entry into the marketing industry. The document begins with a rationale, brief course description, list of course objectives,…
Eldercare. Technical Advisory Committee on Occupational Curriculum Development.
ERIC Educational Resources Information Center
Northern Montana Coll., Havre. Montana Center for Vocational Education, Research, Curriculum and Personnel Development.
This document contains the secondary education model curriculum for the secondary education preparation of home health aides in Montana. The document includes: (1) an introduction and a rationale for the program; (2) skills required by programs that meet certification requirements for a long-term care nurse aide (75 hours) and home health aide (an…
A knowledge-based approach to configuration layout, justification, and documentation
NASA Technical Reports Server (NTRS)
Craig, F. G.; Cutts, D. E.; Fennel, T. R.; Case, C.; Palmer, J. R.
1990-01-01
The design, development, and implementation is described of a prototype expert system which could aid designers and system engineers in the placement of racks aboard modules on Space Station Freedom. This type of problem is relevant to any program with multiple constraints and requirements demanding solutions which minimize usage of limited resources. This process is generally performed by a single, highly experienced engineer who integrates all the diverse mission requirements and limitations, and develops an overall technical solution which meets program and system requirements with minimal cost, weight, volume, power, etc. This system architect performs an intellectual integration process in which the underlying design rationale is often not fully documented. This is a situation which lends itself to an expert system solution for enhanced consistency, thoroughness, documentation, and change assessment capabilities.
A Knowledge-Based Approach to Configuration Layout, Justification, and Documentation
NASA Technical Reports Server (NTRS)
Craig, F. G.; Cutts, D. E.; Fennel, T. R.; Case, C. M.; Palmer, J. R.
1991-01-01
The design, development, and implementation of a prototype expert system which could aid designers and system engineers in the placement of racks aboard modules on the Space Station Freedom are described. This type of problem is relevant to any program with multiple constraints and requirements demanding solutions which minimize usage of limited resources. This process is generally performed by a single, highly experienced engineer who integrates all the diverse mission requirements and limitations, and develops an overall technical solution which meets program and system requirements with minimal cost, weight, volume, power, etc. This system architect performs an intellectual integration process in which the underlying design rationale is often not fully documented. This is a situation which lends itself to an expert system solution for enhanced consistency, thoroughness, documentation, and change assessment capabilities.
DOT National Transportation Integrated Search
2016-10-12
This document describes the System Requirements Specifications (SyRS) of the Dynamic Mobility Applications (DMA) Open Source Application Development Portal (OSADP) system in details according to IEEE-Std. 1233-1998. The requirement statements discuss...
Red Plague Control Plan (RPCP)
NASA Technical Reports Server (NTRS)
Cooke, Robert W.
2010-01-01
SCOPE: Prescribes the minimum requirements for the control of cuprous / cupric oxide corrosion (a.k.a. Red Plague) of silver-coated copper wire, cable, and harness assemblies. PURPOSE: Targeted for applications where exposure to assembly processes, environmental conditions, and contamination may promote the development of cuprous / cupric oxide corrosion (a.k.a. Red Plague) in silver-coated copper wire, cable, and harness assemblies. Does not exclude any alternate or contractor-proprietary documents or processes that meet or exceed the baseline of requirements established by this document. Use of alternate or contractor-proprietary documents or processes shall require review and prior approval of the procuring NASA activity.
IT Requirements Integration in High-Rise Construction Design Projects
NASA Astrophysics Data System (ADS)
Levina, Anastasia; Ilin, Igor; Esedulaev, Rustam
2018-03-01
The paper discusses the growing role of IT support for the operation of modern high-rise buildings, due to the complexity of managing engineering systems of buildings and the requirements of consumers for the IT infrastructure. The existing regulatory framework for the development of design documentation for construction, including high-rise buildings, is analyzed, and the lack of coherence in the development of this documentation with the requirements for the creation of an automated management system and the corresponding IT infrastructure is stated. The lack of integration between these areas is the cause of delays and inefficiencies both at the design stage and at the stage of putting the building into operation. The paper proposes an approach to coordinate the requirements of the IT infrastructure of high-rise buildings and design documentation for construction. The solution to this problem is possible within the framework of the enterprise architecture concept by coordinating the requirements of the IT and technological layers at the design stage of the construction.
Advanced Video Data-Acquisition System For Flight Research
NASA Technical Reports Server (NTRS)
Miller, Geoffrey; Richwine, David M.; Hass, Neal E.
1996-01-01
Advanced video data-acquisition system (AVDAS) developed to satisfy variety of requirements for in-flight video documentation. Requirements range from providing images for visualization of airflows around fighter airplanes at high angles of attack to obtaining safety-of-flight documentation. F/A-18 AVDAS takes advantage of very capable systems like NITE Hawk forward-looking infrared (FLIR) pod and recent video developments like miniature charge-couple-device (CCD) color video cameras and other flight-qualified video hardware.
E-documentation as a process management tool for nursing care in hospitals.
Rajkovic, Uros; Sustersic, Olga; Rajkovic, Vladislav
2009-01-01
Appropriate documentation plays a key role in process management in nursing care. It includes holistic data management based on patient's data along the clinical path with regard to nursing care. We developed an e-documentation model that follows the process method of work in nursing care. It assesses the patient's status on the basis of Henderson's theoretical model of 14 basic living activities and is aligned with internationally recognized nursing classifications. E-documentation development requires reengineering of existing documentation and facilitates process reengineering. A prototype solution of an e-nursing documentation, already being in testing process at University medical centres in Ljubljana and Maribor, will be described.
DOT National Transportation Integrated Search
2004-12-01
The U.S. DOT has conducted research on the requirements for a Crash Event Data Recorder to facilitate the reconstruction of commercial motor vehicle crashes. This report documents the work performed on the Development of Requirements and Functiona...
Waste certification program plan for Oak Ridge National Laboratory. Revision 1
DOE Office of Scientific and Technical Information (OSTI.GOV)
Orrin, R.C.
1997-05-01
This document defines the waste certification program developed for implementation at Oak Ridge National Laboratory (ORNL). The document describes the program structure, logic, and methodology for certification of ORNL wastes. The purpose of the waste certification program is to provide assurance that wastes are properly characterized and that the Waste Acceptance Criteria (WAC) for receiving facilities are met. The program meets the waste certification requirements outlined in US Department of Energy (DOE) Order 5820.2A, Radioactive Waste Management, and ensures that 40 CFR documentation requirements for waste characterization are met for mixed (both radioactive and hazardous) and hazardous (including polychlorinated biphenyls)more » waste. Program activities will be conducted according to ORNL Level 1 document requirements.« less
A diagnostic prototype of the potable water subsystem of the Space Station Freedom ECLSS
NASA Technical Reports Server (NTRS)
Lukefahr, Brenda D.; Rochowiak, Daniel M.; Benson, Brian L.; Rogers, John S.; Mckee, James W.
1989-01-01
In analyzing the baseline Environmental Control and Life Support System (ECLSS) command and control architecture, various processes are found which would be enhanced by the use of knowledge based system methods of implementation. The most suitable process for prototyping using rule based methods are documented, while domain knowledge resources and other practical considerations are examined. Requirements for a prototype rule based software system are documented. These requirements reflect Space Station Freedom ECLSS software and hardware development efforts, and knowledge based system requirements. A quick prototype knowledge based system environment is researched and developed.
Guidance and Control Software Project Data - Volume 2: Development Documents
NASA Technical Reports Server (NTRS)
Hayhurst, Kelly J. (Editor)
2008-01-01
The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the development documents from the GCS project. Volume 2 contains three appendices: A. Guidance and Control Software Development Specification; B. Design Description for the Pluto Implementation of the Guidance and Control Software; and C. Source Code for the Pluto Implementation of the Guidance and Control Software
Analysis of microgravity space experiments Space Shuttle programmatic safety requirements
NASA Technical Reports Server (NTRS)
Terlep, Judith A.
1996-01-01
This report documents the results of an analysis of microgravity space experiments space shuttle programmatic safety requirements and recommends the creation of a Safety Compliance Data Package (SCDP) Template for both flight and ground processes. These templates detail the programmatic requirements necessary to produce a complete SCDP. The templates were developed from various NASA centers' requirement documents, previously written guidelines on safety data packages, and from personal experiences. The templates are included in the back as part of this report.
Managing Requirements-Documents to Data
NASA Technical Reports Server (NTRS)
Orr, Kevin; Hudson, Abe
2017-01-01
Managing Requirements on long term projects like International Space Station (ISS) can go thru many phases, from initial product development to almost over 20 years of operations and sustainment. Over that time many authorized changes have been made to the requirement set, that apply to any new systems that would visit the ISS today, like commercial cargo/crew vehicles or payloads. Explore the benefits of managing requirements in a database while satisfying traditional documents needs for contracts and stakeholder/user consumption that are not tied into the database.
The Development and Initial Evaluation of the Human Readiness Level Framework
2010-06-01
View ICD Initial Capabilities Document ICW Interactive Course Ware ILE Interactive Learning Environment ILT Instructor Led Training IOC...Programmatic Environmental Safety and Health Evaluation PHA Preliminary Hazard Analysis PHL Preliminary Hazard List xiv PM Program Manager PQS...Occupational Health SOW Statement of Work SRD System Requirements Document SPS System Performance Specification SRR System Requirements Review SVR
DOE Office of Scientific and Technical Information (OSTI.GOV)
Yoo, Jun Soo; Choi, Yong Joon; Smith, Curtis Lee
2016-09-01
This document addresses two subjects involved with the RELAP-7 Software Verification and Validation Plan (SVVP): (i) the principles and plan to assure the independence of RELAP-7 assessment through the code development process, and (ii) the work performed to establish the RELAP-7 assessment plan, i.e., the assessment strategy, literature review, and identification of RELAP-7 requirements. Then, the Requirements Traceability Matrices (RTMs) proposed in previous document (INL-EXT-15-36684) are updated. These RTMs provide an efficient way to evaluate the RELAP-7 development status as well as the maturity of RELAP-7 assessment through the development process.
ERIC Educational Resources Information Center
Barajas-Saavedra, Arturo; Álvarez-Rodriguez, Francisco J.; Mendoza-González, Ricardo; Oviedo-De-Luna, Ana C.
2015-01-01
Development of digital resources is difficult due to their particular complexity relying on pedagogical aspects. Another aspect is the lack of well-defined development processes, experiences documented, and standard methodologies to guide and organize game development. Added to this, there is no documented technique to ensure correct…
Information Model for Reusability in Clinical Trial Documentation
ERIC Educational Resources Information Center
Bahl, Bhanu
2013-01-01
In clinical research, New Drug Application (NDA) to health agencies requires generation of a large number of documents throughout the clinical development life cycle, many of which are also submitted to public databases and external partners. Current processes to assemble the information, author, review and approve the clinical research documents,…
29 CFR 11.11 - Development of environmental analyses and documents.
Code of Federal Regulations, 2011 CFR
2011-07-01
... development indicates that preparation of an environmental impact statement will be required, the agency shall begin preparation of such a document by initiating the scoping process in accordance with 40 CFR 1501.7. However, if the information is not clearly indicative of the need for preparation of an environmental...
NASA Technical Reports Server (NTRS)
Mckay, Charles
1991-01-01
This is the configuration management Plan for the AdaNet Repository Based Software Engineering (RBSE) contract. This document establishes the requirements and activities needed to ensure that the products developed for the AdaNet RBSE contract are accurately identified, that proposed changes to the product are systematically evaluated and controlled, that the status of all change activity is known at all times, and that the product achieves its functional performance requirements and is accurately documented.
Authorized limits for Fernald copper ingots
DOE Office of Scientific and Technical Information (OSTI.GOV)
Frink, N.; Kamboj, S.; Hensley, J.
This development document contains data and analysis to support the approval of authorized limits for the unrestricted release of 59 t of copper ingots containing residual radioactive material from the U.S. Department of Energy (DOE) Fernald Environmental Management Project (FEMP). The analysis presented in this document comply with the requirements of DOE Order 5400.5, {open_quotes}Radiation Protection of the Public and the Environment,{close_quotes} as well as the requirements of the proposed promulgation of this order as 10 CFR Part 834. The document was developed following the step-by-step process described in the Draft Handbook for Controlling Release for Reuse or Recycle Propertymore » Containing Residual Radioactive Material.« less
2007 Wholesale Power Rate Case Initial Proposal : Wholesale Power Rate Development Study.
DOE Office of Scientific and Technical Information (OSTI.GOV)
United States. Bonneville Power Administration.
The Wholesale Power Rate Development Study (WPRDS) calculates BPA proposed rates based on information either developed in the WPRDS or supplied by the other studies that comprise the BPA rate proposal. All of these studies, and accompanying documentation, provide the details of computations and assumptions. In general, information about loads and resources is provided by the Load Resource Study (LRS), WP-07-E-BPA-01, and the LRS Documentation, WP-07-E-BPA-01A. Revenue requirements information, as well as the Planned Net Revenues for Risk (PNNR), is provided in the Revenue Requirement Study, WP-07-E-BPA-02, and its accompanying Revenue Requirement Study Documentation, WP-07-E-BPA-02A and WP-07-E-BPA-02B. The Market Pricemore » Forecast Study (MPFS), WP-07-E-BPA-03, and the MPFS Documentation, WP-07-E-BPA-03A, provide the WPRDS with information regarding seasonal and diurnal differentiation of energy rates, as well information regarding monthly market prices for Demand Rates. In addition, this study provides information for the pricing of unbundled power products. The Risk Analysis Study, WP-07-E-BPA-04, and the Risk Analysis Study Documentation, WP-07-E-BPA-04A, provide short-term balancing purchases as well as secondary energy sales and revenue. The Section 7(b)(2) Rate Test Study, WP-07-E-BPA-06, and the Section 7(b)(2) Rate Test Study Documentation, WP-07-E-BPA-06A, implement Section 7(b)(2) of the Northwest Power Act to ensure that BPA preference customers firm power rates applied to their general requirements are no higher than rates calculated using specific assumptions in the Northwest Power Act.« less
Precise Documentation: The Key to Better Software
NASA Astrophysics Data System (ADS)
Parnas, David Lorge
The prime cause of the sorry “state of the art” in software development is our failure to produce good design documentation. Poor documentation is the cause of many errors and reduces efficiency in every phase of a software product's development and use. Most software developers believe that “documentation” refers to a collection of wordy, unstructured, introductory descriptions, thousands of pages that nobody wanted to write and nobody trusts. In contrast, Engineers in more traditional disciplines think of precise blueprints, circuit diagrams, and mathematical specifications of component properties. Software developers do not know how to produce precise documents for software. Software developments also think that documentation is something written after the software has been developed. In other fields of Engineering much of the documentation is written before and during the development. It represents forethought not afterthought. Among the benefits of better documentation would be: easier reuse of old designs, better communication about requirements, more useful design reviews, easier integration of separately written modules, more effective code inspection, more effective testing, and more efficient corrections and improvements. This paper explains how to produce and use precise software documentation and illustrate the methods with several examples.
Resolving the problem of compliance with the ever increasing and changing regulations
NASA Astrophysics Data System (ADS)
Leigh, Harley
1992-01-01
The most common problem identified at several U.S. Department of Energy (DOE) sites is regulatory compliance. Simply, the project viability depends on identifying regulatory requirements at the beginning of a specific project to avoid possible delays and cost overruns. The Radioisotope Power Systems Facility (RPSF) is using the Regulatory Compliance System (RCS) to deal with the problem that well over 1000 regulatory documents had to be reviewed for possible compliance requirements applicable to the facility. This overwhelming number of possible documents is not atypical of all DOE facilities thus far reviewed using the RCS system. The RCS was developed to provide control and tracking of all the regulatory and institutional requirements on a given project. WASTREN, Inc., developed the RCS through various DOE contracts and continues to enhance and update the system for existing and new contracts. The RCS provides the information to allow the technical expert to assimilate and manage accurate resource information, compile the necessary checklists, and document that the project or facility fulfills all of the appropriate regulatory requirements. The RCS provides on-line information, including status throughout the project life, thereby allowing more intelligent and proactive decision making. Also, consistency and traceability are provided for regulatory compliance documentation.
Transit safety retrofit package development : architecture and design specifications.
DOT National Transportation Integrated Search
2014-05-01
The Architecture and Design Specifications capture the TRP system architecture and design that fulfills the technical objectives stated in the TRP requirements document. The document begins with an architectural overview that identifies and describes...
78 FR 72903 - Collection of Information Under Review by Office of Management and Budget
Federal Register 2010, 2011, 2012, 2013, 2014
2013-12-04
... will address them accordingly. Viewing Comments and Documents To view comments, as well as documents.... This information is required to control vessel traffic, develop contingency plans and enforce...
Federal Register 2010, 2011, 2012, 2013, 2014
2011-10-26
.../DevelopmentApprovalProcess/FormsSubmissionRequirements/ElectronicSubmissions/ucm253101.htm , http://www.fda.gov/BiologicsBloodVaccines/GuidanceComplianceRegulatoryInformation/Guidances/default.htm , or http...
Review and comparison of quality standards, guidelines and regulations for laboratories.
Datema, Tjeerd A M; Oskam, Linda; Klatser, Paul R
2012-01-01
The variety and number of laboratory quality standards, guidelines and regulations (hereafter: quality documents) makes it difficult to choose the most suitable one for establishing and maintaining a laboratory quality management system. There is a need to compare the characteristics, suitability and applicability of quality documents in view of the increasing efforts to introduce quality management in laboratories, especially in clinical diagnostic laboratories in low income and middle income countries. This may provide valuable insights for policy makers developing national laboratory policies, and for laboratory managers and quality officers in choosing the most appropriate quality document for upgrading their laboratories. We reviewed the history of quality document development and then selected a subset based on their current use. We analysed these documents following a framework for comparison of quality documents that was adapted from the Clinical Laboratory Standards Institute guideline GP26 Quality management system model for clinical laboratory services . Differences were identified between national and international, and non-clinical and clinical quality documents. The most salient findings were the absence of provisions on occurrence management and customer service in almost all non-clinical quality documents, a low number of safety requirements aimed at protecting laboratory personnel in international quality documents and no requirements regarding ethical behaviour in almost all quality documents. Each laboratory needs to investigate whether national regulatory standards are present. These are preferred as they most closely suit the needs of laboratories in the country. A laboratory should always use both a standard and a guideline: a standard sums up the requirements to a quality management system, a guideline describes how quality management can be integrated in the laboratory processes.
The TMIS life-cycle process document, revision A
NASA Technical Reports Server (NTRS)
1991-01-01
The Technical and Management Information System (TMIS) Life-Cycle Process Document describes the processes that shall be followed in the definition, design, development, test, deployment, and operation of all TMIS products and data base applications. This document is a roll out of TMIS Standards Document (SSP 30546). The purpose of this document is to define the life cycle methodology that the developers of all products and data base applications and any subsequent modifications shall follow. Included in this methodology are descriptions of the tasks, deliverables, reviews, and approvals that are required before a product or data base application is accepted in the TMIS environment.
Traceability of Software Safety Requirements in Legacy Safety Critical Systems
NASA Technical Reports Server (NTRS)
Hill, Janice L.
2007-01-01
How can traceability of software safety requirements be created for legacy safety critical systems? Requirements in safety standards are imposed most times during contract negotiations. On the other hand, there are instances where safety standards are levied on legacy safety critical systems, some of which may be considered for reuse for new applications. Safety standards often specify that software development documentation include process-oriented and technical safety requirements, and also require that system and software safety analyses are performed supporting technical safety requirements implementation. So what can be done if the requisite documents for establishing and maintaining safety requirements traceability are not available?
Fundamental Travel Demand Model Example
NASA Technical Reports Server (NTRS)
Hanssen, Joel
2010-01-01
Instances of transportation models are abundant and detailed "how to" instruction is available in the form of transportation software help documentation. The purpose of this paper is to look at the fundamental inputs required to build a transportation model by developing an example passenger travel demand model. The example model reduces the scale to a manageable size for the purpose of illustrating the data collection and analysis required before the first step of the model begins. This aspect of the model development would not reasonably be discussed in software help documentation (it is assumed the model developer comes prepared). Recommendations are derived from the example passenger travel demand model to suggest future work regarding the data collection and analysis required for a freight travel demand model.
International Space Station Human Behavior and Performance Competency Model: Volume I
NASA Technical Reports Server (NTRS)
Schmidt, Lacey
2008-01-01
This document defines Human Behavior and Performance (HBP) competencies that are recommended to be included as requirements to participate in international long duration missions. They were developed in response to the Multilateral Crew Operations Panel (MMOP) request to develop HBP training requirements for the International Space Station (ISS). The competency model presented here was developed by the ITCB HBPT WG and forms the basis for determining the HBP training curriculum for long duration crewmembers. This document lists specific HBP competencies and behaviors required of astronauts/cosmonauts who participate in ISS expedition and other international longduration missions. Please note that this model does not encompass all competencies required. For example, outside the scope of this document are cognitive skills and abilities, including but not limited to concentration, memorization, perception, imagination, and thinking. It is assumed that these skills, which are crucial in terms of human behavior and performance, are considered during selection phase since such professionally significant qualities of the operator should be taken into consideration in order to ensure sufficient baseline levels that can be further improved during general astronaut training. Also, technical competencies, even though critical for crewmembers, are beyond the scope of this document. It should also be noted that the competencies in this model (and subsequent objectives) are not intended to limit the internal activities or training programs of any international partner.
Bridge, Heather; Smolskis, Mary; Bianchine, Peter; Dixon, Dennis O.; Kelly, Grace; Herpin, Betsey; Tavel, Jorge
2009-01-01
Background: A clinical research protocol document must reflect both sound scientific rationale as well as local, national and, when applicable, international regulatory and human subject protections requirements. These requirements originate from a variety of sources, undergo frequent revision and are subject to interpretation. Tools to assist clinical investigators in the production of clinical protocols could facilitate navigating these requirements and ultimately increase the efficiency of clinical research. Purpose: The National Institute of Allergy and Infectious Diseases (NIAID) developed templates for investigators to serve as the foundation for protocol development. These protocol templates are designed as tools to support investigators in developing clinical protocols. Methods: NIAID established a series of working groups to determine how to improve its capacity to conduct clinical research more efficiently and effectively. The Protocol Template Working Group was convened to determine what protocol templates currently existed within NIAID and whether standard NIAID protocol templates should be produced. After review and assessment of existing protocol documents and requirements, the group reached consensus about required and optional content, determined the format and identified methods for distribution as well as education of investigators in the use of these templates. Results: The templates were approved by the NIAID Executive Committee in 2006 and posted as part of the NIAID Clinical Research Toolkit[1]website for broad access. These documents require scheduled revisions to stay current with regulatory and policy changes. Limitations: The structure of any clinical protocol template, whether comprehensive or specific to a particular study phase, setting or design, affects how it is used by investigators. Each structure presents its own set of advantages and disadvantages. While useful, protocol templates are not stand-alone tools for creating an optimal protocol document but must be complemented by institutional resources and support. Education and guidance of investigators in the appropriate use of templates is necessary to ensure a complete yet concise protocol document. Due to changing regulatory requirements, clinical protocol templates cannot become static but require frequent revisions. Conclusions: Standard protocol templates that meet applicable regulations can be important tools to assist investigators in the effective conduct of clinical research, but they require dedicated resources and ongoing input from key stakeholders. PMID:19625326
Waste certification program plan for Oak Ridge National Laboratory. Revision 2
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1997-09-01
This document defines the waste certification program (WCP) developed for implementation at Oak Ridge National Laboratory (ORNL). The document describes the program structure, logic, and methodology for certification of ORNL wastes. The purpose of the WCP is to provide assurance that wastes are properly characterized and that the Waste Acceptance Criteria (WAC) for receiving facilities are met. The program meets the waste certification requirements for mixed (both radioactive and hazardous) and hazardous [including polychlorinated biphenyls (PCB)] waste. Program activities will be conducted according to ORNL Level 1 document requirements.
Smart gun technology requirements preliminary report
DOE Office of Scientific and Technical Information (OSTI.GOV)
Weiss, D.R.; Brandt, D.J.; Tweet, K.D.
Goal of the Smart Gun Technology project is to eliminate the capability of an unauthorized user from firing a law enforcement officer`s firearm by implementing user-recognizing-and-authorizing surety technologies. This project is funded by the National Institute of Justice. This document reports the projects first objective: to find and document the requirements for a user-recognizing-and-authorizing firearm technology that law enforcement officers will value. This report details the problem of firearm takeaways in law enforcement, the methodology used to develop the law enforcement officers` requirements, and the requirements themselves.
Intentionally Short-Range Communications (ISRC) exploratory development plan
NASA Astrophysics Data System (ADS)
Yen, J.
1992-06-01
This document is an exploratory development plan for the Intentionally Short-Range Communications (ISRC) project. The USMC requirements and project objectives are quantified, then possible solutions identified and developed. Some of these ideas will be attempted to determine the best option(s) satisfying the USMC requirements.
What is the Final Verification of Engineering Requirements?
NASA Technical Reports Server (NTRS)
Poole, Eric
2010-01-01
This slide presentation reviews the process of development through the final verification of engineering requirements. The definition of the requirements is driven by basic needs, and should be reviewed by both the supplier and the customer. All involved need to agree upon a formal requirements including changes to the original requirements document. After the requirements have ben developed, the engineering team begins to design the system. The final design is reviewed by other organizations. The final operational system must satisfy the original requirements, though many verifications should be performed during the process. The verification methods that are used are test, inspection, analysis and demonstration. The plan for verification should be created once the system requirements are documented. The plan should include assurances that every requirement is formally verified, that the methods and the responsible organizations are specified, and that the plan is reviewed by all parties. The options of having the engineering team involved in all phases of the development as opposed to having some other organization continue the process once the design has been complete is discussed.
Facilitating access to information in large documents with an intelligent hypertext system
NASA Technical Reports Server (NTRS)
Mathe, Nathalie
1993-01-01
Retrieving specific information from large amounts of documentation is not an easy task. It could be facilitated if information relevant in the current problem solving context could be automatically supplied to the user. As a first step towards this goal, we have developed an intelligent hypertext system called CID (Computer Integrated Documentation) and tested it on the Space Station Freedom requirement documents. The CID system enables integration of various technical documents in a hypertext framework and includes an intelligent context-sensitive indexing and retrieval mechanism. This mechanism utilizes on-line user information requirements and relevance feedback either to reinforce current indexing in case of success or to generate new knowledge in case of failure. This allows the CID system to provide helpful responses, based on previous usage of the documentation, and to improve its performance over time.
Space shuttle entry terminal area energy management
NASA Technical Reports Server (NTRS)
Moore, Thomas E.
1991-01-01
A historical account of the development for Shuttle's Terminal Area Energy Management (TAEM) is presented. A derivation and explanation of logic and equations are provided as a supplement to the well documented guidance computation requirements contained within the official Functional Subsystem Software Requirements (FSSR) published by Rockwell for NASA. The FSSR contains the full set of equations and logic, whereas this document addresses just certain areas for amplification.
NOSS Altimeter Detailed Algorithm specifications
NASA Technical Reports Server (NTRS)
Hancock, D. W.; Mcmillan, J. D.
1982-01-01
The details of the algorithms and data sets required for satellite radar altimeter data processing are documented in a form suitable for (1) development of the benchmark software and (2) coding the operational software. The algorithms reported in detail are those established for altimeter processing. The algorithms which required some additional development before documenting for production were only scoped. The algorithms are divided into two levels of processing. The first level converts the data to engineering units and applies corrections for instrument variations. The second level provides geophysical measurements derived from altimeter parameters for oceanographic users.
Security Policy for a Generic Space Exploration Communication Network Architecture
NASA Technical Reports Server (NTRS)
Ivancic, William D.; Sheehe, Charles J.; Vaden, Karl R.
2016-01-01
This document is one of three. It describes various security mechanisms and a security policy profile for a generic space-based communication architecture. Two other documents accompany this document- an Operations Concept (OpsCon) and a communication architecture document. The OpsCon should be read first followed by the security policy profile described by this document and then the architecture document. The overall goal is to design a generic space exploration communication network architecture that is affordable, deployable, maintainable, securable, evolvable, reliable, and adaptable. The architecture should also require limited reconfiguration throughout system development and deployment. System deployment includes subsystem development in a factory setting, system integration in a laboratory setting, launch preparation, launch, and deployment and operation in space.
Interface for the documentation and compilation of a library of computer models in physiology.
Summers, R. L.; Montani, J. P.
1994-01-01
A software interface for the documentation and compilation of a library of computer models in physiology was developed. The interface is an interactive program built within a word processing template in order to provide ease and flexibility of documentation. A model editor within the interface directs the model builder as to standardized requirements for incorporating models into the library and provides the user with an index to the levels of documentation. The interface and accompanying library are intended to facilitate model development, preservation and distribution and will be available for public use. PMID:7950046
Quality assurance planning for lunar Mars exploration
NASA Technical Reports Server (NTRS)
Myers, Kay
1991-01-01
A review is presented of the tools and techniques required to meet the challenge of total quality in the goal of traveling to Mars and returning to the moon. One program used by NASA to ensure the integrity of baselined requirements documents is configuration management (CM). CM is defined as an integrated management process that documents and identifies the functional and physical characteristics of a facility's systems, structures, computer software, and components. It also ensures that changes to these characteristics are properly assessed, developed, approved, implemented, verified, recorded, and incorporated into the facility's documentation. Three principal areas are discussed that will realize significant efficiencies and enhanced effectiveness, change assessment, change avoidance, and requirements management.
Large area crop inventory experiment crop assessment subsystem software requirements document
NASA Technical Reports Server (NTRS)
1975-01-01
The functional data processing requirements are described for the Crop Assessment Subsystem of the Large Area Crop Inventory Experiment. These requirements are used as a guide for software development and implementation.
A CMMI-based approach for medical software project life cycle study.
Chen, Jui-Jen; Su, Wu-Chen; Wang, Pei-Wen; Yen, Hung-Chi
2013-01-01
In terms of medical techniques, Taiwan has gained international recognition in recent years. However, the medical information system industry in Taiwan is still at a developing stage compared with the software industries in other nations. In addition, systematic development processes are indispensable elements of software development. They can help developers increase their productivity and efficiency and also avoid unnecessary risks arising during the development process. Thus, this paper presents an application of Light-Weight Capability Maturity Model Integration (LW-CMMI) to Chang Gung Medical Research Project (CMRP) in the Nuclear medicine field. This application was intended to integrate user requirements, system design and testing of software development processes into three layers (Domain, Concept and Instance) model. Then, expressing in structural System Modeling Language (SysML) diagrams and converts part of the manual effort necessary for project management maintenance into computational effort, for example: (semi-) automatic delivery of traceability management. In this application, it supports establishing artifacts of "requirement specification document", "project execution plan document", "system design document" and "system test document", and can deliver a prototype of lightweight project management tool on the Nuclear Medicine software project. The results of this application can be a reference for other medical institutions in developing medical information systems and support of project management to achieve the aim of patient safety.
AgRISTARS: Yield model development/soil moisture. Interface control document
NASA Technical Reports Server (NTRS)
1980-01-01
The interactions and support functions required between the crop Yield Model Development (YMD) Project and Soil Moisture (SM) Project are defined. The requirements for YMD support of SM and vice-versa are outlined. Specific tasks in support of these interfaces are defined for development of support functions.
75 FR 27797 - Notice of Meeting
Federal Register 2010, 2011, 2012, 2013, 2014
2010-05-18
... Offering and Documenting Influenza Vaccination for Nursing Home Residents, Funding Opportunity Announcement... State Law Requiring Mandatory Influenza Vaccination of Hospital Employees, FOA IP10-003; and Improving... Offering and Documenting Influenza Vaccination for Nursing Home Residents, FOA IP10-001; Development...
Kamine Development Corporation Request for a PSD Innovative Control Technology Waiver
This document may be of assistance in applying the New Source Review (NSR) air permitting regulations including the Prevention of Significant Deterioration (PSD) requirements. This document is part of the NSR Policy and Guidance Database. Some documents in the database are a scanned or retyped version of a paper photocopy of the original. Although we have taken considerable effort to quality assure the documents, some may contain typographical errors. Contact the office that issued the document if you need a copy of the original.
10 CFR 850 Implementation of Requirements
DOE Office of Scientific and Technical Information (OSTI.GOV)
Lee, S
2012-01-05
10 CFR 850 defines a contractor as any entity, including affiliated entities, such as a parent corporation, under contract with DOE, including a subcontractor at any tier, with responsibility for performing work at a DOE site in furtherance of a DOE mission. The Chronic Beryllium Disease Prevention Program (CBDPP) applies to beryllium-related activities that are performed at the Lawrence Livermore National Laboratory (LLNL). The CBDPP or Beryllium Safety Program is integrated into the LLNL Worker Safety and Health Program and, thus, implementation documents and responsibilities are integrated in various documents and organizational structures. Program development and management of the CBDPPmore » is delegated to the Environment, Safety and Health (ES&H) Directorate, Worker Safety and Health Functional Area. As per 10 CFR 850, Lawrence Livermore National Security, LLC (LLNS) periodically submits a CBDPP to the National Nuclear Security Administration/Livermore Site Office (NNSA/LSO). The requirements of this plan are communicated to LLNS workers through ES&H Manual Document 14.4, 'Working Safely with Beryllium.' 10 CFR 850 is implemented by the LLNL CBDPP, which integrates the safety and health standards required by the regulation, components of the LLNL Integrated Safety Management System (ISMS), and incorporates other components of the LLNL ES&H Program. As described in the regulation, and to fully comply with the regulation, specific portions of existing programs and additional requirements are identified in the CBDPP. The CBDPP is implemented by documents that interface with the workers, principally through ES&H Manual Document 14.4. This document contains information on how the management practices prescribed by the LLNL ISMS are implemented, how beryllium hazards that are associated with LLNL work activities are controlled, and who is responsible for implementing the controls. Adherence to the requirements and processes described in the ES&H Manual ensures that ES&H practices across LLNL are developed in a consistent manner. Other implementing documents, such as the ES&H Manual, are integral in effectively implementing 10 CFR 850.« less
Application Agreement and Integration Services
NASA Technical Reports Server (NTRS)
Driscoll, Kevin R.; Hall, Brendan; Schweiker, Kevin
2013-01-01
Application agreement and integration services are required by distributed, fault-tolerant, safety critical systems to assure required performance. An analysis of distributed and hierarchical agreement strategies are developed against the backdrop of observed agreement failures in fielded systems. The documented work was performed under NASA Task Order NNL10AB32T, Validation And Verification of Safety-Critical Integrated Distributed Systems Area 2. This document is intended to satisfy the requirements for deliverable 5.2.11 under Task 4.2.2.3. This report discusses the challenges of maintaining application agreement and integration services. A literature search is presented that documents previous work in the area of replica determinism. Sources of non-deterministic behavior are identified and examples are presented where system level agreement failed to be achieved. We then explore how TTEthernet services can be extended to supply some interesting application agreement frameworks. This document assumes that the reader is familiar with the TTEthernet protocol. The reader is advised to read the TTEthernet protocol standard [1] before reading this document. This document does not re-iterate the content of the standard.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Bandlow, Alisa; Durfee, Justin David; Frazier, Christopher Rawls
2016-05-01
This requirements document serves as an addendum to the Contingency Contractor Optimization Phase 2, Requirements Document [1] and Phase 3 Requirements Document [2]. The Phase 2 Requirements document focused on the high-level requirements for the tool. The Phase 3 Requirements document provided more detailed requirements to which the engineering prototype was built in Phase 3. This document will provide detailed requirements for features and enhancements being added to the production pilot in the Phase 3 Sustainment.
Systems simulation for an airport trailing vortex warning system
NASA Technical Reports Server (NTRS)
Jeffreys, H. B.
1972-01-01
The approach, development, and limited system studies associated with a system simulation for an Airport Trailing Vortex Warning System are documented. The usefulness is shown of a systems engineering approach to the problem of developing a system, as dictated by aircraft vortices, which will increase air-traffic flow in the takeoff/landing corridors of busy airports while maintaining the required safety factor for each operation. The simulation program has been developed in a modular form which permits new, more sophisticated component models, when they become available and are required, to be incorporated into the program with a minimum of program modifications. This report documents a limited system study that has been performed using this Total System Simulation Model. The resulting preliminary system requirements, conclusions, and recommendations are given.
36 CFR 801.7 - Information requirements.
Code of Federal Regulations, 2014 CFR
2014-07-01
... 36 Parks, Forests, and Public Property 3 2014-07-01 2014-07-01 false Information requirements. 801... HISTORIC PRESERVATION REQUIREMENTS OF THE URBAN DEVELOPMENT ACTION GRANT PROGRAM § 801.7 Information requirements. (a) Information To Be Retained by Applicants Determining No Effect. (1) Recommended Documentation...
The software development process at the Chandra X-ray Center
NASA Astrophysics Data System (ADS)
Evans, Janet D.; Evans, Ian N.; Fabbiano, Giuseppina
2008-08-01
Software development for the Chandra X-ray Center Data System began in the mid 1990's, and the waterfall model of development was mandated by our documents. Although we initially tried this approach, we found that a process with elements of the spiral model worked better in our science-based environment. High-level science requirements are usually established by scientists, and provided to the software development group. We follow with review and refinement of those requirements prior to the design phase. Design reviews are conducted for substantial projects within the development team, and include scientists whenever appropriate. Development follows agreed upon schedules that include several internal releases of the task before completion. Feedback from science testing early in the process helps to identify and resolve misunderstandings present in the detailed requirements, and allows review of intangible requirements. The development process includes specific testing of requirements, developer and user documentation, and support after deployment to operations or to users. We discuss the process we follow at the Chandra X-ray Center (CXC) to develop software and support operations. We review the role of the science and development staff from conception to release of software, and some lessons learned from managing CXC software development for over a decade.
San Francisco urban partnership agreement, national evaluation : telecommuting/TDM data test plan.
DOT National Transportation Integrated Search
2002-04-01
The Standards Requirements Document (SRD) collects information from the other National ITS Architecture program documents and reorganizes it in a manner intended to support the development of critical ITS standards. The key results in the SRD a...
Resolving the problem of compliance with the ever increasing and changing regulations
DOE Office of Scientific and Technical Information (OSTI.GOV)
Leigh, H.
1991-06-01
The most common problem identified at several US Department of Energy (DOE) sites is regulatory compliance. Simply, the project viability depends on identifying regulatory requirements at the beginning of a specific project to avoid possible delays and cost overruns. The Radioisotope Power Systems Facility (RFSP) is using the Regulatory Compliance System (RCS) to deal with the problem that well over 1000 regulatory documents had to be reviewed for possible compliance requirements applicable to the facility. This overwhelming number of possible documents is not atypical of all DOE facilities thus far reviewed using the RCS system. The RCS was developed tomore » provide a control and tracking of all the regulatory and institutional requirements on a given project. WASTREN, Inc., developed the RCS through various DOE contracts and continues to enhance and update the system for existing and new contracts. The RCS provides the information to allow the technical expert to assimilate and manage accurate resource information, compile the checklists, and document that the project or facility fulfills all of the appropriate regulatory requirements. The RCS provides on-line information, including status throughput the project life, thereby allowing more intelligent and proactive decision making. Also, consistency and traceability are provided for regulatory compliance documentation. 1 ref., 1 fig.« less
Requirements, Verification, and Compliance (RVC) Database Tool
NASA Technical Reports Server (NTRS)
Rainwater, Neil E., II; McDuffee, Patrick B.; Thomas, L. Dale
2001-01-01
This paper describes the development, design, and implementation of the Requirements, Verification, and Compliance (RVC) database used on the International Space Welding Experiment (ISWE) project managed at Marshall Space Flight Center. The RVC is a systems engineer's tool for automating and managing the following information: requirements; requirements traceability; verification requirements; verification planning; verification success criteria; and compliance status. This information normally contained within documents (e.g. specifications, plans) is contained in an electronic database that allows the project team members to access, query, and status the requirements, verification, and compliance information from their individual desktop computers. Using commercial-off-the-shelf (COTS) database software that contains networking capabilities, the RVC was developed not only with cost savings in mind but primarily for the purpose of providing a more efficient and effective automated method of maintaining and distributing the systems engineering information. In addition, the RVC approach provides the systems engineer the capability to develop and tailor various reports containing the requirements, verification, and compliance information that meets the needs of the project team members. The automated approach of the RVC for capturing and distributing the information improves the productivity of the systems engineer by allowing that person to concentrate more on the job of developing good requirements and verification programs and not on the effort of being a "document developer".
Step 1: Human System Interface (HSI) Functional Requirements Document (FRD). Version 2
NASA Technical Reports Server (NTRS)
2006-01-01
This Functional Requirements Document (FRD) establishes a minimum set of Human System Interface (HSI) functional requirements to achieve the Access 5 Vision of "operating High Altitude, Long Endurance (HALE) Unmanned Aircraft Systems (UAS) routinely, safely, and reliably in the National Airspace System (NAS)". Basically, it provides what functions are necessary to fly UAS in the NAS. The framework used to identify the appropriate functions was the "Aviate, Navigate, Communicate, and Avoid Hazards" structure identified in the Access 5 FRD. As a result, fifteen high-level functional requirements were developed. In addition, several of them have been decomposed into low-level functional requirements to provide more detail.
Advanced Extravehicular Activity Breakout Group Summary
NASA Technical Reports Server (NTRS)
Kosmo, Joseph J.; Perka, Alan; Walz, Carl; Cobb, Sharon; Hanford, Anthony; Eppler, Dean
2005-01-01
This viewgraph document summarizes the workings of the Advanced Extravehicular Activity (AEVA) Breakout group in a Martian environment. The group was tasked with: identifying potential contaminants and pathways for AEVA systems with respect to forward and backward contamination; identifying plausible mitigation alternatives and obstacles for pertinent missions; identifying topics that require further research and technology development and discuss development strategies with uncertain Planetary Protection (PP) requirements; Identifying PP requirements that impose the greatest mission/development costs; Identifying PP requirements/topics that require further definition;
Model documentation report: Transportation sector model of the National Energy Modeling System
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1994-03-01
This report documents the objectives, analytical approach and development of the National Energy Modeling System (NEMS) Transportation Model (TRAN). The report catalogues and describes the model assumptions, computational methodology, parameter estimation techniques, model source code, and forecast results generated by the model. This document serves three purposes. First, it is a reference document providing a detailed description of TRAN for model analysts, users, and the public. Second, this report meets the legal requirements of the Energy Information Administration (EIA) to provide adequate documentation in support of its statistical and forecast reports (Public Law 93-275, 57(b)(1)). Third, it permits continuity inmore » model development by providing documentation from which energy analysts can undertake model enhancements, data updates, and parameter refinements.« less
Operational Concepts for a Generic Space Exploration Communication Network Architecture
NASA Technical Reports Server (NTRS)
Ivancic, William D.; Vaden, Karl R.; Jones, Robert E.; Roberts, Anthony M.
2015-01-01
This document is one of three. It describes the Operational Concept (OpsCon) for a generic space exploration communication architecture. The purpose of this particular document is to identify communication flows and data types. Two other documents accompany this document, a security policy profile and a communication architecture document. The operational concepts should be read first followed by the security policy profile and then the architecture document. The overall goal is to design a generic space exploration communication network architecture that is affordable, deployable, maintainable, securable, evolvable, reliable, and adaptable. The architecture should also require limited reconfiguration throughout system development and deployment. System deployment includes: subsystem development in a factory setting, system integration in a laboratory setting, launch preparation, launch, and deployment and operation in space.
Template protocol for clinical trials investigating vaccines—Focus on safety elements☆
Bonhoeffer, Jan; Imoukhuede, Egeruan B.; Aldrovandi, Grace; Bachtiar, Novilia S.; Chan, Eng-Soon; Chang, Soju; Chen, Robert T.; Fernandopulle, Rohini; Goldenthal, Karen L.; Heffelfinger, James D.; Hossain, Shah; Jevaji, Indira; Khamesipour, Ali; Kochhar, Sonali; Makhene, Mamodikoe; Malkin, Elissa; Nalin, David; Prevots, Rebecca; Ramasamy, Ranjan; Sellers, Sarah; Vekemans, Johan; Walker, Kenneth B.; Wilson, Pam; Wong, Virginia; Zaman, Khalequz; Heininger, Ulrich
2015-01-01
This document is intended as a guide to the protocol development for trials of prophylactic vaccines. The template may serve phases I–IV clinical trials protocol development to include safety relevant information as required by the regulatory authorities and as deemed useful by the investigators. This document may also be helpful for future site strengthening efforts. PMID:23499603
10 CFR 830.205 - Technical safety requirements.
Code of Federal Regulations, 2010 CFR
2010-01-01
... must: (1) Develop technical safety requirements that are derived from the documented safety analysis... 10 Energy 4 2010-01-01 2010-01-01 false Technical safety requirements. 830.205 Section 830.205 Energy DEPARTMENT OF ENERGY NUCLEAR SAFETY MANAGEMENT Safety Basis Requirements § 830.205 Technical...
10 CFR 830.205 - Technical safety requirements.
Code of Federal Regulations, 2011 CFR
2011-01-01
... must: (1) Develop technical safety requirements that are derived from the documented safety analysis... 10 Energy 4 2011-01-01 2011-01-01 false Technical safety requirements. 830.205 Section 830.205 Energy DEPARTMENT OF ENERGY NUCLEAR SAFETY MANAGEMENT Safety Basis Requirements § 830.205 Technical...
Phase 111A Crew Interface Specifications Development for Inflight Maintenance and Stowage Functions
NASA Technical Reports Server (NTRS)
Carl, John G.
1973-01-01
This report presents the findings and data products developed during the Phase IIIA Crew Interface Specification Study for Inflight Maintenance and Stowage Functions, performed by General Electric for the NASA, Johnson Space Center with a set of documentation that can be used as definitive guidelines to improve the present process of defining, controlling and managing flight crew interface requirements that are related to inflight maintenance (including assembly and servicing) and stowage functions. During the Phase IIIA contract period, the following data products were developed: 1) Projected NASA Crew Procedures/Flight Data File Development Process. 2) Inflight Maintenance Management Process Description. 3) Preliminary Draft, General Specification, Inflight Maintenance Management Requirements. 4) Inflight Maintenance Operational Process Description. 5) Preliminary Draft, General Specification, Inflight Maintenance Task and Support Requirements Analysis. 6) Suggested IFM Data Processing Reports for Logistics Management The above Inflight Maintenance data products have been developed during the Phase IIIA study after review of Space Shuttle Program Documentation, including the Level II Integrated Logistics Requirements and other DOD and NASA data relative to Payloads Accommodations and Satellite On-Orbit Servicing. These Inflight Maintenance data products were developed to be in consonance with Space Shuttle Program technical and management requirements.
Space Station Program Description Document. Books 1-7
NASA Technical Reports Server (NTRS)
1984-01-01
The Space Station Program Description Document is summarized. The six volumes include: (1) introduction and summary; (2) mission description; (3) systems requirements and characteristics; (4) advanced development; (6) system operations; and (7) program plan. Volume 5 was deleted as a separate book.
48 CFR 752.7003 - Documentation for payment.
Code of Federal Regulations, 2011 CFR
2011-10-01
.... 752.7003 Section 752.7003 Federal Acquisition Regulations System AGENCY FOR INTERNATIONAL DEVELOPMENT CLAUSES AND FORMS SOLICITATION PROVISIONS AND CONTRACT CLAUSES Texts of USAID Contract Clauses 752.7003 Documentation for payment. The following clause is required in all USAID direct contracts, excluding fixed price...
Physiology of chimpanzees in orbit. Part 2: Interface document
NASA Technical Reports Server (NTRS)
Firstenberg, A.
1972-01-01
Interface requirements are presented for the design and development of an earth orbiting experiment to be known as POCO, Physiology of Chimpanzees in Orbit. The POCO experiment may be designed to operate within an orbiting space station (provided artificial gravity measures are not employed), a Saturn 4-B workshop, an Apollo command module or service module, a Saturn-1B spacecraft LM adapter, or aboard one of the presently conceived appendages connected by an umbilical to a space station. This document sets forth the experiment definition and requirements and describes the hardware under development to accomplish these objectives.
Developing Approvable State Enabling Legislation Required to Implement Title V
This document may be of assistance in applying the Title V air operating permit regulations. This document is part of the Title V Policy and Guidance Database available at www2.epa.gov/title-v-operating-permits/title-v-operating-permit-policy-and-guidance-document-index. Some documents in the database are a scanned or retyped version of a paper photocopy of the original. Although we have taken considerable effort to quality assure the documents, some may contain typographical errors. Contact the office that issued the document if you need a copy of the original.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Holter, Gregory M
2001-01-26
This Operational Requirements Document (ORD) describes the capabilities that need to be incorporated in the NCC interactive simulation system being developed under the auspices of the NCC development program. The ORD addresses the necessary capabilities (i.e. what the system needs to be able to do); it defines the envelope of situations and circumstances that the NCC system must be able to represent and operate within. The NCC system will be developed in modules over a period of several years. This ORD, Version 2, supersedes the previous version. Future updates of this ORD are anticipated to be issued as needed tomore » guide the development of later versions of the NCC system.« less
The integration of system specifications and program coding
NASA Technical Reports Server (NTRS)
Luebke, W. R.
1970-01-01
Experience in maintaining up-to-date documentation for one module of the large-scale Medical Literature Analysis and Retrieval System 2 (MEDLARS 2) is described. Several innovative techniques were explored in the development of this system's data management environment, particularly those that use PL/I as an automatic documenter. The PL/I data description section can provide automatic documentation by means of a master description of data elements that has long and highly meaningful mnemonic names and a formalized technique for the production of descriptive commentary. The techniques discussed are practical methods that employ the computer during system development in a manner that assists system implementation, provides interim documentation for customer review, and satisfies some of the deliverable documentation requirements.
Software Management Environment (SME) concepts and architecture, revision 1
NASA Technical Reports Server (NTRS)
Hendrick, Robert; Kistler, David; Valett, Jon
1992-01-01
This document presents the concepts and architecture of the Software Management Environment (SME), developed for the Software Engineering Branch of the Flight Dynamic Division (FDD) of GSFC. The SME provides an integrated set of experience-based management tools that can assist software development managers in managing and planning flight dynamics software development projects. This document provides a high-level description of the types of information required to implement such an automated management tool.
Long range targeting for space based rendezvous
NASA Technical Reports Server (NTRS)
Everett, Louis J.; Redfield, R. C.
1995-01-01
The work performed under this grant supported the Dexterous Flight Experiment one STS-62 The project required developing hardware and software for automating a TRAC sensor on orbit. The hardware developed by for the flight has been documented through standard NASA channels since it has to pass safety, environmental, and other issues. The software has not been documented previously, therefore, this report provides a software manual for the TRAC code developed for the grant.
Software Management Environment (SME) installation guide
NASA Technical Reports Server (NTRS)
Kistler, David; Jeletic, Kellyann
1992-01-01
This document contains installation information for the Software Management Environment (SME), developed for the Systems Development Branch (Code 552) of the Flight Dynamics Division of Goddard Space Flight Center (GSFC). The SME provides an integrated set of management tools that can be used by software development managers in their day-to-day management and planning activities. This document provides a list of hardware and software requirements as well as detailed installation instructions and trouble-shooting information.
Onboard shuttle on-line software requirements system: Prototype
NASA Technical Reports Server (NTRS)
Kolkhorst, Barbara; Ogletree, Barry
1989-01-01
The prototype discussed here was developed as proof of a concept for a system which could support high volumes of requirements documents with integrated text and graphics; the solution proposed here could be extended to other projects whose goal is to place paper documents in an electronic system for viewing and printing purposes. The technical problems (such as conversion of documentation between word processors, management of a variety of graphics file formats, and difficulties involved in scanning integrated text and graphics) would be very similar for other systems of this type. Indeed, technological advances in areas such as scanning hardware and software and display terminals insure that some of the problems encountered here will be solved in the near-term (less than five years). Examples of these solvable problems include automated input of integrated text and graphics, errors in the recognition process, and the loss of image information which results from the digitization process. The solution developed for the Online Software Requirements System is modular and allows hardware and software components to be upgraded or replaced as industry solutions mature. The extensive commercial software content allows the NASA customer to apply resources to solving the problem and maintaining documents.
Hitchhiker: Customer Accommodations and Requirements Specifications (CARS)
NASA Technical Reports Server (NTRS)
1992-01-01
In 1984, NASA Headquarters established projects at the Goddard Space Flight Center (GSFC) and the Marshall Space Flight Center (MSFC) to develop quick-reaction carrier systems for low-cost 'flight of opportunity' or secondary payloads on the Space Transportation System (STS). One of these projects is the Hitchhiker (HH) Program. GSFC has developed a family of carrier equipment known as the Shuttle Payload of Opportunity Carrier (SPOC) system for mounting small payloads such as HH to the side of the Orbiter payload bay. The side-mounted HHs are referred to as Hitchhiker-G (HH-G). MSFC developed a cross-bay 'bridge-type' carrier structure called the Hitchhiker-M (HH-M). In 1987, responsibility for the HH-M carrier was transferred to and is now managed by the HH Project Office at the GSFC. The HH-M carrier now uses the same interchangeable SPOC avionics unit and the same electrical interfaces and services developed for HH-G. National Aeronautics and Space Administration (NASA) has created this document to acquaint potential HH system customers with the facilities NASA provides and the requirements which customers must satisfy to use these facilities. This publication defines interface items required for integrating customer equipment with the HH carrier system. Those items such as mounting equipment and electrical inputs and outputs; configuration, environmental, command, telemetry, and operational constraints are described as well as weight, power, and communications. The purpose of this publication is to help the customer understand essential integration documentation requirements and to prepare a Customer Payload Requirements (CPR) document.
Space Station end effector strategy study
NASA Technical Reports Server (NTRS)
Katzberg, Stephen J.; Jensen, Robert L.; Willshire, Kelli F.; Satterthwaite, Robert E.
1987-01-01
The results of a study are presented for terminology definition, identification of functional requirements, technolgy assessment, and proposed end effector development strategies for the Space Station Program. The study is composed of a survey of available or under-developed end effector technology, identification of requirements from baselined Space Station documents, a comparative assessment of the match between technology and requirements, and recommended strategies for end effector development for the Space Station Program.
HALE UAS Concept of Operations. Version 3.0
NASA Technical Reports Server (NTRS)
2006-01-01
This document is a system level Concept of Operations (CONOPS) from the perspective of future High Altitude Long Endurance (HALE) Unmanned Aircraft Systems (UAS) service providers and National Airspace System (NAS) users. It describes current systems (existing UAS), describes HALE UAS functions and operations to be performed (via sample missions), and offers insight into the user s environment (i.e., the UAS as a system of systems). It is intended to be a source document for NAS UAS operational requirements, and provides a construct for government agencies to use in guiding their regulatory decisions, architecture requirements, and investment strategies. Although it does not describe the technical capabilities of a specific HALE UAS system (which do, and will vary widely), it is intended to aid in requirements capture and to be used as input to the functional requirements and analysis process. The document provides a basis for development of functional requirements and operational guidelines to achieve unrestricted access into the NAS. This document is an FY06 update to the FY05 Access 5 Project-approved Concept of Operations document previously published in the Public Domain on the Access 5 open website. This version is recommended to be approved for public release also. The updates are a reorganization of materials from the previous version with the addition of an updated set of operational requirements, inclusion of sample mission scenarios, and identification of roles and responsibilities of interfaces within flight phases.
Managing the life cycle of electronic clinical documents.
Payne, Thomas H; Graham, Gail
2006-01-01
To develop a model of the life cycle of clinical documents from inception to use in a person's medical record, including workflow requirements from clinical practice, local policy, and regulation. We propose a model for the life cycle of clinical documents as a framework for research on documentation within electronic medical record (EMR) systems. Our proposed model includes three axes: the stages of the document, the roles of those involved with the document, and the actions those involved may take on the document at each stage. The model includes the rules to describe who (in what role) can perform what actions on the document, and at what stages they can perform them. Rules are derived from needs of clinicians, and requirements of hospital bylaws and regulators. Our model encompasses current practices for paper medical records and workflow in some EMR systems. Commercial EMR systems include methods for implementing document workflow rules. Workflow rules that are part of this model mirror functionality in the Department of Veterans Affairs (VA) EMR system where the Authorization/ Subscription Utility permits document life cycle rules to be written in English-like fashion. Creating a model of the life cycle of clinical documents serves as a framework for discussion of document workflow, how rules governing workflow can be implemented in EMR systems, and future research of electronic documentation.
Region 7 Quality Management Plan
To document adherence to EPA Order 5360.1 A2, EPA requires each organizational unitto develop a quality management plan per the specifications in EPA Requirements for QualityManagement Plans, EPA QA R-2.
48 CFR 411.101 - Order of precedence for requirements documents.
Code of Federal Regulations, 2010 CFR
2010-10-01
... AGRICULTURE COMPETITION AND ACQUISITION PLANNING DESCRIBING AGENCY NEEDS Selecting and Developing Requirements... National Institute of Standards and Technology in accordance with the Circular with a copy provided to the...
Directory of Energy Information Administration model abstracts
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1987-08-11
This report contains brief statements from the model managers about each model's title, acronym, purpose, and status, followed by more detailed information on characteristics, uses, and requirements. Sources for additional information are identified. All models ''active'' through March 1987 are included. The main body of this directory is an alphabetical list of all active EIA models. Appendix A identifies major EIA modeling systems and the models within these systems, and Appendix B identifies active EIA models by type (basic, auxiliary, and developing). A basic model is one designated by the EIA Administrator as being sufficiently important to require sustained supportmore » and public scrutiny. An auxiliary model is one designated by the EIA Administrator as being used only occasionally in analyses, and therefore requires minimal levels of documentation. A developing model is one designated by the EIA Administrator as being under development and yet of sufficient interest to require a basic level of documentation at a future date. EIA also leases models developed by proprietary software vendors. Documentation for these ''proprietary'' models is the responsibility of the companies from which they are leased. EIA has recently leased models from Chase Econometrics, Inc., Data Resources, Inc. (DRI), the Oak Ridge National Laboratory (ORNL), and Wharton Econometric Forecasting Associates (WEFA). Leased models are not abstracted here. The directory is intended for the use of energy and energy-policy analysts in the public and private sectors.« less
Crew procedures development techniques
NASA Technical Reports Server (NTRS)
Arbet, J. D.; Benbow, R. L.; Hawk, M. L.; Mangiaracina, A. A.; Mcgavern, J. L.; Spangler, M. C.
1975-01-01
The study developed requirements, designed, developed, checked out and demonstrated the Procedures Generation Program (PGP). The PGP is a digital computer program which provides a computerized means of developing flight crew procedures based on crew action in the shuttle procedures simulator. In addition, it provides a real time display of procedures, difference procedures, performance data and performance evaluation data. Reconstruction of displays is possible post-run. Data may be copied, stored on magnetic tape and transferred to the document processor for editing and documentation distribution.
Template protocol for clinical trials investigating vaccines--focus on safety elements.
Bonhoeffer, Jan; Imoukhuede, Egeruan B; Aldrovandi, Grace; Bachtiar, Novilia S; Chan, Eng-Soon; Chang, Soju; Chen, Robert T; Fernandopulle, Rohini; Goldenthal, Karen L; Heffelfinger, James D; Hossain, Shah; Jevaji, Indira; Khamesipour, Ali; Kochhar, Sonali; Makhene, Mamodikoe; Malkin, Elissa; Nalin, David; Prevots, Rebecca; Ramasamy, Ranjan; Sellers, Sarah; Vekemans, Johan; Walker, Kenneth B; Wilson, Pam; Wong, Virginia; Zaman, Khalequz; Heininger, Ulrich
2013-11-12
This document is intended as a guide to the protocol development for trials of prophylactic vaccines. The template may serve phases I-IV clinical trials protocol development to include safety relevant information as required by the regulatory authorities and as deemed useful by the investigators. This document may also be helpful for future site strengthening efforts. Copyright © 2013 Elsevier Ltd. All rights reserved.
Requirements for Xenon International
DOE Office of Scientific and Technical Information (OSTI.GOV)
Hayes, James C.; Ely, James H.; Haas, Derek A.
2015-12-30
This document defines the requirements for the new Xenon International radioxenon system. The output of this project will be a Pacific Northwest National Laboratory (PNNL) developed prototype and a manufacturer-developed production prototype. The two prototypes are intended to be as close to matching as possible; this will be facilitated by overlapping development cycles and open communication between PNNL and the manufacturer.
Systems engineering implementation in the preliminary design phase of the Giant Magellan Telescope
NASA Astrophysics Data System (ADS)
Maiten, J.; Johns, M.; Trancho, G.; Sawyer, D.; Mady, P.
2012-09-01
Like many telescope projects today, the 24.5-meter Giant Magellan Telescope (GMT) is truly a complex system. The primary and secondary mirrors of the GMT are segmented and actuated to support two operating modes: natural seeing and adaptive optics. GMT is a general-purpose telescope supporting multiple science instruments operated in those modes. GMT is a large, diverse collaboration and development includes geographically distributed teams. The need to implement good systems engineering processes for managing the development of systems like GMT becomes imperative. The management of the requirements flow down from the science requirements to the component level requirements is an inherently difficult task in itself. The interfaces must also be negotiated so that the interactions between subsystems and assemblies are well defined and controlled. This paper will provide an overview of the systems engineering processes and tools implemented for the GMT project during the preliminary design phase. This will include requirements management, documentation and configuration control, interface development and technical risk management. Because of the complexity of the GMT system and the distributed team, using web-accessible tools for collaboration is vital. To accomplish this GMTO has selected three tools: Cognition Cockpit, Xerox Docushare, and Solidworks Enterprise Product Data Management (EPDM). Key to this is the use of Cockpit for managing and documenting the product tree, architecture, error budget, requirements, interfaces, and risks. Additionally, drawing management is accomplished using an EPDM vault. Docushare, a documentation and configuration management tool is used to manage workflow of documents and drawings for the GMT project. These tools electronically facilitate collaboration in real time, enabling the GMT team to track, trace and report on key project metrics and design parameters.
14 CFR 158.20 - Submission of required documents.
Code of Federal Regulations, 2014 CFR
2014-01-01
... due to the security process. (b) Once the database development is completed with air carrier capability, public agencies and air carriers may use the FAA's national PFC database to post their required...
14 CFR 158.20 - Submission of required documents.
Code of Federal Regulations, 2012 CFR
2012-01-01
... due to the security process. (b) Once the database development is completed with air carrier capability, public agencies and air carriers may use the FAA's national PFC database to post their required...
14 CFR 158.20 - Submission of required documents.
Code of Federal Regulations, 2011 CFR
2011-01-01
... due to the security process. (b) Once the database development is completed with air carrier capability, public agencies and air carriers may use the FAA's national PFC database to post their required...
14 CFR 158.20 - Submission of required documents.
Code of Federal Regulations, 2013 CFR
2013-01-01
... due to the security process. (b) Once the database development is completed with air carrier capability, public agencies and air carriers may use the FAA's national PFC database to post their required...
14 CFR 158.20 - Submission of required documents.
Code of Federal Regulations, 2010 CFR
2010-01-01
... due to the security process. (b) Once the database development is completed with air carrier capability, public agencies and air carriers may use the FAA's national PFC database to post their required...
Standard practices for the implementation of computer software
NASA Technical Reports Server (NTRS)
Irvine, A. P. (Editor)
1978-01-01
A standard approach to the development of computer program is provided that covers the file cycle of software development from the planning and requirements phase through the software acceptance testing phase. All documents necessary to provide the required visibility into the software life cycle process are discussed in detail.
Assessing Leader Development: Lessons from a Historical Review of MBA Outcomes
ERIC Educational Resources Information Center
Passarelli, Angela M.; Boyatzis, Richard E.; Wei, Hongguo
2018-01-01
Graduate management education seeks to enhance the likelihood that graduates will be effective leaders, managers, or professionals. This requires programs that are designed to enable students to develop the related competencies, and increasing regulatory pressures require programs to document evidence of success. However, both the design of…
Wojcik, Lauren
2015-01-01
Transitioning to electronic health records (EHRs) provides an opportunity for health care systems to integrate educational content available on interactive patient systems (IPS) with the medical documentation system. This column discusses how one hospital simplified providers' workflow by making it easier to order educational videos and ensure that completed education is documented within the medical record. Integrating the EHR and IPS streamlined the provision of patient education, improved documentation, and supported the organization in meeting core requirements for Meaningful Use.
A Guidance Document for Kentucky's Oil and Gas Operations
DOE Office of Scientific and Technical Information (OSTI.GOV)
None, None
1998-11-10
This technical report is a summary of the progress made for "A Guidance Document for Kentucky's Oil and Gas Operators". During this quarter, the document received continued review and editing in an elec-tronic format to satisfy the United States Department of Energy (DOE). Comments received from oil and gas operators reviewing this document prompted contact to be made with the United States Environmental Protection Agency (USEPA) to develop an addendum section to provide better explanation of USEPA requirements for Class II injection wells in Kentucky.
HALE UAS Command and Control Communications: Step 1 - Functional Requirements Document. Version 4.0
NASA Technical Reports Server (NTRS)
2006-01-01
The High Altitude Long Endurance (HALE) unmanned aircraft system (UAS) communicates with an off-board pilot-in-command in all flight phases via the C2 data link, making it a critical component for the UA to fly in the NAS safely and routinely. This is a new requirement in current FAA communications planning and monitoring processes. This document provides a set of comprehensive C2 communications functional requirements and performance guidelines to help facilitate the future FAA certification process for civil UAS to operate in the NAS. The objective of the guidelines is to provide the ability to validate the functional requirements and in future be used to develop performance-level requirements.
NASA Manned Launch Vehicle Lightning Protection Development
NASA Technical Reports Server (NTRS)
McCollum, Matthew B.; Jones, Steven R.; Mack, Jonathan D.
2009-01-01
Historically, the National Aeronautics and Space Administration (NASA) relied heavily on lightning avoidance to protect launch vehicles and crew from lightning effects. As NASA transitions from the Space Shuttle to the new Constellation family of launch vehicles and spacecraft, NASA engineers are imposing design and construction standards on the spacecraft and launch vehicles to withstand both the direct and indirect effects of lightning. A review of current Space Shuttle lightning constraints and protection methodology will be presented, as well as a historical review of Space Shuttle lightning requirements and design. The Space Shuttle lightning requirements document, NSTS 07636, Lightning Protection, Test and Analysis Requirements, (originally published as document number JSC 07636, Lightning Protection Criteria Document) was developed in response to the Apollo 12 lightning event and other experiences with NASA and the Department of Defense launch vehicles. This document defined the lightning environment, vehicle protection requirements, and design guidelines for meeting the requirements. The criteria developed in JSC 07636 were a precursor to the Society of Automotive Engineers (SAE) lightning standards. These SAE standards, along with Radio Technical Commission for Aeronautics (RTCA) DO-160, Environmental Conditions and Test Procedures for Airborne Equipment, are the basis for the current Constellation lightning design requirements. The development and derivation of these requirements will be presented. As budget and schedule constraints hampered lightning protection design and verification efforts, the Space Shuttle elements waived the design requirements and relied on lightning avoidance in the form of launch commit criteria (LCC) constraints and a catenary wire system for lightning protection at the launch pads. A better understanding of the lightning environment has highlighted the vulnerability of the protection schemes and associated risk to the vehicle, which has resulted in lost launch opportunities and increased expenditures in manpower to assess Space Shuttle vehicle health and safety after lightning events at the launch pad. Because of high-percentage launch availability and long-term on-pad requirements, LCC constraints are no longer considered feasible. The Constellation vehicles must be designed to withstand direct and indirect effects of lightning. A review of the vehicle design and potential concerns will be presented as well as the new catenary lightning protection system for the launch pad. This system is required to protect the Constellation vehicles during launch processing when vehicle lightning effects protection might be compromised by such items as umbilical connections and open access hatches.
78 FR 67204 - Agency Information Collection Activities: Proposed Collection; Comment Request
Federal Register 2010, 2011, 2012, 2013, 2014
2013-11-08
... action to submit an information collection request to the Office of Management and Budget (OMB) and... Verification System (LVS) has been developed, providing an electronic method for fulfilling this requirement... publicly available documents, including the draft supporting statement, at the NRC's Public Document Room...
FDA plan for statutory compliance. Notice of availability.
1998-11-24
The Food and Drug Administration (FDA) is announcing the availability of a document entitled "FDA Plan for Statutory Compliance" (the plan). This document is the agency's response to section 406(b) of the Food and Drug Administration Modernization Act of 1997 (FDAMA), which requires the Secretary of the Department of Health and Human Services (the Secretary) to develop a plan bringing the agency into compliance with the requirements of the Federal Food, Drug, and Cosmetic Act (the act).
NASA Astrophysics Data System (ADS)
Takahashi, Masakazu; Fukue, Yoshinori
This paper proposes a Retrospective Computerized System Validation (RCSV) method for Drug Manufacturing Software (DMSW) that relates to drug production considering software modification. Because DMSW that is used for quality management and facility control affects big impact to quality of drugs, regulatory agency required proofs of adequacy for DMSW's functions and performance based on developed documents and test results. Especially, the work that explains adequacy for previously developed DMSW based on existing documents and operational records is called RCSV. When modifying RCSV conducted DMSW, it was difficult to secure consistency between developed documents and test results for modified DMSW parts and existing documents and operational records for non-modified DMSW parts. This made conducting RCSV difficult. In this paper, we proposed (a) definition of documents architecture, (b) definition of descriptive items and levels in the documents, (c) management of design information using database, (d) exhaustive testing, and (e) integrated RCSV procedure. As a result, we could conduct adequate RCSV securing consistency.
DOE Office of Scientific and Technical Information (OSTI.GOV)
BEVINS, R.R.
This document has been updated during the definitive design portion of the first phase of the W-314 Project to capture additional software requirements and is planned to be updated during the second phase of the W-314 Project to cover the second phase of the Project's scope. The objective is to provide requirement traceability by recording the analysis/basis for the functional descriptions of the master pump shutdown system. This document identifies the sources of the requirements and/or how these were derived. Each requirement is validated either by quoting the source or an analysis process involving the required functionality, performance characteristics, operationsmore » input or engineering judgment.« less
NASA Technical Reports Server (NTRS)
Wilber, George F.
2017-01-01
This Software Description Document (SDD) captures the design for developing the Flight Interval Management (FIM) system Configurable Graphics Display (CGD) software. Specifically this SDD describes aspects of the Boeing CGD software and the surrounding context and interfaces. It does not describe the Honeywell components of the CGD system. The SDD provides the system overview, architectural design, and detailed design with all the necessary information to implement the Boeing components of the CGD software and integrate them into the CGD subsystem within the larger FIM system. Overall system and CGD system-level requirements are derived from the CGD SRS (in turn derived from the Boeing System Requirements Design Document (SRDD)). Display and look-and-feel requirements are derived from Human Machine Interface (HMI) design documents and working group recommendations. This Boeing CGD SDD is required to support the upcoming Critical Design Review (CDR).
Leino, Antti
2002-01-01
In the European Union, Council Directive 96/82/EC requires operators producing, using, or handling significant amounts of dangerous substances to improve their safety management systems in order to better manage the major accident potentials deriving from human error. A new safety management system for the Viikinmäki wastewater treatment plant in Helsinki, Finland, was implemented in this study. The system was designed to comply with both the new safety liabilities and the requirements of OHSAS 18001 (British Standards Institute, 1999). During the implementation phase experiences were gathered from the development processes in this small organisation. The complete documentation was placed in the intranet of the plant. Hyperlinks between documents were created to ensure convenience of use. Documentation was made accessible for all workers from every workstation.
SE Requirements Development Tool User Guide
DOE Office of Scientific and Technical Information (OSTI.GOV)
Benson, Faith Ann
2016-05-13
The LANL Systems Engineering Requirements Development Tool (SERDT) is a data collection tool created in InfoPath for use with the Los Alamos National Laboratory’s (LANL) SharePoint sites. Projects can fail if a clear definition of the final product requirements is not performed. For projects to be successful requirements must be defined early in the project and those requirements must be tracked during execution of the project to ensure the goals of the project are met. Therefore, the focus of this tool is requirements definition. The content of this form is based on International Council on Systems Engineering (INCOSE) and Departmentmore » of Defense (DoD) process standards and allows for single or collaborative input. The “Scoping” section is where project information is entered by the project team prior to requirements development, and includes definitions and examples to assist the user in completing the forms. The data entered will be used to define the requirements and once the form is filled out, a “Requirements List” is automatically generated and a Word document is created and saved to a SharePoint document library. SharePoint also includes the ability to download the requirements data defined in the InfoPath from into an Excel spreadsheet. This User Guide will assist you in navigating through the data entry process.« less
NASA Technical Reports Server (NTRS)
Adams, A.
1973-01-01
The Interface Control Document contains engine information necessary for installation of the baseline RL10 Derivative engines in the Space Tug vehicle. The ICD presents a description of the baseline engines and their operating characteristics, mass and load characteristics, and environmental criteria. The document defines the engine/vehicle mechanical, electrical, fluid and pneumatic interface requirements.
A classification of errors in lay comprehension of medical documents.
Keselman, Alla; Smith, Catherine Arnott
2012-12-01
Emphasis on participatory medicine requires that patients and consumers participate in tasks traditionally reserved for healthcare providers. This includes reading and comprehending medical documents, often but not necessarily in the context of interacting with Personal Health Records (PHRs). Research suggests that while giving patients access to medical documents has many benefits (e.g., improved patient-provider communication), lay people often have difficulty understanding medical information. Informatics can address the problem by developing tools that support comprehension; this requires in-depth understanding of the nature and causes of errors that lay people make when comprehending clinical documents. The objective of this study was to develop a classification scheme of comprehension errors, based on lay individuals' retellings of two documents containing clinical text: a description of a clinical trial and a typical office visit note. While not comprehensive, the scheme can serve as a foundation of further development of a taxonomy of patients' comprehension errors. Eighty participants, all healthy volunteers, read and retold two medical documents. A data-driven content analysis procedure was used to extract and classify retelling errors. The resulting hierarchical classification scheme contains nine categories and 23 subcategories. The most common error made by the participants involved incorrectly recalling brand names of medications. Other common errors included misunderstanding clinical concepts, misreporting the objective of a clinical research study and physician's findings during a patient's visit, and confusing and misspelling clinical terms. A combination of informatics support and health education is likely to improve the accuracy of lay comprehension of medical documents. Published by Elsevier Inc.
Guidance and Control Software Project Data - Volume 1: Planning Documents
NASA Technical Reports Server (NTRS)
Hayhurst, Kelly J. (Editor)
2008-01-01
The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the planning documents from the GCS project. Volume 1 contains five appendices: A. Plan for Software Aspects of Certification for the Guidance and Control Software Project; B. Software Development Standards for the Guidance and Control Software Project; C. Software Verification Plan for the Guidance and Control Software Project; D. Software Configuration Management Plan for the Guidance and Control Software Project; and E. Software Quality Assurance Activities.
The JPL functional requirements tool
NASA Technical Reports Server (NTRS)
Giffin, Geoff; Skinner, Judith; Stoller, Richard
1987-01-01
Planetary spacecraft are complex vehicles which are built according to many thousands of requirements. Problems encountered in documenting and maintaining these requirements led to the current attempt to reduce or eliminate these problems by a computer automated data base Functional Requirements Tool. The tool developed at JPL and in use on several JPL Projects is described. The organization and functionality of the Tool, together with an explanation of the data base inputs, their relationships, and use are presented. Methods of interfacing with external documents, representation of tables and figures, and methods of approval and change processing are discussed. The options available for disseminating information from the Tool are identified. The implementation of the Requirements Tool is outlined, and the operation is summarized. The conclusions drawn from this work is that the Requirements Tool represents a useful addition to the System Engineer's Tool kit, it is not currently available elsewhere, and a clear development path exists to expand the capabilities of the Tool to serve larger and more complex projects.
24 CFR 1710.209 - Title and land use.
Code of Federal Regulations, 2010 CFR
2010-04-01
... all public records which may contain documents affecting title to the land or the developer's ability... cases, the required statement shall clearly reflect the documents and periods searched. (e) Items to be... include specific references to the instruments in the public records upon which they are based). When an...
Communication Skills for Workplace Assessors.
ERIC Educational Resources Information Center
Corbett, Deborah
This document is designed to help develop the communication skills of individuals training for the position of workplace assessor in Australia's National Training Framework and practicing workplace assessors who require additional assistance with on-the-job communication skills. The document consists of 11 units of study that each contain some or…
Minimal Competency Exam Program.
ERIC Educational Resources Information Center
Griffith, E. H.
The high school minimal competency examination described in this document is part one of a three-part program that requires that all students satisfactorily complete tests in reading, language arts, and mathematics prior to receiving a high school diploma. The document outlines the test development and assessment program and describes the plan for…
DOT National Transportation Integrated Search
2014-01-01
This document provides the high-level system architecture for the Prototype Development and Demonstration of a R.E.S.C.U.M.E. system. The requirements addressed in this document are based upon those that can be found in previous R.E.S.C.U.M.E. report...
Interface Management for a NASA Flight Project Using Model-Based Systems Engineering (MBSE)
NASA Technical Reports Server (NTRS)
Vipavetz, Kevin; Shull, Thomas A.; Infeld, Samatha; Price, Jim
2016-01-01
The goal of interface management is to identify, define, control, and verify interfaces; ensure compatibility; provide an efficient system development; be on time and within budget; while meeting stakeholder requirements. This paper will present a successful seven-step approach to interface management used in several NASA flight projects. The seven-step approach using Model Based Systems Engineering will be illustrated by interface examples from the Materials International Space Station Experiment-X (MISSE-X) project. The MISSE-X was being developed as an International Space Station (ISS) external platform for space environmental studies, designed to advance the technology readiness of materials and devices critical for future space exploration. Emphasis will be given to best practices covering key areas such as interface definition, writing good interface requirements, utilizing interface working groups, developing and controlling interface documents, handling interface agreements, the use of shadow documents, the importance of interface requirement ownership, interface verification, and product transition.
This document may be of assistance in applying the New Source Review (NSR) air permitting regulations including the Prevention of Significant Deterioration (PSD) requirements. This document is part of the NSR Policy and Guidance Database. Some documents in the database are a scanned or retyped version of a paper photocopy of the original. Although we have taken considerable effort to quality assure the documents, some may contain typographical errors. Contact the office that issued the document if you need a copy of the original.
Information system life-cycle and documentation standards, volume 1
NASA Technical Reports Server (NTRS)
Callender, E. David; Steinbacher, Jody
1989-01-01
The Software Management and Assurance Program (SMAP) Information System Life-Cycle and Documentation Standards Document describes the Version 4 standard information system life-cycle in terms of processes, products, and reviews. The description of the products includes detailed documentation standards. The standards in this document set can be applied to the life-cycle, i.e., to each phase in the system's development, and to the documentation of all NASA information systems. This provides consistency across the agency as well as visibility into the completeness of the information recorded. An information system is software-intensive, but consists of any combination of software, hardware, and operational procedures required to process, store, or transmit data. This document defines a standard life-cycle model and content for associated documentation.
Function algorithms for MPP scientific subroutines, volume 1
NASA Technical Reports Server (NTRS)
Gouch, J. G.
1984-01-01
Design documentation and user documentation for function algorithms for the Massively Parallel Processor (MPP) are presented. The contract specifies development of MPP assembler instructions to perform the following functions: natural logarithm; exponential (e to the x power); square root; sine; cosine; and arctangent. To fulfill the requirements of the contract, parallel array and solar implementations for these functions were developed on the PDP11/34 Program Development and Management Unit (PDMU) that is resident at the MPP testbed installation located at the NASA Goddard facility.
DOT National Transportation Integrated Search
2015-08-01
This document is the first of a seven volume report that describes performance requirements for connected vehicle vehicle-to-infrastructure (V2I) Safety Applications developed for the U.S. Department of Transportation (U.S. DOT). The applications add...
Requirements report for SSTO vertical take-off/horizontal landing vehicle
NASA Technical Reports Server (NTRS)
Greenberg, H. S.
1994-01-01
This document describes the detailed design requirements and design criteria to support Structures/TPS Technology development for SSTO winged vehicle configurations that use vertical take-off and horizontal landing and deliver 25,000 lb payloads to a 220 nm circular orbit at an inclination of 51.6 degrees or 40,000 lb payloads to a 150 nm circular orbit at a 28.5 degree of inclination. This document will be updated on a timely basis as informatIon becomes available throughout the project.
Requirements report for SSTO vertical take-off/horizontal landing vehicle
NASA Astrophysics Data System (ADS)
Greenberg, H. S.
1994-07-01
This document describes the detailed design requirements and design criteria to support Structures/TPS Technology development for SSTO winged vehicle configurations that use vertical take-off and horizontal landing and deliver 25,000 lb payloads to a 220 nm circular orbit at an inclination of 51.6 degrees or 40,000 lb payloads to a 150 nm circular orbit at a 28.5 degree of inclination. This document will be updated on a timely basis as informatIon becomes available throughout the project.
Designing Flightdeck Procedures
NASA Technical Reports Server (NTRS)
Barshi, Immanuel; Mauro, Robert; Degani, Asaf; Loukopoulou, Loukia
2016-01-01
The primary goal of this document is to provide guidance on how to design, implement, and evaluate flight deck procedures. It provides a process for developing procedures that meet clear and specific requirements. This document provides a brief overview of: 1) the requirements for procedures, 2) a process for the design of procedures, and 3) a process for the design of checklists. The brief overview is followed by amplified procedures that follow the above steps and provide details for the proper design, implementation and evaluation of good flight deck procedures and checklists.
Space Launch System (SLS) Mission Planner's Guide
NASA Technical Reports Server (NTRS)
Smith, David Alan
2017-01-01
The purpose of this Space Launch System (SLS) Mission Planner's Guide (MPG) is to provide future payload developers/users with sufficient insight to support preliminary SLS mission planning. Consequently, this SLS MPG is not intended to be a payload requirements document; rather, it organizes and details SLS interfaces/accommodations in a manner similar to that of current Expendable Launch Vehicle (ELV) user guides to support early feasibility assessment. Like ELV Programs, once approved to fly on SLS, specific payload requirements will be defined in unique documentation.
NASA Technical Reports Server (NTRS)
Wiley, Lowell F.
1985-01-01
The purpose of this requirements document is to develop the foundation for concept development for the Life Sciences Research Facility (LSRF) on the Space Station. These requirements are developed from the perspective of a Space Station laboratory module outfitter. Science and mission requirements including those related to specimens are set forth. System requirements, including those for support, are detailed. Functional and design requirements are covered in the areas of structures, mechanisms, electrical power, thermal systems, data management system, life support, and habitability. Finally, interface requirements for the Command Module and Logistics Module are described.
NASA Technical Reports Server (NTRS)
Plante, Jeannete
2010-01-01
GEIA-STD-0005-1 defines the objectives of, and requirements for, documenting processes that assure customers and regulatory agencies that AHP electronic systems containing lead-free solder, piece parts, and boards will satisfy the applicable requirements for performance, reliability, airworthiness, safety, and certify-ability throughout the specified life of performance. It communicates requirements for a Lead-Free Control Plan (LFCP) to assist suppliers in the development of their own Plans. The Plan documents the Plan Owner's (supplier's) processes, that assure their customer, and all other stakeholders that the Plan owner's products will continue to meet their requirements. The presentation reviews quality assurance requirements traceability and LFCP template instructions.
Expanding the Use of Time/Frequency Difference of Arrival Geolocation in the Department of Defense
2012-01-01
next decade. Military acquisition and research , development, test , and evaluation will likely be the hardest hit by spending cuts (Eaglen and Nguyen...Unauthorized posting of RAND electronic documents to a non-RAND website is prohibited. RAND electronic documents are protected under copyright law...Permission is required from RAND to reproduce, or reuse in another form, any of our research documents for commercial use. For information on reprint
An MBSE Approach to Space Suit Development
NASA Technical Reports Server (NTRS)
Cordova, Lauren; Kovich, Christine; Sargusingh, Miriam
2012-01-01
The EVA/Space Suit Development Office (ESSD) Systems Engineering and Integration (SE&I) team has utilized MBSE in multiple programs. After developing operational and architectural models, the MBSE framework was expanded to link the requirements space to the system models through functional analysis and interfaces definitions. By documenting all the connections within the technical baseline, ESSD experienced significant efficiency improvements in analysis and identification of change impacts. One of the biggest challenges presented to the MBSE structure was a program transition and restructuring effort, which was completed successfully in 4 months culminating in the approval of a new EVA Technical Baseline. During this time three requirements sets spanning multiple DRMs were streamlined into one NASA-owned Systems Requirement Document (SRD) that successfully identified requirements relevant to the current hardware development effort while remaining extensible to support future hardware developments. A capability-based hierarchy was established to provide a more flexible framework for future space suit development that can support multiple programs with minimal rework of basic EVA/Space Suit requirements. This MBSE approach was most recently applied for generation of an EMU Demonstrator technical baseline being developed for an ISS DTO. The relatively quick turnaround of operational concepts, architecture definition, and requirements for this new suit development has allowed us to test and evolve the MBSE process and framework in an extremely different setting while still offering extensibility and traceability throughout ESSD projects. The ESSD MBSE framework continues to be evolved in order to support integration of all products associated with the SE&I engine.
NASA Technical Reports Server (NTRS)
Banda, Carolyn; Bushnell, David; Chen, Scott; Chiu, Alex; Neukom, Christian; Nishimura, Sayuri; Prevost, Michael; Shankar, Renuka; Staveland, Lowell; Smith, Greg
1992-01-01
This is the Software Concept Document for the Man-machine Integration Design and Analysis System (MIDAS) being developed as part of Phase V of the Army-NASA Aircrew/Aircraft Integration (A3I) Progam. The approach taken in this program since its inception in 1984 is that of incremental development with clearly defined phases. Phase 1 began in 1984 and subsequent phases have progressed at approximately 10-16 month intervals. Each phase of development consists of planning, setting requirements, preliminary design, detailed design, implementation, testing, demonstration and documentation. Phase 5 began with an off-site planning meeting in November, 1990. It is expected that Phase 5 development will be complete and ready for demonstration to invited visitors from industry, government and academia in May, 1992. This document, produced during the preliminary design period of Phase 5, is intended to record the top level design concept for MIDAS as it is currently conceived. This document has two main objectives: (1) to inform interested readers of the goals of the MIDAS Phase 5 development period, and (2) to serve as the initial version of the MIDAS design document which will be continuously updated as the design evolves. Since this document is written fairly early in the design period, many design issues still remain unresolved. Some of the unresolved issues are mentioned later in this document in the sections on specific components. Readers are cautioned that this is not a final design document and that, as the design of MIDAS matures, some of the design ideas recorded in this document will change. The final design will be documented in a detailed design document published after the demonstrations.
Fikes, James D; Patrick, Daniel J; Francke, Sabine; Frazier, Kendall S; Reindel, James F; Romeike, Annette; Spaet, Robert H; Tomlinson, Lindsay; Schafer, Kenneth A
2015-10-01
In 2014, the Organisation for Economic Co-operation and Development (OECD) issued guidance no. 16, Guidance on the GLP Requirements for Peer Review of Histopathology. The stated purpose of the guidance document is "to provide guidance to pathologists, test facility management, study directors and quality assurance personnel on how the peer review of histopathology should be planned, managed, documented, and reported in order to meet Good Laboratory Practice (GLP) expectations and requirements." On behalf of and in collaboration with the global societies of toxicologic pathology, the Society of Toxicologic Pathology initiated a review of OECD guidance no. 16. The objectives of this review are to provide a unified interpretation of the guidance, to recommend compliant processes for organizations to implement, and to avoid inconsistent process adaptations across the industry. This review of the guidance document is the product of a global collaboration with other societies of toxicologic pathology and provides a section-by-section international consensus view and interpretation of the OECD guidance on peer review. © 2015 by The Author(s).
NASA Technical Reports Server (NTRS)
Denney, Ewen W.; Fischer, Bernd
2009-01-01
Model-based development and automated code generation are increasingly used for production code in safety-critical applications, but since code generators are typically not qualified, the generated code must still be fully tested, reviewed, and certified. This is particularly arduous for mathematical and control engineering software which requires reviewers to trace subtle details of textbook formulas and algorithms to the code, and to match requirements (e.g., physical units or coordinate frames) not represented explicitly in models or code. Both tasks are complicated by the often opaque nature of auto-generated code. We address these problems by developing a verification-driven approach to traceability and documentation. We apply the AUTOCERT verification system to identify and then verify mathematical concepts in the code, based on a mathematical domain theory, and then use these verified traceability links between concepts, code, and verification conditions to construct a natural language report that provides a high-level structured argument explaining why and how the code uses the assumptions and complies with the requirements. We have applied our approach to generate review documents for several sub-systems of NASA s Project Constellation.
System description and requirements document.
DOT National Transportation Integrated Search
2007-10-10
The Next Generation 911 Initiative (NG911) : is a U.S. Department of Transportation (USDOT) : research and development project that will help : define the system architecture and develop a : transition plan that considers responsibilities...
20 CFR 655.167 - Document retention requirements.
Code of Federal Regulations, 2010 CFR
2010-04-01
... 20 Employees' Benefits 3 2010-04-01 2010-04-01 false Document retention requirements. 655.167... retention requirements. (a) Entities required to retain documents. All employers filing an Application for... retain the documents and records proving compliance with this subpart. (b) Period of required retention...
Detailed requirements for a next generation nuclear data structure.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Brown, D.
2016-07-05
This document attempts to compile the requirements for the top-levels of a hierarchical arrangement of nuclear data such as found in the ENDF format. This set of requirements will be used to guide the development of a new data structure to replace the legacy ENDF format.
Pupil Progression Plan: Requirements and Procedures 1982-83.
ERIC Educational Resources Information Center
Duval County School Board, Jacksonville, FL.
The Pupil Progression Plan detailed in this document was developed in response to Florida's Educational Accountability Act, which requires each school district to establish a comprehensive program for pupil progression, and to fulfill the requirements of school board policy. The first section details general procedures for promotion, grades K-12.…
DOT National Transportation Integrated Search
1978-09-01
The requirements for a navigation guidance system which will effect an increase in the ship processing capacity of the Saint Lawrence Seaway (Lake Ontario to Montreal, Quebec) are developed. The requirements include a specification of system position...
Exploring Operational Test and Evaluation of Unmanned Aircraft Systems: A Qualitative Case Study
NASA Astrophysics Data System (ADS)
Saliceti, Jose A.
The purpose of this qualitative case study was to explore and identify strategies that may potentially remedy operational test and evaluation procedures used to evaluate Unmanned Aircraft Systems (UAS) technology. The sample for analysis consisted of organizations testing and evaluating UASs (e.g., U.S. Air Force, U.S. Navy, U.S. Army, U.S. Marine Corps, U.S. Coast Guard, and Customs Border Protection). A purposeful sampling technique was used to select 15 subject matter experts in the field of operational test and evaluation of UASs. A questionnaire was provided to participants to construct a descriptive and robust research. Analysis of responses revealed themes related to each research question. Findings revealed operational testers utilized requirements documents to extrapolate measures for testing UAS technology and develop critical operational issues. The requirements documents were (a) developed without the contribution of stakeholders and operational testers, (b) developed with vague or unrealistic measures, and (c) developed without a systematic method to derive requirements from mission tasks. Four approaches are recommended to develop testable operational requirements and assist operational testers: (a) use a mission task analysis tool to derive requirements for mission essential tasks for the system, (b) exercise collaboration among stakeholders and testers to ensure testable operational requirements based on mission tasks, (c) ensure testable measures are used in requirements documents, and (d) create a repository list of critical operational issues by mission areas. The preparation of operational test and evaluation processes for UAS technology is not uniform across testers. The processes in place are not standardized, thus test plan preparation and reporting are different among participants. A standard method to prepare and report UAS technology should be used when preparing and reporting on UAS technology. Using a systematic process, such as mission-based test design, resonated among participants as an analytical method to link UAS mission tasks and measures of performance to the capabilities of the system under test when developing operational test plans. Further research should examine system engineering designs for system requirements traceability matrix of mission tasks and subtasks while using an analysis tool that adequately evaluates UASs with an acceptable level of confidence in the results.
2016-09-01
be conducted midstream, at the end of an activity program or LOE, or ex post facto . Not all security cooperation endeavors require evaluation...noncommercial use only. Unauthorized posting of this publication online is prohibited. Permission is given to duplicate this document for personal use only...iv Developing an AME Framework for DoD Security Cooperation approach, the study team analyzed documents, interviewed subject- matter experts
The CMMI Product Suite and International Standards
2006-07-01
standards: “2.3 Reference Documents 2.3.1 Applicable ISO /IEC documents, including ISO /IEC 12207 and ISO /IEC 15504.” “3.1 Development User Requirements...related international standards such as ISO 9001:2000, 12207 , 15288 © 2006 by Carnegie Mellon University Page 12 Key Supplements Needed...the Measurement Framework in ISO /IEC 15504; and • the Process Reference Model included in ISO /IEC 12207 . A possible approach has been developed for
Civilian Radioactive Waste Management System Requirements Document
DOE Office of Scientific and Technical Information (OSTI.GOV)
C.A. Kouts
2006-05-10
The CRD addresses the requirements of Department of Energy (DOE) Order 413.3-Change 1, ''Program and Project Management for the Acquisition of Capital Assets'', by providing the Secretarial Acquisition Executive (Level 0) scope baseline and the Program-level (Level 1) technical baseline. The Secretarial Acquisition Executive approves the Office of Civilian Radioactive Waste Management's (OCRWM) critical decisions and changes against the Level 0 baseline; and in turn, the OCRWM Director approves all changes against the Level 1 baseline. This baseline establishes the top-level technical scope of the CRMWS and its three system elements, as described in section 1.3.2. The organizations responsible formore » design, development, and operation of system elements described in this document must therefore prepare subordinate project-level documents that are consistent with the CRD. Changes to requirements will be managed in accordance with established change and configuration control procedures. The CRD establishes requirements for the design, development, and operation of the CRWMS. It specifically addresses the top-level governing laws and regulations (e.g., ''Nuclear Waste Policy Act'' (NWPA), 10 Code of Federal Regulations (CFR) Part 63, 10 CFR Part 71, etc.) along with specific policy, performance requirements, interface requirements, and system architecture. The CRD shall be used as a vehicle to incorporate specific changes in technical scope or performance requirements that may have significant program implications. Such may include changes to the program mission, changes to operational capability, and high visibility stakeholder issues. The CRD uses a systems approach to: (1) identify key functions that the CRWMS must perform, (2) allocate top-level requirements derived from statutory, regulatory, and programmatic sources, and (3) define the basic elements of the system architecture and operational concept. Project-level documents address CRD requirements by further defining system element functions, decomposing requirements into significantly greater detail, and developing designs of system components, facilities, and equipment. The CRD addresses the identification and control of functional, physical, and operational boundaries between and within CRWMS elements. The CRD establishes requirements regarding key interfaces between the CRWMS and elements external to the CRWMS. Project elements define interfaces between CRWMS program elements. The Program has developed a change management process consistent with DOE Order 413.3-Change 1. Changes to the Secretarial Acquisition Executive and Program-level baselines must be approved by a Program Baseline Change Control Board. Specific thresholds have been established for identifying technical, cost, and schedule changes that require approval. The CRWMS continually evaluates system design and operational concepts to optimize performance and/or cost. The Program has developed systems analysis tools to assess potential enhancements to the physical system and to determine the impacts from cost saving initiatives, scientific and technological improvements, and engineering developments. The results of systems analyses, if appropriate, are factored into revisions to the CRD as revised Programmatic Requirements.« less
Directory of Energy Information Administration model abstracts 1988
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1988-01-01
This directory contains descriptions about each basic and auxiliary model, including the title, acronym, purpose, and type, followed by more detailed information on characteristics, uses, and requirements. For developing models, limited information is provided. Sources for additional information are identified. Included in this directory are 44 EIA models active as of February 1, 1988; 16 of which operate on personal computers. Models that run on personal computers are identified by ''PC'' as part of the acronyms. The main body of this directory is an alphabetical listing of all basic and auxiliary EIA models. Appendix A identifies major EIA modeling systemsmore » and the models within these systems, and Appendix B identifies EIA models by type (basic or auxiliary). Appendix C lists developing models and contact persons for those models. A basic model is one designated by the EIA Administrator as being sufficiently important to require sustained support and public scrutiny. An auxiliary model is one designated by the EIA Administrator as being used only occasionally in analyses, and therefore requires minimal levels of documentation. A developing model is one designated by the EIA Administrator as being under development and yet of sufficient interest to require a basic level of documentation at a future date. EIA also leases models developed by proprietary software vendors. Documentation for these ''proprietary'' models is the responsibility of the companies from which they are leased. EIA has recently leased models from Chase Econometrics, Inc., Data Resources, Inc. (DRI), the Oak Ridge National Laboratory (ORNL), and Wharton Econometric Forecasting Associates (WEFA). Leased models are not abstracted here.« less
The Wildland Fire Decision Support System: Integrating science, technology, and fire management
Morgan Pence; Tom Zimmerman
2011-01-01
Federal agency policy requires documentation and analysis of all wildland fire response decisions. In the past, planning and decision documentation for fires were completed using multiple unconnected processes, yielding many limitations. In response, interagency fire management executives chartered the development of the Wildland Fire Decision Support System (WFDSS)....
Challenges in reusing transactional data for daily documentation in neonatal intensive care.
Kim, G R; Lawson, E E; Lehmann, C U
2008-11-06
The reuse of transactional data for clinical documentation requires navigation of computational, institutional and adaptive barriers. We describe organizational and technical issues in developing and deploying a daily progress note tool in a tertiary neonatal intensive care unit that reuses and aggregates data from a commercial integrated clinical information system.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
The Office of Civilian Radioactive Waste Management Systems Engineering Management Plan (OCRWM SEMP) specifies the technical management approach for the development of the waste management system, and specifies the approach for the development of each of the system elements -- the waste acceptance system, the transportation system, the Monitored Retrievable Storage (MRS) facility, and the mined geologic disposal system, which includes site characterization activity. The SEMP also delineates how systems engineering will be used by OCRWM to describe the system development process; it identifies responsibilities for its implementation, and specifies the minimum requirements for systems engineering. It also identifies themore » close interrelationship of system engineering and licensing processes. This SEMP, which is a combined OCRWM and M&O SEMP, is part of the top-level program documentation and is prepared in accordance with the direction provided in the Program Management System Manual (PMSM). The relationship of this document to other top level documents in the CRWMS document hierarchy is defined in the PMSM. A systems engineering management plan for each project, which specifies the actions to be taken in implementing systems engineering at the project level, shall be prepared by the respective project managers. [``Program`` refers to the CRWMS-wide activity and ``project`` refers to that level responsible for accomplishing the specific activities of that segment of the program.] The requirements for the project level SEMPs are addressed in Section 4.2.2.2. They represent the minimum set of requirements, and do not preclude the broadening of systems engineering activities to meet the specific needs of each project.« less
Center-TRACON Automation System (CTAS) En Route Trajectory Predictor Requirements and Capabilities
NASA Technical Reports Server (NTRS)
Vivona, Robert; Cate, Karen Tung
2013-01-01
This requirements framework document is designed to support the capture of requirements and capabilities for state-of-the-art trajectory predictors (TPs). This framework has been developed to assist TP experts in capturing a clear, consistent, and cross-comparable set of requirements and capabilities. The goal is to capture capabilities (types of trajectories that can be built), functional requirements (including inputs and outputs), non-functional requirements (including prediction accuracy and computational performance), approaches for constraint relaxation, and input uncertainties. The sections of this framework are based on the Common Trajectory Predictor structure developed by the FAA/Eurocontrol Cooperative R&D Action Plan 16 Committee on Common Trajectory Prediction. It is assumed that the reader is familiar with the Common TP Structure.1 This initial draft is intended as a first cut capture of the En Route TS Capabilities and Requirements. As such, it contains many annotations indicating possible logic errors in the CTAS code or in the description provided. It is intended to work out the details of the annotations with NASA and to update this document at a later time.
FLAMMABLE GAS TECHNICAL BASIS DOCUMENT
DOE Office of Scientific and Technical Information (OSTI.GOV)
KRIPPS, L.J.
2005-02-18
This document describes the qualitative evaluation of frequency and consequences for double shell tank (DST) and single shell tank (SST) representative flammable gas accidents and associated hazardous conditions without controls. The evaluation indicated that safety-significant SSCs and/or TSRS were required to prevent or mitigate flammable gas accidents. Discussion on the resulting control decisions is included. This technical basis document was developed to support of the Tank Farms Documented Safety Analysis (DSA) and describes the risk binning process for the flammable gas representative accidents and associated represented hazardous conditions. The purpose of the risk binning process is to determine the needmore » for safety-significant structures, systems, and components (SSC) and technical safety requirement (TSR)-level controls for a given representative accident or represented hazardous condition based on an evaluation of the event frequency and consequence.« less
Reference Model for an Open Archival Information System
NASA Technical Reports Server (NTRS)
1997-01-01
This document is a technical report for use in developing a consensus on what is required to operate a permanent, or indefinite long-term, archive of digital information. It may be useful as a starting point for a similar document addressing the indefinite long-term preservation of non-digital information. This report establishes a common framework of terms and concepts which comprise an Open Archival Information System (OAIS). It allows existing and future archives to be more meaningfully compared and contrasted. It provides a basis for further standardization of within an archival context and it should promote greater vendor awareness of, and support of , archival requirements. Through the process of normal evolution, it is expected that expansion, deletion, or modification to this document may occur. This report is therefore subject to CCSDS document management and change control procedures.
Solid waste information and tracking system client-server conversion project management plan
DOE Office of Scientific and Technical Information (OSTI.GOV)
May, D.L.
1998-04-15
This Project Management Plan is the lead planning document governing the proposed conversion of the Solid Waste Information and Tracking System (SWITS) to a client-server architecture. This plan presents the content specified by American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE) standards for software development, with additional information categories deemed to be necessary to describe the conversion fully. This plan is a living document that will be reviewed on a periodic basis and revised when necessary to reflect changes in baseline design concepts and schedules. This PMP describes the background, planning and management of the SWITS conversion.more » It does not constitute a statement of product requirements. Requirements and specification documentation needed for the SWITS conversion will be released as supporting documents.« less
Deep Borehole Field Test Requirements and Controlled Assumptions.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Hardin, Ernest
2015-07-01
This document presents design requirements and controlled assumptions intended for use in the engineering development and testing of: 1) prototype packages for radioactive waste disposal in deep boreholes; 2) a waste package surface handling system; and 3) a subsurface system for emplacing and retrieving packages in deep boreholes. Engineering development and testing is being performed as part of the Deep Borehole Field Test (DBFT; SNL 2014a). This document presents parallel sets of requirements for a waste disposal system and for the DBFT, showing the close relationship. In addition to design, it will also inform planning for drilling, construction, and scientificmore » characterization activities for the DBFT. The information presented here follows typical preparations for engineering design. It includes functional and operating requirements for handling and emplacement/retrieval equipment, waste package design and emplacement requirements, borehole construction requirements, sealing requirements, and performance criteria. Assumptions are included where they could impact engineering design. Design solutions are avoided in the requirements discussion. Deep Borehole Field Test Requirements and Controlled Assumptions July 21, 2015 iv ACKNOWLEDGEMENTS This set of requirements and assumptions has benefited greatly from reviews by Gordon Appel, Geoff Freeze, Kris Kuhlman, Bob MacKinnon, Steve Pye, David Sassani, Dave Sevougian, and Jiann Su.« less
Software Safety Risk in Legacy Safety-Critical Computer Systems
NASA Technical Reports Server (NTRS)
Hill, Janice; Baggs, Rhoda
2007-01-01
Safety-critical computer systems must be engineered to meet system and software safety requirements. For legacy safety-critical computer systems, software safety requirements may not have been formally specified during development. When process-oriented software safety requirements are levied on a legacy system after the fact, where software development artifacts don't exist or are incomplete, the question becomes 'how can this be done?' The risks associated with only meeting certain software safety requirements in a legacy safety-critical computer system must be addressed should such systems be selected as candidates for reuse. This paper proposes a method for ascertaining formally, a software safety risk assessment, that provides measurements for software safety for legacy systems which may or may not have a suite of software engineering documentation that is now normally required. It relies upon the NASA Software Safety Standard, risk assessment methods based upon the Taxonomy-Based Questionnaire, and the application of reverse engineering CASE tools to produce original design documents for legacy systems.
ISO 9000 and/or Systems Engineering Capability Maturity Model?
NASA Technical Reports Server (NTRS)
Gholston, Sampson E.
2002-01-01
For businesses and organizations to remain competitive today they must have processes and systems in place that will allow them to first identify customer needs and then develop products/processes that will meet or exceed the customers needs and expectations. Customer needs, once identified, are normally stated as requirements. Designers can then develop products/processes that will meet these requirements. Several functions, such as quality management and systems engineering management are used to assist product development teams in the development process. Both functions exist in all organizations and both have a similar objective, which is to ensure that developed processes will meet customer requirements. Are efforts in these organizations being duplicated? Are both functions needed by organizations? What are the similarities and differences between the functions listed above? ISO 9000 is an international standard of goods and services. It sets broad requirements for the assurance of quality and for management's involvement. It requires organizations to document the processes and to follow these documented processes. ISO 9000 gives customers assurance that the suppliers have control of the process for product development. Systems engineering can broadly be defined as a discipline that seeks to ensure that all requirements for a system are satisfied throughout the life of the system by preserving their interrelationship. The key activities of systems engineering include requirements analysis, functional analysis/allocation, design synthesis and verification, and system analysis and control. The systems engineering process, when followed properly, will lead to higher quality products, lower cost products, and shorter development cycles. The System Engineering Capability Maturity Model (SE-CMM) will allow companies to measure their system engineering capability and continuously improve those capabilities. ISO 9000 and SE-CMM seem to have a similar objective, which is to document the organization's processes and certify to potential customers the capability of a supplier to control the processes that determine the quality of the product or services being produced. The remaining sections of this report examine the differences and similarities between ISO 9000 and SE-CMM and make recommendations for implementation.
MODIS information, data and control system (MIDACS) level 2 functional requirements
NASA Technical Reports Server (NTRS)
Han, D.; Salomonson, V.; Ormsby, J.; Sharts, B.; Folta, D.; Ardanuy, P.; Mckay, A.; Hoyt, D.; Jaffin, S.; Vallette, B.
1988-01-01
The MODIS Information, Data and Control System (MIDACS) Level 2 Functional Requirements Document establishes the functional requirements for MIDACS and provides a basis for the mutual understanding between the users and the designers of the EosDIS, including the requirements, operating environment, external interfaces, and development plan. In defining the requirements and scope of the system, this document describes how MIDACS will operate as an element of the EOS within the EosDIS environment. This version of the Level 2 Requirements Document follows an earlier release of a preliminary draft version. The sections on functional and performance requirements do not yet fully represent the requirements of the data system needed to achieve the scientific objectives of the MODIS instruments and science teams. Indeed, the team members have not yet been selected and the team has not yet been formed; however, it has been possible to identify many relevant requirements based on the present concept of EosDIS and through interviews and meetings with key members of the scientific community. These requirements have been grouped by functional component of the data system, and by function within each component. These requirements have been merged with the complete set of Level 1 and Level 2 context diagrams, data flow diagrams, and data dictionary.
NASA Astrophysics Data System (ADS)
Wessels, H.; Stephan, H. J.
1991-08-01
When establishing the Columbus Product Assurance (PA)/safety requirements, the international environment of the Space Station Freedom program has to be taken into account. Considerations given to multiple ways of requirement definition and stages within the European Space Agency (ESA) Procedures, Specifications, and Standards (PSS-01) series of documents and the NASA Space Station requirements are discussed. A series of adaptations introduced by way of tailoring the basic ESA and NASA requirement sets to the Columbus program's needs are described. For the implementation of these tailored requirements, a scheme is developed, which recognizes the PA/safety approach within the European industries by way of various company handbooks and manuals. The changes introduced in the PSS-01 series and the applicable NASA Space Station requirements in recent years, has coincided with the establishment of Columbus PA/safety requirements. To achieve the necessary level of cooperation between ESA and the Columbus industries, a PA Working Group (PAWG) is established. The PAWG supervises the establishement of the Common PA/Safety Plan and the Standards to be used. Due to the high number of European industries participating in the Columbus program, a positive influence on the evolution of the industrial approaches in PA/safety can be expected. Cooperation in the PAWG has brought issues to light which are related to the ESA PSS-01 series and its requirements. Due to the rapid changes of recent years, basic company documentation has not followed the development, specifically as various recent ESA projects use different project specifc issues of the evolving PSS-01 documents.
Modern Corneal Eye-Banking Using a Software-Based IT Management Solution.
Kern, C; Kortuem, K; Wertheimer, C; Nilmayer, O; Dirisamer, M; Priglinger, S; Mayer, W J
2018-01-01
Increasing government legislation and regulations in manufacturing have led to additional documentation regarding the pharmaceutical product requirements of corneal grafts in the European Union. The aim of this project was to develop a software within a hospital information system (HIS) to support the documentation process, to improve the management of the patient waiting list and to increase informational flow between the clinic and eye bank. After an analysis of the current documentation process, a new workflow and software were implemented in our electronic health record (EHR) system. The software takes over most of the documentation and reduces the time required for record keeping. It guarantees real-time tracing of all steps during human corneal tissue processing from the start of production until allocation during surgery and includes follow-up within the HIS. Moreover, listing of the patient for surgery as well as waiting list management takes place in the same system. The new software for corneal eye banking supports the whole process chain by taking over both most of the required documentation and the management of the transplant waiting list. It may provide a standardized IT-based solution for German eye banks working within the same HIS.
Wang, Ning; Björvell, Catrin; Hailey, David; Yu, Ping
2014-12-01
To develop an Australian nursing documentation in aged care (Quality of Australian Nursing Documentation in Aged Care (QANDAC)) instrument to measure the quality of paper-based and electronic resident records. The instrument was based on the nursing process model and on three attributes of documentation quality identified in a systematic review. The development process involved five phases following approaches to designing criterion-referenced measures. The face and content validities and the inter-rater reliability of the instrument were estimated using a focus group approach and consensus model. The instrument contains 34 questions in three sections: completion of nursing history and assessment, description of care process and meeting the requirements of data entry. Estimates of the validity and inter-rater reliability of the instrument gave satisfactory results. The QANDAC instrument may be a useful audit tool for quality improvement and research in aged care documentation. © 2013 ACOTA.
Schnabel, M; Mann, D; Efe, T; Schrappe, M; V Garrel, T; Gotzen, L; Schaeg, M
2004-10-01
The introduction of the German Diagnostic Related Groups (D-DRG) system requires redesigning administrative patient management strategies. Wrong coding leads to inaccurate grouping and endangers the reimbursement of treatment costs. This situation emphasizes the roles of documentation and coding as factors of economical success. The aims of this study were to assess the quantity and quality of initial documentation and coding (ICD-10 and OPS-301) and find operative strategies to improve efficiency and strategic means to ensure optimal documentation and coding quality. In a prospective study, documentation and coding quality were evaluated in a standardized way by weekly assessment. Clinical data from 1385 inpatients were processed for initial correctness and quality of documentation and coding. Principal diagnoses were found to be accurate in 82.7% of cases, inexact in 7.1%, and wrong in 10.1%. Effects on financial returns occurred in 16%. Based on these findings, an optimized, interdisciplinary, and multiprofessional workflow on medical documentation, coding, and data control was developed. Workflow incorporating regular assessment of documentation and coding quality is required by the DRG system to ensure efficient accounting of hospital services. Interdisciplinary and multiprofessional cooperation is recognized to be an important factor in establishing an efficient workflow in medical documentation and coding.
Using NASA's Reference Architecture: Comparing Polar and Geostationary Data Processing Systems
NASA Technical Reports Server (NTRS)
Ullman, Richard; Burnett, Michael
2013-01-01
The JPSS and GOES-R programs are housed at NASA GSFC and jointly implemented by NASA and NOAA to NOAA requirements. NASA's role in the JPSS Ground System is to develop and deploy the system according to NOAA requirements. NASA's role in the GOES-R ground segment is to provide Systems Engineering expertise and oversight for NOAA's development and deployment of the system. NASA's Earth Science Data Systems Reference Architecture is a document developed by NASA's Earth Science Data Systems Standards Process Group that describes a NASA Earth Observing Mission Ground system as a generic abstraction. The authors work within the respective ground segment projects and are also separately contributors to the Reference Architecture document. Opinions expressed are the author's only and are not NOAA, NASA or the Ground Projects' official positions.
DOT National Transportation Integrated Search
2008-03-31
This Requirements Specification Document (RSD) was developed under the project titled TransGuide Integrated Corridor Management Stage 1 as part of the United States Department of Transportation (USDOT) Integrated Corridor Management (ICM) p...
Federal Register 2010, 2011, 2012, 2013, 2014
2011-05-09
... Activities: Documentation Requirements for Articles Entered Under Various Special Tariff Treatment Provisions...: Documentation Requirements for Articles Entered Under Various Special Tariff Treatment Provisions. This request... collection: Title: Documentation Requirements for Articles Entered Under Various Special Tariff Treatment...
Federal Register 2010, 2011, 2012, 2013, 2014
2011-07-06
... Activities: Documentation Requirements for Articles Entered Under Various Special Tariff Treatment Provisions... accordance with the Paperwork Reduction Act: Documentation Requirements for Articles Entered Under Various... techniques or other forms of information. Title: Documentation Requirements for Articles Entered Under...
5 CFR 1315.9 - Required documentation.
Code of Federal Regulations, 2010 CFR
2010-01-01
... 5 Administrative Personnel 3 2010-01-01 2010-01-01 false Required documentation. 1315.9 Section 1315.9 Administrative Personnel OFFICE OF MANAGEMENT AND BUDGET OMB DIRECTIVES PROMPT PAYMENT § 1315.9 Required documentation. Agencies are required to ensure the following payment documentation is established...
Orr, Richard H.; Pings, Vern M.; Pizer, Irwin H.; Olson, Edwin E.; Spencer, Carol C.
1968-01-01
A method of measuring a library's capability for providing the documents its users need has been developed. The library is tested with a representative sample of such documents to determine how long would be required for users to obtain these documents. Test results are expressed in terms of a Capability Index, which has a maximal value of 100 only if all the sample documents are found “on shelf.” Specific tests employing samples of 300 documents have been developed that are appropriate for academic and for “reservoir” biomedical libraries. Realistic field trials have demonstrated that these two tests are practical to administer and that test results are adequately reproducible. When strict comparability is not important, a library can test itself. In assessing a reservoir library, test results are supplemented by data on its typical processing time for interlibrary loan requests. Currently these tests are being used in a national survey. The general method is applicable to other types of libraries, provided appropriate test samples are established. If their limitations are clearly understood, these “Document Delivery Tests” can be valuable tools for planning and managing library services. PMID:5665969
Data Quality Objectives for Regulatory Requirements for Dangerous Waste Sampling and Analysis
DOE Office of Scientific and Technical Information (OSTI.GOV)
MULKEY, C.H.
1999-07-02
This document describes sampling and analytical requirements needed to meet state and federal regulations for dangerous waste (DW). The River Protection Project (RPP) is assigned to the task of storage and interim treatment of hazardous waste. Any final treatment or disposal operations, as well as requirements under the land disposal restrictions (LDRs), fall in the jurisdiction of another Hanford organization and are not part of this scope. The requirements for this Data Quality Objective (DQO) Process were developed using the RPP Data Quality Objective Procedure (Banning 1996), which is based on the U.S. Environmental Protection Agency's (EPA) Guidance for themore » Data Quality Objectives Process (EPA 1994). Hereafter, this document is referred to as the DW DQO. Federal and state laws and regulations pertaining to waste contain requirements that are dependent upon the composition of the waste stream. These regulatory drivers require that pertinent information be obtained. For many requirements, documented process knowledge of a waste composition can be used instead of analytical data to characterize or designate a waste. When process knowledge alone is used to characterize a waste, it is a best management practice to validate the information with analytical measurements.« less
A hypertext system that learns from user feedback
NASA Technical Reports Server (NTRS)
Mathe, Nathalie
1994-01-01
Retrieving specific information from large amounts of documentation is not an easy task. It could be facilitated if information relevant in the current problem solving context could be automatically supplied to the user. As a first step towards this goal, we have developed an intelligent hypertext system called CID (Computer Integrated Documentation). Besides providing an hypertext interface for browsing large documents, the CID system automatically acquires and reuses the context in which previous searches were appropriate. This mechanism utilizes on-line user information requirements and relevance feedback either to reinforce current indexing in case of success or to generate new knowledge in case of failure. Thus, the user continually augments and refines the intelligence of the retrieval system. This allows the CID system to provide helpful responses, based on previous usage of the documentation, and to improve its performance over time. We successfully tested the CID system with users of the Space Station Freedom requirements documents. We are currently extending CID to other application domains (Space Shuttle operations documents, airplane maintenance manuals, and on-line training). We are also exploring the potential commercialization of this technique.
Standard Review Plan for Environmental Restoration Program Quality Management Plans. Revision 2
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1993-12-01
The Department of Energy, Richland Operations Office (RL) Manual Environmental Restoration Program Quality System Requirements (QSR) for the Hanford Site, defines all quality requirements governing Hanford Environmental Restoration (ER) Program activities. The QSR requires that ER Program participants develop Quality Management Plans (QMPs) that describe how the QSR requirements will be implemented for their assigned scopes of work. This standard review plan (SRP) describes the ER program participant responsibilities for submittal of QMPs to the RL Environmental Restoration Division for review and the RL methodology for performing the reviews of participant QMPS. The SRP serves the following functions: acts asmore » a guide in the development or revision of QMPs to assure that the content is complete and adequate; acts as a checklist to be used by the RL staff in their review of participant QMPs; acts as an index or matrix between the requirements of the QSR and implementing methodologies described in the QMPs; decreases the time and subjectivity of document reviews; and provides a formal, documented method for describing exceptions, modifications, or waivers to established ER Program quality requirements.« less
The General Mission Analysis Tool (GMAT) System Test Plan
NASA Technical Reports Server (NTRS)
Conway, Darrel J.; Hughes, Steven P.
2007-01-01
This document serves as the System Test Approach for the GMAT Project. Preparation for system testing consists of three major stages: 1) The Test Approach sets the scope of system testing, the overall strategy to be adopted, the activities to be completed, the general resources required and the methods and processes to be used to test the release. It also details the activities, dependencies and effort required to conduct the System Test. 2) Test Planning details the activities, dependencies and effort required to conduct the System Test. 3) Test Cases documents the tests to be applied, the data to be processed, the automated testing coverage and the expected results. This document covers the first two of these items, and established the framework used for the GMAT test case development. The test cases themselves exist as separate components, and are managed outside of and concurrently with this System Test Plan.
John Hof; Curtis Flather; Tony Baltic; Stephen Davies
1999-01-01
The 1999 forest and rangeland condition indicator model is a set of independent econometric production functions for environmental outputs (measured with condition indicators) at the national scale. This report documents the development of the database and the statistical estimation required by this particular production structure with emphasis on two special...
Spectrum analysis on quality requirements consideration in software design documents.
Kaiya, Haruhiko; Umemura, Masahiro; Ogata, Shinpei; Kaijiri, Kenji
2013-12-01
Software quality requirements defined in the requirements analysis stage should be implemented in the final products, such as source codes and system deployment. To guarantee this meta-requirement, quality requirements should be considered in the intermediate stages, such as the design stage or the architectural definition stage. We propose a novel method for checking whether quality requirements are considered in the design stage. In this method, a technique called "spectrum analysis for quality requirements" is applied not only to requirements specifications but also to design documents. The technique enables us to derive the spectrum of a document, and quality requirements considerations in the document are numerically represented in the spectrum. We can thus objectively identify whether the considerations of quality requirements in a requirements document are adapted to its design document. To validate the method, we applied it to commercial software systems with the help of a supporting tool, and we confirmed that the method worked well.
Development of Hybrid Product Breakdown Structure for NASA Ground Systems
NASA Technical Reports Server (NTRS)
Monaghan, Mark W.; Henry, Robert J.
2013-01-01
The Product Breakdown Structure is traditionally a method of identification of the products of a project in a tree structure. It is a tool used to assess, plan, document, and display the equipment requirements for a project. It is part of a product based planning technique, and attempts to break down all components of a project in as much detail as possible, so that nothing is overlooked. The PBS for ground systems at the Kennedy Space Center is being developed to encompass the traditional requirements including the alignment of facility, systems, and components to the organizational hierarchy. The Ground Operations Product Breakdown Structure is a hybrid in nature in that some aspects of a work breakdown structure will be incorporated and merged with the Architecture Concept of Operations, Master Subsystem List, customer interface, and assigned management responsibility. The Ground Operations Product Breakdown Structure needs to be able to identify the flexibility of support differing customers (internal and external) usage of ground support equipment within the Kennedy Space Center launch and processing complex. The development of the Product Breakdown Structure is an iterative activity Initially documenting the organization hierarchy structure and relationships. The Product Breakdown Structure identifies the linkage between the customer program requirements, allocation of system resources, development of design goals, and identification logistics products. As the Product Breakdown Structure progresses the incorporation of the results of requirement planning for the customer occurs identifying facility needs and systems. The mature Product Breakdown Structure is baselined with a hierarchical drawing, the Product Breakdown Structure database, and an associated document identifying the verification of the data through the life cycle of the program/product line. This paper will document, demonstrate, and identify key aspects of the life cycle of a Hybrid Product Breakdown Structure. The purpose is to show how a project management and system engineering approach can be utilized for providing flexible customer service in an evolving manned space flight launch processing environment.
A strategy for electronic dissemination of NASA Langley technical publications
NASA Technical Reports Server (NTRS)
Roper, Donna G.; Mccaskill, Mary K.; Holland, Scott D.; Walsh, Joanne L.; Nelson, Michael L.; Adkins, Susan L.; Ambur, Manjula Y.; Campbell, Bryan A.
1994-01-01
To demonstrate NASA Langley Research Center's relevance and to transfer technology to external customers in a timely and efficient manner, Langley has formed a working group to study and recommend a course of action for the electronic dissemination of technical reports (EDTR). The working group identified electronic report requirements (e.g., accessibility, file format, search requirements) of customers in U.S. industry through numerous site visits and personal contacts. Internal surveys were also used to determine commonalities in document preparation methods. From these surveys, a set of requirements for an electronic dissemination system was developed. Two candidate systems were identified and evaluated against the set of requirements: the Full-Text Electronic Documents System (FEDS), which is a full-text retrieval system based on the commercial document management package Interleaf, and the Langley Technical Report Server (LTRS), which is a Langley-developed system based on the publicly available World Wide Web (WWW) software system. Factors that led to the selection of LTRS as the vehicle for electronic dissemination included searching and viewing capability, current system operability, and client software availability for multiple platforms at no cost to industry. This report includes the survey results, evaluations, a description of the LTRS architecture, recommended policy statement, and suggestions for future implementations.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Most, W. A.; Kehrman, R.; Gist, C.
2002-02-26
The U.S. Department of Energy (DOE)-Carlsbad Field Office (CBFO) has developed draft documentation to present the proposed Waste Isolation Pilot Plant (WIPP) remote-handled (RH-) transuranic (TRU) waste characterization program to its regulators, the U.S. Environmental Protection Agency and the New Mexico Environment Department. Compliance with Title 40, Code of Federal Regulations, Parts 191 and 194; the WIPP Land Withdrawal Act (PL 102-579); and the WIPP Hazardous Waste Facility Permit, as well as the Certificates of Compliance for the 72-B and 10-160B Casks, requires that specific waste parameter limits be imposed on DOE sites disposing of TRU waste at WIPP. Themore » DOE-CBFO must control the sites' compliance with the limits by specifying allowable characterization methods. As with the established WIPP contact handled TRU waste characterization program, the DOE-CBFO has proposed a Remote-Handled TRU Waste Acceptance Criteria (RH-WAC) document consolidating the requirements from various regulatory drivers and proposed allowable characterization methods. These criteria are consistent with the recommendation of a recent National Academy Sciences/National Research Council to develop an RH-TRU waste characterization approach that removes current self imposed requirements that lack a legal or safety basis. As proposed in the draft RH-WAC and other preliminary documents, the DOE-CBFO RH-TRU waste characterization program proposes the use of acceptable knowledge (AK) as the primary method for obtaining required characterization information. The use of AK involves applying knowledge of the waste in light of the materials or processes used to generate the waste. Documentation, records, or processes providing information about various attributes of a waste stream, such as chemical, physical, and radiological properties, may be used as AK and may be applied to individual waste containers either independently or in conjunction with radiography, visual examination, assay, and other sampling and analytical data. RH-TRU waste cannot be shipped to WIPP on the basis of AK alone if documentation demonstrating that all of the prescribed limits in the RH-WAC are met is not available, discrepancies exist among AK source documents describing the same waste stream and the most conservative assumptions regarding those documents indicates that a limit will not be met, or all required data are not available for a given waste stream.« less
Ares V Utilization in Support of a Human Mission to Mars
NASA Technical Reports Server (NTRS)
Holladay, J. B.; Jaap, J. P.; Pinson, R. M.; Creech, S. D.; Ryan, R. M.; Monk, T. S.; Baggett. K. E.; Runager, M. D.; Dux, I. J.; Hack, K. J.;
2010-01-01
During the analysis cycles of Phase A-Cycle 3 (PA-C3) and the follow-on 8-wk minicycle of PA-C3', the Ares V team assessed the Ares V PA-C3D configuration to the Mars Design Reference Mission as defined in the Constellation Architecture Requirements Document and further described in Mars Design Reference Architecture 5.0 (DRA 5.0) that was publicly released in July 2009. The ability to support the reference approach for the crewed Mars mission was confirmed through this analysis (7-launch nuclear thermal propulsion (NTP) architecture) and the reference chemical approach as defined in DRA 5.0 (11- or 12-launch chemical propulsion module approach). Additional chemical propulsion options were defined that utilized additional technology investments (primarily in-space cryogenic propellant transfer) that allowed for the same mission to be accomplished with 9 launches rather than the 11 or 12, as documented in DRA 5.0 and associated follow-on activities. This nine-launch chemical propulsion approach showed a unique ability to decouple the architecture from major technological developments (such as zero-boiloff technology or the development of NTP stages) and allowed for a relaxing of the infrastructure investments required to support a very rapid launch rate (30-day launch spacing as documented in DRA 5.0). As an enhancing capability, it also shows promise in allowing for and incorporating the development of a commercial market for cryogenic propellant delivery on orbit, without placing such development on the critical path of beyond low-Earth orbit exploration. The ability of Ares V to support all of the aforementioned options and discussion of key forward work that is required to fully understand the complexities and challenges presented by the Mars mission is further documented herein.
Functional Requirements Document for HALE UAS Operations in the NAS: Step 1. Version 3
NASA Technical Reports Server (NTRS)
2006-01-01
The purpose of this Functional Requirements Document (FRD) is to compile the functional requirements needed to achieve the Access 5 Vision of "operating High Altitude, Long Endurance (HALE) Unmanned Aircraft Systems (UAS) routinely, safely, and reliably in the national airspace system (NAS)" for Step 1. These functional requirements could support the development of a minimum set of policies, procedures and standards by the Federal Aviation Administration (FAA) and various standards organizations. It is envisioned that this comprehensive body of work will enable the FAA to establish and approve regulations to govern safe operation of UAS in the NAS on a routine or daily "file and fly" basis. The approach used to derive the functional requirements found within this FRD was to decompose the operational requirements and objectives identified within the Access 5 Concept of Operations (CONOPS) into the functions needed to routinely and safely operate a HALE UAS in the NAS. As a result, four major functional areas evolved to enable routine and safe UAS operations for an on-demand basis in the NAS. These four major functions are: Aviate, Navigate, Communicate, and Avoid Hazards. All of the functional requirements within this document can be directly traceable to one of these four major functions. Some functions, however, are traceable to several, or even all, of these four major functions. These cross-cutting functional requirements support the "Command / Control: function as well as the "Manage Contingencies" function. The requirements associated to these high-level functions and all of their supporting low-level functions are addressed in subsequent sections of this document.
Online Learning Flight Control for Intelligent Flight Control Systems (IFCS)
NASA Technical Reports Server (NTRS)
Niewoehner, Kevin R.; Carter, John (Technical Monitor)
2001-01-01
The research accomplishments for the cooperative agreement 'Online Learning Flight Control for Intelligent Flight Control Systems (IFCS)' include the following: (1) previous IFC program data collection and analysis; (2) IFC program support site (configured IFC systems support network, configured Tornado/VxWorks OS development system, made Configuration and Documentation Management Systems Internet accessible); (3) Airborne Research Test Systems (ARTS) II Hardware (developed hardware requirements specification, developing environmental testing requirements, hardware design, and hardware design development); (4) ARTS II software development laboratory unit (procurement of lab style hardware, configured lab style hardware, and designed interface module equivalent to ARTS II faceplate); (5) program support documentation (developed software development plan, configuration management plan, and software verification and validation plan); (6) LWR algorithm analysis (performed timing and profiling on algorithm); (7) pre-trained neural network analysis; (8) Dynamic Cell Structures (DCS) Neural Network Analysis (performing timing and profiling on algorithm); and (9) conducted technical interchange and quarterly meetings to define IFC research goals.
NASA Technical Reports Server (NTRS)
1973-01-01
Planetary quarantine requirements and parameters are evaluated for their effects upon automated spacecraft flights data describing the heat resistance of naturally occuring microorganisms and sterilization requirements are analyzed and a possible method for assessment of these data is developed. Pertinent data from planetary mission microbial contamination logs are compiled and maintained in the quarantine document system.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1993-01-01
The monitoring requirements presented in the report were developed by EPA before a negotiated Disinfectants and Disinfection By-Products (D/DBP) rule was considered. The framework described herein may be substantially changed as a result of the negotiated rulemaking process. The document is useful to consider in developing various monitoring options during the negotiated rulemaking process.
Space Station Furnace Facility Management Information System (SSFF-MIS) Development
NASA Technical Reports Server (NTRS)
Meade, Robert M.
1996-01-01
This report summarizes the chronology, results, and lessons learned from the development of the SSFF-MIS. This system has been nearly two years in development and has yielded some valuable insights into specialized MIS development. General: In December of 1994, the Camber Corporation and Science Applications International Corporation (SAIC) were contracted to design, develop, and implement a MIS for Marshall Space Flight Center's Space Station Furnace Facility Project. The system was to be accessible from both EBM-Compatible PC and Macintosh platforms. The system was required to contain data manually entered into the MIS as well as data imported from other MSFC sources. Electronic interfaces were established for each data source and retrieval was to be performed at prescribed time intervals. The SOW requirement that predominantly drove the development software selection was the dual-platform (IBM-PC and Macintosh) requirement. The requirement that the system would be maintained by Government personnel influenced the selection of Commercial Off-the-shelf software because of its inherent stability and readily available documentation and support. Microsoft FoxPro Professional 2.6 for Windows and Macintosh was selected as the development tool. This is a software development tool that has been in use for many years. It is stable and powerful. Microsoft has since released the replacement for this product, Microsoft Visual FoxPro, but at the time of this development, it was only available on the Windows platform. The initial contract included included the requirement for capabilities relating to the Work- and Organizational Breakdown Structures, cost (plan and actuals), workforce (plan and actuals), critical path scheduling, trend analysis, procurements and contracts, interface to manufacturing, Safety and Mission Assurance, risk analysis, and technical performance indicators. It also required full documentation of the system and training of users. During the course of the contract, the requirements for Safety and Mission Assurance interface, risk analysis, and technical performance indicators were deleted. Additional capabilities were added as reflected in the Contract Chronology below. Modification 4 added the requirement for Support Contractor manpower data, the ability to manually input data not imported from non-nal sources, a general 'health' indicator screen, and remote usage. Mod 6 included the ability to change the level of planning of Civil Service Manpower at any time and the ability to manually enter Op Codes in the manufacturing data where such codes were not provided by the EMPACS database. Modification 9 included a number of changes to report contents and formats. Modification 11 required the preparation of a detailed System Design Document.
Clustering XML Documents Using Frequent Subtrees
NASA Astrophysics Data System (ADS)
Kutty, Sangeetha; Tran, Tien; Nayak, Richi; Li, Yuefeng
This paper presents an experimental study conducted over the INEX 2008 Document Mining Challenge corpus using both the structure and the content of XML documents for clustering them. The concise common substructures known as the closed frequent subtrees are generated using the structural information of the XML documents. The closed frequent subtrees are then used to extract the constrained content from the documents. A matrix containing the term distribution of the documents in the dataset is developed using the extracted constrained content. The k-way clustering algorithm is applied to the matrix to obtain the required clusters. In spite of the large number of documents in the INEX 2008 Wikipedia dataset, the proposed frequent subtree-based clustering approach was successful in clustering the documents. This approach significantly reduces the dimensionality of the terms used for clustering without much loss in accuracy.
Code of Federal Regulations, 2012 CFR
2012-10-01
... recordkeeping requirements for consignment documents and re-export certificates. 300.185 Section 300.185..., reporting and recordkeeping requirements for consignment documents and re-export certificates. (a) Imports... apply only to entries for consumption. The reporting requirements of paragraph (a)(3) of this section do...
Code of Federal Regulations, 2014 CFR
2014-10-01
... recordkeeping requirements for consignment documents and re-export certificates. 300.185 Section 300.185..., reporting and recordkeeping requirements for consignment documents and re-export certificates. (a) Imports... apply only to entries for consumption. The reporting requirements of paragraph (a)(3) of this section do...
Code of Federal Regulations, 2013 CFR
2013-10-01
... recordkeeping requirements for consignment documents and re-export certificates. 300.185 Section 300.185..., reporting and recordkeeping requirements for consignment documents and re-export certificates. (a) Imports... apply only to entries for consumption. The reporting requirements of paragraph (a)(3) of this section do...
22 CFR 40.71 - Documentation requirements for immigrants.
Code of Federal Regulations, 2010 CFR
2010-04-01
... 22 Foreign Relations 1 2010-04-01 2010-04-01 false Documentation requirements for immigrants. 40... NONIMMIGRANTS AND IMMIGRANTS UNDER THE IMMIGRATION AND NATIONALITY ACT, AS AMENDED Documentation Requirements § 40.71 Documentation requirements for immigrants. INA 212(a)(7)(A) is not applicable at the time of...
An electronic regulatory document management system for a clinical trial network.
Zhao, Wenle; Durkalski, Valerie; Pauls, Keith; Dillon, Catherine; Kim, Jaemyung; Kolk, Deneil; Silbergleit, Robert; Stevenson, Valerie; Palesch, Yuko
2010-01-01
A computerized regulatory document management system has been developed as a module in a comprehensive Clinical Trial Management System (CTMS) designed for an NIH-funded clinical trial network in order to more efficiently manage and track regulatory compliance. Within the network, several institutions and investigators are involved in multiple trials, and each trial has regulatory document requirements. Some of these documents are trial specific while others apply across multiple trials. The latter causes a possible redundancy in document collection and management. To address these and other related challenges, a central regulatory document management system was designed. This manuscript shares the design of the system as well as examples of it use in current studies. Copyright (c) 2009 Elsevier Inc. All rights reserved.
Dodge, Kent A.; Lambing, John H.
2006-01-01
A quality-assurance plan has been developed for use by the sediment laboratory of the U.S. Geological Survey Montana Water Science Center in conducting activities related to the analysis of suspended sediment. The plan documents quality-assurance policies for sediment-laboratory certification, personnel responsibilities and training, documentation requirements, and laboratory safety. The plan also documents quality-assurance procedures related to laboratory equipment and supplies, sample management, sample analysis, analytical quality control, and data management.
Development of an open metadata schema for prospective clinical research (openPCR) in China.
Xu, W; Guan, Z; Sun, J; Wang, Z; Geng, Y
2014-01-01
In China, deployment of electronic data capture (EDC) and clinical data management system (CDMS) for clinical research (CR) is in its very early stage, and about 90% of clinical studies collected and submitted clinical data manually. This work aims to build an open metadata schema for Prospective Clinical Research (openPCR) in China based on openEHR archetypes, in order to help Chinese researchers easily create specific data entry templates for registration, study design and clinical data collection. Singapore Framework for Dublin Core Application Profiles (DCAP) is used to develop openPCR and four steps such as defining the core functional requirements and deducing the core metadata items, developing archetype models, defining metadata terms and creating archetype records, and finally developing implementation syntax are followed. The core functional requirements are divided into three categories: requirements for research registration, requirements for trial design, and requirements for case report form (CRF). 74 metadata items are identified and their Chinese authority names are created. The minimum metadata set of openPCR includes 3 documents, 6 sections, 26 top level data groups, 32 lower data groups and 74 data elements. The top level container in openPCR is composed of public document, internal document and clinical document archetypes. A hierarchical structure of openPCR is established according to Data Structure of Electronic Health Record Architecture and Data Standard of China (Chinese EHR Standard). Metadata attributes are grouped into six parts: identification, definition, representation, relation, usage guides, and administration. OpenPCR is an open metadata schema based on research registration standards, standards of the Clinical Data Interchange Standards Consortium (CDISC) and Chinese healthcare related standards, and is to be publicly available throughout China. It considers future integration of EHR and CR by adopting data structure and data terms in Chinese EHR Standard. Archetypes in openPCR are modularity models and can be separated, recombined, and reused. The authors recommend that the method to develop openPCR can be referenced by other countries when designing metadata schema of clinical research. In the next steps, openPCR should be used in a number of CR projects to test its applicability and to continuously improve its coverage. Besides, metadata schema for research protocol can be developed to structurize and standardize protocol, and syntactical interoperability of openPCR with other related standards can be considered.
NASA's Microgravity Technology Report, 1996: Summary of Activities
NASA Technical Reports Server (NTRS)
Kierk, Isabella
1996-01-01
This report covers technology development and technology transfer activities within the Microgravity Science Research Programs during FY 1996. It also describes the recent major tasks under the Advanced Technology Development (ATD) Program and identifies current technology requirements. This document is consistent with NASA,s Enteprise for the Human Exploration and development of Space (HEDS) Strategic Plan. This annual update reflects changes in the Microgravity Science Research Program's new technology activities and requirements. Appendix A. FY 1996 Advanced Technology Development. Program and Project Descriptions. Appendix B. Technology Development.
ANSI/ASHRAE/IES Standard 90.1-2010 Performance Rating Method Reference Manual
DOE Office of Scientific and Technical Information (OSTI.GOV)
Goel, Supriya; Rosenberg, Michael I.
This document is intended to be a reference manual for the Appendix G Performance Rating Method (PRM) of ANSI/ASHRAE/IES Standard 90.1- 2010 (Standard 90.1-2010).The PRM is used for rating the energy efficiency of commercial and high-rise residential buildings with designs that exceed the requirements of Standard 90.1. The procedures and processes described in this manual are designed to provide consistency and accuracy by filling in gaps and providing additional details needed by users of the PRM. It should be noted that this document is created independently from ASHRAE and SSPC 90.1 and is not sanctioned nor approved by either ofmore » those entities . Potential users of this manual include energy modelers, software developers and implementers of “beyond code” energy programs. Energy modelers using ASHRAE Standard 90.1-2010 for beyond code programs can use this document as a reference manual for interpreting requirements of the Performance Rating method. Software developers, developing tools for automated creation of the baseline model can use this reference manual as a guideline for developing the rules for the baseline model.« less
Functions and requirements document for interim store solidified high-level and transuranic waste
DOE Office of Scientific and Technical Information (OSTI.GOV)
Smith-Fewell, M.A., Westinghouse Hanford
1996-05-17
The functions, requirements, interfaces, and architectures contained within the Functions and Requirements (F{ampersand}R) Document are based on the information currently contained within the TWRS Functions and Requirements database. The database also documents the set of technically defensible functions and requirements associated with the solidified waste interim storage mission.The F{ampersand}R Document provides a snapshot in time of the technical baseline for the project. The F{ampersand}R document is the product of functional analysis, requirements allocation and architectural structure definition. The technical baseline described in this document is traceable to the TWRS function 4.2.4.1, Interim Store Solidified Waste, and its related requirements, architecture,more » and interfaces.« less
Flat-plate solar array project. Volume 6: Engineering sciences and reliability
NASA Technical Reports Server (NTRS)
Ross, R. G., Jr.; Smokler, M. I.
1986-01-01
The Flat-Plate Solar Array (FSA) Project activities directed at developing the engineering technology base required to achieve modules that meet the functional, safety, and reliability requirements of large scale terrestrial photovoltaic systems applications are reported. These activities included: (1) development of functional, safety, and reliability requirements for such applications; (2) development of the engineering analytical approaches, test techniques, and design solutions required to meet the requirements; (3) synthesis and procurement of candidate designs for test and evaluation; and (4) performance of extensive testing, evaluation, and failure analysis of define design shortfalls and, thus, areas requiring additional research and development. A summary of the approach and technical outcome of these activities are provided along with a complete bibliography of the published documentation covering the detailed accomplishments and technologies developed.
Software Engineering Laboratory (SEL) compendium of tools, revision 1
NASA Technical Reports Server (NTRS)
1982-01-01
A set of programs used to aid software product development is listed. Known as software tools, such programs include requirements analyzers, design languages, precompilers, code auditors, code analyzers, and software librarians. Abstracts, resource requirements, documentation, processing summaries, and availability are indicated for most tools.
TWRS authorization basis configuration control summary
DOE Office of Scientific and Technical Information (OSTI.GOV)
Mendoza, D.P.
This document was developed to define the Authorization Basis management functional requirements for configuration control, to evaluate the management control systems currently in place, and identify any additional controls that may be required until the TWRS [Tank Waste Remediation System] Configuration Management system is fully in place.
49 CFR 525.6 - Requirements for petition.
Code of Federal Regulations, 2010 CFR
2010-10-01
... ADMINISTRATION, DEPARTMENT OF TRANSPORTATION EXEMPTIONS FROM AVERAGE FUEL ECONOMY STANDARDS § 525.6 Requirements... arguments of the petitioner supporting the exemption and alternative average fuel economy standard requested... analyses used to develop that information and data. No documents may be incorporated by reference in a...
DOT National Transportation Integrated Search
2016-07-01
This document provides guidance material in regards to System Requirements for the CV Pilots Deployment Concept Development Phase. Methods for system engineering are discussed with definitions for the successful management of each aspect. Important r...
Application Reuse Library for Software, Requirements, and Guidelines
NASA Technical Reports Server (NTRS)
Malin, Jane T.; Thronesbery, Carroll
1994-01-01
Better designs are needed for expert systems and other operations automation software, for more reliable, usable and effective human support. A prototype computer-aided Application Reuse Library shows feasibility of supporting concurrent development and improvement of advanced software by users, analysts, software developers, and human-computer interaction experts. Such a library expedites development of quality software, by providing working, documented examples, which support understanding, modification and reuse of requirements as well as code. It explicitly documents and implicitly embodies design guidelines, standards and conventions. The Application Reuse Library provides application modules with Demo-and-Tester elements. Developers and users can evaluate applicability of a library module and test modifications, by running it interactively. Sub-modules provide application code and displays and controls. The library supports software modification and reuse, by providing alternative versions of application and display functionality. Information about human support and display requirements is provided, so that modifications will conform to guidelines. The library supports entry of new application modules from developers throughout an organization. Example library modules include a timer, some buttons and special fonts, and a real-time data interface program. The library prototype is implemented in the object-oriented G2 environment for developing real-time expert systems.
Automation for System Safety Analysis
NASA Technical Reports Server (NTRS)
Malin, Jane T.; Fleming, Land; Throop, David; Thronesbery, Carroll; Flores, Joshua; Bennett, Ted; Wennberg, Paul
2009-01-01
This presentation describes work to integrate a set of tools to support early model-based analysis of failures and hazards due to system-software interactions. The tools perform and assist analysts in the following tasks: 1) extract model parts from text for architecture and safety/hazard models; 2) combine the parts with library information to develop the models for visualization and analysis; 3) perform graph analysis and simulation to identify and evaluate possible paths from hazard sources to vulnerable entities and functions, in nominal and anomalous system-software configurations and scenarios; and 4) identify resulting candidate scenarios for software integration testing. There has been significant technical progress in model extraction from Orion program text sources, architecture model derivation (components and connections) and documentation of extraction sources. Models have been derived from Internal Interface Requirements Documents (IIRDs) and FMEA documents. Linguistic text processing is used to extract model parts and relationships, and the Aerospace Ontology also aids automated model development from the extracted information. Visualizations of these models assist analysts in requirements overview and in checking consistency and completeness.
24 CFR 1710.15 - Regulatory exemption-multiple site subdivision-determination required.
Code of Federal Regulations, 2010 CFR
2010-04-01
... non-waivable provision in bold face type (which must be distinguished from the type used for the rest... contract or other document by requiring a specific type of notice or by requiring that notice be given at a... font. A copy of the acknowledgement will be maintained by the developer for three years and will be...
DOT National Transportation Integrated Search
2008-03-31
This document summarizes the efforts conducted by the I-880 ICM team for the development of the system requirements for the I-880 Integrated Corridor Management System (ICMS). It describes the approach that the I-880 team took in defining the ICMS an...
Guidance and Control Software Project Data - Volume 3: Verification Documents
NASA Technical Reports Server (NTRS)
Hayhurst, Kelly J. (Editor)
2008-01-01
The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes the verification documents from the GCS project. Volume 3 contains four appendices: A. Software Verification Cases and Procedures for the Guidance and Control Software Project; B. Software Verification Results for the Pluto Implementation of the Guidance and Control Software; C. Review Records for the Pluto Implementation of the Guidance and Control Software; and D. Test Results Logs for the Pluto Implementation of the Guidance and Control Software.
Revision of ISO 15859 Aerospace Fluid Standards
NASA Technical Reports Server (NTRS)
Greene, Benjamin; McClure, Mark B.
2012-01-01
A detailed review of ISO 15859 "Space Systems - Fluid Characteristics, Sampling and Test Methods" was performed An approach to revising Parts 1-9 and 11-13 was developed and concurred by the NASA Technical Standards Program Office. The approach was to align them with the highest level source documents, and not to program-specific requirements. The updated documents were prepared and presented.
Life-Cycle Inventory Analysis of Laminated Veneer Lumber Production in the United States
Richard D. Bergman
2015-01-01
Documenting the environmental performance of building products is becoming increasingly common. Developing environmental product declarations (EPDs) based on life-cycle assessment (LCA) data is one way to provide scientific documentation. Many U.S. structural wood products have LCA-based âeco-labelsâ using the ISO standard. However, the standard requires underlying...
Federal Register 2010, 2011, 2012, 2013, 2014
2010-10-01
... list of guidance documents the Center for Devices and Radiological Health (CDRH) is considering for... annually posting a list of guidance documents that CDRH is considering for development and providing... CDRH is intending to work over the next Fiscal Year (FY). We note that the agency is not required to...
ERIC Educational Resources Information Center
Learning and Skills Development Agency, London (England).
These two documents are designed to assist governing bodies of England's further education (FE) and land-based colleges self-assess their performance and identify ways of improving their performance. Each document contains a "healthcheck" that requires approximately 30 minutes to complete and that was developed in response to informative…
NASA Technical Reports Server (NTRS)
Hayhurst, Kelly J. (Editor)
2008-01-01
The Guidance and Control Software (GCS) project was the last in a series of software reliability studies conducted at Langley Research Center between 1977 and 1994. The technical results of the GCS project were recorded after the experiment was completed. Some of the support documentation produced as part of the experiment, however, is serving an unexpected role far beyond its original project context. Some of the software used as part of the GCS project was developed to conform to the RTCA/DO-178B software standard, "Software Considerations in Airborne Systems and Equipment Certification," used in the civil aviation industry. That standard requires extensive documentation throughout the software development life cycle, including plans, software requirements, design and source code, verification cases and results, and configuration management and quality control data. The project documentation that includes this information is open for public scrutiny without the legal or safety implications associated with comparable data from an avionics manufacturer. This public availability has afforded an opportunity to use the GCS project documents for DO-178B training. This report provides a brief overview of the GCS project, describes the 4-volume set of documents and the role they are playing in training, and includes configuration management and quality assurance documents from the GCS project. Volume 4 contains six appendices: A. Software Accomplishment Summary for the Guidance and Control Software Project; B. Software Configuration Index for the Guidance and Control Software Project; C. Configuration Management Records for the Guidance and Control Software Project; D. Software Quality Assurance Records for the Guidance and Control Software Project; E. Problem Report for the Pluto Implementation of the Guidance and Control Software Project; and F. Support Documentation Change Reports for the Guidance and Control Software Project.
Data Quality Objectives for Tank Farms Waste Compatibility Program
DOE Office of Scientific and Technical Information (OSTI.GOV)
BANNING, D.L.
1999-07-02
There are 177 waste storage tanks containing over 210,000 m{sup 3} (55 million gal) of mixed waste at the Hanford Site. The River Protection Project (RPP) has adopted the data quality objective (DQO) process used by the U.S. Environmental Protection Agency (EPA) (EPA 1994a) and implemented by RPP internal procedure (Banning 1999a) to identify the information and data needed to address safety issues. This DQO document is based on several documents that provide the technical basis for inputs and decision/action levels used to develop the decision rules that evaluate the transfer of wastes. A number of these documents are presentlymore » in the process of being revised. This document will need to be revised if there are changes to the technical criteria in these supporting documents. This DQO process supports various documents, such as sampling and analysis plans and double-shell tank (DST) waste analysis plans. This document identifies the type, quality, and quantity of data needed to determine whether transfer of supernatant can be performed safely. The requirements in this document are designed to prevent the mixing of incompatible waste as defined in Washington Administrative Code (WAC) 173-303-040. Waste transfers which meet the requirements contained in this document and the Double-Shell Tank Waste Analysis Plan (Mulkey 1998) are considered to be compatible, and prevent the mixing of incompatible waste.« less
Human Integration Design Processes (HIDP)
NASA Technical Reports Server (NTRS)
Boyer, Jennifer
2014-01-01
The purpose of the Human Integration Design Processes (HIDP) document is to provide human-systems integration design processes, including methodologies and best practices that NASA has used to meet human systems and human rating requirements for developing crewed spacecraft. HIDP content is framed around human-centered design methodologies and processes in support of human-system integration requirements and human rating. NASA-STD-3001, Space Flight Human-System Standard, is a two-volume set of National Aeronautics and Space Administration (NASA) Agency-level standards established by the Office of the Chief Health and Medical Officer, directed at minimizing health and performance risks for flight crews in human space flight programs. Volume 1 of NASA-STD-3001, Crew Health, sets standards for fitness for duty, space flight permissible exposure limits, permissible outcome limits, levels of medical care, medical diagnosis, intervention, treatment and care, and countermeasures. Volume 2 of NASASTD- 3001, Human Factors, Habitability, and Environmental Health, focuses on human physical and cognitive capabilities and limitations and defines standards for spacecraft (including orbiters, habitats, and suits), internal environments, facilities, payloads, and related equipment, hardware, and software with which the crew interfaces during space operations. The NASA Procedural Requirements (NPR) 8705.2B, Human-Rating Requirements for Space Systems, specifies the Agency's human-rating processes, procedures, and requirements. The HIDP was written to share NASA's knowledge of processes directed toward achieving human certification of a spacecraft through implementation of human-systems integration requirements. Although the HIDP speaks directly to implementation of NASA-STD-3001 and NPR 8705.2B requirements, the human-centered design, evaluation, and design processes described in this document can be applied to any set of human-systems requirements and are independent of reference missions. The HIDP is a reference document that is intended to be used during the development of crewed space systems and operations to guide human-systems development process activities.
NASA Technical Reports Server (NTRS)
Jester, Peggy L.; Lee, Jeffrey; Zukor, Dorothy J. (Technical Monitor)
2001-01-01
This document addresses the software requirements of the Geoscience Laser Altimeter System (GLAS) Standard Data Software (SDS) supporting the GLAS instrument on the EOS ICESat Spacecraft. This Software Requirements Document represents the initial collection of the technical engineering information for the GLAS SDS. This information is detailed within the second of four main volumes of the Standard documentation, the Product Specification volume. This document is a "roll-out" from the governing volume outline containing the Concept and Requirements sections.
Unwin, Ian; Jansen-van der Vliet, Martine; Westenbrink, Susanne; Presser, Karl; Infanger, Esther; Porubska, Janka; Roe, Mark; Finglas, Paul
2016-02-15
The EuroFIR Document and Data Repositories are being developed as accessible collections of source documents, including grey literature, and the food composition data reported in them. These Repositories will contain source information available to food composition database compilers when selecting their nutritional data. The Document Repository was implemented as searchable bibliographic records in the Europe PubMed Central database, which links to the documents online. The Data Repository will contain original data from source documents in the Document Repository. Testing confirmed the FoodCASE food database management system as a suitable tool for the input, documentation and quality assessment of Data Repository information. Data management requirements for the input and documentation of reported analytical results were established, including record identification and method documentation specifications. Document access and data preparation using the Repositories will provide information resources for compilers, eliminating duplicated work and supporting unambiguous referencing of data contributing to their compiled data. Copyright © 2014 Elsevier Ltd. All rights reserved.
Adapting Rational Unified Process (RUP) approach in designing a secure e-Tendering model
NASA Astrophysics Data System (ADS)
Mohd, Haslina; Robie, Muhammad Afdhal Muhammad; Baharom, Fauziah; Darus, Norida Muhd; Saip, Mohamed Ali; Yasin, Azman
2016-08-01
e-Tendering is an electronic processing of the tender document via internet and allow tenderer to publish, communicate, access, receive and submit all tender related information and documentation via internet. This study aims to design the e-Tendering system using Rational Unified Process approach. RUP provides a disciplined approach on how to assign tasks and responsibilities within the software development process. RUP has four phases that can assist researchers to adjust the requirements of various projects with different scope, problem and the size of projects. RUP is characterized as a use case driven, architecture centered, iterative and incremental process model. However the scope of this study only focusing on Inception and Elaboration phases as step to develop the model and perform only three of nine workflows (business modeling, requirements, analysis and design). RUP has a strong focus on documents and the activities in the inception and elaboration phases mainly concern the creation of diagrams and writing of textual descriptions. The UML notation and the software program, Star UML are used to support the design of e-Tendering. The e-Tendering design based on the RUP approach can contribute to e-Tendering developers and researchers in e-Tendering domain. In addition, this study also shows that the RUP is one of the best system development methodology that can be used as one of the research methodology in Software Engineering domain related to secured design of any observed application. This methodology has been tested in various studies in certain domains, such as in Simulation-based Decision Support, Security Requirement Engineering, Business Modeling and Secure System Requirement, and so forth. As a conclusion, these studies showed that the RUP one of a good research methodology that can be adapted in any Software Engineering (SE) research domain that required a few artifacts to be generated such as use case modeling, misuse case modeling, activity diagram, and initial class diagram from a list of requirements as identified earlier by the SE researchers
A New Handbook for the Development of Space Vehicle Terrestrial Environment Design Requirements.
NASA Technical Reports Server (NTRS)
Johnson, Dale L.; Vaughan, William W.
2008-01-01
A new NASA document entitled "Terrestrial Environment (Climatic) Criteria Handbook for Use in Aerospace Vehicle Development (NASA-HDBK-1001A) has been developed. The Handbook provides terrestrial environment information, data bases, models, recommendations, etc. for use in the design, development, trade studies, testing, and mission analyses for space (or launch) .vehicles. This document is organized into fourteen specific natural environment disciplines of which some are winds, atmospheric models, thermal radiation, precipitation-for-icing, cloud cover, atmospheric electricity, geologic hazards, toxic chemical release by propulsion systems, and sea state. Atmospheric phenomena play a significant role in the design and flight of aerospace vehicles and in the integrity of the associated aerospace systems and structures. Environmental design criteria guidelines in this document are based on measurements and observations of atmospheric and climatic phenomena relative to various aerospace development, operational, and vehicle launch locations. The natural environment criteria guidelines data presented in this Handbook were formulated based on discussions with and requests from engineers involved in aerospace vehicle development and operations. Therefore, they represent responses to actual engineering problems and are not just a general compilation of environmental data. The Handbook addresses the basis for the information presented, the interpretations of the terrestrial environment guideline given in the Handbook, and its application to the development of aerospace vehicle design requirements. Specific examples of the Handbook content and associated "lessons lenmed" are given in this paper.
A New Handbook for the Development of Space Vehicle Terrestrial Environment Design Requirements
NASA Technical Reports Server (NTRS)
Johnson, Dale L.; Vaughan, William W.
2008-01-01
A new NASA document entitled "Terrestrial Environment (Climatic) Criteria Handbook for Use in Aerospace Vehicle Development (NASA-HDBK-IOO1A) has been developed. The Handbook provides terrestrial environment information, data bases, models, recommendations, etc. for use in the design, development, trade studies, testing, and mission analyses for space (or launch) vehicles. This document is organized into fourteen specific natural environment disciplines of which some are winds, atmospheric models, thermal radiation, precipitation-for-icing, cloud cover, atmospheric electricity, geologic hazards, toxic chemical release by propulsion systems, and sea state. Atmospheric phenomena play a significant role in the design and flight of aerospace vehicles and in the integrity of the associated aerospace systems and structures. Environmental design criteria guidelines in this document are based on measurements and observations of atmospheric and climatic phenomena relative to various aerospace development, operational, and vehicle launch locations. The natural environment criteria guidelines data presented in this Handbook were formulated based on discussions with and requests from engineers involved in aerospace vehicle development and operations. Therefore, they represent responses to actual engineering problems and are not just a general compilation of environmental data. The Handbook addresses the basis for the information presented, the interpretations of the terrestrial environment guideline given in the Handbook, and its application to the development of aerospace vehicle design requirements. Specific examples of the Handbook content and associated "lessons lenmed" are given in this paper.
10 CFR 1707.203 - Filing requirements for demands or requests for documents or testimony.
Code of Federal Regulations, 2011 CFR
2011-01-01
... 10 Energy 4 2011-01-01 2011-01-01 false Filing requirements for demands or requests for documents... Production of Documents § 1707.203 Filing requirements for demands or requests for documents or testimony. You must comply with the following requirements whenever you issue demands or requests to a DNFSB...
Regulatory constraints as seen from the pharmaceutical industry.
Galligani, G; David-Andersen, I; Fossum, B
2005-01-01
In Chile, Canada, Europe, Japan, and the USA, which are the main geographical areas for fish farming of high value fish such as salmonids, sea bass, sea bream, yellowtail and catfish, vaccination has been established as an important method for the prevention of infectious diseases. To make new vaccines available to the fish farming industry, pharmaceutical companies must comply with the regulatory framework for licensing of fish vaccines, which in recent years has become more regulated. Considerable scientific and regulatory skills are thus required to develop, document and license vaccines in accordance with the requirements in the different geographical areas. International co-operation to harmonise requirements for the licensing documentation is ongoing. Even though there are obvious benefits to the pharmaceutical industry from the harmonisation process, it may sometimes impose unreasonable requirements. The regulatory framework for fish vaccines clearly has an impact on the time for bringing a new fish vaccine to the market. Several hurdles need to be passed to complete the regulatory process, i.e. obtain a licence. Fulfilment of the rather detailed and extensive requirements for documentation of the production and controls, as well as safety and efficacy of the vaccine, represent a challenge to the pharmaceutical industry, as do the different national and regional licensing procedures. This paper describes regulatory constraints related to the documentation, the licensing process, the site of production and the continuing international harmonisation work, with emphasis on inactivated conventional fish vaccines.
ERIC Educational Resources Information Center
Tataw, Oben Moses
2013-01-01
Interdisciplinary research in computer science requires the development of computational techniques for practical application in different domains. This usually requires careful integration of different areas of technical expertise. This dissertation presents image and time series analysis algorithms, with practical interdisciplinary applications…
Research on Generating Method of Embedded Software Test Document Based on Dynamic Model
NASA Astrophysics Data System (ADS)
Qu, MingCheng; Wu, XiangHu; Tao, YongChao; Liu, Ying
2018-03-01
This paper provides a dynamic model-based test document generation method for embedded software that provides automatic generation of two documents: test requirements specification documentation and configuration item test documentation. This method enables dynamic test requirements to be implemented in dynamic models, enabling dynamic test demand tracking to be easily generated; able to automatically generate standardized, standardized test requirements and test documentation, improved document-related content inconsistency and lack of integrity And other issues, improve the efficiency.
NASA Astrophysics Data System (ADS)
Stalcup, Bruce W.; Dennis, Phillip W.; Dydyk, Robert B.
1999-10-01
Litton PRC and Litton Data Systems Division are developing a system, the Imaged Document Optical Correlation and Conversion System (IDOCCS), to provide a total solution to the problem of managing and retrieving textual and graphic information from imaged document archives. At the heart of IDOCCS, optical correlation technology provides the search and retrieval of information from imaged documents. IDOCCS can be used to rapidly search for key words or phrases within the imaged document archives. In addition, IDOCCS can automatically compare an input document with the archived database to determine if it is a duplicate, thereby reducing the overall resources required to maintain and access the document database. Embedded graphics on imaged pages can also be exploited; e.g., imaged documents containing an agency's seal or logo can be singled out. In this paper, we present a description of IDOCCS as well as preliminary performance results and theoretical projections.
NASA Technical Reports Server (NTRS)
Izumi, K. H.; Thompson, J. L.; Groce, J. L.; Schwab, R. W.
1986-01-01
The design requirements for a 4D path definition algorithm are described. These requirements were developed for the NASA ATOPS as an extension of the Local Flow Management/Profile Descent algorithm. They specify the processing flow, functional and data architectures, and system input requirements, and recommended the addition of a broad path revision (reinitialization) function capability. The document also summarizes algorithm design enhancements and the implementation status of the algorithm on an in-house PDP-11/70 computer. Finally, the requirements for the pilot-computer interfaces, the lateral path processor, and guidance and steering function are described.
Towards a Methodology for Identifying Program Constraints During Requirements Analysis
NASA Technical Reports Server (NTRS)
Romo, Lilly; Gates, Ann Q.; Della-Piana, Connie Kubo
1997-01-01
Requirements analysis is the activity that involves determining the needs of the customer, identifying the services that the software system should provide and understanding the constraints on the solution. The result of this activity is a natural language document, typically referred to as the requirements definition document. Some of the problems that exist in defining requirements in large scale software projects includes synthesizing knowledge from various domain experts and communicating this information across multiple levels of personnel. One approach that addresses part of this problem is called context monitoring and involves identifying the properties of and relationships between objects that the system will manipulate. This paper examines several software development methodologies, discusses the support that each provide for eliciting such information from experts and specifying the information, and suggests refinements to these methodologies.
Fulton, James L.
1992-01-01
Spatial data analysis has become an integral component in many surface and sub-surface hydrologic investigations within the U.S. Geological Survey (USGS). Currently, one of the largest costs in applying spatial data analysis is the cost of developing the needed spatial data. Therefore, guidelines and standards are required for the development of spatial data in order to allow for data sharing and reuse; this eliminates costly redevelopment. In order to attain this goal, the USGS is expanding efforts to identify guidelines and standards for the development of spatial data for hydrologic analysis. Because of the variety of project and database needs, the USGS has concentrated on developing standards for documenting spatial sets to aid in the assessment of data set quality and compatibility of different data sets. An interim data set documentation standard (1990) has been developed that provides a mechanism for associating a wide variety of information with a data set, including data about source material, data automation and editing procedures used, projection parameters, data statistics, descriptions of features and feature attributes, information on organizational contacts lists of operations performed on the data, and free-form comments and notes about the data, made at various times in the evolution of the data set. The interim data set documentation standard has been automated using a commercial geographic information system (GIS) and data set documentation software developed by the USGS. Where possible, USGS developed software is used to enter data into the data set documentation file automatically. The GIS software closely associates a data set with its data set documentation file; the documentation file is retained with the data set whenever it is modified, copied, or transferred to another computer system. The Water Resources Division of the USGS is continuing to develop spatial data and data processing standards, with emphasis on standards needed to support hydrologic analysis, hydrologic data processing, and publication of hydrologic thermatic maps. There is a need for the GIS vendor community to develop data set documentation tools similar to those developed by the USGS, or to incorporate USGS developed tools in their software.
NASA Technical Reports Server (NTRS)
Goltz, G.; Kaiser, L. M.; Weiner, H.
1977-01-01
A computer program has been developed for designing and analyzing the performance of solar array/battery power systems for the U.S. Coast Guard Navigational Aids. This program is called the Design Synthesis/Performance Analysis (DSPA) Computer Program. The basic function of the Design Synthesis portion of the DSPA program is to evaluate functional and economic criteria to provide specifications for viable solar array/battery power systems. The basic function of the Performance Analysis portion of the DSPA program is to simulate the operation of solar array/battery power systems under specific loads and environmental conditions. This document establishes the software requirements for the DSPA computer program, discusses the processing that occurs within the program, and defines the necessary interfaces for operation.
DOE Office of Scientific and Technical Information (OSTI.GOV)
O'Farrell, T.; Hund, F.
1986-12-01
The document presents the technical rationale for best conventional technology (BCI) effluent limitations guidelines for the pharmaceutical manufacturing point-source category as required by the Clean Water Act of 1977 (P.L. 95-217, the Act). The document describes the technologies considered as the bases for BCT limitations. Section II of this document summarizes the rulemaking process. Sections III through V describe the technical data and engineering analyses used to develop the regulatory technology options. The costs and removals associated with each technology option for each plant and the application of the BCT cost test methodology are presented in Section VI. BCI limitationsmore » bases on the best conventional pollutant control technology are to be achieved by existing direct-discharging facilities.« less
NASA Astrophysics Data System (ADS)
Mlimandago, S.
This research paper have gone out with very simple and easy (several) new concepts in document management for space projects and programs which can be applied anywhere both in the developing and developed countries. These several new concepts are and have been applied in Tanzania, Kenya and Uganda and found out to bear very good results using simple procedures. The intergral project based its documentation management approach from the outset on electronic document sharing and archiving. The main objective of having new concepts was to provide a faster and wider availability of the most current space information to all parties rather than creating a paperless office. Implementation of the new concepts approach required the capturing of documents in an appropriate and simple electronic format at source establishing new procedures for project wide information sharing and the deployment of a new generation of simple procedure - WEB - based tools. Key success factors were the early adoption of Internet technologies and simple procedures for improved information flow new concepts which can be applied anywhere both in the developed and the developing countries.
1983-09-30
UNCLASSIFIED SECl’IKTY CLASm;IFICATION OF THIS PAGE (When Dato Entered) REPORT DOCUMENTATION PAGE READ ISTRUCTONSBEFORE COMPLETING FORM 1. REPORT...Civilian Health Manpower Requirements Data ... .................. 4.6 4.3.5 Civilian Health Manpower Supply Data . . 4.7 4.4 Gata Base Creation and...reaeral *agencies involved. What is required is the development of adequate data bases for the civilian sector health manpower supply and requirements
SIENA Customer Problem Statement and Requirements
DOE Office of Scientific and Technical Information (OSTI.GOV)
L. Sauer; R. Clay; C. Adams
2000-08-01
This document describes the problem domain and functional requirements of the SIENA framework. The software requirements and system architecture of SIENA are specified in separate documents (called SIENA Software Requirement Specification and SIENA Software Architecture, respectively). While currently this version of the document describes the problems and captures the requirements within the Analysis domain (concentrating on finite element models), it is our intention to subsequent y expand this document to describe problems and capture requirements from the Design and Manufacturing domains. In addition, SIENA is designed to be extendible to support and integrate elements from the other domains (see SIENAmore » Software Architecture document).« less
Performance measures in the earth observations commercialization applications program
NASA Astrophysics Data System (ADS)
Macauley, Molly K.
1996-03-01
Performance measures in the Earth Observations Commercialization Application Program (EOCAP) are key to its success and include net profitability; enhancements to industry productivity through generic innovations in industry practices, standards, and protocols; and documented contributions to public policy governing the newly developing remote sensing industry. Because EOCAP requires company co-funding, both parties to the agreement (the government and the corporate partner) have incentives to pursue these goals. Further strengthening progress towards these goals are requirements for business plans in the company's EOCAP proposal, detailed scrutiny given these plans during proposal selection, and regularly documented progress reports during project implementation.
Taylor, Benjamin B; Parekh, Vikas; Estrada, Carlos A; Schleyer, Anneliese; Sharpe, Bradley
2014-01-01
Physicians increasingly investigate, work, and teach to improve the quality of care and safety of care delivery. The Society of General Internal Medicine Academic Hospitalist Task Force sought to develop a practical tool, the quality portfolio, to systematically document quality and safety achievements. The quality portfolio was vetted with internal and external stakeholders including national leaders in academic medicine. The portfolio was refined for implementation to include an outlined framework, detailed instructions for use and an example to guide users. The portfolio has eight categories including: (1) a faculty narrative, (2) leadership and administrative activities, (3) project activities, (4) education and curricula, (5) research and scholarship, (6) honors, awards, and recognition, (7) training and certification, and (8) an appendix. The authors offer this comprehensive, yet practical tool as a method to document quality and safety activities. It is relevant for physicians across disciplines and institutions and may be useful as a standalone document or as an adjunct to traditional promotion documents. As the Next Accreditation System is implemented, academic medical centers will require faculty who can teach and implement the systems-based practice requirements. The quality portfolio is a method to document quality improvement and safety activities.
Automated documentation generator for advanced protein crystal growth
NASA Technical Reports Server (NTRS)
Maddux, Gary A.; Provancha, Anna; Chattam, David; Ford, Ronald
1993-01-01
The System Management and Production Laboratory at the Research Institute, the University of Alabama in Huntsville (UAH), was tasked by the Microgravity Experiment Projects (MEP) Office of the Payload Projects Office (PPO) at Marshall Space Flight Center (MSFC) to conduct research in the current methods of written documentation control and retrieval. The goals of this research were to determine the logical interrelationships within selected NASA documentation, and to expand on a previously developed prototype system to deliver a distributable, electronic knowledge-based system. This computer application would then be used to provide a paperless interface between the appropriate parties for the required NASA document.
The IRMIS object model and services API.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Saunders, C.; Dohan, D. A.; Arnold, N. D.
2005-01-01
The relational model developed for the Integrated Relational Model of Installed Systems (IRMIS) toolkit has been successfully used to capture the Advanced Photon Source (APS) control system software (EPICS process variables and their definitions). The relational tables are populated by a crawler script that parses each Input/Output Controller (IOC) start-up file when an IOC reboot is detected. User interaction is provided by a Java Swing application that acts as a desktop for viewing the process variable information. Mapping between the display objects and the relational tables was carried out with the Hibernate Object Relational Modeling (ORM) framework. Work is wellmore » underway at the APS to extend the relational modeling to include control system hardware. For this work, due in part to the complex user interaction required, the primary application development environment has shifted from the relational database view to the object oriented (Java) perspective. With this approach, the business logic is executed in Java rather than in SQL stored procedures. This paper describes the object model used to represent control system software, hardware, and interconnects in IRMIS. We also describe the services API used to encapsulate the required behaviors for creating and maintaining the complex data. In addition to the core schema and object model, many important concepts in IRMIS are captured by the services API. IRMIS is an ambitious collaborative effort for defining and developing a relational database and associated applications to comprehensively document the large and complex EPICS-based control systems of today's accelerators. The documentation effort includes process variables, control system hardware, and interconnections. The approach could also be used to document all components of the accelerator, including mechanical, vacuum, power supplies, etc. One key aspect of IRMIS is that it is a documentation framework, not a design and development tool. We do not generate EPICS control system configurations from IRMIS, and hence do not impose any additional requirements on EPICS developers.« less
NASA Technical Reports Server (NTRS)
Keeley, J. T.
1976-01-01
Guidelines and general requirements applicable to the development of instrument flight hardware intended for use on the GSFC Shuttle Scientific Payloads Program are given. Criteria, guidelines, and an organized approach to specifying the appropriate level of requirements for each instrument in order to permit its development at minimum cost while still assuring crew safety, are included. It is recognized that the instruments for these payloads will encompass wide ranges of complexity, cost, development risk, and safety hazards. The flexibility required to adapt the controls, documentation, and verification requirements in accord with the specific instrument is provided.
Integration of safety engineering into a cost optimized development program.
NASA Technical Reports Server (NTRS)
Ball, L. W.
1972-01-01
A six-segment management model is presented, each segment of which represents a major area in a new product development program. The first segment of the model covers integration of specialist engineers into 'systems requirement definition' or the system engineering documentation process. The second covers preparation of five basic types of 'development program plans.' The third segment covers integration of system requirements, scheduling, and funding of specialist engineering activities into 'work breakdown structures,' 'cost accounts,' and 'work packages.' The fourth covers 'requirement communication' by line organizations. The fifth covers 'performance measurement' based on work package data. The sixth covers 'baseline requirements achievement tracking.'
NASA Standard for Models and Simulations: Philosophy and Requirements Overview
NASA Technical Reports Server (NTRS)
Blattnig, Steve R.; Luckring, James M.; Morrison, Joseph H.; Sylvester, Andre J.; Tripathi, Ram K.; Zang, Thomas A.
2013-01-01
Following the Columbia Accident Investigation Board report, the NASA Administrator chartered an executive team (known as the Diaz Team) to identify those CAIB report elements with NASA-wide applicability and to develop corrective measures to address each element. One such measure was the development of a standard for the development, documentation, and operation of models and simulations. This report describes the philosophy and requirements overview of the resulting NASA Standard for Models and Simulations.
NASA Standard for Models and Simulations: Philosophy and Requirements Overview
NASA Technical Reports Server (NTRS)
Blattnig, St3eve R.; Luckring, James M.; Morrison, Joseph H.; Sylvester, Andre J.; Tripathi, Ram K.; Zang, Thomas A.
2009-01-01
Following the Columbia Accident Investigation Board report, the NASA Administrator chartered an executive team (known as the Diaz Team) to identify those CAIB report elements with NASA-wide applicability and to develop corrective measures to address each element. One such measure was the development of a standard for the development, documentation, and operation of models and simulations. This report describes the philosophy and requirements overview of the resulting NASA Standard for Models and Simulations.
Automated document analysis system
NASA Astrophysics Data System (ADS)
Black, Jeffrey D.; Dietzel, Robert; Hartnett, David
2002-08-01
A software application has been developed to aid law enforcement and government intelligence gathering organizations in the translation and analysis of foreign language documents with potential intelligence content. The Automated Document Analysis System (ADAS) provides the capability to search (data or text mine) documents in English and the most commonly encountered foreign languages, including Arabic. Hardcopy documents are scanned by a high-speed scanner and are optical character recognized (OCR). Documents obtained in an electronic format bypass the OCR and are copied directly to a working directory. For translation and analysis, the script and the language of the documents are first determined. If the document is not in English, the document is machine translated to English. The documents are searched for keywords and key features in either the native language or translated English. The user can quickly review the document to determine if it has any intelligence content and whether detailed, verbatim human translation is required. The documents and document content are cataloged for potential future analysis. The system allows non-linguists to evaluate foreign language documents and allows for the quick analysis of a large quantity of documents. All document processing can be performed manually or automatically on a single document or a batch of documents.
DOT National Transportation Integrated Search
1978-09-01
The requirements for a navigation guidance system which will effect an increase in the ship processing capacity of the Saint Lawrence Seaway (Lake Ontario to Montreal, Quebec) are developed. The requirements include a specification of system position...
DOT National Transportation Integrated Search
2015-08-01
This document is the third of a seven volume report that describe the Performance Requirements for the connected vehicle vehicle-to-infrastructure (V2I) safety applications developed for the U.S. Department of Transportation (U.S. DOT). This volume d...
DOT National Transportation Integrated Search
2015-08-01
This document is the seventh of a seven volume report that describe the Performance Requirements for the connected vehicle vehicle-to-infrastructure (V2I) safety applications developed for the U.S. Department of Transportation (U.S. DOT). This volume...
DOT National Transportation Integrated Search
2015-08-01
This document is the second of a seven volume report that describe the Performance Requirements for the connected vehicle vehicle-to-infrastructure (V2I) safety applications developed for the U.S. Department of Transportation (U.S. DOT). This volume ...
Conceptual design of a monitoring system for the Charters of Freedom
NASA Technical Reports Server (NTRS)
Cutts, J. A.
1984-01-01
A conceptual design of a monitoring system for the Charters of Freedom was developed for the National Archives and Records Service. The monitoring system would be installed at the National Archives and used to document the condition of the Charters as part of a regular inspection program. The results of an experimental measurements program that led to the definition of analysis system requirements are presented, a conceptual design of the monitoring system is described and the alternative approaches to implementing this design were discussed. The monitoring system is required to optically detect and measure deterioration in documents that are permanently encapsulated in glass cases. An electronic imaging system with the capability for precise photometric measurements of the contrast of the script on the documents can perform this task. Two general types of imaging systems are considered (line and area array), and their suitability for performing these required measurements are compared. A digital processing capability for analyzing the electronic imaging data is also required, and several optional levels of complexity for this digital analysis system are evaluated.
Programs of Study and Support Services Guide. Workforce Development Education.
ERIC Educational Resources Information Center
North Carolina State Dept. of Public Instruction, Raleigh.
This document was developed to assist local school systems in North Carolina in planning effective and comprehensive workforce development education programs. It contains information about planning, required resources, instructional guidelines, and program area offerings. The guide is organized in three parts. Part I provides a program description…
NASA TSRV essential flight control system requirements via object oriented analysis
NASA Technical Reports Server (NTRS)
Duffy, Keith S.; Hoza, Bradley J.
1992-01-01
The objective was to analyze the baseline flight control system of the Transport Systems Research Vehicle (TSRV) and to develop a system specification that offers high visibility of the essential system requirements in order to facilitate the future development of alternate, more advanced software architectures. The flight control system is defined to be the baseline software for the TSRV research flight deck, including all navigation, guidance, and control functions, and primary pilot displays. The Object Oriented Analysis (OOA) methodology developed is used to develop a system requirement definition. The scope of the requirements definition contained herein is limited to a portion of the Flight Management/Flight Control computer functionality. The development of a partial system requirements definition is documented, and includes a discussion of the tasks required to increase the scope of the requirements definition and recommendations for follow-on research.
NASA Astrophysics Data System (ADS)
Kondrateva, O. E.; Roslyakov, P. V.; Borovkova, A. M.; Loktionov, O. A.
2017-11-01
Over the past 3 years there have been significant changes in Russian environmental legislation related to the transition to technological regulation based on the principles of the best available technologies (BAT). These changes also imply control and accounting of the harmful impact of industrial enterprises on the environment. Therefore, a mandatory requirement for equipping automatic continuous emission monitoring systems (ACEMS) is established for all large TPPs. For a successful practical solution of the problem of introducing such systems in the whole country there is an urgent need to develop the governing regulatory document for the design and operation of systems for continuous monitoring of TPP emissions into the air, allowing within reasonable limits to unify these systems for their work with the state data fund of state environmental monitoring and make easier the process of their implementation at operating facilities for industrial enterprises. Based on the large amount of research in the field of creation of ACEMS, which conducted in National Research University “MPEI”, a draft guidance document was developed, which includes the following regulatory provisions: goals and objectives of ACEMS, the stages of their introduction rules of carrying out preliminary inspection of energy facilities, requirements to develop technical specifications, general requirements for the operation of ACEMS, requirements to the structure and elements of ACEMS, recommendations on selection of places of measuring equipment installation, rules for execution, commissioning and acceptance testing, continuous measurement method, method for determination of the current gross and specific emissions. The draft guidance document, developed by the National Research University “MPEI”, formed the basis of the Preliminary national standards PNST 187-2017 “Automatic systems for continuous control and metering of contaminants emissions from thermal electric power stations into the atmospheric air. General requirements”. [1
ERIC Educational Resources Information Center
Georgia State Dept. of Education, Atlanta. Facilities Services Unit.
This document presents the space requirements for Georgia's elementary, middle, and high schools. All square footage requirements are computed by using inside dimensions of a room; the square footage of support spaces in suites may be included when computing the square footage of the suite. Examples of support spaces include storage rooms,…
45 CFR 164.316 - Policies and procedures and documentation requirements.
Code of Federal Regulations, 2013 CFR
2013-10-01
... when it last was in effect, whichever is later. (ii) Availability (Required). Make documentation.... (iii) Updates (Required). Review documentation periodically, and update as needed, in response to...
U.S. Central Command Headquarters’ Use of the Government Purchase Card
2011-01-25
required the coordinator to document training sessions. During our review, the squadron was developing a new electronic system to support the...approving officials and cardholders. 2. Establish a plan to ensure that the new electronic Government Purchase Card Tracking system is completed...tickets,” invoices, shipping/packing documents or receiving reports, or electronic purchase confirmations are acceptable) for each purchase and other
20 CFR 655.1319 - Document retention requirements.
Code of Federal Regulations, 2010 CFR
2010-04-01
... 20 Employees' Benefits 3 2010-04-01 2010-04-01 false Document retention requirements. 655.1319... Employment in the United States (H-2A Workers) § 655.1319 Document retention requirements. (a) Entities... retention. Records and documents must be retained for a period of 3 years from the date of certification of...
46 CFR 67.105 - Requirement for determination.
Code of Federal Regulations, 2013 CFR
2013-10-01
... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.105 Requirement for determination. The gross and net tonnage and dimensions of a vessel must be determined: (a) For initial documentation; (b) Whenever there is a change in the gross or net tonnage or dimensions of a documented vessel...
46 CFR 67.105 - Requirement for determination.
Code of Federal Regulations, 2014 CFR
2014-10-01
... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.105 Requirement for determination. The gross and net tonnage and dimensions of a vessel must be determined: (a) For initial documentation; (b) Whenever there is a change in the gross or net tonnage or dimensions of a documented vessel...
46 CFR 67.105 - Requirement for determination.
Code of Federal Regulations, 2012 CFR
2012-10-01
... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.105 Requirement for determination. The gross and net tonnage and dimensions of a vessel must be determined: (a) For initial documentation; (b) Whenever there is a change in the gross or net tonnage or dimensions of a documented vessel...
46 CFR 67.105 - Requirement for determination.
Code of Federal Regulations, 2010 CFR
2010-10-01
... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.105 Requirement for determination. The gross and net tonnage and dimensions of a vessel must be determined: (a) For initial documentation; (b) Whenever there is a change in the gross or net tonnage or dimensions of a documented vessel...
46 CFR 67.105 - Requirement for determination.
Code of Federal Regulations, 2011 CFR
2011-10-01
... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.105 Requirement for determination. The gross and net tonnage and dimensions of a vessel must be determined: (a) For initial documentation; (b) Whenever there is a change in the gross or net tonnage or dimensions of a documented vessel...
TARGET's role in knowledge acquisition, engineering, validation, and documentation
NASA Technical Reports Server (NTRS)
Levi, Keith R.
1994-01-01
We investigate the use of the TARGET task analysis tool for use in the development of rule-based expert systems. We found TARGET to be very helpful in the knowledge acquisition process. It enabled us to perform knowledge acquisition with one knowledge engineer rather than two. In addition, it improved communication between the domain expert and knowledge engineer. We also found it to be useful for both the rule development and refinement phases of the knowledge engineering process. Using the network in these phases required us to develop guidelines that enabled us to easily translate the network into production rules. A significant requirement for TARGET remaining useful throughout the knowledge engineering process was the need to carefully maintain consistency between the network and the rule representations. Maintaining consistency not only benefited the knowledge engineering process, but also has significant payoffs in the areas of validation of the expert system and documentation of the knowledge in the system.
Technical Basis for PNNL Beryllium Inventory
DOE Office of Scientific and Technical Information (OSTI.GOV)
Johnson, Michelle Lynn
2014-07-09
The Department of Energy (DOE) issued Title 10 of the Code of Federal Regulations Part 850, “Chronic Beryllium Disease Prevention Program” (the Beryllium Rule) in 1999 and required full compliance by no later than January 7, 2002. The Beryllium Rule requires the development of a baseline beryllium inventory of the locations of beryllium operations and other locations of potential beryllium contamination at DOE facilities. The baseline beryllium inventory is also required to identify workers exposed or potentially exposed to beryllium at those locations. Prior to DOE issuing 10 CFR 850, Pacific Northwest Nuclear Laboratory (PNNL) had documented the beryllium characterizationmore » and worker exposure potential for multiple facilities in compliance with DOE’s 1997 Notice 440.1, “Interim Chronic Beryllium Disease.” After DOE’s issuance of 10 CFR 850, PNNL developed an implementation plan to be compliant by 2002. In 2014, an internal self-assessment (ITS #E-00748) of PNNL’s Chronic Beryllium Disease Prevention Program (CBDPP) identified several deficiencies. One deficiency is that the technical basis for establishing the baseline beryllium inventory when the Beryllium Rule was implemented was either not documented or not retrievable. In addition, the beryllium inventory itself had not been adequately documented and maintained since PNNL established its own CBDPP, separate from Hanford Site’s program. This document reconstructs PNNL’s baseline beryllium inventory as it would have existed when it achieved compliance with the Beryllium Rule in 2001 and provides the technical basis for the baseline beryllium inventory.« less
Photogrammetry for Archaeology: Collecting Pieces Together
NASA Astrophysics Data System (ADS)
Chibunichev, A. G.; Knyaz, V. A.; Zhuravlev, D. V.; Kurkov, V. M.
2018-05-01
The complexity of retrieving and understanding the archaeological data requires to apply different techniques, tools and sensors for information gathering, processing and documenting. Archaeological research now has the interdisciplinary nature involving technologies based on different physical principles for retrieving information about archaeological findings. The important part of archaeological data is visual and spatial information which allows reconstructing the appearance of the findings and relation between them. Photogrammetry has a great potential for accurate acquiring of spatial and visual data of different scale and resolution allowing to create archaeological documents of new type and quality. The aim of the presented study is to develop an approach for creating new forms of archaeological documents, a pipeline for their producing and collecting in one holistic model, describing an archaeological site. A set of techniques is developed for acquiring and integration of spatial and visual data of different level of details. The application of the developed techniques is demonstrated for documenting of Bosporus archaeological expedition of Russian State Historical Museum.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Casey, Leslie A.
The goal, objectives, and requirements (GOR) presented in this document define a framework for describing research directed specifically by the Ground-based Nuclear Detonation Detection (GNDD) Team of the National Nuclear Security Administration (NNSA). The intent of this document is to provide a communication tool for the GNDD Team with NNSA management and with its stakeholder community. It describes the GNDD expectation that much of the improvement in the proficiency of nuclear explosion monitoring will come from better understanding of the science behind the generation, propagation, recording, and interpretation of seismic, infrasound, hydroacoustic, and radionuclide signals and development of "game-changer" advancesmore » in science and technology.« less
Detailed Design Documentation, without the Pain
NASA Astrophysics Data System (ADS)
Ramsay, C. D.; Parkes, S.
2004-06-01
Producing detailed forms of design documentation, such as pseudocode and structured flowcharts, to describe the procedures of a software system:(1) allows software developers to model and discuss their understanding of a problem and the design of a solution free from the syntax of a programming language,(2) facilitates deeper involvement of non-technical stakeholders, such as the customer or project managers, whose influence ensures the quality, correctness and timeliness of the resulting system,(3) forms comprehensive documentation of the system for its future maintenance, reuse and/or redeployment.However, such forms of documentation require effort to create and maintain.This paper describes a software tool which is currently being developed within the Space Systems Research Group at the University of Dundee which aims to improve the utility of, and the incentive for, creating detailed design documentation for the procedures of a software system. The rationale for creating such a tool is briefly discussed, followed by a description of the tool itself, a summary of its perceived benefits, and plans for future work.
NASA Technical Reports Server (NTRS)
Garcia, Hector D.; Coleman, M.; James, J.; Lam, C.
1999-01-01
Data on chemical and biological materials to be flown in the pressurized volumes of habitable spacecraft, including the International Space Station (ISS), are needed by JSC toxicologists to assess the toxicity and assign hazard levels. This document defines submission schedules and establishes requirements for the types and format of these data. JSC 27472 Rev A is a major revision of JSC 25607, "Requirements for Submission of Test Sample-Materials Data for Shuttle Payload Safety Evaluations", dated October 1994, which was subsequently re-issued (September 1996) with a new document number, JSC 27472, but with the same title and date and no revisions. The revisions in the present document have been necessitated by the recent introduction of a two-step process (described in this document) for verification of data for flight materials and by the anticipated needs of the ISS. The requirements -for data submission apply to items which contain liquids, gases, gels, greases, powders/ particulates, radioisotopes, or biological materials and are located in the habitable pressurized volume of ISS or U.S. operated spacecraft. These include, but are not limited to, science payloads, government furnished equipment (GFE), risk mitigation experiments (RmEs), development test objectives (DTOs), detailed supplementary objectives (DSOs), life science experiments, and medical studies.
NASA Supportability Engineering Implementation Utilizing DoD Practices and Processes
NASA Technical Reports Server (NTRS)
Smith, David A.; Smith, John V.
2010-01-01
The Ares I design and development program made the determination early in the System Design Review Phase to utilize DoD ILS and LSA approach for supportability engineering as an integral part of the system engineering process. This paper is to provide a review of the overall approach to design Ares-I with an emphasis on a more affordable, supportable, and sustainable launch vehicle. Discussions will include the requirements development, design influence, support concept alternatives, ILS and LSA planning, Logistics support analyses/trades performed, LSA tailoring for NASA Ares Program, support system infrastructure identification, ILS Design Review documentation, Working Group coordination, and overall ILS implementation. At the outset, the Ares I Project initiated the development of the Integrated Logistics Support Plan (ILSP) and a Logistics Support Analysis process to provide a path forward for the management of the Ares-I ILS program and supportability analysis activities. The ILSP provide the initial planning and coordination between the Ares-I Project Elements and Ground Operation Project. The LSA process provided a system engineering approach in the development of the Ares-I supportability requirements; influence the design for supportability and development of alternative support concepts that satisfies the program operability requirements. The LSA planning and analysis results are documented in the Logistics Support Analysis Report. This document was required during the Ares-I System Design Review (SDR) and Preliminary Design Review (PDR) review cycles. To help coordinate the LSA process across the Ares-I project and between programs, the LSA Report is updated and released quarterly. A System Requirement Analysis was performed to determine the supportability requirements and technical performance measurements (TPMs). Two working groups were established to provide support in the management and implement the Ares-I ILS program, the Integrated Logistics Support Working Group (ILSWG) and the Logistics Support Analysis Record Working Group (LSARWG). The Ares I ILSWG is established to assess the requirements and conduct, evaluate analyses and trade studies associated with acquisition logistic and supportability processes and to resolve Ares I integrated logistics and supportability issues. It established a strategic collaborative alliance for coordination of Logistics Support Analysis activates in support of the integrated Ares I vehicle design and development of logistics support infrastructure. A Joint Ares I - Orion LSAR Working Group was established to: 1) Guide the development of Ares-I and Orion LSAR data and serve as a model for future Constellation programs, 2) Develop rules and assumptions that will apply across the Constellation program with regards to the program's LSAR development, and 3) Maintain the Constellation LSAR Style Guide.
NASA Astrophysics Data System (ADS)
Salim, Mohd Faiz; Roslan, Ridha; Ibrahim, Mohd Rizal Mamat @
2014-02-01
Deterministic Safety Analysis (DSA) is one of the mandatory requirements conducted for Nuclear Power Plant licensing process, with the aim of ensuring safety compliance with relevant regulatory acceptance criteria. DSA is a technique whereby a set of conservative deterministic rules and requirements are applied for the design and operation of facilities or activities. Computer codes are normally used to assist in performing all required analysis under DSA. To ensure a comprehensive analysis, the conduct of DSA should follow a systematic approach. One of the methodologies proposed is the Standardized and Consolidated Reference Experimental (and Calculated) Database (SCRED) developed by University of Pisa. Based on this methodology, the use of Reference Data Set (RDS) as a pre-requisite reference document for developing input nodalization was proposed. This paper shall describe the application of RDS with the purpose of assessing its effectiveness. Two RDS documents were developed for an Integral Test Facility of LOBI-MOD2 and associated Test A1-83. Data and information from various reports and drawings were referred in preparing the RDS. The results showed that by developing RDS, it has made possible to consolidate all relevant information in one single document. This is beneficial as it enables preservation of information, promotes quality assurance, allows traceability, facilitates continuous improvement, promotes solving of contradictions and finally assisting in developing thermal hydraulic input regardless of whichever code selected. However, some disadvantages were also recognized such as the need for experience in making engineering judgments, language barrier in accessing foreign information and limitation of resources. Some possible improvements are suggested to overcome these challenges.
NASA Technical Reports Server (NTRS)
Teverovsky, Alexander A.
2012-01-01
This document has been developed in the course of NASA Electronic Parts and Packaging (NEPP) program and is not an official endorsement of the insertion of commercial capacitors in space programs or an established set of requirements for their testing. The purpose of this document is to suggest possible ways for selection, screening, and qualification of commercial capacitors for NASA projects and open discussions in the parts engineering community related to the use of COTS ceramic capacitors. This guideline is applicable to commercial surface mount chip, simple parallel plate design, multi-layer ceramic capacitors (MLCCs) rated to voltages of 100V and less. Parts with different design, e.g. low inductance ceramic capacitors (LICA), land grid array (LGA) etc., might need additional testing and tailoring of the requirements described in this document. Although the focus of this document is on commercial MLCCs, many procedures discussed below would be beneficial for military-grade capacitors
25 CFR 559.7 - May a tribe submit documents required by this part electronically?
Code of Federal Regulations, 2013 CFR
2013-04-01
... 25 Indians 2 2013-04-01 2013-04-01 false May a tribe submit documents required by this part... NOTIFICATIONS AND SUBMISSIONS § 559.7 May a tribe submit documents required by this part electronically? Yes. Tribes wishing to submit documents electronically should contact the Commission for guidance on...
25 CFR 559.7 - May a tribe submit documents required by this part electronically?
Code of Federal Regulations, 2014 CFR
2014-04-01
... 25 Indians 2 2014-04-01 2014-04-01 false May a tribe submit documents required by this part... NOTIFICATIONS AND SUBMISSIONS § 559.7 May a tribe submit documents required by this part electronically? Yes. Tribes wishing to submit documents electronically should contact the Commission for guidance on...
42 CFR 102.53 - Documentation a survivor must submit to be deemed eligible by the Secretary.
Code of Federal Regulations, 2012 CFR
2012-10-01
... AND HUMAN SERVICES VACCINES SMALLPOX COMPENSATION PROGRAM Required Documentation To Be Deemed Eligible... documentation required in: (1) Section 102.51(a)(2)-(4) (documentation requirements for smallpox vaccine recipients), in the case of a deceased smallpox vaccine recipient. The survivor requester may submit a...
42 CFR 102.53 - Documentation a survivor must submit to be deemed eligible by the Secretary.
Code of Federal Regulations, 2014 CFR
2014-10-01
... AND HUMAN SERVICES VACCINES SMALLPOX COMPENSATION PROGRAM Required Documentation To Be Deemed Eligible... documentation required in: (1) Section 102.51(a)(2)-(4) (documentation requirements for smallpox vaccine recipients), in the case of a deceased smallpox vaccine recipient. The survivor requester may submit a...
42 CFR 102.53 - Documentation a survivor must submit to be deemed eligible by the Secretary.
Code of Federal Regulations, 2013 CFR
2013-10-01
... AND HUMAN SERVICES VACCINES SMALLPOX COMPENSATION PROGRAM Required Documentation To Be Deemed Eligible... documentation required in: (1) Section 102.51(a)(2)-(4) (documentation requirements for smallpox vaccine recipients), in the case of a deceased smallpox vaccine recipient. The survivor requester may submit a...
42 CFR 102.53 - Documentation a survivor must submit to be deemed eligible by the Secretary.
Code of Federal Regulations, 2011 CFR
2011-10-01
... AND HUMAN SERVICES VACCINES SMALLPOX COMPENSATION PROGRAM Required Documentation To Be Deemed Eligible... documentation required in: (1) Section 102.51(a)(2)-(4) (documentation requirements for smallpox vaccine recipients), in the case of a deceased smallpox vaccine recipient. The survivor requester may submit a...
42 CFR 102.53 - Documentation a survivor must submit to be deemed eligible by the Secretary.
Code of Federal Regulations, 2010 CFR
2010-10-01
... AND HUMAN SERVICES VACCINES SMALLPOX COMPENSATION PROGRAM Required Documentation To Be Deemed Eligible... documentation required in: (1) Section 102.51(a)(2)-(4) (documentation requirements for smallpox vaccine recipients), in the case of a deceased smallpox vaccine recipient. The survivor requester may submit a...
NASA Technical Reports Server (NTRS)
1977-01-01
Components of a videotape storage and retrieval system originally developed for NASA have been adapted as a tool for law enforcement agencies. Ampex Corp., Redwood City, Cal., built a unique system for NASA-Marshall. The first application of professional broadcast technology to computerized record-keeping, it incorporates new equipment for transporting tapes within the system. After completing the NASA system, Ampex continued development, primarily to improve image resolution. The resulting advanced system, known as the Ampex Videofile, offers advantages over microfilm for filing, storing, retrieving, and distributing large volumes of information. The system's computer stores information in digital code rather than in pictorial form. While microfilm allows visual storage of whole documents, it requires a step before usage--developing the film. With Videofile, the actual document is recorded, complete with photos and graphic material, and a picture of the document is available instantly.
Deterministic binary vectors for efficient automated indexing of MEDLINE/PubMed abstracts.
Wahle, Manuel; Widdows, Dominic; Herskovic, Jorge R; Bernstam, Elmer V; Cohen, Trevor
2012-01-01
The need to maintain accessibility of the biomedical literature has led to development of methods to assist human indexers by recommending index terms for newly encountered articles. Given the rapid expansion of this literature, it is essential that these methods be scalable. Document vector representations are commonly used for automated indexing, and Random Indexing (RI) provides the means to generate them efficiently. However, RI is difficult to implement in real-world indexing systems, as (1) efficient nearest-neighbor search requires retaining all document vectors in RAM, and (2) it is necessary to maintain a store of randomly generated term vectors to index future documents. Motivated by these concerns, this paper documents the development and evaluation of a deterministic binary variant of RI. The increased capacity demonstrated by binary vectors has implications for information retrieval, and the elimination of the need to retain term vectors facilitates distributed implementations, enhancing the scalability of RI.
Deterministic Binary Vectors for Efficient Automated Indexing of MEDLINE/PubMed Abstracts
Wahle, Manuel; Widdows, Dominic; Herskovic, Jorge R.; Bernstam, Elmer V.; Cohen, Trevor
2012-01-01
The need to maintain accessibility of the biomedical literature has led to development of methods to assist human indexers by recommending index terms for newly encountered articles. Given the rapid expansion of this literature, it is essential that these methods be scalable. Document vector representations are commonly used for automated indexing, and Random Indexing (RI) provides the means to generate them efficiently. However, RI is difficult to implement in real-world indexing systems, as (1) efficient nearest-neighbor search requires retaining all document vectors in RAM, and (2) it is necessary to maintain a store of randomly generated term vectors to index future documents. Motivated by these concerns, this paper documents the development and evaluation of a deterministic binary variant of RI. The increased capacity demonstrated by binary vectors has implications for information retrieval, and the elimination of the need to retain term vectors facilitates distributed implementations, enhancing the scalability of RI. PMID:23304369
DOE Office of Scientific and Technical Information (OSTI.GOV)
Izmaylov, Alexandr V.; Babkin, Vladimir; Kurov, Valeriy
2009-10-07
The development of new or the upgrade of existing physical protection systems (PPS) for nuclear facilities involves a multi-step and multidimensional process. The process consists of conceptual design, design, and commissioning stages. The activities associated with each of these stages are governed by Russian government and agency regulations. To ensure a uniform approach to development or upgrading of PPS at Russian nuclear facilities, the development of a range of regulatory and methodological documents is necessary. Some issues of PPS development are covered by the regulatory documents developed by Rosatom, as well as other Russian agencies with nuclear facilities under theirmore » control. This regulatory development has been accomplished as part of the U.S.-Russian MPC&A cooperation or independently by the Russian Federation. While regulatory coverage is extensive, there are a number of issues such as vulnerability analysis, effectiveness assessment, upgrading PPS, and protection of information systems for PPS that require additional regulations be developed. This paper reports on the status of regulatory coverage for PPS development or upgrade, and outlines a new approach to regulatory document development. It describes the evolutionary process of regulatory development through experience gained in the design, development and implementation of PPS as well as experience gained through the cooperative efforts of Russian and U.S. experts involved the development of MPC&A regulations.« less
The DACUM Job Analysis Process.
ERIC Educational Resources Information Center
Dofasco, Inc., Hamilton (Ontario).
This document explains the DACUM (Developing A Curriculum) process for analyzing task-based jobs to: identify where standard operating procedures are required; identify duplicated low value added tasks; develop performance standards; create job descriptions; and identify the elements that must be included in job-specific training programs. The…
STARPAHC space-oriented medical evaluation. [telemedicine system
NASA Technical Reports Server (NTRS)
1979-01-01
Development of the STARPAHC telemedicine system is documented. Using STARPAHC assessment results and monitoring experience, on board and ground based flight medical system monitoring requirements and operational procedures were developed for use with the Space Transportation System during OFT and mature operation phases of the shuttle.
NASA Technical Reports Server (NTRS)
Gallagher, Seana; Olson, Matt; Blythe, Doug; Heletz, Jacob; Hamilton, Griff; Kolb, Bill; Homans, Al; Zemrowski, Ken; Decker, Steve; Tegge, Cindy
2000-01-01
This document is the NASA AATT Task Order 24 Final Report. NASA Research Task Order 24 calls for the development of eleven distinct task reports. Each task was a necessary exercise in the development of comprehensive communications systems architecture (CSA) for air traffic management and aviation weather information dissemination for 2015, the definition of the interim architecture for 2007, and the transition plan to achieve the desired End State. The eleven tasks are summarized along with the associated Task Order reference. The output of each task was an individual task report. The task reports that make up the main body of this document include Task 5, Task 6, Task 7, Task 8, Task 10, and Task 11. The other tasks provide the supporting detail used in the development of the architecture. These reports are included in the appendices. The detailed user needs, functional communications requirements and engineering requirements associated with Tasks 1, 2, and 3 have been put into a relational database and are provided electronically.
20 CFR 627.455 - Reports required.
Code of Federal Regulations, 2010 CFR
2010-04-01
... outlays on an accrual basis. If the recipient's accounting records are not normally kept on the accrual basis, the recipient shall develop such accrual information through an analysis of the documentation on...
NASA Technical Reports Server (NTRS)
Hatterick, G. R.
1972-01-01
Activities are documented of the study to determine skills required of on-orbit crew personnel of the space shuttle. The material is presented in four sections that include: (1) methodology for identifying flight experiment task-skill requirements, (2) task-skill analysis of selected flight experiments, (3) study results and conclusions, and (4) new technology.
NASA Technical Reports Server (NTRS)
Eller, H. H.; Sugg, F. E.
1970-01-01
The methods and procedures used to perform nondestructive testing inspections of the Saturn S-2 liquid hydrogen and liquid oxygen tank weldments during fabrication and after proof testing are described to document special skills developed during the program. All post-test inspection requirements are outlined including radiographic inspections procedures.
ERIC Educational Resources Information Center
Usiewicz, Ronald A.
An investigation ascertained, analyzed, and documented competency standards and certification requirements for secondary-level vocational food service programs. A literature review produced no instruments used in past studies to measure the attitudes of food service professionals toward task competencies. Six occupations were selected for the…
48 CFR 752.7005 - Submission requirements for development experience documents.
Code of Federal Regulations, 2011 CFR
2011-10-01
..., technologies, management, research, results and experience as outlined in the Agency's ADS Chapter 540, section... paragraph (b)(1)(i) of this clause. (2) Format. (i) Descriptive information is required for all Contractor... descriptive information: (A) Name and version of the application software used to create the file, e.g., Word...
48 CFR 752.7005 - Submission requirements for development experience documents.
Code of Federal Regulations, 2012 CFR
2012-10-01
..., technologies, management, research, results and experience as outlined in the Agency's ADS Chapter 540, section... paragraph (b)(1)(i) of this clause. (2) Format. (i) Descriptive information is required for all Contractor... descriptive information: (A) Name and version of the application software used to create the file, e.g., Word...
48 CFR 752.7005 - Submission requirements for development experience documents.
Code of Federal Regulations, 2013 CFR
2013-10-01
..., technologies, management, research, results and experience as outlined in the Agency's ADS Chapter 540, section... paragraph (b)(1)(i) of this clause. (2) Format. (i) Descriptive information is required for all Contractor... descriptive information: (A) Name and version of the application software used to create the file, e.g., Word...
48 CFR 752.7005 - Submission requirements for development experience documents.
Code of Federal Regulations, 2014 CFR
2014-10-01
..., technologies, management, research, results and experience as outlined in the Agency's ADS Chapter 540, section... paragraph (b)(1)(i) of this clause. (2) Format. (i) Descriptive information is required for all Contractor... descriptive information: (A) Name and version of the application software used to create the file, e.g., Word...
48 CFR 752.7005 - Submission requirements for development experience documents.
Code of Federal Regulations, 2010 CFR
2010-10-01
..., technologies, management, research, results and experience as outlined in the Agency's ADS Chapter 540, section... paragraph (b)(1)(i) of this clause. (2) Format. (i) Descriptive information is required for all Contractor... descriptive information: (A) Name and version of the application software used to create the file, e.g., Word...
Federal Register 2010, 2011, 2012, 2013, 2014
2013-01-17
... requires the auditor additionally to obtain an understanding of the internal controls environment for the company, which requires the development of certain documentation, such as internal controls procedures... detailed understanding of the internal controls environment, a CPA review generally is less costly than a...
DOT National Transportation Integrated Search
1993-10-01
This document describes the Concept of Operations and Generic System Requirements for : the next generation of Traffic Management Centers (TMC). Four major steps comprise the : development of this Concept of Operations. The first step was to survey t...
DOT National Transportation Integrated Search
1996-12-01
The enclosed report provides information regarding the following: : (1)documentation requirements as prepared by the U.S. Coast Guard : for use in developing an ITOS, (2) performance requirements for : crew qualifications, tug performance capabilitie...
Interpretation of Radiological Images: Towards a Framework of Knowledge and Skills
ERIC Educational Resources Information Center
van der Gijp, A.; van der Schaaf, M. F.; van der Schaaf, I. C.; Huige, J. C. B. M.; Ravesloot, C. J.; van Schaik, J. P. J.; ten Cate, Th. J.
2014-01-01
The knowledge and skills that are required for radiological image interpretation are not well documented, even though medical imaging is gaining importance. This study aims to develop a comprehensive framework of knowledge and skills, required for two-dimensional and multiplanar image interpretation in radiology. A mixed-method study approach was…
DOT National Transportation Integrated Search
2015-08-01
This document is the fifth of a seven volume report that describe the Performance Requirements for the connected vehicle vehicle-to-infrastructure (V2I) safety applications developed for the U.S. Department of Transportation (U.S. DOT). This volume d...
DOT National Transportation Integrated Search
2015-08-01
This document is the sixth of a seven volume report that describe the Performance Requirements for the connected vehicle vehicle-to-infrastructure (V2I) safety applications developed for the U.S. Department of Transportation (U.S. DOT). This volume d...
DOT National Transportation Integrated Search
2015-08-01
This document is the fourth of a seven volume report that describe the Performance Requirements for the connected vehicle vehicle-to-infrastructure (V2I) safety applications developed for the U.S. Department of Transportation (U.S. DOT). This volume ...
Integrated information systems for electronic chemotherapy medication administration.
Levy, Mia A; Giuse, Dario A; Eck, Carol; Holder, Gwen; Lippard, Giles; Cartwright, Julia; Rudge, Nancy K
2011-07-01
Chemotherapy administration is a highly complex and distributed task in both the inpatient and outpatient infusion center settings. The American Society of Clinical Oncology and the Oncology Nursing Society (ASCO/ONS) have developed standards that specify procedures and documentation requirements for safe chemotherapy administration. Yet paper-based approaches to medication administration have several disadvantages and do not provide any decision support for patient safety checks. Electronic medication administration that includes bar coding technology may provide additional safety checks, enable consistent documentation structure, and have additional downstream benefits. We describe the specialized configuration of clinical informatics systems for electronic chemotherapy medication administration. The system integrates the patient registration system, the inpatient order entry system, the pharmacy information system, the nursing documentation system, and the electronic health record. We describe the process of deploying this infrastructure in the adult and pediatric inpatient oncology, hematology, and bone marrow transplant wards at Vanderbilt University Medical Center. We have successfully adapted the system for the oncology-specific documentation requirements detailed in the ASCO/ONS guidelines for chemotherapy administration. However, several limitations remain with regard to recording the day of treatment and dose number. Overall, the configured systems facilitate compliance with the ASCO/ONS guidelines and improve the consistency of documentation and multidisciplinary team communication. Our success has prompted us to deploy this infrastructure in our outpatient chemotherapy infusion centers, a process that is currently underway and that will require a few unique considerations.
Decal Process Document and Catalog
NASA Technical Reports Server (NTRS)
1999-01-01
The Decal Process Document and Catalog, JSC 27260 is the standard flight decal catalog, complete with illustrations and part numbers. As hardware developers identify labels that have common applicability across end items, these labels can be evaluated for "standard decal classification" and entered into the decal catalog for general use. The hardware developer must have a label design that meets current, applicable labeling requirements, and submit to the Decal Design and Production Facility (DDPF) as a standard label candidate. Upon approval, the label will be added to the decal catalog. The Decal Process Document and Catalog provides a selection of decals from which the NASA and NASA contractor customers can easily order. The decals shown in the catalog have been previously produced and have released engineering/fabrication drawings on file in the (DDPF). A released drawing is required before a decal can be produced or placed into the catalog. Some decals included in the catalog have a common applicability and are used in various NASA vehicles/habitats. It is the intent of the DDPF to maintain this catalog as a "living document" to which decals/placards can be added as they are repeatedly used. The advantage of identifYing flight decals in this catalog is that a released drawing is already in place, and the products will be flight certified.
The 30/20 GHz flight experiment system, phase 2. Volume 3: Experiment system requirement document
NASA Technical Reports Server (NTRS)
Bronstein, L.; Kawamoto, Y.; Ribarich, J. J.; Scope, J. R.; Forman, B. J.; Berman, S. G.; Reisenfeld, S.
1981-01-01
An approach to the requirements document to be used to procure the system by NASA is presented. The basic approach is similar to the requirements document used in the commercial communication satellite. Enough detail requirements are given to define the system without tight constraints.
A review of the FDA draft guidance document for software validation: guidance for industry.
Keatley, K L
1999-01-01
A Draft Guidance Document (Version 1.1) was issued by the United States Food and Drug Administration (FDA) to address the software validation requirement of the Quality System Regulation, 21 CFR Part 820, effective June 1, 1997. The guidance document outlines validation considerations that the FDA regards as applicable to both medical device software and software used to "design, develop or manufacture" medical devices. The Draft Guidance is available at the FDA web site http:@www.fda.gov/cdrh/comps/swareval++ +.html. Presented here is a review of the main features of the FDA document for Quality System Regulation (QSR), and some guidance for its implementation in industry.
Information Extraction for System-Software Safety Analysis: Calendar Year 2008 Year-End Report
NASA Technical Reports Server (NTRS)
Malin, Jane T.
2009-01-01
This annual report describes work to integrate a set of tools to support early model-based analysis of failures and hazards due to system-software interactions. The tools perform and assist analysts in the following tasks: 1) extract model parts from text for architecture and safety/hazard models; 2) combine the parts with library information to develop the models for visualization and analysis; 3) perform graph analysis and simulation to identify and evaluate possible paths from hazard sources to vulnerable entities and functions, in nominal and anomalous system-software configurations and scenarios; and 4) identify resulting candidate scenarios for software integration testing. There has been significant technical progress in model extraction from Orion program text sources, architecture model derivation (components and connections) and documentation of extraction sources. Models have been derived from Internal Interface Requirements Documents (IIRDs) and FMEA documents. Linguistic text processing is used to extract model parts and relationships, and the Aerospace Ontology also aids automated model development from the extracted information. Visualizations of these models assist analysts in requirements overview and in checking consistency and completeness.
Tank waste remediation system configuration management plan
DOE Office of Scientific and Technical Information (OSTI.GOV)
Vann, J.M.
The configuration management program for the Tank Waste Remediation System (TWRS) Project Mission supports management of the project baseline by providing the mechanisms to identify, document, and control the functional and physical characteristics of the products. This document is one of the tools used to develop and control the mission and work. It is an integrated approach for control of technical, cost, schedule, and administrative information necessary to manage the configurations for the TWRS Project Mission. Configuration management focuses on five principal activities: configuration management system management, configuration identification, configuration status accounting, change control, and configuration management assessments. TWRS Projectmore » personnel must execute work in a controlled fashion. Work must be performed by verbatim use of authorized and released technical information and documentation. Application of configuration management will be consistently applied across all TWRS Project activities and assessed accordingly. The Project Hanford Management Contract (PHMC) configuration management requirements are prescribed in HNF-MP-013, Configuration Management Plan (FDH 1997a). This TWRS Configuration Management Plan (CMP) implements those requirements and supersedes the Tank Waste Remediation System Configuration Management Program Plan described in Vann, 1996. HNF-SD-WM-CM-014, Tank Waste Remediation System Configuration Management Implementation Plan (Vann, 1997) will be revised to implement the requirements of this plan. This plan provides the responsibilities, actions and tools necessary to implement the requirements as defined in the above referenced documents.« less
Human Research Program Requirements Document (Revision C)
NASA Technical Reports Server (NTRS)
Vargas, Paul R.
2009-01-01
The purpose of this document is to define, document, and allocate the Human Research Program (HRP) requirements to the HRP Program Elements. It establishes the flow-down of requirements from Exploration Systems Mission Directorate (ESMD) and Office of the Chief Health and Medical Officer (OCHMO) to the various Program Elements of the HRP to ensure that human research and technology countermeasure investments are made to insure the delivery of countermeasures and technologies that satisfy ESMD's and OCHMO's exploration mission requirements. Requirements driving the HRP work and deliverables are derived from the exploration architecture, as well as Agency standards regarding the maintenance of human health and performance. Agency human health and performance standards will define acceptable risk for each type and duration of exploration mission. It is critical to have the best available scientific and clinical evidence in setting and validating these standards. In addition, it is imperative that the best available evidence on preventing and mitigating human health and performance risks is incorporated into exploration mission and vehicle designs. These elements form the basis of the HRP research and technology development requirements and highlight the importance of HRP investments in enabling NASA's exploration missions. This PRD defines the requirements of the HRP which is comprised of the following major Program Elements: Behavioral Health and Performance (BHP), Exploration Medical Capability (ExMC), Human Health Countermeasures (HHC), ISS Medical Project (ISSMP), Space Human Factors and Habitability (SHFH), and Space Radiation (SR).
Overview of Energy Systems' safety analysis report programs
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1992-03-01
The primary purpose of an Safety Analysis Report (SAR) is to provide a basis for judging the adequacy of a facility's safety. The SAR documents the safety analyses that systematically identify the hazards posed by the facility, analyze the consequences and risk of potential accidents, and describe hazard control measures that protect the health and safety of the public and employees. In addition, some SARs document, as Technical Safety Requirements (TSRs, which include Technical Specifications and Operational Safety Requirements), technical and administrative requirements that ensure the facility is operated within prescribed safety limits. SARs also provide conveniently summarized information thatmore » may be used to support procedure development, training, inspections, and other activities necessary to facility operation. This Overview of Energy Systems Safety Analysis Report Programs'' Provides an introduction to the programs and processes used in the development and maintenance of the SARs. It also summarizes some of the uses of the SARs within Energy Systems and DOE.« less
Overview of Energy Systems` safety analysis report programs. Safety Analysis Report Update Program
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1992-03-01
The primary purpose of an Safety Analysis Report (SAR) is to provide a basis for judging the adequacy of a facility`s safety. The SAR documents the safety analyses that systematically identify the hazards posed by the facility, analyze the consequences and risk of potential accidents, and describe hazard control measures that protect the health and safety of the public and employees. In addition, some SARs document, as Technical Safety Requirements (TSRs, which include Technical Specifications and Operational Safety Requirements), technical and administrative requirements that ensure the facility is operated within prescribed safety limits. SARs also provide conveniently summarized information thatmore » may be used to support procedure development, training, inspections, and other activities necessary to facility operation. This ``Overview of Energy Systems Safety Analysis Report Programs`` Provides an introduction to the programs and processes used in the development and maintenance of the SARs. It also summarizes some of the uses of the SARs within Energy Systems and DOE.« less
Fluor Daniel Hanford contract standards/requirements identification document
DOE Office of Scientific and Technical Information (OSTI.GOV)
Bennett, G.L.
1997-04-24
This document, the Standards/Requirements Identification Document (S/RID) for the Fluor Daniel Hanford Contract, represents the necessary and sufficient requirements to provide an adequate level of protection of the worker, public health and safety, and the environment.
IDC Re-Engineering Phase 2 System Specification Document Version 1.5
DOE Office of Scientific and Technical Information (OSTI.GOV)
Satpathi, Meara Allena; Burns, John F.; Harris, James M.
This document contains the system specifications derived to satisfy the system requirements found in the IDC System Requirements Document for the IDC Re-Engineering Phase 2 project. This System Specification Document (SSD) defines waveform data processing requirements for the International Data Centre (IDC) of the Comprehensive Nuclear Test Ban Treaty Organization (CTBTO). The routine processing includes characterization of events with the objective of screening out events considered to be consistent with natural phenomena or non-nuclear, man-made phenomena. This document does not address requirements concerning acquisition, processing and analysis of radionuclide data but does include requirements for the dissemination of radionuclide datamore » and products.« less
Using SCR methods to analyze requirements documentation
NASA Technical Reports Server (NTRS)
Callahan, John; Morrison, Jeffery
1995-01-01
Software Cost Reduction (SCR) methods are being utilized to analyze and verify selected parts of NASA's EOS-DIS Core System (ECS) requirements documentation. SCR is being used as a spot-inspection tool. Through this formal and systematic approach of the SCR requirements methods, insights as to whether the requirements are internally inconsistent or incomplete as the scenarios of intended usage evolve in the OC (Operations Concept) documentation. Thus, by modelling the scenarios and requirements as mode charts using the SCR methods, we have been able to identify problems within and between the documents.
24 CFR 107.25 - Provisions in legal instruments.
Code of Federal Regulations, 2012 CFR
2012-04-01
... 24 Housing and Urban Development 1 2012-04-01 2012-04-01 false Provisions in legal instruments. 107.25 Section 107.25 Housing and Urban Development Regulations Relating to Housing and Urban... Provisions in legal instruments. (a) The following documents shall contain provisions or statements requiring...
24 CFR 107.25 - Provisions in legal instruments.
Code of Federal Regulations, 2010 CFR
2010-04-01
... 24 Housing and Urban Development 1 2010-04-01 2010-04-01 false Provisions in legal instruments. 107.25 Section 107.25 Housing and Urban Development Regulations Relating to Housing and Urban... Provisions in legal instruments. (a) The following documents shall contain provisions or statements requiring...
Federal Register 2010, 2011, 2012, 2013, 2014
2010-12-09
... DEPARTMENT OF THE INTERIOR Bureau of Ocean Energy Management, Regulation and Enforcement [Docket... for Exploration Plans, Development and Production Plans, and Development Operations Coordination Documents on the OCS NTL, Renewal of a Collection; Submitted for Office of Management and Budget (OMB...
Students' Developing Understanding of Water in Environmental Systems
ERIC Educational Resources Information Center
Covitt, Beth A.; Gunckel, Kristin L.; Anderson, Charles W.
2009-01-01
The authors developed a framework of empirically grounded curricular goals for water-science literacy and documented the challenges that students face in achieving these goals. Water-related environmental science literacy requires an understanding of connected natural and human-engineered systems at multiple scales ranging from atomic-molecular…
DOE Office of Scientific and Technical Information (OSTI.GOV)
Burchard, Ross L.; Pierson, Kathleen P.; Trumbo, Derek
Tarjetas is used to generate requirements from source documents. These source documents are in a hierarchical XML format that have been produced from PDF documents processed through the “Reframe” software package. The software includes the ability to create Topics and associate text Snippets with those topics. Requirements are then generated and text Snippets with their associated Topics are referenced to the requirement. The software maintains traceability from the requirement ultimately to the source document that produced the snippet
Getter, James; D'Erchia, Terry D.; Root, Ralph; Getter, James; D'Erchia, Terry D.; Root, Ralph
1999-01-01
The format for this 3-day workshop (27-29 October 1998) included plenary presentations by USGS Biological Resources Division (BRD) and U.S. Fish and Wildlife Service per onnel who u e and develop decision support systems (DSS); breakout ses ions addressing DSS technical information aspect , outreach/ customer requirements, and future perspectives; and a DSS Steering Committee meeting to evaluate work hop goals and to provide guidance for fu ture efforts. Steering committee action item developed from workshop inputs were to ( I) develop a "DSS framework" document for u e in biological research. (2) develop a "proof of concept" DSS based upon the framework document, and (3) integrate decision support ystem into BRD program elements.
18 CFR 5.24 - Applications not requiring a draft NEPA document.
Code of Federal Regulations, 2013 CFR
2013-04-01
... requiring a draft NEPA document. 5.24 Section 5.24 Conservation of Power and Water Resources FEDERAL ENERGY... APPLICATION PROCESS § 5.24 Applications not requiring a draft NEPA document. (a) If the Commission determines... environmental impact statement and that a draft environmental assessment will not be required, the Commission...
18 CFR 5.24 - Applications not requiring a draft NEPA document.
Code of Federal Regulations, 2012 CFR
2012-04-01
... requiring a draft NEPA document. 5.24 Section 5.24 Conservation of Power and Water Resources FEDERAL ENERGY... APPLICATION PROCESS § 5.24 Applications not requiring a draft NEPA document. (a) If the Commission determines... environmental impact statement and that a draft environmental assessment will not be required, the Commission...
18 CFR 5.24 - Applications not requiring a draft NEPA document.
Code of Federal Regulations, 2014 CFR
2014-04-01
... requiring a draft NEPA document. 5.24 Section 5.24 Conservation of Power and Water Resources FEDERAL ENERGY... APPLICATION PROCESS § 5.24 Applications not requiring a draft NEPA document. (a) If the Commission determines... environmental impact statement and that a draft environmental assessment will not be required, the Commission...
12 CFR 16.17 - Filing requirements and inspection of documents.
Code of Federal Regulations, 2010 CFR
2010-01-01
... the submission of any fee required under § 16.33 of this part. (e) Any filing of amendments or... 12 Banks and Banking 1 2010-01-01 2010-01-01 false Filing requirements and inspection of documents... SECURITIES OFFERING DISCLOSURE RULES § 16.17 Filing requirements and inspection of documents. (a) Except as...
Documenting Models for Interoperability and Reusability (proceedings)
Many modeling frameworks compartmentalize science via individual models that link sets of small components to create larger modeling workflows. Developing integrated watershed models increasingly requires coupling multidisciplinary, independent models, as well as collaboration be...
Documenting Models for Interoperability and Reusability
Many modeling frameworks compartmentalize science via individual models that link sets of small components to create larger modeling workflows. Developing integrated watershed models increasingly requires coupling multidisciplinary, independent models, as well as collaboration be...
78 FR 78967 - Agency Information Collection Activities: Proposed Collection; Comment Request
Federal Register 2010, 2011, 2012, 2013, 2014
2013-12-27
... Regulatory Affairs, Division of Regulations Development, Attention: Document Identifier/OMB Control Number... State Medicaid Programs; Use: In accordance with the Deficit Act of 2005, states are required to provide...
75 FR 15434 - Agency Information Collection Activities: Proposed Collection; Comment Request
Federal Register 2010, 2011, 2012, 2013, 2014
2010-03-29
... beneficiaries. The Deficit Reduction Act (DRA) of 2005 modified section 1927 to require additional reporting... Regulations Development, Attention: Document Identifier/OMB Control Number, Room C4-26-05, 7500 Security...
The Empirical Investigation of Perspective-Based Reading
NASA Technical Reports Server (NTRS)
Basili, Victor R.; Green, Scott; Laitenberger, Oliver; Shull, Forrest; Sorumgard, Sivert; Zelkowitz, Marvin V.
1996-01-01
We consider reading techniques a fundamental means of achieving high quality software. Due to the lack of research in this area, we are experimenting with the application and comparison of various reading techniques. This paper deals with our experiences with Perspective-Based Reading (PBR), a particular reading technique for requirements documents. The goal of PBR is to provide operational scenarios where members of a review team read a document from a particular perspective (e.g., tester, developer, user). Our assumption is that the combination of different perspectives provides better coverage of the document than the same number of readers using their usual technique.
TRACER - TRACING AND CONTROL OF ENGINEERING REQUIREMENTS
NASA Technical Reports Server (NTRS)
Turner, P. R.
1994-01-01
TRACER (Tracing and Control of Engineering Requirements) is a database/word processing system created to document and maintain the order of both requirements and descriptive material associated with an engineering project. A set of hierarchical documents are normally generated for a project whereby the requirements of the higher level documents levy requirements on the same level or lower level documents. Traditionally, the requirements are handled almost entirely by manual paper methods. The problem with a typical paper system, however, is that requirements written and changed continuously in different areas lead to misunderstandings and noncompliance. The purpose of TRACER is to automate the capture, tracing, reviewing, and managing of requirements for an engineering project. The engineering project still requires communications, negotiations, interactions, and iterations among people and organizations, but TRACER promotes succinct and precise identification and treatment of real requirements separate from the descriptive prose in a document. TRACER permits the documentation of an engineering project's requirements and progress in a logical, controllable, traceable manner. TRACER's attributes include the presentation of current requirements and status from any linked computer terminal and the ability to differentiate headers and descriptive material from the requirements. Related requirements can be linked and traced. The program also enables portions of documents to be printed, individual approval and release of requirements, and the tracing of requirements down into the equipment specification. Requirement "links" can be made "pending" and invisible to others until the pending link is made "binding". Individuals affected by linked requirements can be notified of significant changes with acknowledgement of the changes required. An unlimited number of documents can be created for a project and an ASCII import feature permits existing documents to be incorporated. TRACER can automatically renumber section headers when inserting or deleting sections of a document and generate sign-off forms for any approval process as well as a table of contents. TRACER was implemented on an IBM PC under PC-DOS. The program requires 640K RAM, a hard disk, and PC-DOS version 3.3 or higher. It was written in CLIPPER (Summer '87). TRACER is available on two 5.25 inch 1.2Mb MS-DOS format diskettes. The executable program is also provided with the distribution. TRACER is a copyrighted work with all copyright vested in the National Aeronautics and Space Administration. IBM PC and PC-DOS are registered trademarks of International Business Machines. CLIPPER is a trademark of Nantucket Corporation.
Environmental health discipline science plan
NASA Technical Reports Server (NTRS)
1991-01-01
The purpose of this plan is to provide a conceptual strategy for NASA's Life Sciences Division research and development activities in environmental health. It covers the significant research areas critical to NASA's programmatic requirements for the Extended Duration Orbiter, Space Station Freedom, and exploration mission science activities. These science activities include ground-based and flight; basic, applied, and operational; animal and human subjects; and research and development. This document summarizes the history and current status of the program elements, outlines available knowledge, establishes goals and objectives, identifies scientific priorities, and defines critical questions in the three disciplines: (1) Barophysiology, (2) Toxicology, and (3) Microbiology. This document contains a general plan that will be used by both NASA Headquarters Program Officers and the field centers to review and plan basic, applied, and operational research and development activities, both intramural and extramural, in this area. The document is divided into sections addressing these three disciplines.
Development and evaluation of nursing user interface screens using multiple methods.
Hyun, Sookyung; Johnson, Stephen B; Stetson, Peter D; Bakken, Suzanne
2009-12-01
Building upon the foundation of the Structured Narrative Electronic Health Record (EHR) model, we applied theory-based (combined Technology Acceptance Model and Task-Technology Fit Model) and user-centered methods to explore nurses' perceptions of functional requirements for an electronic nursing documentation system, design user interface screens reflective of the nurses' perspectives, and assess nurses' perceptions of the usability of the prototype user interface screens. The methods resulted in user interface screens that were perceived to be easy to use, potentially useful, and well-matched to nursing documentation tasks associated with Nursing Admission Assessment, Blood Administration, and Nursing Discharge Summary. The methods applied in this research may serve as a guide for others wishing to implement user-centered processes to develop or extend EHR systems. In addition, some of the insights obtained in this study may be informative to the development of safe and efficient user interface screens for nursing document templates in EHRs.
Spieler, Bernadette; Burgsteiner, Harald; Messer-Misak, Karin; Gödl-Purrer, Barbara; Salchinger, Beate
2015-01-01
Findings in physiotherapy have standardized approaches in treatment, but there is also a significant margin of differences in how to implement these standards. Clinical decisions require experience and continuous learning processes to consolidate personal values and opinions and studies suggest that lecturers can influence students positively. Recently, the study course of Physiotherapy at the University of Applied Science in Graz has offered a paper based finding document. This document supported decisions through the adaption of the clinical reasoning process. The document was the starting point for our learning application called "EasyAssess", a Java based web-application for a digital findings documentation. A central point of our work was to ensure efficiency, effectiveness and usability of the web-application through usability tests utilized by both students and lecturers. Results show that our application fulfills the previously defined requirements and can be efficiently used in daily routine largely because of its simple user interface and its modest design. Due to the close cooperation with the study course Physiotherapy, the application has incorporated the various needs of the target audiences and confirmed the usefulness of our application.
Implementation of a School-wide Clinical Intervention Documentation System
Stevenson, T. Lynn; Fox, Brent I.; Andrus, Miranda; Carroll, Dana
2011-01-01
Objective. To evaluate the effectiveness and impact of a customized Web-based software program implemented in 2006 for school-wide documentation of clinical interventions by pharmacy practice faculty members, pharmacy residents, and student pharmacists. Methods. The implementation process, directed by a committee of faculty members and school administrators, included preparation and refinement of the software, user training, development of forms and reports, and integration of the documentation process within the curriculum. Results. Use of the documentation tool consistently increased from May 2007 to December 2010. Over 187,000 interventions were documented with over $6.2 million in associated cost avoidance. Conclusions. Successful implementation of a school-wide documentation tool required considerable time from the oversight committee and a comprehensive training program for all users, with ongoing monitoring of data collection practices. Data collected proved to be useful to show the impact of faculty members, residents, and student pharmacists at affiliated training sites. PMID:21829264
7 CFR 1423.6 - Financial information documentation requirements.
Code of Federal Regulations, 2010 CFR
2010-01-01
... CORPORATION APPROVED WAREHOUSES § 1423.6 Financial information documentation requirements. To be approved under this part, a warehouse operator shall submit a current financial statement at the time of... 7 Agriculture 10 2010-01-01 2010-01-01 false Financial information documentation requirements...
TWRS configuration management requirement source document
DOE Office of Scientific and Technical Information (OSTI.GOV)
Vann, J.M.
The TWRS Configuration Management (CM) Requirement Source document prescribes CM as a basic product life-cycle function by which work and activities are conducted or accomplished. This document serves as the requirements basis for the TWRS CM program. The objective of the TWRS CM program is to establish consistency among requirements, physical/functional configuration, information, and documentation for TWRS and TWRS products, and to maintain this consistency throughout the life-cycle of TWRS and the product, particularly as changes are being made.
NASA Technical Reports Server (NTRS)
Zelkin, Natalie; Henriksen, Stephen
2010-01-01
This NASA Contractor Report summarizes and documents the work performed to develop concepts of use (ConUse) and high-level system requirements and architecture for the proposed L-band (960 to 1164 MHz) terrestrial en route communications system. This work was completed as a follow-on to the technology assessment conducted by NASA Glenn Research Center and ITT for the Future Communications Study (FCS). ITT assessed air-to-ground (A/G) communications concepts of use and operations presented in relevant NAS-level, international, and NAS-system-level documents to derive the appropriate ConUse relevant to potential A/G communications applications and services for domestic continental airspace. ITT also leveraged prior concepts of use developed during the earlier phases of the FCS. A middle-out functional architecture was adopted by merging the functional system requirements identified in the bottom-up assessment of existing requirements with those derived as a result of the top-down analysis of ConUse and higher level functional requirements. Initial end-to-end system performance requirements were derived to define system capabilities based on the functional requirements and on NAS-SR-1000 and the Operational Performance Assessment conducted as part of the COCR. A high-level notional architecture of the L-DACS supporting A/G communication was derived from the functional architecture and requirements.
Parabolic Dish Solar Thermal Power Annual Program Review Proceedings
NASA Technical Reports Server (NTRS)
Lucas, J. W.
1982-01-01
The results of activities of the parabolic dish technology and applications development element of DOE's Solar Thermal Energy System Program are presented. Topics include the development and testing of concentrators, receivers, and power conversion units; system design and development for engineering experiments; economic analysis and marketing assessment; and advanced development activities. A panel discussion concerning industrial support sector requirements is also documented.
Distributed EDLSI, BM25, and Power Norm at TREC 2008
2008-11-01
LSI would work on the IIT Complex Document Information Processing (IIT CDIP ) test collection, which contains approximately 7 million documents (57 GB...requirements, specifically the memory, for EDLSI are reduced over LSI, they are still significant, especially for a corpus the size of IIT CDIP . After...data, for training purposes. Initially we ran the 2006 and 2007 queries against the IIT CDIP corpus and developed a pseudo submis- sion file containing
Legal considerations for document delivery services.
Bunting, A
1994-04-01
Health sciences libraries that provide fee-based information services must consider and develop policies and procedures for complying with legal requirements. This paper reviews the provisions of copyright law that pertain to document delivery, including two court decisions concerning copyright. Also discussed are recent actions by publishers to reinforce their view of libraries' responsibilities for royalty fees for articles copied and their use of licenses to impose additional restrictions on the use of and reproduction of materials.
Utilizing IHE-based Electronic Health Record systems for secondary use.
Holzer, K; Gall, W
2011-01-01
Due to the increasing adoption of Electronic Health Records (EHRs) for primary use, the number of electronic documents stored in such systems will soar in the near future. In order to benefit from this development in secondary fields such as medical research, it is important to define requirements for the secondary use of EHR data. Furthermore, analyses of the extent to which an IHE (Integrating the Healthcare Enterprise)-based architecture would fulfill these requirements could provide further information on upcoming obstacles for the secondary use of EHRs. A catalog of eight core requirements for secondary use of EHR data was deduced from the published literature, the risk analysis of the IHE profile MPQ (Multi-Patient Queries) and the analysis of relevant questions. The IHE-based architecture for cross-domain, patient-centered document sharing was extended to a cross-patient architecture. We propose an IHE-based architecture for cross-patient and cross-domain secondary use of EHR data. Evaluation of this architecture concerning the eight core requirements revealed positive fulfillment of six and the partial fulfillment of two requirements. Although not regarded as a primary goal in modern electronic healthcare, the re-use of existing electronic medical documents in EHRs for research and other fields of secondary application holds enormous potential for the future. Further research in this respect is necessary.
Overview of the Design, Development, and Application of Nickel-hydrogen Batteries
NASA Technical Reports Server (NTRS)
Thaller, Lawrence H.; Zimmerman, Albert H.
2003-01-01
This document provides an overview of the design, development, and application of nickel-hydrogen (Ni-H2) battery technology for aerospace applications. It complements and updates the information presented in NASA RP-1314, NASA Handbook for Nickel- Hydrogen Batteries, published in 1993. Since that time, nickel-hydrogen batteries have become widely accepted for aerospace energy storage requirements and much more has been learned. The intent of this document is to capture some of that additional knowledge. This document addresses various aspects of nickel-hydrogen technology including the electrochemical reactions, cell component design, and selection considerations; overall cell and battery design considerations; charge control considerations; and manufacturing issues that have surfaced over the years that nickel-hydrogen battery technology has been the major energy storage technology for geosynchronous and low-Earth-orbiting satellites.
NASA Technical Reports Server (NTRS)
Lowrie, J. W.; Fermelia, A. J.; Haley, D. C.; Gremban, K. D.; Vanbaalen, J.; Walsh, R. W.
1982-01-01
Documentation of the preliminary software developed as a framework for a generalized integrated robotic system simulation is presented. The program structure is composed of three major functions controlled by a program executive. The three major functions are: system definition, analysis tools, and post processing. The system definition function handles user input of system parameters and definition of the manipulator configuration. The analysis tools function handles the computational requirements of the program. The post processing function allows for more detailed study of the results of analysis tool function executions. Also documented is the manipulator joint model software to be used as the basis of the manipulator simulation which will be part of the analysis tools capability.
NASA Technical Reports Server (NTRS)
1972-01-01
The specifications for the performance, design, development, and test requirements of the P2-156, S3-156, and S6-120 space shuttle booster solid rocket motors are presented. The applicable documents which form a part of the specifications are listed.
Individual Development Plans as Governance Tools--Changed Governance of Teachers' Work
ERIC Educational Resources Information Center
Parding, Karolina; Liljegren, Andreas
2017-01-01
Auditing, accountability, and transparency are concepts that greatly impact the working conditions of today's public sector professionals, including teachers. Documentation requirements have been on the increase for some time, which can be seen in the education sector's Individual Development Plans (IDPs), for example. These IDPs are pedagogical…
Sex Equity: Recruitment and Retention of Non-Traditional Students.
ERIC Educational Resources Information Center
Mewhorter, V. Carolyn
This document contains the materials required to present two courses that were developed during a project to increase the recruitment/retention of women in technical education programs. Presented first is Developing Mechanical/Electrical Aptitude, a 30-hour course to improve students' (primarily women's) mechanical and electrical aptitude and…
Designing a Standard Model for Development and Execution of an Analysis Project Plan
2012-06-01
mitigations set forth are agreeable to all parties involved. 1.3 Document Risks, Issues, and Constraints 1.1 Gather Information 1.2 Develop...parent requirement into lower level objective, performance-based sibling actions. Collective accomplishment of the set of derived “ sibling ” actions
Federal Register 2010, 2011, 2012, 2013, 2014
2013-07-22
... leadership skill building, exposure to ethical and value based issues, self-awareness, strategic thinking... development, communication, feedback, Type Theory, emotional intelligence, self awareness and group dynamics... Requirements: Documents or other media that are produced under this award must follow these guidelines: Prior...
25 CFR 162.528 - What documents are required for BIA approval of a WEEL?
Code of Federal Regulations, 2013 CFR
2013-04-01
... LEASES AND PERMITS Wind and Solar Resource Leases Weel Approval § 162.528 What documents are required for... required by § 162.527; (d) Statement from the appropriate tribal authority that the proposed use is in... environmental and land use requirements, including any documentation prepared under § 162.027(b); (f) An...
25 CFR 162.528 - What documents are required for BIA approval of a WEEL?
Code of Federal Regulations, 2014 CFR
2014-04-01
... LEASES AND PERMITS Wind and Solar Resource Leases Weel Approval § 162.528 What documents are required for... required by § 162.527; (d) Statement from the appropriate tribal authority that the proposed use is in... environmental and land use requirements, including any documentation prepared under § 162.027(b); (f) An...
36 CFR 1251.10 - What are the filing requirements for a demand for documents or testimony?
Code of Federal Regulations, 2011 CFR
2011-07-01
... date that records or testimony is required. Demands submitted in less than 45 days before records or... requirements for a demand for documents or testimony? 1251.10 Section 1251.10 Parks, Forests, and Public... the filing requirements for a demand for documents or testimony? You must comply with the following...
36 CFR 1251.10 - What are the filing requirements for a demand for documents or testimony?
Code of Federal Regulations, 2010 CFR
2010-07-01
... date that records or testimony is required. Demands submitted in less than 45 days before records or... requirements for a demand for documents or testimony? 1251.10 Section 1251.10 Parks, Forests, and Public... the filing requirements for a demand for documents or testimony? You must comply with the following...
A proposed USAF fatigue evaluation program based upon recent systems experience
NASA Technical Reports Server (NTRS)
Haviland, G. P.; Purkey, G. F.
1972-01-01
The United States Air Force has published a document entitled Aircraft Structural Integrity Program. One phase of the program is concerned with the fatigue life certification of all types of military aircraft. The document describes the criteria, analyses, and tests that are necessary in order to satisfy the USAF fatigue life requirement. Some recent and valid criticism has been directed toward the document, particularly the fatigue-life requirements contained in it. Some changes are proposed based on surveys conducted in the United States and abroad as well as some recent systems' experience. The surveys covered both military and civilian organizations. The fatigue certification case histories of selected military and commercial aircraft are presented. The design development element tests, preproduction design verification tests, and full-scale fatigue tests of each are described. A brief status report on the revisions to the MIL-A-008860 series specifications is included.
Space station systems analysis study. Part 3: Documentation. Volume 1: Executive summary
NASA Technical Reports Server (NTRS)
1977-01-01
The space stations systems analysis study is summarized. A cost efffective system concept capable of meeting a broad spectrum of mission requirements was developed. Candidate objectives were reviewed and implementation requirements were defined. Program options for both low earth and geosynchronous orbits were examined. Space construction concepts were analyzed and defined in detail.
2014-01-01
the executable SRM is developed according to the specification and marketing documents. Hence, for example, the Vehicles, Car, and Truck classes in...transitions ternary relation: transitions ⊆ states x transitionIDs x states, such as <"Init", "Tr1", " stP "> • A conditions unary relation bound to
Computerized Adaptive Testing Project: Objectives and Requirements.
1982-07-01
developing a cqmputerlzed adaptive lwfb system ( CAT ). SiN 0102- LP. Old. "O AM"- S/M "of F.g~ smuuim ftmAYUSN 0 IM ~ A joint-service coordinated effort is In...progress to develop a computerized adaptive testing ( CAT ) system and to evaluate its potential for use in the Military Enlistment Processing Stations...lead laboratory for this effort. This report is intended to serve as a working paper documenting CAT system functional requirements and schedules. It
DOE Office of Scientific and Technical Information (OSTI.GOV)
Washington TRU Solutions, LLC
The purpose of this program guidance document is to provide technical requirements for use, operation, inspection, and maintenance of the RH-TRU 72-B Waste Shipping Package and directly related components. This document complies with the requirements as specified in the RH-TRU 72-B Safety Analysis Report for Packaging (SARP), and Nuclear Regulatory Commission (NRC) Certificate of Compliance (C of C) 9212. If there is a conflict between this document and the SARP and/or C of C, the SARP and/or C of C shall govern. The C of C states: ''...each package must be prepared for shipment and operated in accordance with themore » procedures described in Chapter 7.0, ''Operating Procedures,'' of the application.'' It further states: ''...each package must be tested and maintained in accordance with the procedures described in Chapter 8.0, ''Acceptance Tests and Maintenance Program of the Application.'' Chapter 9.0 of the SARP tasks the Waste Isolation Pilot Plant (WIPP) Management and Operating (M&O) contractor with assuring the packaging is used in accordance with the requirements of the C of C. Because the packaging is NRC approved, users need to be familiar with 10 CFR {section} 71.11, ''Deliberate Misconduct.'' Any time a user suspects or has indications that the conditions of approval in the C of C were not met, the Carlsbad Field Office (CBFO) shall be notified immediately. CBFO will evaluate the issue and notify the NRC if required. This document details the instructions to be followed to operate, maintain, and test the RH-TRU 72-B packaging. This Program Guidance standardizes instructions for all users. Users shall follow these instructions. Following these instructions assures that operations are safe and meet the requirements of the SARP. This document is available on the Internet at: ttp://www.ws/library/t2omi/t2omi.htm. Users are responsible for ensuring they are using the current revision and change notices. Sites may prepare their own document using the word-for-word steps in th is document, in sequence, including Notes and cautions. Site specific information may be included as necessary. The document, and revisions, must then be submitted to CBFO at sitedocuments@wipp.ws for approval. A copy of the approval letter from CBFO shall be available for audit purposes. Users may develop site-specific procedures addressing preoperational activities, quality assurance (QA), hoisting and rigging, and radiation health physics to be used with the instructions contained in this document. Users may recommend changes to this document by submitting their recommendations (in writing) to the WIPP M&O Contractor RH Packaging Maintenance Engineer for evaluation. If approved, the change(s) will be incorporated into this document for use by ALL users. Before first use and every 12 months after, user sites will be audited to this document to ensure compliance. They will also be audited within one year from the effective date of revisions to this document.« less
optical, and structural integrity of the full scale ASTEC solar collector before further development proceeds. This document specifies these initial...engineering ground tests recommended for testing petals and other critical components of the ASTEC collector. It defines the requirements and
7 CFR 1710.405 - Supplemental financing documents.
Code of Federal Regulations, 2010 CFR
2010-01-01
... 7 Agriculture 11 2010-01-01 2010-01-01 false Supplemental financing documents. 1710.405 Section... GUARANTEES Application Requirements and Procedures for Loans § 1710.405 Supplemental financing documents. (a) The borrower is responsible for ensuring that the loan documents required for supplemental financing...
Imaged document information location and extraction using an optical correlator
NASA Astrophysics Data System (ADS)
Stalcup, Bruce W.; Dennis, Phillip W.; Dydyk, Robert B.
1999-12-01
Today, the paper document is fast becoming a thing of the past. With the rapid development of fast, inexpensive computing and storage devices, many government and private organizations are archiving their documents in electronic form (e.g., personnel records, medical records, patents, etc.). Many of these organizations are converting their paper archives to electronic images, which are then stored in a computer database. Because of this, there is a need to efficiently organize this data into comprehensive and accessible information resources and provide for rapid access to the information contained within these imaged documents. To meet this need, Litton PRC and Litton Data Systems Division are developing a system, the Imaged Document Optical Correlation and Conversion System (IDOCCS), to provide a total solution to the problem of managing and retrieving textual and graphic information from imaged document archives. At the heart of IDOCCS, optical correlation technology provide a means for the search and retrieval of information from imaged documents. IDOCCS can be used to rapidly search for key words or phrases within the imaged document archives and has the potential to determine the types of languages contained within a document. In addition, IDOCCS can automatically compare an input document with the archived database to determine if it is a duplicate, thereby reducing the overall resources required to maintain and access the document database. Embedded graphics on imaged pages can also be exploited, e.g., imaged documents containing an agency's seal or logo can be singled out. In this paper, we present a description of IDOCCS as well as preliminary performance results and theoretical projections.
The Empirical Investigation of Perspective-Based Reading
NASA Technical Reports Server (NTRS)
Basili, Victor R.; Green, Scott; Laitenberger, Oliver; Shull, Forrest; Sorumgard, Sivert; Zelkowitz, Marvin V.
1995-01-01
We consider reading techniques a fundamental means of achieving high quality software. Due to lack of research in this area, we are experimenting with the application and comparison of various reading techniques. This paper deals with our experiences with Perspective Based Reading (PBR) a particular reading technique for requirement documents. The goal of PBR is to provide operation scenarios where members of a review team read a document from a particular perspective (eg., tester, developer, user). Our assumption is that the combination of different perspective provides better coverage of the document than the same number of readers using their usual technique. To test the efficacy of PBR, we conducted two runs of a controlled experiment in the environment of NASA GSFC Software Engineering Laboratory (SEL), using developers from the environment. The subjects read two types of documents, one generic in nature and the other from the NASA Domain, using two reading techniques, PBR and their usual technique. The results from these experiment as well as the experimental design, are presented and analyzed. When there is a statistically significant distinction, PBR performs better than the subjects' usual technique. However, PBR appears to be more effective on the generic documents than on the NASA documents.
Reliability program requirements for aeronautical and space system contractors
NASA Technical Reports Server (NTRS)
1987-01-01
General reliability program requirements for NASA contracts involving the design, development, fabrication, test, and/or use of aeronautical and space systems including critical ground support equipment are prescribed. The reliability program requirements require (1) thorough planning and effective management of the reliability effort; (2) definition of the major reliability tasks and their place as an integral part of the design and development process; (3) planning and evaluating the reliability of the system and its elements (including effects of software interfaces) through a program of analysis, review, and test; and (4) timely status indication by formal documentation and other reporting to facilitate control of the reliability program.
Update on US EPA's Revision to the 1985 Guidelines for ...
National Water Quality Criteria for the Protection of Aquatic Organisms and Their Uses (Stephan et al. 1985), to reflect the current state-of-the-science for aquatic effects assessments. Following a 2015 public meeting soliciting early input from the scientific community, EPA decided to undertake two overarching parallel tracks for this revision: 1) updating and refining methods for deriving state-of-the-science criteria through comprehensive analyses, and 2) developing criteria more rapidly for the broader protection of aquatic life from the potential adverse effects of the large number of chemicals released into the aquatic environment. The first track reflects that for a smaller group of chemicals, criteria development may be scientifically complex, and deriving robust criteria for these chemicals may require detailed investigation. The second track reflects the recognition that extensive testing of all chemicals is infeasible and there is a need to efficiently derive criteria using approaches that estimate safe environmental concentrations with limited empirical data. Based on these objectives, EPA will develop two criteria documents for this revision: 1) a Comprehensive Guidelines Document, intended to directly update and expand upon approaches presented in the 1985 Guidelines, and that will describe methods that provide criteria for chemicals requiring a more detailed level of evaluation, and 2) an Expedited Guidelines Document, which will focus on criteri
Draft Plan to Develop Non-Intrusive Load Monitoring Test Protocols
DOE Office of Scientific and Technical Information (OSTI.GOV)
Mayhorn, Ebony T.; Sullivan, Greg P.; Petersen, Joseph M.
2015-09-29
This document presents a Draft Plan proposed to develop a common test protocol that can be used to evaluate the performance requirements of Non-Intrusive Load Monitoring. Development on the test protocol will be focused on providing a consistent method that can be used to quantify and compare the performance characteristics of NILM products. Elements of the protocols include specifications for appliances to be used, metrics, instrumentation, and a procedure to simulate appliance behavior during tests. In addition, three priority use cases for NILM will be identified and their performance requirements will specified.
Detailed requirements document for the integrated structural analysis system, phase B
NASA Technical Reports Server (NTRS)
Rainey, J. A.
1976-01-01
The requirements are defined for a software system entitled integrated Structural Analysis System (ISAS) Phase B which is being developed to provide the user with a tool by which a complete and detailed analysis of a complex structural system can be performed. This software system will allow for automated interface with numerous structural analysis batch programs and for user interaction in the creation, selection, and validation of data. This system will include modifications to the 4 functions developed for ISAS, and the development of 25 new functions. The new functions are described.
Federal Register 2010, 2011, 2012, 2013, 2014
2013-02-27
... of total applicants who require English translations of their supporting documents. The percentage of supporting documents for each individual applicant that require translation into English. The time required to find, hire or otherwise obtain translations of supporting documents for immigration benefit...
Development of Innovative Design Processor
DOE Office of Scientific and Technical Information (OSTI.GOV)
Park, Y.S.; Park, C.O.
2004-07-01
The nuclear design analysis requires time-consuming and erroneous model-input preparation, code run, output analysis and quality assurance process. To reduce human effort and improve design quality and productivity, Innovative Design Processor (IDP) is being developed. Two basic principles of IDP are the document-oriented design and the web-based design. The document-oriented design is that, if the designer writes a design document called active document and feeds it to a special program, the final document with complete analysis, table and plots is made automatically. The active documents can be written with ordinary HTML editors or created automatically on the web, which ismore » another framework of IDP. Using the proper mix-up of server side and client side programming under the LAMP (Linux/Apache/MySQL/PHP) environment, the design process on the web is modeled as a design wizard style so that even a novice designer makes the design document easily. This automation using the IDP is now being implemented for all the reload design of Korea Standard Nuclear Power Plant (KSNP) type PWRs. The introduction of this process will allow large reduction in all reload design efforts of KSNP and provide a platform for design and R and D tasks of KNFC. (authors)« less
75 FR 22162 - Draft NIJ Duty Holster Retention Standard for Law Enforcement
Federal Register 2010, 2011, 2012, 2013, 2014
2010-04-27
...In an effort to obtain comments from interested parties, the U.S. Department of Justice, Office of Justice Programs, National Institute of Justice will make available to the general public two draft documents: (1) A draft standard entitled, ``NIJ Duty Holster Retention Standard for Law Enforcement'' and (2) a draft companion document entitled, ``NIJ Duty Holster Retention Certification Program Requirements.'' The opportunity to provide comments on these two documents is open to industry technical representatives, law enforcement agencies and organizations, research, development and scientific communities, and all other stakeholders and interested parties. Those individuals wishing to obtain and provide comments on the draft documents under consideration are directed to the following Web site: http://www.justnet.org.
Documentation requirements for Applications Systems Verification and Transfer projects (ASVTs)
NASA Technical Reports Server (NTRS)
Suchy, J. T.
1977-01-01
NASA's Application Systems Verification and Transfer Projects (ASVTs) are deliberate efforts to facilitate the transfer of applications of NASA-developed space technology to users such as federal agencies, state and local governments, regional planning groups, public service institutions, and private industry. This study focused on the role of documentation in facilitating technology transfer both to primary users identified during project planning and to others with similar information needs. It was understood that documentation can be used effectively when it is combined with informal (primarily verbal) communication within each user community and with other formal techniques such as organized demonstrations and training programs. Documentation examples from eight ASVT projects and one potential project were examined to give scope to the investigation.
23 CFR 1340.5 - Documentation requirements.
Code of Federal Regulations, 2010 CFR
2010-04-01
... STATE OBSERVATIONAL SURVEYS OF SEAT BELT USE § 1340.5 Documentation requirements. All sample design, data collection, and estimation procedures used in State surveys conducted in accordance with this part must be well documented. At a minimum, the documentation must: (a) For sample design— (1) Define all...
23 CFR 1340.5 - Documentation requirements.
Code of Federal Regulations, 2011 CFR
2011-04-01
... STATE OBSERVATIONAL SURVEYS OF SEAT BELT USE § 1340.5 Documentation requirements. All sample design, data collection, and estimation procedures used in State surveys conducted in accordance with this part must be well documented. At a minimum, the documentation must: (a) For sample design— (1) Define all...
Ayuela Azcárate, J M; Clau-Terré, F; Vicho Pereira, R; Guerrero de Mier, M; Carrillo López, A; Ochagavia, A; López Pérez, J M; Trenado Alvarez, J; Pérez, L; Llompart-Pou, J A; González de Molina, F J; Fojón, S; Rodríguez Salgado, A; Martínez Díaz, M C; Royo Villa, C; Romero Bermejo, F J; Ruíz Bailén, M; Arroyo Díez, M; Argueso García, M; Fernández Fernández, J L
2014-01-01
Ultrasound has become an essential tool in assisting critically ill patients. His knowledge, use and instruction requires a statement by scientific societies involved in its development and implementation. Our aim are to determine the use of the technique in intensive care medicine, clinical situations where its application is recommended, levels of knowledge, associated responsibility and learning process also implement the ultrasound technique as a common tool in all intensive care units, similar to the rest of european countries. The SEMICYUC's Working Group Cardiac Intensive Care and CPR establishes after literature review and scientific evidence, a consensus document which sets out the requirements for accreditation in ultrasound applied to the critically ill patient and how to acquire the necessary skills. Training and learning requires a structured process within the specialty. The SEMICYUC must agree to disclose this document, build relationships with other scientific societies and give legal cover through accreditation of the training units, training courses and different levels of training. Copyright © 2013 Elsevier España, S.L. y SEMICYUC. All rights reserved.
[The REACH legislation: the consumer and environment protection perspective].
Gundert-Remy, Ursula
2008-12-01
REACH has been initiated with the aim of improving existing legislation. In order to assist in the interpretation of the REACH legislation, guidance documents have been developed, which have only lately become available. According to the REACH annexes and supported by guidance documents, waiving of test requirements will be possible, thus, opening the possibility that under REACH no new (eco)toxicological data will be required. Concerning products, a guidance document was released in April 2008 stating that the substance concentration threshold of 0.1 % (w/w) applies to the article as produced or imported and it does not relate to the homogeneous materials or parts of an article, but relates to the article as such (i.e., as produced or imported). Hence, notification will not be required for many products containing chemicals with properties which place them on the candidate list for authorization. In summary, it is at present not foreseeable whether the expected benefit of the REACH legislation will materialise for the environment and for the health of consumers and at the work place.
DARHT: INTEGRATION OF AUTHORIZATION BASIS REQUIREMENTS AND WORKER SAFETY
DOE Office of Scientific and Technical Information (OSTI.GOV)
D. A. MC CLURE; C. A. NELSON; R. L. BOUDRIE
2001-04-01
This document describes the results of consensus agreements reached by the DARHT Safety Planning Team during the development of the update of the DARHT Safety Analysis Document (SAD). The SAD is one of the Authorization Basis (AB) Documents required by the Department prior to granting approval to operate the DARHT Facility. The DARHT Safety Planning Team is lead by Mr. Joel A. Baca of the Department of Energy Albuquerque Operations Office (DOE/AL). Team membership is drawn from the Department of Energy Albuquerque Operations Office, the Department of Energy Los Alamos Area Office (DOE/LAAO), and several divisions of the Los Alamosmore » National Laboratory. Revision 1 of the DARHT SAD had been written as part of the process for gaining approval to operate the Phase 1 (First Axis) Accelerator. Early in the planning stage for the required update of the SAD for the approval to operate both Phase 1 and Phase 2 (First Axis and Second Axis) DARHT Accelerator, it was discovered that a conflict existed between the Laboratory approach to describing the management of facility and worker safety.« less
DOE Office of Scientific and Technical Information (OSTI.GOV)
Vargo, G.F. Jr.
1994-10-11
The DOE Standard defines the configuration management program by the five basic program elements of ``program management,`` ``design requirements,`` ``document control,`` ``change control,`` and ``assessments,`` and the two adjunct recovery programs of ``design reconstitution,`` and ``material condition and aging management. The C-M model of five elements and two adjunct programs strengthen the necessary technical and administrative control to establish and maintain a consistent technical relationship among the requirements, physical configuration, and documentation. Although the DOE Standard was originally developed for the operational phase of nuclear facilities, this plan has the flexibility to be adapted and applied to all life-cycle phasesmore » of both nuclear and non-nuclear facilities. The configuration management criteria presented in this plan endorses the DOE Standard and has been tailored specifically to address the technical relationship of requirements, physical configuration, and documentation during the full life-cycle of the 101-SY Hydrogen Mitigation Test Project Mini-Data Acquisition and Control System of Tank Waste Remediation System.« less
Simulant Basis for the Standard High Solids Vessel Design
DOE Office of Scientific and Technical Information (OSTI.GOV)
Peterson, Reid A.; Fiskum, Sandra K.; Suffield, Sarah R.
The Waste Treatment and Immobilization Plant (WTP) is working to develop a Standard High Solids Vessel Design (SHSVD) process vessel. To support testing of this new design, WTP engineering staff requested that a Newtonian simulant and a non-Newtonian simulant be developed that would represent the Most Adverse Design Conditions (in development) with respect to mixing performance as specified by WTP. The majority of the simulant requirements are specified in 24590-PTF-RPT-PE-16-001, Rev. 0. The first step in this process is to develop the basis for these simulants. This document describes the basis for the properties of these two simulant types. Themore » simulant recipes that meet this basis will be provided in a subsequent document.« less
Shuttle unified navigation filter, revision 1
NASA Technical Reports Server (NTRS)
Muller, E. S., Jr.
1973-01-01
Equations designed to meet the navigation requirements of the separate shuttle mission phases are presented in a series of reports entitled, Space Shuttle GN and C Equation Document. The development of these equations is based on performance studies carried out for each particular mission phase. Although navigation equations have been documented separately for each mission phase, a single unified navigation filter design is embodied in these separate designs. The purpose of this document is to present the shuttle navigation equations in a form in which they would most likely be coded-as the single unified navigation filter used in each mission phase. This document will then serve as a single general reference for the navigation equations replacing each of the individual mission phase navigation documents (which may still be used as a description of a particular navigation phase).
Spaceflight Human System Standards
NASA Technical Reports Server (NTRS)
Holubec, Keith; Tillman, Barry; Connolly, Jan
2009-01-01
NASA created a new approach for human system integration and human performance standards. NASA created two documents a standard and a reference handbook. The standard is titled NASA Space Flight Human-System Standard (SFHSS) and consists of two-volumes: Volume 1- Crew Health This volume covers standards needed to support astronaut health (medical care, nutrition, sleep, exercise, etc.) Volume 2 Human Factors, Habitability and Environmental Health This volume covers the standards for system design that will maintain astronaut performance (ie., environmental factors, design of facilities, layout of workstations, and lighting requirements). It includes classic human factors requirements. The new standards document is written in terms so that it is applicable to a broad range of present and future NASA systems. The document states that all new programs prepare system-specific requirements that will meet the general standards. For example, the new standard does not specify a design should accommodate specific percentiles of a defined population. Rather, NASA-STD-3001, Volume 2 states that all programs shall prepare program-specific requirements that define the user population and their size ranges. The design shall then accommodate the full size range of those users. The companion reference handbook, Human Integration Design Handbook (HIDH), was developed to capture the design consideration information from NASA-STD-3000, and adds spaceflight lessons learned, gaps in knowledge, example solutions, and suggests research to further mature specific disciplines. The HIDH serves two major purposes: HIDH is the reference document for writing human factors requirements for specific systems. HIDH contains design guidance information that helps insure that designers create systems which safely and effectively accommodate the capabilities and limitations of space flight crews.
Monitored Geologic Repository Project Description Document
DOE Office of Scientific and Technical Information (OSTI.GOV)
P. M. Curry
2001-01-30
The primary objective of the Monitored Geologic Repository Project Description Document (PDD) is to allocate the functions, requirements, and assumptions to the systems at Level 5 of the Civilian Radioactive Waste Management System (CRWMS) architecture identified in Section 4. It provides traceability of the requirements to those contained in Section 3 of the ''Monitored Geologic Repository Requirements Document'' (MGR RD) (YMP 2000a) and other higher-level requirements documents. In addition, the PDD allocates design related assumptions to work products of non-design organizations. The document provides Monitored Geologic Repository (MGR) technical requirements in support of design and performance assessment in preparing formore » the Site Recommendation (SR) and License Application (LA) milestones. The technical requirements documented in the PDD are to be captured in the System Description Documents (SDDs) which address each of the systems at Level 5 of the CRWMS architecture. The design engineers obtain the technical requirements from the SDDs and by reference from the SDDs to the PDD. The design organizations and other organizations will obtain design related assumptions directly from the PDD. These organizations may establish additional assumptions for their individual activities, but such assumptions are not to conflict with the assumptions in the PDD. The PDD will serve as the primary link between the technical requirements captured in the SDDs and the design requirements captured in US Department of Energy (DOE) documents. The approved PDD is placed under Level 3 baseline control by the CRWMS Management and Operating Contractor (M and O) and the following portions of the PDD constitute the Technical Design Baseline for the MGR: the design characteristics listed in Table 1-1, the MGR Architecture (Section 4.1), the Technical Requirements (Section 5), and the Controlled Project Assumptions (Section 6).« less
Science-based requirements and operations development for the Maunakea Spectroscopic Explorer
NASA Astrophysics Data System (ADS)
McConnachie, Alan W.; Flagey, Nicolas; Murowinski, Rick; Szeto, Kei; Salmon, Derrick; Withington, Kanoa; Mignot, Shan
2016-07-01
MSE is a wide field telescope (1.5 square degree field of view) with an aperture of 11.25m. It is dedicated to multi-object spectroscopy at several different spectral resolutions in the range R 2500 - 40000 over a broad wavelength range (0:36 - 1:8μm). MSE enables transformational science in areas as diverse as exoplanetary host characterization; stellar monitoring campaigns; tomographic mapping of the interstellar and intergalactic media; the in-situ chemical tagging of the distant Galaxy; connecting galaxies to the large scale structure of the Universe; measuring the mass functions of cold dark matter sub-halos in galaxy and cluster-scale hosts; reverberation mapping of supermassive black holes in quasars. Here, we summarize the Observatory and describe the development of the top level science requirements and operational concepts. Specifically, we describe the definition of the Science Requirements to be the set of capabilities that allow certain high impact science programs to be conducted. We cross reference these science cases to the science requirements to illustrate the traceability of this approach. We further discuss the operations model for MSE and describe the development of the Operations Concept Document, one of the foundational documents for the project. We also discuss the next stage in the science based development of MSE, specifically the development of the initial Legacy Survey that will occupy a majority of time on the telescope over the first few years of operation.
Aging management program of the reactor building concrete at Point Lepreau Generating Station
NASA Astrophysics Data System (ADS)
Aldea, C.-M.; Shenton, B.; Demerchant, M. M.; Gendron, T.
2011-04-01
In order for New Brunswick Power Nuclear (NBPN) to control the risks of degradation of the concrete reactor building at the Point Lepreau Generating Station (PLGS) the development of an aging management plan (AMP) was initiated. The intention of this plan was to determine the requirements for specific structural components of concrete of the reactor building that require regular inspection and maintenance to ensure the safe and reliable operation of the plant. The document is currently in draft form and presents an integrated methodology for the application of an AMP for the concrete of the reactor building. The current AMP addresses the reactor building structure and various components, such as joint sealant and liners that are integral to the structure. It does not include internal components housed within the structure. This paper provides background information regarding the document developed and the strategy developed to manage potential degradation of the concrete of the reactor building, as well as specific programs and preventive and corrective maintenance activities initiated.
NASA Technical Reports Server (NTRS)
Mcgreevy, Michael W.
1990-01-01
An advanced human-system interface is being developed for evolutionary Space Station Freedom as part of the NASA Office of Space Station (OSS) Advanced Development Program. The human-system interface is based on body-pointed display and control devices. The project will identify and document the design accommodations ('hooks and scars') required to support virtual workstations and telepresence interfaces, and prototype interface systems will be built, evaluated, and refined. The project is a joint enterprise of Marquette University, Astronautics Corporation of America (ACA), and NASA's ARC. The project team is working with NASA's JSC and McDonnell Douglas Astronautics Company (the Work Package contractor) to ensure that the project is consistent with space station user requirements and program constraints. Documentation describing design accommodations and tradeoffs will be provided to OSS, JSC, and McDonnell Douglas, and prototype interface devices will be delivered to ARC and JSC. ACA intends to commercialize derivatives of the interface for use with computer systems developed for scientific visualization and system simulation.
NASA Astrophysics Data System (ADS)
Pascoe, Charlotte; Lawrence, Bryan; Moine, Marie-Pierre; Ford, Rupert; Devine, Gerry
2010-05-01
The EU METAFOR Project (http://metaforclimate.eu) has created a web-based model documentation questionnaire to collect metadata from the modelling groups that are running simulations in support of the Coupled Model Intercomparison Project - 5 (CMIP5). The CMIP5 model documentation questionnaire will retrieve information about the details of the models used, how the simulations were carried out, how the simulations conformed to the CMIP5 experiment requirements and details of the hardware used to perform the simulations. The metadata collected by the CMIP5 questionnaire will allow CMIP5 data to be compared in a scientifically meaningful way. This paper describes the life-cycle of the CMIP5 questionnaire development which starts with relatively unstructured input from domain specialists and ends with formal XML documents that comply with the METAFOR Common Information Model (CIM). Each development step is associated with a specific tool. (1) Mind maps are used to capture information requirements from domain experts and build a controlled vocabulary, (2) a python parser processes the XML files generated by the mind maps, (3) Django (python) is used to generate the dynamic structure and content of the web based questionnaire from processed xml and the METAFOR CIM, (4) Python parsers ensure that information entered into the CMIP5 questionnaire is output as CIM compliant xml, (5) CIM compliant output allows automatic information capture tools to harvest questionnaire content into databases such as the Earth System Grid (ESG) metadata catalogue. This paper will focus on how Django (python) and XML input files are used to generate the structure and content of the CMIP5 questionnaire. It will also address how the choice of development tools listed above provided a framework that enabled working scientists (who we would never ordinarily get to interact with UML and XML) to be part the iterative development process and ensure that the CMIP5 model documentation questionnaire reflects what scientists want to know about the models. Keywords: metadata, CMIP5, automatic information capture, tool development
Models of unit operations used for solid-waste processing
DOE Office of Scientific and Technical Information (OSTI.GOV)
Savage, G.M.; Glaub, J.C.; Diaz, L.F.
1984-09-01
This report documents the unit operations models that have been developed for typical refuse-derived-fuel (RDF) processing systems. These models, which represent the mass balances, energy requirements, and economics of the unit operations, are derived, where possible, from basic principles. Empiricism has been invoked where a governing theory has yet to be developed. Field test data and manufacturers' information, where available, supplement the analytical development of the models. A literature review has also been included for the purpose of compiling and discussing in one document the available information pertaining to the modeling of front-end unit operations. Separate analytics have been donemore » for each task.« less
Launch Deployment Assembly Extravehicular Activity Neutral Buoyancy Development Test Report
NASA Technical Reports Server (NTRS)
Loughead, T.
1996-01-01
This test evaluated the Launch Deployment Assembly (LDA) design for Extravehicular Activity (EVA) work sites (setup, igress, egress), reach and visual access, and translation required for cargo item removal. As part of the LDA design, this document describes the method and results of the LDA EVA Neutral Buoyancy Development Test to ensure that the LDA hardware support the deployment of the cargo items from the pallet. This document includes the test objectives, flight and mockup hardware description, descriptions of procedures and data collection used in the testing, and the results of the development test at the National Aeronautics and Space Administrations (NASA) Marshall Space Flight Center (MSFC) Neutral Buoyancy Simulator (NBS).
A planning support system to optimize approval of private housing development projects
NASA Astrophysics Data System (ADS)
Hussnain, M. Q.; Wakil, K.; Waheed, A.; Tahir, A.
2016-06-01
Out of 182 million population of Pakistan, 38% reside in urban areas having an average growth rate of 1.6%, raising the urban housing demand significantly. Poor state response to fulfil the housing needs has resulted in a mushroom growth of private housing schemes (PHS) over the years. Consequently, only in five major cities of Punjab, there are 383 legal and 150 illegal private housing development projects against 120 public sector housing schemes. A major factor behind the cancerous growth of unapproved PHS is the prolonged and delayed approval process in concerned approval authorities requiring 13 months on average. Currently, manual and paper-based approaches are used for vetting and for granting the permission which is highly subjective and non-transparent. This study aims to design a flexible planning support system (PSS) to optimize the vetting process of PHS projects under any development authority in Pakistan by reducing time and cost required for site and documents investigations. Relying on the review of regulatory documents and interviews with professional planners and land developers, this study describes the structure of a PSS developed using open- source geo-spatial tools such as OpenGeo Suite, PHP, and PostgreSQL. It highlights the development of a Knowledge Module (based on regulatory documents) containing equations related to scheme type, size (area), location, access road, components of layout plan, planning standards and other related approval checks. Furthermore, it presents the architecture of the database module and system data requirements categorized as base datasets (built-in part of PSS) and input datasets (related to the housing project under approval). It is practically demonstrated that developing a customized PSS to optimize PHS approval process in Pakistan is achievable with geospatial technology. With the provision of such a system, the approval process for private housing schemes not only becomes quicker and user-friendly but also transparent.
MARC ES: a computer program for estimating medical information storage requirements.
Konoske, P J; Dobbins, R W; Gauker, E D
1998-01-01
During combat, documentation of medical treatment information is critical for maintaining continuity of patient care. However, knowledge of prior status and treatment of patients is limited to the information noted on a paper field medical card. The Multi-technology Automated Reader Card (MARC), a smart card, has been identified as a potential storage mechanism for casualty medical information. Focusing on data capture and storage technology, this effort developed a Windows program, MARC ES, to estimate storage requirements for the MARC. The program calculates storage requirements for a variety of scenarios using medical documentation requirements, casualty rates, and casualty flows and provides the user with a tool to estimate the space required to store medical data at each echelon of care for selected operational theaters. The program can also be used to identify the point at which data must be uploaded from the MARC if size constraints are imposed. Furthermore, this model can be readily extended to other systems that store or transmit medical information.
Integrated Information Systems for Electronic Chemotherapy Medication Administration
Levy, Mia A.; Giuse, Dario A.; Eck, Carol; Holder, Gwen; Lippard, Giles; Cartwright, Julia; Rudge, Nancy K.
2011-01-01
Introduction: Chemotherapy administration is a highly complex and distributed task in both the inpatient and outpatient infusion center settings. The American Society of Clinical Oncology and the Oncology Nursing Society (ASCO/ONS) have developed standards that specify procedures and documentation requirements for safe chemotherapy administration. Yet paper-based approaches to medication administration have several disadvantages and do not provide any decision support for patient safety checks. Electronic medication administration that includes bar coding technology may provide additional safety checks, enable consistent documentation structure, and have additional downstream benefits. Methods: We describe the specialized configuration of clinical informatics systems for electronic chemotherapy medication administration. The system integrates the patient registration system, the inpatient order entry system, the pharmacy information system, the nursing documentation system, and the electronic health record. Results: We describe the process of deploying this infrastructure in the adult and pediatric inpatient oncology, hematology, and bone marrow transplant wards at Vanderbilt University Medical Center. We have successfully adapted the system for the oncology-specific documentation requirements detailed in the ASCO/ONS guidelines for chemotherapy administration. However, several limitations remain with regard to recording the day of treatment and dose number. Conclusion: Overall, the configured systems facilitate compliance with the ASCO/ONS guidelines and improve the consistency of documentation and multidisciplinary team communication. Our success has prompted us to deploy this infrastructure in our outpatient chemotherapy infusion centers, a process that is currently underway and that will require a few unique considerations. PMID:22043185
76 FR 5537 - Electronic On-Board Recorders and Hours of Service Supporting Documents
Federal Register 2010, 2011, 2012, 2013, 2014
2011-02-01
...The Federal Motor Carrier Safety Administration (FMCSA) proposes to amend the Federal Motor Carrier Safety Regulations (FMCSRs) to require certain motor carriers operating commercial motor vehicles (CMVs) in interstate commerce to use electronic on-board recorders (EOBRs) to document their drivers' hours of service (HOS). Under this proposal, all motor carriers currently required to maintain Records of Duty Status (RODS) for HOS recordkeeping would be required to use EOBRs to systematically and effectively monitor their drivers' compliance with HOS requirements. Additionally, this proposal sets forth the supporting documents that all motor carriers currently required to use RODS would still be required to obtain and keep, as required by section 113(a) of the Hazardous Materials Transportation Authorization Act (HMTAA). It explains, however, that although motor carriers subject to the proposed EOBR requirements would still need to retain some supporting documents, they would be relieved of the requirements to retain supporting documents to verify driving time. FMCSA also proposes to require all motor carriers--both RODS and timecard users--to systematically monitor their drivers' compliance with HOS requirements. Motor carriers would be given 3 years after the effective date of the final rule to comply with these requirements.
Federal Register 2010, 2011, 2012, 2013, 2014
2013-07-08
... applicants who require English translations of their supporting documents. The percentage of supporting documents for each individual applicant that require translation into English. The time required to find, hire, or otherwise obtain translations of supporting documents for immigration benefit requests. The...
19 CFR 122.157 - Documents required for clearance.
Code of Federal Regulations, 2010 CFR
2010-04-01
... 19 Customs Duties 1 2010-04-01 2010-04-01 false Documents required for clearance. 122.157 Section 122.157 Customs Duties U.S. CUSTOMS AND BORDER PROTECTION, DEPARTMENT OF HOMELAND SECURITY; DEPARTMENT OF THE TREASURY AIR COMMERCE REGULATIONS Flights to and From Cuba § 122.157 Documents required for...
7 CFR 1488.8 - Documents required after delivery.
Code of Federal Regulations, 2014 CFR
2014-01-01
... Financing of Export Sales of Agricultural Commodities From Private Stocks Under CCC Export Credit Sales Program (GSM-5) Documents Required for Financing § 1488.8 Documents required after delivery. (a) CCC will... regulations within forty-five days, or any extension thereof by the Treasurer or Assistant Treasurer, CCC...
7 CFR 1488.8 - Documents required after delivery.
Code of Federal Regulations, 2012 CFR
2012-01-01
... Financing of Export Sales of Agricultural Commodities From Private Stocks Under CCC Export Credit Sales Program (GSM-5) Documents Required for Financing § 1488.8 Documents required after delivery. (a) CCC will... regulations within forty-five days, or any extension thereof by the Treasurer or Assistant Treasurer, CCC...
7 CFR 1488.8 - Documents required after delivery.
Code of Federal Regulations, 2013 CFR
2013-01-01
... Financing of Export Sales of Agricultural Commodities From Private Stocks Under CCC Export Credit Sales Program (GSM-5) Documents Required for Financing § 1488.8 Documents required after delivery. (a) CCC will... regulations within forty-five days, or any extension thereof by the Treasurer or Assistant Treasurer, CCC...
Functions & Requirements for Debris Removal System Project A-2
DOE Office of Scientific and Technical Information (OSTI.GOV)
PRECECHTEL, D.R.
1999-12-29
This revision of the Functions and Requirements Document updates the approved Functions and Requirements for Debris Removal Subproject WHC-SD-SNF-FRD-009, Rev. 0. It has been revised in its entirety to reflect the current scope of work for Debris Removal as canisters and lids under the K Basin Projects work breakdown structure (WBS). In this revision the canisters and lids will be consider debris and a new set of Functions and Requirements have been developed to remove the canisters and lids from the basin.
Exploration Planetary Surface Structural Systems: Design Requirements and Compliance
NASA Technical Reports Server (NTRS)
Dorsey, John T.
2011-01-01
The Lunar Surface Systems Project developed system concepts that would be necessary to establish and maintain a permanent human presence on the Lunar surface. A variety of specific system implementations were generated as a part of the scenarios, some level of system definition was completed, and masses estimated for each system. Because the architecture studies generally spawned a large number of system concepts and the studies were executed in a short amount of time, the resulting system definitions had very low design fidelity. This paper describes the development sequence required to field a particular structural system: 1) Define Requirements, 2) Develop the Design and 3) Demonstrate Compliance of the Design to all Requirements. This paper also outlines and describes in detail the information and data that are required to establish structural design requirements and outlines the information that would comprise a planetary surface system Structures Requirements document.
Software archeology: a case study in software quality assurance and design
DOE Office of Scientific and Technical Information (OSTI.GOV)
Macdonald, John M; Lloyd, Jane A; Turner, Cameron J
2009-01-01
Ideally, quality is designed into software, just as quality is designed into hardware. However, when dealing with legacy systems, demonstrating that the software meets required quality standards may be difficult to achieve. As the need to demonstrate the quality of existing software was recognized at Los Alamos National Laboratory (LANL), an effort was initiated to uncover and demonstrate that legacy software met the required quality standards. This effort led to the development of a reverse engineering approach referred to as software archaeology. This paper documents the software archaeology approaches used at LANL to document legacy software systems. A case studymore » for the Robotic Integrated Packaging System (RIPS) software is included.« less
Requirements and design aspects of a data model for a data dictionary in paediatric oncology.
Merzweiler, A; Knaup, P; Creutzig, U; Ehlerding, H; Haux, R; Mludek, V; Schilling, F H; Weber, R; Wiedemann, T
2000-01-01
German children suffering from cancer are mostly treated within the framework of multicentre clinical trials. An important task of conducting these trials is an extensive information and knowledge exchange, which has to be based on a standardised documentation. To support this effort, it is the aim of a nationwide project to define a standardised terminology that should be used by clinical trials for therapy documentation. In order to support terminology maintenance we are currently developing a data dictionary. In this paper we describe requirements and design aspects of the data model used for the data dictionary as first results of our research. We compare it with other terminology systems.
Geospatial database for heritage building conservation
NASA Astrophysics Data System (ADS)
Basir, W. N. F. W. A.; Setan, H.; Majid, Z.; Chong, A.
2014-02-01
Heritage buildings are icons from the past that exist in present time. Through heritage architecture, we can learn about economic issues and social activities of the past. Nowadays, heritage buildings are under threat from natural disaster, uncertain weather, pollution and others. In order to preserve this heritage for the future generation, recording and documenting of heritage buildings are required. With the development of information system and data collection technique, it is possible to create a 3D digital model. This 3D information plays an important role in recording and documenting heritage buildings. 3D modeling and virtual reality techniques have demonstrated the ability to visualize the real world in 3D. It can provide a better platform for communication and understanding of heritage building. Combining 3D modelling with technology of Geographic Information System (GIS) will create a database that can make various analyses about spatial data in the form of a 3D model. Objectives of this research are to determine the reliability of Terrestrial Laser Scanning (TLS) technique for data acquisition of heritage building and to develop a geospatial database for heritage building conservation purposes. The result from data acquisition will become a guideline for 3D model development. This 3D model will be exported to the GIS format in order to develop a database for heritage building conservation. In this database, requirements for heritage building conservation process are included. Through this research, a proper database for storing and documenting of the heritage building conservation data will be developed.
Unique strategies for technical information management at Johnson Space Center
NASA Technical Reports Server (NTRS)
Krishen, Vijay
1994-01-01
In addition to the current NASA manned programs, the maturation of Space Station and the introduction of the Space Exploration programs are anticipated to add substantially to the number and variety of data and documentation at NASA Johnson Space Center (JSC). This growth in the next decade has been estimated at five to ten fold compared to the current numbers. There will be an increased requirement for the tracking and currency of space program data and documents with National pressures to realize economic benefits from the research and technological developments of space programs. From a global perspective the demand for NASA's technical data and documentation is anticipated to increase at local, national, and international levels. The primary users will be government, industry, and academia. In our present national strategy, NASA's research and technology will assume a great role in the revitalization of the economy and gaining international competitiveness. Thus, greater demand will be placed on NASA's data and documentation resources. In this paper the strategies and procedures developed by DDMS, Inc., to accommodate the present and future information utilization needs are presented. The DDMS, Inc., strategies and procedures rely on understanding user requirements, library management issues, and technological applications for acquiring, searching, storing, and retrieving specific information accurately and quickly. The proposed approach responds to changing customer requirements and product deliveries. The unique features of the proposed strategy include: (1) To establish customer driven data and documentation management through an innovative and unique methods to identify needs and requirements. (2) To implement a structured process which responds to user needs, aimed at minimizing costs and maximizing services, resulting in increased productivity. (3) To provide a process of standardization of services and procedures. This standardization is the central theme of the strategic approach. It will allow Division level Data and Documentation Libraries (DDL's) to function independently and optimize efficiency at the Directorate level. This process also facilitates interconnectivity between Division level DDL's and makes them transparent to the users. (4) To implement the process of 'cost savings', and at the same time the objective is to gain substantial improvement in the organization, categorization, and preservation of JSC-generated data and documentation, and (5) To find, locate, retrace, restore, and preserve the Center-generated crucial scientific and technical information that has been and is being provided by the engineers and scientists of JSC. This is important to the preservation of 'lessons learned'. Preliminary estimates of the possible cost savings which will result from the implementation of this process will also be discussed in this paper.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Piscotty, M A; Nazario, O L
2007-06-20
The objective of this project is the delivery of an application that will provide a unified, web-based system for collecting, verifying and analyzing the achievements for Laboratory employees. The application will enable individual Directorates to manage and report achievement record data for their employees using an LLNL standard web browser. In addition, cross directorate data reporting and analysis will be available for such organizations as LSTO and programmatic directorates. This system is intended to store reference data and metadata for employee achievements. Abstracts and entire publications will not be stored in this system.Directorates are expected to use this system atmore » all levels of management in preparing for Annual Self-Assessments, peer reviews, LDRD reviews, work force reviews, performance appraisals, and requests from sponsors. This document represents the primary deliverable for the Requirements Definition stage of system development. As part of a successful Requirements Definition, this document provides the development staff, the project sponsor, and the user community with a clear understanding of the product's operational, data, and other requirements. With this understanding, the development staff will take the opportunity to refine estimates regarding the cost, schedule, and deliverables reflected in it.« less
NASA Technical Reports Server (NTRS)
Isenberg, J. M.; Southall, J. W.
1979-01-01
The Integrated Programs for Aerospace Vehicle Design (IPAD) is a computing system to support company-wide design information processing. This document presents a brief description of the management system used to direct and control a product-oriented program. This document, together with the reference design process (CR 2981) and the manufacture interactions with the design process (CR 2982), comprises the reference information that forms the basis for specifying IPAD system requirements.
Legal considerations for document delivery services.
Bunting, A
1994-01-01
Health sciences libraries that provide fee-based information services must consider and develop policies and procedures for complying with legal requirements. This paper reviews the provisions of copyright law that pertain to document delivery, including two court decisions concerning copyright. Also discussed are recent actions by publishers to reinforce their view of libraries' responsibilities for royalty fees for articles copied and their use of licenses to impose additional restrictions on the use of and reproduction of materials. PMID:8004023
Transportation conformity particulate matter hot-spot air quality modeling.
DOT National Transportation Integrated Search
2013-07-01
In light of the new development in particulate matter (PM) hot-spot regulations and Illinois Department : of Transportation (IDOT)s National Environmental Policy Act (NEPA) documentation requirements, : this project is intended to (1) perform and ...
NASA Technical Reports Server (NTRS)
Rao, Gopalakrishna M.; Vaidyanathan, Hari
2007-01-01
This viewgraph presentation reviews the use of the binding procurement process in purchasing Aerospace Flight Battery Systems. NASA Engineering and Safety Center (NESC) requested NASA Aerospace Flight Battery Systems Working Group to develop a set of guideline requirements document for Binding Procurement Contracts.
DOT National Transportation Integrated Search
2016-07-01
This document provides guidance material in regards to the Participant Training and Stakeholder Education Plan forthe CV Pilots Deployment Concept Development Phase. The guidance provides key requirements and references indeveloping the training plan...
USDOT guidance summary for connected vehicle deployments : human use approval.
DOT National Transportation Integrated Search
2016-07-01
This document provides guidance material in regards to human use approval required for the CV Pilots DeploymentConcept Development Phase. Background is provided on relevant Federal guidance and Institutional Review Boards,including specific reference...
Requirements Document for Development of a Livermore Tomography Tools Interface
DOE Office of Scientific and Technical Information (OSTI.GOV)
Seetho, I. M.
In this document, we outline an exercise performed at LLNL to evaluate the user interface deficits of a LLNL-developed CT reconstruction software package, Livermore Tomography Tools (LTT). We observe that a difficult-to-use command line interface and the lack of support functions compound to generate a bottleneck in the CT reconstruction process when input parameters to key functions are not well known. Through the exercise of systems engineering best practices, we generate key performance parameters for a LTT interface refresh, and specify a combination of back-end (“test-mode” functions) and front-end (graphical user interface visualization and command scripting tools) solutions to LTT’smore » poor user interface that aim to mitigate issues and lower costs associated with CT reconstruction using LTT. Key functional and non-functional requirements and risk mitigation strategies for the solution are outlined and discussed.« less
Space Station Furnace Facility Preliminary Project Implementation Plan (PIP). Volume 2, Appendix 2
NASA Technical Reports Server (NTRS)
Perkey, John K.
1992-01-01
The Space Station Furnace Facility (SSFF) is an advanced facility for materials research in the microgravity environment of the Space Station Freedom and will consist of Core equipment and various sets of Furnace Module (FM) equipment in a three-rack configuration. This Project Implementation Plan (PIP) document was developed to satisfy the requirements of Data Requirement Number 4 for the SSFF study (Phase B). This PIP shall address the planning of the activities required to perform the detailed design and development of the SSFF for the Phase C/D portion of this contract.
NASA Technical Reports Server (NTRS)
Gault, J. W. (Editor); Trivedi, K. S. (Editor); Clary, J. B. (Editor)
1980-01-01
The validation process comprises the activities required to insure the agreement of system realization with system specification. A preliminary validation methodology for fault tolerant systems documented. A general framework for a validation methodology is presented along with a set of specific tasks intended for the validation of two specimen system, SIFT and FTMP. Two major areas of research are identified. First, are those activities required to support the ongoing development of the validation process itself, and second, are those activities required to support the design, development, and understanding of fault tolerant systems.
Maintenance of Certification for Radiation Oncology
DOE Office of Scientific and Technical Information (OSTI.GOV)
Kun, Larry E.; Ang, Kian; Erickson, Beth
2005-06-01
Maintenance of Certification (MOC) recognizes that in addition to medical knowledge, several essential elements involved in delivering quality care must be developed and maintained throughout one's career. The MOC process is designed to facilitate and document professional development of American Board of Radiology (ABR) diplomates in the essential elements of quality care in Radiation Oncology and Radiologic Physics. ABR MOC has been developed in accord with guidelines of the American Board of Medical Specialties. All Radiation Oncology certificates issued since 1995 are 10-year, time-limited certificates; diplomates with time-limited certificates who wish to maintain specialty certification must complete specific requirements ofmore » the American Board of Radiology MOC program. Diplomates with lifelong certificates are not required to participate but are strongly encouraged to do so. Maintenance of Certification is based on documentation of participation in the four components of MOC: (1) professional standing, (2) lifelong learning and self-assessment, (3) cognitive expertise, and (4) performance in practice. Through these components, MOC addresses six competencies-medical knowledge, patient care, interpersonal and communication skills, professionalism, practice-based learning and improvement, and systems-based practice. Details of requirements for components 1, 2, and 3 of MOC are outlined along with aspects of the fourth component currently under development.« less
STOVL Control Integration Program
NASA Technical Reports Server (NTRS)
Weiss, C.; Mcdowell, P.; Watts, S.
1994-01-01
An integrated flight/propulsion control for an advanced vector thrust supersonic STOVL aircraft, was developed by Pratt & Whitney and McDonnell Douglas Aerospace East. The IFPC design was based upon the partitioning of the global requirements into flight control and propulsion control requirements. To validate the design, aircraft and engine models were also developed for use on a NASA Ames piloted simulator. Different flight control implementations, evaluated for their handling qualities, are documented in the report along with the propulsion control, engine model, and aircraft model.
10 CFR 95.37 - Classification and preparation of documents.
Code of Federal Regulations, 2010 CFR
2010-01-01
... classification decisions. (c) Markings required on face of documents. (1) For derivative classification of... to a document must be placed in a conspicuous fashion in letters at the top and bottom of the outside... on the face of the document: Reproduction or Further Dissemination Requires Approval of If any...
10 CFR 95.37 - Classification and preparation of documents.
Code of Federal Regulations, 2011 CFR
2011-01-01
... classification decisions. (c) Markings required on face of documents. (1) For derivative classification of... to a document must be placed in a conspicuous fashion in letters at the top and bottom of the outside... on the face of the document: Reproduction or Further Dissemination Requires Approval of If any...
Development of a Communications Front End Processor (FEP) for the VAX-11/780 Using an LSI-11/23.
1983-12-01
9 Approach . . . . . . . . . . . . . . . . . . 11 Software Development Life Cycle . . . . . . . 11 Requirements Analysis...proven to be useful (25] during the Software Development Life Cycle of a project. Development tools and documentation aids used throughout this effort...include "Structure Charts" ( ref Appendix B ), a "Data Dictionary" ( ref Appendix C ),and Program Design Language CPDL). 1.5.1 Software Development- Life
Semantic Document Model to Enhance Data and Knowledge Interoperability
NASA Astrophysics Data System (ADS)
Nešić, Saša
To enable document data and knowledge to be efficiently shared and reused across application, enterprise, and community boundaries, desktop documents should be completely open and queryable resources, whose data and knowledge are represented in a form understandable to both humans and machines. At the same time, these are the requirements that desktop documents need to satisfy in order to contribute to the visions of the Semantic Web. With the aim of achieving this goal, we have developed the Semantic Document Model (SDM), which turns desktop documents into Semantic Documents as uniquely identified and semantically annotated composite resources, that can be instantiated into human-readable (HR) and machine-processable (MP) forms. In this paper, we present the SDM along with an RDF and ontology-based solution for the MP document instance. Moreover, on top of the proposed model, we have built the Semantic Document Management System (SDMS), which provides a set of services that exploit the model. As an application example that takes advantage of SDMS services, we have extended MS Office with a set of tools that enables users to transform MS Office documents (e.g., MS Word and MS PowerPoint) into Semantic Documents, and to search local and distant semantic document repositories for document content units (CUs) over Semantic Web protocols.
Simulation Data Management - Requirements and Design Specification
DOE Office of Scientific and Technical Information (OSTI.GOV)
Clay, Robert L.; Friedman-Hill, Ernest J.; Gibson, Marcus J.
Simulation Data Management (SDM), the ability to securely organize, archive, and share analysis models and the artifacts used to create them, is a fundamental requirement for modern engineering analysis based on computational simulation. We have worked separately to provide secure, network SDM services to engineers and scientists at our respective laboratories for over a decade. We propose to leverage our experience and lessons learned to help develop and deploy a next-generation SDM service as part of a multi-laboratory team. This service will be portable across multiple sites and platforms, and will be accessible via a range of command-line tools andmore » well-documented APIs. In this document, we’ll review our high-level and low-level requirements for such a system, review one existing system, and briefly discuss our proposed implementation.« less
The making of the mechanical universe
NASA Technical Reports Server (NTRS)
Blinn, James
1989-01-01
The Mechanical Universe project required the production of over 550 different animated scenes, totaling about 7 and 1/2 hours of screen time. The project required the use of a wide range of techniques and motivated the development of several different software packages. A documentation is presented of many aspects of the project, encompassing artistic design issues, scientific simulations, software engineering, and video engineering.
ERIC Educational Resources Information Center
Browne, Geoffrey R.; Davern, Melanie; Giles-Corti, Billie
2017-01-01
Victorian local governments (LGs) are required to develop evidence-based Municipal Public Health and Wellbeing Plans (MPHWPs) that improve health and wellbeing. This study evaluated the implementation of this requirement across 79 LGs. Evidence in 116 documents was categorised by source, issue, and policy specificity. Over 11,000…
AgRISTARS. Semiannual program review presentation to level 1, interagency Coordination Committee
NASA Technical Reports Server (NTRS)
1982-01-01
Results are presented for (1) spring small grains; (2) summer crops/corn and soybeans; and (3) crop signature characterization. The development of an early season approach, profile and segment based change estimation, and future satellite and sensor system requirements are discussed. Documentation for the inventory technology development project is included.
Career Fields for Inspection and Enforcement Personnel.
ERIC Educational Resources Information Center
Bartley, Hugh J.; And Others
This document is the General Research Corporation (GRC) report on Task II, which called for the development of career fields for headquarters and regional positions of the U.S. Nuclear Regulatory Commission Office of Inspection and Enforcement (NRC/IE). GRC examined the data of Task I (development of qualifications requirements) for commonality of…
Resource Requirements and Costs of Developing and Delivering MOOCs
ERIC Educational Resources Information Center
Hollands, Fiona M.; Tirthali, Devayani
2014-01-01
Given the ongoing alarm regarding uncontrollable costs of higher education, it would be reasonable to expect not only concern about the impact of MOOCs on educational outcomes, but also systematic efforts to document the resources expended on their development and delivery. However, there is little publicly available information on MOOC costs that…
ERIC Educational Resources Information Center
Hodges, Michael; Kulinna, Pamela Hodges; Lee, Chong; Kwon, Ja Youn
2017-01-01
Students of all ages have documented a deficiency in health-related fitness knowledge (HRFK). However, improving students HRFK may require a change in teacher practices and professional development (PD). Purpose: This study, framed by Guskey's Model of Teacher Change (GMTC; Guskey, 2002), sought to assist teachers' HRFK instruction as part of…
40 CFR 80.1651 - Product transfer document requirements.
Code of Federal Regulations, 2014 CFR
2014-07-01
..., “This gasoline is for use in vehicles, engines, or equipment under an EPA-approved national security exemption only.” (2) For gasoline with a research, development, or testing exemption under § 80.1656, “This gasoline is for research, development, or testing purposes only.” (3) For gasoline for use in American...
Development of a Health Survey Instrument for 5- to 8-Year-Old Youths
ERIC Educational Resources Information Center
Neelon, Marisa; Brian, Kelley; Iaccopucci, Anne M.; Lewis, Kendra M.; Worker, Steven M.
2017-01-01
Measuring program outcomes is required for documenting effectiveness of interventions with youths participating in programs funded through the U.S. Department of Agriculture's Children, Youth, and Families at Risk (CYFAR) initiative. The California CYFAR program provided programming for youths aged 5-8, which necessitated the development of an…
Top 10 Research Questions Related to Children Physical Activity Motivation
ERIC Educational Resources Information Center
Chen, Ang
2013-01-01
Physical activity is critical to healthy development of children. It is well documented that helping children develop and sustain a physically active lifestyle requires children to become motivated. Many studies have been conducted in the past 2.5 decades on determinants and correlates for children and adolescents' physical activity…
Assuring Best Practice in Technology-Enhanced Learning Environments
ERIC Educational Resources Information Center
Keppell, Mike; Suddaby, Gordon; Hard, Natasha
2015-01-01
This paper documents the development and findings of the Good Practice Report on Technology-Enhanced Learning and Teaching funded by the Australian Learning and Teaching Council (ALTC). Developing the Good Practice Report required a meta-analysis of 33 ALTC learning and teaching projects relating to technology funded between 2006 and 2010. This…
Advanced silver zinc battery development for the SRB and ET range safety subsystems
NASA Technical Reports Server (NTRS)
Adamedes, Zoe
1994-01-01
This document presents in viewgraph format the design and development of silver zinc (AgZn) batteries for the solid rocket booster (SRB) and external tank (ET) range safety subsystems. Various engineering techniques, including composite separator systems, new electrode processing techniques, and new restraint techniques, were used to meet difficult requirements.
Requirement of scientific documentation for the development of Naturopathy.
Rastogi, Rajiv
2006-01-01
Past few decades have witnessed explosion of knowledge in almost every field. This has resulted not only in the advancement of the subjects in particular but also have influenced the growth of various allied subjects. The present paper explains about the advancement of science through efforts made in specific areas and also through discoveries in different allied fields having an indirect influence upon the subject in proper. In Naturopathy this seems that though nothing particular is added to the basic thoughts or fundamental principles of the subject yet the entire treatment understanding is revolutionised under the influence of scientific discoveries of past few decades. Advent of information technology has further added to the boom of knowledge and many times this seems impossible to utilize these informations for the good of human being because these are not logically arranged in our minds. In the above background, the author tries to define documentation stating that we have today ocean of information and knowledge about various things- living or dead, plants, animals or human beings; the geographical conditions or changing weather and environment. What required to be done is to extract the relevant knowledge and information required to enrich the subject. The author compares documentation with churning of milk to extract butter. Documentation, in fact, is churning of ocean of information to extract the specific, most appropriate, relevant and defined information and knowledge related to the particular subject . The paper besides discussing the definition of documentation, highlights the areas of Naturopathy requiring an urgent necessity to make proper documentations. Paper also discusses the present status of Naturopathy in India, proposes short-term and long-term goals to be achieved and plans the strategies for achieving them. The most important aspect of the paper is due understanding of the limitations of Naturopathy but a constant effort to improve the same with the growth made in various discipline of science so far.
Hanford tanks initiative (HTI) configuration management desk instruction
DOE Office of Scientific and Technical Information (OSTI.GOV)
Schaus, P.S., Fluor Daniel Hanford
The purpose of the document is to provide working level directions for submitting requirements, making changes to the requirements database, and entering Project documentation into the HTI Project information and document management system.
DOT National Transportation Integrated Search
2016-10-12
This document offers a detailed discussion of the systems functionality that was planned to be implemented. However, following the Agile Development methodology, during the course of system development, diligent decisions were made based on the la...
Ballistic Missile Defense System (BMDS)
2015-12-01
Assessment and Program Evaluation CARD - Cost Analysis Requirements Description CDD - Capability Development Document CLIN - Contract Line Item Number CPD...Estimate RDT&E - Research, Development, Test, and Evaluation SAR - Selected Acquisition Report SCP - Service Cost Position TBD - To Be Determined TY - Then...BMDS December 2015 SAR March 23, 2016 16:29:09 UNCLASSIFIED 5 Mission and Description Mission and Description To develop, test, and field a layered
Efforts to integrate CMIP metadata and standards into NOAA-GFDL's climate model workflow
NASA Astrophysics Data System (ADS)
Blanton, C.; Lee, M.; Mason, E. E.; Radhakrishnan, A.
2017-12-01
Modeling centers participating in CMIP6 run model simulations, publish requested model output (conforming to community data standards), and document models and simulations using ES-DOC. GFDL developed workflow software implementing some best practices to meet these metadata and documentation requirements. The CMIP6 Data Request defines the variables that should be archived for each experiment and specifies their spatial and temporal structure. We used the Data Request's dreqPy python library to write GFDL model configuration files as an alternative to hand-crafted tables. There was also a largely successful effort to standardize variable names within the model to reduce the additional overhead of translating "GFDL to CMOR" variables at a later stage in the pipeline. The ES-DOC ecosystem provides tools and standards to create, publish, and view various types of community-defined CIM documents, most notably model and simulation documents. Although ES-DOC will automatically create simulation documents during publishing by harvesting NetCDF global attributes, the information must be collected, stored, and placed in the NetCDF files by the workflow. We propose to develop a GUI to collect the simulation document precursors. In addition, a new MIP for CMIP6-CPMIP, a comparison of computational performance of climate models-is documented using machine and performance CIM documents. We used ES-DOC's pyesdoc python library to automatically create these machine and performance documents. We hope that these and similar efforts will become permanent features of the GFDL workflow to facilitate future participation in CMIP-like activities.
The Earth System Documentation (ES-DOC) Software Process
NASA Astrophysics Data System (ADS)
Greenslade, M. A.; Murphy, S.; Treshansky, A.; DeLuca, C.; Guilyardi, E.; Denvil, S.
2013-12-01
Earth System Documentation (ES-DOC) is an international project supplying high-quality tools & services in support of earth system documentation creation, analysis and dissemination. It is nurturing a sustainable standards based documentation eco-system that aims to become an integral part of the next generation of exa-scale dataset archives. ES-DOC leverages open source software, and applies a software development methodology that places end-user narratives at the heart of all it does. ES-DOC has initially focused upon nurturing the Earth System Model (ESM) documentation eco-system and currently supporting the following projects: * Coupled Model Inter-comparison Project Phase 5 (CMIP5); * Dynamical Core Model Inter-comparison Project (DCMIP); * National Climate Predictions and Projections Platforms Quantitative Evaluation of Downscaling Workshop. This talk will demonstrate that ES-DOC implements a relatively mature software development process. Taking a pragmatic Agile process as inspiration, ES-DOC: * Iteratively develops and releases working software; * Captures user requirements via a narrative based approach; * Uses online collaboration tools (e.g. Earth System CoG) to manage progress; * Prototypes applications to validate their feasibility; * Leverages meta-programming techniques where appropriate; * Automates testing whenever sensibly feasible; * Streamlines complex deployments to a single command; * Extensively leverages GitHub and Pivotal Tracker; * Enforces strict separation of the UI from underlying API's; * Conducts code reviews.
DOE Office of Scientific and Technical Information (OSTI.GOV)
Burt, D.L.
1994-04-01
The High-Level Waste Storage Tank Farms/242-A Evaporator Standards/Requirements Identification Document (S/RID) is contained in multiple volumes. This document (Volume 7) presents the standards and requirements for the following sections: Occupational Safety and Health, and Environmental Protection.
7 CFR 1.613 - What are the requirements for service of documents?
Code of Federal Regulations, 2010 CFR
2010-01-01
... 7 Agriculture 1 2010-01-01 2010-01-01 false What are the requirements for service of documents? 1.613 Section 1.613 Agriculture Office of the Secretary of Agriculture ADMINISTRATIVE REGULATIONS Conditions in FERC Hydropower Licenses Document Filing and Service § 1.613 What are the requirements for...
Documentation of Heritage Structures Through Geo-Crowdsourcing and Web-Mapping
NASA Astrophysics Data System (ADS)
Dhonju, H. K.; Xiao, W.; Shakya, B.; Mills, J. P.; Sarhosis, V.
2017-09-01
Heritage documentation has become increasingly urgent due to both natural impacts and human influences. The documentation of countless heritage sites around the globe is a massive project that requires significant amounts of financial and labour resources. With the concepts of volunteered geographic information (VGI) and citizen science, heritage data such as digital photographs can be collected through online crowd participation. Whilst photographs are not strictly geographic data, they can be geo-tagged by the participants. They can also be automatically geo-referenced into a global coordinate system if collected via mobile phones which are now ubiquitous. With the assistance of web-mapping, an online geo-crowdsourcing platform has been developed to collect and display heritage structure photographs. Details of platform development are presented in this paper. The prototype is demonstrated with several heritage examples. Potential applications and advancements are discussed.
Drivers of Dashboard Development (3-D): A Curricular Continuous Quality Improvement Approach.
Shroyer, A Laurie; Lu, Wei-Hsin; Chandran, Latha
2016-04-01
Undergraduate medical education (UME) programs are seeking systematic ways to monitor and manage their educational performance metrics and document their achievement of external goals (e.g., Liaison Committee on Medical Education [LCME] accreditation requirements) and internal objectives (institution-specific metrics). In other continuous quality improvement (CQI) settings, summary dashboard reports have been used to evaluate and improve performance. The Stony Brook University School of Medicine UME leadership team developed and implemented summary dashboard performance reports in 2009 to document LCME standards/criteria compliance, evaluate medical student performance, and identify progress in attaining institutional curricular goals and objectives. Key performance indicators (KPIs) and benchmarks were established and have been routinely monitored as part of the novel Drivers of Dashboard Development (3-D) approach to curricular CQI. The systematic 3-D approach has had positive CQI impacts. Substantial improvements over time have been documented in KPIs including timeliness of clerkship grades, midclerkship feedback, student mistreatment policy awareness, and student satisfaction. Stakeholder feedback indicates that the dashboards have provided useful information guiding data-driven curricular changes, such as integrating clinician-scientists as lecturers in basic science courses to clarify the clinical relevance of specific topics. Gaining stakeholder acceptance of the 3-D approach required clear communication of preestablished targets and annual meetings with department leaders and course/clerkship directors. The 3-D approach may be considered by UME programs as a template for providing faculty and leadership with a CQI framework to establish shared goals, document compliance, report accomplishments, enrich communications, facilitate decisions, and improve performance.
Directory of Energy Information Administration Model Abstracts
DOE Office of Scientific and Technical Information (OSTI.GOV)
Not Available
1986-07-16
This directory partially fulfills the requirements of Section 8c, of the documentation order, which states in part that: The Office of Statistical Standards will annually publish an EIA document based on the collected abstracts and the appendices. This report contains brief statements about each model's title, acronym, purpose, and status, followed by more detailed information on characteristics, uses, and requirements. Sources for additional information are identified. All models active through March 1985 are included. The main body of this directory is an alphabetical list of all active EIA models. Appendix A identifies major EIA modeling systems and the models withinmore » these systems, and Appendix B identifies active EIA models by type (basic, auxiliary, and developing). EIA also leases models developed by proprietary software vendors. Documentation for these proprietary models is the responsibility of the companies from which they are leased. EIA has recently leased models from Chase Econometrics, Inc., Data Resources, Inc. (DRI), the Oak Ridge National Laboratory (ORNL), and Wharton Econometric Forecasting Associates (WEFA). Leased models are not abstracted here. The directory is intended for the use of energy and energy-policy analysts in the public and private sectors.« less
DOE Office of Scientific and Technical Information (OSTI.GOV)
Minana, Molly A.; Sturtevant, Judith E.; Heaphy, Robert
2005-01-01
The purpose of the Sandia National Laboratories (SNL) Advanced Simulation and Computing (ASC) Software Quality Plan is to clearly identify the practices that are the basis for continually improving the quality of ASC software products. Quality is defined in DOE/AL Quality Criteria (QC-1) as conformance to customer requirements and expectations. This quality plan defines the ASC program software quality practices and provides mappings of these practices to the SNL Corporate Process Requirements (CPR 1.3.2 and CPR 1.3.6) and the Department of Energy (DOE) document, ASCI Software Quality Engineering: Goals, Principles, and Guidelines (GP&G). This quality plan identifies ASC management andmore » software project teams' responsibilities for cost-effective software engineering quality practices. The SNL ASC Software Quality Plan establishes the signatories commitment to improving software products by applying cost-effective software engineering quality practices. This document explains the project teams opportunities for tailoring and implementing the practices; enumerates the practices that compose the development of SNL ASC's software products; and includes a sample assessment checklist that was developed based upon the practices in this document.« less
Takeda, Toshihiro; Ueda, Kanayo; Manabe, Shiro; Teramoto, Kei; Mihara, Naoki; Matsumura, Yasushi
2013-01-01
Standard Japanese electronic medical record (EMR) systems are associated with major shortcomings. For example, they do not assure lifelong readability of records because each document requires its own viewing software program, a system that is difficult to maintain over long periods of time. It can also be difficult for users to comprehend a patient's clinical history because different classes of documents can only be accessed from their own window. To address these problems, we developed a document-based electronic medical record that aggregates all documents for a patient in a PDF or DocuWorks format. We call this system the Document Archiving and Communication System (DACS). There are two types of viewers in the DACS: the Matrix View, which provides a time line of a patient's history, and the Tree View, which stores the documents in hierarchical document classes. We placed 2,734 document classes into 11 categories. A total of 22,3972 documents were entered per month. The frequency of use of the DACS viewer was 268,644 instances per month. The DACS viewer was used to assess a patient's clinical history.
Embedding the shapes of regions of interest into a Clinical Document Architecture document.
Minh, Nguyen Hai; Yi, Byoung-Kee; Kim, Il Kon; Song, Joon Hyun; Binh, Pham Viet
2015-03-01
Sharing a medical image visually annotated by a region of interest with a remotely located specialist for consultation is a good practice. It may, however, require a special-purpose (and most likely expensive) system to send and view them, which is an unfeasible solution in developing countries such as Vietnam. In this study, we design and implement interoperable methods based on the HL7 Clinical Document Architecture and the eXtensible Markup Language Stylesheet Language for Transformation standards to seamlessly exchange and visually present the shapes of regions of interest using web browsers. We also propose a new integration architecture for a Clinical Document Architecture generator that enables embedding of regions of interest and simultaneous auto-generation of corresponding style sheets. Using the Clinical Document Architecture document and style sheet, a sender can transmit clinical documents and medical images together with coordinate values of regions of interest to recipients. Recipients can easily view the documents and display embedded regions of interest by rendering them in their web browser of choice. © The Author(s) 2014.
A COMPREHENSIVE TECHNICAL REVIEW OF THE DEMONSTRATION BULK VITRIFICATION SYSTEM
DOE Office of Scientific and Technical Information (OSTI.GOV)
SCHAUS, P.S.
2006-09-29
In May 2006, CH2M Hill Hanford Group, Inc. chartered an Expert Review Panel (ERP) to review the current status of the Demonstration Bulk Vitrification System (DBVS). It is the consensus of the ERP that bulk vitrification is a technology that requires further development and evaluation to determine its potential for meeting the Hanford waste stabilization mission. No fatal flaws (issues that would jeopardize the overall DBVS mission that cannot be mitigated) were found, given the current state of the project. However, a number of technical issues were found that could significantly affect the project's ability to meet its overall missionmore » as stated in the project ''Justification of Mission Need'' document, if not satisfactorily resolved. The ERP recognizes that the project has changed from an accelerated schedule demonstration project to a formally chartered project that must be in full compliance with DOE 413.3 requirements. The perspective of the ERP presented herein, is measured against the formally chartered project as stated in the approved Justification of Mission Need document. A justification of Mission Need document was approved in July 2006 which defined the objectives for the DBVS Project. In this document, DOE concluded that bulk vitrification is a viable technology that requires additional development to determine its potential applicability to treatment of a portion of the Hanford low activity waste. The DBVS mission need statement now includes the following primary objectives: (1) process approximately 190,000 gallons of Tank S-109 waste into fifty 100 metric ton boxes of vitrified product; (2) store and dispose of these boxes at Hanford's Integrated Disposal Facility (IDF); (3) evaluate the waste form characteristics; (4) gather pilot plant operability data, and (5) develop the overall life cycle system performance of bulk vitrification and produce a comparison of the bulk vitrification process to building a second LAW Immobilization facility or other supplemental treatment alternatives as provided in M-62-08.« less
Review of LLNL Mixed Waste Streams for the Application of Potential Waste Reduction Controls
DOE Office of Scientific and Technical Information (OSTI.GOV)
Belue, A; Fischer, R P
2007-01-08
In July 2004, LLNL adopted the International Standard ISO 14001 as a Work Smart Standard in lieu of DOE Order 450.1. In support of this new requirement the Director issued a new environmental policy that was documented in Section 3.0 of Document 1.2, ''ES&H Policies of LLNL'', in the ES&H Manual. In recent years the Environmental Management System (EMS) process has become formalized as LLNL adopted ISO 14001 as part of the contract under which the laboratory is operated for the Department of Energy (DOE). On May 9, 2005, LLNL revised its Integrated Safety Management System Description to enhance existingmore » environmental requirements to meet ISO 14001. Effective October 1, 2005, each new project or activity is required to be evaluated from an environmental aspect, particularly if a potential exists for significant environmental impacts. Authorizing organizations are required to consider the management of all environmental aspects, the applicable regulatory requirements, and reasonable actions that can be taken to reduce negative environmental impacts. During 2006, LLNL has worked to implement the corrective actions addressing the deficiencies identified in the DOE/LSO audit. LLNL has begun to update the present EMS to meet the requirements of ISO 14001:2004. The EMS commits LLNL--and each employee--to responsible stewardship of all the environmental resources in our care. The generation of mixed radioactive waste was identified as a significant environmental aspect. Mixed waste for the purposes of this report is defined as waste materials containing both hazardous chemical and radioactive constituents. Significant environmental aspects require that an Environmental Management Plan (EMP) be developed. The objective of the EMP developed for mixed waste (EMP-005) is to evaluate options for reducing the amount of mixed waste generated. This document presents the findings of the evaluation of mixed waste generated at LLNL and a proposed plan for reduction.« less