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.