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
ContextConcept development takes place early in the systems engineering life cycle. The success of the subsequent development of a system or capability can be critically dependent on the soundness of the foundation that is laid during the concept development stage. In their definitions of concept development, Kossiakoff and Sweet [1] highlight phases 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).
In this guide, concept development is described as 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 are significant impediments to achieving the mission area objectives.
Concept of Operations——A description of a proposed system characteristics 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 systems engineers (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 change. This means that requirements cannot be viewed as cast-in-stone with subsequent system engineering aligned to an inflexible baseline. Trade-off analyses may be required more or less continuously to ensure effective capabilities are delivered to meet user's 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 developing a product (system, capability, or service) or an operational structure to employ the product. MITRE systems engineers 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 the questions above 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 systems engineers should seek out guidance on customer-specific elements and approaches (i.e., Air Force (AF) Concept Development) [2].
MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to develop and agree upon 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 their high-level conceptual design. 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
Questions to Ask (adapted from [1])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? Are there more mature technologies that can support the concepts? A number of 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 delivered early be of greater value to accomplishing mission success? Beware 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 for achieving service quickly and cost-effectively, and to begin the process of incremental improvements based on operational experience, needs, and capability evolutions.
References & ResourcesKossiakoff, A. and W. Sweet, 2003, Systems Engineering: Principles and Practice, Hoboken, NJ, John Wiley & Sons, Inc.
Air Force Policy Directive 10-28, September 15, 2003, AF Concept Developmen
No comments:
Post a Comment