AIR FORCE MIL-HDBK-520 A-2011 SYSTEM REQUIREMENTS DOCUMENT GUIDANCE《系统要求文件指南》.pdf

1、 NOT MEASUREMENT SENSITIVE MIL-HDBK-520A 19 December 2011 SUPERSEDING MIL-HDBK-520 (USAF) 5 March 2010 DEPARTMENT OF DEFENSE HANDBOOK SYSTEM REQUIREMENTS DOCUMENT GUIDANCE This handbook is for guidance only. Do not cite this document as a requirement. AMSC N/A AREA SESS DISTRIBUTION STATEMENT A. App

2、roved for public release; distribution is unlimited. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-520A ii FOREWORD 1. This handbook is approved for use by all Departments and Agencies of the Department of Defense (DoD). 2. This handbook w

3、as prepared solely for Government personnel and associated support contract staff. Therefore, many of the links herein require .gov or .mil access using a Common Access Card (CAC). Please report any broken links. 3. This handbook was initially prepared through the Continuous Capability Planning Inte

4、grated Product Team (CCP IPT) under the Develop and Sustain Warfighting Systems (D data or information about data; or descriptive information about an entitys data, data activities, systems, and holdings. For example, discovery metadata is a type of metadata that allows data assets to be found using

5、 enterprise search capabilities (DoDD 8320.02). Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-520A 6 3.20 Operational Requirements. Top level system performance attributes or capabilities of the system or subsystem documented in the warfig

6、hters capabilities documents. 3.21 Performance Requirements. Requirements defining the extent to which a mission or function should be executed, generally measured in terms of quantity, quality, coverage, timeliness or readiness. 3.22 Regulatory Requirements. Requirements directed by military regula

7、tions and other governmental agencies (DoDI 5000.02). 3.23 Requirements Analysis. Requirements Analysis encompasses definition and refinement of system, subsystem, and lower-level functional and performance requirements and interfaces to facilitate the Architecture Design process. Requirements Analy

8、sis needs to provide measurable and verifiable requirements. Requirements being developed by the materiel developer balance requirements to include performance, functional and technical constraints and both life-cycle costs and development cycle time (DAG, https:/dag.dau.mil). 3.24 Requirements Mana

9、gement. Requirements Management provides traceability back to user-defined capabilities as documented through either the Joint Capabilities Integration and Development System or other user-defined source, and to other sources of requirements. Requirements traceability is one function of requirements

10、 management. As the systems engineering process proceeds, requirements are developed to increasing lower levels of the design. Requirements traceability is conducted throughout the system life cycle and confirmed at each technical review. Traceability between requirements documents and other related

11、 technical planning documents, such as the Test and Evaluation Master Plan, is maintained through a relational data base, numbering standards or other methods that show relationships. A good requirements management system allows for traceability from the lowest level component all the way back to th

12、e user capability document or other source document from which it was derived (DAG, https:/dag.dau.mil). 3.25 Statutory Requirements. Requirements directed by public law (DoDI 5000.02). 3.26 Subsystem. A grouping of items satisfying a logical group of functions within a particular system. 3.27 Synth

13、esis. Translation of input requirements (including performance, function, and interface) into possible solutions (resources and techniques) satisfying those inputs. Defines a physical architecture of people, product and process solutions for logical groupings of requirements (performance, function a

14、nd interface) and then designs those solutions. Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-520A 7 3.28 System. An integrated composite of people, products and processes that provide a capability to satisfy a stated need or objective. 3.

15、29 Systems Analysis and Control. Imposition of structure and discipline into system evolution by: measuring progress based on demonstrated performance; identifying, developing and examining alternatives; making decisions based on cost, schedule, performance and risk to affect balanced results; docum

16、enting evolution and rationale; and controlling resulting configurations. 3.30 Systems Engineering (SE). Systems engineering is an interdisciplinary approach and process encompassing the entire technical effort to evolve, verify and sustain an integrated and total life cycle balanced set of system,

17、people, and process solutions that satisfy customer needs. Systems engineering is the integrating mechanism for the technical and technical management efforts related to the concept analysis, materiel solution analysis, engineering and manufacturing development, production and deployment, operations

18、 and support, disposal of, and user training for systems and their life cycle processes. (DAG, https:/dag.dau.mil). 3.31 System of Systems (SoS). A set or arrangement of interdependent systems that are related or connected to provide a given capability. The loss of any part of the system will degrad

19、e the performance or capabilities of the whole. An example of an SoS could be interdependent information systems. While individual systems within the SoS may be developed to satisfy the peculiar needs of a given warfighter group (like a specific Service or agency), the information they share is so i

20、mportant that the loss of a single system may deprive other systems of the data needed to achieve even minimal capabilities (Acquisition Community Connection https:/acc.dau.mil/CommunityBrowser.aspx?id=54715). 3.32 Weapon Systems Acquisition Reform Act (WSARA). The Weapon System Acquisition Reform A

21、ct (WSARA) of 2009, Public Law 111-23, May 22, 2009. Weapon Systems Acquisition Reform Act of 2009 One Hundred Eleventh Congress of the United States of America AT THE FIRST SESSION Begun and held at the City of Washington on Tuesday, the sixth day of January, two thousand and nine An Act To improve

22、 the organization and procedures of the Department of Defense for the acquisition of major weapon systems, and for other purposes. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled (http:/www.gpo.gov/fdsys/pkg/PLAW-111publ23/pdf/PLAW-111pu

23、bl23.pdf) 3.33 Acronyms. ABL Allocated Baseline AF Air Force AFROC Air Force Requirements Oversight Council AFRL Air Force Research Laboratory AFSO21 AF Smart Operations for the 21st Century Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-52

24、0A 8 AIP Acquisition Improvement Plan AoA Analysis of Alternatives ASC Aeronautical Systems Center C2 Command and Control CAC Common Access Card CBA Capabilities-Based Assessment CBP Capabilities Based Planning CCP Continuous Capability Planning and Contract Change Proposal CCTD Concept Characteriza

25、tion and Technical Designation CDD Capability Development Document CI Configuration Item CJCSI Chairman of the Joint Chiefs of Staff Instruction CoE Concept of Employment CONOPS Concept of Operations CPD Capability Production Document CRRA Capabilities Review and Risk Assessment CSAF Chief of Staff

26、of the Air Force CWBS Contract Work Breakdown Structure DAG Defense Acquisition Guidebook DAU Defense Acquisition University DCR DOTMLPF Change Recommendation DID Data Item Description DoD Department of Defense DoDD Department of Defense Directive DoDI Department of Defense Instruction DOTMLPF Doctr

27、ine, Organization, Training, Materiel, Leadership and Education, Personnel, and Facilities DSP Defense Standardization Program D supportability; physical and functional integration; human system integration; security, test and evaluation; quality assurance; hardware; software; etc. The SRD will also

28、 be used on mature programs to add or modify current capabilities. 4.4 Functional baseline (FBL). An SRD establishes the basis for an acquisition program FBL (see MIL-HDBK-61). It documents acquisition requirements translated from a warfighter capabilities document(CJCSI 3170.01) into an acquisition

29、 format used as a baseline for a system or subsystem specification typically prepared by an offeror/contractor. It communicates government system or subsystem requirements in a concise, measurable and understandable fashion. At contract award the SRD is replaced by a documented FBL in a contractor p

30、repared system or subsystem specification. The generic SRD template in this handbook is written in a very broad fashion without documenting specific requirements. It was meant to be used to facilitate documentation of acquisition requirements for a range of systems or subsystems that can be passed t

31、o a contractor as part of an RFP or ECP. The generic SRD template accommodates any MS (for example, pre MS A, MS A, MS B, MS C) or program phase. As every program is unique with its own set of capabilities and requirements, so will each respective SRD be unique. There is no one single template or fo

32、rmat suitable for all systems and subsystems hence a generic template was developed. 4.5 Early systems engineering (SE). Throughout the acquisition process, SE provides the technical foundation for an acquisition program. Particularly in early stages of an acquisition, SE analysis and products are v

33、ital to a program offices ability to assess feasibility of addressing warfighter capabilities, technology needs of potential solutions, and robust estimates of cost, schedule, and risk, all leading to a predictable, disciplined acquisition. With increased emphasis in the Weapons Systems Acquisition

34、Reform Act (WSARA) and the new DoDI 5000.02 on the Materiel Solution Analysis Phase (Enclosure 2, paragraph 4 of DoDI 5000.2) and the Technology Development Phase (Enclosure 2, paragraph 5 of DoDI 5000.2) there is a need for increased emphasis on SE during these activities. “The ability of U.S. mili

35、tary forces to field new weapon systems quickly and to contain their cost growth has declined significantly over the past few decades. There are many causes including increased complexity, funding instability, bureaucracy, and more diverse user demands, but a view that is gaining more acceptance is

36、that better SE could help shorten development time.” To investigate this assertion in more detail, the US Air Force asked the National Research Council (NRC) to examine the role that SE can play during the acquisition life cycle to address root causes of program failure especially during pre-milesto

37、ne A and early program phases. This study assessed the relationship between SE and program outcome; examined the SE workforce and analyzed SE functions and guidelines. It includes a definition of the minimum set of SE processes that need to be accounted for during project development. The study repo

38、rt, Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for Future Air Force Acquisition, National Research Council, 2008, The National Academies Press, can be accessed at The National Academies Press website11. Pre-Milestone A and Early-Phase Systems Engineering

39、: A Retrospective Review and Benefits for Future Air Force Acquisition, National Research Council, 2008, The National Academies Press, . http:/www.nap.edu/catalog.php?record_id=12065 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-MIL-HDBK-520A 12 5.

40、 SRD DESCRIPTION 5.1 Requirements development. A program office engineering team defines system or subsystem level functional and performance requirements derived from warfighter capabilities documents, Concept of Operations (CONOPS), Concept of Employment (CoE), Analysis of Alternatives (AoA), syst

41、em-level performance metrics, mission threads/use cases, and usage environment, which are captured in a programs SRD. These requirements known as acquisition requirements or system/subsystem requirements because taken as an aggregate, they are written in acquisition/contractual terms and they define

42、 the entire system/subsystem performance characteristics. Further complicating the terminology used, these aggregate requirements are also now known as attributes. 5.2 Attributes. The program office engineering team defines acquisition requirements in terms of system level attributes and associated

43、constraints defined by the warfighter. Attributes are further broken out and prioritized as Key Performance Parameters (KPPs) and Key System Attributes (KSAs). Acquisition requirements are written using performance language. The SRD avoids describing a specific solution unless there is a compelling

44、warfighter capabilities need. It should not preclude leasing, commercial, or non-developmental solutions. An SRD should not contain any programmatic or Statement of Work (SOW) or Statement of Objectives (SOO) language that belong in other sections of an RFP or ECP. During the subsequent source selec

45、tion, these performance requirements, as documented in the offerors draft system or subsystem specification, are evaluated for cost, performance, schedule, and risk of various candidate solutions resulting in a best value solution. Note: The Defense Acquisition Guidebook (DAG) uses the term “system

46、performance specification” interchangeably with “system specification.” System specification is used exclusively throughout this handbook. 5.3 Capabilities documents. There are three Joint Capabilities Integration and Development System (JCIDS)capability documents used for materiel development: Init

47、ial Capabilities Document (ICD), Capability Development Document (CDD) and Capability Production Document (CPD). Details on use, content and format of JCIDS documents are located in CJCSI 3170.01 and the JCIDS Manual. The Joint Capabilities Document (JCD) was rescinded by CJCSI 3170.01G but may stil

48、l exist on some programs. Additionally, there are Service specific alternative means for documenting capabilities that are used in some situations, for example, system modification. 5.4 Warfighter attributes. JCIDS capability documents, (for example, ICD, CDD, CPD) identify warfighter attributes in

49、the form of Key Performance Parameters (KPPs), Key System Attributes (KSAs), and other Attributes. The JCIDS capability document lists each capability requirement, associated threshold, objective and rationale/analytical reference. Section 3 of the SRD documents these system capability attributes and associated thresholds and objectives. Section 4 of the SRD contains verification provisions for each requirement (attribute) implementing a ve