Renovating the Requirements Process

Check back daily as we will be publishing the award-winning essays, here. 

Category: Acquisition Reform

Honorable Mention

“As the old problem-solving maxim goes, a problem well put is half solved.” – Dewey 1938

“If I had an hour to solve a problem, and my life depended on solving it, I would spend the first 55 minutes formulating the right questions.” – attributed to Albert Einstein

“We’re not just building systems anymore — we’re building systems of systems, with real humans, policies, constraints and edge cases. If you don’t define it, you can’t design it.” – Dr. Dan Powell, a former lead system engineer for the Australian Air Warfare Destroyer

Background

The current requirement development process, driven as much by law, regulation and precedent as by the operational need, often fails to communicate a clear vision of the operational challenge.  Lack of a succinct operational vision, elucidated with an equally clear set of integrated requirements, often results in a requirement document that is excessively long, drives up costs, inhibits innovation and often fails to deliver a timely and effective solution to the operational need. Additionally, requirement documents with many authors and containing large sections cut and pasted from previous solicitation inhibit clarity and result in overly complicated, nuanced, inconsistent and often contradictory requirements scattered throughout hundreds of pages. In the end, without a clear definition of the operational need and an unambiguous set of requirements, it is nearly impossible to create shared intent between the warfighter, acquisition official and contractor on the operational mission, the desired outcomes and the proposed solution. This approach does not set the conditions for the successful acquisition and timely fielding of a new capability. To address this requirements challenge, the acquisition community adopted a series of “new” approaches—system engineering, digital engineering, mission engineering, etc. —all of which are important and critical to different aspects of a successful project, but have not enabled the fundamental attributes of a successful project:

A clear, concise and shared understanding of intent by the warfighter, the acquisition official and the contractor on the operational mission objectives and the proposed solution. The ability to:

• Understand how changes to the mission objectives between issuing the RFP and fielding the capability impact the solution’s ultimate effectiveness.
• Make timely, risk-informed decisions on change proposals with respect to project cost, scope, schedule and operational impact when faced with changing operational requirements (the adversary’s vote).

A New Approach for Building Requirements: Definition Operations and Behavior Modeling

Definition Operations (DefOps) is a set of practices, supported by integrated models, that bridges the gap between understanding the operational intent to field a capability/system, and the definition, design, development/acquisition, integration, test, evaluation and sustainment activities relating to that capability/system.

DefOps gives leaders a foundational starting point for acquiring a new capability, one that connects intent, constraints, behaviors and structure into a single integrated model that everyone can understand. Behavior Modeling (BM) enables DefOps and brings an entirely new approach to mission engineering and the requirements development process; BM breaks down and describes the mission objectives in a manner that ensures shared understanding of intent by all involved parties of the operational challenge and connects these objectives directly to the proposed solution. The BM approach asks three questions:

• What do you want to do? – purpose, missions, objectives, desired outcomes, etc. (behaviors).
• How well do you want to do it? – measures of performance, quality, etc., (the “quality” of the behavior and its supporting structure).
• What is the environment in which you operate? – constraints such as policy, regulations, resources, laws of physics, rules of engagement, etc. (conditions that impact/influence the desired behavior and quality of performance).

BM integrates individual actions, interactions and exchanges, performed under known conditions and constraints (representing the operational environment), into concurrently composed end-to-end threads of behavior to achieve the desired effects with defined quality attributes. These behavior threads at different levels of abstraction represent mission threads, mission engineering threads, scenarios, vignettes, use cases, etc. The concurrent and branching threads of behaviors are composed into a Behavior Tree (BT). Implicit in the BM approach is ontological information identifying and relating actors/performers, activity/function/service, and the enabling resources and resource exchange requirements necessary to create the desired effect or behavior. The BT, in the form of a knowledge graph, represents the integration of operational, functional, service and resource/information architectures.

The BT/knowledge graph becomes an operational digital twin organizing the connections, relationships and constraints between the internal behaviors within a system/system-of-systems, the performers and enablers of that behavior, and the resultant effects to accomplish the operational mission.

BM does not directly evaluate the adequacy of any technology within the BT process per se, but rather, it assesses each node’s inputs from connected nodes (data streams, decision results, resources, etc.) and its behavior (its outputs) for connectivity, continuity and integration across and throughout the BT for each mission thread to produce the desired effects. During model construction, the underpinning algorithms in the modeling process assess the BT to identify internal issues: ambiguities, gaps, inconsistencies (particularly inconsistent vocabulary), risk and duplication. The issue identification capability enables the effective focus of management time and resources to resolve ambiguities, close gaps and understand risk. For those issues requiring more work, BM carries them forward through the process tracking as known uncertainties. In addition, the BM representation is human-readable by non-technical personnel, enabling the review and validation of the model and the mission threads by subject matter experts, mitigating the risk that the proposed solution will fail to capture the shared intent for achieving the mission objectives. Once the issues are resolved (or documented and accepted “as is”) and the model/mission threads validated, BM enables the synthesis of an integrated set of requirements that contains the providence of each requirement as well as a test plan to verify and validate each requirement in the provider’s proposed solution.

DefOps is a set of practices, supported by integrated models, that bridges the gap between understanding the operational intent to field a capability/system, and the definition, design, development/acquisition, integration, test, evaluation and sustainment activities relating to that capability/system. (Image courtesy of Dale A. Ormond)

As an example, to demonstrate the power of this approach, consider the following mission statement: Autonomously supply troops operating in a non-permissive environment.

The BM approach, which uses natural language inputs, requires the acquisition team to define each term and set the “conditions” to build the model. For example, possible information to “define” the terms might include:

• Autonomous; command and control, partial control, duration of autonomy, etc.
• Supply (what)?: food, parts, ammunition, water, etc.; how often? At what distances? Weight? Bulk? In what physical environment? etc.
• Troops: platoon, company, battalion, brigade? How many? Distribution in the AOR, etc.
• Operating (what are the troops doing): stationary, moving, under fire, rules of engagement, etc.
• Non-permissive: under fire, behind enemy lines, threats to resupply, etc.
• Environment: mountainous, desert, island, swamp, jungle, doctrine, policies, etc.

Using the terms, qualifiers, constraints and descriptions, BM builds a rich ontology of integrated, connected and tagged data for context and understanding the mission, and it creates a BT/knowledge graph, an architecture of connected behaviors. Each series of behaviors (mission threads) are assessed to gain “shared intent” and provide a framework to assess proposed solutions, both technical and tactical, for producing the effects needed to execute the mission.

Once the initial model is constructed, operators apply it to operational scenarios to flush out inaccuracies and poor assumptions, incorporate approved tactics, techniques and procedures (TTPs), identify the best approaches to create shared intent, set the requirements, understand the testing approach and prepare the procurement documentation to address the warfighter’s operational challenge. In addition, the operational scenario reviews enable the warfighter to begin the process for determining the Army’s DOT(M)L-PF requirements, essentially creating an integrated “Army” model for the actions and resources needed for fielding this material capability. Again, BM creates shared intent between the warfighter, acquisition official and contractor to get the operational capability in the hands of the warfighter.

The BM approach restores ownership of the technical baseline to the acquirer as it provides a single-view, human-readable description of each processing node, its connections to the different mission threads throughout the model and the required behaviors (effects) for mission success in plain language. It enables determination of where current technical solutions or TTPs are sufficient and when a new technical approach is required to close an identified uncertainty. If any operational objectives change during acquisition or after fielding, the impacts of the changes can be quickly determined on project requirements and proposed modifications developed for both acquisition and testing requirements. For the contractor/provider, BM provides a clear set of coherent and integrated requirements that removes subjectivity from the evaluation and acceptance processes and maximizes the opportunity for the provider’s ingenuity, within clearly stated requirements and constraints, to provide an innovative solution. In addition, this behavior-based digital twin is a living model ready to assess the impact of mission changes, new/emerging requirements, technology advancements, obsolescence, etc., on the fielded capability at any point in its life cycle.

Mission engineering begins with definition operations to attain a clear and shared understanding of the operational challenge. Behavior modeling enables DevOps by creating a BT, a knowledge graph, describing the architecture needed to integrate the necessary behaviors of the system or system-of-systems to produce the desired effect. By understanding the inputs and outputs throughout the BT, this modeling approach generates an integrated set of unambiguous, integrated and non-conflicting requirements for acquisition and associated tests to verify and validate that the contractor’s solution is fit for purpose and meets the operational need. In addition, by understanding the system’s collective performance, it sets the path for the warfighter to determine the external support requirements (DOTML-PF) to field the capability to the warfighter. This is mission engineering. Behavior modeling is the future for effective, integrated and comprehensive requirements development, the approach needed to renovate the requirements process for the next generation of Army acquisitions.

DALE A. ORMOND is a retired Department of War senior executive with over 35 years of federal service with the Navy, Energy, Army and OSD. An acquisition professional and DAWIA Certified Practitioner in program management and engineering and technical management, he served in several senior Army leadership positions including director of the U.S. Army Research, Development and Engineering Command. He retired in 2018.