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 127 records · Page 7

HSCT high lift system aerodynamic requirements

The viewgraphs and discussion of high lift system aerodynamic requirements are provided. Low speed aerodynamics has been identified as critical to the successful development of a High Speed Civil Transport (HSCT). The airplane must takeoff and land at a sufficient number of existing or projected airports to be economically viable. At the same time, community noise must be acceptable. Improvements in cruise drag, engine fuel consumption, and structural weight tend to decrease the wing size and thrust required of engines. Decreasing wing size increases the requirements for effective and efficient low speed characteristics. Current design concepts have already been compromised away from better cruise wings for low speed performance. Flap systems have been added to achieve better lift-to-drag ratios for climb and approach and for lower pitch attitudes for liftoff and touchdown. Research to achieve improvements in low speed aerodynamics needs to be focused on areas most likely to have the largest effect on the wing and engine sizing process. It would be desirable to provide enough lift to avoid sizing the airplane for field performance and to still meet the noise requirements. The airworthiness standards developed in 1971 will be the basis for performance requirements for an airplane that will not be critical to the airplane wing and engine size. The lift and drag levels that were required to meet the performance requirements of tentative airworthiness standards established in 1971 and that were important to community noise are identified. Research to improve the low speed aerodynamic characteristics of the HSCT needs to be focused in the areas of performance deficiency and where noise can be reduced. Otherwise, the wing planform, engine cycle, or other parameters for a superior cruising airplane would have to be changed.

Paulson, John A.↗

A Methodology for Writing High Quality Requirement Specifications and for Evaluating Existing Ones

Requirements development and management have always been critical in the implementation of software systems-engineers are unable to build what analysts can not define. It is generally accepted that the earlier in the life cycle potential risks are identified the easier it is to eliminate or manage the conditions that introduce that risk. Problems that are not found until testing are approximately 14 times more costly to fix than if the problem was found in the requirement phase. The requirements specification, as the first tangible representation of the capability to be produced, establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor it can give rise to risks in all areas of the project. Recently, automated tools have become available to support requirements management. The use of these tools not only provides support in the definition and tracing of requirements, but it also opens the door to effective use of metrics in characterizing and assessing the quality of the requirement specifications.

Rosenberg, Linda↗

A Methodology for Writing High Quality Requirements Specification and Evaluating Existing Ones

Requirements development and management have always been critical in the implementation of software systems; engineers are unable to build what analysts can't define. It is generally accepted that the earlier in the life cycle potential risks are identified the easier it is to eliminate or manage the conditions that introduce that risk. Problems that are not found until testing are approximately 14 times more costly to fix than if the problem was found in the requirement phase. The requirements specification, as the first tangible representation of the capability to be produced, establishes the basis for all of the project's engineering management and assurance functions. If the quality of the requirements specification is poor it can give rise to risks in all areas of the project. Recently, automated tools have become available to support requirements management. The use of these tools not only provides support in the definition and tracing of requirements, but it also opens the door to effective use of metrics in characterizing and assessing the quality of the requirement specifications.

Rosenberg, Linda↗

Requirements, Verification, and Compliance (RVC) Database Tool

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

Rainwater, Neil E., II↗

Energy Requirements of Hydrogen-utilizing Microbes: A Boundary Condition for Subsurface Life

Microbial ecosystems based on the energy supplied by water-rock chemistry carry particular significance in the context of geo- and astrobiology. With no direct dependence on solar energy, lithotrophic microbes could conceivably penetrate a planetary crust to a depth limited only by temperature or pressure constraints (several kilometers or more). The deep lithospheric habitat is thereby potentially much greater in volume than its surface counterpart, and in addition offers a stable refuge against inhospitable surface conditions related to climatic or atmospheric evolution (e.g., Mars) or even high-energy impacts (e.g., early in Earth's history). The possibilities for a deep microbial biosphere are, however, greatly constrained by life s need to obtain energy at a certain minimum rate (the maintenance energy requirement) and of a certain minimum magnitude (the energy quantum requirement). The mere existence of these requirements implies that a significant fraction of the chemical free energy available in the subsurface environment cannot be exploited by life. Similar limits may also apply to the usefulness of light energy at very low intensities or long wavelengths. Quantification of these minimum energy requirements in terrestrial microbial ecosystems will help to establish a criterion of energetic habitability that can significantly constrain the prospects for life in Earth's subsurface, or on other bodies in the solar system. Our early work has focused on quantifying the biological energy quantum requirement for methanogenic archaea, as representatives of a plausible subsurface metabolism, in anoxic sediments (where energy availability is among the most limiting factors in microbial population growth). In both field and laboratory experiments utilizing these sediments, methanogens retain a remarkably consistent free energy intake, in the face of fluctuating environmental conditions that affect energy availability. The energy yields apparently required by methanogens in these sediment systems for sustained metabolism are about half that previously thought necessary. Lowered energy requirements would imply that a correspondingly greater proportion of the planetary subsurface could represent viable habitat for microorganisms.

Hoehler, Tori M.↗

A Tool for Requirements-Based Programming

Absent a general method for mathematically sound, automated transformation of customer requirements into a formal model of the desired system, developers must resort to either manual application of formal methods or to system testing (either manual or automated). While formal methods have afforded numerous successes, they present serious issues, e.g., costs to gear up to apply them (time, expensive staff), and scalability and reproducibility when standards in the field are not settled. The testing path cannot be walked to the ultimate goal, because exhaustive testing is infeasible for all but trivial systems. So system verification remains problematic. System or requirements validation is similarly problematic. The alternatives available today depend on either having a formal model or pursuing enough testing to enable the customer to be certain that system behavior meets requirements. The testing alternative for non-trivial systems always have some system behaviors unconfirmed and therefore is not the answer. To ensure that a formal model is equivalent to the customer s requirements necessitates that the customer somehow fully understands the formal model, which is not realistic. The predominant view that provably correct system development depends on having a formal model of the system leads to a desire for a mathematically sound method to automate the transformation of customer requirements into a formal model. Such a method, an augmentation of requirements-based programming, will be briefly described in this paper, and a prototype tool to support it will be described. The method and tool enable both requirements validation and system verification for the class of systems whose behavior can be described as scenarios. An application of the tool to a prototype automated ground control system for NASA mission is presented.

Rash, James L.↗

Structural Requirements for the Space Propulsion Engine Systems

In January 2004, the National Aeronautics and Space Administration (NASA) was given a vision for Space Exploration by President Bush, setting our sight on a bold new path to go back to the Moon, then to Mars and beyond. As NASA gets ready to meet the vision set by President Bush, failures are not an option. Reliability of the propulsion engine systems will play an important role in establishing an overall safe and reliable operation of these new space systems. A new standard, NASA-STD-5012, Strength and Life Assessment for Space Propulsion System Engines, has been developed to provide structural requirements for assessment of the propulsion systems engine. This standard is a complement to the current NASA-wide standard NASA-STD-5001, Structural Design and Test Factors of Safety for Spaceflight Hardware, which excluded the requirement for the engine systems (rotatory structures) along with pressure vessels. As developed, this document builds on the heritage of the multiple industrial standards related to strength and life assessment of the structures. For assuring a safe and reliable operation of a product and/or mission, establishing a set of structural assessment requirements is a key ingredient. Hence, a concentrated effort was made to improve the requirements where there are known lessons learned during the design, test, and operation phases of the Space Shuttle Main Engine (SSME) and other engine development programs. Requirements delineated in this standard are also applicable for the reusable and/or human missions. It shall be noted that "reliability of a system cannot be tested and inspected but can only be achieved if it is first designed into a system." Hence, these strength and life assessment requirements for the space propulsion system engines shall be used along with other good engineering practices, requirements, and policies.

Aggarwal, Pravin K.↗

Automated Derivation of Complex System Constraints from User Requirements

International Space Station (ISS) payload developers submit their payload science requirements for the development of on-board execution timelines. The ISS systems required to execute the payload science operations must be represented as constraints for the execution timeline. Payload developers use a software application, User Requirements Collection (URC), to submit their requirements by selecting a simplified representation of ISS system constraints. To fully represent the complex ISS systems, the constraints require a level of detail that is beyond the insight of the payload developer. To provide the complex representation of the ISS system constraints, HOSC operations personnel, specifically the Payload Activity Requirements Coordinators (PARC), manually translate the payload developers simplified constraints into detailed ISS system constraints used for scheduling the payload activities in the Consolidated Planning System (CPS). This paper describes the implementation for a software application, User Requirements Integration (URI), developed to automate the manual ISS constraint translation process.

Muery, Kim↗

Determining Exercise Strength Requirements for Astronaut Critical Mission Tasks: Reaching Under G-Load

The critical mission tasks assessments effort seeks to determine the physical performance requirements that astronauts must meet in order to safely and successfully accomplish lunar exploration missions. These assessments will determine astronaut preflight strength, fitness, and flexibility requirements, and the extent to which exercise and other countermeasures must prevent the physical deconditioning associated with prolonged weightlessness. The purpose is to determine the flexibility and strength that crewmembers must possess in order to reach Crew Exploration Vehicle controls during maneuvers that result in sustained acceleration levels ranging from 3.7G to 7.8G. An industry standard multibody dynamics application was used to create human models representing a 5th percentile female, a 50th percentile male, and a 95th percentile male. The additional mass of a space suit sleeve was added to the reaching arm to account for the influence of the suit mass on the reaching effort. The human model was merged with computer models of a pilot seat and control panel for the Crew Exploration Vehicle. Three dimensional paths were created that guided the human models hand from a starting position alongside its thigh to three control targets: a joystick, a keyboard, and an overhead switch panel. The reaching motion to each target was repeated under four vehicle acceleration conditions: nominal ascent (3.7G), two ascent aborts (5.5G and 7.8G) and lunar reentry (4.6G). Elbow and shoulder joint angular excursions were analyzed to assess range of motion requirements. Mean and peak elbow and shoulder joint torques were determined and converted to equivalent resistive exercise loads to assess strength requirements. Angular excursions for the 50th and 95th percentile male models remained within joint range of motion limits. For the 5th percentile female, both the elbow and the shoulder exceeded range of motion limits during the overhead reach. Elbow joint torques ranged from 10 N-m (nominal ascent) to 60 N-m (ascent abort). Shoulder joint torques ranged from 65 N-m (nominal ascent) to 280 N-m (ascent abort). Maximal equivalent exercise loads reached 30 lb in tricep extension, 9 lb in bicep curl, 110 lb in unilateral pullover and unilateral bench press for nominal conditions (lunar reentry), and 188 lb in unilateral pullover and unilateral bench press. The location of the pilot seat was found to be inadequately located to allow a 5th percentile female to reach the switches on the overhead panel. Elbow strength requirements were found to be well within population norms. Shoulder strength was found to be a limiting factor. Reaching under nominal ascent and lunar reentry conditions was found to require near maximal shoulder strength. Reaching under ascent abort conditions requires shoulder strength well beyond population norms. Pilot seats must adjust to accomodate a 5th percentile female. Exercise countermeasures must maintain maximal pullover and bench press strength to allow pilots to reach and operate controls during lunar reentry. Reaching will not be possible during ascent abort conditions. Flight controls should be built into armrests or flight control must be accomplished by autonomous systems during acceleration exceeding 4.6G.

Schaffner, Grant↗

Step 1: Human System Integration Pilot-Technology Interface Requirements for Weather Management

This document involves definition of technology interface requirements for Hazardous Weather Avoidance. Technology concepts in use by the Access 5 Weather Management Work Package were considered. Beginning with the Human System Integration (HIS) high-level functional requirement for Hazardous Weather Avoidance, and Hazardous Weather Avoidance 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 hazardous weather, and (2) the control capability needed by the pilot to obtain hazardous weather information. Fundamentally, these requirements provide the candidate Hazardous Weather Avoidance technology concepts with the necessary human-related elements to make them compatible with human capabilities and limitations. The results of the analysis describe how Hazardous Weather Avoidance operations and functions should interface with the pilot to provide the necessary Weather Management functionality to the UA-pilot system. Requirements and guidelines for Hazardous Weather Avoidance are partitioned into four categories: (1) Planning En Route (2) Encountering Hazardous Weather En Route, (3) Planning to Destination, and (4) Diversion Planning Alternate Airport. Each requirement is stated and is supported with a rationale and associated reference(s).

Source record↗

Review of the Constellation Level II Safety, Reliability, and Quality Assurance (SR&QA) Requirements Documents during Participation in the Constellation Level II SR&QA Forum

At the request of the Exploration Systems Mission Directorate (ESMD) and the Constellation Program (CxP) Safety, Reliability; and Quality Assurance (SR&QA) Requirements Director, the NASA Engineering and Safety Center (NESC) participated in the Cx SR&QA Requirements forum. The Requirements Forum was held June 24-26; 2008, at GRC's Plum Brook Facility. The forums purpose was to gather all stakeholders into a focused meeting to help complete the process of refining the CxP to refine its Level II SR&QA requirements or defining project-specific requirements tailoring. Element prime contractors had raised specific questions about the wording and intent of many requirements in areas they felt were driving costs without adding commensurate value. NESC was asked to provide an independent and thorough review of requirements that contractors believed were driving Program costs, by active participation in the forum. This document contains information from the forum.

Cameron, Kenneth D.↗

Altair Lander Life Support: Requirement Analysis Cycles 1 and 2

Life support systems are a critical part of human exploration beyond low earth orbit. NASA s Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally-functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair s life support system.

Anderson, Molly↗

Altair Lander Life Support: Requirements Analysis Cycles 1 and 2

Life support systems are a critical part of human exploration beyond low earth orbit. NASA's Altair Lunar Lander has unique missions to perform and will need a unique life support system to complete them. Initial work demonstrated a feasible minimally -functional Lander design. This work was completed in Design Analysis Cycles (DAC) 1, 2, and 3 were reported in a previous paper'. On October 21, 2008, the Altair project completed the Mission Concept Review (MCR), moving the project into Phase A. In Phase A activities, the project is preparing for the System Requirements Review (SRR). Altair has conducted two Requirements Analysis Cycles (RACs) to begin this work. During this time, the life support team must examine the Altair mission concepts, Constellation Program level requirements, and interfaces with other vehicles and spacesuits to derive the right set of requirements for the new vehicle. The minimum functionality design meets some of these requirements already and can be easily adapted to meet others. But Altair must identify which will be more costly in mass, power, or other resources to meet. These especially costly requirements must be analyzed carefully to be sure they are truly necessary, and are the best way of explaining and meeting the true need. If they are necessary and clear, they become important mass threats to track at the vehicle level. If they are not clear or do not seem necessary to all stakeholders, Altair must work to redefine them or push back on the requirements writers. Additionally, the life support team is evaluating new technologies to see if they are more effective than the existing baseline design at performing necessary functions in Altair's life support system.

Anderson, Molly↗

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

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.

Zelkin, Natalie↗

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

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.

Bernstein, Karen S.↗

Flight Hardware Packaging Design for Stringent EMC Radiated Emission Requirements

This packaging design approach can help heritage hardware meet a flight project's stringent EMC radiated emissions requirement. The approach requires only minor modifications to a hardware's chassis and mainly concentrates on its connector interfaces. The solution is to raise the surface area where the connector is mounted by a few millimeters using a pedestal, and then wrapping with conductive tape from the cable backshell down to the surface-mounted connector. This design approach has been applied to JPL flight project subsystems. The EMC radiated emissions requirements for flight projects can vary from benign to mission critical. If the project's EMC requirements are stringent, the best approach to meet EMC requirements would be to design an EMC control program for the project early on and implement EMC design techniques starting with the circuit board layout. This is the ideal scenario for hardware that is built from scratch. Implementation of EMC radiated emissions mitigation techniques can mature as the design progresses, with minimal impact to the design cycle. The real challenge exists for hardware that is planned to be flown following a built-to-print approach, in which heritage hardware from a past project with a different set of requirements is expected to perform satisfactorily for a new project. With acceptance of heritage, the design would already be established (circuit board layout and components have already been pre-determined), and hence any radiated emissions mitigation techniques would only be applicable at the packaging level. The key is to take a heritage design with its known radiated emissions spectrum and repackage, or modify its chassis design so that it would have a better chance of meeting the new project s radiated emissions requirements.

Lortz, Charlene L.↗

Exploration of the Trade Space Between Unmanned Aircraft Systems Descent Maneuver Performance and Sense-and-Avoid System Performance Requirements

A need exists to safely integrate Unmanned Aircraft Systems (UAS) into the United States' National Airspace System. Replacing manned aircraft's see-and-avoid capability in the absence of an onboard pilot is one of the key challenges associated with safe integration. Sense-and-avoid (SAA) systems will have to achieve yet-to-be-determined required separation distances for a wide range of encounters. They will also need to account for the maneuver performance of the UAS they are paired with. The work described in this paper is aimed at developing an understanding of the trade space between UAS maneuver performance and SAA system performance requirements, focusing on a descent avoidance maneuver. An assessment of current manned and unmanned aircraft performance was used to establish potential UAS performance test matrix bounds. Then, near-term UAS integration work was used to narrow down the scope. A simulator was developed with sufficient fidelity to assess SAA system performance requirements. The simulator generates closest-point-of-approach (CPA) data from the wide range of UAS performance models maneuvering against a single intruder with various encounter geometries. Initial attempts to model the results made it clear that developing maneuver performance groups is required. Discussion of the performance groups developed and how to know in which group an aircraft belongs for a given flight condition and encounter is included. The groups are airplane, flight condition, and encounter specific, rather than airplane-only specific. Results and methodology for developing UAS maneuver performance requirements are presented for a descent avoidance maneuver. Results for the descent maneuver indicate that a minimum specific excess power magnitude can assure a minimum CPA for a given time-to-go prediction. However, smaller amounts of specific excess power may achieve or exceed the same CPA if the UAS has sufficient speed to trade for altitude. The results of this study will support UAS maneuver performance requirements development for integrating UAS in the NAS. The methods described are being used to help RTCA Special Committee 228 develop requirements.

Jack, Devin P.↗

Importance of Requirements Analysis & Traceability to Improve Software Quality and Reduce Cost and Risk

The goal of this paper is to emphasize the importance of developing complete and unambiguous requirements early in the project cycle (prior to Preliminary Design Phase). Having a complete set of requirements early in the project cycle allows sufficient time to generate a traceability matrix. Requirements traceability and analysis are the key elements in improving verification and validation process, and thus overall software quality. Traceability can be most beneficial when the system changes. If changes are made to high-level requirements it implies that low-level requirements need to be modified. Traceability ensures that requirements are appropriately and efficiently verified at various levels whereas analysis ensures that a rightly interpreted set of requirements is produced.

Kapoor, Manju M.↗