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

Electrical, Electronic, and Electromechanical (EEE) parts management and control requirements for NASA space flight programs

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).

Tank waste remediation system privatization infrastructure program requirements and document management process guide

DOE Office of Scientific and Technical Information (OSTI.GOV)

ROOT, R.W.

1999-05-18

This guide provides the Tank Waste Remediation System Privatization Infrastructure Program management with processes and requirements to appropriately control information and documents in accordance with the Tank Waste Remediation System Configuration Management Plan (Vann 1998b). This includes documents and information created by the program, as well as non-program generated materials submitted to the project. It provides appropriate approval/control, distribution and filing systems.

Gary-Chicago-Milwaukee corridor : corridor transportation information center : system glossary

DOT National Transportation Integrated Search

1995-10-30

The following definitions, abbreviations and acronyms are generated from the : System Definition Document (Document #9931.GCM), the Interface Control : Specification (Document #9932.GCM), and the Requirements Specification (Document : #9933.GCM). The...

Orbiter data reduction complex data processing requirements for the OFT mission evaluation team (level C)

NASA Technical Reports Server (NTRS)

1979-01-01

This document addresses requirements for post-test data reduction in support of the Orbital Flight Tests (OFT) mission evaluation team, specifically those which are planned to be implemented in the ODRC (Orbiter Data Reduction Complex). Only those requirements which have been previously baselined by the Data Systems and Analysis Directorate configuration control board are included. This document serves as the control document between Institutional Data Systems Division and the Integration Division for OFT mission evaluation data processing requirements, and shall be the basis for detailed design of ODRC data processing systems.

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.

High-level requirements for the US-75 integrated corridor in Dallas, Texas

DOT National Transportation Integrated Search

2008-04-30

This document is intended as a listing and discussion of the high-level Requirements for the US-75 Integrated Corridor Management System (ICMS) in Dallas. This document describes what the system is to do (the functional requirements), how well it is ...

Design criteria for the light duty utility arm system end effectors

DOE Office of Scientific and Technical Information (OSTI.GOV)

Pardini, A.F.; Kiebel, G.R.

1995-12-01

The purpose of this document is to provide criteria for the design of end effectors that will be used as part of the Light Duty Utility Arm (LDUA) System. Actual component design, fabrication, testing, and inspection will be performed by various DOE laboratories, industry, and academia. This document augments WHC-SD-TD-FRD-003, `Functions and Requirements for the Light Duty Utility Arm Integrated System` (F). All requirements dictated in the F shall also be applicable in this document. Whenever conflicts arise between this document and the F, this document shall take precedence.

Assessment of documentation requirements under DOE 5481. 1, Safety Analysis and Review System (SARS)

DOE Office of Scientific and Technical Information (OSTI.GOV)

Browne, E.T.

1981-03-01

This report assesses the requirements of DOE Order 5481.1, Safety Analysis and Review System for DOE Operations (SARS) in regard to maintaining SARS documentation. Under SARS, all pertinent details of the entire safety analysis and review process for each DOE operation are to be traceable from the initial identification of a hazard. This report is intended to provide assistance in identifying the points in the SARS cycle at which documentation is required, what type of documentation is most appropriate, and where it ultimately should be maintained.

ICESat (GLAS) Science Processing Software Document Series. Volume 3; GLAS Science Software Requirements Document; Ver 2.1

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.

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.

Earth Observatory Satellite system definition study. Report no. 3: Design/cost tradeoff studies. Appendix C: EOS program requirements document

NASA Technical Reports Server (NTRS)

1974-01-01

An analysis of the requirements for the Earth Observatory Satellite (EOS) system specifications is presented. The analysis consists of requirements obtained from existing documentation and those derived from functional analysis. The requirements follow the hierarchy of program, mission, system, and subsystem. The code for designating specific requirements is explained. Among the subjects considered are the following: (1) the traffic model, (2) space shuttle related performance, (3) booster related performance, (4) the data collection system, (5) spacecraft structural tests, and (6) the ground support requirements.

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.

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.

Cold Vacuum Drying facility civil structural system design description (SYS 06)

DOE Office of Scientific and Technical Information (OSTI.GOV)

PITKOFF, C.C.

This document describes the Cold Vacuum Drying (CVD) Facility civil - structural system. This system consists of the facility structure, including the administrative and process areas. The system's primary purpose is to provide for a facility to house the CVD process and personnel and to provide a tertiary level of containment. The document provides a description of the facility and demonstrates how the design meets the various requirements imposed by the safety analysis report and the design requirements document.

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

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.

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

Functional Requirements for an Electronic Work Package System

DOE Office of Scientific and Technical Information (OSTI.GOV)

Oxstrand, Johanna H.

This document provides a set of high level functional requirements for a generic electronic work package (eWP) system. The requirements have been identified by the U.S. nuclear industry as a part of the Nuclear Electronic Work Packages - Enterprise Requirements (NEWPER) initiative. The functional requirements are mainly applied to eWP system supporting Basic and Moderate types of smart documents, i.e., documents that have fields for recording input such as text, dates, numbers, and equipment status, and documents which incorporate additional functionalities such as form field data “type“ validation (e.g. date, text, number, and signature) of data entered and/or self-populate basicmore » document information (usually from existing host application meta data) on the form when the user first opens it. All the requirements are categorized by the roles; Planner, Supervisor, Craft, Work Package Approval Reviewer, Operations, Scheduling/Work Control, and Supporting Functions. The categories Statistics, Records, Information Technology are also included used to group the requirements. All requirements are presented in Section 2 through Section 11. Examples of more detailed requirements are provided for the majority of high level requirements. These examples are meant as an inspiration to be used as each utility goes through the process of identifying their specific requirements. The report’s table of contents provides a summary of the high level requirements.« less

IDC Re-Engineering Phase 2 System Requirements Document Version 1.4

DOE Office of Scientific and Technical Information (OSTI.GOV)

Harris, James M.; Burns, John F.; Satpathi, Meara Allena

This System Requirements Document (SRD) defines waveform data processing requirements for the International Data Centre (IDC) of the Comprehensive Nuclear Test Ban Treaty Organization (CTBTO). The IDC applies, on a routine basis, automatic processing methods and interactive analysis to raw International Monitoring System (IMS) data in order to produce, archive, and distribute standard IDC products on behalf of all States Parties. 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,more » but includes requirements for the dissemination of radionuclide data and products.« less

IDC Re-Engineering Phase 2 System Requirements Document V1.3.

DOE Office of Scientific and Technical Information (OSTI.GOV)

Harris, James M.; Burns, John F.; Satpathi, Meara Allena

2015-12-01

This System Requirements Document (SRD) defines waveform data processing requirements for the International Data Centre (IDC) of the Comprehensive Nuclear Test Ban Treaty Organization (CTBTO). The IDC applies, on a routine basis, automatic processing methods and interactive analysis to raw International Monitoring System (IMS) data in order to produce, archive, and distribute standard IDC products on behalf of all States Parties. 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 datamore » but includes requirements for the dissemination of radionuclide data and products.« less

Guidelines for Documentation of Computer Programs and Automated Data Systems. (Category: Software; Subcategory: Documentation).

ERIC Educational Resources Information Center

Federal Information Processing Standards Publication, 1976

1976-01-01

These guidelines provide a basis for determining the content and extent of documentation for computer programs and automated data systems. Content descriptions of ten document types plus examples of how management can determine when to use the various types are included. The documents described are (1) functional requirements documents, (2) data…

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 ...

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

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?

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.

ATM Technology Demonstration-1 Phase II Boeing Configurable Graphical Display (CGD) Software Design Description

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).

Managing the life cycle of electronic clinical documents.

PubMed

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.

International Low Impact Docking System (iLIDS) Project Technical Requirements Specification, Revision F

NASA Technical Reports Server (NTRS)

Lewis, James L.

2011-01-01

The NASA Docking System (NDS) is NASA's implementation for the emerging International Docking System Standard (IDSS) using low impact docking technology. The NASA Docking System Project (NDSP) is the International Space Station (ISS) Program's project to produce the NDS, Common Docking Adapter (CDA) and Docking Hub. The NDS design evolved from the Low Impact Docking System (LIDS). The acronym international Low Impact Docking System (iLIDS) is also used to describe this system as well as the Government Furnished Equipment (GFE) project designing the NDS for the NDSP. NDS and iLIDS may be used interchangeability. This document will use the acronym iLIDS. Some of the heritage documentation and implementations (e.g., software command names, requirement identification (ID), figures, etc.) used on NDS will continue to use the LIDS acronym. This specification defines the technical requirements for the iLIDS GFE delivered to the NDSP by the iLIDS project. This document contains requirements for two iLIDS configurations, SEZ29101800-301 and SEZ29101800-302. Requirements with the statement, iLIDS shall, are for all configurations. Examples of requirements that are unique to a single configuration may be identified as iLIDS (-301) shall or iLIDS (-302) shall. Furthermore, to allow a requirement to encompass all configurations with an exception, the requirement may be designated as iLIDS (excluding -302) shall. Verification requirements for the iLIDS project are identified in the Verification Matrix (VM) provided in the iLIDS Verification and Validation Document, JSC-63966. The following definitions differentiate between requirements and other statements: Shall: This is the only verb used for the binding requirements. Should/May: These verbs are used for stating non-mandatory goals. Will: This verb is used for stating facts or declaration of purpose. A Definition of Terms table is provided in Appendix B to define those terms with specific tailored uses in this document.

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.

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.

Full-scale system impact analysis: Digital document storage project

NASA Technical Reports Server (NTRS)

1989-01-01

The Digital Document Storage Full Scale System can provide cost effective electronic document storage, retrieval, hard copy reproduction, and remote access for users of NASA Technical Reports. The desired functionality of the DDS system is highly dependent on the assumed requirements for remote access used in this Impact Analysis. It is highly recommended that NASA proceed with a phased, communications requirement analysis to ensure that adequate communications service can be supplied at a reasonable cost in order to validate recent working assumptions upon which the success of the DDS Full Scale System is dependent.

Initial SVS Integrated Technology Evaluation Flight Test Requirements and Hardware Architecture

NASA Technical Reports Server (NTRS)

Harrison, Stella V.; Kramer, Lynda J.; Bailey, Randall E.; Jones, Denise R.; Young, Steven D.; Harrah, Steven D.; Arthur, Jarvis J.; Parrish, Russell V.

2003-01-01

This document presents the flight test requirements for the Initial Synthetic Vision Systems Integrated Technology Evaluation flight Test to be flown aboard NASA Langley's ARIES aircraft and the final hardware architecture implemented to meet these requirements. Part I of this document contains the hardware, software, simulator, and flight operations requirements for this light test as they were defined in August 2002. The contents of this section are the actual requirements document that was signed for this flight test. Part II of this document contains information pertaining to the hardware architecture that was realized to meet these requirements as presented to and approved by a Critical Design Review Panel prior to installation on the B-757 Airborne Research Integrated Experiments Systems (ARIES) airplane. This information includes a description of the equipment, block diagrams of the architecture, layouts of the workstations, and pictures of the actual installations.

NASA Requirements for Ground-Based Pressure Vessels and Pressurized Systems (PVS). Revision C

NASA Technical Reports Server (NTRS)

Greulich, Owen Rudolf

2017-01-01

The purpose of this document is to ensure the structural integrity of PVS through implementation of a minimum set of requirements for ground-based PVS in accordance with this document, NASA Policy Directive (NPD) 8710.5, NASA Safety Policy for Pressure Vessels and Pressurized Systems, NASA Procedural Requirements (NPR) 8715.3, NASA General Safety Program Requirements, applicable Federal Regulations, and national consensus codes and standards (NCS).

The Development and Initial Evaluation of the Human Readiness Level Framework

DTIC Science & Technology

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

Functional requirements document for NASA/MSFC Earth Science and Applications Division: Data and information system (ESAD-DIS). Interoperability, 1992

NASA Technical Reports Server (NTRS)

Stephens, J. Briscoe; Grider, Gary W.

1992-01-01

These Earth Science and Applications Division-Data and Information System (ESAD-DIS) interoperability requirements are designed to quantify the Earth Science and Application Division's hardware and software requirements in terms of communications between personal and visualization workstation, and mainframe computers. The electronic mail requirements and local area network (LAN) requirements are addressed. These interoperability requirements are top-level requirements framed around defining the existing ESAD-DIS interoperability and projecting known near-term requirements for both operational support and for management planning. Detailed requirements will be submitted on a case-by-case basis. This document is also intended as an overview of ESAD-DIs interoperability for new-comers and management not familiar with these activities. It is intended as background documentation to support requests for resources and support requirements.

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.

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.

Weather Requirements and Procedures for Step 1: High Altitude Long Endurance (HALE) Unmanned Aircraft System (UAS) Flight Operations in the National Air Space (NAS)

NASA Technical Reports Server (NTRS)

2007-01-01

This cover sheet is for version 2 of the weather requirements document along with Appendix A. The purpose of the requirements document was to identify and to list the weather 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." A discussion of the Federal Aviation Administration (FAA) references and related policies, procedures, and standards is provided as basis for the recommendations supported within this document. Additional procedures and reference documentation related to weather functional requirements is also provided for background. The functional requirements and related information are to be proposed to the FAA and various standards organizations for consideration and approval. The appendix was designed to show that sources of flight weather information are readily available to UAS pilots conducting missions in the NAS. All weather information for this presentation was obtained from the public internet.

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.

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.

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.

Requirements Analysis Study for Master Pump Shutdown System Project Development Specification [SEC 1 and 2

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

SP-100 Program: space reactor system and subsystem investigations

DOE Office of Scientific and Technical Information (OSTI.GOV)

Harty, R.B.

1983-09-30

For a space reactor power system, a comprehensive safety program will be required to assure that no undue risk is present. This report summarizes the nuclear safety review/approval process that will be required for a space reactor system. The documentation requirements are presented along with a summary of the required contents of key documents. Finally, the aerospace safety program conducted for the SNAP-10A reactor system is summarized. The results of this program are presented to show the type of program that can be expected and to provide information that could be usable in future programs.

SP-100 program: Space reactor system and subsystem investigations

NASA Astrophysics Data System (ADS)

Harty, R. B.

1983-09-01

For a space reactor power system, a comprehensive safety program will be required to assure that no undue risk is present. The nuclear safety review/approval process that is required for a space reactor system is summarized. The documentation requirements are presented along with a summary of the required contents of key documents. Finally, the aerospace safety program conducted for the SNAP-10A reactor system is summarized. The results of this program are presented to show the type of program that is expected and to provide information that could be usable in future programs.

Interface Control Specification

DOT National Transportation Integrated Search

1996-06-12

The Requirements Specification Document (#9933.04) identifies the overall system level requirements of the Gary-Chicago-Milwaukee (GCM) Corridor Transportation Information Center (C-TIC). This document provides details about the data and control flow...

Work Package 5: Contingency Management. Mission Planning Requirements Document: Preliminary Version. Revision A

NASA Technical Reports Server (NTRS)

2005-01-01

The purpose of this document is to identify the general flight/mission planning requirements for same-day file-and-fly access to the NAS for both civil and military High-Altitude Long Endurance (HALE) Unmanned Aircraft System (UAS). Currently the scope of this document is limited to Step 1, operations above flight level 43,000 feet (FL430). This document describes the current applicable mission planning requirements and procedures for both manned and unmanned aircraft and addresses HALE UAS flight planning considerations in the future National Airspace System (NAS). It also discusses the unique performance and operational capabilities of HALE UAS associated with the Access 5 Project, presents some of the projected performance characteristics and conceptual missions for future systems, and provides detailed analysis of the recommended mission planning elements for operating HALE UAS in the NAS.

[Recommendations for the control of documents and the establishment of a documentary system].

PubMed

Vinner, E

2013-06-01

The quality management system that must be implemented in a MBL to meet the requirements of the standard NF EN ISO 15189 is based, among other things, on the creation and use by staff of a documentary system approved and updated. This documentary system is constituted by external documents (standards, suppliers' documents...) and internal documents (quality manual, procedures, instructions, technical and quality recordings...). A procedure of the documentary system control must be formalized. The documentary system should be modeled in order to identify the various procedures to be drafted and the incurred risks in the case a document would be missing in this system. Each document must be indexed in a unique way and document management must be carried out rigorously. The use of document management software is a great help to manage the life cycle of documents.

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.

Impact of an electronic health record operating room management system in ophthalmology on documentation time, surgical volume, and staffing.

PubMed

Sanders, David S; Read-Brown, Sarah; Tu, Daniel C; Lambert, William E; Choi, Dongseok; Almario, Bella M; Yackel, Thomas R; Brown, Anna S; Chiang, Michael F

2014-05-01

Although electronic health record (EHR) systems have potential benefits, such as improved safety and quality of care, most ophthalmology practices in the United States have not adopted these systems. Concerns persist regarding potential negative impacts on clinical workflow. In particular, the impact of EHR operating room (OR) management systems on clinical efficiency in the ophthalmic surgery setting is unknown. To determine the impact of an EHR OR management system on intraoperative nursing documentation time, surgical volume, and staffing requirements. For documentation time and circulating nurses per procedure, a prospective cohort design was used between January 10, 2012, and January 10, 2013. For surgical volume and overall staffing requirements, a case series design was used between January 29, 2011, and January 28, 2013. This study involved ophthalmic OR nurses (n = 13) and surgeons (n = 25) at an academic medical center. Electronic health record OR management system implementation. (1) Documentation time (percentage of operating time documenting [POTD], absolute documentation time in minutes), (2) surgical volume (procedures/time), and (3) staffing requirements (full-time equivalents, circulating nurses/procedure). Outcomes were measured during a baseline period when paper documentation was used and during the early (first 3 months) and late (4-12 months) periods after EHR implementation. There was a worsening in total POTD in the early EHR period (83%) vs paper baseline (41%) (P < .001). This improved to baseline levels by the late EHR period (46%, P = .28), although POTD in the cataract group remained worse than at baseline (64%, P < .001). There was a worsening in absolute mean documentation time in the early EHR period (16.7 minutes) vs paper baseline (7.5 minutes) (P < .001). This improved in the late EHR period (9.2 minutes) but remained worse than in the paper baseline (P < .001). While cataract procedures required more circulating nurses in the early EHR (mean, 1.9 nurses/procedure) and late EHR (mean, 1.5 nurses/procedure) periods than in the paper baseline (mean, 1.0 nurses/procedure) (P < .001), overall staffing requirements and surgical volume were not significantly different between the periods. Electronic health record OR management system implementation was associated with worsening of intraoperative nursing documentation time especially in shorter procedures. However, it is possible to implement an EHR OR management system without serious negative impacts on surgical volume and staffing requirements.

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.

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.

Tank Monitoring and Document control System (TMACS) As Built Software Design Document

DOE Office of Scientific and Technical Information (OSTI.GOV)

GLASSCOCK, J.A.

This document describes the software design for the Tank Monitor and Control System (TMACS). This document captures the existing as-built design of TMACS as of November 1999. It will be used as a reference document to the system maintainers who will be maintaining and modifying the TMACS functions as necessary. The heart of the TMACS system is the ''point-processing'' functionality where a sample value is received from the field sensors and the value is analyzed, logged, or alarmed as required. This Software Design Document focuses on the point-processing functions.

Mission analysis for cross-site transfer

DOE Office of Scientific and Technical Information (OSTI.GOV)

Riesenweber, S.D.; Fritz, R.L.; Shipley, L.E.

1995-11-01

The Mission Analysis Report describes the requirements and constraints associated with the Transfer Waste Function as necessary to support the Manage Tank Waste, Retrieve Waste, and Process Tank Waste Functions described in WHC-SD-WM-FRD-020, Tank Waste Remediation System (TWRS) Functions and Requirements Document and DOE/RL-92-60, Revision 1, TWRS Functions and Requirements Document, March 1994. It further assesses the ability of the ``initial state`` (or current cross-site transfer system) to meet the requirements and constraints.

Human Research Program Requirements Document

NASA Technical Reports Server (NTRS)

Rieger, Gabe

2007-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.

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.

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.

Integrated information systems for electronic chemotherapy medication administration.

PubMed

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.

Quarantine provisions for unmanned extra-terrestrial missions

NASA Technical Reports Server (NTRS)

1976-01-01

This document sets forth requirements applicable to unmanned planetary flight programs which are necessary to enable the Associate Administrator for Space Science to fulfill those responsibilities pertaining to planetary quarantine as stated in NPD 8020.7 and NPD 8020.10A. This document is specifically directed to the control of terrestrial microbial contamination associated with unmanned space vehicles intended to encounter, orbit, flyby, or otherwise be in the vicinity of extra-terrestrial solar system bodies. The requirements of this document apply to all unmanned planetary flight programs. This includes solar system exploratory missions to the major planets as well as missions to planet satellites, or to other solar system objects that may be of scientific interest. This document is not applicable to terrestrial (including lunar) missions and manned missions. NASA officials having cognizance of applicable flight programs will invoke these requirements in such directives or contractual instruments as may be necessary to assure their implementation.

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.

System Definition Document

DOT National Transportation Integrated Search

1996-06-12

The Gary-Chicago-Milwaukee (GCM) Corridor Transportation Information Center : (C-TIC) System Definition Document describes the C-TIC concept and defines the : high level processes and dataflows. The Requirements Specification together : with the Inte...

48 CFR 52.247-52 - Clearance and Documentation Requirements-Shipments to DOD Air or Water Terminal Transshipment...

Code of Federal Regulations, 2013 CFR

2013-10-01

... 48 Federal Acquisition Regulations System 2 2013-10-01 2013-10-01 false Clearance and Documentation Requirements-Shipments to DOD Air or Water Terminal Transshipment Points. 52.247-52 Section 52.247-52 Federal Acquisition Regulations System FEDERAL ACQUISITION REGULATION (CONTINUED) CLAUSES AND FORMS SOLICITATION PROVISIONS AND CONTRACT CLAUSES...

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.

ISS Crew Transportation and Services Requirements Document

NASA Technical Reports Server (NTRS)

Bayt, Robert L. (Compiler); Lueders, Kathryn L. (Compiler)

2016-01-01

The ISS Crew Transportation and Services Requirements Document (CCT-REQ-1130) contains all technical, safety, and crew health medical requirements that are mandatory for achieving a Crew Transportation System Certification that will allow for International Space Station delivery and return of NASA crew and limited cargo. Previously approved on TN23183.

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.

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.

MARA (Multimode Airborne Radar Altimeter) system documentation. Volume 1: MARA system requirements document

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.

21 CFR 820.40 - Document controls.

Code of Federal Regulations, 2011 CFR

2011-04-01

... 21 Food and Drugs 8 2011-04-01 2011-04-01 false Document controls. 820.40 Section 820.40 Food and... QUALITY SYSTEM REGULATION Document Controls § 820.40 Document controls. Each manufacturer shall establish and maintain procedures to control all documents that are required by this part. The procedures shall...

21 CFR 820.40 - Document controls.

Code of Federal Regulations, 2014 CFR

2014-04-01

... 21 Food and Drugs 8 2014-04-01 2014-04-01 false Document controls. 820.40 Section 820.40 Food and... QUALITY SYSTEM REGULATION Document Controls § 820.40 Document controls. Each manufacturer shall establish and maintain procedures to control all documents that are required by this part. The procedures shall...

21 CFR 820.40 - Document controls.

Code of Federal Regulations, 2010 CFR

2010-04-01

... 21 Food and Drugs 8 2010-04-01 2010-04-01 false Document controls. 820.40 Section 820.40 Food and... QUALITY SYSTEM REGULATION Document Controls § 820.40 Document controls. Each manufacturer shall establish and maintain procedures to control all documents that are required by this part. The procedures shall...

21 CFR 820.40 - Document controls.

Code of Federal Regulations, 2013 CFR

2013-04-01

... 21 Food and Drugs 8 2013-04-01 2013-04-01 false Document controls. 820.40 Section 820.40 Food and... QUALITY SYSTEM REGULATION Document Controls § 820.40 Document controls. Each manufacturer shall establish and maintain procedures to control all documents that are required by this part. The procedures shall...

21 CFR 820.40 - Document controls.

Code of Federal Regulations, 2012 CFR

2012-04-01

... 21 Food and Drugs 8 2012-04-01 2012-04-01 false Document controls. 820.40 Section 820.40 Food and... QUALITY SYSTEM REGULATION Document Controls § 820.40 Document controls. Each manufacturer shall establish and maintain procedures to control all documents that are required by this part. The procedures shall...

Integrated Information Systems for Electronic Chemotherapy Medication Administration

PubMed Central

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

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.

Engineering Safety- and Security-Related Requirements for Software-Intensive Systems

DTIC Science & Technology

2010-04-27

Requirements Negative (shall not) Requirements Hardware Requirements equ remen s System / Documentation Requirements eve oper Requirements Operational ...Validation Actual / Proposed Defensibility C li Operational Vulnerability Analysis VulnerabilityVulnerability Safety Vulnerability performs System ...including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson

An electronic regulatory document management system for a clinical trial network.

PubMed

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.

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.

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.

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.

46 CFR 67.107 - System of measurement; evidence.

Code of Federal Regulations, 2013 CFR

2013-10-01

... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.107 System of measurement; evidence. (a) The gross and net tonnage and dimensions of a vessel for purposes of this part are...

46 CFR 67.107 - System of measurement; evidence.

Code of Federal Regulations, 2010 CFR

2010-10-01

... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.107 System of measurement; evidence. (a) The gross and net tonnage and dimensions of a vessel for purposes of this part are...

46 CFR 67.107 - System of measurement; evidence.

Code of Federal Regulations, 2014 CFR

2014-10-01

... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.107 System of measurement; evidence. (a) The gross and net tonnage and dimensions of a vessel for purposes of this part are...

46 CFR 67.107 - System of measurement; evidence.

Code of Federal Regulations, 2011 CFR

2011-10-01

... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.107 System of measurement; evidence. (a) The gross and net tonnage and dimensions of a vessel for purposes of this part are...

46 CFR 67.107 - System of measurement; evidence.

Code of Federal Regulations, 2012 CFR

2012-10-01

... DOCUMENTATION OF VESSELS Tonnage and Dimension Requirements for Vessel Documentation § 67.107 System of measurement; evidence. (a) The gross and net tonnage and dimensions of a vessel for purposes of this part are...

Intranet-based safety documentation in management of major hazards and occupational health and safety.

PubMed

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.

Developing an Interface to Order and Document Health Education Videos in the Electronic Health Record.

PubMed

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.

Emergency Response Capability Baseline Needs Assessment Compliance Assessment

DOE Office of Scientific and Technical Information (OSTI.GOV)

Sharry, John A.

2013-09-16

This document is the second of a two-part analysis of Emergency Response Capabilities of Lawrence Livermore National Laboratory. The first part, 2013 Baseline Needs Assessment Requirements Document established the minimum performance criteria necessary to meet mandatory requirements. This second part analyses the performance of Lawrence Livermore Laboratory Emergency Management Department to the contents of the Requirements Document. The document was prepared based on an extensive review of information contained in the 2009 BNA, the 2012 BNA document, a review of Emergency Planning Hazards Assessments, a review of building construction, occupancy, fire protection features, dispatch records, LLNL alarm system records, firemore » department training records, and fire department policies and procedures.« less

Dynamic mobility applications open source application development portal : Task 4 : system requirements specifications : final report.

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...

STS-2: SAIL non-avionics subsystems math model requirements

NASA Technical Reports Server (NTRS)

Bennett, W. P.; Herold, R. W.

1980-01-01

Simulation of the STS-2 Shuttle nonavionics subsystems in the shuttle avionics integration laboratory (SAIL) is necessary for verification of the integrated shuttle avionics system. The math model (simulation) requirements for each of the nonavionics subsystems that interfaces with the Shuttle avionics system is documented and a single source document for controlling approved changes (by the SAIL change control panel) to the math models is provided.

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.

45 CFR 307.0 - Scope of this part.

Code of Federal Regulations, 2010 CFR

2010-10-01

...) The requirement for computerized support enforcement systems; (b) The functional requirements that a statewide computerized support enforcement system must meet; (c) Security and confidentiality requirements... to approving an advance planning document (APD); (e) The requirements and procedures for the...

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.

Live Virtual Constructive (LVC): Interface Control Document (ICD) for the LVC Gateway. [Flight Test 3

NASA Technical Reports Server (NTRS)

Jovic, Srba

2015-01-01

This Interface Control Document (ICD) documents and tracks the necessary information required for the Live Virtual and Constructive (LVC) systems components as well as protocols for communicating with them in order to achieve all research objectives captured by the experiment requirements. The purpose of this ICD is to clearly communicate all inputs and outputs from the subsystem components.

Universal Documentation System Handbook. Volume 2. Requirement Formats and Instructions; Program Introduction, Program Requirements Document/Operations Requirements

DTIC Science & Technology

1989-08-01

and the local horizontal plane, measured positive above the horizontal plane. The local horizontal plane is defined as a plane normal to the geocentric ...preparation instructions for Format 1000. LOCATION: Enter the areas or locations that are to be staffed with medical personnel, i.e., Vandenberg AFB

The Algorithm Theoretical Basis Document for Level 1A Processing

NASA Technical Reports Server (NTRS)

Jester, Peggy L.; Hancock, David W., III

2012-01-01

The first process of the Geoscience Laser Altimeter System (GLAS) Science Algorithm Software converts the Level 0 data into the Level 1A Data Products. The Level 1A Data Products are the time ordered instrument data converted from counts to engineering units. This document defines the equations that convert the raw instrument data into engineering units. Required scale factors, bias values, and coefficients are defined in this document. Additionally, required quality assurance and browse products are defined in this document.

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.

Detailed requirements document for the problem reporting data system (PDS). [space shuttle and batch processing

NASA Technical Reports Server (NTRS)

West, R. S.

1975-01-01

The system is described as a computer-based system designed to track the status of problems and corrective actions pertinent to space shuttle hardware. The input, processing, output, and performance requirements of the system are presented along with standard display formats and examples. Operational requirements, hardware, requirements, and test requirements are also included.

Connected Vehicle Pilot Deployment Program phase 1 : System Requirements Specification (SyRS) : Tampa (THEA) : final report.

DOT National Transportation Integrated Search

2016-08-01

This document describes the System Requirements Specification (SyRS) for the Tampa Hillsborough Expressway Authority (THEA) Connected Vehicle (CV) Pilot Deployment. This SyRS describes the current system requirements derived from the user needs, Conc...

Human machine interface display design document.

DOT National Transportation Integrated Search

2008-01-01

The purpose of this document is to describe the design for the human machine interface : (HMI) display for the Next Generation 9-1-1 (NG9-1-1) System (or system of systems) : based on the initial Tier 1 requirements identified for the NG9-1-1 S...

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.

Improved Emergency Egress Lighting System for the ISS

NASA Technical Reports Server (NTRS)

Eaton, Leslie L.; Barr, Don A.

2005-01-01

Emergency lights provide illumination in corridors, stairwells, ramps, escalators, aisles, and exit passageways during power failures. Safety and visibility are critical during a power outage. If emergency lights fail to operate properly, the building occupants can become disoriented. Four documents in a collection discuss different topics relating to a proposed improved emergency egress lighting system (EELS) for the International Space Station (ISS). While the present EELS is designed around rows of green-light-emitting diodes, the proposed system contains strips of electroluminescent tape using different colors for each egress path. The proposed EELS can be powered by the same battery currently used by the present EELS, but would require an inverter because electroluminescent devices require AC. Electroluminescent devices also require significantly less current and, depending on the color, would emit 3 to 8 times the light of the present EELS. In addition, they could operate for up to 75 hours (versus .20 minutes for the present system). The first document contains a one-page summary of the proposal and an evaluation of technical merit. The second document summarizes the motivation for, and the design of, the proposed EELS. The third document addresses relevant aspects of the measurement of spectral sensitivity and the psychophysics of perception of light. The fourth document presents additional background information and technical specifications for the electroluminescent tapes.

Critical Characteristics of Radiation Detection System Components to be Dedicated for use in Safety Class and Safety Significant System

DOE Office of Scientific and Technical Information (OSTI.GOV)

DAVIS, S.J.

2000-05-25

This document identifies critical characteristics of components to be dedicated for use in Safety Class (SC) or Safety Significant (SS) Systems, Structures, or Components (SSCs). This document identifies the requirements for the components of the common radiation area monitor alarm in the WESF pool cell. These are procured as Commercial Grade Items (CGI), with the qualification testing and formal dedication to be performed at the Waste Encapsulation Storage Facility (WESF), in safety class, safety significant systems. System modifications are to be performed in accordance with the instructions provided on ECN 658230. Components for this change are commercially available and interchangeablemore » with the existing alarm configuration This document focuses on the operational requirements for alarm, declaration of the safety classification, identification of critical characteristics, and interpretation of requirements for procurement. Critical characteristics are identified herein and must be verified, followed by formal dedication, prior to the components being used in safety related applications.« less

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

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

XML and its impact on content and structure in electronic health care documents.

PubMed Central

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

Modern Corneal Eye-Banking Using a Software-Based IT Management Solution.

PubMed

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.

System-Inspection Guidelines for Minnesota PK-12 School Construction Projects.

ERIC Educational Resources Information Center

Minnesota State Dept. of Children, Families, and Learning, St. Paul.

This document describes a 1998 commissioning statute passed by the Minnesota legislature requiring that mechanical HVAC systems undergo an inspection process to uncover and rectify problems before or shortly after a school building is occupied. The document presents the statute, describes the commissioning/system-inspection process and optional…

[Quality management and strategic consequences of assessing documentation and coding under the German Diagnostic Related Groups system].

PubMed

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.

40 CFR 63.181 - Recordkeeping requirements.

Code of Federal Regulations, 2014 CFR

2014-07-01

... subpart. Individual components in an instrumentation system need not be identified. (5) Identification of... subpart, and documentation of the integrity of the weld for any removed connectors, as required in § 63... that is subject to the provisions of this subpart. Examples of suitable documentation are records of...

40 CFR 63.181 - Recordkeeping requirements.

Code of Federal Regulations, 2013 CFR

2013-07-01

... subpart. Individual components in an instrumentation system need not be identified. (5) Identification of... subpart, and documentation of the integrity of the weld for any removed connectors, as required in § 63... that is subject to the provisions of this subpart. Examples of suitable documentation are records of...

40 CFR 63.181 - Recordkeeping requirements.

Code of Federal Regulations, 2012 CFR

2012-07-01

... subpart. Individual components in an instrumentation system need not be identified. (5) Identification of... subpart, and documentation of the integrity of the weld for any removed connectors, as required in § 63... that is subject to the provisions of this subpart. Examples of suitable documentation are records of...

Open Source Patient-Controlled Analgesic Pump Requirements Documentation

PubMed Central

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 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

Solid Waste Program technical baseline description

DOE Office of Scientific and Technical Information (OSTI.GOV)

Carlson, A.B.

1994-07-01

The system engineering approach has been taken to describe the technical baseline under which the Solid Waste Program is currently operating. The document contains a mission analysis, function analysis, system definition, documentation requirements, facility and project bases, and uncertainties facing the program.

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...

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.

NASA Construction of Facilities Validation Processes - Total Building Commissioning (TBCx)

NASA Technical Reports Server (NTRS)

Hoover, Jay C.

2004-01-01

Key Atributes include: Total Quality Management (TQM) System that looks at all phases of a project. A team process that spans boundaries. A Commissioning Authority to lead the process. Commissioning requirements in contracts. Independent design review to verify compliance with Facility Project Requirements (FPR). Formal written Commissioning Plan with Documented Results. Functional performance testing (FPT) against the requirements document.

Universal Documentation System Handbook. Volume 2. Requirement Formats and Instructions, Program Introduction, Program Requirements Document/Operations Requirements.

DTIC Science & Technology

1989-08-01

horizontal plane is defined as a plane normal to the geocentric position vector. Inertial Azimuth Heading Angle entries are the angles measured east of north...0CATICN: Enter the areas or locations that are to be staffed with redical perscnel, i.e., Vandenberg AFB Hospital, PMIC; or offshore boats, etc. NUMB

Review and comparison of quality standards, guidelines and regulations for laboratories.

PubMed

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.

Definition and means of maintaining the criticality detectors and alarms portion of the PFP safety envelope

DOE Office of Scientific and Technical Information (OSTI.GOV)

White, W.F.

The purpose of this document is to provide the definition and means of maintaining the Safety Envelope (SE) related to the Criticality Alarm System (CAS). This document provides amplification of the Limiting Condition for Operation (LCO) described in the Plutonium Finishing Plant (PFP) Operational Safety Requirements (OSR), WHC-SD-CP-OSR-010, Rev. 0, 1994, Section 3.1.2, Criticality Detectors and Alarms. This document, with its appendices, provides the following: (1) System functional requirements for determining system operability (Section 3); (2) A list of annotated system block diagrams which indicate the safety envelope boundaries (Appendix C); (3) A list of the Safety Class 1 andmore » 2 Safety Envelope (SC-1/2 SE) equipment for input into the Master Component Index (Appendix B); (4) Functional requirements for individual SC-1/2 SE components, including appropriate setpoints and process parameters (Section 6 and Appendix A); (5) A list of the operational, maintenance and surveillance procedures necessary to operate and maintain the SC-1/2 SE components as required by the LCO (Section 6 and Appendix A).« less

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.

Functions and requirements for tank farm restoration and safe operations, Project W-314. Revision 3

DOE Office of Scientific and Technical Information (OSTI.GOV)

Garrison, R.C.

1995-02-01

This Functions and Requirements document (FRD) establishes the basic performance criteria for Project W-314, in accordance with the guidance outlined in the letter from R.W. Brown, RL, to President, WHC, ``Tank Waste Remediation System (TWRS) Project Documentation Methodology,`` 94-PRJ-018, dated 3/18/94. The FRD replaces the Functional Design Criteria (FDC) as the project technical baseline documentation. Project W-314 will improve the reliability of safety related systems, minimize onsite health and safety hazards, and support waste retrieval and disposal activities by restoring and/or upgrading existing Tank Farm facilities and systems. The scope of Project W-314 encompasses the necessary restoration upgrades of themore » Tank Farms` instrumentation, ventilation, electrical distribution, and waste transfer systems.« less

Computer program for design and performance analysis of navigation-aid power systems. Program documentation. Volume 1: Software requirements document

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.

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.

39 CFR 3001.10 - Form and number of copies of documents.

Code of Federal Regulations, 2014 CFR

2014-07-01

... document filed with the Commission must be submitted through Filing Online by an account holder, unless a... Filing Online. (3) The form of documents filed as library references is governed by § 3001.31(b)(2)(iv). (4) Documents filed online must satisfy Filing Online system compatibility requirements specified by...

39 CFR 3001.10 - Form and number of copies of documents.

Code of Federal Regulations, 2013 CFR

2013-07-01

... document filed with the Commission must be submitted through Filing Online by an account holder, unless a... Filing Online. (3) The form of documents filed as library references is governed by § 3001.31(b)(2)(iv). (4) Documents filed online must satisfy Filing Online system compatibility requirements specified by...

Space Telecommunications Radio System (STRS) Application Repository Design and Analysis

NASA Technical Reports Server (NTRS)

Handler, Louis M.

2013-01-01

The Space Telecommunications Radio System (STRS) Application Repository Design and Analysis document describes the STRS application repository for software-defined radio (SDR) applications intended to be compliant to the STRS Architecture Standard. The document provides information about the submission of artifacts to the STRS application repository, to provide information to the potential users of that information, and for the systems engineer to understand the requirements, concepts, and approach to the STRS application repository. The STRS application repository is intended to capture knowledge, documents, and other artifacts for each waveform application or other application outside of its project so that when the project ends, the knowledge is retained. The document describes the transmission of technology from mission to mission capturing lessons learned that are used for continuous improvement across projects and supporting NASA Procedural Requirements (NPRs) for performing software engineering projects and NASAs release process.

76 FR 61937 - Practice and Procedure: Rules of General Application, Safeguards, Antidumping and Countervailing...

Federal Register 2010, 2011, 2012, 2013, 2014

2011-10-06

... System Web site at https://edis.usitc.gov . Failure to comply with the requirements of this chapter and... Electronic Document Information System (EDIS) already accepts electronic filing of certain documents, and..., regardless of whether the electronic docketing system is operational. The ITC TLA makes a similar comment...

Saint Lawrence Seaway Navigation-Aid System Study : Volume III - Appendix C - User's Manual and Documentation of the Ship Maneuvering Requirements Computer Program

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...

Collision Avoidance Functional Requirements for Step 1. Revision 6

NASA Technical Reports Server (NTRS)

2006-01-01

This Functional Requirements Document (FRD) describes the flow of requirements from the high level operational objectives down to the functional requirements specific to cooperative collision avoidance for high altitude, long endurance unmanned aircraft systems. These are further decomposed into performance and safety guidelines that are backed up by analysis or references to various documents or research findings. The FRD should be considered when establishing future policies, procedures, and standards pertaining to cooperative collision avoidance.

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.

Flight design system-1 system design. Volume 5: Data management and data base documentation support system. [for shuttle flight planning

NASA Technical Reports Server (NTRS)

1979-01-01

Application software intended to reduce the man-hours required per flight design cycle by producing major flight design documents with little or no manual typing is described. The documentation support software is divided into two separately executable processors. However, since both processors support the same overall functions, and most of the software contained in one is also contained in the other, both are collectively presented.

Smart roadside initiative : system requirements specifications.

DOT National Transportation Integrated Search

2015-09-01

This document describes the system requirements specifications (SyRS) for the Smart Roadside Initiative (SRI) Prototype for the delivery of capabilities related to wireless roadside inspections, electronic screening/virtual weigh stations, universal ...

Prototype development and demonstration for response, emergency staging, communications, uniform management, and evacuation (R.E.S.C.U.M.E.) : R.E.S.C.U.M.E. final functional and performance requirements.

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....

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.

Requirements Analysis Study for Master Pump Shutdown System Project Development Specification [SEC 1 and 2

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

Design of the SGML-based electronic patient record system with the use of object-oriented analysis methods.

PubMed

Kuikka, E; Eerola, A; Porrasmaa, J; Miettinen, A; Komulainen, J

1999-01-01

Since a patient record is typically a document updated by many users, required to be represented in many different layouts, and transferred from place to place, it is a good candidate to be represented structured and coded using the SGML document standard. The use of the SGML requires that the structure of the document is defined in advance by a Document Type Definition (DTD) and the document follows it. This paper represents a method which derives an SGML DTD by starting from the description of the usage of the patient record in medical care and nursing.

6 CFR 37.13 - Document verification requirements.

Code of Federal Regulations, 2010 CFR

2010-01-01

... required under § 37.11 with the issuer of the document. States shall use systems for electronic validation... process is not warranted in the situation, the DMV must not issue a REAL ID driver's license or... authentic upon inspection or the data does not match and the use of an exceptions process is not warranted...

6 CFR 37.13 - Document verification requirements.

Code of Federal Regulations, 2012 CFR

2012-01-01

... required under § 37.11 with the issuer of the document. States shall use systems for electronic validation... process is not warranted in the situation, the DMV must not issue a REAL ID driver's license or... authentic upon inspection or the data does not match and the use of an exceptions process is not warranted...

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.

I-880 Integrated Corridor Management ICM System Requirements : Final Submittal : System Requirement Specification for the I-880 Corridor in Oakland, California

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...

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…

System requirement specification for the I-15 integrated corridor management system (ICMS) in San Diego, California.

DOT National Transportation Integrated Search

2008-03-31

This document presents a System Requirement Specification for an Integrated Corridor Management System (ICMS) in the I-15 Corridor in San Diego, California. The ICMS will consist of two major subsystems: the existing Intermodal Transportation Managem...

System configuration management plan for 101-SY Hydrogen Mitigation Test Project Mini-Data Acquisition and Control System of Tank Waste Remediation System

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

The paper crisis: from hospitals to medical practices.

PubMed

Park, Gregory; Neaveill, Rodney S

2009-01-01

Hospitals, not unlike physician practices, are faced with an increasing burden of managing piles of hard copy documents including insurance forms, requests for information, and advance directives. Healthcare organizations are moving to transform paper-based forms and documents into digitized files in order to save time and money and to have those documents available at a moment's notice. The cost of these document management/imaging systems can be easily justified with the significant savings of resources realized from the implementation of these systems. This article illustrates the enormity of the "paper problem" in healthcare and outlines just a few of the required processes that could be improved with the use of automated document management/imaging systems.

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.

Solid waste information and tracking system server conversion project management plan

DOE Office of Scientific and Technical Information (OSTI.GOV)

MAY, D.L.

1999-04-12

The Project Management Plan governing the conversion of Solid Waste Information and Tracking System (SWITS) to a client-server architecture. The Solid Waste Information and Tracking System Project Management Plan (PMP) describes the background, planning and management of the SWITS conversion. Requirements and specification documentation needed for the SWITS conversion will be released as supporting documents.

Implementation Procedure for STS Payloads, System Safety Requirements

NASA Technical Reports Server (NTRS)

1979-01-01

Guidelines and instructions for the implementation of the SP&R system safety requirements applicable to STS payloads are provided. The initial contact meeting with the payload organization and the subsequent safety reviews necessary to comply with the system safety requirements of the SP&R document are described. Waiver instructions are included for the cases in which a safety requirement cannot be met.

Automated search and retrieval of information from imaged documents using optical correlation techniques

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.

Systems Operation Studies for Automated Guideway Transit Systems: Feeder Systems Model Functional Specification

DOT National Transportation Integrated Search

1981-01-01

This document specifies the functional requirements for the AGT-SOS Feeder Systems Model (FSM), the type of hardware required, and the modeling techniques employed by the FSM. The objective of the FSM is to map the zone-to-zone transit patronage dema...

Document Storage and Retrieval in the Electronic Office.

ERIC Educational Resources Information Center

Ashford, John

1985-01-01

Proposals are made for practical approaches to the design of electronic office systems to provide for the effective storage and retrieval of the documents that they generate. Problems of records management and requirements to be met by the designer of an electronic office system are highlighted. Nineteen references are cited. (EJS)

Designing Control System Application Software for Change

NASA Technical Reports Server (NTRS)

Boulanger, Richard

2001-01-01

The Unified Modeling Language (UML) was used to design the Environmental Systems Test Stand (ESTS) control system software. The UML was chosen for its ability to facilitate a clear dialog between software designer and customer, from which requirements are discovered and documented in a manner which transposes directly to program objects. Applying the UML to control system software design has resulted in a baseline set of documents from which change and effort of that change can be accurately measured. As the Environmental Systems Test Stand evolves, accurate estimates of the time and effort required to change the control system software will be made. Accurate quantification of the cost of software change can be before implementation, improving schedule and budget accuracy.

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.

DOE Office of Scientific and Technical Information (OSTI.GOV)

Guyer, H.B.; McChesney, C.A.

The overall primary Objective of HDAR is to create a repository of historical personnel security documents and provide the functionality needed for archival and retrieval use by other software modules and application users of the DISS/ET system. The software product to be produced from this specification is the Historical Document Archival and Retrieval Subsystem The product will provide the functionality to capture, retrieve and manage documents currently contained in the personnel security folders in DOE Operations Offices vaults at various locations across the United States. The long-term plan for DISS/ET includes the requirement to allow for capture and storage ofmore » arbitrary, currently undefined, clearance-related documents that fall outside the scope of the ``cradle-to-grave`` electronic processing provided by DISS/ET. However, this requirement is not within the scope of the requirements specified in this document.« less

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.

Fort Hood Solar Total Energy Project. Volume II. Preliminary design. Part 1. System criteria and design description. Final report

DOE Office of Scientific and Technical Information (OSTI.GOV)

None,

1979-01-01

This volume documents the preliminary design developed for the Solar Total Energy System to be installed at Fort Hood, Texas. Current system, subsystem, and component designs are described and additional studies which support selection among significant design alternatives are presented. Overall system requirements which form the system design basis are presented. These include program objectives; performance and output load requirements; industrial, statutory, and regulatory standards; and site interface requirements. Material in this section will continue to be issued separately in the Systems Requirements Document and maintained current through revision throughout future phases of the project. Overall system design and detailedmore » subsystem design descriptions are provided. Consideration of operation and maintenance is reflected in discussion of each subsystem design as well as in an integrated overall discussion. Included are the solar collector subsystem; the thermal storage subsystem, the power conversion sybsystem (including electrical generation and distribution); the heating/cooling and domestic hot water subsystems; overall instrumentation and control; and the STES building and physical plant. The design of several subsystems has progressed beyond the preliminary stage; descriptions for such subsystems are therefore provided in more detail than others to provide complete documentation of the work performed. In some cases, preliminary design parameters require specific verificaton in the definitive design phase and are identified in the text. Subsystem descriptions will continue to be issued and revised separately to maintain accuracy during future phases of the project. (WHK)« less

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.

W-320 Department of Health documentation

DOE Office of Scientific and Technical Information (OSTI.GOV)

Bailey, J.W.

1998-08-07

The purpose of this document is to gather information required to show that Project W-320 is in compliance with Washington State Department of Health requirements as specified in Radioactive Air Emissions Notice of Construction Project W-320, Tank 241-C-106 Sluicing, DOE/RL-95-45. Specifically, that W-320 is in compliance with ASME N509-1989 (Nuclear Power Plant Air-Cleaning Units and Components) and ASME N5 10-1989 (Testing of Nuclear Air Treatment Systems) for the 296-C-006 exhaust system.

Usage experience with the document archiving and communication system for the storage and retrieval of medical records.

PubMed

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.

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.

Facilitating NASA's Use of GEIA-STD-0005-1, Performance Standard for Aerospace and High Performance Electronic Systems Containing Lead-Free Solder

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.

Universal Documentation System Handbook. Volume 2: Program Requirements and Operations Requirements Documents

DTIC Science & Technology

1979-11-01

plane. The local horizontal plane is de- lined as a plane normal to the geocentric position vector. Boxes 11J and UJ are the angles measured east...support the program/mission. BOX 1-9 Follow instructions for Pa«« 1010. BOX 10 LOCATION: Enter the areas or locations that are to be staffed with

76 FR 49303 - Approval and Promulgation of Air Quality Implementation Plans; Minnesota; Rules Update

Federal Register 2010, 2011, 2012, 2013, 2014

2011-08-10

... design requirements for the monitoring systems. The revised CMS rules also delineate the recordkeeping..., [Insert page number where the document begins]. 7017.1140 CEMS design 03/01/99 08/10/11, [Insert page...]. 7017.1190 COMS design 03/01/99 08/10/11, [Insert page requirements. number where the document begins...

Tire pressure special study : data documentation

DOT National Transportation Integrated Search

2002-01-01

In 2000, Congress passed the Transportation Recall Enhancement, Accountability, and : Documentation (TREAD) Act. Section 12 of this act directed the Department of Transportation : to complete a rulemaking requiring implementation of a warning system ...

[Problems encountered during the installation of an automated anesthesia documentation system (AIMS)].

PubMed

Müller, H; Naujoks, F; Dietz, S

2002-08-01

Problems encountered during the installation and introduction of an automated anaesthesia documentation system are discussed. Difficulties have to be expected in the area of staff training because of heterogeneous experience in computer usage and in the field of online documentation of vital signs. Moreover the areas of net administration and hardware configuration as well as general administrative issues also represent possible sources of drawbacks. System administration and reliable support provided by personnel of the department of anaesthesiology assuring staff motivation and reducing time of system failures require adequately staffed departments. Based on our own experiences, we recommend that anaesthesiology departments considering the future installation and use of an automated anaesthesia documentation system should verify sufficient personnel capacities prior to their decision.

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.

5 CFR 1216.203 - Filing requirements for litigants seeking documents or testimony.

Code of Federal Regulations, 2010 CFR

2010-01-01

... documents or testimony. 1216.203 Section 1216.203 Administrative Personnel MERIT SYSTEMS PROTECTION BOARD... OFFICIAL RECORDS IN LEGAL PROCEEDINGS Demands or Requests for Testimony and Production of Documents § 1216... written request must contain the following information: (1) The caption of the legal proceeding, docket...

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

Medical Treatment Facility Workload Documentation Guide.

DTIC Science & Technology

1980-04-15

to the system implementation should be presented. This document is intended as a guidebook for determining the site specific characteristics of an...wide volume analysis of a communications system. Prior to collecting any data, objectives and initial operating characteristics of the system(s...unique characteristics involved. An on-site inspection of all spaces to be impacted by NIS implementation is required initially. During this inspection

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.

Urban mass transportation industry uniform system of accounts and records and reporting system. Volume III. Reporting system forms and instructions--required.

DOT National Transportation Integrated Search

1977-01-10

The purpose of the report is to present and document the detailed features of the uniform system of accounts and records and reporting system required by Section 15 of the Urban Mass Transportation Act of 1964, as amended. Volume 3 contains illustrat...

Universal computer test stand (recommended computer test requirements). [for space shuttle computer evaluation

NASA Technical Reports Server (NTRS)

1973-01-01

Techniques are considered which would be used to characterize areospace computers with the space shuttle application as end usage. The system level digital problems which have been encountered and documented are surveyed. From the large cross section of tests, an optimum set is recommended that has a high probability of discovering documented system level digital problems within laboratory environments. Defined is a baseline hardware, software system which is required as a laboratory tool to test aerospace computers. Hardware and software baselines and additions necessary to interface the UTE to aerospace computers for test purposes are outlined.

Assured crew return vehicle man-systems integration standards

NASA Technical Reports Server (NTRS)

1991-01-01

This is Volume 6 of the Man-Systems Integration Standards (MSIS) family of documents, which is contained in several volumes and a relational database. Each volume has a specific purpose, and each has been assembled from the data contained in the relational database. Volume 6 serves as the Assured Crew Return Vehicle project man-systems integration design requirements. The data in this document is a subset of the data found in Volume 1 and defines the requirements which are pertinent to the Assured Crew Return Vehicle as defined in the SPRD. Additional data and guidelines are provided to assist in the design.

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.

USDOT Guidance Summary for Connected Vehicle Deployments : System Requirements and the CVRIA/Set-It Tool : Final Report

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...

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.

A nursing-specific model of EPR documentation: organizational and professional requirements.

PubMed

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.

Structural Design Requirements and Factors of Safety for Spaceflight Hardware: For Human Spaceflight. Revision A

NASA Technical Reports Server (NTRS)

Bernstein, Karen S.; Kujala, Rod; Fogt, Vince; Romine, Paul

2011-01-01

This document establishes the structural requirements for human-rated spaceflight hardware including launch vehicles, spacecraft and payloads. These requirements are applicable to Government Furnished Equipment activities as well as all related contractor, subcontractor and commercial efforts. These requirements are not imposed on systems other than human-rated spacecraft, such as ground test articles, but may be tailored for use in specific cases where it is prudent to do so such as for personnel safety or when assets are at risk. The requirements in this document are focused on design rather than verification. Implementation of the 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 SVP may also document unique verifications that meet or exceed these requirements with NASA Technical Authority approval.

Formal Verification of Complex Systems based on SysML Functional Requirements

DTIC Science & Technology

2014-12-23

Formal Verification of Complex Systems based on SysML Functional Requirements Hoda Mehrpouyan1, Irem Y. Tumer2, Chris Hoyle2, Dimitra Giannakopoulou3...requirements for design of complex engineered systems. The proposed ap- proach combines a SysML modeling approach to document and structure safety requirements...methods and tools to support the integration of safety into the design solution. 2.1. SysML for Complex Engineered Systems Traditional methods and tools

12 CFR 611.1216 - Public availability of documents related to the termination.

Code of Federal Regulations, 2010 CFR

2010-01-01

... termination. 611.1216 Section 611.1216 Banks and Banking FARM CREDIT ADMINISTRATION FARM CREDIT SYSTEM ORGANIZATION Termination of System Institution Status § 611.1216 Public availability of documents related to the termination. (a) We may post on our Web site, or require you to post on your Web site: (1) Results...

The Wildland Fire Decision Support System: Integrating science, technology, and fire management

Treesearch

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)....

MODIS. Volume 1: MODIS level 1A software baseline requirements

NASA Technical Reports Server (NTRS)

Masuoka, Edward; Fleig, Albert; Ardanuy, Philip; Goff, Thomas; Carpenter, Lloyd; Solomon, Carl; Storey, James

1994-01-01

This document describes the level 1A software requirements for the moderate resolution imaging spectroradiometer (MODIS) instrument. This includes internal and external requirements. Internal requirements include functional, operational, and data processing as well as performance, quality, safety, and security engineering requirements. External requirements include those imposed by data archive and distribution systems (DADS); scheduling, control, monitoring, and accounting (SCMA); product management (PM) system; MODIS log; and product generation system (PGS). Implementation constraints and requirements for adapting the software to the physical environment are also included.

Baseline Design Compliance Matrix for the Rotary Mode Core Sampling System

DOE Office of Scientific and Technical Information (OSTI.GOV)

LECHELT, J.A.

2000-10-17

The purpose of the design compliance matrix (DCM) is to provide a single-source document of all design requirements associated with the fifteen subsystems that make up the rotary mode core sampling (RMCS) system. It is intended to be the baseline requirement document for the RMCS system and to be used in governing all future design and design verification activities associated with it. This document is the DCM for the RMCS system used on Hanford single-shell radioactive waste storage tanks. This includes the Exhauster System, Rotary Mode Core Sample Trucks, Universal Sampling System, Diesel Generator System, Distribution Trailer, X-Ray Cart System,more » Breathing Air Compressor, Nitrogen Supply Trailer, Casks and Cask Truck, Service Trailer, Core Sampling Riser Equipment, Core Sampling Support Trucks, Foot Clamp, Ramps and Platforms and Purged Camera System. Excluded items are tools such as light plants and light stands. Other items such as the breather inlet filter are covered by a different design baseline. In this case, the inlet breather filter is covered by the Tank Farms Design Compliance Matrix.« less

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...

18 CFR 35.9 - Requirements for filing rate schedules, tariffs or service agreements.

Code of Federal Regulations, 2010 CFR

2010-04-01

... entire document except as provided in paragraphs (b) and (c) of this section. (b) Open Access...) OATT and other open access documents filed by Independent System Operators or Regional Transmission...

18 CFR 35.9 - Requirements for filing rate schedules, tariffs or service agreements.

Code of Federal Regulations, 2011 CFR

2011-04-01

... entire document except as provided in paragraphs (b) and (c) of this section. (b) Open Access...) OATT and other open access documents filed by Independent System Operators or Regional Transmission...

Contingency Management Requirements Document: Preliminary Version. Revision F

NASA Technical Reports Server (NTRS)

2005-01-01

This is the High Altitude, Long Endurance (HALE) Remotely Operated Aircraft (ROA) Contingency Management (CM) Functional Requirements document. This document applies to HALE ROA operating within the National Airspace System (NAS) limited at this time to enroute operations above 43,000 feet (defined as Step 1 of the Access 5 project, sponsored by the National Aeronautics and Space Administration). A contingency is an unforeseen event requiring a response. The unforeseen event may be an emergency, an incident, a deviation, or an observation. Contingency Management (CM) is the process of evaluating the event, deciding on the proper course of action (a plan), and successfully executing the plan.

Emergency Response Capability Baseline Needs Assessment - Compliance Assessment

DOE Office of Scientific and Technical Information (OSTI.GOV)

Sharry, John A.

This document was prepared by John A. Sharry, LLNL Fire Marshal and Division Leader for Fire Protection and was reviewed by LLNL Emergency Management Department Head, James Colson. This document is the second of a two-part analysis on Emergency Response Capabilities of Lawrence Livermore National Laboratory. The first part, 2016 Baseline Needs Assessment Requirements Document established the minimum performance criteria necessary to meet mandatory requirements. This second part analyses the performance of Lawrence Livermore Laboratory Emergency Management Department to the contents of the Requirements Document. The document was prepared based on an extensive review of information contained in the 2016more » BNA, a review of Emergency Planning Hazards Assessments, a review of building construction, occupancy, fire protection features, dispatch records, LLNL alarm system records, fire department training records, and fire department policies and procedures. The 2013 BNA was approved by NNSA’s Livermore Field Office on January 22, 2014.« less

Space station system analysis study. Part 3: Documentation. Volume 2: Technical report. [structural design and construction

NASA Technical Reports Server (NTRS)

1977-01-01

An analysis of construction operation is presented as well as power system sizing requirements. Mission hardware requirements are reviewed in detail. Space construction base and design configurations are also examined.

FORTRAN Automated Code Evaluation System (faces) system documentation, version 2, mod 0. [error detection codes/user manuals (computer programs)

NASA Technical Reports Server (NTRS)

1975-01-01

A system is presented which processes FORTRAN based software systems to surface potential problems before they become execution malfunctions. The system complements the diagnostic capabilities of compilers, loaders, and execution monitors rather than duplicating these functions. Also, it emphasizes frequent sources of FORTRAN problems which require inordinate manual effort to identify. The principle value of the system is extracting small sections of unusual code from the bulk of normal sequences. Code structures likely to cause immediate or future problems are brought to the user's attention. These messages stimulate timely corrective action of solid errors and promote identification of 'tricky' code. Corrective action may require recoding or simply extending software documentation to explain the unusual technique.

National Counterdrug Center (NCC) Simulation System Operational Requirements Document (ORD) Version 2

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

ATMS concept of operations and generic system requirements : task B : final interim report for design of support systems for advanced traffic management systems

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...

High-level waste storage tank farms/242-A evaporator standards/requirements identification document (S/RID), Vol. 7

DOE Office of Scientific and Technical Information (OSTI.GOV)

Not Available

1994-04-01

This Requirements Identification Document (RID) describes an Occupational Health and Safety Program as defined through the Relevant DOE Orders, regulations, industry codes/standards, industry guidance documents and, as appropriate, good industry practice. The definition of an Occupational Health and Safety Program as specified by this document is intended to address Defense Nuclear Facilities Safety Board Recommendations 90-2 and 91-1, which call for the strengthening of DOE complex activities through the identification and application of relevant standards which supplement or exceed requirements mandated by DOE Orders. This RID applies to the activities, personnel, structures, systems, components, and programs involved in maintaining themore » facility and executing the mission of the High-Level Waste Storage Tank Farms.« less

Crew Transportation Technical Management Processes

NASA Technical Reports Server (NTRS)

Mckinnie, John M. (Compiler); Lueders, Kathryn L. (Compiler)

2013-01-01

Under the guidance of processes provided by Crew Transportation Plan (CCT-PLN-1100), this document, with its sister documents, International Space Station (ISS) Crew Transportation and Services Requirements Document (CCT-REQ-1130), Crew Transportation Technical Standards and Design Evaluation Criteria (CCT-STD-1140), Crew Transportation Operations Standards (CCT STD-1150), and ISS to Commercial Orbital Transportation Services Interface Requirements Document (SSP 50808), provides the basis for a National Aeronautics and Space Administration (NASA) certification for services to the ISS for the Commercial Provider. When NASA Crew Transportation System (CTS) certification is achieved for ISS transportation, the Commercial Provider will be eligible to provide services to and from the ISS during the services phase.

GCS programmer's manual

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.

STV engine design considerations

NASA Technical Reports Server (NTRS)

1991-01-01

The topics covered include the following: (1) engine design criteria and issues; (2) design requirements for man rating; (3) test requirements for man rating; (4) design requirements for space basing; (5) engine operation requirements; (6) health monitoring; (7) lunar transfer vehicle (LTV) feed system; (8) lunar excursion vehicle (LEV) propellant system; (9) area ratio gimbal angle limits; (10) reaction control system; and (11) engine configuration and characteristics. This document is presented in viewgraph form.

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

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.

Air Force Technical Objective Document FY 87

DTIC Science & Technology

1985-12-01

Air Force Systems Command Edwards Air Force Base. Cal ifornia 93523-5000 NOTICES THIS DOCUMENT IS FOR INFORMATION AND GUIDANCE ONL Y This...acquisition of Air Foree weapon systems . Each Air Foree laboratory annually formulates Q Research and Technology (R& T) Pion in response to available...guidance based on USAF requirements, the identification of scientific and technological opportunities, and the needs of present and projected systems

Step 1: Human System Integration (HSI) FY05 Pilot-Technology Interface Requirements for Contingency Management

NASA Technical Reports Server (NTRS)

2005-01-01

This document involves definition of technology interface requirements for Contingency Management. This was performed through a review of Contingency Management-related, HSI requirements documents, standards, and recommended practices. Technology concepts in use by the Contingency Management Work Package were considered. Beginning with HSI high-level functional requirements for Contingency Management, and Contingency Management technology elements, HSI requirements for the interface to the pilot were identified. Results of the analysis describe (1) the information required by the pilot to have knowledge of system failures and associated contingency procedures, and (2) the control capability needed by the pilot to obtain system status and procedure information. Fundamentally, these requirements provide the candidate Contingency Management technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how Contingency Management operations and functions should interface with the pilot to provide the necessary Contingency Management functionality to the UA-pilot system. Requirements and guidelines for Contingency Management are partitioned into four categories: (1) Health and Status and (2) Contingency Management. Each requirement is stated and is supported with a rationale and associated reference(s).

Earth Observing System/Advanced Microwave Sounding Unit-A (EOS/AMSU-A): Firmware Requirements

NASA Technical Reports Server (NTRS)

Schwantje, Robert

1995-01-01

This Firmware Requirements Document specifies the functional, performance, and interface requirements of the firmware. It also specifies the major characteristics, implementation constraints, and design goals of the firmware.

49 CFR 236.1015 - PTC Safety Plan content requirements and PTC System Certification.

Code of Federal Regulations, 2013 CFR

2013-10-01

... Administrator finds that the PTCSP and supporting documentation support a finding that the system complies with... additional requirements apply to: (1) Non-vital overlay. A PTC system proposed as an overlay on the existing... greater than the level of safety for the previous PTC systems. (2) Vital overlay. A PTC system proposed on...

49 CFR 236.1015 - PTC Safety Plan content requirements and PTC System Certification.

Code of Federal Regulations, 2012 CFR

2012-10-01

... Administrator finds that the PTCSP and supporting documentation support a finding that the system complies with... additional requirements apply to: (1) Non-vital overlay. A PTC system proposed as an overlay on the existing... greater than the level of safety for the previous PTC systems. (2) Vital overlay. A PTC system proposed on...

49 CFR 236.1015 - PTC Safety Plan content requirements and PTC System Certification.

Code of Federal Regulations, 2011 CFR

2011-10-01

... Administrator finds that the PTCSP and supporting documentation support a finding that the system complies with... additional requirements apply to: (1) Non-vital overlay. A PTC system proposed as an overlay on the existing... greater than the level of safety for the previous PTC systems. (2) Vital overlay. A PTC system proposed on...

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.

FBI fingerprint identification automation study: AIDS 3 evaluation report. Volume 9: Functional requirements

NASA Technical Reports Server (NTRS)

1980-01-01

The current system and subsystem used by the Identification Division are described. System constraints that dictate the system environment are discussed and boundaries within which solutions must be found are described. The functional requirements were related to the performance requirements. These performance requirements were then related to their applicable subsystems. The flow of data, documents, or other pieces of information from one subsystem to another or from the external world into the identification system is described. Requirements and design standards for a computer based system are presented.

Analysis of Data in Accordance with Space Flight Mission Environmental Requirements

NASA Technical Reports Server (NTRS)

Shei, Monica

2011-01-01

The Environmental Assurance Program sets forth standards to ensure that all flight hardware is compatible with the environments that will be encountered during a spacecraft mission. It outlines the design, test and analysis, and risk control standards for the mission and certifies that it will survive in any external or self-induced environments that the spacecraft may experience. The Environmental Requirements Document (ERD) is the most important document in the Environmental Assurance Program, providing the design and test requirements for the project's flight system, subsystems, assemblies, and instruments. This summer's project was to assist Environmental Requirements Engineers (ERE's) in completing the Environmental Assurance Program Summary Report for both the Juno Project and Mars Science Laboratory (MSL) Project. The Summary Report is a document summarizing the environmental tests and analyses of each spacecraft at both the assembly and system level. It compiles a source of all relevant information such as waivers and Problem/Failure Reports (PFRs) into a single report for easy reference of how well the spacecraft met the requirements of the project.

L-Band Digital Aeronautical Communications System Engineering - Concepts of Use, Systems Performance, Requirements, and Architectures

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.

Saint Lawrence Seaway Navigation-Aid System Study : Volume II - Appendix B - User's Manual and Documentation of Seaway Capacity and Capacity Analysis Programs

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...

Program Description: Financial Master File Processor-SWRL Financial System.

ERIC Educational Resources Information Center

Ideda, Masumi

Computer routines designed to produce various management and accounting reports required by the Southwest Regional Laboratory's (SWRL) Financial System are described. Input data requirements and output report formats are presented together with a discussion of the Financial Master File updating capabilities of the system. This document should be…

7 CFR 1730.26 - Certification.

Code of Federal Regulations, 2010 CFR

2010-01-01

... ELECTRIC SYSTEM OPERATIONS AND MAINTENANCE Operations and Maintenance Requirements § 1730.26 Certification. (a) Engineer's certification. Where provided for in the borrower's loan documents, RUS may require the borrower to provide an “Engineer's Certification” as to the condition of the borrower's system...

7 CFR 1730.26 - Certification.

Code of Federal Regulations, 2011 CFR

2011-01-01

... ELECTRIC SYSTEM OPERATIONS AND MAINTENANCE Operations and Maintenance Requirements § 1730.26 Certification. (a) Engineer's certification. Where provided for in the borrower's loan documents, RUS may require the borrower to provide an “Engineer's Certification” as to the condition of the borrower's system...

7 CFR 1730.26 - Certification.

Code of Federal Regulations, 2012 CFR

2012-01-01

... ELECTRIC SYSTEM OPERATIONS AND MAINTENANCE Operations and Maintenance Requirements § 1730.26 Certification. (a) Engineer's certification. Where provided for in the borrower's loan documents, RUS may require the borrower to provide an “Engineer's Certification” as to the condition of the borrower's system...

7 CFR 1730.26 - Certification.

Code of Federal Regulations, 2014 CFR

2014-01-01

... ELECTRIC SYSTEM OPERATIONS AND MAINTENANCE Operations and Maintenance Requirements § 1730.26 Certification. (a) Engineer's certification. Where provided for in the borrower's loan documents, RUS may require the borrower to provide an “Engineer's Certification” as to the condition of the borrower's system...

7 CFR 1730.26 - Certification.

Code of Federal Regulations, 2013 CFR

2013-01-01

... ELECTRIC SYSTEM OPERATIONS AND MAINTENANCE Operations and Maintenance Requirements § 1730.26 Certification. (a) Engineer's certification. Where provided for in the borrower's loan documents, RUS may require the borrower to provide an “Engineer's Certification” as to the condition of the borrower's system...

77 FR 27097 - LaCrosse Boiling Water Reactor, Exemption From Certain Requirements, Vernon County, WI

Federal Register 2010, 2011, 2012, 2013, 2014

2012-05-08

... status of LACBWR means that there are no longer interconnected operating systems which require security... System (ADAMS), which provides text and image files of NRC's public documents. If you do not have access...

System requirement specification for the IH-10 Integrated Corridor Management System (ICMS) in San Antonio, Texas

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...

The 3-axis Dynamic Motion Simulator (DMS) system

NASA Technical Reports Server (NTRS)

1975-01-01

A three-axis dynamic motion simulator (DMS) consisting of a test table with three degrees of freedom and an electronics control system was designed, constructed, delivered, and tested. Documentation, as required in the Data Requirements List (DRL), was also provided.

Teaching home care electronic documentation skills to undergraduate nursing students.

PubMed

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.

Emergency Operation Center

NASA Technical Reports Server (NTRS)

Chinea, Anoushka Z.

1995-01-01

The Emergency Operation Center (EOC) is a site from which NASA LaRC Emergency Preparedness Officials exercise control and direction in an emergency. Research was conducted in order to determine what makes an effective EOC. Specifically information concerning the various types of equipment and communication capability that an efficient EOC should contain (i.e., computers, software, telephone systems, radio systems, etc.) was documented. With this information a requirements document was written stating a brief description of the equipment and required quantity to be used in an EOC and then compared to current capabilities at the NASA Langley Research Center.

The Johnson Space Center Management Information Systems (JSCMIS). 1: Requirements Definition and Design Specifications for Versions 2.1 and 2.1.1. 2: Documented Test Scenario Environments. 3: Security Design and Specifications

NASA Technical Reports Server (NTRS)

1986-01-01

The Johnson Space Center Management Information System (JSCMIS) is an interface to computer data bases at NASA Johnson which allows an authorized user to browse and retrieve information from a variety of sources with minimum effort. This issue gives requirements definition and design specifications for versions 2.1 and 2.1.1, along with documented test scenario environments, and security object design and specifications.

DOE Office of Scientific and Technical Information (OSTI.GOV)

Edgar, Thomas W.; Hadley, Mark D.; Manz, David O.

This document provides the methods to secure routable control system communication in the electric sector. The approach of this document yields a long-term vision for a future of secure communication, while also providing near term steps and a roadmap. The requirements for the future secure control system environment were spelled out to provide a final target. Additionally a survey and evaluation of current protocols was used to determine if any existing technology could achieve this goal. In the end a four-step path was described that brought about increasing requirement completion and culminates in the realization of the long term vision.

A multi-agent system for monitoring patient flow.

PubMed

Rosati, Samanta; Tralli, Augusta; Balestra, Gabriella

2013-01-01

Patient flow within a healthcare facility may follow different and, sometimes, complicated paths. Each path phase is associated with the documentation of the activities carried out during it and may require the consultation of clinical guidelines, medical literature and the use of specific software and decision aid systems. In this study we present the design of a Patient Flow Management System (PFMS) based on Multi Agent Systems (MAS) methodology. System requirements were identified by means of process modeling tools and a MAS consisting of six agents was designed and is under construction. Its main goal is to support both the medical staff during the health care process and the hospital managers in assuring that all the required documentation is completed and available. Moreover, such a tool can be used for the assessment and comparison of different clinical pathways, in order to identify possible improvementsand the optimum patient flow.

Optimization in the systems engineering process

NASA Technical Reports Server (NTRS)

Lemmerman, Loren A.

1993-01-01

The essential elements of the design process consist of the mission definition phase that provides the system requirements, the conceptual design, the preliminary design and finally the detailed design. Mission definition is performed largely by operations analysts in conjunction with the customer. The result of their study is handed off to the systems engineers for documentation as the systems requirements. The document that provides these requirements is the basis for the further design work of the design engineers at the Lockheed-Georgia Company. The design phase actually begins with conceptual design, which is generally conducted by a small group of engineers using multidisciplinary design programs. Because of the complexity of the design problem, the analyses are relatively simple and generally dependent on parametric analyses of the configuration. The result of this phase is a baseline configuration from which preliminary design may be initiated.

Functional design specification for Stowage List And Hardware Tracking System (SLAHTS). [space shuttles

NASA Technical Reports Server (NTRS)

Keltner, D. J.

1975-01-01

This functional design specification defines the total systems approach to meeting the requirements stated in the Detailed Requirements Document for Stowage List and Hardware Tracking System for the space shuttle program. The stowage list and hardware tracking system is identified at the system and subsystem level with each subsystem defined as a function of the total system.

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.

75 FR 35318 - Cargo Insurance for Property Loss or Damage

Federal Register 2010, 2011, 2012, 2013, 2014

2010-06-22

... requirements for the reasons given later in this document. Legal Basis for the Rulemaking Cargo insurance... system required by 49 U.S.C. 13908. Jurisdiction over motor carrier and freight forwarder cargo insurance... the new unified registration system in accordance with the requirements of 49 U.S.C. 13908. In the...

45 CFR 307.15 - Approval of advance planning documents for computerized support enforcement systems.

Code of Federal Regulations, 2011 CFR

2011-10-01

... feasibility of the proposed effort and provide for the conduct of a requirements analysis study which address... indicate how the results of the requirements analysis study will be incorporated into the proposed system... address requirements analysis, program design, procurement and project management; and, a description of...

Study of data entry requirements at Marshall Space Flight Computation Center

NASA Technical Reports Server (NTRS)

Sherman, G. R.

1975-01-01

An economic and systems analysis of a data center was conducted. Current facilities for data storage of documentation are shown to be inadequate and outmoded for efficient data handling. Redesign of documents, condensation of the keypunching operation, upgrading of hardware, and retraining of personnel are the solutions proposed to improve the present data system.

W-026, Waste Receiving and Processing Facility data management system validation and verification report

DOE Office of Scientific and Technical Information (OSTI.GOV)

Palmer, M.E.

1997-12-05

This V and V Report includes analysis of two revisions of the DMS [data management system] System Requirements Specification (SRS) and the Preliminary System Design Document (PSDD); the source code for the DMS Communication Module (DMSCOM) messages; the source code for selected DMS Screens, and the code for the BWAS Simulator. BDM Federal analysts used a series of matrices to: compare the requirements in the System Requirements Specification (SRS) to the specifications found in the System Design Document (SDD), to ensure the design supports the business functions, compare the discreet parts of the SDD with each other, to ensure thatmore » the design is consistent and cohesive, compare the source code of the DMS Communication Module with the specifications, to ensure that the resultant messages will support the design, compare the source code of selected screens to the specifications to ensure that resultant system screens will support the design, compare the source code of the BWAS simulator with the requirements to interface with DMS messages and data transfers relating to the BWAS operations.« less

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.

48 CFR 43.204 - Administration.

Code of Federal Regulations, 2010 CFR

2010-10-01

... Section 43.204 Federal Acquisition Regulations System FEDERAL ACQUISITION REGULATION CONTRACT MANAGEMENT CONTRACT MODIFICATIONS Change Orders 43.204 Administration. (a) Change order documentation. When change orders are not forward priced, they require two documents: the change order and a supplemental agreement...

75 FR 48629 - Electronic Tariff Filing System (ETFS)

Federal Register 2010, 2011, 2012, 2013, 2014

2010-08-11

...In this document, the Federal Communications Commission (Commission) seeks comment on extending the electronic tariff filing requirement for incumbent local exchange carriers to all carriers that file tariffs and related documents. Additionally, the Commission seeks comment on the appropriate time frame for implementing this proposed requirement. The Commission also seeks comment on the proposal that the Chief of the Wireline Competition Bureau administer the adoption of this extended electronic filing requirement. Also, the Commission seeks comment on proposed rule changes to implement mandatory electronic tariff filing.

ANOPP programming and documentation standards document

NASA Technical Reports Server (NTRS)

1976-01-01

Standards defining the requirements for preparing software for the Aircraft Noise Prediction Program (ANOPP) were given. It is the intent of these standards to provide definition, design, coding, and documentation criteria for the achievement of a unity among ANOPP products. These standards apply to all of ANOPP's standard software system. The standards encompass philosophy as well as techniques and conventions.

Prototype development and demonstration for response, emergency staging, communications, uniform management, and evacuation (R.E.S.C.U.M.E.) : R.E.S.C.U.M.E. prototype system architecture.

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...

A CMMI-based approach for medical software project life cycle study.

PubMed

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.

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.

Relevance of health level 7 clinical document architecture and integrating the healthcare enterprise cross-enterprise document sharing profile for managing chronic wounds in a telemedicine context.

PubMed

Finet, Philippe; Gibaud, Bernard; Dameron, Olivier; Le Bouquin Jeannès, Régine

2016-03-01

The number of patients with complications associated with chronic diseases increases with the ageing population. In particular, complex chronic wounds raise the re-admission rate in hospitals. In this context, the implementation of a telemedicine application in Basse-Normandie, France, contributes to reduce hospital stays and transport. This application requires a new collaboration among general practitioners, private duty nurses and the hospital staff. However, the main constraint mentioned by the users of this system is the lack of interoperability between the information system of this application and various partners' information systems. To improve medical data exchanges, the authors propose a new implementation based on the introduction of interoperable clinical documents and a digital document repository for managing the sharing of the documents between the telemedicine application users. They then show that this technical solution is suitable for any telemedicine application and any document sharing system in a healthcare facility or network.

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.

System Design Description for the TMAD Code

DOE Office of Scientific and Technical Information (OSTI.GOV)

Finfrock, S.H.

This document serves as the System Design Description (SDD) for the TMAD Code System, which includes the TMAD code and the LIBMAKR code. The SDD provides a detailed description of the theory behind the code, and the implementation of that theory. It is essential for anyone who is attempting to review or modify the code or who otherwise needs to understand the internal workings of the code. In addition, this document includes, in Appendix A, the System Requirements Specification for the TMAD System.

Calculation of Cost Effectiveness of Emission Control Systems

EPA Pesticide Factsheets

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.

Enhancing Documentation of Pressure Ulcer Prevention Interventions: A Quality Improvement Strategy to Reduce Pressure Ulcers.

PubMed

Jacobson, Therese M; Thompson, Susan L; Halvorson, Anna M; Zeitler, Kristine

2016-01-01

Prevention of hospital-acquired pressure ulcers requires the implementation of evidence-based interventions. A quality improvement project was conducted to provide nurses with data on the frequency with which pressure ulcer prevention interventions were performed as measured by documentation. Documentation reports provided feedback to stakeholders, triggering reminders and reeducation. Intervention reports and modifications to the documentation system were effective both in increasing the documentation of pressure ulcer prevention interventions and in decreasing the number of avoidable hospital-acquired pressure ulcers.

Integrated Advanced Microwave Sounding Unit-A (AMSU-A). Test Report, Electromagnetic Interference (EMI)/Electromagnetic Radiation(EMR) and Electromagnetic Capability (EMC) for the EOS/AMSU-A1

NASA Technical Reports Server (NTRS)

Paliwoda, L.

1998-01-01

This document contains the procedure and the test results of the Advanced Microwave Sounding Unit-A (AMSU-A) Earth Observing System (EOS) Project, assembly part number 1356008-1, serial number 202, Electromagnetic Interference (EMI) and Electromagnetic Susceptibility (EMC) qualification test. The test was conducted in accordance with the approved EMI/EMC Test Plan/Procedure, Specification number AE-26151/8B, dated 10 September 1998. Aerojet intends that the presentation and submittal of this document, prepared in accordance with the objectives established by the aforementioned Test Plan/Procedure, document number AE-26151/8B, will satisfy the data requirement with respect to the AMSU-A/EOS instrument operational compliance of the EMI/EMC test requirement. Test for the AMSU-A/EOS instrument have been completed and all the requirements per General Interface Requirement Document (GIRD), GSFC 422-11-12-01, for EOS Common Spacecraft/Instruments, paragraph 10.11, were met with the exceptions of the test methods CE03, RE01, and RE02, as described in this document.

32 CFR 989.35 - Reporting requirements.

Code of Federal Regulations, 2013 CFR

2013-07-01

... documents electronically. Public review comments should be required in writing, rather than by electronic... measures will be tracked at bases and MAJCOMs through an appropriate environmental management system. (b...

32 CFR 989.35 - Reporting requirements.

Code of Federal Regulations, 2014 CFR

2014-07-01

... documents electronically. Public review comments should be required in writing, rather than by electronic... measures will be tracked at bases and MAJCOMs through an appropriate environmental management system. (b...

32 CFR 989.35 - Reporting requirements.

Code of Federal Regulations, 2012 CFR

2012-07-01

... documents electronically. Public review comments should be required in writing, rather than by electronic... measures will be tracked at bases and MAJCOMs through an appropriate environmental management system. (b...

32 CFR 989.35 - Reporting requirements.

Code of Federal Regulations, 2011 CFR

2011-07-01

... documents electronically. Public review comments should be required in writing, rather than by electronic... measures will be tracked at bases and MAJCOMs through an appropriate environmental management system. (b...

32 CFR 989.35 - Reporting requirements.

Code of Federal Regulations, 2010 CFR

2010-07-01

... documents electronically. Public review comments should be required in writing, rather than by electronic... measures will be tracked at bases and MAJCOMs through an appropriate environmental management system. (b...

Development of integrated programs for Aerospace-vehicle Design (IPAD): Product program management systems

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.

Tracing And Control Of Engineering Requirements

NASA Technical Reports Server (NTRS)

Turner, Philip R.; Stoller, Richard L.; Neville, Ted; Boyle, Karen A.

1991-01-01

TRACER (Tracing and Control of Engineering Requirements) is data-base/word-processing software system created to document and maintain order of both requirements and descriptions associated with engineering project. Implemented on IBM PC under PC-DOS. Written with CLIPPER.

Recommendations for UAS Crew Ratings. Pilot Ratings and Authorization Requirements for UAS

NASA Technical Reports Server (NTRS)

2005-01-01

This position paper is intended to recommend the minimum certificate and rating requirements for a pilot to operate an Unmanned Aircraft System (UAS) in the National Airspace System. The paper will recommend the minimum requirements based on the Knowledge, Skills, and Abilities (KSA) required of a UAS pilot and show how those compare to the KSAs required by regulation for manned-aircraft pilots. The paper will provide substantiation based on studies conducted using analyses, simulation and flight experience. The paper is not yet complete; only initial working material is included. The material provided describes the body of work completed thus far and the plan for remaining tasks to complete the recommendation. The HSI Pilot KSA document provides an analysis of the knowledge, skills, and abilities required for UAS operation in the NAS. It is the source document used for the position paper.

ISS Crew Transportation and Services Requirements Document

NASA Technical Reports Server (NTRS)

Lueders, Kathryn L. (Compiler)

2015-01-01

Under the guidance of processes provided by Crew Transportation Plan (CCT-PLN-1100), this document with its sister documents, Crew Transportation Technical Management Processes (CCT-PLN-1120), Crew Transportation Technical Standards and Design Evaluation Criteria (CCT-STD-1140), and Crew Transportation Operations Standards (CCT-STD-1150), and International Space Station (ISS) to Commercial Orbital Transportation Services Interface Requirements Document (SSP 50808), provides the basis for a National Aeronautics and Space Administration (NASA) certification for services to the ISS for the Commercial Provider. When NASA Crew Transportation System (CTS) certification is achieved for ISS transportation, the Commercial Provider will be eligible to provide services to and from the ISS during the services phase of the NASA Commercial Crew Program (CCP).

NETMARK

NASA Technical Reports Server (NTRS)

Maluf, David A.; Koga, Dennis (Technical Monitor)

2002-01-01

This presentation discuss NASA's proposed NETMARK knowledge management tool which aims 'to control and interoperate with every block in a document, email, spreadsheet, power point, database, etc. across the lifecycle'. Topics covered include: system software requirements and hardware requirements, seamless information systems, computer architecture issues, and potential benefits to NETMARK users.

Connected Vehicle Pilot Deployment Program Phase 1, System Requirements Specification (SyRS) – New York City.

DOT National Transportation Integrated Search

2016-07-28

This document describes the System Requirements Specification (SyRS) for the New York City Department of Transportation (NYC) Connected Vehicle Pilot Deployment (CVPD) Project. This SyRS describes the results of the definition of need, the operationa...

48 CFR 801.602-81 - Documents required for business clearance reviews.

Code of Federal Regulations, 2010 CFR

2010-10-01

... business clearance reviews. 801.602-81 Section 801.602-81 Federal Acquisition Regulations System DEPARTMENT OF VETERANS AFFAIRS GENERAL DEPARTMENT OF VETERANS AFFAIRS ACQUISITION REGULATION SYSTEM Career... reviews. When a bid or offer, proposed contract modification, or proposed lease requires a business...

Space Segment (SS) and the Navigation User Segment (US) Interface Control Document (ICD)

DOT National Transportation Integrated Search

1993-10-10

This Interface Control Document (ICD) defines the requirements related to the interface between the Space Segment (SS) of the Global Positioning System (GPS) and the Navigation Users Segment of the GPS. 2880k, 154p.

Software Process Automation: Experiences from the Trenches.

DTIC Science & Technology

1996-07-01

Integration of problem database Weaver tions) J Process WordPerfect, All-in-One, Oracle, CM Integration of tools Weaver System K Process Framemaker , CM...handle change requests and problem reports. * Autoplan, a project management tool * Framemaker , a document processing system * Worldview, a document...Cadre, Team Work, FrameMaker , some- thing for requirements traceability, their own homegrown scheduling tool, and their own homegrown tool integrator

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

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.

Document Concurrence System

NASA Technical Reports Server (NTRS)

Muhsin, Mansour; Walters, Ian

2004-01-01

The Document Concurrence System is a combination of software modules for routing users expressions of concurrence with documents. This system enables determination of the current status of concurrences and eliminates the need for the prior practice of manually delivering paper documents to all persons whose approvals were required. This system runs on a server, and participants gain access via personal computers equipped with Web-browser and electronic-mail software. A user can begin a concurrence routing process by logging onto an administration module, naming the approvers and stating the sequence for routing among them, and attaching documents. The server then sends a message to the first person on the list. Upon concurrence by the first person, the system sends a message to the second person, and so forth. A person on the list indicates approval, places the documents on hold, or indicates disapproval, via a Web-based module. When the last person on the list has concurred, a message is sent to the initiator, who can then finalize the process through the administration module. A background process running on the server identifies concurrence processes that are overdue and sends reminders to the appropriate persons.

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

Tags Extarction from Spatial Documents in Search Engines

NASA Astrophysics Data System (ADS)

Borhaninejad, S.; Hakimpour, F.; Hamzei, E.

2015-12-01

Nowadays the selective access to information on the Web is provided by search engines, but in the cases which the data includes spatial information the search task becomes more complex and search engines require special capabilities. The purpose of this study is to extract the information which lies in spatial documents. To that end, we implement and evaluate information extraction from GML documents and a retrieval method in an integrated approach. Our proposed system consists of three components: crawler, database and user interface. In crawler component, GML documents are discovered and their text is parsed for information extraction; storage. The database component is responsible for indexing of information which is collected by crawlers. Finally the user interface component provides the interaction between system and user. We have implemented this system as a pilot system on an Application Server as a simulation of Web. Our system as a spatial search engine provided searching capability throughout the GML documents and thus an important step to improve the efficiency of search engines has been taken.

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.

Definition and means of maintaining the supply ventilation system seismic shutdown portion of the PFP safety envelope

DOE Office of Scientific and Technical Information (OSTI.GOV)

Keck, R.D.

1997-01-21

The purpose of this document is to record the technical evaluation of the Limiting Condition for Operation (LCO) described in the Plutonium Finishing Plant (PFP) Operational Safety Requirements, WHC-SD-CP-OSR- 010, Rev. 0. Kay 1994, Section 3.2.3, `Supply Ventilation System Seismic Shutdown.` This document, with its appendices, provides the following: 1. The system functional requirements for determining system operability (Section 3). 2. Evaluations of equipment to determine the safety boundary for the system (Section 4). 3. A list of annotated drawings which show the safety envelope boundaries (Appendix C). 4. A list of the safety envelope equipment (Appendix B). 5. Functionalmore » requirements for the individual safety envelope equipment, including appropriate setpoints and process parameters (Section 4.1). 6. A list of the operational, maintenance and surveillance procedures necessary to operate and maintain the system equipment within the safety envelope (Sections 5 and 6 and Appendix A).« less

Documenting quality improvement and patient safety efforts: the quality portfolio. A statement from the academic hospitalist taskforce.

PubMed

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.

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.

System Guidelines for EMC Safety-Critical Circuits: Design, Selection, and Margin Demonstration

NASA Technical Reports Server (NTRS)

Lawton, R. M.

1996-01-01

Demonstration of safety margins for critical points (circuits) has traditionally been required since it first became a part of systems-level Electromagnetic Compatibility (EMC) requirements of MIL-E-6051C. The goal of this document is to present cost-effective guidelines for ensuring adequate Electromagnetic Effects (EME) safety margins on spacecraft critical circuits. It is for the use of NASA and other government agencies and their contractors to prevent loss of life, loss of spacecraft, or unacceptable degradation. This document provides practical definition and treatment guidance to contain costs within affordable limits.

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.

Detailed requirements document for Stowage List and Hardware Tracking System (SLAHTS). [computer based information management system in support of space shuttle orbiter stowage configuration

NASA Technical Reports Server (NTRS)

Keltner, D. J.

1975-01-01

The stowage list and hardware tracking system, a computer based information management system, used in support of the space shuttle orbiter stowage configuration and the Johnson Space Center hardware tracking is described. The input, processing, and output requirements that serve as a baseline for system development are defined.

HYDROLOGIC EVALUATION OF LANDFILL PERFORMANCE (HELP) MODEL - USER'S GUIDE FOR VERSION 3

EPA Science Inventory

This report documents the solution methods and process descriptions used in the Version 3 of the HELP model. Program documentation including program options, system and operating requirements, file structures, program structure and variable descriptions are provided in a separat...

36 CFR § 1222.28 - What are the series level recordkeeping requirements?

Code of Federal Regulations, 2013 CFR

2013-07-01

... AND RECORDS ADMINISTRATION RECORDS MANAGEMENT CREATION AND MAINTENANCE OF FEDERAL RECORDS Agency... series and systems adequately document agency policies, transactions, and activities, each program must... documentation of phone calls, meetings, instant messages, and electronic mail exchanges that include substantive...

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...

User Manual for the AZ-101 Data Acquisition System (AS-101 DAS)

DOE Office of Scientific and Technical Information (OSTI.GOV)

BRAYTON, D.D.

2000-02-17

User manual for the TK AZ-101 Waste Retrieval System Data Acquisition System. The purpose of this document is to describe use of the AZ-101 Data Acquisition System (AZ-101 DAS). The AZ-101 DAS is provided to fulfill the requirements for data collection and monitoring as defined in Letters of Instruction (LOI) from Numatec Hanford Corporation (NHC) to Fluor Federal Services (FFS). For a complete description of the system, including design, please refer to the AZ-101 DAS System Description document, RPP-5572.

Step 1:Human System Integration (HSI) FY05 Pilot-Technology Interface Requirements for Collision Avoidance

NASA Technical Reports Server (NTRS)

2007-01-01

This document provides definition of technology human interface requirements for Collision Avoidance (CA). This was performed through a review of CA-related, HSI requirements documents, standards, and recommended practices. Technology concepts in use by the Access 5 CA work package were considered... Beginning with the HSI high-level functional requirement for CA, and CA technology elements, HSI requirements for the interface to the pilot were identified. Results of the analysis describe (1) the information required by the pilot to have knowledge CA system status, and (2) the control capability needed by the pilot to obtain CA information and affect an avoidance maneuver. Fundamentally, these requirements provide the candidate CA technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how CA operations and functions should interface with the pilot to provide the necessary CA functionality to the UA-pilot system .Requirements and guidelines for CA are partitioned into four categories: (1) General, (2) Alerting, (3) Guidance, and (4) Cockpit Display of Traffic Information. Each requirement is stated and is supported with a rationale and associated reference(s).

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

Environmental Response Laboratory Network (ERLN) Laboratory Requirements

EPA Pesticide Factsheets

The Environmental Response Laboratory Network requires its member labs follow specified quality systems, sample management, data reporting, and general, in order to ensure consistent analytical data of known and documented quality.

Large Bore Powder Gun Qualification (U)

DOE Office of Scientific and Technical Information (OSTI.GOV)

Rabern, Donald A.; Valdiviez, Robert

A Large Bore Powder Gun (LBPG) is being designed to enable experimentalists to characterize material behavior outside the capabilities of the NNSS JASPER and LANL TA-55 PF-4 guns. The combination of these three guns will create a capability to conduct impact experiments over a wide range of pressures and shock profiles. The Large Bore Powder Gun will be fielded at the Nevada National Security Site (NNSS) U1a Complex. The Complex is nearly 1000 ft below ground with dedicated drifts for testing, instrumentation, and post-shot entombment. To ensure the reliability, safety, and performance of the LBPG, a qualification plan has beenmore » established and documented here. Requirements for the LBPG have been established and documented in WE-14-TR-0065 U A, Large Bore Powder Gun Customer Requirements. The document includes the requirements for the physics experiments, the gun and confinement systems, and operations at NNSS. A detailed description of the requirements is established in that document and is referred to and quoted throughout this document. Two Gun and Confinement Systems will be fielded. The Prototype Gun will be used primarily to characterize the gun and confinement performance and be the primary platform for qualification actions. This gun will also be used to investigate and qualify target and diagnostic modifications through the life of the program (U1a.104 Drift). An identical gun, the Physics Gun, will be fielded for confirmatory and Pu experiments (U1a.102D Drift). Both guns will be qualified for operation. The Gun and Confinement System design will be qualified through analysis, inspection, and testing using the Prototype Gun for the majority of process. The Physics Gun will be qualified through inspection and a limited number of qualification tests to ensure performance and behavior equivalent to the Prototype gun. Figure 1.1 shows the partial configuration of U1a and the locations of the Prototype and Physics Gun/Confinement Systems.« less

System analysis study of space platform and station accommodations for life sciences research facilities. Volume 2: Study results. Appendix D: Life sciences research facility requirements

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.

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.

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.

49 CFR 236.1035 - Field testing requirements.

Code of Federal Regulations, 2010 CFR

2010-10-01

... uncertified PTC system, or a product of an uncertified PTC system, or any regression testing of a certified...: (1) A complete description of the PTC system; (2) An operational concepts document; (3) A complete...

Human Performance Considerations for Remotely Piloted Aircraft Systems (RPAS)

NASA Technical Reports Server (NTRS)

Shively, R. Jay; Hobbs, Alan; Lyall, Beth; Rorie, Conrad

2015-01-01

Successful integration of Remotely Piloted Aircraft Systems (RPAS) into civil airspace will not only require solutions to technical challenges, but will also require that the design and operation of RPAS take into account human limitations and capabilities. Human factors can affect overall system performance whenever the system relies on people to interact with another element of the system. Four types of broad interactions can be described. These are (1) interactions between people and hardware, such as controls and displays; (2) human use of procedures and documentation; (3) impact of the task environment, including lighting, noise and monotony; and lastly, (4) interactions between operational personnel, including communication and coordination. In addition to the human factors that have been identified for conventional aviation, RPAS operations introduce a set of unique human challenges. The purpose of document is to raise human factors issues for consideration by workgroups of the ICAO RPAS panel as they work to develop guidance material and additions to ICAO annexes. It is anticipated that the content of this document will be revised and updated as the work of the panel progresses.

Transport systems research vehicle color display system operations manual

NASA Technical Reports Server (NTRS)

Easley, Wesley C.; Johnson, Larry E.

1989-01-01

A recent upgrade of the Transport Systems Research Vehicle operated by the Advanced Transport Operating Systems Program Office at the NASA Langley Research Center has resulted in an all-glass panel in the research flight deck. Eight ARINC-D size CRT color displays make up the panel. A major goal of the display upgrade effort was ease of operation and maintenance of the hardware while maintaining versatility needed for flight research. Software is the key to this required versatility and will be the area demanding the most detailed technical design expertise. This document is is intended to serve as a single source of quick reference information needed for routine operation and system level maintenance. Detailed maintenance and modification of the display system will require specific design documentation and must be accomplished by individuals with specialized knowledge and experience.

Flight Design System-1 System Design Document. Volume 9: Executive logic flow, program design language

NASA Technical Reports Server (NTRS)

1979-01-01

The detailed logic flow for the Flight Design System Executive is presented. The system is designed to provide the hardware/software capability required for operational support of shuttle flight planning.

U.S. Central Command Headquarters’ Use of the Government Purchase Card

DTIC Science & Technology

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

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".

Human Systems Integration: Requirements and Functional Decomposition

NASA Technical Reports Server (NTRS)

Berson, Barry; Gershzohn, Gary; Boltz, Laura; Wolf, Russ; Schultz, Mike

2005-01-01

This deliverable was intended as an input to the Access 5 Policy and Simulation Integrated Product Teams. This document contains high-level pilot functionality for operations in the National Airspace System above FL430. Based on the derived pilot functions the associated pilot information and control requirements are given.

48 CFR 1506.303-2 - Content.

Code of Federal Regulations, 2012 CFR

2012-10-01

... 48 Federal Acquisition Regulations System 6 2012-10-01 2012-10-01 false Content. 1506.303-2 Section 1506.303-2 Federal Acquisition Regulations System ENVIRONMENTAL PROTECTION AGENCY ACQUISITION PLANNING COMPETITION REQUIREMENTS Other Than Full and Open Competition 1506.303-2 Content. The documentation requirements in this section apply only to...

48 CFR 1506.303-2 - Content.

Code of Federal Regulations, 2013 CFR

2013-10-01

... 48 Federal Acquisition Regulations System 6 2013-10-01 2013-10-01 false Content. 1506.303-2 Section 1506.303-2 Federal Acquisition Regulations System ENVIRONMENTAL PROTECTION AGENCY ACQUISITION PLANNING COMPETITION REQUIREMENTS Other Than Full and Open Competition 1506.303-2 Content. The documentation requirements in this section apply only to...

48 CFR 1506.303-2 - Content.

Code of Federal Regulations, 2014 CFR

2014-10-01

... 48 Federal Acquisition Regulations System 6 2014-10-01 2014-10-01 false Content. 1506.303-2 Section 1506.303-2 Federal Acquisition Regulations System ENVIRONMENTAL PROTECTION AGENCY ACQUISITION PLANNING COMPETITION REQUIREMENTS Other Than Full and Open Competition 1506.303-2 Content. The documentation requirements in this section apply only to...

48 CFR 1506.303-2 - Content.

Code of Federal Regulations, 2010 CFR

2010-10-01

... 48 Federal Acquisition Regulations System 6 2010-10-01 2010-10-01 true Content. 1506.303-2 Section 1506.303-2 Federal Acquisition Regulations System ENVIRONMENTAL PROTECTION AGENCY ACQUISITION PLANNING COMPETITION REQUIREMENTS Other Than Full and Open Competition 1506.303-2 Content. The documentation requirements in this section apply only to...

48 CFR 1506.303-2 - Content.

Code of Federal Regulations, 2011 CFR

2011-10-01

... 48 Federal Acquisition Regulations System 6 2011-10-01 2011-10-01 false Content. 1506.303-2 Section 1506.303-2 Federal Acquisition Regulations System ENVIRONMENTAL PROTECTION AGENCY ACQUISITION PLANNING COMPETITION REQUIREMENTS Other Than Full and Open Competition 1506.303-2 Content. The documentation requirements in this section apply only to...

2002 Controls Design Challenge

NASA Technical Reports Server (NTRS)

Hess, Ronald A.; Vetter, T. K.; Wells, S. R.

2002-01-01

This document is intended to provide the specifications and requirements for a flight control system design challenge. The response to the challenge will involve documenting whether the particular design has met the stated requirements through analysis and computer simulation. The response should be written in the general format of a technical publication with corresponding length limits, e.g., an approximate maximum length of 45 units, with each full-size figure and double-spaced typewritten page constituting one unit.

Space station data system analysis/architecture study. Task 1: Functional requirements definition, DR-5. Appendix: Requirements data base

NASA Technical Reports Server (NTRS)

1985-01-01

Appendix A contains data that characterize the system functions in sufficient depth as to determine the requirements for the Space Station Data System (SSDS). This data is in the form of: (1) top down traceability report; (2) bottom up traceability report; (3) requirements data sheets; and (4) cross index of requirements paragraphs of the source documents and the requirements numbers. A data base users guide is included that interested parties can use to access the requirements data base and get up to date information about the functions.

Orbital transfer vehicle concept definition and system analysis study. Volume 2: OTV concept definition and evaluation. Book 1: Mission and system requirements

NASA Technical Reports Server (NTRS)

Kofal, Allen E.

1987-01-01

The mission and system requirements for the concept definition and system analysis of the Orbital Transfer Vehicle (OTV) are established. The requirements set forth constitute the single authority for the selection, evaluation, and optimization of the technical performance and design of the OTV. This requirements document forms the basis for the Ground and Space Based OTV concept definition analyses and establishes the physical, functional, performance and design relationships to STS, Space Station, Orbital Maneuvering Vehicle (OMV), and payloads.

Contingency Plan for FGD Systems During Downtime as a Function of PSD

EPA Pesticide Factsheets

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.

Response to Request for Guidance Concerning Installation of Nitrogen Oxides Continuous Emissions Monitoring Systems

EPA Pesticide Factsheets

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.

Integrated Baseline System (IBS), Version 1. 03. [Chemical Stockpile Emergency Preparedness Program

DOE Office of Scientific and Technical Information (OSTI.GOV)

Bailey, B.M.; Burford, M.J.; Downing, T.R.

The Integrated Baseline System (IBS), operated by the Federal Emergency Management Agency (FEMA), is a system of computerized tools for emergency planing and analysis. This document is the user guide for the IBS and explains how to operate the IBS system. The fundamental function of the IBS is to provide tools that civilian emergency management personnel can use in developing emergency plans and in supporting emergency management activities to cope with a chemical-releasing event at a military chemical stockpile. Emergency management planners can evaluate concepts and ideas using the IBS system. The results of that experience can then be factoredmore » into refining requirements and plans. This document provides information for the general system user, and is the primary reference for the system features of the IBS. It is designed for persons who are familiar with general emergency management concepts, operations, and vocabulary. Although the IBS manual set covers basic and advanced operations, it is not a complete reference document set. Emergency situation modeling software in the IBS is supported by additional technical documents. Some of the other LBS software is commercial software for which more complete documentation is available. The IBS manuals reference such documentation where necessary. IBS is a dynamic system. Its capabilities are in a state of continuing expansion and enhancement.« less

Critical Characteristics of Radiation Detection System Components to be Dedicated for use in Safety Class and Safety Significant System

DOE Office of Scientific and Technical Information (OSTI.GOV)

DAVIS, S.J.

2000-12-28

This document identifies critical characteristics of components to be dedicated for use in Safety Significant (SS) Systems, Structures, or Components (SSCs). This document identifies the requirements for the components of the common, radiation area, monitor alarm in the WESF pool cell. These are procured as Commercial Grade Items (CGI), with the qualification testing and formal dedication to be performed at the Waste Encapsulation Storage Facility (WESF) for use in safety significant systems. System modifications are to be performed in accordance with the approved design. Components for this change are commercially available and interchangeable with the existing alarm configuration This documentmore » focuses on the operational requirements for alarm, declaration of the safety classification, identification of critical characteristics, and interpretation of requirements for procurement. Critical characteristics are identified herein and must be verified, followed by formal dedication, prior to the components being used in safety related applications.« less

A computer-based specification methodology

NASA Technical Reports Server (NTRS)

Munck, Robert G.

1986-01-01

Standard practices for creating and using system specifications are inadequate for large, advanced-technology systems. A need exists to break away from paper documents in favor of documents that are stored in computers and which are read and otherwise used with the help of computers. An SADT-based system, running on the proposed Space Station data management network, could be a powerful tool for doing much of the required technical work of the Station, including creating and operating the network itself.

DOE Office of Scientific and Technical Information (OSTI.GOV)

NONE

This report supplements the final safety evaluation report (FSER) for the System 80+ standard design. The FSER was issued by the US Nuclear Regulatory Commission (NRC) staff as NUREG-1462 in August 1994 to document the NRC staff`s review of the System 80+ design. The System 80+ design was submitted by Asea Brown Boveri-Combustion Engineering (ABB-CE), in accordance with the procedures of Subpart B to Part 52 of Title 10 of the Code of Federal Regulations. This supplement documents the NRC staff`s review of the changes to the System 80+ design documentation since the issuance of the FSER. ABB-CE made thesemore » changes as a result of its review of the System 80+ design details. The NRC staff concludes that the changes to the System 80+ design documentation are acceptable, and that ABB-CE`s application for design certification meets the requirements of Subpart B to 10 CFR Part 52 that are applicable and technically relevant to the System 80+ design.« less

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.

The Source to S2K Conversion System.

DTIC Science & Technology

1978-12-01

mandgement system Provides. As for all software production, the cost of writing this program is high, particularily considering it may be executed only...research, and 3 findlly, implement the system using disciplined, structured software engineering principles. In order to properly document how these...complete read step is required (as done by the Michigan System and EXPRESS) or software support outside the conversion system (as in CODS) is required

Design and Data Management System

NASA Technical Reports Server (NTRS)

Messer, Elizabeth; Messer, Brad; Carter, Judy; Singletary, Todd; Albasini, Colby; Smith, Tammy

2007-01-01

The Design and Data Management System (DDMS) was developed to automate the NASA Engineering Order (EO) and Engineering Change Request (ECR) processes at the Propulsion Test Facilities at Stennis Space Center for efficient and effective Configuration Management (CM). Prior to the development of DDMS, the CM system was a manual, paper-based system that required an EO or ECR submitter to walk the changes through the acceptance process to obtain necessary approval signatures. This approval process could take up to two weeks, and was subject to a variety of human errors. The process also requires that the CM office make copies and distribute them to the Configuration Control Board members for review prior to meetings. At any point, there was a potential for an error or loss of the change records, meaning the configuration of record was not accurate. The new Web-based DDMS eliminates unnecessary copies, reduces the time needed to distribute the paperwork, reduces time to gain the necessary signatures, and prevents the variety of errors inherent in the previous manual system. After implementation of the DDMS, all EOs and ECRs can be automatically checked prior to submittal to ensure that the documentation is complete and accurate. Much of the configuration information can be documented in the DDMS through pull-down forms to ensure consistent entries by the engineers and technicians in the field. The software also can electronically route the documents through the signature process to obtain the necessary approvals needed for work authorization. The workflow of the system allows for backups and timestamps that determine the correct routing and completion of all required authorizations in a more timely manner, as well as assuring the quality and accuracy of the configuration documents.

Safety and fitness electronic records system (SAFER) : user and system requirements document

DOT National Transportation Integrated Search

1996-10-28

The Federal Highway Administration (FHWA) is currently testing and evaluating Intelligent : Transportation Systems (ITS) technologies to enhance the safety and efficiency of interstate and : intrastate commercial vehicle operations. The current focus...

NAS Requirements Checklist for Job Queuing/Scheduling Software

NASA Technical Reports Server (NTRS)

Jones, James Patton

1996-01-01

The increasing reliability of parallel systems and clusters of computers has resulted in these systems becoming more attractive for true production workloads. Today, the primary obstacle to production use of clusters of computers is the lack of a functional and robust Job Management System for parallel applications. This document provides a checklist of NAS requirements for job queuing and scheduling in order to make most efficient use of parallel systems and clusters for parallel applications. Future requirements are also identified to assist software vendors with design planning.

Human computer interface guide, revision A

NASA Technical Reports Server (NTRS)

1993-01-01

The Human Computer Interface Guide, SSP 30540, is a reference document for the information systems within the Space Station Freedom Program (SSFP). The Human Computer Interface Guide (HCIG) provides guidelines for the design of computer software that affects human performance, specifically, the human-computer interface. This document contains an introduction and subparagraphs on SSFP computer systems, users, and tasks; guidelines for interactions between users and the SSFP computer systems; human factors evaluation and testing of the user interface system; and example specifications. The contents of this document are intended to be consistent with the tasks and products to be prepared by NASA Work Package Centers and SSFP participants as defined in SSP 30000, Space Station Program Definition and Requirements Document. The Human Computer Interface Guide shall be implemented on all new SSFP contractual and internal activities and shall be included in any existing contracts through contract changes. This document is under the control of the Space Station Control Board, and any changes or revisions will be approved by the deputy director.

Flammability, Odor, Offgassing, and Compatibility Requirements and Test Procedures for Materials in Environments that Support Combustion

NASA Technical Reports Server (NTRS)

1998-01-01

This handbook establishes NASA program requirements for evaluation, testing, and selection of materials to preclude unsafe conditions related to flammability, odor, offgassing, and fluid compatibility. Materials intended for use in space vehicles, specified test facilities, and specified ground support equipment (GSE) must meet the requirements of this document. Additional materials performance requirements may be specified in other program or NASA center specific documentation. Responsible NASA centers materials organizations must include applicable requirements of this document in their materials control programs. Materials used in habitable areas of spacecraft, including the materials of the spacecraft, stowed equipment, and experiments, must be evaluated for flammability, odor, and offgassing characteristics. All materials used in other areas must be evaluated for flammability characteristics. In addition, materials that are exposed to liquid oxygen (LOX), gaseous oxygen (GOX), and other reactive fluids' must be evaluated for compatibility with the fluid in their use application. Materials exposed to pressurized breathing gases also must be evaluated for odor and offgassing characteristics. The worst-case anticipated use environment (most hazardous pressure, temperature, material thickness, and fluid exposure conditions) must be used in the evaluation process. Materials that have been shown to meet the criteria of the required tests are acceptable for further consideration in design. Whenever possible, materials should be selected that have already been shown to meet the test criteria in the use environment. Existing test data are compiled in the NASA Marshall Space Flight Center (MSFC) Materials and Processes Technical Information System (MAPTIS) and published periodically as the latest revision of a joint document with Johnson Space Center (JSC), MSFC-HDBK-527/JSC 09604. MAPTIS can be accessed by computer datalink. Systems containing materials that have not been tested or do not meet the criteria of the required tests must be verified to be acceptable in the use configuration by analysis or testing. This verification rationale must be documented and submitted to the responsible NASA center materials organization for approval.

Manned Orbital Transfer Vehicle (MOTV). Volume 3: Program requirements documents

NASA Technical Reports Server (NTRS)

Boyland, R. E.; Sherman, S. W.; Morfin, H. W.

1979-01-01

The requirements for geosynchronous orbit capability using the manned orbit transfer vehicle (MOTV) are defined. The program requirements, the mission requirements, and the system and subsystem requirements for the MOTV are discussed. The mission requirements include a geosynchronous Earth orbit vehicle for the construction, servicing, repair and operation of communications, solar power, and Earth observation satellites.

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...

openECA Detailed Design Document

DOE Office of Scientific and Technical Information (OSTI.GOV)

Robertson, Russell

This document describes the functional and non-functional requirements for: The openECA platform The included analytic systems that will: Validate the operational readiness and performance of the openECA platform Provide out-of-box value to those that implement the openECA platform with an initial collection of analytics

Documenting the Assessment of Institutional Effectiveness at Community Colleges in Ohio

ERIC Educational Resources Information Center

Zahler, Megan M.

2013-01-01

The community college of today confronts decreased state funding, increased demand, and increased calls for accountability. In this highly competitive environment, community colleges are required to document the assessment of institutional effectiveness to satisfy state accountability systems and regional accreditation standards. The purpose of…

Data Quality Objectives for Regulatory Requirements for Hazardous and Radioactive Air Emissions Sampling and Analysis

DOE Office of Scientific and Technical Information (OSTI.GOV)

MULKEY, C.H.

1999-07-06

This document describes the results of the data quality objective (DQO) process undertaken to define data needs for state and federal requirements associated with toxic, hazardous, and/or radiological air emissions under the jurisdiction of the River Protection Project (RPP). Hereafter, this document is referred to as the Air DQO. The primary drivers for characterization under this DQO are the regulatory requirements pursuant to Washington State regulations, that may require sampling and analysis. The federal regulations concerning air emissions are incorporated into the Washington State regulations. Data needs exist for nonradioactive and radioactive waste constituents and characteristics as identified through themore » DQO process described in this document. The purpose is to identify current data needs for complying with regulatory drivers for the measurement of air emissions from RPP facilities in support of air permitting. These drivers include best management practices; similar analyses may have more than one regulatory driver. This document should not be used for determining overall compliance with regulations because the regulations are in constant change, and this document may not reflect the latest regulatory requirements. Regulatory requirements are also expected to change as various permits are issued. Data needs require samples for both radionuclides and nonradionuclide analytes of air emissions from tanks and stored waste containers. The collection of data is to support environmental permitting and compliance, not for health and safety issues. This document does not address health or safety regulations or requirements (those of the Occupational Safety and Health Administration or the National Institute of Occupational Safety and Health) or continuous emission monitoring systems. This DQO is applicable to all equipment, facilities, and operations under the jurisdiction of RPP that emit or have the potential to emit regulated air pollutants.« less

Database management systems for process safety.

PubMed

Early, William F

2006-03-17

Several elements of the process safety management regulation (PSM) require tracking and documentation of actions; process hazard analyses, management of change, process safety information, operating procedures, training, contractor safety programs, pre-startup safety reviews, incident investigations, emergency planning, and compliance audits. These elements can result in hundreds of actions annually that require actions. This tracking and documentation commonly is a failing identified in compliance audits, and is difficult to manage through action lists, spreadsheets, or other tools that are comfortably manipulated by plant personnel. This paper discusses the recent implementation of a database management system at a chemical plant and chronicles the improvements accomplished through the introduction of a customized system. The system as implemented modeled the normal plant workflows, and provided simple, recognizable user interfaces for ease of use.

NASA/ESA CV-990 Spacelab simulation. Appendixes: C, data-handling: Planning and implementation; D, communications; E, mission documentation

NASA Technical Reports Server (NTRS)

Reller, J. O., Jr.

1976-01-01

Data handling, communications, and documentation aspects of the ASSESS mission are described. Most experiments provided their own data handling equipment, although some used the airborne computer for backup, and one experiment required real-time computations. Communications facilities were set up to simulate those to be provided between Spacelab and the ground, including a downlink TV system. Mission documentation was kept to a minimum and proved sufficient. Examples are given of the basic documents of the mission.

Identification of high-level functional/system requirements for future civil transports

NASA Technical Reports Server (NTRS)

Swink, Jay R.; Goins, Richard T.

1992-01-01

In order to accommodate the rapid growth in commercial aviation throughout the remainder of this century, the Federal Aviation Administration (FAA) is faced with a formidable challenge to upgrade and/or modernize the National Airspace System (NAS) without compromising safety or efficiency. A recurring theme in both the Aviation System Capital Investment Plan (CIP), which has replaced the NAS Plan, and the new FAA Plan for Research, Engineering, and Development (RE&D) rely on the application of new technologies and a greater use of automation. Identifying the high-level functional and system impacts of such modernization efforts on future civil transport operational requirements, particularly in terms of cockpit functionality and information transfer, was the primary objective of this project. The FAA planning documents for the NAS of the 2005 era and beyond were surveyed; major aircraft functional capabilities and system components required for such an operating environment were identified. A hierarchical structured analysis of the information processing and flows emanating from such functional/system components were conducted and the results documented in graphical form depicting the relationships between functions and systems.

Trusted Computing Technologies, Intel Trusted Execution Technology.

DOE Office of Scientific and Technical Information (OSTI.GOV)

Guise, Max Joseph; Wendt, Jeremy Daniel

2011-01-01

We describe the current state-of-the-art in Trusted Computing Technologies - focusing mainly on Intel's Trusted Execution Technology (TXT). This document is based on existing documentation and tests of two existing TXT-based systems: Intel's Trusted Boot and Invisible Things Lab's Qubes OS. We describe what features are lacking in current implementations, describe what a mature system could provide, and present a list of developments to watch. Critical systems perform operation-critical computations on high importance data. In such systems, the inputs, computation steps, and outputs may be highly sensitive. Sensitive components must be protected from both unauthorized release, and unauthorized alteration: Unauthorizedmore » users should not access the sensitive input and sensitive output data, nor be able to alter them; the computation contains intermediate data with the same requirements, and executes algorithms that the unauthorized should not be able to know or alter. Due to various system requirements, such critical systems are frequently built from commercial hardware, employ commercial software, and require network access. These hardware, software, and network system components increase the risk that sensitive input data, computation, and output data may be compromised.« less

A review of the FDA draft guidance document for software validation: guidance for industry.

PubMed

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.

Contingency Contractor Optimization Phase 3 Sustainment Requirements Document Contingency Contractor Optimization Tool - Prototype

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.

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.

System analysis study of space platform and station accommodations for life sciences research facilities. Volume 1: Executive summary. Phase A: Conceptual design and programmatics

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.

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.

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.

Space station systems: A bibliography with indexes (supplement 6)

NASA Technical Reports Server (NTRS)

1988-01-01

This bibliography lists 1,133 reports, articles, and other documents introduced into the NASA scientific and technical information system between July 1, 1987 and December 31, 1987. Its purpose is to provide helpful information to the researcher, manager, and designer in technology development and mission design according to system, interactive analysis and design, structural and thermal analysis and design, structural concepts and control systems, electronics, advanced materials, assembly concepts, propulsion, and solar power satellite systems. The coverage includes documents that define major systems and subsystems, servicing and support requirements, procedures and operations, and missions for the current and future Space Station.

Space station systems: A bibliography with indexes (supplement 3)

NASA Technical Reports Server (NTRS)

1987-01-01

This bibliography lists 780 reports, articles and other documents introduced into the NASA scientific and technical information system between January 1, 1986 and June 30, 1986. Its purpose is to provide helpful information to the researcher, manager, and designer in technology development and mission design according to system, interactive analysis and design, structural and thermal analysis and design, structural concepts and control systems, electronics, advanced materials, assembly concepts, propulsion, and solar power satellite system. The coverage includes documents that define major systems and subsystems, servicing and support requirements, procedures and operations, and missions for the current and future space station.

Space station systems: A bibliography with indexes (supplement 2)

NASA Technical Reports Server (NTRS)

1986-01-01

This bibliography lists 904 reports, articles and other documents introduced into the NASA scientific and technical information system between July 1, 1985 and December 31, 1985. Its purpose is to provide helpful information to the researcher, manager, and designer in technology development and mission design according to system, interactive analysis and design, structural and thermal analysis and design, structural concepts and control systems, electronics, advanced materials, assembly concepts, propulsion, and solar power satellite systems. The coverage includes documents that define major systems and subsystems, servicing and support requirements, procedures and operations, and missions for the current and future space station.

Space station systems: A bibliography with indexes

NASA Technical Reports Server (NTRS)

1987-01-01

This bibliography lists 967 reports, articles, and other documents introduced into the NASA scientific and technical information system between January 1, 1987 and June 30, 1987. Its purpose is to provide helpful information to the researcher, manager, and designer in technology development and mission design according to system, interactive analysis and design, structural and thermal analysis and design, structural concepts and control systems, electronics, advanced materials, assembly concepts, propulsion, and solar power satellite systems. The coverage includes documents that define major systems and subsystems, servicing and support requirements, procedures and operations, and missions for the current and future space station.

Land use and land cover digital data

USGS Publications Warehouse

Fegeas, Robin G.; Claire, Robert W.; Guptill, Stephen C.; Anderson, K. Eric; Hallam, Cheryl A.

1983-01-01

The discipline of cartography is undergoing a number of profound changesthat center on the emerging influence ofdigital manipulation and analysis ofdata for the preparation of cartographic materials and for use in geographic information systems. Operational requirements have led to the development by the USGS National Mapping Division of several documents that establish in-house digital cartographic standards. In an effort to fulfill lead agency requirements for promulgation of Federal standards in the earth sciences, the documents have been edited and assembled with explanatory text into a USGS Circular. This Circular describes some of the pertinent issues relative to digital cartographic data standards, documents the digital cartographic data standards currently in use within the USGS, and details the efforts of the USGS related to the definition of national digital cartographic data standards. It consists of several chapters; the first is a general overview, and each succeeding chapter is made up from documents that establish in-house standards for one of the various types of digital cartographic data currently produced. This chapter 895-E, describes the Geographic Information Retrieval and Analysis System that is used in conjunction with the USGS land use and land cover classification system to encode, edit, manipuate, and analyze land use and land cover digital data.

C2 Link Security for UAS: Technical Literature Study and Preliminary Functional Requirements. Version 0.9 (Working Draft)

NASA Technical Reports Server (NTRS)

2005-01-01

This document provides a study of the technical literature related to Command and Control (C2) link security for Unmanned Aircraft Systems (UAS) for operation in the National Airspace System (NAS). Included is a preliminary set of functional requirements for C2 link security.

ATALARS Operational Requirements: Automated Tactical Aircraft Launch and Recovery System

DOT National Transportation Integrated Search

1988-04-01

The Automated Tactical Aircraft Launch and Recovery System (ATALARS) is a fully automated air traffic management system intended for the military service but is also fully compatible with civil air traffic control systems. This report documents a fir...

77 FR 33489 - Draft Offender Tracking System Standard

Federal Register 2010, 2011, 2012, 2013, 2014

2012-06-06

... Tracking System Standard AGENCY: National Institute of Justice. ACTION: Notice of Draft Offender Tracking System Standard, Selection and Application Guide, and Certification Program Requirements. SUMMARY: In an...) A draft standard entitled, ``Offender Tracking System Standard'' (2) a draft companion document...

Air Force Space Command. Space and Missile Systems Center Standard. Electromagnetic Compatibility Requirements for Space Equipment and Systems

DTIC Science & Technology

2008-06-13

technology developments. 2. This new-issue SMC standard comprises the text of The Aerospace Corporation report number TOR-2005( 8583 )-1. 3...issues of the documents are the current versions. 1. Aerospace Report No. TOR-2005( 8583 )-2, Electrical Power Systems, Direct Current, Space Vehicle...Design Requirements, The Aerospace Corp., 13 January 2005. 2. Aerospace Report No. TR-2004( 8583 )-1 (proposed MIL-STD-1540E), Test Requirements for

48 CFR 1506.303-2 - Content.

Code of Federal Regulations, 2010 CFR

1997-10-01

... 48 Federal Acquisition Regulations System 6 1997-10-01 1997-10-01 false Content. 1506.303-2....303-2 Content. The documentation requirements in this section apply only to acquisitions processed... synopsis in the JOFOC. (See 1506.371(d) for contents of the evaluation document). [50 FR 14357, Apr. 11...

48 CFR 13.501 - Special documentation requirements.

Code of Federal Regulations, 2014 CFR

2014-10-01

... 48 Federal Acquisition Regulations System 1 2014-10-01 2014-10-01 false Special documentation... officer's knowledge and belief will serve as approval, unless a higher approval level is established in..., Sept. 30, 2005; 71 FR 57360, 57366, Sept. 28, 2006; 75 FR 34276, June 16, 2010; 75 FR 53132, Aug. 30...

48 CFR 13.501 - Special documentation requirements.

Code of Federal Regulations, 2011 CFR

2011-10-01

... 48 Federal Acquisition Regulations System 1 2011-10-01 2011-10-01 false Special documentation... and complete to the best of the contracting officer's knowledge and belief will serve as approval...; 69 FR 76352, Dec. 20, 2004; 70 FR 57457, Sept. 30, 2005; 71 FR 57360, 57366, Sept. 28, 2006; 75 FR...

48 CFR 13.501 - Special documentation requirements.

Code of Federal Regulations, 2010 CFR

2010-10-01

... 48 Federal Acquisition Regulations System 1 2010-10-01 2010-10-01 false Special documentation... and complete to the best of the contracting officer's knowledge and belief will serve as approval...; 69 FR 76352, Dec. 20, 2004; 70 FR 57457, Sept. 30, 2005; 71 FR 57360, 57366, Sept. 28, 2006; 75 FR...

Preliminary analysis of an integrated logistics system for OSSA payloads. Volume 3: OSSA integrated logistics support planning document

NASA Technical Reports Server (NTRS)

Palguta, T.; Bradley, W.; Stockton, T.

1988-01-01

Guidance in preparing and updating an integrated logistics support plan (ILSP) is given. Clear, concise, and detailed instructions are provided on the preparation and content of an ILSP in order to ensure a quality document that reflects total program requirements.

16 CFR 1211.12 - Requirements for edge sensors.

Code of Federal Regulations, 2012 CFR

2012-01-01

... edge sensor system and associated components shall withstand 30,000 cycles of mechanical operation... accordance with 5 U.S.C. 552(a) and 1 CFR part 51. Copies may be obtained from Global Engineering Documents, 15 Inverness Way East, Englewood, CO 80112, Telephone (800) 854-7179 or Global Engineering Documents...

41 CFR 102-118.565 - What documentation is required when filing an administrative claim?

Code of Federal Regulations, 2010 CFR

2010-07-01

... 41 Public Contracts and Property Management 3 2010-07-01 2010-07-01 false What documentation is... Management Federal Property Management Regulations System (Continued) FEDERAL MANAGEMENT REGULATION..., reports and information available to GSA and/or to the agency involved and the written and documentary...

Cargo Movement Operations System (CMOS) Requirements Traceability Matrix, Version 3 Increment II

DTIC Science & Technology

1990-12-17

above SCs should be documented. CMOS PMO ACCEPTS COMMENT: YES [ ] NO [ ] ERCI ACCEPTS COMMENT: YES [ ] NO [ ] COMMENT DISPOSITION: COMMENT STATUS: OPEN...These two documents should be in agreement with each other. CMOS PMO ACCEPTS COMMENT: YES [ ] NO [ ] ERCI ACCEPTS COMMENT: YES [ ] NO [ ] COMMENT DISPOSITION...completeness, they should be documented. CMOS PMO ACCEPTS COMMENT: YES [ ] NO [ ] ERCI ACCEPTS COMMENT: YES [ ] NO [ ] COMMENT DISPOSITION: COMMENT STATUS: OPEN

Addendum to the Closure Report for Corrective Action Unit 427: Area 3 Septic Waste Systems 2, 6, Tonopah Test Range, Nevada, Revision 0

DOE Office of Scientific and Technical Information (OSTI.GOV)

Lynn Kidman

This document constitutes an addendum to the April 1999, Closure Report for Corrective Action Unit 427: Area 3 Septic Waste Systems 2, 6, Tonopah Test Range, Nevada as described in the document Recommendations and Justifications for Modifications for Use Restrictions Established under the U.S. Department of Energy, National Nuclear Security Administration Nevada Site Office Federal Facility Agreement and Consent Order (UR Modification document) dated February 2008. The UR Modification document was approved by NDEP on February 26, 2008. The approval of the UR Modification document constituted approval of each of the recommended UR modifications. In conformance with the UR Modificationmore » document, this addendum consists of: • This cover page that refers the reader to the UR Modification document for additional information • The cover and signature pages of the UR Modification document • The NDEP approval letter • The corresponding section of the UR Modification document This addendum provides the documentation justifying the cancellation of the URs for: • CAS 03-05-002-SW02, Septic Waste System • CAS 03-05-002-SW06, Septic Waste System These URs were established as part of Federal Facility Agreement and Consent Order (FFACO) corrective actions and were based on the presence of contaminants at concentrations greater than the action levels established at the time of the initial investigation (FFACO, 1996; as amended August 2006). Since these URs were established, practices and procedures relating to the implementation of risk-based corrective actions (RBCA) have changed. Therefore, these URs were re-evaluated against the current RBCA criteria as defined in the Industrial Sites Project Establishment of Final Action Levels (NNSA/NSO, 2006c). This re-evaluation consisted of comparing the original data (used to define the need for the URs) to risk-based final action levels (FALs) developed using the current Industrial Sites RBCA process. The re-evaluation resulted in a recommendation to remove these URs because contamination is not present at these sites above the risk-based FALs. Requirements for inspecting and maintaining these URs will be canceled, and the postings and signage at each site will be removed. Fencing and posting may be present at these sites that are unrelated to the FFACO URs such as for radiological control purposes as required by the NV/YMP Radiological Control Manual (NNSA/NSO, 2004f). This modification will not affect or modify any non-FFACO requirements for fencing, posting, or monitoring at these sites.« less

Astrionics system designers handbook, volume 1

NASA Technical Reports Server (NTRS)

1973-01-01

Hardware elements in new and advanced astrionics system designs are discussed. This cost effective approach has as its goal the reduction of R&D and testing costs through the application of proven and tested astrionics components. The ready availability to the designer of data facts for applicable system components is highly desirable. The astrionics System Designers Handbook has as its objective this documenting of data facts to serve the anticipated requirements of the astrionics system designer. Eleven NASA programs were selected as the reference base for the document. These programs are: ATS-F, ERTS-B, HEAO-A, OSO-I, Viking Orbiter, OAO-C, Skylab AM/MDA, Skylab ATM, Apollo 17 CSM, Apollo 17 LM and Mariner Mars 71. Four subsystems were chosen for documentation: communications, data management, electrical power and guidance, navigation and control.

Evaluation of automated decisionmaking methodologies and development of an integrated robotic system simulation, volume 2, part 1. Appendix A: Software documentation

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.

Computer Applications Group FY91 final report, February 11, 1991--September 30, 1991

DOE Office of Scientific and Technical Information (OSTI.GOV)

Not Available

1992-02-24

This Functional Requirements Document (FRD) defines the functional requirements and general solutions required for design of the Integrated Data System (IDS). The FRD is the primary source of requirements for the designers and all requirements used in the design process shall be part of this or succeeding revisions of the FRD with no exceptions.

Information retrieval for a document writing assistance program

DOE Office of Scientific and Technical Information (OSTI.GOV)

Corral, M.L.; Simon, A.; Julien, C.

This paper presents an Information Retrieval mechanism to facilitate the writing of technical documents in the space domain. To address the need for document exchange between partners in a given project, documents are standardized. The writing of a new document requires the re-use of existing documents or parts thereof. These parts can be identified by {open_quotes}tagging{close_quotes} the logical structure of documents and restored by means of a purpose-built Information Retrieval System (I.R.S.). The I.R.S. implemented in our writing assistance tool uses natural language queries and is based on a statistical linguistic approach which is enhanced by the use of documentmore » structure module.« less

Requirements-Based Conformance Testing of ARINC 653 Real-Time Operating Systems

NASA Astrophysics Data System (ADS)

Maksimov, Andrey

2010-08-01

Requirements-based testing is emphasized in avionics certification documents because this strategy has been found to be the most effective at revealing errors. This paper describes the unified requirements-based approach to the creation of conformance test suites for mission-critical systems. The approach uses formal machine-readable specifications of requirements and finite state machine model for test sequences generation on-the-fly. The paper also presents the test system for automated test generation for ARINC 653 services built on this approach. Possible application of the presented approach to various areas of avionics embedded systems testing is discussed.

Crewed Space Vehicle Battery Safety Requirements

NASA Technical Reports Server (NTRS)

Jeevarajan, Judith A.; Darcy, Eric C.

2014-01-01

This requirements document is applicable to all batteries on crewed spacecraft, including vehicle, payload, and crew equipment batteries. It defines the specific provisions required to design a battery that is safe for ground personnel and crew members to handle and/or operate during all applicable phases of crewed missions, safe for use in the enclosed environment of a crewed space vehicle, and safe for use in launch vehicles, as well as in unpressurized spaces adjacent to the habitable portion of a space vehicle. The required provisions encompass hazard controls, design evaluation, and verification. The extent of the hazard controls and verification required depends on the applicability and credibility of the hazard to the specific battery design and applicable missions under review. Evaluation of the design and verification program results shall be completed prior to certification for flight and ground operations. This requirements document is geared toward the designers of battery systems to be used in crewed vehicles, crew equipment, crew suits, or batteries to be used in crewed vehicle systems and payloads (or experiments). This requirements document also applies to ground handling and testing of flight batteries. Specific design and verification requirements for a battery are dependent upon the battery chemistry, capacity, complexity, charging, environment, and application. The variety of battery chemistries available, combined with the variety of battery-powered applications, results in each battery application having specific, unique requirements pertinent to the specific battery application. However, there are basic requirements for all battery designs and applications, which are listed in section 4. Section 5 includes a description of hazards and controls and also includes requirements.

Requirements Specification Language (RSL) and supporting tools

NASA Technical Reports Server (NTRS)

Frincke, Deborah; Wolber, Dave; Fisher, Gene; Cohen, Gerald C.

1992-01-01

This document describes a general purpose Requirement Specification Language (RSL). RSL is a hybrid of features found in several popular requirement specification languages. The purpose of RSL is to describe precisely the external structure of a system comprised of hardware, software, and human processing elements. To overcome the deficiencies of informal specification languages, RSL includes facilities for mathematical specification. Two RSL interface tools are described. The Browser view contains a complete document with all details of the objects and operations. The Dataflow view is a specialized, operation-centered depiction of a specification that shows how specified operations relate in terms of inputs and outputs.

Report on detailed requirements for the INFLO prototype.

DOT National Transportation Integrated Search

2013-12-01

This report documents the System Requirements for the implementation of the Intelligent Network Flow Optimization (INFLO) Prototype bundle within the Dynamic Mobility Applications (DMA) portion of the Connected Vehicle Program. It builds off of the p...

Earth Observing System/Meteorological Satellite (EOS/METSAT). Advanced Microwave Sounding Unit-A (AMSU-A) Contamination Control Plan

NASA Technical Reports Server (NTRS)

Fay, M.

1998-01-01

This Contamination Control Plan is submitted in response the Contract Document requirements List (CDRL) 007 under contract NAS5-32314 for the Earth Observing System (EOS) Advanced Microwave Sounding Unit A (AMSU-A). In response to the CDRL instructions, this document defines the level of cleanliness and methods/procedures to be followed to achieve adequate cleanliness/contamination control, and defines the required approach to maintain cleanliness/contamination control through shipping, observatory integration, test, and flight. This plan is also applicable to the Meteorological Satellite (METSAT) except where requirements are identified as EOS-specific. This plan is based on two key factors: a. The EOS/METSAT AMSU-A Instruments are not highly contamination sensitive. b. Potential contamination of other EOS Instruments is a key concern as addressed in Section 9/0 of the Performance Assurance Requirements for EOS/METSAT Integrated Programs AMSU-A Instrument (MR) (NASA Specification S-480-79).

77 FR 29247 - Federal Motor Vehicle Safety Standards; Occupant Crash Protection

Federal Register 2010, 2011, 2012, 2013, 2014

2012-05-17

...). ACTION: Final rule; technical amendments. SUMMARY: This final rule makes technical amendments to Federal... advanced air bag requirements. As written now, the general warning label requirements contain an explicit... equipment requirements for restraint systems. This document makes technical amendments to several of the...

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...

Do Combined Cycle Gas Turbine Systems Qualify as Electric Utility Steam Generating Units for Purposes of Determining Applicability of NSR

EPA Pesticide Factsheets

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.

Videofile for Law Enforcement

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.

Utilizing IHE-based Electronic Health Record systems for secondary use.

PubMed

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.

AN ULTRAVIOLET-VISIBLE SPECTROPHOTOMETER AUTOMATION SYSTEM. PART I: FUNCTIONAL SPECIFICATIONS

EPA Science Inventory

This document contains the project definition, the functional requirements, and the functional design for a proposed computer automation system for scanning spectrophotometers. The system will be implemented on a Data General computer using the BASIC language. The system is a rea...

76 FR 13436 - NIJ Request for Comments on Draft Vehicular Digital Multimedia Evidence Recording System...

Federal Register 2010, 2011, 2012, 2013, 2014

2011-03-11

... Comments on Draft Vehicular Digital Multimedia Evidence Recording System Certification Program Requirements for Law Enforcement and Draft Law Enforcement Vehicular Digital Multimedia Evidence Recording System... two draft documents: ``Vehicular Digital Multimedia Evidence Recording System Certification Program...

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.

Intranet-based quality improvement documentation at the Veterans Affairs Maryland Health Care System.

PubMed

Borkowski, A; Lee, D H; Sydnor, D L; Johnson, R J; Rabinovitch, A; Moore, G W

2001-01-01

The Pathology and Laboratory Medicine Service of the Veterans Affairs Maryland Health Care System is inspected biannually by the College of American Pathologists (CAP). As of the year 2000, all documentation in the Anatomic Pathology Section is available to all staff through the VA Intranet. Signed, supporting paper documents are on file in the office of the department chair. For the year 2000 CAP inspection, inspectors conducted their document review by use of these Web-based documents, in which each CAP question had a hyperlink to the corresponding section of the procedure manual. Thus inspectors were able to locate the documents relevant to each question quickly and efficiently. The procedure manuals consist of 87 procedures for surgical pathology, 52 procedures for cytopathology, and 25 procedures for autopsy pathology. Each CAP question requiring documentation had from one to three hyperlinks to the corresponding section of the procedure manual. Intranet documentation allows for easier sharing among decentralized institutions and for centralized updates of the laboratory documentation. These documents can be upgraded to allow for multimedia presentations, including text search for key words, hyperlinks to other documents, and images, audio, and video. Use of Web-based documents can improve the efficiency of the inspection process.

Overview of the EPA Quality System for Environmental Data and Technology

EPA Pesticide Factsheets

This document provides a brief summary of EPA’s Quality System for environmental data and technology for EPA and non-EPA organizations who are not familiar with the system but are subject to its requirements.

48 CFR 232.901 - Applicability.

Code of Federal Regulations, 2013 CFR

2013-10-01

... 48 Federal Acquisition Regulations System 3 2013-10-01 2013-10-01 false Applicability. 232.901 Section 232.901 Federal Acquisition Regulations System DEFENSE ACQUISITION REGULATIONS SYSTEM, DEPARTMENT... and shipments require language translations that cannot be performed and documented within normal...

Detailed requirements document for the Interactive Financial Management System (IFMS), volume 1

NASA Technical Reports Server (NTRS)

Dodson, D. B.

1975-01-01

The detailed requirements for phase 1 (online fund control, subauthorization accounting, and accounts receivable functional capabilities) of the Interactive Financial Management System (IFMS) are described. This includes information on the following: systems requirements, performance requirements, test requirements, and production implementation. Most of the work is centered on systems requirements, and includes discussions on the following processes: resources authority, allotment, primary work authorization, reimbursable order acceptance, purchase request, obligation, cost accrual, cost distribution, disbursement, subauthorization performance, travel, accounts receivable, payroll, property, edit table maintenance, end-of-year, backup input. Other subjects covered include: external systems interfaces, general inquiries, general report requirements, communication requirements, and miscellaneous. Subjects covered under performance requirements include: response time, processing volumes, system reliability, and accuracy. Under test requirements come test data sources, general test approach, and acceptance criteria. Under production implementation come data base establishment, operational stages, and operational requirements.

Preliminary design data package, appendix C. [hybrid electric vehicles

NASA Technical Reports Server (NTRS)

1979-01-01

The data and documentation required to define the preliminary design of a near term hybrid vehicle and to quantify its operational characteristics are presented together with the assumptions and rationale behind the design decisions. Aspects discussed include development requirements for the propulsion system, the chassis system, the body, and the vehicle systems. Particular emphasis is given to the controls, the heat engine, and the batteries.

Data-Base for Communication Planning. The Basic and Statistical Data Required for the Elaboration of a Plan for a National Communication System.

ERIC Educational Resources Information Center

Rahim, Syed A.

Based in part on a list developed by the United Nations Educational, Scientific, and Cultural Organization (UNESCO) for use in Afghanistan, this document presents a comprehensive checklist of items of statistical and descriptive data required for planning a national communication system. It is noted that such a system provides the vital…

Integrated Baseline System (IBS), Version 1.03. User guide: Chemical Stockpile Emergency Preparedness Program

DOE Office of Scientific and Technical Information (OSTI.GOV)

Bailey, B.M.; Burford, M.J.; Downing, T.R.

The Integrated Baseline System (IBS), operated by the Federal Emergency Management Agency (FEMA), is a system of computerized tools for emergency planing and analysis. This document is the user guide for the IBS and explains how to operate the IBS system. The fundamental function of the IBS is to provide tools that civilian emergency management personnel can use in developing emergency plans and in supporting emergency management activities to cope with a chemical-releasing event at a military chemical stockpile. Emergency management planners can evaluate concepts and ideas using the IBS system. The results of that experience can then be factoredmore » into refining requirements and plans. This document provides information for the general system user, and is the primary reference for the system features of the IBS. It is designed for persons who are familiar with general emergency management concepts, operations, and vocabulary. Although the IBS manual set covers basic and advanced operations, it is not a complete reference document set. Emergency situation modeling software in the IBS is supported by additional technical documents. Some of the other LBS software is commercial software for which more complete documentation is available. The IBS manuals reference such documentation where necessary. IBS is a dynamic system. Its capabilities are in a state of continuing expansion and enhancement.« less

Software Safety Risk in Legacy Safety-Critical Computer Systems

NASA Technical Reports Server (NTRS)

Hill, Janice L.; Baggs, Rhoda

2007-01-01

Safety Standards contain technical and process-oriented safety requirements. Technical requirements are those such as "must work" and "must not work" functions in the system. Process-Oriented requirements are software engineering and safety management process requirements. Address the system perspective and some cover just software in the system > NASA-STD-8719.13B Software Safety Standard is the current standard of interest. NASA programs/projects will have their own set of safety requirements derived from the standard. Safety Cases: a) Documented demonstration that a system complies with the specified safety requirements. b) Evidence is gathered on the integrity of the system and put forward as an argued case. [Gardener (ed.)] c) Problems occur when trying to meet safety standards, and thus make retrospective safety cases, in legacy safety-critical computer systems.

Configuration management plan. System definition and project development. Repository Based Software Engineering (RBSE) program

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.

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.

Description of the AILS Alerting Algorithm

NASA Technical Reports Server (NTRS)

Samanant, Paul; Jackson, Mike

2000-01-01

This document provides a complete description of the Airborne Information for Lateral Spacing (AILS) alerting algorithms. The purpose of AILS is to provide separation assurance between aircraft during simultaneous approaches to closely spaced parallel runways. AILS will allow independent approaches to be flown in such situations where dependent approaches were previously required (typically under Instrument Meteorological Conditions (IMC)). This is achieved by providing multiple levels of alerting for pairs of aircraft that are in parallel approach situations. This document#s scope is comprehensive and covers everything from general overviews, definitions, and concepts down to algorithmic elements and equations. The entire algorithm is presented in complete and detailed pseudo-code format. This can be used by software programmers to program AILS into a software language. Additional supporting information is provided in the form of coordinate frame definitions, data requirements, calling requirements as well as all necessary pre-processing and post-processing requirements. This is important and required information for the implementation of AILS into an analysis, a simulation, or a real-time system.

Digitization of medical documents: an X-Windows application for fast scanning.

PubMed

Muñoz, A; Salvador, C H; Gonzalez, M A; Dueñas, A

1992-01-01

This paper deals with digitization, using a commercial scanner, of medical documents as still images for introduction into a computer-based Information System. Document management involves storing, editing and transmission. This task has usually been approached from the perspective of the difficulties posed by radiologic images because of their indisputable qualitative and quantitative significance. However, healthcare activities require the management of many other types of documents and involve the requirements of numerous users. One key to document management will be the availability of a digitizer to deal with the greatest possible number of different types of documents. This paper describes the relevant aspects of documents and the technical specifications that digitizers must fulfill. The concept of document type is introduced as the ideal set of digitizing parameters for a given document. The use of document type parameters can drastically reduce the time the user spends in scanning sessions. Presentation is made of an application based on Unix, X-Windows and OSF/Motif, with a GPIB interface, implemented around the document type concept. Finally, the results of the evaluation of the application are presented, focusing on the user interface, as well as on the viewing of color images in an X-Windows environment and the use of lossy algorithms in the compression of medical images.

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.

Validation Methods Research for Fault-Tolerant Avionics and Control Systems: Working Group Meeting, 2

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.

Requirements for migration of NSSD code systems from LTSS to NLTSS

NASA Technical Reports Server (NTRS)

Pratt, M.

1984-01-01

The purpose of this document is to address the requirements necessary for a successful conversion of the Nuclear Design (ND) application code systems to the NLTSS environment. The ND application code system community can be characterized as large-scale scientific computation carried out on supercomputers. NLTSS is a distributed operating system being developed at LLNL to replace the LTSS system currently in use. The implications of change are examined including a description of the computational environment and users in ND. The discussion then turns to requirements, first in a general way, followed by specific requirements, including a proposal for managing the transition.

Comparison of A-SMGCS Requirements with Observed Performance of an Integrated Airport CNS System

NASA Technical Reports Server (NTRS)

Young, Steven D.

1997-01-01

The International Civil Aviation Organization (ICAO) has recently drafted a reference document describing the operational requirements for Advanced Surface Movement Guidance and Control Systems (A-SMGCS). During the summer of 1997, NASA, the FAA, industry, and academia partners demonstrated a holistic system approach that has the potential to meet many of the proposed A-SMGCS requirements. An assessment of the field tested system and data resulting from the field testing is presented to determine its compliance with A-SMGCS requirements. In those areas where compliance was not demonstrated, a recommendation is presented suggesting further research or a modification of the system architecture.

Documentation of pharmaceutical care: Validation of an intervention oriented classification system.

PubMed

Maes, Karen A; Studer, Helene; Berger, Jérôme; Hersberger, Kurt E; Lampert, Markus L

2017-12-01

During the dispensing process, pharmacists may come across technical and clinical issues requiring a pharmaceutical intervention (PI). An intervention-oriented classification system is a helpful tool to document these PIs in a structured manner. Therefore, we developed the PharmDISC classification system (Pharmacists' Documentation of Interventions in Seamless Care). The aim of this study was to evaluate the PharmDISC system in the daily practice environment (in terms of interrater reliability, appropriateness, interpretability, acceptability, feasibility, and validity); to assess its user satisfaction, the descriptive manual, and the online training; and to explore first implementation aspects. Twenty-one pharmacists from different community pharmacies each classified 30 prescriptions requiring a PI with the PharmDISC system on 5 selected days within 5 weeks. Interrater reliability was determined using model PIs and Fleiss's kappa coefficients (κ) were calculated. User satisfaction was assessed by questionnaire with a 4-point Likert scale. The main outcome measures were interrater reliability (κ); appropriateness, interpretability, validity (ratio of completely classified PIs/all PIs); feasibility, and acceptability (user satisfaction and suggestions). The PharmDISC system reached an average substantial agreement (κ = 0.66). Of documented 519 PIs, 430 (82.9%) were completely classified. Most users found the system comprehensive (median user agreement 3 [2/3.25 quartiles]) and practical (3[2.75/3]). The PharmDISC system raised the awareness regarding drug-related problems for most users (n = 16). To facilitate its implementation, an electronic version that automatically connects to the prescription together with a task manager for PIs needing follow-up was suggested. Barriers could be time expenditure and lack of understanding the benefits. Substantial interrater reliability and acceptable user satisfaction indicate that the PharmDISC system is a valid system to document PIs in daily community pharmacy practice. © 2017 John Wiley & Sons, Ltd.

Advanced information processing system: Input/output network management software

NASA Technical Reports Server (NTRS)

Nagle, Gail; Alger, Linda; Kemp, Alexander

1988-01-01

The purpose of this document is to provide the software requirements and specifications for the Input/Output Network Management Services for the Advanced Information Processing System. This introduction and overview section is provided to briefly outline the overall architecture and software requirements of the AIPS system before discussing the details of the design requirements and specifications of the AIPS I/O Network Management software. A brief overview of the AIPS architecture followed by a more detailed description of the network architecture.

Hierarchical, Three-Dimensional Measurement System for Crime Scene Scanning.

PubMed

Marcin, Adamczyk; Maciej, Sieniło; Robert, Sitnik; Adam, Woźniak

2017-07-01

We present a new generation of three-dimensional (3D) measuring systems, developed for the process of crime scene documentation. This measuring system facilitates the preparation of more insightful, complete, and objective documentation for crime scenes. Our system reflects the actual requirements for hierarchical documentation, and it consists of three independent 3D scanners: a laser scanner for overall measurements, a situational structured light scanner for more minute measurements, and a detailed structured light scanner for the most detailed parts of tscene. Each scanner has its own spatial resolution, of 2.0, 0.3, and 0.05 mm, respectively. The results of interviews we have conducted with technicians indicate that our developed 3D measuring system has significant potential to become a useful tool for forensic technicians. To ensure the maximum compatibility of our measuring system with the standards that regulate the documentation process, we have also performed a metrological validation and designated the maximum permissible length measurement error E MPE for each structured light scanner. In this study, we present additional results regarding documentation processes conducted during crime scene inspections and a training session. © 2017 American Academy of Forensic Sciences.

User's manual for the Shuttle Electric Power System analysis computer program (SEPS), volume 2 of program documentation

NASA Technical Reports Server (NTRS)

Bains, R. W.; Herwig, H. A.; Luedeman, J. K.; Torina, E. M.

1974-01-01

The Shuttle Electric Power System Analysis SEPS computer program which performs detailed load analysis including predicting energy demands and consumables requirements of the shuttle electric power system along with parameteric and special case studies on the shuttle electric power system is described. The functional flow diagram of the SEPS program is presented along with data base requirements and formats, procedure and activity definitions, and mission timeline input formats. Distribution circuit input and fixed data requirements are included. Run procedures and deck setups are described.

Design of a clinical notification system.

PubMed

Wagner, M M; Tsui, F C; Pike, J; Pike, L

1999-01-01

We describe the requirements and design of an enterprise-wide notification system. From published descriptions of notification schemes, our own experience, and use cases provided by diverse users in our institution, we developed a set of functional requirements. The resulting design supports multiple communication channels, third party mappings (algorithms) from message to recipient and/or channel of delivery, and escalation algorithms. A requirement for multiple message formats is addressed by a document specification. We implemented this system in Java as a CORBA object. This paper describes the design and current implementation of our notification system.

Online mass storage system detailed requirements document

NASA Technical Reports Server (NTRS)

1976-01-01

The requirements for an online high density magnetic tape data storage system that can be implemented in a multipurpose, multihost environment is set forth. The objective of the mass storage system is to provide a facility for the compact storage of large quantities of data and to make this data accessible to computer systems with minimum operator handling. The results of a market survey and analysis of candidate vendor who presently market high density tape data storage systems are included.

Teaching Case: IS Security Requirements Identification from Conceptual Models in Systems Analysis and Design: The Fun & Fitness, Inc. Case

ERIC Educational Resources Information Center

Spears, Janine L.; Parrish, James L., Jr.

2013-01-01

This teaching case introduces students to a relatively simple approach to identifying and documenting security requirements within conceptual models that are commonly taught in systems analysis and design courses. An introduction to information security is provided, followed by a classroom example of a fictitious company, "Fun &…

American Association of University Women: Branch Operations Data Modeling Case

ERIC Educational Resources Information Center

Harris, Ranida B.; Wedel, Thomas L.

2015-01-01

A nationally prominent woman's advocacy organization is featured in this case study. The scenario may be used as a teaching case, an assignment, or a project in systems analysis and design as well as database design classes. Students are required to document the system operations and requirements, apply logical data modeling concepts, and design…

An exponentiation method for XML element retrieval.

PubMed

Wichaiwong, Tanakorn

2014-01-01

XML document is now widely used for modelling and storing structured documents. The structure is very rich and carries important information about contents and their relationships, for example, e-Commerce. XML data-centric collections require query terms allowing users to specify constraints on the document structure; mapping structure queries and assigning the weight are significant for the set of possibly relevant documents with respect to structural conditions. In this paper, we present an extension to the MEXIR search system that supports the combination of structural and content queries in the form of content-and-structure queries, which we call the Exponentiation function. It has been shown the structural information improve the effectiveness of the search system up to 52.60% over the baseline BM25 at MAP.

Semantic Clinical Guideline Documents

PubMed Central

Eriksson, Henrik; Tu, Samson W.; Musen, Mark

2005-01-01

Decision-support systems based on clinical practice guidelines can support physicians and other health-care personnel in the process of following best practice consistently. A knowledge-based approach to represent guidelines makes it possible to encode computer-interpretable guidelines in a formal manner, perform consistency checks, and use the guidelines directly in decision-support systems. Decision-support authors and guideline users require guidelines in human-readable formats in addition to computer-interpretable ones (e.g., for guideline review and quality assurance). We propose a new document-oriented information architecture that combines knowledge-representation models with electronic and paper documents. The approach integrates decision-support modes with standard document formats to create a combined clinical-guideline model that supports on-line viewing, printing, and decision support. PMID:16779037

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.

A Verification-Driven Approach to Traceability and Documentation for Auto-Generated Mathematical Software

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.

From a Content Delivery Portal to a Knowledge Management System for Standardized Cancer Documentation.

PubMed

Schlue, Danijela; Mate, Sebastian; Haier, Jörg; Kadioglu, Dennis; Prokosch, Hans-Ulrich; Breil, Bernhard

2017-01-01

Heterogeneous tumor documentation and its challenges of interpretation of medical terms lead to problems in analyses of data from clinical and epidemiological cancer registries. The objective of this project was to design, implement and improve a national content delivery portal for oncological terms. Data elements of existing handbooks and documentation sources were analyzed, combined and summarized by medical experts of different comprehensive cancer centers. Informatics experts created a generic data model based on an existing metadata repository. In order to establish a national knowledge management system for standardized cancer documentation, a prototypical tumor wiki was designed and implemented. Requirements engineering techniques were applied to optimize this platform. It is targeted to user groups such as documentation officers, physicians and patients. The linkage to other information sources like PubMed and MeSH was realized.

5 CFR 9901.221 - Classification requirements.

Code of Federal Regulations, 2010 CFR

2010-01-01

... Section 9901.221 Administrative Personnel DEPARTMENT OF DEFENSE HUMAN RESOURCES MANAGEMENT AND LABOR RELATIONS SYSTEMS (DEPARTMENT OF DEFENSE-OFFICE OF PERSONNEL MANAGEMENT) DEPARTMENT OF DEFENSE NATIONAL..., qualifications, and other requirements of categories of jobs, and will make such descriptions and documentation...

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.

48 CFR 13.501 - Special documentation requirements.

Code of Federal Regulations, 2012 CFR

2012-10-01

... 48 Federal Acquisition Regulations System 1 2012-10-01 2012-10-01 false Special documentation... justification is accurate and complete to the best of the contracting officer's knowledge and belief will serve..., Jan. 27, 2003; 69 FR 8314, Feb. 23, 2004; 69 FR 76352, Dec. 20, 2004; 70 FR 57457, Sept. 30, 2005; 71...

48 CFR 13.501 - Special documentation requirements.

Code of Federal Regulations, 2013 CFR

2013-10-01

... 48 Federal Acquisition Regulations System 1 2013-10-01 2013-10-01 false Special documentation... justification is accurate and complete to the best of the contracting officer's knowledge and belief will serve..., Jan. 27, 2003; 69 FR 8314, Feb. 23, 2004; 69 FR 76352, Dec. 20, 2004; 70 FR 57457, Sept. 30, 2005; 71...

Data Display Markup Language (DDML) Handbook

DTIC Science & Technology

2017-01-31

Moreover, the tendency of T&E is towards a plug-and-play-like data acquisition system that requires standard languages and modules for data displays...Telemetry Group DOCUMENT 127-17 DATA DISPLAY MARKUP LANGUAGE (DDML) HANDBOOK DISTRIBUTION A: APPROVED FOR...DOCUMENT 127-17 DATA DISPLAY MARKUP LANGUAGE (DDML) HANDBOOK January 2017 Prepared by Telemetry Group

12 CFR 625.12 - Documentation of fees and expenses.

Code of Federal Regulations, 2010 CFR

2010-01-01

... 12 Banks and Banking 6 2010-01-01 2010-01-01 false Documentation of fees and expenses. 625.12 Section 625.12 Banks and Banking FARM CREDIT ADMINISTRATION FARM CREDIT SYSTEM APPLICATION FOR AWARD OF FEES AND OTHER EXPENSES UNDER THE EQUAL ACCESS TO JUSTICE ACT Applicant Information Required § 625.12...

E4 AND COOPERATIVE AGREEMENTS: GUIDANCE TO EXTRAMURAL ORGANIZATIONS FOR DOCUMENTING CONFORMANCE TO ANSI/ASQC E4-1994

EPA Science Inventory

This paper makes suggestions on how to comply with ANSI/ASQC E4-1994 while avoiding some of the frustration. Some options for writing a quality system document compliant with E4 are given, along with a model outline, to provide assistance in interpreting requirements.

Challenges in reusing transactional data for daily documentation in neonatal intensive care.

PubMed

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.

Actual issues of introduction of continuous emission monitoring systems for control of negative impact of TPP to atmospheric air

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

Imaged Document Optical Correlation and Conversion System (IDOCCS)

NASA Astrophysics Data System (ADS)

Stalcup, Bruce W.; Dennis, Phillip W.; Dydyk, Robert B.

1999-03-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.). In addition, many organizations are converting their paper archives to electronic images, which are stored in a computer database. Because of this, there is a need to efficiently organize this data into comprehensive and accessible information resources. The Imaged Document Optical Correlation and Conversion System (IDOCCS) provides 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 capability of document images. The IDOCCS can be used to rapidly search for key words or phrases within the imaged document archives and can even 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, or documents with a particular individual's signature block, can be singled out. With this dual capability, IDOCCS outperforms systems that rely on optical character recognition as a basis for indexing and storing only the textual content of documents for later retrieval.

Standard formatted data units-control authority operations

NASA Technical Reports Server (NTRS)

1991-01-01

The purpose of this document is to illustrate a Control Authority's (CA) possible operation. The document is an interpretation and expansion of the concept found in the CA Procedures Recommendation. The CA is described in terms of the functions it performs for the management and control of data descriptions (metadata). Functions pertaining to the organization of Member Agency Control Authority Offices (MACAOs) (e.g., creating and disbanding) are not discussed. The document also provides an illustrative operational view of a CA through scenarios describing interaction between those roles involved in collecting, controlling, and accessing registered metadata. The roles interacting with the CA are identified by their actions in requesting and responding to requests for metadata, and by the type of information exchanged. The scenarios and examples presented in this document are illustrative only. They represent possible interactions supported by either a manual or automated system. These scenarios identify requirements for an automated system. These requirements are expressed by identifying the information to be exchanged and the services that may be provided by a CA for that exchange.

48 CFR 2811.002 - Policy.

Code of Federal Regulations, 2011 CFR

2011-10-01

... whenever metric is the accepted industry system. Whenever possible, commercially developed metric... include requirements documents stated in soft metric, hybrid, or dual systems, except when impractical or... 48 Federal Acquisition Regulations System 6 2011-10-01 2011-10-01 false Policy. 2811.002 Section...

48 CFR 2811.002 - Policy.

Code of Federal Regulations, 2012 CFR

2012-10-01

... whenever metric is the accepted industry system. Whenever possible, commercially developed metric... include requirements documents stated in soft metric, hybrid, or dual systems, except when impractical or... 48 Federal Acquisition Regulations System 6 2012-10-01 2012-10-01 false Policy. 2811.002 Section...

48 CFR 2811.002 - Policy.

Code of Federal Regulations, 2013 CFR

2013-10-01

... whenever metric is the accepted industry system. Whenever possible, commercially developed metric... include requirements documents stated in soft metric, hybrid, or dual systems, except when impractical or... 48 Federal Acquisition Regulations System 6 2013-10-01 2013-10-01 false Policy. 2811.002 Section...

48 CFR 2811.002 - Policy.

Code of Federal Regulations, 2014 CFR

2014-10-01

... whenever metric is the accepted industry system. Whenever possible, commercially developed metric... include requirements documents stated in soft metric, hybrid, or dual systems, except when impractical or... 48 Federal Acquisition Regulations System 6 2014-10-01 2014-10-01 false Policy. 2811.002 Section...

48 CFR 2811.002 - Policy.

Code of Federal Regulations, 2010 CFR

2010-10-01

... whenever metric is the accepted industry system. Whenever possible, commercially developed metric... include requirements documents stated in soft metric, hybrid, or dual systems, except when impractical or... 48 Federal Acquisition Regulations System 6 2010-10-01 2010-10-01 true Policy. 2811.002 Section...

42 CFR 493.1233 - Standard: Complaint investigations.

Code of Federal Regulations, 2011 CFR

2011-10-01

... SERVICES (CONTINUED) STANDARDS AND CERTIFICATION LABORATORY REQUIREMENTS Quality System for Nonwaived Testing General Laboratory Systems § 493.1233 Standard: Complaint investigations. The laboratory must have a system in place to ensure that it documents all complaints and problems reported to the laboratory...

Constellation Program Human-System Integration Requirements. Revision E, Nov. 19, 2010

NASA Technical Reports Server (NTRS)

Dory, Jonathan

2010-01-01

The Human-Systems Integration Requirements (HSIR) in this document drive the design of space vehicles, their systems, and equipment with which humans interface in the Constellation Program (CxP). These requirements ensure that the design of Constellation (Cx) systems is centered on the needs, capabilities, and limitations of the human. The HSIR provides requirements to ensure proper integration of human-to-system interfaces. These requirements apply to all mission phases, including pre-launch, ascent, Earth orbit, trans-lunar flight, lunar orbit, lunar landing, lunar ascent, Earth return, Earth entry, Earth landing, post-landing, and recovery. The Constellation Program must meet NASA's Agency-level human rating requirements, which are intended to ensure crew survival without permanent disability. The HSIR provides a key mechanism for achieving human rating of Constellation systems.

[Document management systems to support quality management systems at university hospitals - an interview-based study].

PubMed

Holderried, Martin; Bökel, Ann-Catrin; Ochsmann, Elke

2018-05-01

In order to save and control the processes and quality of medical services, a suitable steering system of all relevant documents is essential from the point of view of clinical quality management. Systems supporting an automated steering system of documents are called document management systems (DMS), and they also enter the healthcare sector. The use of DMS in the German healthcare sector has hardly been investigated so far. To close this knowledge gap, interviews were carried out with German university hospitals over a six-month period and subjected to a qualitative content analysis according to Mayring. In total, 25 university hospitals agreed to participate in this study, 19 of which have been working with a digital DMS for about six years on average. There was a great variety among the IT systems used. Document management and usability of the DMS as well as its integration into existing IT structures were key decision-making criteria for the selection of a digital DMS. In general, the long-term usability of the DMS is supported by regular evaluation of one's own requirements for the system, administration and training programs. In addition, DMS have a positive effect on patient safety and the quality of medical care. Copyright © 2018. Published by Elsevier GmbH.

MODIS information, data and control system (MIDACS) operations concepts

NASA Technical Reports Server (NTRS)

Han, D.; Salomonson, V.; Ormsby, J.; Ardanuy, P.; Mckay, A.; Hoyt, D.; Jaffin, S.; Vallette, B.; Sharts, B.; Folta, D.

1988-01-01

The MODIS Information, Data, and Control System (MIDACS) Operations Concepts Document provides a basis for the mutual understanding between the users and the designers of the MIDACS, including the requirements, operating environment, external interfaces, and development plan. In defining the concepts and scope of the system, how the MIDACS will operate as an element of the Earth Observing System (EOS) within the EosDIS environment is described. This version follows an earlier release of a preliminary draft version. The individual operations concepts for planning and scheduling, control and monitoring, data acquisition and processing, calibration and validation, data archive and distribution, and user access do not yet fully represent the requirements of the data system needed to achieve the scientific objectives of the MODIS instruments and science teams. The teams are not yet formed; however, it is possible to develop the operations concepts based on the present concept of EosDIS, the level 1 and level 2 Functional Requirements Documents, and through interviews and meetings with key members of the scientific community. The operations concepts were exercised through the application of representative scenarios.

CWA 15793 2011 Planning and Implementation Tool

DOE Office of Scientific and Technical Information (OSTI.GOV)

Gross, Alan; Nail, George

This software, built on an open source platform called Electron (runs on Chromium and Node.js), is designed to assist organizations in the implementation of a biorisk management system consistent with the requirements of the international, publicly available guidance document CEN Workshop Agreement 15793:2011 (CWA 15793). The software includes tools for conducting organizational gap analysis against CWA 15793 requirements, planning tools to support the implementation of CWA 15793 requirements, and performance monitoring support. The gap analysis questions are based on the text of CWA 15793, and its associated guidance document, CEN Workshop Agreement 16393:2012. The authors have secured permission from themore » publisher of CWA 15793, the European Committee for Standardization (CEN), to use language from the document in the software, with the understanding that the software will be made available freely, without charge.« less

The computer integrated documentation project: A merge of hypermedia and AI techniques

NASA Technical Reports Server (NTRS)

Mathe, Nathalie; Boy, Guy

1993-01-01

To generate intelligent indexing that allows context-sensitive information retrieval, a system must be able to acquire knowledge directly through interaction with users. In this paper, we present the architecture for CID (Computer Integrated Documentation). CID is a system that enables integration of various technical documents in a hypertext framework and includes an intelligent browsing system that incorporates indexing in context. CID's knowledge-based indexing mechanism allows case based knowledge acquisition by experimentation. It utilizes on-line user information requirements and suggestions either to reinforce current indexing in case of success or to generate new knowledge in case of failure. This allows CID's intelligent interface system to provide helpful responses, based on previous experience (user feedback). We describe CID's current capabilities and provide an overview of our plans for extending the system.

Analyzing Software Requirements Errors in Safety-Critical, Embedded Systems

NASA Technical Reports Server (NTRS)

Lutz, Robyn R.

1993-01-01

This paper analyzes the root causes of safety-related software errors in safety-critical, embedded systems. The results show that software errors identified as potentially hazardous to the system tend to be produced by different error mechanisms than non- safety-related software errors. Safety-related software errors are shown to arise most commonly from (1) discrepancies between the documented requirements specifications and the requirements needed for correct functioning of the system and (2) misunderstandings of the software's interface with the rest of the system. The paper uses these results to identify methods by which requirements errors can be prevented. The goal is to reduce safety-related software errors and to enhance the safety of complex, embedded systems.

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

48 CFR 211.275 - Radio frequency identification.

Code of Federal Regulations, 2010 CFR

2010-10-01

... 48 Federal Acquisition Regulations System 3 2010-10-01 2010-10-01 false Radio frequency identification. 211.275 Section 211.275 Federal Acquisition Regulations System DEFENSE ACQUISITION REGULATIONS... Requirements Documents 211.275 Radio frequency identification. ...

National Airspace System interface management plan

DOT National Transportation Integrated Search

1986-01-01

This document is intended to implement Interface Management for interfacing subsystems of the National Airspace System (NAS) and for external NAS interfaces by establishing a process which assures that: Interface requirements are agreed to by interfa...

Procedure for Electronic Management of Rulemaking and Other Docketed Records in the Federal Docket Management System

EPA Pesticide Factsheets

This procedure identifies the specific requirements, processes and supporting documents EPA uses to electronically manage rulemaking and other docketed records in the Federal Docket Management System (FDMS).

Magnetohydrodynamics (MHD) Engineering Test Facility (ETF) 200 MWe power plant. Design Requirements Document (DRD)

NASA Technical Reports Server (NTRS)

Rigo, H. S.; Bercaw, R. W.; Burkhart, J. A.; Mroz, T. S.; Bents, D. J.; Hatch, A. M.

1981-01-01

A description and the design requirements for the 200 MWe (nominal) net output MHD Engineering Test Facility (ETF) Conceptual Design, are presented. Performance requirements for the plant are identified and process conditions are indicated at interface stations between the major systems comprising the plant. Also included are the description, functions, interfaces and requirements for each of these major systems. The lastest information (1980-1981) from the MHD technology program are integrated with elements of a conventional steam electric power generating plant.

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.

The Electronic Documentation Project in the NASA mission control center environment

NASA Technical Reports Server (NTRS)

Wang, Lui; Leigh, Albert

1994-01-01

NASA's space programs like many other technical programs of its magnitude is supported by a large volume of technical documents. These documents are not only diverse but also abundant. Management, maintenance, and retrieval of these documents is a challenging problem by itself; but, relating and cross-referencing this wealth of information when it is all on a medium of paper is an even greater challenge. The Electronic Documentation Project (EDP) is to provide an electronic system capable of developing, distributing and controlling changes for crew/ground controller procedures and related documents. There are two primary motives for the solution. The first motive is to reduce the cost of maintaining the current paper based method of operations by replacing paper documents with electronic information storage and retrieval. And, the other is to improve the efficiency and provide enhanced flexibility in document usage. Initially, the current paper based system will be faithfully reproduced in an electronic format to be used in the document viewing system. In addition, this metaphor will have hypertext extensions. Hypertext features support basic functions such as full text searches, key word searches, data retrieval, and traversal between nodes of information as well as speeding up the data access rate. They enable related but separate documents to have relationships, and allow the user to explore information naturally through non-linear link traversals. The basic operational requirements of the document viewing system are to: provide an electronic corollary to the current method of paper based document usage; supplement and ultimately replace paper-based documents; maintain focused toward control center operations such as Flight Data File, Flight Rules and Console Handbook viewing; and be available NASA wide.

Development of a prediction model on the acceptance of electronic laboratory notebooks in academic environments.

PubMed

Kloeckner, Frederik; Farkas, Robert; Franken, Tobias; Schmitz-Rode, Thomas

2014-04-01

Documentation of research data plays a key role in the biomedical engineering innovation processes. It makes an important contribution to the protection of intellectual property, the traceability of results and fulfilling the regulatory requirement. Because of the increasing digitalization in laboratories, an electronic alternative to the commonly-used paper-bound notebooks could contribute to the production of sophisticated documentation. However, compared to in an industrial environment, the use of electronic laboratory notebooks is not widespread in academic laboratories. Little is known about the acceptance of an electronic documentation system and the underlying reasons for this. Thus, this paper aims to establish a prediction model on the potential preference and acceptance of scientists either for paper-based or electronic documentation. The underlying data for the analysis originate from an online survey of 101 scientists in industrial, academic and clinical environments. Various parameters were analyzed to identify crucial factors for the system preference using binary logistic regression. The analysis showed significant dependency between the documentation system preference and the supposed workload associated with the documentation system (p<0.006; odds ratio=58.543) and an additional personal component. Because of the dependency of system choice on specific parameters it is possible to predict the acceptance of an electronic laboratory notebook before implementation.

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

EMC Test Report Electrodynamic Dust Shield

NASA Technical Reports Server (NTRS)

Carmody, Lynne M.; Boyette, Carl B.

2014-01-01

This report documents the Electromagnetic Interference E M I evaluation performed on the Electrodynamic Dust Shield (EDS) which is part of the MISSE-X System under the Electrostatics and Surface Physics Laboratory at Kennedy Space Center. Measurements are performed to document the emissions environment associated with the EDS units. The purpose of this report is to collect all information needed to reproduce the testing performed on the Electrodynamic Dust Shield units, document data gathered during testing, and present the results. This document presents information unique to the measurements performed on the Bioculture Express Rack payload; using test methods prepared to meet SSP 30238 requirements. It includes the information necessary to satisfy the needs of the customer per work order number 1037104. The information presented herein should only be used to meet the requirements for which it was prepared.

Evaluating the usability of speech recognition to create clinical documentation using a commercial electronic health record.

PubMed

Hodgson, Tobias; Magrabi, Farah; Coiera, Enrico

2018-05-01

To conduct a usability study exploring the value of using speech recognition (SR) for clinical documentation tasks within an electronic health record (EHR) system. Thirty-five emergency department clinicians completed a system usability scale (SUS) questionnaire. The study was undertaken after participants undertook randomly allocated clinical documentation tasks using keyboard and mouse (KBM) or SR. SUS scores were analyzed and the results with KBM were compared to SR results. Significant difference in SUS scores between EHR system use with and without SR were observed (KBM 67, SR 61; P = 0.045; CI, 0.1 to 12.0). Nineteen of 35 participants scored higher for EHR with KBM, 11 higher for EHR with SR and 5 gave the same score for both. Factor analysis showed no significant difference in scores for the sub-element of usability (EHR with KBM 65, EHR with SR 62; P = 0.255; CI, -2.6 to 9.5). Scores for the sub-element of learnability were significantly different (KBM 72, SR 55; P < 0.001; CI, 9.8 to 23.5). A significant correlation was found between the perceived usability of the two system configurations (EHR with KBM or SR) and the efficiency of documentation (time to document) (P = 0.002; CI, 10.5 to -0.1) but not with safety (number of errors) (P = 0.90; CI, -2.3 to 2.6). SR was associated with significantly reduced overall usability scores, even though it is often positioned as ease of use technology. SR was perceived to impose larger costs in terms of learnability via training and support requirements for EHR based documentation when compared to using KBM. Lower usability scores were significantly associated with longer documentation times. The usability of EHR systems with any input modality is an area that requires continued development. The addition of an SR component to an EHR system may cause a significant reduction in terms of perceived usability by clinicians. Copyright © 2018 Elsevier B.V. All rights reserved.

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

Observations, Ideas, and Opinions: Systems Engineering and Integration for Return to Flight

NASA Technical Reports Server (NTRS)

Gafka, George K.

2006-01-01

This presentation addresses project management and systems engineering and integration challenges for return to flight, focusing on the Thermal Protection System Tile Repair Project (TRP). The program documentation philosophy, communication with program requirements flow and philosophy and planned deliverables and documentation are outlined. The development of TRP 'use-as-is' analytical tools is also highlighted and emphasis is placed on the use flight history to assess pre-flight and real-time risk. Additionally, an overview is provided of the repair procedure, including an outline of the logistics deployment chart.

Space station systems: A bibliography with indexes (supplement 7)

NASA Technical Reports Server (NTRS)

1988-01-01

This bibliography lists 1,158 reports, articles, and other documents introduced into the NASA scientific and technical information system between January 1, 1988 and June 30, 1988. Its purpose is to provide helpful information to researchers, designers and managers engaged in Space Station technology development and mission design. Coverage includes documents that define major systems and subsystems related to structures and dynamic control, electronics and power supplies, propulsion, and payload integration. In addition, orbital construction methods, servicing and support requirements, procedures and operations, and missions for the current and future Space Station are included.

Space station systems: A bibliography with indexes (supplement 10)

NASA Technical Reports Server (NTRS)

1990-01-01

This bibliography lists 1,422 reports, articles, and other documents introduced into the NASA scientific and technical information system between July 1, 1989 and December 31, 1989. Its purpose is to provide helpful information to researchers, designers and managers engaged in Space Station technology development and mission design. Coverage includes documents that define major systems and subsystems related to structures and dynamic control, electronics and power supplies, propulsion, and payload integration. In addition, orbital construction methods, servicing and support requirements, procedures and operations, and missions for the current and future Space Station are included.

Space Station Systems: a Bibliography with Indexes (Supplement 8)

NASA Technical Reports Server (NTRS)

1988-01-01

This bibliography lists 950 reports, articles, and other documents introduced into the NASA scientific and technical information system between July 1, 1989 and December 31, 1989. Its purpose is to provide helpful information to researchers, designers and managers engaged in Space Station technology development and mission design. Coverage includes documents that define major systems and subsystems related to structures and dynamic control, electronics and power supplies, propulsion, and payload integration. In addition, orbital construction methods, servicing and support requirements, procedures and operations, and missions for the current and future Space Station are included.

Space station systems: A bibliography with indexes (supplement 9)

NASA Technical Reports Server (NTRS)

1989-01-01

This bibliography lists 1,313 reports, articles, and other documents introduced into the NASA scientific and technical information system between January 1, 1989 and June 30, 1989. Its purpose is to provide helpful information to researchers, designers and managers engaged in Space Station technology development and mission design. Coverage includes documents that define major systems and subsystems related to structures and dynamic control, electronics and power supplies, propulsion, and payload integration. In addition, orbital construction methods, servicing and support requirements, procedures and operations, and missions for the current and future Space Station are included.

Safety-related requirements for photovoltaic modules and arrays. Final report

DOE Office of Scientific and Technical Information (OSTI.GOV)

Levins, A.

1984-03-01

Underwriters Laboratories has conducted a study to identify and develop safety requirements for photovoltaic module and panel designs and configurations for residential, intermediate, and large scale applications. Concepts for safety systems, where each system is a collection of subsystems which together address the total anticipated hazard situation, are described. Descriptions of hardware, and system usefulness and viability are included. This discussion of safety systems recognizes that there is little history on which to base the expected safety related performance of a photovoltaic system. A comparison of these systems, as against the provisions of the 1984 National Electrical Code covering photovoltaicmore » systems is made. A discussion of the UL investigation of the photovoltaic module evaluated to the provisions of the Proposed UL Standard for Flat-Plate Photovoltaic Modules and Panels is included. Grounding systems, their basis and nature, and the advantages and disadvantages of each are described. The meaning of frame grounding, circuit grounding, and the type of circuit ground are covered. The development of the Standard for Flat-Plate Photovoltaic Modules and Panels has continued, and with both industry comment and a product submittal and listing, the Standard has been refined to a viable document allowing an objective safety review of photovoltaic modules and panels. How this document, and other UL documents would cover investigations of certain other photovoltaic system components is described.« less

Automated Instructional Management Systems (AIMS) Version III, Users Manual.

ERIC Educational Resources Information Center

New York Inst. of Tech., Old Westbury.

This document sets forth the procedures necessary to utilize and understand the operating characteristics of the Automated Instructional Management System - Version III, a computer-based system for management of educational processes. Directions for initialization, including internal and user files; system and operational input requirements;…

The Bartlesville System; TGISS Software Documentation.

ERIC Educational Resources Information Center

Roberts, Tommy L.; And Others

TGISS (Total Guidance Information Support System) is an information storage and retrieval system specifically designed to meet the needs and requirements of a counselor in the Bartlesville Public School environment. The system, which is a combination of man/machine capabilities, includes the hardware and software necessary to extend the…

17 CFR 240.17i-5 - Record creation, maintenance, and access requirements for supervised investment bank holding...

Code of Federal Regulations, 2010 CFR

2010-04-01

... shall make and keep current the following records: (1) A record reflecting the results of stress tests...; and (5) Records documenting the system of internal risk management controls required to be established...

17 CFR 240.17i-5 - Record creation, maintenance, and access requirements for supervised investment bank holding...

Code of Federal Regulations, 2013 CFR

2013-04-01

... shall make and keep current the following records: (1) A record reflecting the results of stress tests...; and (5) Records documenting the system of internal risk management controls required to be established...

17 CFR 240.17i-5 - Record creation, maintenance, and access requirements for supervised investment bank holding...

Code of Federal Regulations, 2012 CFR

2012-04-01

... shall make and keep current the following records: (1) A record reflecting the results of stress tests...; and (5) Records documenting the system of internal risk management controls required to be established...

17 CFR 240.17i-5 - Record creation, maintenance, and access requirements for supervised investment bank holding...

Code of Federal Regulations, 2011 CFR

2011-04-01

... shall make and keep current the following records: (1) A record reflecting the results of stress tests...; and (5) Records documenting the system of internal risk management controls required to be established...

40 CFR 62.14620 - What site-specific documentation is required?

Code of Federal Regulations, 2010 CFR

2010-07-01

... the incinerator and associated air pollution control systems within the standards established under... required? 62.14620 Section 62.14620 Protection of Environment ENVIRONMENTAL PROTECTION AGENCY (CONTINUED...) Procedures for receiving, handling, and charging waste. (3) Incinerator startup, shutdown, and malfunction...

40 CFR 265.1064 - Recordkeeping requirements.

Code of Federal Regulations, 2010 CFR

2010-07-01

... waste management units in one recordkeeping system if the system identifies each record by each...) Design documentation and monitoring, operating, and inspection information for each closed-vent system...) An up-to-date analysis and the supporting information and data used to determine whether or not...

Installation of Existing Lift Systems for the Handicapped on Light Rail Vehicles

DOT National Transportation Integrated Search

1985-05-01

This report documents the results of a three-phase program to install an existing transit bus wheelchair lift system on a Boeing Light Rail Vehicle (LRV). Program activities included a review of lift requirements, evaluation of existing lift systems,...

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.

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.

Document fraud deterrent strategies: four case studies

NASA Astrophysics Data System (ADS)

Mercer, John W.

1998-04-01

This paper discusses the approaches taken to deter fraud committed against four documents: the machine-readable passport; the machine-readable visa; the Consular Report of Birth Abroad; and the Border Crossing Card. General approaches are discussed first, with an emphasis on the reasons for the document, the conditions of its use and the information systems required for it to function. A cost model of counterfeit deterrence is introduced. Specific approaches to each of the four documents are then discussed, in light of the issuance circumstances and criteria, the intent of the issuing authority, the applicable international standards and the level of protection and fraud resistance appropriate for the document.

Response to Request for Written Confirmation that the 100-Ton per Year Potential Emission Exemption for Graphic Art Systems Applies to Plantwide Emissions, Not to Each Printing Line

EPA Pesticide Factsheets

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.

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.

Urban Combat Advanced Training Technology (Technologie Avancee d’Entrainement au Combat Urbain)

DTIC Science & Technology

2010-04-01

JRTC Joint Readiness Training Center JRTC-MOUT-IS Joint Readiness Training Center Military Operations in Urbanised Terrain Instrumentation System...did not support or identify joint or multi-national requirements for conducting effective military operations in an urbanised environment. Very few...Requirements Document (ORD) for the Joint Readiness Training Center (JRTC) Military Operations on Urbanised Terrain (MOUT) Instrumentation System

48 CFR 227.7106 - Contracts for special works.

Code of Federal Regulations, 2012 CFR

2012-10-01

... works. 227.7106 Section 227.7106 Federal Acquisition Regulations System DEFENSE ACQUISITION REGULATIONS SYSTEM, DEPARTMENT OF DEFENSE GENERAL CONTRACTING REQUIREMENTS PATENTS, DATA, AND COPYRIGHTS Rights in... software documentation, scripts, soundtracks, musical compositions, and adaptations; histories of...

48 CFR 227.7106 - Contracts for special works.

Code of Federal Regulations, 2013 CFR

2013-10-01

... works. 227.7106 Section 227.7106 Federal Acquisition Regulations System DEFENSE ACQUISITION REGULATIONS SYSTEM, DEPARTMENT OF DEFENSE GENERAL CONTRACTING REQUIREMENTS PATENTS, DATA, AND COPYRIGHTS Rights in... software documentation, scripts, soundtracks, musical compositions, and adaptations; histories of...

48 CFR 227.7106 - Contracts for special works.

Code of Federal Regulations, 2010 CFR

2010-10-01

... works. 227.7106 Section 227.7106 Federal Acquisition Regulations System DEFENSE ACQUISITION REGULATIONS SYSTEM, DEPARTMENT OF DEFENSE GENERAL CONTRACTING REQUIREMENTS PATENTS, DATA, AND COPYRIGHTS Rights in... software documentation, scripts, soundtracks, musical compositions, and adaptations; histories of...

48 CFR 227.7106 - Contracts for special works.

Code of Federal Regulations, 2011 CFR

2011-10-01

... works. 227.7106 Section 227.7106 Federal Acquisition Regulations System DEFENSE ACQUISITION REGULATIONS SYSTEM, DEPARTMENT OF DEFENSE GENERAL CONTRACTING REQUIREMENTS PATENTS, DATA, AND COPYRIGHTS Rights in... software documentation, scripts, soundtracks, musical compositions, and adaptations; histories of...

48 CFR 227.7106 - Contracts for special works.

Code of Federal Regulations, 2014 CFR

2014-10-01

... works. 227.7106 Section 227.7106 Federal Acquisition Regulations System DEFENSE ACQUISITION REGULATIONS SYSTEM, DEPARTMENT OF DEFENSE GENERAL CONTRACTING REQUIREMENTS PATENTS, DATA, AND COPYRIGHTS Rights in... software documentation, scripts, soundtracks, musical compositions, and adaptations; histories of...

Binding Procurement

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.

Superfund Hazard Ranking System Training Course

EPA Pesticide Factsheets

The Hazard Ranking System (HRS) training course is a four and ½ day, intermediate-level course designed for personnel who are required to compile, draft, and review preliminary assessments (PAs), site inspections (SIs), and HRS documentation records/packag

48 CFR 211.275 - Passive radio frequency identification.

Code of Federal Regulations, 2011 CFR

2011-10-01

... 48 Federal Acquisition Regulations System 3 2011-10-01 2011-10-01 false Passive radio frequency identification. 211.275 Section 211.275 Federal Acquisition Regulations System DEFENSE ACQUISITION REGULATIONS... Requirements Documents 211.275 Passive radio frequency identification. ...

Critical Review of NOAA's Observation Requirements Process

NASA Astrophysics Data System (ADS)

LaJoie, M.; Yapur, M.; Vo, T.; Templeton, A.; Bludis, D.

2017-12-01

NOAA's Observing Systems Council (NOSC) maintains a comprehensive database of user observation requirements. The requirements collection process engages NOAA subject matter experts to document and effectively communicate the specific environmental observation measurements (parameters and attributes) needed to produce operational products and pursue research objectives. User observation requirements documented using a structured and standardized manner and framework enables NOAA to assess its needs across organizational lines in an impartial, objective, and transparent manner. This structure provides the foundation for: selecting, designing, developing, acquiring observing technologies, systems and architectures; budget and contract formulation and decision-making; and assessing in a repeatable fashion the productivity, efficiency and optimization of NOAA's observing system enterprise. User observation requirements are captured independently from observing technologies. Therefore, they can be addressed by a variety of current or expected observing capabilities and allow flexibility to be remapped to new and evolving technologies. NOAA's current inventory of user observation requirements were collected over a ten-year period, and there have been many changes in policies, mission priorities, and funding levels during this time. In light of these changes, the NOSC initiated a critical, in-depth review to examine all aspects of user observation requirements and associated processes during 2017. This presentation provides background on the NOAA requirements process, major milestones and outcomes of the critical review, and plans for evolving and connecting observing requirements processes in the next year.

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.

Feasibility of mining lunar resources for earth use: Circa 2000 AD. Volume 2: Technical discussion

NASA Technical Reports Server (NTRS)

Nishioka, K.; Arno, R. D.; Alexander, A. D.; Slye, R. E.

1973-01-01

The technologies and systems required to establish the mining base, mine, refine, and return lunar resources to earth are discussed. Gross equipment requirements, their weights and costs are estimated and documented. The operational requirements are analyzed and tabulated. Diagrams of equipment and processing facilities are provided.

Planetary data system requirements: Multi-mission radio science requirements for the 1978 to 1988 era

NASA Technical Reports Server (NTRS)

Howard, H. T. (Editor)

1979-01-01

The functional and performance requirements for support of multimission radio science are established. The classes of radio science investigation are described and the needed data is discussed. This document is for a sliding ten year period and will be iterated as the mission set evolves.

75 FR 80296 - Extension of Filing Accommodation for Static Pool Information in Filings With Respect to Asset...

Federal Register 2010, 2011, 2012, 2013, 2014

2010-12-22

... Systems in 1993 for document exchange. PDF captures formatting information from a variety of desktop publishing applications, making it possible to send formatted documents and have them appear on the recipient... Administrative Procedure Act generally requires that an agency publish an adopted rule in the Federal Register 30...

36 CFR 1234.10 - What are the facility requirements for all records storage facilities?

Code of Federal Regulations, 2014 CFR

2014-07-01

... the HVAC systems, fire alarm and fire protection systems. Manual switching between sources of service... elements are protected by a properly installed, properly maintained wet-pipe automatic sprinkler system, as... must provide documentation that the facility has a fire suppression system specifically designed to...

Operations and maintenance manual for the LDUA supervisory control and data acquisition system (LDUA System 4200) and control network (LDUA System 4400)

DOE Office of Scientific and Technical Information (OSTI.GOV)

Barnes, G.A.

1998-03-11

This document defines the requirements applicable to the operation, maintenance and storage of the Supervisory Control and Data Acquisition System (SCADAS) and Control Network in support of the Light Duty Utility Arm (LDUA) operations.

40 CFR 60.2910 - What site-specific documentation is required?

Code of Federal Regulations, 2010 CFR

2010-07-01

... the incinerator and associated air pollution control systems within the standards established under... required? 60.2910 Section 60.2910 Protection of Environment ENVIRONMENTAL PROTECTION AGENCY (CONTINUED) AIR...) Procedures for receiving, handling, and charging waste. (3) Incinerator startup, shutdown, and malfunction...

40 CFR 60.2095 - What site-specific documentation is required?

Code of Federal Regulations, 2010 CFR

2010-07-01

.... (5) Procedures for operating the incinerator and associated air pollution control systems within the... incinerator operating limits. (7) Reporting and recordkeeping procedures. (8) The waste management plan... required? 60.2095 Section 60.2095 Protection of Environment ENVIRONMENTAL PROTECTION AGENCY (CONTINUED) AIR...

Report on functional requirements and software architecture for the IDTO prototype : phase I demonstration site (Columbus).

DOT National Transportation Integrated Search

2013-08-01

This report documents the System Requirements and Architecture for the Phase I implementation of the Integrated Dynamic Transit Operations (IDTO) Prototype bundle within the Dynamic Mobility Applications (DMA) portion of the Connected Vehicle Program...

Report on functional requirements and software architecture for the IDTO prototype phase 2 : central Florida demonstration.

DOT National Transportation Integrated Search

2015-05-01

This report documents the System Requirements and Architecture for the Phase 2 implementation of the Integrated Dynamic Transit Operations (IDTO) Prototype bundle within the Dynamic Mobility Applications (DMA) portion of the Connected Vehicle Program...

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

Advanced Platform Systems Technology study. Volume 2: Trade study and technology selection

NASA Technical Reports Server (NTRS)

1983-01-01

Three primary tasks were identified which include task 1-trade studies, task 2-trade study comparison and technology selection, and task 3-technology definition. Task 1 general objectives were to identify candidate technology trade areas, determine which areas have the highest potential payoff, define specific trades within the high payoff areas, and perform the trade studies. In order to satisfy these objectives, a structured, organized approach was employed. Candidate technology areas and specific trades were screened using consistent selection criteria and considering possible interrelationships. A data base comprising both manned and unmanned space platform documentation was used as a source of system and subsystem requirements. When requirements were not stated in the data base documentation, assumptions were made and recorded where necessary to characterize a particular spacecraft system. The requirements and assumptions were used together with the selection criteria to establish technology advancement goals and select trade studies. While both manned and unmanned platform data were used, the study was focused on the concept of an early manned space station.

An Exponentiation Method for XML Element Retrieval

PubMed Central

2014-01-01

XML document is now widely used for modelling and storing structured documents. The structure is very rich and carries important information about contents and their relationships, for example, e-Commerce. XML data-centric collections require query terms allowing users to specify constraints on the document structure; mapping structure queries and assigning the weight are significant for the set of possibly relevant documents with respect to structural conditions. In this paper, we present an extension to the MEXIR search system that supports the combination of structural and content queries in the form of content-and-structure queries, which we call the Exponentiation function. It has been shown the structural information improve the effectiveness of the search system up to 52.60% over the baseline BM25 at MAP. PMID:24696643

76 FR 52350 - Vehicular Digital Multimedia Evidence Recording System (VDMERS) Standard, Certification Program...

Federal Register 2010, 2011, 2012, 2013, 2014

2011-08-22

... DEPARTMENT OF JUSTICE Office of Justice Programs [OJP (NIJ) Docket No. 1564] Vehicular Digital Multimedia Evidence Recording System (VDMERS) Standard, Certification Program Requirements, and Selection and... three draft documents related to Vehicular Digital Multimedia Evidence Recording Systems (VDMERSs) used...

13 CFR 143.20 - Standards for financial management systems.

Code of Federal Regulations, 2011 CFR

2011-01-01

... Requirements Financial Administration § 143.20 Standards for financial management systems. (a) A State must... prohibitions of applicable statutes. (b) The financial management systems of other grantees and subgrantees... subgrant award documents, etc. (7) Cash management. Procedures for minimizing the time elapsing between the...

15 CFR 24.20 - Standards for financial management systems.

Code of Federal Regulations, 2011 CFR

2011-01-01

... Requirements Financial Administration § 24.20 Standards for financial management systems. (a) A State must... prohibitions of applicable statutes. (b) The financial management systems of other grantees and subgrantees... subgrant award documents, etc. (7) Cash management. Procedures for minimizing the time elapsing between the...

13 CFR 143.20 - Standards for financial management systems.

Code of Federal Regulations, 2012 CFR

2012-01-01

... Requirements Financial Administration § 143.20 Standards for financial management systems. (a) A State must... prohibitions of applicable statutes. (b) The financial management systems of other grantees and subgrantees... subgrant award documents, etc. (7) Cash management. Procedures for minimizing the time elapsing between the...

13 CFR 143.20 - Standards for financial management systems.

Code of Federal Regulations, 2014 CFR

2014-01-01

... Requirements Financial Administration § 143.20 Standards for financial management systems. (a) A State must... prohibitions of applicable statutes. (b) The financial management systems of other grantees and subgrantees... subgrant award documents, etc. (7) Cash management. Procedures for minimizing the time elapsing between the...

15 CFR 24.20 - Standards for financial management systems.

Code of Federal Regulations, 2013 CFR

2013-01-01

... Requirements Financial Administration § 24.20 Standards for financial management systems. (a) A State must... prohibitions of applicable statutes. (b) The financial management systems of other grantees and subgrantees... subgrant award documents, etc. (7) Cash management. Procedures for minimizing the time elapsing between the...

13 CFR 143.20 - Standards for financial management systems.

Code of Federal Regulations, 2013 CFR

2013-01-01

... Requirements Financial Administration § 143.20 Standards for financial management systems. (a) A State must... prohibitions of applicable statutes. (b) The financial management systems of other grantees and subgrantees... subgrant award documents, etc. (7) Cash management. Procedures for minimizing the time elapsing between the...

28 CFR 66.20 - Standards for financial management systems.

Code of Federal Regulations, 2012 CFR

2012-07-01

... Requirements Financial Administration § 66.20 Standards for financial management systems. (a) A State must... prohibitions of applicable statutes. (b) The financial management systems of other grantees and subgrantees... subgrant award documents, etc. (7) Cash management. Procedures for minimizing the time elapsing between the...

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.

Final Inventory Work-Off Plan for ORNL transuranic wastes (1986 version)

DOE Office of Scientific and Technical Information (OSTI.GOV)

Dickerson, L.S.

1988-05-01

The Final Inventory Work-Off Plan (IWOP) for ORNL Transuranic Wastes addresses ORNL's strategy for retrieval, certification, and shipment of its stored and newly generated contact-handled (CH) and remote-handled (RH) transuranic (TRU) wastes to the Waste Isolation Pilot Plant (WIPP), the proposed geologic repository near Carlsbad, New Mexico. This document considers certification compliance with the WIPP waste acceptance criteria (WAC) and is consistent with the US Department of Energy's Long-Range Master Plan for Defense Transuranic Waste Management. This document characterizes Oak Ridge National Laboratory's (ORNL's) TRU waste by type and estimates the number of shipments required to dispose of it; describesmore » the methods, facilities, and systems required for its certification and shipment; presents work-off strategies and schedules for retrieval, certification, and transportation; discusses the resource needs and additions that will be required for the effort and forecasts costs for the long-term TRU waste management program; and lists public documentation required to support certification facilities and strategies. 22 refs., 6 figs., 10 tabs.« less

MODIS Information, Data, and Control System (MIDACS) system specifications and conceptual design

NASA Technical Reports Server (NTRS)

Han, D.; Salomonson, V.; Ormsby, J.; Ardanuy, P.; Mckay, A.; Hoyt, D.; Jaffin, S.; Vallette, B.; Sharts, B.; Folta, D.

1988-01-01

The MODIS Information, Data, and Control System (MIDACS) Specifications and Conceptual Design Document discusses system level requirements, the overall operating environment in which requirements must be met, and a breakdown of MIDACS into component subsystems, which include the Instrument Support Terminal, the Instrument Control Center, the Team Member Computing Facility, the Central Data Handling Facility, and the Data Archive and Distribution System. The specifications include sizing estimates for the processing and storage capacities of each data system element, as well as traffic analyses of data flows between the elements internally, and also externally across the data system interfaces. The specifications for the data system, as well as for the individual planning and scheduling, control and monitoring, data acquisition and processing, calibration and validation, and data archive and distribution components, do not yet fully specify the data system in the complete manner needed to achieve the scientific objectives of the MODIS instruments and science teams. The teams have not yet been formed; however, it was possible to develop the specifications and conceptual design based on the present concept of EosDIS, the Level-1 and Level-2 Functional Requirements Documents, the Operations Concept, and through interviews and meetings with key members of the scientific community.

Instrument constraints and interface specifications. Earth Observatory Satellite system definition study (EOS)

NASA Technical Reports Server (NTRS)

1974-01-01

The equipment specifications for the thematic mapper and high resolution pointable imager for use on the Earth Observatory Satellite (EOS) are presented. The interface requirements of the systems are defined. The interface requirements are extracted from the equipment specifications and are intended as a summary to be used by the system and spacecraft designer. The appropriate documentation from which the specifications of the equipment are established are identified.