Original title: Interpretation of the report "Improving the Development Process of Weapon System Technical Requirements: System Based Management Method"
Interpretation of the report "Improving the Development Process of Weapon System Technical Requirements: System Based Management Method"
On November 3, 2022, RAND Corporation of the United States released the Report on Improving the Development Process of Weapon System Technical Requirements - System based Management Method, which aims to reduce or avoid the cost or schedule overrun of weapon systems caused by negligence in the development process of technical requirements through the application and research of the theoretical methods of system engineering in the development of weapon system technical requirements The weapon performance cannot meet the operational requirements, and the project is cancelled. The report is roughly divided into five parts: introduction, the process of developing technical requirements of the Air Force Department, the method of developing technical requirements, the applicability and feasibility of system theory process analysis (STPA), discussion and suggestions, and four appendices: research methods, T-7 and MH-139 case studies, system theory process analysis (STPA) research, and detailed methods.
1、 Background
2、 Main contents
（1） Introduction
The Air Force Department contracts with industry to design and produce weapon systems through competitive source selection. The bidding document is an integral part of the procurement process, including a set of technical requirements (requirements) for system design, which determines the selection of the main contractor and the criteria for the baseline contract negotiation between the government and the contractor. Therefore, accurate, feasible and affordable technical requirements are formulated, It is critical to ensure that the Air Force weapon system provides the required operational capability within budget and schedule constraints.
Technical requirements development is from the preparation of capability development document (CDD) in the whole life cycle of weapon system acquisition to milestone B (i.e. project startup). The project management office receives the capability development document, converts it into the technical requirements in the bidding document, determines the contractor and signs the contract, and then starts to supervise the detailed design, development test and production. The requirements generally go through three stages in the acquisition process: "warfighter defines operational capability requirements", "project management office defines system level technical requirements", and "contractor defines detailed subsystem and component level technical requirements". Each stage depends on the requirements of the previous stage. Negligences or errors in the requirements of one stage may be found in subsequent stages, It is necessary to supplement or revise the existing design requirements. The evolution of such requirements may lead to rework and additional testing of design or production, increase the acquisition cost and schedule of the project, increase the use and support costs, and in particular may lead to combat weapon systems with design defects, cause security risks, and reduce the effectiveness of completing tasks.
The research shows that the demand growth is more directly related to the system level technical demand decomposition that is not clearly defined, as well as the underestimate of technical complexity, which leads to unrealistic cost estimates. The US Government Accountability Office (GAO) report points out that the technical requirements of the Department of Defense are often not feasible, because "the Department of Defense often does not conduct sufficient pre demand analysis for projects through systems engineering". Through the case study, it is found that the project that adopts the system engineering method to develop technical requirements will have better cost and schedule control.
The research method used in this study aims to answer the following three questions:
① How does the Air Force currently develop technical requirements and why? (Blue)
② Can System Theory Process Analysis (STPA) be used for technical requirements development? (Red)
③ What are the best practices for developing technical requirements? (orange)
（2） Current Air Force Department process for developing technical requirements
At present, the technical requirements development process of the US Air Force Department lacks authoritative, consistent and detailed policy guidance, which is easy to make the project management office adopt unsupported or invalid methods. The development process of its general technical requirements is as follows: First, the project management office will analyze the capacity requirements into basic technical fields under the focus on key performance parameters and key system attributes; Secondly, operators and industry participate in the process, repeatedly define and integrate initial technical requirements with the project management office, review the trade-offs between cost/schedule and performance of system design, and determine which trade-offs are acceptable; Finally, through repeated iterations, an agreement is reached until the final technical requirements are determined.
The study found that the Air Force is facing some challenges that restrict the effective development of technology requirements:
① The professional knowledge and manpower level of system engineering are limited.
② Temporary technical requirements development process. In view of the lack of available system engineering expertise, training and guidance, as well as the high demand for such low-density resources, the project management office has to find alternative ways to meet the project schedule, such as relying on personnel experience, using temporary procedures to develop technical needs, most of which draw on the technical needs of similar project development, relevant industry standards Market research and existing subject matter expert judgment, rather than specific system engineering tools.
③ Limited by the number and type of stakeholder participation. Although the warfighter has participated in the development of technical requirements, the role of the warfighter depends on the existing relationship with the warfighter and his personality. In addition, no maintenance personnel, testers and other stakeholders have been found involved.
④ The scope of power is vague. The study found that there are some uncertainties in the boundaries of power between the PMO, combatants and testers. And since there is no formal stakeholder participation mechanism, there is no procedure to ensure that the opinions of operators are included.
（3） Methods of technical requirements development
Systems engineering is considered the best practice for developing technical requirements. Based on system engineering and combined with the system theory process analysis (STPA) method, this report explores and studies a method for developing technical requirements, as shown in the figure below, to transform the capability requirements (orange input arrows) into technical requirements (orange output arrows) suitable for inclusion in the bidding document, To help the PMO successfully develop technical requirements from operational capabilities in the capability document.
The method of technical requirements development includes seven elements, which are: defining scenarios, collecting information, formulating strategies, generating technical requirements, quality inspection, obtaining feedback, and meeting exit criteria. Each element consists of a set of tasks, tools and stakeholders. It emphasizes several basic concepts:
① The method itself is iterative. As more information is determined and decisions are reached, technical requirements are constantly improved. At the same time, the method includes a set of exit criteria, which are objective and measurable, and clearly delineate where it is possible to exit the process with a set of high-quality (such as feasible and affordable) technical requirements that meet the required capabilities.
② Ensure data traceability. The key is to record the process and track the decision, including the experience gained and the basis for the decision from beginning to end.
③ Distinguish between "development" and "generation" of technical requirements. The development technology demand refers to the whole development process, including information collection, feedback solicitation and strategic decision-making; Generating technical requirements refers to the process used to define the technical requirements to be used in the bidding document.
④ Each iteration should follow the usual sequence. The first is to establish situation awareness and strategy, the second is to generate technical requirements, and the third is to improve technical requirements.
1. Establish situational awareness and strategy
This method defines three elements for establishing appropriate situational awareness and determining the strategy for generating technical requirements. The tasks and stakeholders involved in each element are shown in red below.
2. Generate technical requirements
The fourth element of this method includes five tasks, namely, defining functional boundaries, defining functions, deriving technical requirements, defining technical requirements to include constraints, analyzing, trading and defining technical requirements. These tasks generate technical requirements in a top-down manner, as shown in the figure below. For each function, it is required to derive its quality attributes, including the performance, reliability, maintainability and safety of the system. There are many methods for deriving requirements, such as functional flow charts, but stakeholders other than the project management office need to participate, such as operators, maintenance and testing groups, to ensure that the derived requirements are consistent with the objectives of stakeholders.
After each draft of technical requirements is generated, the technical requirements will be improved repeatedly by analyzing it, including affordability, feasibility and physical quality allocation, as well as developing a trading space to capture the sensitivity of its characteristics to changes in technical requirements, so that it can finally be incorporated into regulatory requirements.
3. Improve technical requirements
Based on the above process, two elements need to be adopted to review the draft technical requirements to make necessary improvements. The first is quality assurance assessment. In view of the fact that the subset of technical requirements may be developed in isolation, it is necessary to integrate them. A standardized checklist can be used to ensure that each technical requirement can be met while avoiding redundancy, gap or conflict. If problems are found, it may lead to feedback on the previous element (that is, generating technical requirements) for improvement. Once the technical requirements are fully integrated, the project management office can translate them into the contract language. The second is the feedback mechanism. Once the technical requirements have passed the quality inspection, three tasks provide a formal mechanism for the review of stakeholders outside the PMO. The first task is to advise stakeholders to provide feedback and determine feedback based on the process agreed during the development strategy elements. Task 2 is red team or independent review. This task can take many forms, but it should include individuals who are already familiar with the system and tasks to reduce the need for additional personnel and resources. The third task is to solicit and adjudicate feedback from the industry, such as the draft RFP.
（4） Applicability and feasibility of system theoretical process analysis (STPA)
1. Applicability
(1) Insight and driving force
How STPA realizes the understanding of the system is mainly shown in:
① Using the STPA method, analysts are required to change their thinking mode from bottom-up (i.e. component level) to top-down (i.e. system level). They must first define and understand the system objectives before conducting subsequent analysis.
② To define objectives, develop control structures, and determine unsafe control actions and scenarios, analysts need to fully understand the system. In order to answer the questions raised by STPA, analysts must strictly review relevant documents (such as capability requirements, operational concepts) and discuss with system stakeholders (warfighters, testers, pilots, maintenance personnel, etc.).
③ STPA provides a structure and goal for analysts to review documents and hold discussions. Structured analysis process enables analysts to organize system concepts to provide a better overall picture of the system.
(2) Constraints and uncertainties
First, STPA cannot replace many basic system engineering works, which are necessary for developing technical system knowledge and effectively preparing technical requirements for inclusion in the bidding document. This study identified the following:
① Technical knowledge about the system still needs to be acquired through engineering experience and research.
② Trade studies are still needed to determine which technology needs are beneficial to cost or risk.
③ The design proposal developed through STPA still needs to be translated into a technical requirement statement suitable for the RFP.
④ Efforts are still needed to integrate the technical requirements of various technical areas and ensure that the requirements meet all quality characteristics.
Secondly, it is impossible to find enough evidence to determine whether STPA can effectively perform some other important functions required for technical requirements development. For example, trade off analysis of technical requirements. In addition, there is little evidence that STPA itself can derive a comprehensive set of technical requirements.
2. Feasibility
Requirements for effective implementation of STPA, including (1) methodological expertise; (2) Special or technical expertise; (3) Stakeholder participation and coordination; (4) Human resources. The stakeholders of STPA said that if these four requirements are not met, the analysis conducted may provide wrong, unreliable or incomplete results.
（5） Discussion and suggestions
1. Short term suggestions
① Take this method as the customizable guidance of the project management office and system stakeholders, and give priority to their understanding of this method.
② Assign military representatives to stakeholders, and assign representatives from the executive command and test teams to the initial cadres of new projects or the management offices of existing projects, so that they can truly participate in the development of technical requirements.
2. Medium term suggestions
① As the system engineering headquarters, the Air Force Life Cycle Management Center/Technical Engineering Division should adopt a trusted agency mechanism (a system engineering company prohibited from participating in project competition) to enhance its system engineering expertise.
② Provide and/or request additional training for the PMO.
3. Long term suggestions
① Specify formal warfighter roles and participation mechanisms.
② Increase organic system engineering expertise.
③ Early system engineering shall be given priority in procurement.
3、 Conclusion
To sum up, in recent years, the U.S. military has widely used the theoretical methods of system engineering to explore and study its application in the process of weapon system research and development, constantly standardize and improve the scientific and efficient development of its weapons and equipment, reasonably reduce the cost and progress of weapons and equipment, and comprehensively improve the efficiency cost ratio of equipment operations to obtain asymmetric technical advantages.
The RAND Air Force Project is a department of RAND Corporation and also a federally funded research and development center of the Air Force Department. It provides independent analysis on policy choices that affect the development, deployment, combat readiness and supply of current and future aviation, aerospace and network forces, and provides support for the US Air Force and the PLA.
Disclaimer: This article is adapted from Haiying Information, originally written by Yuan Guiping. The content of the article is the personal opinion of the original author. This public account is compiled/reproduced only to share and convey different views. If you have any objection, please contact us!
Transferred from Haiying Information
Author Yuan Guiping
Editor: Zheng Shi
Introduction to the Institute
The International Institute of Technology and Economics (IITE), established in November 1985, is a non-profit research institution affiliated to the Development Research Center of the State Council. Its main function is to study major policy, strategic and forward-looking issues in China's economic, scientific and technological social development, track and analyze the world's scientific, technological and economic development trend, and provide decision-making advisory services for the central government and relevant ministries. "Global Technology Map" is the official WeChat account of the International Institute of Technology and Economics, which is dedicated to delivering cutting-edge technology information and scientific and technological innovation insights to the public.
Address: Block A, Building 20, Xiaonanzhuang, Haidian District, Beijing
WeChat: iite_er Go back to Sohu to see more
Editor in charge:
