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.

System Requirements Analysis – SEBOK (34)

The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements. (ISO/IEC 2008)

Activities of the process

Major activities and tasks during this process include

1. Analyze the stakeholder requirements to check completeness of expected services and operational scenarios (glossary), conditions, operational modes, and constraints.

2. Define the system requirements and their rationale.

3. Classify the system requirements using suggested classifications (see examples above).

4. Incorporate the derived requirements (coming from architecture and design) into the system requirements baseline.

5. Establish the upward traceability with the stakeholder needs and requirements.

6. Establish bi-directional traceability between requirements at adjacent levels of the system hierarchy.

7. Verify the quality and completeness of each system requirement and the consistency of the set of system requirements.

8. Validate the content and relevance of each system requirement against the set of stakeholder requirements.

9. Identify potential risks (or threats and hazards) that could be generated by the system requirements.

10. Synthesize, record, and manage the system requirements and potential associated risks.

11. Upon approval of the requirements, establish and control baselines along with the other system definition elements in conjunction with established configuration management practices.

Checking and Correctness of System Requirements

System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics which can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (above). Requirements can be further validated using the requirements elicitation and rationale capture described in section "Methods and Modeling Techniques" (below).

Requirements Elicitation and Prototyping

Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.

QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included so that all aspects of user needs are accounted for and prioritized.

Early prototyping can help the users and developers interactively identify functional and operational requirements and user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.

Capturing Requirements Rationale

One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database. (Hull, Jackson, and Dick 2010).

Presentation and Quality of Requirements

Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about syntax of requirements statements, wording (exclusions, representation of concepts, etc.), characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to (INCOSE 2010, Section 4.2.2.2) and (ISO/IEC 2011).

There are several characteristics of both requirements and sets of requirements that are used to aid the development of the requirements and to verify the implementation of requirements into the solution.

Characteristics of Individual Requirements. (SEBoK Original)

Necessary: The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.

Implementation Free: The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.

Unambiguous: The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.

Consistent: The requirement is free of conflicts with other requirements.

Complete: The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs.

Singular: The requirement statement includes only one requirement with no use of conjunctions. Feasible: The requirement is technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory).

Traceable: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or other source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specification or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.

Verifiable: The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.

Characteristics of a Set of Requirements. (SEBoK Original)

Complete The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set contains no to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies.

Consistent: The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicate. The same term is used for the same item in all requirements.

Affordable: The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory).

Bounded: The set of requirements maintains the identified scope for the intended solution without increasing beyond what is needed to satisfy user needs.

System Requirement

Statement that expresses an expected characteristic or a constraint using a semantic code (such as natural language, mathematical, arithmetic, geometrical expression). A system requirement is feasible, objective, and verifiable.

Rationale Argument that provides the justification for the selection of an engineering element.

Scenario A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.

Risk An event having a probability of occurrence and gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.

System Requirements – SEBOK (33)

System requirements are all of the requirements at the “system level” that have been properly translated from the list of stakeholders' requirements. System requirements form the basis of system architecture and design, verification, validation, and stakeholder acceptance. System requirements play major roles in the engineering activities

• as the essential inputs of the system architecture and design activities;

• as reference for the system validation activities; and

• as a communication means, between the various technical staff that interact within the project.

Definition and Purpose of Requirements

A requirement is a statement that identifies a product or process operational, functional, or design characteristic or constraint which is unambiguous, testable or measurable and necessary for product or process acceptability. (ISO/IEC 2007)

To avoid confusion in the multitude of terms around requirements, consider the following classifications:

• Process role or state: The role the requirement plays in the definition process; for instance, its position in the system block: translated, derived, satisfied; or its state of agreement: proposed, approved, cancelled.

• Level of abstraction: The level within the definition process for the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.

• Type of requirement: The nature of the requirement itself; for instance functional, performance, constraint, etc.

Requirements Management

Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes ensuring an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule.

There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to configuration management for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.

Assessment Types for a System Requirement. (SEBoK Original)

Direct Assignment The system requirement from the higher level is directly assigned to a system or a system element for a lower level (for example, the color used to paint visible parts of the product).

Indirect Assignment (Simply Decomposed) The system requirement is distributed across several systems or system elements, and the sum or a more complex calculation for distribution is equal to the requirement of higher level (for example, a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.

Indirect Assignment (Modeled and Decomposed) The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique, and the resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, a radar detection requirement may be analyzed; lower-level parameters for output power, beam size, frequencies, etc. will then be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.

Derived Requirement (from Design) Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.

Classification of System Requirements

Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods used.

Functional Requirements Describe qualitatively the system functions or tasks to be performed in operation.

Performance Requirements Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task.

Usability Requirements Define quality in use such as measurable effectiveness, efficiency, and satisfaction criteria.

Interface Requirements Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.

Operational Requirements Define operational conditions or properties under which the system is required to operate or exist. This type of requirement includes human factors and ergonomics, availability, maintainability, reliability, security.

Modes and/or States Requirements Define the various operational modes of the system in use and events conducting to transitions of modes.

Adaptability Requirements Define potential extension, growth, or scalability during the lift of the system.

Physical Constraints Define constraints on weight, volume, and dimension applicable on system elements that compose the system.

Design Constraints Define the limits on the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).

Environmental Conditions Define the environmental conditions to be encountered by the system in its different operational modes. Should be addressed the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environment (e.g. motion, shock, noise, electromagnetism, thermal, etc.), threats societal environment (e.g. legal, political, economic, social, business, etc.).

Logistical Requirements Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.

Policies and Regulations Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).

Cost and Schedule Constraints Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.

Architecture Definition – SEBOK (30)

System Architecture

Within the SE community, notions of architecture seem to have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with design as part of a single system life cycle process called “architectural design”. Although there are diverse viewpoints on architecture, the different perspectives have much in common. We consider systems engineering to cover all aspects of the creation of a system, including system architecture. The majority of interpretations of system architecture are based on the fairly intangible notion of structure – i.e. relationships between elements.

Some authors limit the types of structure considered to be architectural; say, for example, restricting themselves to functional and physical structure. Recent practice has extended consideration to include temporal and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).

While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice with potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group. (Wilkinson et al.2010, Wilkinson 2010).

System Design

In industrial practices, the term “design” is often used to mean both "architecture" and "design" as defined in the SEBoK. In the recent past, professionals used the term "design" when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of "system" in dealing with complexity.

The trend today is to consider system architecture and design as different sets of activities; attempts are made to define separate concurrent processes, but they are strongly intertwined:

• System design includes activities to conceive a system that answers an intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply traded-off system requirements.

• System design is the complete set of detailed models, properties or characteristics described into a form suitable for implementation.

• System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems.

The purpose of system design is to make the link between the system architecture and the implementation of technological system elements that compose the physical architecture of the system. These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities.

Transition from System Requirements to Physical Architecture

The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of logical architecture (glossary), then to allocate the elements of the logical architecture to system elements of candidate physical architectures.

Design decisions and technological solutions are selected according to performance criteria and non-functional requirements such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.). Creating intermediate models such as logical architecture models enables facilitation of the validation of functional, behavioral, temporal properties of the system against system requirements which have no major technological influence, and changing during the life of the system the physical interfaces or the technological layer without completely questioning the logical functioning of the system.

Iterations between Logical and Physical Architecture definition

Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model.

A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not taken before. Derived functions must, in their turn, be allocated to system elements. This, in turn, affects the physical architecture models.

Additional architecture and design iterations can produce an exhaustive and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can conduct to creation of new system requirements, called “derived requirements”.

Concept of Interface

The concept of interface is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function “send,” located in one system element, the function “receive,” located in the other one, and the function “carry,” performed by the physical interface which supports the input/output flow.

System Definition – SEBOK (31)

After the determination of the need for a new or modified system, system definition activities are conducted to describe the system in detail. The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected development cycle model. These consist of the definition of system requirements, the definition of the logical and physical system architecture, and system analysis. During and/or at the end of each iteration, gap analysis is performed to insure that all system requirements have been mapped to the architecture and design.

System definition activities build on the artifacts and decisions from concept definition, primarily the articulation of the mission of the system of interest (SoI), the needs and requirements of stakeholders, and preliminary operational concepts. The products of system definition activities (system requirements, architecture, etc.) are inputs to system realization. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized.

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics:

• System Requirements

• Architectural Design: Logical

• Architectural Design: Physical

• System Analysis

System Views and System Elements

To engineer a system, a set of engineering elements, characteristics, and properties have to be defined. These elements can be grouped in several views as follows:

• needs and requirements view,

• architecture view,

• boundary and interface view, or

• system breakdown view.

Each of these views is described in the following sections.

Needs and Requirements View

The following characteristics provide a global understanding of the system in its context of use and seen as a black box:

• The purpose states the relevance of the system within the context of use.

• The mission expresses the set of services the system provides, the main and global transformation it performs, and how it fulfills a capability or need for the enterprise.

• The objectives are elements that quantify the mission as a set of measurable data related to space, time and effectiveness.

• The expression of the mission is generally an abstraction of a set of actions performed by the system within its context of use and under operational conditions. This set of actions is called operational scenario and describes how these actions are related to each other, as well as what they exchange with the elements of the context.

All these elements are refined iteratively until a comprehensive view of the system within its context is obtained. They are used to elicit needs, to define stakeholder requirements, then system requirements.

Architecture View

There are several architectural representations or views/models of the system:

1.- The logical architecture supports the logical operation of the system all along its life cycle, and includes as a minimum functional, behavioral, and temporal views/models. Operational scenarios refine the mission into a collection of functions and dynamic structures that describe how the mission is performed (behavior).

2.- The physical architecture is a set of system elements performing functions of the system. Those system elements can be either material or immaterial (e.g., equipments made of hardware, software and/or human roles).

The logical and physical representations of the system architecture are mapped onto each other. The interactions between system elements are defined by interfaces whose complexity strongly depends on the way the system architecture is defined.

Boundary and Interface View

Boundary of the system depends on what engineers include within the scope of the system and outside of it. This view encompasses

1.- Input-Output Flow (glossary) exchanged between the system and elements of its context of use (functional interface)

2.- Physical Interface (glossary) (physical connections) that support these exchanges.

Interactions are modeled and defined using operational scenarios.

System breakdown View

Facing the potential number of system elements that constitute the physical architecture, sets of system elements can be grouped to form systems. The decomposition of the SoI (highest level) may include several layers of systems (intermediate levels of systems) until technological system elements (lowest level) are defined. Any layer of the decomposition may include systems and non-decomposable technological system elements.

Because a system element is primarily a system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive.

Top-down and recursive approach to system decomposition

System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form a system breakdown structure (SBS). For project management purposes, every system of the SBS may be included in a "building block", a notion introduced in (ANSI/EIA 1998), also called "system block".

Stakeholder requirements and system requirements exist at all layers of the SBS. In (ISO/IEC. 2011), these layers are known as levels of abstraction. Along with systematically introducing layers of systems, the architecture and design process manages the transformation of system requirements through levels of abstraction.

Stakeholder Needs and Requirements – SEBOK (30)

Stakeholder requirements (glossary) represent the views of users, acquirers, and customers regarding the problem (or opportunity), through a set of requirements for a solution that can provide the services needed by the stakeholders in a defined environment. This topic provides knowledge about the idea of stakeholder needs and requirements and the activities necessary to identify and prioritize the needs of the stakeholder(s), as well as transform those needs into stakeholder requirements. The definition of the set of stakeholder requirements is the primary outcome of these activities, and these requirements then feed into the next phase of the systems engineering (SE) process of system definition.

It is assumed that the definition of the problem or the issue to be solved and/or the opportunity for developing a new solution or improving a system of interest (SoI) has been done prior to starting the activities necessary to define stakeholder needs and requirements. This means that the context of use of the new or modified mission, operation, or capability has been characterized (see the Mission Analysis topic).

Purpose and Definition

The purpose of defining stakeholder requirements is to elicit a set of needs related to a new or changed mission for an enterprise (see Mission Analysis (MA) for information relevant to identifying and defining the mission or operation), and to transform these needs into clear, concise, and verifiable stakeholder requirements.

Stakeholder needs analysis is the elicitation, communication, validation (glossary) and refinement of the needs and objectives of the enterprise or set of stakeholders. Stakeholder needs analysis is aimed at understanding a potential capability (often identified through MA) that is needed to address an identified problem or opportunity. After defining the stakeholder needs and requirements, they interact with the MA to transform the defined set of needs into stakeholder requirements (also known as mission requirements) that reflect these needs.

From the Capture of Needs to the Definition of Stakeholder Requirements

There are:

• Real needs are those that lie behind any perceived needs (see below); they are conditioned by the context in which people live. As an example, a generic need could be the ability to “identify infectious diseases easily.” Often, real needs appear to be simple tasks.

• Perceived needs are based on a person’s awareness that something is wrong, that there is a lack of something, that there is something that could improve a situation, or that there are business, investment, or market opportunities. Perceived needs are often presented as a list of organized expectations resulting from an analysis of the usage conditions for the considered action (see the Mission Analysis topic). Following from the infectious disease example above, the real need might be perceived as a need to "carry out medical tests in particular circumstances (laboratories, points of care, hospitals, and/or human dispensaries).” Since the real need is seldom clearly expressed, richness of the knowledge of the perceived needs is used as a basis for potential solutions. This step has to be as complete as possible to cover all the contexts of use.

• Expressed needs originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. In the example, if safety is the primary concern, the expressed need to “protect the operator against contamination” may take priority over other expressed needs such as “assist in the execution of tests.” When determining the expressed needs, the analysis of the expected mission or services in terms of operational scenarios takes place.

• Retained needs are selected from the expressed needs. The selection process uses the prioritization of expressed needs to achieve something or make solutions feasible. The retained needs allow the consideration of potential solutions for a SoI. These retained “stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis, and possibly consistency and feasibility. Using the concept of operations to aid the understanding of the stakeholder intentions at the organizational level and the system operational concept from the system perspective, requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements” (ISO/IEC/IEEE 29148 2011). Characteristics of good requirements can be found in ISO/IEC/IEEE 29148 (2011). Exploration of potential solutions must start from this step. The various solutions suggested at this step are not yet products, but describe means of satisfying the stakeholder requirements. Each potential solution imposes constraints on the potential future SoI.

• Specified needs, generally called “system requirements (glossary),” are the translation of the stakeholder requirements to represent the views of the supplier, keeping in mind the potential, preferred, and feasible solutions. “The stakeholder requirements are then transformed into system requirements for the SoI, Consistent practice has shown this process requires iterative and recursive steps in parallel with other life cycle processes through the system design hierarchy. The recursive application of the processes will generate lower-level system element requirements.” (ISO/IEC/IEEE 29148 2011).

• Realized needs are the product, service or enterprise realized, taking into account every system requirement (and hence, the stakeholder requirement(s)). Each class of needs listed above aligns with an area of the SE process. For example, the development of "specified needs" requirements is discussed in the System Requirements topic. For more information on how requirements are used in the systems engineering process, please see the System Definition knowledge area (KA).

Identifying Stakeholders and their Requirements

Stakeholders of a SoI may vary throughout the life cycle. Thus, in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the life cycle when identifying the stakeholders or classes of stakeholders.

Every system has its own stages of life; these may include concept, development, production, operations, sustainment, and retirement (for more information, please see Life Cycle Models). For each stage, a list of all stakeholders having an interest in the future system is identified. The goal is to get every stakeholder’s point of view for every stage of the system life in order to consolidate a complete set of stakeholder needs that can be prioritized and transformed into the set of stakeholder requirements as exhaustively as possible.

Classification of Stakeholder Requirements

Several classifications of stakeholder requirements are possible, e.g. ISO/IEC 29148, section 9.4.2.3 (ISO/IEC 2011) provides a useful set of elements for classification. One possible way to classify the stakeholder requirements is:

Functional Sets of actions to perform the mission or operation of the system-of-interest; enhanced by effectiveness or performance characteristics attached to the mission or operations.

Operational This category may include:

• Operational concept that indicates the operational features to be provided without specifying design solutions;

• Operational scenarios describing the sequence or series of activities supported by the system-of-interest;

• Operational modes and transitions of modes between states/modes of the system-of-interest during its utilization to include dynamic interactions between the system-of-interest (viewed as a black box) and the system-of-interest's interface with external components in the context of its use.

Interface Matter, energy, or information flows exchanged between the system-of-interest and its external components in the context of its use, including physical interfaces.

Environmental External conditions affecting the system when in operation.

Utilization Characteristics The '-ilities' used to indicate conditions of the utilization of the system-of-interest (e.g. usability, dependability, security, etc.)

Human Factors Capabilities of users and operators, ergonomics, and associated constraints. Logistical Acquisition, transportation, and storage of elements needed by the system-of-interest to perform its services (e.g. constraints for logistical support).

Design and Realization Constraints Re-use of existing system elements or forbidden materials, for example.

Process Constraints: These are stakeholder, usually acquirer or user, requirements imposed through the contract or statement of work. These requirements do not directly address the end-item system, but rather how the end-item system is developed and provided.

Process requirements include compliance with national, state, or local laws, including environmental laws; administrative requirements; acquirer/supplier relationship requirements; and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work (SOW), and quality plans.

Project Constraints: Constraints to performing the project and/or the end-item system within cost and schedule.

Business Model Constraints: Constraints related to the expected business goal achieved by the system-of-interest, when this is relevant within the context of use; these may include geographic position (local, national, international) of the future product, service, or organization resulting from the system-of-interest, distribution channels, alliance and partnership, finance and revenue model etc.

Stakeholder Requirement

Necessity or desire expected by an end user, formally drafted and expressed in terms of a client and end user; service, objective, capability expected from the future system by the end users. Equivalent to expectation; includes user requirements.

Scenario: A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.

Risk: An event having a probability of occurrence and a gravity degree on its consequence onto the system mission or on other properties (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.

Mission Analysis – SEBOK (29)

The starting point of engineering any system-of-interest (SoI) is understanding the socio-economic and technological context in which potential problems or opportunities reside. The enterprise strategic goals and stakeholders’ needs, expectations, and requirements represent the problem or the opportunity from the viewpoint of users, acquirers, and customers.

Mission analysis (MA) is often performed iteratively with stakeholder needs and requirements generation to better understand the problem (or opportunity) space, as well as the solution space. The execution of this process enables a systems engineer to then establish a set of stakeholder requirements for a potential SoI, or other solution, that could provide a capability or service needed by the acquirer, the users, and the other stakeholders in a defined environment.

MA is part of the larger set of concept definition activities - the phase of systems engineering in which the problem space and the needs of the stakeholders are closely examined; this occurs before any formal definition of the (SoI) is developed. In fact, the activities of concept definition determine whether the enterprise strategic goals and stakeholder needs will be addressed by a new system, a change to an existing system, a service, an operational change or some other solution. Mission analysis focuses on the identification of the primary purpose(s) of the solution, while stakeholder needs and requirements definition explores what capabilities stakeholders desire and may include some detail on the performance of certain aspects of the solution.

The purpose of MA is to understand a mission/market problem or opportunity, analyze the solution space, and initiate the life cycle of a potential solution that could address the problem or take advantage of an opportunity. MA is a type of strategic or operations analysis related to needs, capability gaps, or opportunities and solutions that can be applied to any organization that evolves its strategy for its business objectives.

MA, in some domains called market analysis (glossary) or business analysis, is the identification, characterization, and assessment of an operational problem or opportunity within an enterprise. The definition of a mission need in a problem space frames the solution, both in terms of the direct application to the mission or business function, and in terms of the context for the resulting solution. MA is used to define needed (or desired) operational actions, not hardware/software functions; that is, it is focused on defining the problem space, not the solution space. It characterizes the operational need in terms of mission description/provisions and the environment/context, together with the proposed enterprise concept of operations (ConOps) and operational scenarios. The primary products of MA are the revised ConOps of the enterprise, the operational concept, the operational scenarios for the mission, and the context in which the solution will exist.

MA may include mathematical analysis, modeling, simulation, visualization, and other analytical tools to characterize the intended mission and determine how to best achieve the needs/objectives. MA evaluates alternative approaches to determine which best supports the stakeholder needs (among both materiel and non-materiel solution alternatives, also known as product solutions and service/operational solutions). Thus, MA defines the problem space and analyzes the solution space alternatives using quality attribute constraints driven by the enterprise objectives.

Mission Analysis and Concept of Operations

MA and the ConOps are broadly used in defense and aerospace organizations to analyze and define how a system is intended to operate, as well as how the major operations or operational scenarios are intended to be performed. They take into account the strategic, operational, and tactical aspects of the identified scenarios.

In order to determine appropriate technical solutions for evolving enterprise capabilities, systems engineering (SE) leaders interact with enterprise leaders and operations analysts to understand

• the enterprise ConOps and future mission, business, and operational (MBO) objectives;

• the characterization of the operational concept and objectives (i.e., constraints, mission or operational scenarios, tasks, resources, risks, assumptions, and related missions or operations); and

• how specific missions or operations are currently conducted and what gaps exist in those areas.

They then conceptually explore and select from alternative candidate solutions. This interaction ensures a full understanding of both the problem space and the solution space. The alternative candidate solutions can include a wide range of approaches to address the need, as well as variants for an approach to optimize specific characteristics (e.g., using a different distribution of satellite orbit parameters to maximize coverage or events while minimizing the number of satellites). Analysis, modeling and simulation, and trade studies are employed to select alternative approaches (NDIA 2010).

The ConOps, at the organization level, addresses the leadership's intended way of operating the organization. It may refer to the use of one or more systems (as black boxes) to forward the organization's goals and objectives. The ConOps document describes the organization's assumptions or intent in regard to an overall operation or series of operations within the business in regards to the system to be developed, existing systems, and possible future systems. This document is frequently embodied in long-range strategic plans and annual operational plans. The ConOps document serves as a basis for the organization to direct the overall characteristics of future business and systems. (ISO/IEC 2011)

In commercial sectors, MA is often primarily performed as market analysis. Wikipedia defines market analysis as a process that: . . . studies the attractiveness and the dynamics of a special market within a special industry. It is part of the industry analysis and this in turn of the global environmental analysis. Through all these analyses, the chances, strengths, weaknesses, and risks of a company can be identified. Finally, with the help of a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, adequate business strategies of a company will be defined. The market analysis is also known as a documented investigation of a market that is used to inform a firm's planning activities, particularly around decisions of inventory, purchase, work force expansion/contraction, facility expansion, purchases of capital equipment, promotional activities, and many other aspects of a company. (Wikipedia Contributors, 2012)

Mission Analysis as Part of Enterprise Strategy Development

Periodically, most enterprises re-evaluate their strategy with respect to their mission, vision, and positioning to accomplish their goals.

As the enterprise evolves the strategy, it is essential to conduct the supporting MA or strategic analysis for each element of the enterprise to determine readiness to achieve future objectives. This analysis examines the current state to identify any problems or opportunities related to the objective achievement and aids the enterprise in fully understanding and defining the problem space. The analysis examines the external environment and interfaces in search of impacts and trends, as well as the internal enterprise to gauge its capabilities and value stream gaps.

Additionally, a strengths, weaknesses, opportunities, and threats (SWOT) analysis may be performed. As the problem space is defined, the stakeholder needs are defined and transformed into stakeholder requirements that define the solutions needed. These requirements include those that address customer and mission needs, the future state of core processes and capabilities of the enterprise, and the enablers to support performance of those processes and capabilities. Finally, MA is engaged again to examine the solution space. Candidate solutions that span the potential solution space are identified, from simple operational changes to various system developments or modifications. Various techniques are applied to analyze the candidates, understand their feasibility and value, and select the best alternative.

Integration of Process and Product Models – SEBOK (28)

When performing systems engineering activities, it is important to consider the mutual relationship between processes and the desired system. The type of system (see Types of Systems) being produced will affect the needed processes, as indicated in system life cycle process drivers and choices. This may cause the tailoring (glossary) of defined processes as described in application of systems engineering standards.

Process and Product Models

The life cycle models introduced the perspective of viewing stage work products provided by process execution as versions of a system-of-interest (SoI) at various life stages. The fundamental changes that take place during the life cycle of any man-made system include definition, production, and utilization. Building upon these, it is useful to consider the structure of a generic process and product life cycle stage model.

The (T) model indicates a definition stage precedes a production stage where the implementation (acquisition, provisioning, or development) of two or more system elements has been accomplished. The system elements are integrated according to defined relationships into the SoI. Thus, both the process and product aspects are portrayed.

The implementation and integration processes are followed in providing the primary stage results—namely, in assembled system product or service instances. However, as noted in life cycle models, the definition of the SoI when provided in a development stage can also be the result of first versions of the system. For example, a prototype (glossary), which may be viewed as a form of production or pre-production stage. Following the production stage is a utilization stage. Further relevant stages can include support and retirement. Note that this model also displays the important distinction between definition versus implementation and integration.

According to ISO/IEC/IEEE 15288 (2008), this structure is generic for any type of man-made SoI to undergo life cycle management. The production stage thus becomes the focal point (T) at which system elements are implemented and integrated into system product or service instances based upon the definitions. For defined physical systems, this is the point at which product instances are manufactured and assembled (singularly or mass-produced). For non-physical systems, the implementation and integration processes are used in service preparation (establishment) prior to being instantiated to provide a service. For software systems, this is the point at which builds that combine software elements into versions, releases, or some other form of managed software product are produced.

Stage Execution Order

A sequential execution of life cycle stages is the most straightforward. Three are iterative forms, for which several variants can be extracted:

1. Iterative development is quite frequently deployed in order to assess stakeholder requirements, analyze the requirements, and develop a viable architectural design. Thus, it is typical that the concept stage may be revisited during the development stage. For systems where products are based upon physical structures (electronics, mechanics, chemicals, and so on), iteration after production has begun can involve significant costs and schedule delays. It is, therefore, important to get it "right" before going to production. The early stages are thus used to build confidence (verify and validate) that the solution works properly and will meet the needs of the stakeholders. Naturally, such an approach could be used for software and human activity systems as well; however, due to their soft nature, it can be useful to go further by experimenting and evaluating various configurations of the system.

2. Iterative development and implementation involves producing (defining, implementing, and integrating) various versions of the system, evaluating how well they meet stakeholder requirements, perhaps in the context of changing requirements, and then revisiting the concept and/or development stages. Such iterations are typical within software system development, where the cost of production is not as significant as for defined physical systems. A variant of this approach is the spiral model, where successive iterations fill in more detail (Boehm and May 1998). The use of this approach requires careful attention to issues related to baseline and configuration management. In this approach, significant verification (testing) should be performed on software systems in order to build confidence that the system delivered will meet stakeholder requirements.

3. Incremental or progressive acquisition involves releasing systems in the form of products and/or services to the consumers. This approach is appropriate when structural and capability (functions) changes are anticipated in a controlled manner after deployment. The use of this approach can be due to not knowing all of the requirements at the beginning, which leads to progressive acquisition/ deployment, or due to a decision to handle the complexity of the system and its utilization in increments—namely, incremental acquisition. These approaches are vital for complex systems in which software is a significant system element. Each increment involves revisiting the definition and production stages. The utilization of these approaches must be based upon well-defined, agreed relationships between the supplying and acquiring enterprises. In fact, the iteration associated with each resulting product and/or service instance may well be viewed as a joint project, with actor roles being provided by both enterprises.

In all of the approaches it is wise to use modeling and simulation techniques and related tools to assist in understanding the effect of changes made in the complex systems being life cycle managed. These techniques are typically deployed in the earlier stages; however, they can be used in gaining insight into the potential problems and opportunities associated with the latter stages of utilization and maintenance (for example, in understanding the required logistics and help-desk aspects).

Systems Engineering and Management – SEBOK (27)

Knowledge Areas

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The knowledge areas are:

• Life Cycle Models

• Concept Definition

• System Definition

• System Realization

• System Deployment and Use

• Systems Engineering Management

• Product and Service Life Management

• Systems Engineering Standards

Systems Engineering Definition

There is not community consensus on a single definition for "systems engineering"; the term has different connotations in different domains. However, one of the more commonly recognized definitions in the field is that of the International Council on Systems Engineering (INCOSE): An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:

• Operations

• Performance

• Test

• Manufacturing

• Cost & Schedule

• Training & Support

• Disposal

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (INCOSE 2012)

Process

A process is a series of actions or steps taken in order to achieve a particular end; as a verb it is the performing of the operations. Processes can be performed by humans or machines transforming inputs into outputs. In SEBoK processes are interpreted in several ways, including: technical, lifecycle, business, or manufacturing flow processes. Many of the Part 3 sections are structured along technical processes (e.g. design, verification); however, Life Cycle Models applies the concept at the high level of a program lifecycle sequence (e.g. rational unified process (RUP), Vee model, etc.).

Architecture

An architecture refers to the the organizational structure of a system, whereby the system can be defined in different contexts. Architecting is the art or practice of designing the structures. Architectures can apply for a system, product, enterprise, or service.

Frameworks are closely related to architectures, as they are ways of representing architectures. The terms Architecture Framework and Architectural Framework both refer to the same. Examples include: DoDAF, MoDAF, NAF for representing systems in defense applications, the TOGAF open group Architecture Framework, and the Federal Enterprise Architecture Framework (FEAF) for information technology acquisition, use and disposal.

Requirement

A requirement is something that is needed or wanted, but may not be compulsory in all circumstances. Requirements may refer to product or process characteristics or constraints. Different understandings of requirements are dependent on process state, level of abstraction, and type (e.g. functional, performance, constraint). An individual requirement may also have multiple interpretations over time. System Definition has further descriptions of requirements and their types (e.g. system requirement, stakeholder requirement, derived requirement). It discusses how different process roles/ states, levels, and the nature of requirements apply to the understanding of requirements.

Life Cycle Models

The life cycle model is one of the key concepts involved in systems engineering (SE). A life cycle (glossary) for a system (glossary) generally consists of a series of stages (glossary) regulated by a set of management decisions which confirm that the system is mature enough to leave one stage and enter another.

A Generic System Life Cycle Model

A life cycle model for a system identifies the major stages that the system goes through, from its inception to its retirement. The stages are culminated by decision gates, at which point the key stakeholders decide whether to proceed into the next stage, remain in the current stage, or terminate or re-scope related projects. Its inception begins with a set of stakeholders agreeing to the need for a system and exploring whether a new system can be developed, in which the life cycle benefits are worth the investments in the life cycle costs.

To be successful, most organizations must adapt to the need for “Competing on Internet Time” (Cusumano and Yoffee 1998), subsequently causing a need for rapid adaptation to unforeseen changes. This has caused many organizations to emphasize evolutionary development with emergent requirements as compared to a traditional development with a fixed set of requirements. Yet, there are still significant areas in which development driven by fixed requirements is appropriate.

The System Definition Stage begins with a decision by a protagonist individual or organization to invest resources in a new or improved system. It’s normally concurrent activities include: determining the system’s key stakeholders and their desired capabilities, developing the system’s concept of operations and business case, negotiating the system’s requirements among the key stakeholders, selecting the system’s non-developmental items (NDIs), developing the system’s architecture and systems-level life cycle plans, and performing system analysis in order to illustrate the compatibility and feasibility of the resulting system definition. There may be one or more intermediate decision gates within the definition stage. The transition into the system development stage can lead to either single-pass or multiple-pass development.

It should be noted that the system definition activities above constitute the major portion of the activities performed by systems engineers when performing systems engineering. Other activities include: prototyping or actual development of high-risk items to show evidence of system feasibility, collaboration with business analysts or performing mission effectiveness analyses to provide a viable business case for proceeding into development, and continuous improvement of the systems engineering process.

Analysis and Selection between Alternative Solutions – SEBOK (26)

This topic is part of the Systems Approach Applied to Engineered Systems Knowledge Area (KA). It describes knowledge related to the analysis and selection of a preferred solution from the possible options, which may have been proposed by Synthesizing Possible Solutions. Selected solution options may form the starting point for Implementing and Proving a Solution. Any of the activities described below may also need to be considered concurrently with other activities in the systems approach at a particular point in the life of a system-of-interest (SoI).

The activities described below should be considered in the context of the Overview of the Systems Approach topic at the start of this KA. The final topic in this KA, Applying the Systems Approach, considers the dynamic aspects of how these activities are used as part of the systems approach and how this relates in detail to elements of systems engineering (SE).

System Analysis

System analysis is an activity in the systems approach that evaluates one or more system artifacts created during the activities involved in Synthesizing Possible Solutions, such as:

• Defining assessment criteria based on the required properties and behavior of an identified problem or opportunity system situation.

• Accessing the properties and behavior of each candidate solution in comparison to the criteria.

• Comparing the assessments of the candidate solutions and identification of any that could resolve the problem or exploit the opportunities, along with the selection of candidates that should be further explored.

The problem context for an engineered system will include a logical or ideal system solution description. It is assumed that the solution that “best” matches the ideal one will be the most acceptable solution to the stakeholders. Note, as discussed below, the “best” solution should include an understanding of cost and risk, as well as effectiveness. The problem context may include a soft system conceptual model describing the logical elements of a system to resolve the problem situation and how these are perceived by different stakeholders (Checkland 1999). This soft context view will provide additional criteria for the analysis process, which may become the critical issue in selecting between two equally effective solution alternatives. Hence, analysis is often not a one-time process of solution selection; rather, it is used in combination with problem understanding and solution synthesis to progress towards a more complete understanding of problems and solutions over time.

Effectiveness Analysis

Effectiveness studies use the problem or opportunity system context as a starting point. The effectiveness of a synthesized system solution will include performance criteria associated with both the system’s primary and enabling functions. These are derived from the system’s purpose, in order to enable the realization of stakeholder needs in one or more, wider system contexts. For a service system or enterprise system the criteria will be more directly linked to the identified user needs or enterprise goals. Typical qualities for such systems include agility, resilience, flexibility, In addition to assessments of the absolute effectiveness of a given solution system, systems engineers must also be able to combine effectiveness with the limitations of cost and timescales included in the problem context. In general, the role of system analysis is to identify the proposed solutions which can provide some effectiveness within the cost and time allocated to any given iteration of the systems approach. If none of the solutions can deliver an effectiveness level that justifies the proposed investment, then it is necessary to return to the original framing of the problem. If at least one solution is assessed as sufficiently effective, then a choice between solutions can be proposed.

Systems Principles of System Analysis

From the discussions above, the following general principles of systems analysis can be defined:

1.- Systems analysis is an iterative activity consisting of trade studies made between various solution options from the systems synthesis activity.

2.- Systems analysis uses assessment criteria based upon a problem or opportunity system description.

3.- These criteria will be based around an ideal system description that assumes a hard system problem context can be defined.

4.- The criteria must consider required system behavior and properties of the complete solution in all of the possible wider system contexts and environments.

5.- Trade studies requires equal consideration to the primary system and the enabling system working as a single sytem to address the User need. These trades need to consider system requirements for Key Performance Parameters (KPPs), systems safety, security, and affordability across the entire life cycle

6.- This idea system description may be supported by soft system descriptions from which additional “soft” criteria may be defined (e.g., a stakeholder preference for or against certain kinds of solutions and relevant social, political, or cultural conventions to be considered in the likely solution environment, etc.).

7.- At a minimum, the assessment criteria should include the constraints on cost and time scales acceptable to stakeholders.

9.- A trade study should consider a “system of assessment criteria”, designating special attention to the limitations and dependencies between individual criteria.

10.- Trade studies need to deal with both objective and subjective criteria. Care must be taken to assess the sensitivity of the overall assessment to particular criteria.

Engineer System Context - SEBOK (25)

Engineered System Context

This article is part of the Systems Approach Applied to Engineered Systems knowledge area (KA). It describes knowledge related to the further expansion of the ideas of an engineered system and engineered system context that were introduced in the Systems Fundamentals KA.

The single most important principle of the systems approach is that it is applied to an engineered system context and not just to a single system (INCOSE 2012). The systems approach includes models and activities useful for the understanding, creation, use, and sustainment of engineered systems to enable the realization of stakeholder needs.

Disciplines that use a systems approach (like systems engineering (SE)) consider an engineered system context that defines stakeholder needs, and look for the best ways to provide value by applying managed technical activities to one or more selected engineered systems of interest (SoI).

Engineered System of Interest

We use the idea of an engineered system context to define an engineered SoI and to capture and agree on the important relationships between it, the systems it works directly with, and any other systems with which it work. All applications of a systems approach (and hence of SE) are applied in a system context rather than only to an individual system.

Applying the System Context

For lower-level and less-complex systems, the WSoI can represent levels of a product system hierarchy. An example of this would be an engine management unit as part of an engine, or an engine as part of a car. The WSoI in a system context may encapsulate some aspects of SoS ideas for sufficiently complex (glossary) systems. In these cases, the WSoI represents a collection of systems with their own objectives and ownership with which the NSoI must cooperate with in working towards a shared goal.

Product System Context

A product system context would be one in which the SoI is the product itself. The wider system context for a product system can be a higher level of product hierarchy, a service, or an enterprise system that uses the product directly to help provide value to the user. A significant aspect of a product systems context is the clear statement of how the product is intended to be used and the ensures that this information is given to the acquirer upon delivery. The customer will be required to accept the system, typically through a formal process, agreeing not to go against the terms of use.

If a systems approach is applied to a product context, it is done with the purpose of engineering a narrow system product to be integrated and used in a wider system product hierarchy or to enable the delivery of a wider system service directly to a user by an enterprise. This view of the relationship between product and service is specific to product systems engineering. While some engineering of the acquirer's static service system may occur, it is done with a product focus. The definition of service system in a service systems engineering context describes a more dynamic view of service systems.

Service System Context

Services are activities that cause a transformation of the state of an entity (people, product, business, and region or nation) by mutually agreed terms between the service provider and the customer (Spohrer 2008). The distinction between service and a service system is discussed in the article Types of Systems.

A service system context is one in which the SoI is the service system. This SoI contains all of the technology, infrastructure, people, resources, etc. that are needed to enable the service. The WSoI describes the enterprise providing the service as well as its relationship with other services that are impact the success of the enterprise.

If a systems approach is applied to a service system, it is done with the purpose of engineering a service system to enable the outcomes required by an enterprise to satisfy its clients. When operating in the service system context, all options to provide the service must be considered, providing that they fit within the constraints of the enterprise. This will include interfaces to other services, people, and resources in the enterprise. If an option for providing the service makes use of existing products or resources within or outside of the enterprise, it must be ensured that they are available for this use and that this does not adversely affect other services. Part of getting the right service may require the negotiation of changes to the wider enterprise context, but this must be by agreement with the relevant authority.

For a service system, and also when considering the service system context, the value is realized only through service transactions. The end-user co-creates value at the time of the request to use the service. For example, to make a flight reservation using a smart phone, the service system is composed of many service system entities (the caller, the person called, the smart phone, the access network, the core Internet Protocol (IP) network, the Internet Service provider (ISP), the World Wide Web (WWW), data centers, etc. All these are necessary to enable the service. When a caller makes a reservation and then books the flight, the value has been created.

Enterprise System Context

An enterprise system context is one in which the SoI is the enterprise system. This system contains all of the technology, infrastructure, people, resources, etc. needed to enable the service. The WSoI describes the business environment within which the enterprise sits. It is to be noted that an enterprise context is not equivalent to an organization according to this definition. An enterprise includes not only the organizations that participate in it, but also the people, knowledge, and other assets, such as processes, principles, policies, practices, doctrines, theories, beliefs, facilities, land, and intellectual property that compose the enterprise. An enterprise may contain or employ service systems along with product systems.