System Analysis - SEBOK (37)

System analysis allows developers to objectively carry out quantitative assessments of systems in order to select and/or update the most efficient system architecture and to generate derived engineering data. During engineering, assessments should be performed every time technical choices or decisions are made to determine compliance with system requirements.

System analysis provides a rigorous approach to technical decision-making. It is used to perform trade-off studies, and includes modeling and simulation, cost analysis, technical risks analysis, and effectiveness analysis.

Purpose and Principles of the Approach

The system analysis process is used to: (1) provide a rigorous basis for technical decision making, resolution of requirement conflicts, and assessment of alternative physical solutions (system elements and physical architectures); (2) determine progress in satisfying system requirements and derived requirements; (3) support risk management; and (4) ensure that decisions are made only after evaluating the cost, schedule, performance, and risk effects on the engineering or re-engineering of a system (ANSI/EIA 1998).

This process is also called the decision analysis process by NASA (2007, 1-360) and is used to help evaluate technical issues, alternatives, and their uncertainties to support decision-making. (See Decision Management for more details.). System analysis supports other system definition processes:

• Stakeholder requirements definition and system requirements definition processes use system analysis to solve issues relating to conflicts among the set of requirements; in particular, those related to costs, technical risks, and effectiveness (performances, operational conditions, and constraints). System requirements subject to high risks, or those which would require different architectures, are discussed.

• The Architectural Design: Logical and Architectural Design: Physical processes use it to assess characteristics or design properties of candidate logical and physical architectures, providing arguments for selecting the most efficient one in terms of costs, technical risks, and effectiveness (e.g., performances, dependability, human factors, etc.). Like any system definition process, the system analysis process is iterative. Each operation is carried out several times; each step improves the precision of analysis.

Activities of the Process

Major activities and tasks performed within this process include

• Planning the trade-off studies:

• Determine the number of candidate solutions to analyze, the methods and procedures to be used, the expected results (examples of objects to be selected: behavioral architecture/scenario, physical architecture, system element, etc.), and the justification items.

• Schedule the analyses according to the availability of models, engineering data (system requirements, design properties), skilled personnel, and procedures.

• Define the selection criteria model:

• Select the assessment criteria from non-functional requirements (performances, operational conditions, constraints, etc.), and/or from design properties.

• Sort and order the assessment criteria.

• Establish a scale of comparison for each assessment criterion, and weigh every assessment criterion according to its level of relative importance with the others.

• Identify candidate solutions, related models, and data.

• Assess candidate solutions using previously defined methods or procedures:

• Carry out costs analysis, technical risks analysis, and effectiveness analysis placing every candidate solution on every assessment criterion comparison scale.

• Score every candidate solution as an assessment score.

• Provide results to the calling process: assessment criteria, comparison scales, solutions’ scores, assessment selection, and possibly recommendations and related arguments.

Checking Correctness of System Analysis

The main items to be checked within system analysis in order to get validated arguments are

• Relevance of the models and data in the context of use of the system,

• Relevance of assessment criteria related to the context of use of the system,

• Reproducibility of simulation results and of calculations,

• Precision level of comparisons' scales,

• Confidence of estimates, and

• Sensitivity of solutions' scores related to assessment criteria weights.

See Ring, Eisner, and Maier (2010) for additional perspective.

Methods and Modeling Techniques

• General usage of models: Various types of models can be used in the context of system analysis:

• Physical models are scale models allowing simulation of physical phenomena. They are specific to each discipline; associated tools include mock-ups, vibration tables, test benches, prototypes, decompression chamber, wind tunnels, etc.

• Representation models are mainly used to simulate the behavior of a system. For example, enhanced functional flow block diagrams (eFFBDs), statecharts, state machine diagrams (based in systems modeling language (SysML)), etc.

• Analytical models are mainly used to establish values of estimates. We can consider the deterministic models and probabilistic models (also known as stochastic models) to be analytical in nature. Analytical models use equations or diagrams to approach the real operation of the system. They can be very simple (addition) to incredibly complicated (probabilistic distribution with several variables). • Use right models depending on the project progress

• At the beginning of the project, first studies use simple tools, allowing rough approximations which have the advantage of not requiring too much time and effort. These approximations are often sufficient to eliminate unrealistic or outgoing candidate solutions.

• Progressively with the progress of the project it is necessary to improve precision of data to compare the candidate solutions still competing. The work is more complicated if the level of innovation is high.

• A systems engineer alone cannot model a complex system; he has to be supported by skilled people from different disciplines involved.

• Specialist expertise: When the values of assessment criteria cannot be given in an objective or precise way, or because the subjective aspect is dominating, we can ask specialists for expertise. The estimates proceed in four steps:

1. Select interviewees to collect the opinion of qualified people for the considered field.

2. Draft a questionnaire; a precise questionnaire allows an easy analysis, but a questionnaire that is too closed risks the neglection of significant points.

3. Interview a limited number of specialists with the questionnaire, including an in-depth discussion to get precise opinions.

4. Analyze the data with several different people and compare their impressions until an agreement on a classification of assessment criteria and/or candidate solutions is reached.

Architectural Design: Physical – SEBOK (36)

The purpose of physical architecture definition (or design) is to create a physical, concrete solution that accommodates the logical architecture and satisfies and trades-off system requirements. Once a logical architecture is defined (see Architectural Design: Logical), concrete physical elements have to be identified that can support functional, behavioral, and temporal features as well as expected properties of the system deduced from non-functional system requirements (for example constraint of replacement of obsolescence, and/or continued product support).

A physical architecture is an arrangement of physical elements (system elements and physical interfaces) which provides the designed solution for a product, service, or enterprise. It is intended to satisfy logical architecture elements and system requirements (ISO/IEC 26702 2007). It is implementable through technological system elements. System requirements are allocated to both the logical and physical architectures. The global system architecture is assessed with system analysis and when achieved becomes the basis for system realization.

System Element, Physical Interface, and Physical Architecture

A system element is a discrete part of a system that can be implemented to fulfill design properties. A system element can be hardware, software, data, humans, processes (e.g., processes that provide a service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, and minerals), or any combination of these (ISO/IEC/IEEE 15288 2008). A physical interface binds two system elements together; this is similar to a link or a connector.

Types of System Elements and Physical Interfaces. (SEBoK Original)

System Element

• Hardware Parts (mechanics, electronics, electrical, plastic, chemical, etc.) - Operator Roles - Software Pieces

• Processes, data bases, procedures, etc. - Operator Roles - Software Applications - Corporate, direction, division, department, project, technical team, leader, etc. - IT Components

Physical Interface

Hardware parts, protocols, procedures, etc. Protocols, documents, etc. Protocols, procedures, documents, etc. A complex system composed of thousands of physical and/or intangible parts may be structured in several layers of systems and system elements. The number of elements in the decomposition of one system is limited to only a few, in order to facilitate the ease of mastering the system; a common guideline is "five plus or minus two" elements.

The purpose of the physical architecture definition (design) process is to define, select, and synthesize a system physical architecture which can support the logical architecture. A physical architecture will have specific properties designed to address stakeholder or environmental issues and satisfy system requirements.

Because of the evolution of the context of use or technological possibilities, the physical architecture which is composed of System Elements is supposed to change along the life cycle of the system in order for it to continue to perform its mission within the limits of its required effectiveness. Depending on whether or not evolution impacts logical architecture elements, allocations to system elements may change. A physical architecture is equipped with specific design properties (glossary) to continuously challenge the evolution.

Generic inputs include the selected logical architecture, system requirements, generic patterns and properties that designers identify and utilize to answer requirements, outcomes from system analysis, and feedback from system verification and system validation.

Generic outputs are the selected physical architecture, allocation matrix of functional elements to physical elements, traceability matrix with system requirements, stakeholder requirements of each system and system element composing the physical architecture, and rejected solutions.

Activities of the Process

Major activities and tasks to be performed during this process include the following:

Partition and allocate functional elements to system elements:

1.- Search for system elements or technologies able to perform functions and physical interfaces to carry input-output and control flows. Ensure system elements exist or can be engineered. Assess each potential system element using criteria deduced from design properties (themselves deduced from non-functional system requirements).

2.- Partition functional elements (functions, scenarios, input-outputs, triggers, etc.) using the given criteria and allocate partitioned sets to system elements (using the same criteria).

3.- When it is impossible to identify a system element that corresponds to a partitioned functional set, decompose the function until the identification of implementable system elements is possible.

4.- Check the compatibility of technologies and the compatibility of interfaces between selected system elements.

Model candidate physical architectures; for each candidate:

1.- Because partitioned sets of functions can be numerous, there are generally too many system elements. For defining controllable architectures, system elements have to be grouped into higher-level system elements known as (sub) systems.

2.- Constitute several different sets of (sub) systems corresponding to different combinations of elementary system elements. One set of (sub) systems plus one or several non-decomposable system elements form a candidate physical architecture of the considered system.

3.- Represent (using patterns) the physical architecture of each (sub) system connecting its system elements with physical Interfaces that carry input-output flows and triggers. Add physical interfaces as needed; in particular, add interfaces with external elements to the (sub) system.

4.- Represent the synthesized physical architecture of the considered system built from (sub) systems, non-decomposable system, and physical interfaces inherited from the physical architecture of (sub) systems.

5.- Equip the physical architecture with design properties such as modularity, evolution capability, adaptability to different environments, robustness, scalability, resistance to environmental conditions, etc.

6.- If possible, use executable architecture prototypes (e.g., hardware-software (HW-SW)-in-the-loop prototypes) for identifying potential deficiencies and correct the architecture as needed.

Assess physical architecture candidates and select the most suitable one:

1.- Constitute a decision model based on criteria deduced from non-functional requirements (effectiveness, environmental conditions, safety, human factors, cost, risks, etc.) and design properties (modularity, communication commonality, maintainability, etc.).

2.- Assess physical architecture candidates against the given criteria. Select the most suitable one by comparing scores and rationales to determine which candidate best matches the criteria. Use the system analysis process to perform assessments (see the System Analysis Topic).

Synthesize the selected physical architecture:

1.- Formalize physical elements and properties. Verify that system requirements are satisfied and that the solution is realistic.

2.- Identify the derived physical and functional elements created for the necessity of architecture and design and the corresponding system requirements.

3.- Establish traceability between system requirements and physical elements as well as allocate matrices between functional and physical elements.

Prepare for the acquisition of each system or non-decomposable system element:

1.- Define the system or system element’s mission and objectives from allocated functions and effectiveness.

2.- Define the stakeholder requirements (the concerned stakeholder being the current studied system).

3.- Establish traceability between these stakeholder requirements and elements of the studied system (in particular design properties). This allows traceability of requirements between two layers of systems.

Architectural Design: Logical – SEBOK (35)

The purpose of logical architecture definition (or design) is to work out the functionality and behavior of the system while in service. The logical architecture of a system is composed of a set of related technical concepts and principles that support the logical operation of the system. It is described with views corresponding to viewpoints, and as a minimum, includes a functional architecture view, a behavioral architecture view, and a temporal architecture view.

Functional Architecture View

A functional architecture is a set of functions and their sub-functions that defines the transformations performed by the system to achieve its mission.

Function and Input-Output Flow - A function is an action that transforms inputs and generates outputs, involving data, materials, and/or energies. These inputs and outputs are the flow items exchanged between functions. The general mathematic notation of a function is y = ƒ(x,t), in which y and x are Generally speaking, there are two kinds of functions:

1.- functions that are directly deduced from functional and interface requirements. These equations express the expected services of a system necessary to meet its system requirements and

2.- functions that are derived and issued from the alternative solutions of physical architecture and are dependent upon the result of the design; additionally, they rely upon on technology choice to implement the logical architecture elements.

Functional Hierarchy/Decomposition of Functions – At the highest level of a hierarchy, it is possible to represent a system as a unique, central function (defined as the system's mission) that in many ways is similar to a "black box" ("F0" in plan A-0). In order to understand in detail, what the system does, this "head-of-hierarchy" (F0) is broken down into sub-functions (F1, F2, F3, F4) grouped to form a sub-level of the hierarchy (plan A0), and so on. Functions of the last level of a functional hierarchy can be called leaf-functions (F21, F22, F23, F24 in plan A2). Hierarchies (or breakdowns) decompose a complex or global function into a set of functions for which physical solutions are known, feasible, or possible to imagine. But a static functional hierarchy does not represent well how the flows of inputs and outputs are exchanged.

Behavioral Architecture View

A behavioral architecture is an arrangement of functions and their sub-functions as well as interfaces (inputs and outputs) that defines the execution sequencing, conditions for control or data-flow, and performance level necessary to satisfy the system requirements (ISO/IEC 26702 2007). A behavioral architecture can be described as a set of inter-related scenarios of functions and/or operational modes.

Control (Trigger) - A control flow is an element that activates a function as a condition of its execution. The state of this element, or the condition it represents, activates or deactivates the function (or elements thereof). A control flow can be a signal or an event, such as a switch being moved to the “on” position, an alarm, a trigger, a temperature variation, or the push of a key on a keyboard.

Scenario (of Functions) - A scenario is a chain of functions performed as a sequence that synchronizes the functions between them by using their control flows to achieve a global transformation of inputs into outputs. A scenario of functions expresses the dynamic of an upper level function. A behavioral architecture is developed with considering both scenarios for each level of the functional hierarchy and for each level of the system hierarchy. When representing scenarios of functions and behavioral architectures it is appropriate to use modeling techniques using diagrams, such as functional flow block diagrams (FFBD) (Oliver, Kelliher, and Keegan 1997) or activity diagrams, developed with SysML (OMG 2010).

Operational Mode - A scenario of functions can be viewed by abstracting the transformation of inputs into outputs of each function and focusing on the active or non-active state of the function and its controls. This view is called a "scenario of modes" - a chain of modes performed as a sequence of transitions between the various modes of the system. The transition from one mode to another is triggered by the arrival of a control flow (event/trigger). An action (function) can be generated within a transition between two modes following the arrival of an event or a trigger.

Behavioral Patterns

When designing scenarios or behavioral architectures, architects may opt to recognize and use known models to represent the expected transformations and behaviors. Patterns are generic basic models that may be more or less sophisticated depending on the complexity of the treatment. A pattern can be represented with different notations. Behavioral design patterns are classified into several categories, which can be seen in the following examples:

• Basic patterns or constructs linking functions - such as sequence, iteration, selection, concurrence, multiple exits, loops with an exit, and replication.

• Complex patterns - such as monitoring a treatment, exchanging a message, man machine interfaces, modes monitoring, real-time monitoring of processes, queue management, and continuous monitoring with supervision.

• Failure detection, identification, and recovery (FDIR) patterns- such as passive redundancies, active redundancies, semi-active redundancies, and treatments with reduced performance.

Temporal Architecture View

A temporal architecture is a classification of the functions of a system that are derived according to the frequency level of execution. Temporal architecture includes the definition of synchronous and asynchronous aspects of functions. The decision monitoring that occurs inside a system follows the same temporal classification because the decisions are related to the monitoring of functions.

Temporal and Decisional Hierarchy Concept – Not every function of a system is performed at the same frequency. The frequencies change depending on the time and the manner in which the functions are started and executed. One must therefore consider several classes of performance. There are synchronous functions that are executed cyclically and asynchronous functions that are executed following the occurrence of an event or trigger.

To be more specific, "real-time" systems and "command-control" systems combine cyclical operations (synchronous) and factual aspects (asynchronous). Cyclical operations consist of sharing the execution of functions according to frequencies, which depend on either the constraints of capture or dispatching the input/output and control flows. Two types of asynchronous events can be distinguished:

• Disturbances on high frequencies - Decisions that are made at either the level they occur or one level above. The goal is to deter disturbances from affecting the low frequencies so that the system continues to achieve its mission objectives. This is the way to introduce exception operations, with the typical example relating to operations concerns, breakdowns, or failures.

• Changes happening on low frequencies - Decisions pertaining to changes that are made at the upper levels. The ultimate goal is to transmit them toward bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.