INCOSE Systems Engineering Handbook (4th edition)

The INCOSE Systems Engineering Handbook (4th edition) is the fourth edition of the systems engineering handbook that is developed and marketed by the International Council on Systems Engineering (INCOSE).

• Acquirer. The stakeholder that acquires or procures a product or service from a supplier.
• "‐ilities". The developmental, operational, and support requirements a program must address (named because they typically end in "ility" -- availability, maintainability, vulnerability, reliability, supportability, etc.).
• Acquisition logistics. Technical and management activities conducted to ensure supportability implications are considered early and throughout the acquisition process to minimize support costs and to provide the user with the resources to sustain the system in the field.
• Activity. A set of cohesive tasks of a process.
• Agile. Project execution methods can be described on a continuum from "adaptive" to "predictive." Agile methods exist on the "adaptive" side of this continuum, which is not the same as saying that agile methods are "unplanned" or "undisciplined".
• Agreement. The mutual acknowledgment of terms and conditions under which a working relationship is conducted.
• Architecture. (System) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (see ISO 42010).
• Baseline. The gate‐controlled step‐by‐step elaboration of business, budget, functional, performance, and physical characteristics, mutually agreed to by buyer and seller, and under formal change control. Baselines can be modified between formal decision gates by mutual consent through the change control process. An agreed‐to description of the attributes of a product at a point in time, which serves as a basis for defining change (AnSI/EIA‐649‐1998).
• Black box/white box. Black box represents an external view of the system (attributes). White box represents an internal view of the system (attributes and structure of the elements).
• Capability. An expression of a system, product, function, or process ability to achieve a specific objective under stated conditions.
• Commercial off‐the‐shelf (COTS). Commercial items that require no unique acquirer modifications or maintenance over the life cycle of the product to meet the needs of the procuring agency.
• Commonality. (Of a product line) refers to functional and nonfunctional characteristics that can be shared with all member products within a product line (ISO 26550 2nd Cd).
• Configuration. A characteristic of a system element, or project artifact, describing their maturity or performance.
• Configuration item (CI). A hardware, software, or composite item at any level in the system hierarchy designated for configuration management. (The system and each of its elements are individual CIs.) CIs have four common characteristics: 1. defined functionality 2. replaceable as an entity 3. Unique specification 4. formal control of form, fit, and function.
• Decision gate. A decision gate is an approval event (often associated with a review meeting). Entry and exit criteria are established for each decision gate; continuation beyond the decision gate is contingent on the agreement of decision makers.
• Derived requirements. detailed characteristics of the system of interest (SOI) that typically are identified during elicitation of stakeholder requirements, requirements analysis, trade studies, or validation.
• Design constraints. The boundary conditions, externally or internally imposed, for the SOI within which the organization must remain when executing the processes during the concept and development stages.
• Domain asset. Is the output of a subprocess of domain engineering that is reused for producing two or more products in a product line. A domain asset may be a variability model, an architectural design, a software component, a domain model, a requirements statement or specification, a plan, a test case, a process description, or any other element useful for producing products and services. Syn: domain artifact (ISO 26550 2nd Cd) Note: In systems engineering, domain assets may be subsystems or components to be reused in further system designs. Domain assets are considered through their original requirements and technical characteristics. Domain assets include, but are not limited to, use cases, logical principles, environmental behavioral data, and risks or opportunities learned from the previous projects domain assets are not physical products available off‐the‐shelf and ready for commissioning. Physical products (e.g., mechanical parts, electronic components, harnesses, optic lenses) are stored and managed according to the best practices of their respective disciplines Note: In software engineering, domain assets can include source or object code to be reused during the implementation Note: Domain assets have their own life cycles. ISO/IEC/IEEE 15288 may be used to manage a life cycle.
• Domain scoping. Identifies and bounds the functional domains that are important to an envisioned product line and provide sufficient reuse potential to justify the product line creation. domain scoping builds on the definitions of the product scoping (ISO 26550 2nd Cd).
• Element. See system element.
• Enabling system. A system that supports a SOI during its life cycle stages but does not necessarily contribute directly to its function during operation.
• Enterprise. A purposeful combination of interdependent resources that interact with each other to achieve buisness and operational goals (rebovich and White, 2011).
• Environment. The surroundings (natural or manmade) in which the SOI is utilized and supported or in which the system is being developed, produced, and retired.
• Facility. The physical means or equipment for facilitating the performance of an action, for example, buildings, instruments, and tools.
• Failure. The event in which any part of an item does not perform as required by its specification. The failure may occur at a value in excess of the minimum required in the specification, that is, past design limits or beyond the margin of safety.
• Functional configuration audit. An evaluation to ensure that the product meets baseline functional and performance capabilities (adapted from ISO/IEC/IEEE 15288).
• Human factors. The systematic application of relevant information about human abilities, characteristics, behavior, motivation, and performance. It includes principles and applications in the areas of human-related engineering, anthropometrics, ergonomics, job performance skills and aids, and human performance evaluation.
• Human systems integration. The interdisciplinary technical and management processes for integrating human considerations within and across all system elements; an essential enabler to SE practice.
• Interface. A shared boundary between two functional units, defined by functional characteristics, common physical interconnection characteristics, signal characteristics, or other characteristics, as appropriate (ISO 2382‐1).
• Integration definition for functional modeling (IDEF). A family of modeling languages in the fields of systems and software engineering that provide a multiple‐page (view) model of a system that depicts functions and information or product flow. Boxes illustrate IdEf0—functional modeling method • functions and arrows illustrate information and product flow (KBS, 2010). Alphanumeric coding is used to denote the view: •IdEf1—information modeling method •IdEf1x—data modeling method •IdEf3—process description capture method •IdEf4—object‐oriented design method •IdEf5—ontology description capture method.
• IPO diagram. Figures in this handbook that provide a high‐level view of the process of interest. The diagram summarizes the process activities and their inputs and outputs from/to external actors; some inputs are categorized as controls and enablers. A control governs the accomplishments of the process; an enabler is the means by which the process is performed.
• Life cycle cost (LCC). The total cost of acquisition and ownership of a system over its entire life. It includes all costs associated with the system and its use in the concept, development, production, utilization, support, and retirement stages.
• Life cycle model. A framework of processes and activities concerned with the life cycle, which also acts as a common reference for communication and understanding.
• Measures of effectiveness. Measures that define the information needs of the decision makers with respect to system effectiveness to meet operational expectations.
• Measures of performance. Measures that define the key performance characteristics the system should have when fielded and operated in its intended operating environment.
• N2 diagrams. Graphical representation used to define the internal operational relationships or external interfaces of the SOI.
• Operator. An individual who, or an organization that, contributes to the functionality of a system and draws on knowledge, skills, and procedures to contribute the function.
• Organization. Person or a group of people and facilities with an arrangement of responsibilities, authorities, and relationships (adapted from ISO 9001:2008).
• Performance. A quantitative measure characterizing a physical or functional attribute relating to the execution of a process, function, activity, or task; performance attributes include quantity (how many or how much), quality (how well), timeliness (how responsive, how frequent), and readiness (when, under which circumstances).
• Physical configuration audit. An evaluation to ensure that the operational system or product conforms to the operational and configuration documentation (adapted from ISO/IEC/ IEEE 15288).
• Process. A set of interrelated or interacting activities that transforms inputs into outputs (adapted from ISO 9001:2008).
• Product line. 1. Group of products or services sharing a common, managed set of features that satisfy specific needs of a selected market or mission. ISO/ IEC/IEEE 24765 (2010), Systems and software engineering vocabulary 2. A collection of systems that are potentially derivable from a single-domain architecture. IEEE 1517‐1999 (r2004) IEEE standard for information technology— Software life cycle processes— reuse processes (3.14) (ISO/IEC fCd 24765.5).
• Product line scoping. Defines the products that will constitute the product line and the major (externally visible) common and variable features among the products, analyzes the products from an economic point of view, and controls and schedules the development, production, and marketing of the product line and its products. Product management is primarily responsible for this process (ISO 26550 2nd Cd).
• Project. An endeavor with defined start and finish criteria undertaken to create a product or service in accordance with specified resources and requirements.
• Proof of concept. A naïve realization of an idea or technology to demonstrate its feasibility.
• Prototype. A production‐ready demonstration model developed under engineering supervision that is specification compliant and represents what manufacturing should replicate.
• Qualification limit. Proving that the design will survive in its intended environment with margin. The process includes testing and analyzing hardware and software configuration items to prove that the design will survive the anticipated accumulation of acceptance test environments, plus its expected handling, storage, and operational environments, plus a specified qualification margin.
• Requirement. A statement that identifies a system, product, or process characteristic or constraint, which is unambiguous, clear, unique, consistent, stand‐alone (not grouped), and verifiable, and is deemed necessary for stakeholder acceptability.
• Resource. An asset that is utilized or consumed during the execution of a process.
• Return on investment. Ratio of revenue from output (product or service) to development and production costs, which determines whether an organization benefits from performing an action to produce something (ISO/IEC 24765.5 fCd; ISO/IEC/IEEE 24765, 2010).
• Reuse. 1. The use of an asset in the solution of different problems. [IEEE 1517‐1999 (r2004)] 2. Building a software system at least partly from existing pieces to perform a new application. [ISO/IEC/ IEEE 24765 (2010)].
• Specialty engineering. Analysis of specific features of a system that requires special skills to identify requirements and assess their impact on the system life cycle.
• Stage. A period within the life cycle of an entity that relates to the state of its description or realization.
• Stakeholder. A party having a right, share, or claim in a system or in its possession of characteristics that meet that party’s needs and expectations.
• Supplier. An organization or an individual that enters into an agreement with the acquirer for the supply of a product or service.
• System. An integrated set of elements, subsystems, or assemblies that accomplish a defined objective. These elements include products (hardware, software, firmware), processes, people, information, techniques, facilities, services, and other support elements (InCOSE) A combination of interacting elements organized to achieve one or more stated purposes (ISO/IEC/IEEE 15288).
• System element. Member of a set of elements that constitutes a system.
• System life cycle. The evolution with time of a SOI from conception to retirement.
• System of interest. The system whose life cycle is under consideration.
• System of systems. A SOI whose system elements are themselves systems; typically, these entail large‐scale interdisciplinary problems with multiple, heterogeneous, distributed systems.
• Systems engineering. Systems engineering (SE) is 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, document ing requirements, and then proceeding with design synthesis and system validation while considering the complete problem: operations, cost and schedule, performance, training and support, test, manufacturing, and disposal. SE 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).
• Systems engineering effort. Systems engineering effort integrates multiple disciplines and specialty groups into a set of activities that proceed from concept to production and to operation. SE considers both the business and the technical needs of all stakeholders with the goal of providing a quality system that meets their needs.
• Systems engineering management plan (SEMP). Structured information describing how the systems engineering effort, in the form of tailored processes and activities, for one or more life cycle stages, will be managed and conducted in the organization for the actual project.
• Tailoring. The manner in which any selected issue is addressed in a particular project. Tailoring may be applied to various aspects of the project, including project documentation, processes and activities performed in each life cycle stage, the time and scope of reviews, analysis, and decision making consistent with all applicable statutory requirements.
• Technical performance measures. Measures that define attributes of a system element to determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal.
• Trade‐off. Decision‐making actions that select from various requirements and alternative solutions on the basis of net benefit to the stakeholders.
• User. Individual who or group that benefits from a system during its utilization.
• Validation. Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled (ISO/IEC/IEEE 15288) Note: Validation is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals, and objectives (i.e., meet stakeholder requirements) in the intended operational environment.
• Value. A measure of worth (e.g., benefit divided by cost) of a specific product or service by a customer, and potentially other stakeholders and is a function of (i) the product’s usefulness in satisfying a customer need, (ii) the relative importance of the need being satisfied, (iii) the availability of the product relative to when it is needed, and (iv) the cost of ownership to the customer (mcmanus, 2004).
• Variability. Of a product line refers to characteristics that may differ among members of the product line (ISO 26550 2nd Cd).
• Variability constraints. Denotes constraint relationships between a variant and a variation point, between two variants, and between two variation points (ISO 26550 2nd Cd).
• Verification. Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled (ISO/ IEC/IEEE 15288) Note: Verification is a set of activities that compares a system or system element against the required characteristics. This may include, but is not limited to, specified requirements, design description, and the system itself.
• Waste. Work that adds no value to the product or service in the eyes of the customer (Womack and Jones, 1996).