Department Of Defense Dod Perspectives

Looking at Military Standard 499B [8.2], we find requirements analysis to be one of the four key elements of the systems engineering process (see Figure 7.1), represented in a short form by the key words:

• Define/derive/refine performance requirements (what item must do and how well)

• The (systems engineering) process shall define and analyze performance and functional requirements, define and design system elements to satisfy those requirements, and establish the final configuration.

The full description of the element of requirements analysis is reproduced in Exhibit 8.1.

Exhibit 8.1: Requirements Analysis as Stated in Mil-Std-499B

User requirements/objectives shall be defined/refined and integrated in terms of quantifiable characteristics and tasks that item solutions must satisfy. Technical requirements shall be developed concurrently for all functions and subfunctions based on the system life cycle, and iteratively to provide progressively more detailed performance requirements definition. For each requirement, the absoluteness, relative priority and relationship to other derived requirements shall be identified. Impacts of identified user requirements/objectives and derived requirements in terms of mission (tasks), environments, constraints and measures of effectiveness shall be analyzed as the basis for defining and deriving performance requirements. These impacts shall be continually examined for validity, consistency, desirability, and attainability with respect to technology availability, physical and human resources, human performance capabilities, life cycle costs, schedule and other identified constraints. The output of this analysis will define technical performance requirements and either verify existing requirements or develop new requirements that are more appropriate for each item.

We note especially that the systems engineering team is to ''either verify existing requirements or develop new requirements that are more appropriate for each item.'' Although this clearly makes good sense, the insertion of new requirements, as alluded to before, can be an extremely controversial issue. Strictly new requirements developed by the systems engineering team cannot be accepted until they are confirmed as acceptable by the user and system acquisition agent. Again, this can be a difficult process that is impeded by the general reluctance to change requirements, often necessitating an approved change in a formal contractual document and relationship.

In our definition of RAA, we include the matter of requirements allocation. This inclusive definition means that requirements, in addition to being analyzed, are allocated to system functions and subfunctions. Thus, the definition in this book leads to the explicit interaction between RAA and functional analysis/allocation (see the list of thirty systems engineering elements in Exhibit 7.1).

Another DoD perspective related to RAA can be found in the so-called DoD 5000 series. In DoD Directive 5000.1 [8.3], reference is made to evolutionary requirements definition. A key statement in this regard is:

Once approved as a new start acquisition program, operational performance requirements for the concept(s) selected shall be progressively evolved from broad operational capability needs to system-specific performance requirements (e.g., for range, speed, weight, payload, reliability, maintainability, availability, interoperability).

In addition, the same directive identifies the three major decision-making support systems that affect the acquisition processes, namely, the

• Requirements Generation System (RGS)

• Acquisition Management System (AMS)

• Planning, Programming, and Budgeting System (PPBS)

Thus, the DoD sees the matter of generating requirements as a major factor in its overall acquisition approach. The front end of the RGS is developing a mission needs statement that defines projected needs in broad operational terms. Examples cited are

• The need to impede the advance of large armored formations 200 kilometers beyond the front lines

• The need to neutralize advances in submarine quieting made by potential adversaries

The Mission Need Statement flow is depicted in Figure 8.1. As shown, when the Mission Need Statement is approved, the system enters Milestone 0, allowing for the initiation of concept studies. Again, all of this is defined as part of the Requirements Generation System within the DoD.

In DoD Instruction 5000.2 [8.3], there is a section on Evolutionary Requirements Definition. The stated purpose of that section is to ''establish the basis for the determination, evolution, documentation, and validation of mission needs and system performance requirements.'' The focus is on establishing system performance objectives and minimum acceptable requirements, and the need for documentation in an Operational Requirements Document (ORD). Another point of emphasis is the progressive refinement of the initial broad objectives and the minimum acceptable requirements. Thus, there is a carry-forward of the notion of defining and then evolving a set of minimum acceptable requirements for the system.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment