Follow Us:

High-Level Conceptual Definition

Definition: High-level conceptual definition (HLCD) is the explicit construction of the ideas or concepts needed to understand what a system, product, or component is, what it does, and how it is best used. An HLCD is used by the operational users or, more generally, the stakeholder community. The HLCD may also address what a product is not, what it doesn't do, and how it is not well used. The HLCD reflects a shared point of view, conveying a clear description or model of the characteristic or attributes needed to address a specific set of requirements or capabilities.

Keywords: acquisition program, concept definition, concept development, early systems engineering

MITRE SE Roles & Expectations: MITRE systems engineers (SEs) are expected to develop or help develop a high-level conceptual definition during the concept development phase of system development. They are expected to assess the full breadth of the solution space (trade space) and to consider, refine, discard, or adopt alternative concepts. This assessment is useful as the life cycle continues into acquisition and development. It is a key input to performing the analysis of alternatives to support the acquisition approach (see Performing Analyses of Alternatives in this Guide). MITRE SEs are also expected to take operational requirements and translate them into a concept that provides the stakeholder community with a clear and unambiguous definition of the capability, system, product, or component. They are expected to use this concept definition to guide users in refining requirements, reconsidering the concept of operations or employment, and exploring fundamental implementation approaches. Techniques such as prototyping and experimentation with user community involvement can help highlight aspects of the trade space and illuminate alternatives for addressing user operational concepts and needs.

In developing an HLCD, MITRE SEs are expected to create a user-centered view that facilitates user/stakeholder discussion focused on further system requirements development and specification.

Background

The HLCD process, especially the concept definition, is a useful tool for establishing a common framework or construct early in the systems engineering and product development cycle. (Note: Don't refrain from including elements in the initial concept that may be beyond the scope of the system or product eventually specified. They may help stimulate thinking.) Though seemingly an obvious initial step in the solution development process and basic systems engineering, frequently the clear articulation of a high-level concept definition is omitted because it is believed that such a definition is implicit knowledge among the group (engineers, acquisition professionals, developers, integrators, users, etc.) or because a detailed design solution is "in hand," thus obviating the need for the higher-level composition.

Given the diverse experiences of a typical team, the assumption that even a small number of engineering, acquisition, development, and integration professionals share a common understanding of a complex system is likely to yield disappointing results. More often, engineering, acquisition, and user perspectives diverge at some point, and failure to tie solution development to a common view (the conceptual definition) may allow these differing ideas to go unchallenged and lead to significant disagreements and capability, schedule, and cost impacts later in the design cycle.

Proceeding directly to a more detailed design solution and bypassing an analysis of the trade space performed as an important step in developing the HLCD can lead to an expeditious, but inefficient solution. More effort and resources may eventually be expended to adapt the proposed solution to the user needs, due to discoveries late in the systems engineering process.

In either case, the result can be a solution requiring extensive rework to meet the basic user expectations—often at considerable cost and delivery delay.

Conceptual Definition Process

As part of the early life-cycle systems engineering process, HLCD uses the operational needs assessment, concept of operations (CONOPS), operational requirements, initial capability statements, articulated high-level stakeholder requirements, and an understanding of the domain to lay the foundation for a definition of user expectations and a further understanding of the solution space. The process of HLCD involves a set of steps for translating capability statements or operational requirements into a recognizable concept or model. The process begins by identifying the central capabilities or main objectives of the effort, and proceeds by organizing a set of descriptors aimed at helping illustrate critical attributes of the central objectives. Throughout this process, a deeper understanding of the users and their requirements is developed and captured in the outline or model that characterizes the concept definition; this will later support further system design.

The form this outline or model captures can vary, and depends on many factors, including the complexity of the concept and the breadth of the stakeholder community. One form of this outline or model is a conceptual definition map, shown below in Figure 1. This map helps the systems engineer explore a spectrum of factors that must be considered to fully chart user expectations and translate them into a concise definition.

Step-by-step considerations for completing this map (see Figure 1) include:

1. Begin by capturing the main objective(s) or necessary capabilities (green box). These concise statements explain the need, which is clearly defined from the user point of view. They are written for the broader stakeholder and acquisition (including systems engineering) communities.
2. Proceed to identify stakeholders and their roles and objectives (blue box). The MITRE SE will need to know or ascertain who will be involved in the various aspects of the whole solution across development, use, modification, and sustainment of the systems and capabilities supporting the objectives in Step 1. This step also identifies the stakeholder community that will use the concept definition as the basis for exploration of the solution space, and eventual decisions on program direction, acquisition, and further solution development.
3. Describe the key properties of the concept (orange box). These meaningful statements describe the basic properties of the concept so that the full stakeholder community can easily and uniformly understand the needs and objectives of the users.
4. Identify the products, information, or consumables required to meet user requirements (purple box). These items should tie into the needs of the user and stakeholder community and support the CONOPS and concept of employment.
5. Describe major technical, operational, and organizational interfaces (e.g., to other products, systems, domains, data/information, or communities) (yellow box). This portion of the map describes how the concept and user fit into the large enterprise or interact with other elements of the domain or mission area.
6. Articulate constraints (gray box). Describe all constraints, especially those that may help bound the solution space during later design evolution. In particular, cost or schedule constraints may be driving factors in defining the extent of possible future solutions. It is not the intent during this portion of the systems engineering process to eliminate specific solutions, but to express those constraints that may be critical in shaping the future solution.

Figure 1. Conceptual Definition Map

Lessons Learned

As with any element of systems engineering, potential hazards must be negotiated when applied to complex integrated systems. These include:

• Narrowing the solution space too quickly: Becoming too focused on a single approach, technology, or solution during concept definition and eliminating viable (and possibly better) alternatives early in the process.
• Narrowing the solution space too slowly: Too much exploration of alternative approaches, excessive waiting for technologies to mature, or working to an expectation of finding a solution that addresses all the consideration of all the stakeholders can lead to analysis paralysis and failure to deliver in a reasonable time period.
• Insufficient stakeholder engagement: Failing to fully engage the end-user/stakeholder community, and missing critical perspectives and inputs that might shape the final concept definition. In particular, be sure to engage those who are not immediate stakeholders (e.g., certification and accreditation authorities) whose considerations can be show-stoppers if they are engaged late in the process.
• Excluding non-materiel solutions: Beware of the inclination to narrow the focus of the high-level concept to materiel options, intentionally or unintentionally avoiding other elements of the possible solution including doctrine, training, operations, etc.

Finally, each concept definition phase provides a new opportunity to ensure a clear, understandable representation of the users' objectives and needs that are developed and vetted by the stakeholder community. A successful concept definition activity helps anchor the future design and engineering efforts, so that customer expectations and acquisition commitments are well managed from the beginning.

References & Resources

1. Kossiakoff, A. and W. Sweet, 2003, Systems Engineering: Principles and Practice, Hoboken, NJ: John Wiley and Sons, Inc.
2. Murch, R., 2001, Project Management: Best Practices for IT Professionals, Upper Saddle River, NJ: Prentice Hall PTR.