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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS1985

Space Station data system analysis/architecture study. Task 1: Functional requirements definition, DR-5

The initial task in the Space Station Data System (SSDS) Analysis/Architecture Study is the definition of the functional and key performance requirements for the SSDS. The SSDS is the set of hardware and software, both on the ground and in space, that provides the basic data management services for Space Station customers and systems. The primary purpose of the requirements development activity was to provide a coordinated, documented requirements set as a basis for the system definition of the SSDS and for other subsequent study activities. These requirements should also prove useful to other Space Station activities in that they provide an indication of the scope of the information services and systems that will be needed in the Space Station program. The major results of the requirements development task are as follows: (1) identification of a conceptual topology and architecture for the end-to-end Space Station Information Systems (SSIS); (2) development of a complete set of functional requirements and design drivers for the SSIS; (3) development of functional requirements and key performance requirements for the Space Station Data System (SSDS); and (4) definition of an operating concept for the SSIS. The operating concept was developed both from a Space Station payload customer and operator perspective in order to allow a requirements practicality assessment.

Source record↗
NASA NTRS1992

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

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.

Stephens, J. Briscoe↗
NASA NTRS1987

Maintainability Program Requirements for Space Systems

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.

Source record↗
NASA NTRS1995

Development and analysis of SCR requirements tables for system scenarios

We describe the use of scenarios to develop and refine requirement tables for parts of the Earth Observing System Data and Information System (EOSDIS). The National Aeronautics and Space Administration (NASA) is developing EOSDIS as part of its Mission-To-Planet-Earth (MTPE) project to accept instrument/platform observation requests from end-user scientists, schedule and perform requested observations of the Earth from space, collect and process the observed data, and distribute data to scientists and archives. Current requirements for the system are managed with tools that allow developers to trace the relationships between requirements and other development artifacts, including other requirements. In addition, the user community (e.g., earth and atmospheric scientists), in conjunction with NASA, has generated scenarios describing the actions of EOSDIS subsystems in response to user requests and other system activities. As part of a research effort in verification and validation techniques, this paper describes our efforts to develop requirements tables from these scenarios for the EOSDIS Core System (ECS). The tables specify event-driven mode transitions based on techniques developed by the Naval Research Lab's (NRL) Software Cost Reduction (SCR) project. The SCR approach has proven effective in specifying requirements for large systems in an unambiguous, terse format that enhance identification of incomplete and inconsistent requirements. We describe development of SCR tables from user scenarios and identify the strengths and weaknesses of our approach in contrast to the requirements tracing approach. We also evaluate the capabilities of both approach to respond to the volatility of requirements in large, complex systems.

Callahan, John R.↗
NASA NTRS1995

Planetary and Deep Space Requirements for Photovoltaic Solar Arrays

In the past 25 years, the majority of interplanetary spacecraft have been powered by nuclear sources. However, as the emphasis on smaller, low cost missions gains momentum, more deep space missions now being planned have baselined photovoltaic solar arrays due to the low power requirements (usually significantly less than 100 W) needed for engineering and science payloads. This will present challenges to the solar array builders, inasmuch as planetary requirements usually differ from earth orbital requirements. In addition, these requirements often differ greatly, depending on the specific mission; for example, inner planets vs. outer planets, orbiters vs. flybys, spacecraft vs. landers, and so on. Also, the likelihood of electric propulsion missions will influence the requirements placed on solar array developers. This paper will discuss representative requirements for a range of planetary and deep space science missions now in the planning stages. We have divided the requirements into three categories: Inner planets and the sun; outer planets (greater than 3 AU); and Mars, cometary, and asteroid landers and probes. Requirements for Mercury and Ganymede landers will be covered in the Inner and Outer Planets sections with their respective orbiters. We will also discuss special requirements associated with solar electric propulsion (SEP). New technology developments will be needed to meet the demanding environments presented by these future applications as many of the technologies envisioned have not yet been demonstrated. In addition, new technologies that will be needed reside not only in the photovoltaic solar array, but also in other spacecraft systems that are key to operating the spacecraft reliably with the photovoltaics.

Bankston, C. P.↗
NASA NTRS2000

Science Requirements Document for OMI-EOS

A Dutch-Finnish scientific and industrial consortium is supplying the Ozone Monitoring Instrument (OMI) for Earth Observing System-Aura (EOS-Aura). EOS-Aura is the next NASA mission to study the Earth's atmosphere extensively, and successor to the highly successful UARS (Upper Atmospheric Research Satellite) mission. The 'Science Requirements Document for OMI-EOS' presents an overview of the Aura and OMI mission objectives. It describes how OMI fits into the Aura mission and it reviews the synergy with the other instruments onboard Aura to fulfill the mission. This evolves in the Scientific Requirements for OMI (Chapter 3), stating which trace gases have to be measured with what necessary accuracy, in order for OMI to meet Aura's objectives. The most important data product of OMI, the ozone vertical column, densities shall have a better accuracy and an improved global coverage than the predecessor instruments TOMS (Total Ozone Monitoring Spectrometer) and GOME (Global Ozone Monitoring Experiment), which is a.o. achieved by a better signal to noise ratio, improved calibration and a wide field-of-view. Moreover, in order to meet its role on Aura, OMI shall measure trace gases, such as NO2, OClO, BrO, HCHO and SO2, aerosols, cloud top height and cloud coverage. Improved accuracy, better coverage, and finer ground grid than has been done in the past are goals for OMI. After the scientific requirements are defined, three sets of subordinate requirements are derived. These are: the algorithm requirements, i.e. what do the algorithms need in order to meet the scientific requirements; the instrument and calibration requirements, i.e. what has to be measured and how accurately in order to provide the quality of data necessary for deriving the data products; and the validation requirements, i.e. a strategy of how the OMI program will assure that its data products are valid in the atmosphere, at least to the required accuracy.

Levelt, P. F.↗
NASA NTRS2002

Remote Sensing System Requirements Development: A Simulation-Based Approach

Earth science research and application requirements for multispectral data have often been driven by currently available remote sensing technology. Few parametric studies exist that specify data required for certain applications. Consequently, data requirements are often defined based on the best data available or on what has worked successfully in the past. Since properites such as spatial resolution, swath width, spectral bands, signal-to-noise ratio (SNR), data quantization, and band-to-band registration drive sensor platform and spaceraft system architecture and cost, analysis of these criteria is important to objectively optimize system design. Remote sensing data requirements are also linked to calibration and characterization methods. Parameters such as spatial resolution, radiometric accuracy, and geopositional accuracy affect the complexity and cost of calibration methods. However, there are few studies that quantify the true accuracies required for specific problems. As calibration methods and standards are proposed, it is important that they be tied to well-known data requirements. The Application Research Toolbox (ART) developed at Stennis Space Center provides a simulation-based method for multispectral data requirements development. The ART produces simulated data sets from hyperspectral data through band synthesis. Parameters such as spectral band shape and width, SNR, data quantization, spatial resolution, and band-to-band registration can be varied to create many different simulated data products. Simulated data utility can then be assessed for different applications so that requirements can be better understood. This paper describes the ART and its applicability for rigorously deriving remote sensing data requirements.

Zanoni, Vicki↗
NASA NTRS2009

Universal Sensor and Actuator Requirements

The previous chapters have focused on the requirements for sensors and actuators for "More Intelligent Gas Turbine Engines" from the perspective of performance and operating environment. Even if a technology is available, which meets these performance requirements, there are still various hurdles to be overcome for the technology to transition into a real engine. Such requirements relate to TRL (Technology Readiness Level), durability, reliability, volume, weight, cost, etc. This chapter provides an overview of such universal requirements which any sensor or actuator technology will have to meet before it can be implemented on a product. The objective here is to help educate the researchers or technology developers on the extensive process that the technology has to go through beyond just meeting performance requirements. The hope is that such knowledge will help the technology developers as well as decision makers to prevent wasteful investment in developing solutions to performance requirements, which have no potential to meet the "universal" requirements. These "universal" requirements can be divided into 2 broad areas: 1) Technology value proposition; and 2) Technology maturation. These requirements are briefly discussed in the following.

Taylor Rosenfeld↗
NASA NTRS2011

Requirement Assurance: A Verification Process

Requirement Assurance is an act of requirement verification which assures the stakeholder or customer that a product requirement has produced its "as realized product" and has been verified with conclusive evidence. Product requirement verification answers the question, "did the product meet the stated specification, performance, or design documentation?". In order to ensure the system was built correctly, the practicing system engineer must verify each product requirement using verification methods of inspection, analysis, demonstration, or test. The products of these methods are the "verification artifacts" or "closure artifacts" which are the objective evidence needed to prove the product requirements meet the verification success criteria. Institutional direction is given to the System Engineer in NPR 7123.1A NASA Systems Engineering Processes and Requirements with regards to the requirement verification process. In response, the verification methodology offered in this report meets both the institutional process and requirement verification best practices.

Alexander, Michael G.↗
NASA NTRS2012

Next Generation Microbiology Requirements

As humans continue to explore deep into space, microorganisms will travel with them. The primary means to mitigate the risk of infectious disease are a combination of prudent spacecraft design and rigorous operational controls. The effectiveness of these methods are evaluated by microbiological monitoring of spacecraft, food, water, and the crew that is performed preflight, in-flight, and post-flight. Current NASA requirements associated with microbiological monitoring are based on culture-based methodology where microorganisms are grown on a semi-solid growth medium and enumerated. Subsequent identification of the organisms requires specialized labor and large equipment, which historically has been performed on Earth. Requirements that rely strictly on culture-based units limit the use of non-culture based monitoring technology. Specifically, the culture-based "measurement criteria" are Colony Forming Units (CFU, representing the growth of one microorganism at a single location on the agar medium) per a given volume, area, or sample size. As the CFU unit by definition is culture-based, these requirements limit alternative technologies for spaceflight applications. As spaceflight missions such as those to Mars extend further into space, culture-based technology will become difficult to implement due to the (a) limited shelf life of the culture media, (b) mass/volume necessary to carry these consumables, and (c) problems associated with the production of biohazardous material in the habitable volume of the spacecraft. In addition, an extensive amount of new knowledge has been obtained during the Space Shuttle, NASA-Mir, and International Space Station Programs, which gave direction for new or modified microbial control requirements for vehicle design and mission operations. The goal of this task is to develop and recommend a new set of requirements for vehicle design and mission operations, including microbiological monitoring, based upon "lessons learned" and new technology. During 2011, this study focused on evaluating potable water requirements by assembling a forum of internal and external experts from NASA, other federal agencies, and academia. Key findings from this forum included: (1) Preventive design and operational strategies should be stringent and the primary focus of NASA's mitigation efforts, as they are cost effective and can be attained with conventional technology. (2) Microbial monitoring hardware should be simple and must be able to measure the viability of microorganisms in a sample. Multiple monitoring technologies can be utilized as long as at the microorganisms being identified can also be confirmed as viable. (3) Evidence showing alterations in the crew immune function and microbial virulence complicates risk assessments and creates the need for very conservative requirements. (4) One key source of infectious agents will always be the crew, and appropriate preventative measures should be taken preflight. (5) Water systems should be thoroughly disinfected (sterilized if possible) preflight and retain a residual biocide throughout the mission. Future forums will cover requirements for other types of samples, specifically spaceflight food and environmental samples, such as vehicle air and vehicle and cargo surfaces. An interim report on the potable water forum has been delivered to the Human Research Program with a final report on the recommendations for all sample types being delivered in September 2013.

Ott, C. M.↗
NASA NTRS2015

Closed Loop Requirements and Analysis Management

Effective systems engineering involves the use of analysis in the derivation of requirements and verification of designs against those requirements. The initial development of requirements often depends on analysis for the technical definition of specific aspects of a product. Following the allocation of system-level requirements to a product's components, the closure of those requirements often involves analytical approaches to verify that the requirement criteria have been satisfied. Meanwhile, changes that occur in between these two processes need to be managed in order to achieve a closed-loop requirement derivation/verification process. Herein are presented concepts for employing emerging Team center capabilities to jointly manage requirements and analysis data such that analytical techniques are utilized to effectively derive and allocate requirements, analyses are consulted and updated during the change evaluation processes, and analyses are leveraged during the design verification process. Recommendations on concept validation case studies are also discussed.

Lamoreaux, Michael↗
NASA NTRS2016

Integrating MBSE into Ongoing Projects: Requirements Validation and Test Planning for the ISS SAFER

The International Space Station (ISS) Simplified Aid for Extra Vehicular Activity (EVA) Rescue (SAFER) is the spacewalking astronaut's final safety measure against separating from the ISS and being unable to return safely. Since the late 1990s, the SAFER has been a standard element of the spacewalking astronaut's equipment. The ISS SAFER project was chartered to develop a new block of SAFER units using a highly similar design to the legacy SAFER (known as the USA SAFER). An on-orbit test module was also included in the project to enable periodic maintenance/propulsion system checkout on the ISS SAFER. On the ISS SAFER project, model-based systems engineering (MBSE) was not the initial systems engineering (SE) approach, given the volume of heritage systems engineering and integration (SE&I) products. The initial emphasis was ensuring traceability to ISS program standards as well as to legacy USA SAFER requirements. The requirements management capabilities of the Cradle systems engineering tool were to be utilized to that end. During development, however, MBSE approaches were applied selectively to address specific challenges in requirements validation and test and verification (T&V) planning, which provided measurable efficiencies to the project. From an MBSE perspective, ISS SAFER development presented a challenge and an opportunity. Addressing the challenge first, the project was tasked to use the original USA SAFER operational and design requirements baseline, with a number of additional ISS program requirements to address evolving certification expectations for systems operating on the ISS. Additionally, a need to redesign the ISS SAFER avionics architecture resulted in a set of changes to the design requirements baseline. Finally, the project added an entirely new functionality for on-orbit maintenance. After initial requirements integration, the system requirements count was approaching 1000, which represented a growth of 4x over the original USA SAFER system. This presented the challenge - How to confirm that this new set of requirements set would result in the creation of the desired capability.

Anderson, Herbert A.↗
NASA NTRSDate not supplied

CLINICAL DECISION SUPPORT: PATH TO FUNCTIONAL REQUIREMENTS

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

clinical decision support↗
NASA NTRS1980

Technology requirements and readiness for very large aircraft

The technology requirements for designing, manufacturing and operating any vehicle depend largely on the configuration of that vehicle. Under the general heading of Very Large Aircraft (VLA), configurations are many and varied, so, therefore, are the technology requirements. The present work is limited to technology requirements of particular interest to VLA. While many are of common interest, a few technology requirements critical to specific VLA types are also covered. Addressed in turn are common VLA concerns and how they influence configurations and technology; the methodology followed in selecting requirements and assessing readiness; the resultant technology requirements and readiness; and some overall observations regarding technology areas judged to be particularly critical. Over 50 technology requirements are identified as unique or particularly critical to VLA. However, none of the requirements is considered to have an excellent state of technology readiness.

Conner, D. W.↗
NASA NTRS2003

Requirements: The More the Better?

Nothing ever, ever, becomes a requirement until two things happen: (1) there is a solid understanding and acceptance of the requirement's cost and schedule implications; and (2) knowledgeable technical people are so confident that the program can meet the requirement within the cost and schedule that they are willing to bet their jobs on it. Yikes!! Does this mean that we never undertake high-risk projects? No. what it does mean is that when you undertake high-risk activities, you agree on an expectation or requirement that includes failure, or falling short, as a real possibility, and your cost and schedule reflect the risk. The other thing that it means is that you may have to start a project with some requirements open until after the work progresses to a point where the requirement meets the two criteria above. The process is also flawed because there are usually too many requirements. Something about the engineering or designer mentality seems to demand hosts of requirements as an input to the technical process.

Little, Terry↗
NASA NTRS2002

Remote Sensing Requirements Development: A Simulation-Based Approach

Earth science research and application requirements for multispectral data have often been driven by currently available remote sensing technology. Few parametric studies exist that specify data required for certain applications. Consequently, data requirements are often defined based on the best data available or on what has worked successfully in the past. Since properties such as spatial resolution, swath width, spectral bands, signal-to-noise ratio (SNR), data quantization and band-to-band registration drive sensor platform and spacecraft system architecture and cost, analysis of these criteria is important to optimize system design objectively. Remote sensing data requirements are also linked to calibration and characterization methods. Parameters such as spatial resolution, radiometric accuracy and geopositional accuracy affect the complexity and cost of calibration methods. However, few studies have quantified the true accuracies required for specific problems. As calibration methods and standards are proposed, it is important that they be tied to well-known data requirements. The Application Research Toolbox (ART) developed at the John C. Stennis Space Center provides a simulation-based method for multispectral data requirements development. The ART produces simulated datasets from hyperspectral data through band synthesis. Parameters such as spectral band shape and width, SNR, data quantization, spatial resolution and band-to-band registration can be varied to create many different simulated data products. Simulated data utility can then be assessed for different applications so that requirements can be better understood.

Zanoni, Vicki↗
NASA NTRS2004

Robust Requirements Tracing via Internet Search Technology: Improving an IV and V Technique

There are three major objectives to this phase of the work. (1) Improvement of Information Retrieval (IR) methods for Independent Verification and Validation (IV&V) requirements tracing. Information Retrieval methods are typically developed for very large (order of millions - tens of millions and more documents) document collections and therefore, most successfully used methods somewhat sacrifice precision and recall in order to achieve efficiency. At the same time typical IR systems treat all user queries as independent of each other and assume that relevance of documents to queries is subjective for each user. The IV&V requirements tracing problem has a much smaller data set to operate on, even for large software development projects; the set of queries is predetermined by the high-level specification document and individual requirements considered as query input to IR methods are not necessarily independent from each other. Namely, knowledge about the links for one requirement may be helpful in determining the links of another requirement. Finally, while the final decision on the exact form of the traceability matrix still belongs to the IV&V analyst, his/her decisions are much less arbitrary than those of an Internet search engine user. All this suggests that the information available to us in the framework of the IV&V tracing problem can be successfully leveraged to enhance standard IR techniques, which in turn would lead to increased recall and precision. We developed several new methods during Phase II; (2) IV&V requirements tracing IR toolkit. Based on the methods developed in Phase I and their improvements developed in Phase II, we built a toolkit of IR methods for IV&V requirements tracing. The toolkit has been integrated, at the data level, with SAIC's SuperTracePlus (STP) tool; (3) Toolkit testing. We tested the methods included in the IV&V requirements tracing IR toolkit on a number of projects.

Hayes, Jane↗
NASA NTRS2007

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

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

Source record↗