The answer analysis method identifies the top-level components of a complex system

Systems are becoming increasingly complex requiring disparate domain specializations coming together to form a system-of-systems. Software is already ubiquitous in most engineered systems. Autonomous systems where advanced intelligent data driven high performance computing with deterministic real-time system control providing a heterogenous hardware-software ecosystem holds significant promise to revolutionize the way we engage in personal road mobility, handle logistics in warehouses, factories and yards, get services and products delivered to us through unmanned air or road systems, boost productivity in agriculture and construction and list goes on and on. These highly engineered products require a framework for systems design and analysis to design a system for effective use and maintenance. In this piece, I will introduce a 10-STEP system definition framework I have created that may be used in design and development of complex systems. It is a foundation framework for system design without dwelling into specialized sub-disciplines of design such as reliability engineering, systems safety engineering, maintainability engineering and so on. This foundational framework may be deployed using a variety of methodologies. I suggest potential methods for use with the possibility to scale them or devise alternatives based on your industry domain and relevant standards. I will provide only a brief description of each step in the framework without going into all details that may be involved in specific methods that the reader may research on their own. The focus in this piece is the left-leg of the System V development model that involves design definition and unit construction without dwelling into system integration and test evaluation on the right leg of the V.

STEP 1: Define the opportunity space from a user centered perspective.

Method: Concept of Operations, Use Case Diagrams, Capability Definition.

Opportunity space also referred to as the Problem space is a key first step in the framework. Everyone realizes engineers are interested in tinkering in the lab with hardware or hacking into code developing geeky solutions. This approach most often leads to a “tribal knowledge” of technology pieces without a clear or consistent understanding in the enterprise of how to deploy and commercialize these technology piece point solutions. The solution to this condition often found in enterprises is to develop a concept of operations or a business case with a charter and a clear definition of the problem space. Market needs or customer pain points must be addressed in such a document with even a Strengths, Weakness, Threats and Opportunities identification. The capabilities requested to be developed must clearly address the market space while keeping organizational roadmap of existing capabilities and projected capability growth perspective. Product strategy and business alignment must be clearly spelt out in such a document.

Use case diagrams are a great tool to describe user capabilities from a clear boundary of interacting user actors. The use case diagram may be described with an UML tool, clearly outlining how a stakeholder may use the system functions. The actors in a use case diagram does not necessarily have to be human users, they may be other technology systems, infrastructure etc.

Capability definition may be defined using natural language. Modeling capabilities may be used with tools employing frameworks such as DoDAF where capability definition constructs are built-in.

STEP 2: Define operational concept with a system-of-interest (SOI) and mission operating envelope.

 Method: AIAA standard (ANSI/AIAA G-043B-2018)

A clear system of interest boundary is important to define when defining complex systems. Very often in early technology life cycle stages, boundaries for systems capabilities are not clear. This leads to functionality creep, unnecessary redundancies, missed functionality requirements or may result in reliability and maintainability issues over the product life cycle. A system boundary provides clear scope for system design and development. It also provides a separation of concern in a large complex system-of-systems functionality. The system of interest encapsulates all capabilities of interest within a system. In large system-of-systems, it is useful to group logically cohesive capabilities together to create a composable architecture. Reducing complexity for a large complex system reduces cost for design and development but also helps reduce failure conditions resulting from “inside-out” or “outside-in” emergent behavior.

Operational concepts captures the context of operating mission scenarios the SOI is employed within. STEP 1 is used to describe how the system will be used with respect to external actors within constraints defined in mission scenarios. Operating envelopes including static and dynamic contexts with assumptions and limits are defined.

STEP 3: Define Intended Function (s) for the SOI

Method: Function definition in natural language, SysML block diagrams.

Intended function is a description of what the function is supposed to achieve with clear performance objectives at the system level. These performance objectives may be termed KPI’s (key performance indicators) or MoE’s (Measures of Effectiveness). MoE's are high level design targets with a technical orientation that directly tie to system operational capability and business targets. Intended function provide for system capability accounting for mission operating envelope. MoE's include quantitative constraints and parameters for mission operating envelopes identified in STEP 2.

STEP 4: Define a Boundary for SOI with interacting influences from the situational context.

Method: Sketch boundary diagram, contextual actors with specified influences.

Boundary diagrams are a great tool to clearly define a system boundary with interacting context influences. A boundary diagram may be employed at various levels of architectural abstraction and functionality. Boundary diagrams clearly sketch the interfaces and context coupling influences on a system function or subsystem function (sub-function).

STEP 5: Define a p-Diagram with inputs, desired objectives, noise factors, control factors and error states.

Method: Sketch p-diagram.

A p-diagram is a perfect tool to identify design control factors necessary to create robust systems. Like boundary diagrams, p-diagrams may be constructed for a function or sub-function at any layer of architecture. System inputs and desired function objectives or “ideal functions” are described. Perturbations or uncertainties that sensitize a system function that may diverge outputs from the ideal function are identified as noise factors. These deviations are error states or failure modes. Control design factors are devised to mitigate the risk of producing these error states.

A p-diagram may be used to design a function and sub-functions for robustness. It may be used as a first step for robust design and to develop design requirements at various layers in the system design definition. Further, p-diagram may be used as an input to risk analysis methods as part of inductive safety analysis such as systems or (component design) failure modes, effects and criticality analysis (FMECA, DFMEA).

STEP 6: Define system interface description.

Method: Interface Control Definition.

System interfaces are an obvious outgrowth of boundary, p-diagrams and of function definition. A clear interface control definition is required for system design. System interface control is used for exchange between different subsystems within a system within a single enterprise or may be used to exchange information between suppliers. Interface Control Definitions are often used as technical contractual specifications by an acquisition enterprise to its multi-tiered supplier network. Interfaces may be defined at various hierarchies from system and sub-system levels all the way down to component levels like computer hardware/software interfaces.

STEP 7: Decompose an Intended Function into hierarchical sub-Functions as Functional Architecture.

Method: Block hierarchy, Block Definition Diagram in SySML.

An intended function at the highest layer of system abstraction may be decomposed into various sub-system levels or sub-function levels in a reductionist manner. As systems are decomposed, analysis must be performed in the function chains to understand impact laterally and on higher layers of definition. This interaction may induce complexity and a rigorous approach to identify these interacting influences is necessary to define and evaluate complex systems. The right leg of the system V will formally perform system integration and verify interfaces. However a forward path of system analysis must be employed to design for system resilience with decomposition and informal design verification putting the blocks together.

STEP 8: Define specifications with performance metrics at system level (functional and non-functional).

Method: Specification in natural language, Measures of Performance (MoP), Data Flow Diagrams (DFD), SysML constructs BDD, Activity Diagrams, Sequence Diagrams.

Developing formal specifications is an integral part of formal system design process. Requirements driven engineering forms the basis of developing high integrity complex systems. In domain areas, where safety and reliability are of paramount importance, it is important to clearly define non-functional requirements and derive impact on functional specifications. Functional specifications play a key role in defining what the system function must perform and against what performance objectives. All functional requirements must be written with proper requirements writing best practices and it is ideal to standardize them across an enterprise or even cross a base of suppliers in a large-scale complex system development program. All verification and validation require well authored specifications that reflect functionality to be achieved. The functional specification must be accurate and complete. Both dimensions are important to achieve.

STEP 9: Define sub-function design requirements at all levels of hierarchy (sub-system level and component level).

 Method: Specification in natural language, Technical performance measures (TPM’s), UML for software systems employing component diagrams, class diagrams for structure and sequence diagrams for behavior.

A subsystem function or sub-function is a layer in hierarchy below system function layer or SOI. This functional hierarchy is in the realm of intermediate design. A level below the subsystem is the component hierarchy layer. At this layer, hardware or software detailed design must be specified. All the steps above must be kept in context and tools such as boundary and p-diagrams may be employed for very large subsystems while writing design specifications. Design specifications in detailed design must trace tightly to actual physical product as they go deeper down in design layers. At the component layers of system design, the design specifications must be complete and reflect hardware or software construction. Metrics at the system level must be traced to by technical performance measures at the sub-functions and component level designs.

STEP 10: Physical hardware construction or software construction with traceability to the STEPS above.

Method: Requirements Management tool linkages to digital hardware assemblies and software repositories.

Each atomic unit in physical hardware and software must be fulfilled by specifications from STEP 9. All sub-components in a hardware assembly or all software units must be traced to detailed design specifications. Requirements traceability matrices (RTM) or Cross validation matrices (CVM) may be employed to ensure physical construction coverage of specifications. 

What are the components of system analysis?

What is system analysis answer?

What are the methods used in system analysis?

What method of analysis breaks each component down into smaller and smaller components?