Search NASA⌕ Search

SEARCH · Search NASA

Results for “requirement management”

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 NTRS2023

NASA Standing Review Board Handbook

This handbook provides guidance based on best practices for the planning, preparation, review, reporting, and closeout of Standing Review Board (SRB) activities. Revision C updates the Revision B version of the SRB Handbook published in 2016 to incorporate updates to NASA Procedural Requirements (NPR) 7120.5F, NASA Space Flight Program and Project Management Requirements. These updates include: - Changing the Dissenting Opinion process to the Formal Dissent process, which retains the current process augmented with an expedited escalation path. - Updates to requirements for establishing an Agency Baseline Commitment (ABC) and for performing Joint Cost and Schedule Confidence Level (JCL) analyses for tightly coupled programs. - Additional requirements for performing a JCL analysis for single-project programs and projects over $1B Life-Cycle Cost (LCC). - Use of initial capability cost estimates instead of LCC estimates in specific, identified instances for single-project programs and projects that plan continuing operations and production, including integration of capability upgrades, with an unspecified Phase E end point. These single-project programs and projects define an initial capability during Phase A and develop an initial capability cost that establishes the ABC at Key Decision Point (KDP) C. Initial capability is the first operational mission flight (or as defined in the KDP B Review Plan) and is documented in the KDP B Decision Memorandum. Initial capability cost includes operations cost for the initial capability. The Phase E cost estimate for continuing operations and production is established separately as part of the Operational Readiness Review (ORR) and KDP E for the 5 years after initial capability and subsequently updated and documented annually for the next 5-year period. Upgrades during Phase E that meet the Agency criteria for a major project for external reporting are treated as projects for the purposes of establishing their own development ABC outside the Phase E cost estimate. The Phase E cost estimate is updated to include production and operations costs associated with these upgrades. Development, production, and operations costs of other (i.e., non-major) upgrades are included in the Phase E cost estimate. (See NPR 7120.5, Sections 2.4.1.5 and 2.4.1.6 and the NASA Space Flight Program and Project Management Handbook (PM Handbook), Section 5.5.4 for additional information.) The scope of the SRB’s assessment with respect to initial capability, Phase E cost estimate, and major upgrades for these single-project programs and projects is defined in the Terms of Reference (ToR).

Kevin Michael Gilligan↗
DOE OSTI2023

Talent Acquisition in Scientific and Engineering Disciplines: A Case Study of National Laboratory (TASED) [Thesis]

Identifying the hindrances to performing effective talent acquisition within the science, technology, engineering, and mathematics field is an important topic for technical hiring managers. Top candidates have multiple options during highly competitive market conditions requiring managers to look for unique solutions which diverge from competition. Prior to this study there has been very little research considering national laboratory research and development challenges from a technical hiring manager’s talent acquisition perspective. Utilizing a unique combination of national laboratory multi-organization survey, pilot study, Human Resource (HR) tracking data and trust based business strategy to enhance partnering this research finds hiring managers can leverage out of the box techniques to improve internal processes while developing industry support to target highly qualified individuals. This methodology could be utilized by technical hiring managers across federal national laboratory enterprise to effectively capture next generation staff and leadership talent who align with their organization professionally as well as social culture.

99 GENERAL AND MISCELLANEOUS↗
NASA NTRS1975

The total Earth Resources System of the 1980's: A view of the future

The study was organized to address the total earth resources system in the broadest sense: distinguishing characteristics of the resources form the input, and information from user models forms the output. The effort began with a treatment of resource management requirements which traced information needs back to budgets, laws, and charters. These requirements were used to structure a 1980's scenario and to define thirty broad resource management missions (or applications) which could be confidently expected to be carried out by the future system. A classical systems approach was followed to assess the current state-of-the-art, structure system requirements, and to define the necessary platforms, sensors, and ground system architecture. The study of two resource management missions in additional detail was conducted to illuminate problems of transition from R&D to operational systems. The space shuttle's role in the system received special attention and a mission able to be served by an early flight was defined.

Cheeseman, C. E.↗
DOE OSTI2020

Guidance and Recommendations for Streamlining Reporting for Federal Energy and Water Efficiency Projects

Federal agencies are required to report on their progress in meeting various energy and water management requirements. These reporting requirements encompass energy and water projects at federal facilities, including projects that are alternatively financed, e.g., conducted through energy savings performance contracts (ESPCs) or utility energy service contracts (UESCs). The purpose of this guidance is to provide recommendations to streamline federal agency reporting. The guidance recommends the use of eProject Builder (ePB), a project development and archiving tool for energy projects. ePB carries additional value in its simplification of federal agency reporting by dovetailing with the Federal Energy Management Program’s (FEMP’s) EISA 432 Compliance Tracking System (CTS).

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
NASA NTRS1994

Issues in NASA program and project management

This volume is the eighth in an ongoing series addressing current topics and lessons learned in NASA program and project management. Articles in this volume cover the following topics: (1) power sources for the Galileo and Ulysses Missions; (2) managing requirements; (3) program control of the Tropical Rainfall Measuring Mission; (4) project management method; (5) career development for project managers; and (6) resources for NASA managers.

Hoffman, Edward J.↗
NASA NTRS2011

SOFIA Program SE and I Lessons Learned

Once a "Troubled Project" threatened with cancellation, the Stratospheric Observatory for Infrared Astronomy (SOFIA) Program has overcome many difficult challenges and recently achieved its first light images. To achieve success, SOFIA had to overcome significant deficiencies in fundamental Systems Engineering identified during a major Program restructuring. This presentation will summarize the lessons learn in Systems Engineering on the SOFIA Program. After the Program was reformulated, an initial assessment of Systems Engineering established the scope of the problem and helped to set a list of priorities that needed to be work. A revised Systems Engineering Management Plan (SEMP) was written to address the new Program structure and requirements established in the approved NPR7123.1A. An important result of the "Technical Planning" effort was the decision by the Program and Technical Leadership team to re-phasing the lifecycle into increments. The reformed SOFIA Program Office had to quickly develop and establish several new System Engineering core processes including; Requirements Management, Risk Management, Configuration Management and Data Management. Implementing these processes had to consider the physical and cultural diversity of the SOFIA Program team which includes two Projects spanning two NASA Centers, a major German partnership, and sub-contractors located across the United States and Europe. The SOFIA Program experience represents a creative approach to doing "System Engineering in the middle" while a Program is well established. Many challenges were identified and overcome. The SOFIA example demonstrates it is never too late to benefit from fixing deficiencies in the System Engineering processes.

Ray, Ronald J.↗
NASA NTRS1973

Functional Requirements for Onboard Management of Space Shuttle Consumables

This report documents the results of the study "Functional Requirements for Onboard Management of Space Shuttle Consumables." The study was conducted for the Mission Planning and Analysis Division of the NASA Lyndon B. Johnson Space Center, Houston, Texas, between 3 July 1972 and 16 November 1973. The overall study program objective was two-fold. The first objective was to define a generalized consumable management concept which is applicable to advanced spacecraft. The second objective was to develop a specific consumables management concept for the Space Shuttle vehicle and to generate the functional requirements for the onboard portion of that concept. Consumables management is the process of controlling or influencing the usage of expendable materials involved in vehicle subsystem operation. The report consists of two volumes. Volume I presents a description of the study activities related to general approaches for developing consumable management, concepts for advanced spacecraft applications, and functional requirements for a Shuttle consumables management concept. Volume II presents a detailed description of the onboard consumables management concept proposed for use on the Space Shuttle.

Graf, P. J.↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer's Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗
NASA NTRSDate not supplied

Lessons Learned With Risk Management: A Systems Engineer’s Perspective

Risk management is a communications device that, when executed as an essential task, enables systems engineering to effectively balance risk across the project. Developing and baselining risks is an essential continuous task to ensure top project concerns both from bottom up and top down are being mitigated. Risk management provides the opportunity to avoid the consequence of the risk when mitigation steps start early enough. Just discussing risk with all the project flight elements during development, even if no risks are open, provides an excellent communication opportunity between systems engineering and those elements, ensuring concerns and worries have a platform for discussion. A well-managed risk identification process will identify concerns that are serious but not being clearly communicated, and it will enable mitigation of those potential problems before they cause a failure. Effective risk management requires considerable time and effort, but that effort will save time and money across the development. Risk management must be frequent enough to be useful and in depth enough to bring out emerging issues. It also requires a trusting relationship between the lead systems engineer and element and/or subsystem leads. The discussions need to be with the right number of individuals (typically a handful) and the right duration in time (typically an hour a month). Outside of these risk working groups, there is a formal management process to input, status, and disposition risks, and a monthly Risk Management Board meeting where key project stakeholders are informed. This paper provides good guidance on effective risk management from a systems engineering perspective and provides project lessons learned from the NASA spaceflight missions NICER, Landsat 9, LRO, and OSIRIS-REx to demonstrate the effectiveness of risk management.

Lessons Learned↗
NASA NTRS1993

New mission requirements methodologies for services provided by the Office of Space Communications

The Office of Space Communications, NASA Headquarters, has recently revised its methodology for receiving, accepting and responding to customer requests for use of that office's tracking and communications capabilities. This revision is the result of a process which has become over-burdened by the size of the currently active and proposed missions set, requirements reviews that focus on single missions rather than on mission sets, and negotiations most often not completed early enough to effect needed additions to capacity or capability prior to launch. The requirements-coverage methodology described is more responsive to project/program needs and provides integrated input into the NASA budget process early enough to effect change, and describes the mechanisms and tools in place to insure a value-added process which will benefit both NASA and its customers. Key features of the requirements methodology include the establishment of a mechanism for early identification of and systems trades with new customers, and delegates the review and approval of requirements documents to NASA centers in lieu of Headquarters, thus empowering the system design teams to establish and negotiate the detailed requirements with the user. A Mission Requirements Request (MRR) is introduced to facilitate early customer interaction. The expected result is that the time to achieve an approved set of implementation requirements which meet the customer's needs can be greatly reduced. Finally, by increasing the discipline in requirements management, through the use of base lining procedures, a tighter coupling between customer requirements and the budget is provided. A twice-yearly projection of customer requirements accommodation, designated as the Capacity Projection Plan (CPP), provides customer feedback allowing the entire mission set to be serviced.

Holmes, Dwight P.↗
NASA NTRS1980

Requirements for company-wide management

Computing system requirements were developed for company-wide management of information and computer programs in an engineering data processing environment. The requirements are essential to the successful implementation of a computer-based engineering data management system; they exceed the capabilities provided by the commercially available data base management systems. These requirements were derived from a study entitled The Design Process, which was prepared by design engineers experienced in development of aerospace products.

Southall, J. W.↗
NASA NTRS2018

An “EPIIC” Vision to Evolve Project Integration, Innovation, and Collaboration with Broad Impact for How NASA Executes Complex Projects

Evolving Project Integration, Innovation, and Collaboration (EPIIC) is a vision defined to transform the way projects manage information to support real-time decisions, capture best practices and lessons learned, perform assessments, and manage risk across a portfolio of projects. The foundational project management needs for data and information will be revolutionized through innovations on how we manage and access that data, implement configuration control, and certify compliance. The embedded intelligence of new interactive data interfaces integrate technical and programmatic data such that near real time analytics can be accomplished to more efficiently and accurately complete systems engineering and project management tasks. The system-wide data analytics that are integrated into customized data interfaces allows the growing team of engineers and managers required to develop and implement major NASA missions the ability to access authoritative source(s) of system information while greatly reducing the labor required to complete system assessments. This would allow, for example, much of what is accomplished in a scheduled design review to take place as needed, between any team members, at any time. An intelligent data interface that rigorously integrates systems engineering and project management information in near real time can provide substantially greater insight for systems engineers, project managers, and the large diverse teams required to complete a complex project. System engineers, programmatic personnel (those who focus on cost, schedule, and risk), the technical engineering disciplines, and project management can realize immediate benefit from the shared vision described herein. Implementation of the vision also enables significant improvements in the performance of the engineered system being developed.

Moreland, Robert J.↗
NASA NTRS2014

NASA Space Flight Program and Project Management Handbook

This handbook is a companion to NPR 7120.5E, NASA Space Flight Program and Project Management Requirements and supports the implementation of the requirements by which NASA formulates and implements space flight programs and projects. Its focus is on what the program or project manager needs to know to accomplish the mission, but it also contains guidance that enhances the understanding of the high-level procedural requirements. (See Appendix C for NPR 7120.5E requirements with rationale.) As such, it starts with the same basic concepts but provides context, rationale, guidance, and a greater depth of detail for the fundamental principles of program and project management. This handbook also explores some of the nuances and implications of applying the procedural requirements, for example, how the Agency Baseline Commitment agreement evolves over time as a program or project moves through its life cycle.

Michael P Blythe↗
NASA NTRS2006

From Zero to Integration in Eight Months, the Dawn Ground Data System Engineering Challenge

The Dawn GDS Team met the SC Sim integration challenge in eight months. The GDS System Engineering approach in response to the SC Simintegration challenge, focused on a set of key practices: decomposition of project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; risk management thru management of expectations; and aggregation of intermediate products into a final product. By maintaining a a system-level focus, the overall systems engineering process unified team GDS Team members with a common goal: the success of the ground system as a whole and not just the success of their individual expert contributions. Incorporation of Agile-type development efforts were aligned with a risk strategy based on team-oriented principles and expectations management, thus achieving a more stable baseline solution without compromising the integrity of the GDS design.

Dawn Mission↗
NASA NTRS2008

Reducing NPR 7120.5D to Practice: Preparing for a Life-Cycle Review

In March 2007, NASA issued revised rules for space flight project management, NPR 7120.5D, 'NASA Space Flight Program and Project Management Requirements.' Central to the new rules was the construct of Key Decision Points, maturity gates that the project team must pass in order to continue development. In order that the KDP decision be fully informed, the NPR required, as entrance criteria for the gate, the generation and delivery of specified planning, technical, and cost/schedule documents (gate products) and a life-cycle review, the Preliminary Design Review. Building on JPL experience on the Prometheus and Juno projects, the team successfully organized for and conducted these reviews on an aggressive schedule. Key actions were taken to proactively interact with the SRB, produce high-quality gate products with stakeholder review, generate review presentation materials, and handle a myriad of supporting logistical functions. A review preparation team was established, including a Review Captain and leads for documentation, information systems, and logistics, and their roles, responsibilities and task assignments were identified. Aids were produced, including a detailed review preparation schedule and a comprehensive gate products production table. Institutional support was leveraged early and often. Implementation strategy reflected the needs of a nationally-distributed team, as well as applicable export control and IT security requirements. This paper gives a brief overview of the GRAIL mission and its project management challenges, provides a detailed description of project PMSR and PDR preparation and execution activities, including positive and negative lessons learned, and identifies recommendations for future NASA (and non-NASA) project teams.

NPR 7120.5D↗
NASA NTRS1985

Design of an advanced flight planning system

The demand for both fuel conservation and four-dimensional traffic management require that the preflight planning process be designed to account for advances in airborne flight management and weather forecasting. The steps and issues in designing such an advanced flight planning system are presented. Focus is placed on the different optimization options for generating the three-dimensional reference path. For the cruise phase, one can use predefined jet routes, direct routes based on a network of evenly spaced grid points, or a network where the grid points are existing navaid locations. Each choice has its own problem in determining an optimum solution. Finding the reference path is further complicated by choice of cruise altitude levels, use of a time-varying weather field, and requiring a fixed time-of-arrival (four-dimensional problem).

Sorensen, J. A.↗
NASA NTRS2005

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↗
DOE OSTI2021

Nondestructive Assay Technical Infrastructure Program Mission and Vision

The Nondestructive Assay Program (NDAP) mission and vision is achieved by identifying and accomplishing a set of programmatic goals that correspond with eight broad technical program elements. The NDAP was created as a result of Defense Nuclear Facility Safety Board Recommendation 2007-1, entitled “Safety-Related In Situ Nondestructive Assay of Radioactive Materials,” which emphasized the need to improve in situ measurements of radioactive material at US Department of Energy (DOE) defense nuclear facilities. An NDAP five-year plan will define tasks to accomplish specific goals identified in the NDAP mission and vision. This mission and vision is applicable for eight technical program elements: Hardware/Software Development, Algorithm Development and Nuclear Data, Uncertainty Quantification, Nuclear Materials, Staffing, Personnel, And Training, Data Management, Requirement and Standards, and Information Preservation and Dissemination. An additional program element is technical support, which provides daily execution management support for the NDAP, site scope, and deliverable tracking via site task managers, along with technical advisement and support from the technical support group. The NDAP mission and vision provides attributes with specific goals for each program element, and some goals benefit multiple program elements. The goals and attributes defined herein are implemented via an NDAP five-year execution plan that defines site work scope, budget, and deliverables, all of which are updated annually. The NDAP is designed to benefit nondestructive assay (NDA) needs to support DOE nuclear criticality safety programs, ensuring that NDA technology is sufficiently capable of guaranteeing the safety of those who handle, store, process, or transport fissionable materials in the complex. Especially important for the NDAP is to maximize capabilities to identify, characterize, and manage in situ fissile material deposits in process equipment to ensure nuclear criticality safety at processing facilities.

73 NUCLEAR PHYSICS AND RADIATION PHYSICS↗