Top left banner Top right banner
Bottom left banner Bottom right banner
Home : Home : Warfare Centers : NSWC Dahlgren : Resources : Leading Edge : I&I Leading Edge : Zilic
Capability Evolution Documents:
Managing R&D and S&T Investments to Improve Warfighting Capabilities

By Anthony Zilic

Acquisition decisions are made in the context of a complex system of systems. These decisions are driven by many different factors; threats, capability gaps, requirements, legacy architectures, measures of effectiveness and performance, business process changes, and strategic choices.

Developers currently synthesize their plans and milestones through an iterated manual process until reaching stakeholder consensus that capability, cost, performance and schedule are appropriately balanced. Articulating the vision and resulting plan to senior leadership to explain how capability matures over time is more art than craft. Imagine if your car’s dashboard changed every time you turned the key, or worse, every time you looked down to check your speed. Providing a common holistic view of how drivers influence technology and how technology matures into capability is the challenge to managers, designers, scientists and engineers.

This article proposes the use of “Capabilities Evolution Documents” (CEDs) as a “common dashboard.” The CED is a data-driven, high-level depiction of a mission framework, enabling capabilities, warfighting systems and supporting technologies. By exploring the foundational CED elements and the relationships across capability, technology and threshold, the reader will better understand how these documents foster improved management of the Navy’s research and development and science and technology investments. Before exploring the elements of the CED, it helps to review a basic approach to Systems Engineering illustrated in the process known as the Systems Engineering “V.”

The Systems Engineering “V”

Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete Systems Engineering domain, including:

  • Cost & Schedule
  • Performance
  • Manufacturing
  • Test
  • Training & Support
  • Operations
  • Disposal

Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all stakeholders with the goal of providing a quality product that meets the user needs. The International Council on Systems Engineering provides resources explaining this process (http://www.incose. org/practice/whatissystemseng.aspx ).

Processes have matured since the Systems Engineering discipline was recognized in the 1950’s. Figure 1 depicts the modern process as applied to design and acquisition of military systems, commonly known as the System Engineering “V.”

Inputs and Processes

Processes and inputs that flow down the left side of the diagram represent increasingly granular and specific statements of the user’s needs. The technical processes are iteratively applied until it is possible to develop a detailed production design, test plans, and employment concepts. This activity is undertaken using well defined “Technical Processes” listed on the left side of the diagram.

Outputs and Processes

After selecting a design that best meets the requirements, tasks flow up the right side of the diagram until capability has been delivered to the warfighter. The activity progresses using well defined “Technical Processes” listed on the left side of the diagram. Both the top-down requirements flow and bottom-up capability development are governed by Technical Management Processes which, when properly applied, ensure requirements “creep” i.e., uncontrolled changes or continuous growth in a project’s scope, is minimized within the context of the system design.

Introduction to the Capability Evolution Document Concept

It is easy to imagine the complexity of developing the acquisition documentation package. There is often very little detail regarding enabling science and technology (S&T). A new artifact depicting the relationship of S&T to a warfighting need is required. This artifact will articulate the total system of warfighting need to research, acquisition and fielding. The Capabilities Evolution Document (CED) is proposed as a solution to this need.

The CED in Figure 2, is a depiction of technology flowing through development and integration to meet a warfighting need over time. It is a top-down mission architecture enriched by the bottom-up, data-driven summaries of research, technology, systems, platforms, missions, and drivers. Drivers can be strategy, capability gaps, requirements, technical gaps, policy - all of which correspond to the upper left side of the System Engineering “V.”

As the focus flows through Mission(s) to Capability to Systems/Components to Technology Advancements, the impact of today’s research is shown to be increasing in the far term. Reversing this flow corresponds to the right side of the System Engineering “V.” The relationship of solid research and/or technology development today is aligned to operational needs of the near, mid and far term, thus reinforcing research investments (Budget Activity 2 and Budget Activity 3 S&T projects) as part of the Systems Engineering processes.

Common taxonomy is a key factor of practical and usable CED’s. Properly developed, sets of CED’s underpinned by shared taxonomy can be analyzed across missions. This helps identify cases where technologies can contribute to multiple capabilities. For example, improved information technology has application to many DoD systems from weapons development to business office operations. Such analysis is possible if CED developers not only use the same vocabulary but also the same definitions. In later paragraphs, we explore techniques to enforce shared taxonomy across communities.

Figure 2 is an idealized CED model. In practice, the model is adaptable to incorporate only the layers needed to help “tell the story” of how user’s needs guide technology advancements and system development. Other themes available in the CED are the identification of missing projects or programs from the critical path to capability development and how newly available technologies can inform system design.

“New capabilities desired by national leadership may involve modifications to kill chains, Command and Control (C2) constructs, improved coordination, and performance. These capabilities must be realized through modifications to programs of record and integration across elements of the system that have their own independent programmatic momentum. A challenge of Systems of Systems Engineering is to objectively evaluate competing solutions and assess the technical viability of trade off options.” 2 Figure 3 depicts how CED’s both are informed by the system engineering process and inform leadership of key relationships between capabilities and end items.

Automation Requirements

CED generation is a multi-disciplinary participatory activity. Critical discussion among program managers, system engineers, and both technical and operational subject matter experts contributes to the CED. Figure 4 depicts the results of a work session where the interrelationships (strings) of specific developments (note cards) are worked out and understood by a set of participants. While effective, employment of this approach is not an efficient use of time in the long-term due to the maintenance demands of manually placing note cards and string on a war room wall. Also, the product is not easily reproduced or copied to other media types.

At a minimum, the tool must be able to track relationships and changes, and graphically display an entire plan for achieving an Operational Capability such that the relationship of maturity of capability and time are clearly shown. All database variables listed below must be included.

Functionally, such a tool needs to:

  • Track capabilities, programs, and activities
  • Manage linkage across programs and fielding process
  • Provide multiple views (e.g., roll-up, timeline, functional, relational, etc.)
  • Provide a flexible and extensible database
  • Provide menu driven data entry capability and connection to the Integrated Digital Environment
  • Track risk and dependencies
  • Handle varying levels of classification
  • Provide network based access


The primary goal of the CED is to develop processes and tools to manage, track, and visualize the dependencies across time from desired warfighting capability, through system development, down to foundational S&T while considering the links between the following:

  • Strategy
  • Mission
  • Systems of Systems to perform missions
  • System components
  • Technological advancements and how they impact system performance
  • Warfare concepts and capabilities
  • Key performance parameters
  • Force Structure such as Carrier Strike Groups, Expeditionary Warfare Groups and/ or Tactical Ballistic Missile Defenses Groups
  • Network enabled systems and platforms and how the they relate
  • Systems installation and deployment plans
  • Full range of RDT&E (Research, Development, Test, and Evaluation)
  • Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel and Facilities (DOTMLPF) modifications and/or alternatives to achieving capability

The taxonomies, relationships, and tracking analysis shown in Figure 5 must be included.

Achieving this goal will ensure the application of System of Systems and Mission Engineering methodologies results in a better alignment of future RDT&E with warfighting needs.

Article Images

Figure 1. Systems Engineering "V"1 

Figure 2. Conceptual CED Model

Figure 3. How Capability Evolution Documents Fit in System Engineering Process

Figure 4. Manually Constructed CED

Article References

  1. Defense Acquisition Guidebook, Chapter 4 -- Systems Engineering, Defense Acquisition University

  2. Robert K. Garrett Jr., Steve Anderson, Neil T. Baron, and James D. Moreland Jr., Managing the Interstitials, a System of Systems Framework Suited for the Ballistic Missile Defense System, Journal of Systems Engineering, 2011