Definition: Concept development is a set of activities that are carried out early in the systems engineering life cycle to collect and prioritize operational needs and challenges, develop alternative concepts to meet the needs, and select a preferred one as the basis for subsequent system or capability development and implementation.
Keywords: analysis, concept, definition, development, exploration, requirements, systems engineering
MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to develop and agree on a working description and view of how the systems or capabilities to be developed will be used, how they will function in their expected environments, what top-level requirements they will satisfy, and what their high-level conceptual design will be. MITRE SEs are expected to be able to use a variety of approaches to elicit user needs and explore and assess alternative concepts to meet them, including prototypes (see the Competitive Prototyping article in the SEG's Acquisition Systems Engineering section) and experiments that involve users, developers, and integrators.
Concept development takes place early in the systems engineering life cycle. The success of the subsequent development of a system or capability can critically depend on the soundness of the foundation that is laid during the concept development stage. In their definitions of concept development, Kossiakoff et al.  describe concept development as consisting of needs analysis (valid need and practical approach), concept exploration (performance to meet the need, feasible cost-effective approach), and concept definition (key characteristics that balance capability, operational life, and cost).
The articles in this topic area describe concept development in terms of four activities that identify and characterize user needs:
- Operational Needs Assessment—The application of operational experience to identify and characterize gaps in existing capabilities that significantly impede achieving the mission area objectives.
- Concept of Operations—A description of a proposed system characteristic in terms of the needs it will fulfill, from a user's perspective.
- Operational Requirements—Statements that formally, unambiguously, and as completely as possible identify the essential capabilities and associated performance measures.
- High-Level Conceptual Definition—A clear description or model of the characteristics or attributes needed to address a specific set of requirements or capabilities.
MITRE SEs should understand that, like the environment, operational needs and requirements cannot be viewed as static. User needs change, their priorities change, and the technology to enable them changes. This means that requirements cannot be viewed as cast in concrete with subsequent systems engineering aligned to an inflexible baseline. Tradeoff analyses may be required more or less continuously to ensure that effective capabilities are delivered to meet users' immediate and evolving needs.
Many processes, methods, and tools are available for conducting concept development. Of critical importance are the initial questions that must be answered early to get the requirements elicitation done right. These questions apply whether you are developing a product (system, capability, or service) or an operational structure to employ the product. MITRE SEs must ask more than "who, what, where, when, why, and how." They must develop specific questions to address broader issues, such as:
- What are the current deficiencies and gaps?
- What are the external constraints?
- What are the real-world performance drivers?
- What are the operational, security, and support concepts?
- Is it feasible technically, economically, and in a timely manner?
- What are the associated external and interfacing activities?
- What happens if any of these questions cannot be answered?
The insight obtained from such questions will likely lead to a preferred concept to satisfy the end users' needs and provide a sound basis for development. MITRE SEs should seek out guidance on customer-specific elements and approaches (i.e., Air Force Concept Development and Exploration ).
Best Practices and Lessons Learned
Questions to ask (adapted from ):
To meet the need, have at least two alternative concepts been developed and evaluated? The purpose of alternatives is to stimulate thinking to find simpler, faster, or cheaper solutions.
What technologies does each concept depend on? Have they been critically assessed for maturity? Can other more mature technologies support the concepts? Several high-level government studies concluded that the development of risky new technology to support a major acquisition program is a leading contributor to cost and schedule overruns and failure to deliver. Increasingly, government departments and agencies are requiring mature technologies before allowing an acquisition program to go on contract.
Is the proposed solution right-sized economically? Would delivering 80 percent of the solution early be of greater value to accomplishing mission success? Beware of attempts to satisfy that last, lone requirement before getting capabilities to the users.
Have external interface concepts, requirements, and complexities, including dependencies on other programs, been identified and addressed? Are there one or more specific "in-hand" alternatives that will enable the concept to be negotiated or realized, particularly when the concept relies on capabilities to be delivered by third-party programs over which your program has no control or little influence? Complex, ill-defined external requirements and interfaces can be a major source of requirements instability during the development phase. This can be important when a system must operate in a system-of-systems environment.
Are concepts and requirements firmly tied to operational and mission success versus individual user/organization preferences? Achieving capabilities or demonstrating critical subsystems that transcend individual perspectives while meeting operational timelines is important in order to achieve service quickly and cost effectively and to begin the process of incremental improvements based on operational experience, needs, and capability evolutions.
References and Resources
- Kossiakoff, A., W. Sweet, S. Seymour, and S. Biemer, May 2011, Systems Engineering: Principles and Practice, 2nd Ed., Hoboken, N.J., John Wiley & Sons, Inc.
- Air Force Policy Directive 10-28, April 17, 2012, Air Force Concept Development and Experimentation.
Additional References and Resources
Air Force Studies Board Division on Engineering and Physical Sciences, 2008, Pre-Milestone A and Early-Phase Systems Engineering: A Retrospective Review and Benefits for Future Air Force Systems Acquisition.
International Organization for Standardization, 2015, "ISO/IEC/IEEE 15288:2015 Systems and software engineering—System life cycle processes."
Maier, M., and E. Rechtin, 2009, The Art of Systems Architecting, 3rd Ed., CRC Press.
Stevens, R., P. Brook, K. Jackson, and S. Arnold, 1998, Systems Engineering: Coping with Complexity, Prentice Hall.
The MITRE Corporation, September 1, 2007, "Concept Definition," MITRE Systems Engineering Competency Model, Section 2.1.