Search NASA⌕ Search

SEARCH · Search NASA

Results for “requirements”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2005

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

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

Source record↗
NASA NTRS2006

Functional Requirements Document for HALE UAS Operations in the NAS: Step 1. Version 3

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.

Source record↗
NASA NTRS2008

Defining Constellation Suit Helmet Field of View Requirements Employing a Mission Segment Based Reduction Process

Field of view has always been a design feature paramount to helmet design, and in particular space suit design, where the helmet must provide an adequate field of view for a large range of activities, environments, and body positions. For Project Constellation, a slightly different approach to helmet requirement maturation was utilized; one that was less a direct function of body position and suit pressure and more a function of the mission segment in which the field of view is required. Through taxonimization of various parameters that affect suited FOV, as well as consideration for possible nominal and contingency operations during that mission segment, a reduction process was able to condense the large number of possible outcomes to only six unique field of view angle requirements that still captured all necessary variables without sacrificing fidelity. The specific field of view angles were defined by considering mission segment activities, historical performance of other suits, comparison between similar requirements (pressure visor up versus down, etc.), estimated requirements from other teams for field of view (Orion, Altair, EVA), previous field of view tests, medical data for shirtsleeve field of view performance, and mapping of visual field data to generate 45degree off-axis field of view requirements. Full resolution of several specific field of view angle requirements warranted further work, which consisted of low and medium fidelity field of view testing in the rear entry ISuit and DO27 helmet prototype. This paper serves to document this reduction progress and followup testing employed to write the Constellation requirements for helmet field of view.

McFarland, Shane M.↗
NASA NTRS2010

What is the Final Verification of Engineering Requirements?

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.

Poole, Eric↗
NASA NTRS2006

Requirements and Waivers

Good requirements are the first step for good communications, and good communications are central to insure an understanding between the customer and contractor. Failure to generate good requirements is unfortunately commonplace and repeated. Waivers to requirements are discussed from a risk based point of view. The assumption that every requirement will eventually be waived is used to establish a critical review of a draft safety requirement. Validation methods of requirements are addressed. Value added that safety requirements contribute to the Project is estimated to further our critical review of draft requirements.

Goodin, James Ronald↗
NASA NTRS2014

VARED: Verification and Analysis of Requirements and Early Designs

Requirements are a part of every project life cycle; everything going forward in a project depends on them. Good requirements are hard to write, there are few useful tools to test, verify, or check them, and it is difficult to properly marry them to the subsequent design, especially if the requirements are written in natural language. In fact, the inconsistencies and errors in the requirements along with the difficulty in finding these errors contribute greatly to the cost of the testing and verification stage of flight software projects [1]. Large projects tend to have several thousand requirements written at various levels by different groups of people. The design process is distributed and a lack of widely accepted standards for requirements often results in a product that varies widely in style and quality. A simple way to improve this would be to standardize the design process using a set of tools and widely accepted requirements design constraints. The difficulty with this approach is finding the appropriate constraints and tools. Common complaints against the tools available include ease of use, functionality, and available features. Also, although preferable, it is rare that these tools are capable of testing the quality of the requirements.

Badger, Julia↗
NASA NTRS2014

Advanced Extravehicular Activity Pressure Garment Requirements Development

The NASA Johnson Space Center advanced pressure garment technology development team is addressing requirements development for exploration missions. Lessons learned from the Z‐2 high fidelity prototype development have reiterated that clear low‐level requirements and verification methods reduce risk to the government, improve efficiency in pressure garment design efforts, and enable the government to be a smart buyer. The expectation is to provide requirements at the specification level that are validated so that their impact on pressure garment design is understood. Additionally, the team will provide defined verification protocols for the requirements. However, in reviewing exploration space suit high level requirements there are several gaps in the team's ability to define and verify related lower level requirements. This paper addresses the efforts in requirement areas such as mobility/fit/comfort and environmental protection (dust, radiation, plasma, secondary impacts) to determine the by what method the requirements can be defined and use of those methods for verification. Gaps exist at various stages. In some cases component level work is underway, but no system level effort has begun, in other cases no effort has been initiated to close the gap. Status of ongoing efforts and potential approaches to open gaps are discussed.

Ross, Amy↗
NASA NTRS2015

Advanced Extra-Vehicular Activity Pressure Garment Requirements Development

The NASA Johnson Space Center advanced pressure garment technology development team is addressing requirements development for exploration missions. Lessons learned from the Z-2 high fidelity prototype development have reiterated that clear low-level requirements and verification methods reduce risk to the government, improve efficiency in pressure garment design efforts, and enable the government to be a smart buyer. The expectation is to provide requirements at the specification level that are validated so that their impact on pressure garment design is understood. Additionally, the team will provide defined verification protocols for the requirements. However, in reviewing exploration space suit high level requirements there are several gaps in the team's ability to define and verify related lower level requirements. This paper addresses the efforts in requirement areas such as mobility/fit/comfort and environmental protection (dust, radiation, plasma, secondary impacts) to determine the method by which the requirements can be defined and use of those methods for verification. Gaps exist at various stages. In some cases component level work is underway, but no system level effort has begun; in other cases no effort has been initiated to close the gap. Status of on-going efforts and potential approaches to open gaps are discussed.

Ross, Amy↗
NASA NTRS2019

Gateway System Requirements

The Gateway Program (GW) System Requirements Document (SRD) is approved for the public domain to support NASA's Lunar Gateway Program. The main intent of these documents is to define top level functional and performance requirements for the systems that facilitate cooperative deep space exploration endeavors and execute lunar missions. The SRD defines NASA requirements for the procurement and development of the GW mission. The Gateway Program is a collaboration of US government, international partners and commercial providers. The Gateway SRD are expected to be used by all parties in development of the Gateway Program elements. For effective development and integration of the Gateway vehicle, all involved entities must use, and have awareness of, these high level program requirements to flow down to their respective developmental responsibilities so all Gateway elements will be operable as an entity. The Gateway SRD represents the requirements that are necessary for the Gateway mission. NASA has determined there is benefit to U.S. and foreign spacecraft developers to approve this information for the public domain because all the parties/participants need a common understanding of the requirements and the parameters under which they operate (size, shape, form fit and function). This will allow systems built by various nations and commercial entities to attach and function together properly and safely in the hostile environment of space.The Gateway SRD provides information regarding the current requirements for Gateway elements. Specifically, the Gateway SRD provide an overview of expected features and capabilities and requirements for safe integration of elements within the Gateway program. The SRD contains top-level functional and performance descriptions of the Gateway and definition of the interfaces limited to the scope necessary for integration purposes between Gateway elements. The documents do NOT contain detailed design information or any specifics of hardware or software implementation. The data approved for release does not include: manufacturing drawings, detailed interface control and design data, software code, detailed CAD models, structural or thermal models of the system, avionics or avionics box, board, or cable manufacturing information.

Adamek, Christopher↗
NASA NTRS2021

A Fully Automated Approach to Requirement Extraction from Design Documents

Design documents are intended to outline the goalsof a system or project, which are utilized in the creation ofspecific software requirements. At the NASA Jet PropulsionLaboratory, California Institute of Technology, Functional DesignDescription (FDD) documents describe the scope of theproject and reflect the design and implementation of the system.The specifications in the document are not explicitly writtenas requirements, though these guidelines must be reflected inthe official software requirements. In this work we present afully automatic approach to extracting software requirementsfrom design documents as well as comparing the extractedrequirements to those that exist in the official software requirementdatabase. We do this through (1) sentence extractionfrom the design document, (2) the incorporation of coreferenttext, and (3) aligning the extracted text to the official softwarerequirements. Via natural language processing and informationretrieval techniques, our system results in an automated processthat ensures that the specifications in the design document resultin official software requirements. We find that extraction ofimperatives results in a recall rate of 0.73 and the TF-IDF cosinesimilarity metric is shown to be a useful and successful way tocompare requirements.Though there has been recent work investigating the usefulnessof natural language processing techniques in requirement engineering,this has not been made use of in the aerospace industry.Aerospace requirement engineering is a field particularly ripefor this type of innovation because these techniques can bothautomate some of needlessly manual work and contribute toaerospace safety practices by identifying issues that a humanmay miss. We present the first fully automated approach thatextracts requirements from a design document and comparesthem to a database, and use these findings as encouragementfor future work that makes use of natural language processingtechniques in aerospace requirement engineering.

Briggs, Paul↗
NASA NTRS2023

Towards Streamlining Auditing for Compliance With Requirements in Open-Source Software at NASA

Context: NASA requires all software to meet several requirements (NPR 7150.2) depending on software criticality. The instantiation of these requirements may vary per project; however, once decided upon, projects must undergo audits to evaluate compliance with these requirements. Aim: We propose that audit effort can be reduced when requirements are realized by leveraging commonly used open-source infrastructure for version control, issue tracking and continuous integration, and the generated records are analyzed using a repository mining software tool to quantify process compliance. Method: We perform a case study in the NASA-funded Copilot project, utilizing Kaiaulu, a repository mining software tool. We define four software compliance metrics based on the Copilot’s requirements, and analyze their impact on source code quality. Results: Our work demonstrates how it is possible to leverage existing open source tools and platforms to facilitate software certification and qualification, and to streamline the auditing process required even when stringent requirements must be enforced. Conclusion: Together, both project and tool can be utilized to visualize project compliance, and metrics can be defined to more easily identify process irregularities to minimize auditing efforts. Project Repository: github.com/Copilot-Language/copilot Tool Repository: github.com/sailuh/kaiaulu

code-quality↗
NASA NTRS2024

Loads and Structural Dynamics Requirements for Spaceflight Hardware

The NASA Exploration Systems Development Mission Directorate requires Crewed Space Systems (CSS) to meet the intent of a set of Engineering Technical Authority (TA) documents called out in HEOMD-003, Crewed Deep Space Systems Human Rating Certification Requirements and Standards for NASA Missions. For the Loads and Dynamics technical discipline, the document invoked by the HEOMD-003 is JSC 65829, Loads and Structural Dynamics Requirements for Spaceflight Hardware. JSC 65829 was originally developed for the NASA Commercial Crew Program as an implementation of NASA STD-5002, Load Analyses of Spacecraft and Payloads, for that Program. Since that time, tailored alternatives to JSC 65829 have been produced for the Gateway, Human Landing System, and Extravehicular Activity and Human Surface Mobility Programs. Experience with those Programs has shown that the reduced set of less-prescriptive requirements in those tailored documents offers an advantage over the set of requirements in JSC 65829 Rev A and is a better fit for the paradigm of NASA procurement of commercially developed systems for crewed spaceflight. Revision B of JSC 65829 has been constructed to align with those tailored documents. The reduction in the number and specificity of requirements is balanced by a new requirement for hardware developers to create and provide a Loads Control Plan which describes how the approaches used to generate design-to loads and dynamic environments and substantiate dynamic model validity satisfy the requirements herein. The Plan will establish an agreement between the hardware developer and the TA for the loads and dynamics discipline and offer an opportunity for reengagement if the Plan changes during development.

Kenneth Schultz↗
NASA NTRSDate not supplied

Capturing and Analyzing Requirements with FRET

FRET is an open source tool, developed at NASA Ames, for writing, understanding, formalizing, and analyzing requirements. In practice, requirements are typically written in natural language, which is ambiguous and consequently not amenable to formal analysis. Since formal, mathematical notations are unintuitive, requirements in FRET are entered in a restricted, natural language, called FRETish with precise unambiguous meaning. FRET helps users write FRETish requirements both by providing grammar information and examples during editing, but also through English and diagrammatic explanations to clarify subtle semantic issues. For each requirement, FRET automatically produces formalizations and supports interactive simulation of produced formalizations to ensure that they capture user intentions. Through its analysis portal, FRET connects to analysis tools by exporting verification code. Currently FRET connects to (1) the CoCoSim automated analysis tool for the verification of Simulink and Stateflow models, and (2) the Copilot runtime monitoring tool for the analysis of C programs. FRET also supports the consistency/realizability analysis of requirements for identifying conflicting requirements. In this tutorial, we introduce FRET and learn to speak and analyze FRETish through several examples.

FRET↗
NASA NTRS1975

Future payload technology requirements

This paper presents the background and results of a study of future payload technology requirements. The overall objectives of the study were the identification and description of technology items that must be advanced beyond the current state of the art in order for early shuttle-era NASA payloads to meet their currently defined objectives. The purpose was to provide data that will effectively assist the NASA payload technology planning effort. A total of 91 payload technology requirements have been defined in detail with requirements occurring in all disciplines. Included in the description of these technology requirements are the current state-of-the-art, the level of technology advancement required, and the date when the technology will be needed. The highlights of the study are: (1) NASA must provide the major impetus to attain these technology requirements, (2) most of these technologies must be available in 3-4 years, and (3) about half of the technology advancements require a test in space.

Ikerd, H. M.↗
NASA NTRS1981

Generic waste management requirements for a controlled ecological life support system /CELSS/

Regenerative life support systems for future space missions will require closure of the waste-food loop. Each mission application will generate specific requirements for the waste management system. However, there are generic input and output requirements that can be identified when a probable scenario is chosen. This paper discusses the generic requirements when higher plants are chosen as the primary food source. Attention is focused on the quality and quantity of nutrients necessary for culturing higher plants. The types of wastes to be processed are also discussed. In addition, requirements generated by growing plants on three different substrates are presented. This work suggests that the mineral composition of waste materials may require minimal adjustment to satisfy the plant requirements.

Hoshizaki, T.↗
NASA NTRS1991

Science requirements for a global change technology architecture trade study

Science requirements for a global change technology initiative (GCTI) Architecture Trade Study were established by reviewing and synthesizing results from recent studies. A scientific rationale was adopted and used to identify a comprehensive set of measureables and their priorities. Spatial and temporal requirements for a number of measurement parameters were evaluated based on results from several working group studies. Science requirements were defined using these study results in conjunction with the guidelines for investigating global changes over a time scale of decades to centuries. Requirements are given separately for global studies and regional process studies. For global studies, temporal requirements are for sampling every 1 to 12 hours for atmospheric and radiation parameters and 1 day or more for most earth surface measurements. Therefore, the atmospheric measureables provide the most critical drivers for temporal sampling. Spatial sampling requirements vary from 1 km for land and ocean surface characteristics to 50 km for some atmospheric parameters. Thus, the land and ocean surface parameters have the more significant spatial variations and provide the most challenging spatial sampling requirements.

Suttles, John T.↗
NASA NTRS1991

Science requirements for a global change technology initiative architecture trade study

Science requirements for a Global Change Technology Initiative (GCTI) Architecture Trade Study were established by reviewing and synthesizing results from recent studies. A scientific rationale was adopted and used to identify a comprehensive set of measurables and their priorities. Spatial and temporal requirements for a number of measurement parameters were evaluated based on results from several working group studies. Science requirements were defined using these study results in conjunction with guidelines for investigating global changes over a time scale of decades to centuries. Requirements are given separately for global studies and regional process studies. For global studies, temporal requirements are for sampling every 1 to 12 hours for atmospheric and radiation parameters and 1 day or more for most Earth surface measurements. Therefore, the atmospheric measurables provide the most critical drivers for temporal sampling. Spatial sampling requirements vary from 1 km for land and ocean surface characteristics to 50 km for some atmospheric parameters. Thus, the land and ocean surface parameters have the more significant spatial variations and provide the most challenging spatial sampling requirements.

Suttles, John T.↗
NASA NTRS1988

Knowledge-based requirements analysis for automating software development

We present a new software development paradigm that automates the derivation of implementations from requirements. In this paradigm, informally-stated requirements are expressed in a domain-specific requirements specification language. This language is machine-understable and requirements expressed in it are captured in a knowledge base. Once the requirements are captured, more detailed specifications and eventually implementations are derived by the system using transformational synthesis. A key characteristic of the process is that the required human intervention is in the form of providing problem- and domain-specific engineering knowledge, not in writing detailed implementations. We describe a prototype system that applies the paradigm in the realm of communication engineering: the prototype automatically generates implementations of buffers following analysis of the requirements on each buffer.

Markosian, Lawrence Z.↗