{"text_format":"2","workbook":"xls","n_sheets":13,"sheets":["Summary","Sources","ISO15288","EIA632v11d7","IEEE 100","IEEE 1220","RMODP","IDEF0","DERA","MethH","Spiby SS","SECMv8","All terms"],"not_rendered":{"charts":1,"images":0,"macros":0,"external_links":1,"defined_names":11,"comments":1,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"run_cost":"one","rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900","formulas":"cached_only"}

{"sheet":"Summary","index":0,"n_rows":41,"n_cols":3,"rows_kept":41,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["Summary of Comparison of Concept Model Draft 8 terms with mulitple other sources"]
[]
["Total number of definitions"]
["Total defs in SECM 8",null,66]
[]
["No ref",47]
["Compatible",0]
["Conflict",18]
["(single duff entry)",1]
[null,66]
{"$rows_empty":30}
["Julian Johnson, BAE SYSTEMS 7 Jan 2003"]

{"sheet":"Sources","index":1,"n_rows":18,"n_cols":3,"rows_kept":18,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["SOURCE/ID PREFIX","DOCUMENT","LOCATION"]
["IEEE 1220","IEEE 1220, 1999 (from INCOSE Concepts & Terms WG, 1998)","http://www.incose.org/stc/terminology.htm"]
["IEEE 100","IEEE 100, 1996 (from INCOSE Concepts & Terms WG, 1998)","http://www.incose.org/stc/terminology.htm"]
["RMODP","Open Distributed Processing Reference Model","http://community-ml.org/RM-ODP/index.html"]
["IDEF0","Language to model the decisions, actions, and activities of an organization or system; IDEF0 web site","http://www.idef.com/idef0.html"]
["DERA","GLOSSARY - Annex B, DERA Systems Engineering Practices Reference Model, 1997 ","http://www.incose.org/stc/SEGD12_2.htm"]
["MetaH","MetaH User’s Manual Version 1.27, 1998","http://www.htc.honeywell.com/metah/uguide.pdf "]
["EIA632v11d7","Processes for Engineering a System ANSI/EIA-632-1998 Version 1.1 DRAFT 7"]
["ISO15288","Systems Engineering — System Life Cycle Processes, Final Committee Draft, 2001"]
["SECMv8","Concept Model Semantic Dictionary 8th Draft","Concept Model Semantic Dictionary 8th Draft Partitioned 10_9_02.xls"]
["DICST90","Williamson, Mark; Dictionary of Space Technology.  Adam Hilger, Bristol and New York, 1990"]
["Janes86","Gunston, Bill: Jane's Aerospace Dictionary.  London, 1986"]
["DICST","Angelo, Jr., Joseph A.; The Dictionary of Space Technology.  Facts on File, Inc., New York, 1982 "]
["MDE","Graf, Rudolf F.; Modern Dictionary of Electronics, 7th Edition, Boston, 1999+C3"]
["DWOemail1","Oliver, David; Email,  DRAFT DEFINITIONS FOR AP233 ; May, 2001"]
["PLCSApr01","Dunford, John, et al, PLCS Combined Terms, April, 2001"]
["DWOemail2","Oliver, David; Email,  DRAFT DEFINITIONS FOR AP233 ; May, 2001; longer version"]
["Spiby SS","Original spreadsheet by Spiby & Nelson pulling together multiple sources for definitions","Semantic Dictionary AP233.xls"]

{"sheet":"ISO15288","index":2,"n_rows":24,"n_cols":4,"rows_kept":24,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ISO15288_1 ","acquirer","the stakeholder that acquires or procures a system, product or service, from a supplier","ref"]
["ISO15288_2 ","activity","a set of actions that consume time and resources and whose performance is necessary to achieve, or contribute to, the realization of one or more outcomes","[Based on IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology]"]
["ISO15288_3 ","agreement","the mutual acknowledgement of terms and conditions under which a working relationship is conducted","ref"]
["ISO15288_4 ","baseline","a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures","[IEEE 610 Standard Computer Dictionary]"]
["ISO15288_5 ","enabling system","a system that complements the system-of-interest during its life cycle stages","ref"]
["ISO15288_6 ","enterprise","that part of an organization with responsibility to acquire and to supply products and/or services according to agreements","ref"]
["ISO15288_7 ","facility","the physical means or equipment for facilitating the performance of an action, e.g. buildings, instruments, tools","ref"]
["ISO15288_8 ","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","ref"]
["ISO15288_9 ","operator","an individual or an organization who/that contributes to the functionality of a system and draws on knowledge, skills and/or procedures to contribute the function","ref"]
["ISO15288_10 ","process","set of interrelated activities which transform inputs to outputs","[ISO 9000: 2000]"]
["ISO15288_11 ","project","unique process, consisting of a set of co-ordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources","[ISO 9000: 2000]"]
["ISO15288_12 ","resource","an entity that is utilized or consumed during the execution of a process","ref"]
["ISO15288_13 ","stage","a period within the life cycle of a system that relates to the state of system description and/or the system itself","ref"]
["ISO15288_14 ","stakeholder","an interested party having a right, share or claim in the system or in its possession of characteristics that meet that party’s needs and/or expectations","ref"]
["ISO15288_15 ","supplier","an organization or an individual that enters into an agreement with the acquirer for the supply of a system, product or service","ref"]
["ISO15288_16 ","system","a combination of interacting elements organized to achieve one or more stated purposes","ref"]
["ISO15288_17 ","system element","any part of a system structure below the level of the current system","ref"]
["ISO15288_18 ","system entity","any part of a system, in part or whole","ref"]
["ISO15288_19 ","system-of-interest","the system whose life cycle is under consideration in the context of this International Standard","ref"]
["ISO15288_20 ","system life cycle","the evolution with time of the system from conception through to retirement","ref"]
["ISO15288_21 ","trade-off","decision-making actions that select from various requirements and alternative solutions on the basis of net benefit to the stakeholders","ref"]
["ISO15288_22 ","user","individual or group who/that benefits from the system-of-interest in an operational capacity","ref"]
["ISO15288_23 ","validation","confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled","[ISO 9000: 2000]"]
["ISO15288_24 ","verification","confirmation, through the provision of objective evidence, that specified requirements have been fulfilled","[ISO 9000: 2000]"]

{"sheet":"EIA632v11d7","index":3,"n_rows":61,"n_cols":3,"rows_kept":61,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition"]
["EIA632v11d7_1","acquirer"," An enterprise, organization, or individual that obtains a product (good or service) from a supplier.  "]
["EIA632v11d7_2","agreement"," An arrangement, not necessarily contractual, between two parties (an acquirer and a supplier) that defines the tasks to be performed, the items to be delivered, the acceptance criteria to be applied to delivered items, and other requirements affecting the development or procurement of system products."]
["EIA632v11d7_3","assign"," Designate a function, product, process, or other item as accountable for a particular purpose."]
["EIA632v11d7_4","associated processes"," Processes that enable one or more end products to be put into service, maintained in service, or retired from service."]
["EIA632v11d7_5","building block"," A representation of the conceptual framework of a system that is used for organizing the requirements, work, and other information associated with the engineering of a system.  An element in the structured decomposition of the system."]
["EIA632v11d7_6","configuration management","  A management process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational management information throughout its life. ReferenceANSI/EIA-649."]
["EIA632v11d7_7","constraint"," (1) A restriction, limit, or regulation imposed on a product, project, or process.   (2) A type of requirement or design feature that cannot be traded off."]
["EIA632v11d7_8","customer"," An individual, organization, or enterprise that (1) commissions the engineering of a system; (2) is a prospective purchaser of the end products of a system, or portions thereof; or (3) is an acquirer of a product."]
["EIA632v11d7_9","deliverable"," An item agreed to be delivered to an acquirer as specified in an agreement.  This item can be a document, a hardware item, a software item, a service, or any type of work product."]
["EIA632v11d7_10","derivative system"," A special type of precedented system derived from a previously operational system through the use of major elements, but whose requirements have been modified to meet new objectives."]
["EIA632v11d7_11","derived requirement"," (1) A requirement that is further refined from a primary source requirement or a higher-level derived requirement. (2) A requirement that results from a design decision for a logical or physical solution representation. "]
["EIA632v11d7_12","developer","An enterprise or organization that performs the process requirements of this Standard."]
["EIA632v11d7_13","development"," The action by which a set of requirements is translated into a solution definition for a set of products that satisfy stakeholders."]
["EIA632v11d7_14","document"," A collection of data, regardless of the medium on which it is recorded, that generally has permanence and can be read by humans or machines.  "]
["EIA632v11d7_15","effectiveness analysis"," An assessment of how well a product associated with an alternative logical, physical, or design solution is expected to perform or operate, given an anticipated usage scenario."]
["EIA632v11d7_16","enabling product"," Item that provides the means for a) getting an end product into service, b) keeping it in service, or c) ending its service."]
["EIA632v11d7_17","end product"," The portion of a system that performs the operational functions and is delivered to an acquirer."]
["EIA632v11d7_18","end product validation"," Confirmation by examination and provision of objective evidence that the specific intended use of an end product (developed or purchased), or an aggregation of end products, is accomplished in an intended usage environment."]
["EIA632v11d7_19","end product verification"," Confirmation by examination and provision of objective evidence that the specified requirements to which an end product is built, coded, or assembled have been fulfilled. "]
["EIA632v11d7_20","engineering life cycle"," A sequence of phases that evolves an instance of a system from a concept to a set of products consistent with the exit criteria established for an enterprise-based life cycle phase."]
["EIA632v11d7_21","engineering plan"," The plan for implementing the processes for engineering a system.  The engineering plan reflects an integrated technical effort that balances all factors associated with meeting life cycle requirements."]
["EIA632v11d7_22","enterprise","The entity that has governance over a set projects, or over organizations in which projects are carried out."]
["EIA632v11d7_23","enterprise-based life cycle"," The incremental progress of a system from conception through disposal, marked by management-established milestones with assigned exit criteria."]
["EIA632v11d7_24","environment"," (1) The natural conditions (weather, climate, ocean conditions, terrain, vegetation, dust, etc.) and induced conditions (electromagnetic interference, heat, vibration, etc.) that constrain the design definitions for end products and their enabling products. (2) External factors affecting an enterprise or project. (3) External factors affecting development tools, methods, or processes."]
["EIA632v11d7_25","function"," A task, action, or activity performed to achieve a desired outcome.  "]
["EIA632v11d7_26","functional requirement"," A requirement that defines what system products must do and their desired behavior in terms of an effect produced, or an action or service to be performed."]
["EIA632v11d7_27","information database"," A repository that provides a capacity to maintain work products and outcomes from implementation of the processes for engineering a system in a controlled manner."]
["EIA632v11d7_28","interface requirement"," A requirement that defines the conditions of interaction between items.  "]
["EIA632v11d7_29","layer of development"," (1) A level of abstraction as it relates to the system structure made up of building blocks. (2) A level of system decomposition."]
["EIA632v11d7_30","method"," Techniques that support implementation of process tasks.  "]
["EIA632v11d7_31","multidisciplinary teamwork"," The cooperative application of all appropriate disciplines by people functioning as a team to achieve solutions that balance the contributions of the disciplines effectively.  "]
["EIA632v11d7_32","normative"," That portion of a standard or specification that governs  implementation."]
["EIA632v11d7_33","operational scenario"," A sequence of events expected during operation of system products.  Includes the environmental conditions and usage rates as well as expected stimuli (inputs) and responses (outputs).  "]
["EIA632v11d7_34","performance requirement"," A requirement that defines how well the system products are required to perform a function, along with the conditions under which the function is performed."]
["EIA632v11d7_35","precedented","An end product that is a legacy product undergoing modification or a product that the enterprise both has the expertise to make and has similar products already in the market place."]
["EIA632v11d7_36","process"," A set of interrelated tasks that, together, transform inputs into outputs."]
["EIA632v11d7_37","product"," (1) An item that consists of one or more of the followinghardware, software, firmware, facilities, data, materials, personnel, services, techniques, and processes. (2) A constituent part of a system.  "]
["EIA632v11d7_38","project"," A development effort consisting of both technical and management activities for the purpose of engineering a system.  "]
["EIA632v11d7_39","prototype"," A model (physical, electronic, digital, analytical, etc.) of a product built for the purpose of a) assessing the feasibility of a new or unfamiliar technology; b) assessing or mitigating technical risk; c) validating requirements; d) demonstrating critical features; e) verifying a product; f) validating a product; g) determining enabling product readiness; h) characterizing performance or product features; or i) discovering physical principles.  "]
["EIA632v11d7_40","requirement"," (1) Something that governs what, how well, and under what conditions a product will achieve a given purpose. (2) Normative elements that govern implementation of this Standard, including certain documents such as agreements, plans, or specifications. "]
["EIA632v11d7_41","requirements validation"," Confirmation by examination that requirements (individually and as a set) are well formulated and are usable for intended use. "]
["EIA632v11d7_42","risk"," (1) A measure combining the uncertainty of reaching a goal with the consequences of failing to reach the goal. (2) The probability of suffering injury or loss."]
["EIA632v11d7_43","risk aversion"," The act of averting risk.  Averting risk can be through various means mitigation, avoidance, transfer, or acceptance."]
["EIA632v11d7_44","risk management"," An organized process for identifying and assessing risks, and for implementing means to avoid them or mitigate their effect if they occur.  "]
["EIA632v11d7_45","specification"," A document that contains specified requirements for a product and the means to be used to determine that the product satisfies these requirements.  "]
["EIA632v11d7_46","stakeholder"," An enterprise, organization, or individual having an interest or a stake in the outcome of the engineering of a system.  "]
["EIA632v11d7_47","stakeholder requirement"," A requirement that represents what stakeholders of a system need or expect of the system products."]
["EIA632v11d7_48","standard"," A document that establishes engineering and technical requirements for products, processes, procedures, practices, and methods that have been decreed by authority or adopted by consensus."]
["EIA632v11d7_49","subsystem"," A grouping of items that perform a set of functions within a particular end product."]
["EIA632v11d7_50","supplier"," Provides a product (either end products, enabling products, or both) or a group of products to an acquirer.  The supplier (external or internal to the acquirer’s organization) can be a vendor that has a product that does not need development, or a developer that must develop the desired system product or products."]
["EIA632v11d7_51","system"," An aggregation of end products and enabling products to achieve a given purpose. "]
["EIA632v11d7_52","system technical requirement"," A requirement derived from one or more stakeholder requirements and stated in technical terms."]
["EIA632v11d7_53","technical performance measurement"," (TPM) The technique of predicting the future value of a key technical parameter of the higher-level end product under development, based on current assessments of products lower in the system structure."]
["EIA632v11d7_54","technical review","  An event at which the progress of the technical effort is assessed relative to its governing plans and technical requirements.  "]
["EIA632v11d7_55","test article"," An item built, constructed, coded, or otherwise implemented, for checking conformance to specified requirements or for checking validation against acquirer requirements for the item."]
["EIA632v11d7_56","traceability","The ability to identify the relationship between various artifacts of the development process, i.e., the lineage of requirements, the relationship between a design decision and the affected requirements and design features, the assignment of requirements to design features, the relationship of test results to the original source of requirements."]
["EIA632v11d7_57","unprecedented","A specific end product that is not known a priori, or the enterprise has limited experience in developing this type of system."]
["EIA632v11d7_58","user"," Individual, organization, or enterprise that uses, applies, or operates system products."]
["EIA632v11d7_59","validation","See end product validation and requirements validation."]
["EIA632v11d7_60","verification","See end product verification."]

{"sheet":"IEEE 100","index":4,"n_rows":32,"n_cols":5,"rows_kept":32,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition",null,"MODULE"]
[" IEEE_100_1","architecture","A logical or physical representation of a product which depicts its structure, but, provides few or no implementation details."]
[" IEEE_100_2","assembly","An element of the physical or system architecture, specification tree, and system breakdown structure that is a subordinate element to a subsystem and is comprised of two or more components."]
[" IEEE_100_3","behavior","The analysis of the logical (stimulus/response) and physical (resource consumption, event timing, throughput etc.) execution of a system to assess the functional and physical."]
[" IEEE_100_4","change management","The process of evaluating the impact of a requirement or design change on the system, analyzing the effects of a proposed change in terms of the system foundation architecture, performance, costs, and schedule criteria."]
[" IEEE_100_5","component","An element of the physical or system architecture, specification tree, and system breakdown structure that is a subordinate element to an assembly and may be composed of two or more sub-components, or parts; or one or more subassemblies and their associated life-cycle processes."]
[" IEEE_100_6","design","The results of the synthesis process which provides sufficient details, drawings, or other pertinent information for a physical element that permits further development; or fabrication, assembly, and integration; or production of a product."]
[" IEEE_100_7","design architecture","The arrangement of elements or components, their decomposition, interfaces (internal and external), and physical constraints, which form the basis of a system design."]
[" IEEE_100_8","effectiveness measure","(measure of effectiveness) The figure-of-merit which provide a quantitative means for comparing alternative system solutions."]
[" IEEE_100_9","environment","The natural (weather, climate, ocean conditions, terrain, vegetation, dust, etc.) and induced (electromagnetic, interference, heat, vibration, etc.) conditions which constrain the design solutions for consumer products and their life-cycle processes."]
[" IEEE_100_10","environment","The natural conditions (weather, climate, ocean conditions, terrain, vegetation, dust, etc.) which define the utilization environment in which the system will be expected to operate within."]
[" IEEE_100_11","external system","The system or product interfaces to other systems, communication networks, power supplies, resource connectors, etc., which affect the design of the product under consideration."]
[" IEEE_100_12","external system interface","The system or product interfaces to other systems, platforms, or products which influence the design solutions for consumer products and their life-cycle processes."]
[" IEEE_100_13","function","A task, action or activity that must be accomplished to achieve a desired outcome, or to provide a desired capability."]
[" IEEE_100_14","functional architecture","The arrangement of functions, their decomposition, and interfaces (internal and external) which defines the execution sequencing, conditions for control or data flow, and the relative performance levels of achievement for a desired outcome, or for providing a desired capability."]
[" IEEE_100_15","functional architecture","An arrangement of functions and their sub-functions and interfaces (internal and external) which defines the execution sequencing, conditions for control or data-flow, and the performance requirements to satisfy the requirements baseline."]
[" IEEE_100_16","mode","An operating condition of a function or sub-function or physical element of the system."]
[" IEEE_100_17","part","The lowest element of a physical or system architecture, specification tree, or system breakdown structure that is not partitionable (bolt, nut, bracket, computer software unit)."]
[" IEEE_100_18","performance measure","(measure of performance) A performance measure that provides design requirements which are necessary to satisfy a measure of effectiveness."]
[" IEEE_100_19","physical architecture","An arrangement of physical elements which provides the design solution for a consumer product or life-cycle process intended to satisfy the requirements of the functional architecture and the requirements baseline."]
[" IEEE_100_20","physical characteristic","The physical design attributes or distinguishing features which pertain to a measurable description of a product or process."]
[" IEEE_100_21","physical element","A product, subsystem, assembly, component, sub-component, subassembly, or part of the physical architecture defined by its designs, interfaces (internal and external), and requirements (functional, performance, constraints, and physical characteristics)."]
[" IEEE_100_22","product","The result of a human, mechanical or natural effort or process, such as, a manufacturing process."]
[" IEEE_100_23","service","The delivery, installation, maintenance, training, and other labor intensive activities providing life-cycle support associated with the products and processes of the system."]
[" IEEE_100_24","specification","A document which fully describes a physical element or its interfaces in terms of requirements (functional, performance, constraints and physical characteristics) and the qualification conditions and procedures for each requirement."]
[" IEEE_100_25","subassembly","An element of the physical or system architecture, specification tree, and system breakdown structure that is subordinate to a complex component and is comprised of two or more sub-components."]
[" IEEE_100_26","subcomponent","An element of the physical or system architecture, specification tree, and system breakdown structure that is subordinate to a noncomplex component, or a subassembly, and is comprised of two or more parts."]
[" IEEE_100_27","subsystem","An element of the physical or system architecture, specification tree or system breakdown structure that is a subordinate element to a product and is comprised of one or more assemblies and their associated life-cycle processes."]
[" IEEE_100_28","system architecture","The composite of the physical architectures for consumer products and their life-cycle processes."]
[" IEEE_100_29","system design","The product of the development process which provides sufficient details, drawings, or other pertinent information, on the system components, elements, parts, interfaces, etc., to permit the fabrication, production, assembly, integration and testing of the system under development."]
[" IEEE_100_30","system element","A product, subsystem, assembly, component, sub-component, subassembly, or part of the system breakdown structure which includes the specifications, configuration baseline, budget, schedule, and work tasks."]
[" IEEE_100_31","system requirement","Provides a description of desired capabilities, constraints, and other details which pertain to the product's functional, performance, and physical characteristics."]

{"sheet":"IEEE 1220","index":5,"n_rows":20,"n_cols":3,"rows_kept":20,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition"]
["IEEE_1220_1","constraint","A limitation or implied requirement which constrains the design solution or implementation of the systems engineering process, is not changeable by the performing activity, and is generally non allocable."]
["IEEE_1220_2","development","The planning and execution of system and subsystem definition tasks required to evolve the system from customer needs to consumer product solutions and their life-cycle processes."]
["IEEE_1220_3","disposal","The tasks, actions, and activities to ensure that disposal or recycling of destroyed or irreparable consumer and life-cycle process products and by-products comply with applicable environmental regulations and directives."]
["IEEE_1220_4","distribution","The tasks, actions, and activities to initially transport, deliver, assemble, install, test, and checkout products to effect proper transition to users, operators, or consumers."]
["IEEE_1220_5","foundation architecture","The elements of the product design, including interfaces, which should be designed in such a manner that the adoption of new technologies or changes to the product design may be accomplished without major impacts to the system architecture."]
["IEEE_1220_6","interface","A contractual or area of responsibility boundary between/among systems and/or subsystems. (derived from interface specification)"]
["IEEE_1220_7","interface specification","The description of essential functional, performance, and design requirements and constraints at a common boundary between two or more system elements."]
["IEEE_1220_8","life cycle process","The eight essential functional processes (development, manufacturing, test, distribution, operations, support, training, disposal) that may be necessary to provide total consumer satisfaction and meet public acceptance. (abbrev)"]
["IEEE_1220_9","manufacturing","The tasks, actions, and activities for fabrication and assembly of engineering test models and brassboards, prototypes, and production of product solutions and their life cycle process products."]
["IEEE_1220_10","operations","The tasks, actions, and activities that are associated the use of the product or a life-cycle process."]
["IEEE_1220_11","part","The lowest element of a physical or system architecture, specification tree, or system breakdown structure that is not partitionable (bolt, nut, bracket, computer software unit)."]
["IEEE_1220_12","requirement","A statement which identifies a product or process limitation, capability, or physical characteristic."]
["IEEE_1220_13","state","A condition which characterizes the behavior of a function/sub-function or element at a point in time."]
["IEEE_1220_14","support","The tasks, actions, and activities to provide supply, maintenance, and support material and facility management for sustaining operations."]
["IEEE_1220_15","synthesis","The combining of information, concepts, constraints, components or elements to establish a complete and consistent system architecture, or to identify conflicts or deficiencies in established requirements or design solutions."]
["IEEE_1220_16","system","A set or arrangement of elements [people, products (hardware and software) and processes(facilities, equipment, material, and procedures)] that are related and whose behavior satisfies customer/operational needs, and provides for the life cycle sustainent of the products."]
["IEEE_1220_17","system architecture","The composite of the design architectures for products and their life cycle processes."]
["IEEE_1220_18","test","The tasks, actions, and activities for evaluating synthesis products against the functional architecture or requirements baseline, or the functional architecture against the requirements baseline."]
["IEEE_1220_19","training","The measurable tasks, actions, and activities (including instruction and applied exercises) required to achieve and maintain the knowledge, skills, and abilities necessary to efficiently and effectively perform operations, support, and disposal throughout the system life cycle."]

{"sheet":"RMODP","index":6,"n_rows":84,"n_cols":3,"rows_kept":84,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition"]
["RMODP_1","<X> Domain","A set of objects, each of which is related by a characterizing relationship <X> to a controlling object. Every domain has a controlling object associated with it. The controlling object can determine the identities of the collection of objects which comprises the associated domain. The controlling object may communicate with a controlled object dynamically or it may be considered to have communicated in an earlier epoch (see 10.5) of the controlling object. Generally, the controlling object is not a member of the associated domain."]
["RMODP_2","<X> Group","A set of objects with a particular characterizing relationship <X>. The relationship <X> characterizes either the structural relationship among objects or an expected common behaviour of the objects."]
["RMODP_3","<X> Template","The specification of the common features of a collection of <X>s in sufficient detail that an <X> can be instantiated using it. <X> can be anything that has a type (see 9.7). An <X> template is an abstraction of a collection of <X>s. A template may specify parameters to be bound at instantiation time. The definition given here is generic; the precise form of a template will depend on the specification technique used. The parameter types (where applicable) will also depend on the specification technique used. Templates may be combined according to some calculus. The precise form of template combination will depend on the specification language used."]
["RMODP_4","Abstraction","The process of suppressing irrelevant detail to establish a simplified model, or the result of that process."]
["RMODP_5","Action","Something which happens.  Every action of interest for modelling purposes is associated with at least one object.  The set of actions associated with an object is partitioned into internal actions and interactions. An internal action always takes place without the participation of the environment of the object. An interaction takes place with the participation of the environment of the object."]
["RMODP_6","Activity","A single-headed directed acyclic graph of actions, where occurrence of each action in the graph is made possible by the occurrence of all immediately preceding actions (i.e. by all adjacent actions which are closer to the head)."]
["RMODP_7","Architecture (of a system)","A set of rules to define the structure of a system and the interrelationships between its parts."]
["RMODP_8","Atomicity","An entity is atomic at a given level of abstraction if it cannot be subdivided at that level of abstraction.  Fixing a given level of abstraction may involve identifying which elements are atomic."]
["RMODP_9","Behaviour (of an object)","A collection of actions with a set of constraints on when they may occur.  The specification language in use determines the constraints which may be expressed. Constraints may include for example sequentiality, non-determinism, concurrency or real-time constraints.  A behaviour may include internal actions.  The actions that actually take place are restricted by the environment in which the object is placed."]
["RMODP_10","Behavioural compatibility","An object is behaviourally compatible with a second object with respect to a set of criteria (see notes) if the first object can replace the second object without the environment being able to notice the difference in the objects' behaviour on the basis of the set of criteria.<BR><BR>Typically, the criteria impose constraints on the allowed behaviour of the environment. If the criteria are such that the environment behaves as a tester for the original object, i.e. the environment defines the smallest behaviour that does not constrain the behaviour of the original object, the resulting behavioural compatibility relation is called extension.<BR><BR>The criteria may allow the replacement object to be derived by modification of an otherwise incompatible object in order that it should be an acceptable replacement. An example of such a modification might be hiding of additional parameters on certain interactions. In this way, an interaction of the new object can be made to look like an interaction of the original object. In such cases behavioural compatibility is called coerced behavioural compatibility. If no modification is necessary, behavioural compatibility is called natural behavioural compatibility.<BR><BR>The concept of behavioural compatibility defined above on objects applies equally well to the behavioural compatibility of templates and of template types.<BR><BR>Behavioural compatibility is reflexive, but not necessarily symmetric or transitive (though it may be either or both)."]
["RMODP_11","Binding","A contractual context, resulting from a given establishing behaviour.  Establishing behaviour, contractual context and enabled behaviour may involve just two object interfaces or more than two.  An object which initiates an establishing behaviour may or may not take part in the subsequent enabled behaviour.  Enabled behaviour (and, by analogy, contractual context) may be uniform (i.e. each participating object can do the same as every other) or non-uniform (i.e. one participating object has a different role from another, as in client and server).  There is no necessary correspondence between an object which initiates establishing behaviour and a particular role in non-uniform enabled behaviours (e.g. in a client-server contractual context, either object could validly have initiated the establishing behaviour)."]
["RMODP_12","Binding behaviour","An establishing behaviour between two or more interfaces (and hence between their supporting objects)."]
["RMODP_13","Binding precondition","A set of conditions required for the successful execution of a binding behaviour.  The objects performing the binding behaviour must possess identifiers for all the interfaces involved in the binding. There may be additional preconditions."]
["RMODP_14","Causality","Identification of causality allows the categorization of roles of interacting objects. This clause gives a basic set of roles. ~~br~~Causality implies a constraint on each behaviour of the participating objects while they are interacting. Causality will be identified in the definition of classes (or sub classes) to which interacting objects belong, or in the refinement of templates for their classes (or subclasses)."]
["RMODP_15","Chain (of actions)","A sequence of actions within an activity where, for each adjacent pair of actions, occurrence of the first action is necessary for the occurrence of the second action."]
["RMODP_16","Class (of <X>s)","The set of all <X>s satisfying a type (see 9.7). The elements of the set are referred to as members of the class."]
["RMODP_17","Client object","An object which requests that a function be performed by another object."]
["RMODP_18","Communication","The conveyance of information between two or more objects as a result of one or more interactions, possibly involving some intermediate objects."]
["RMODP_19","Composite object","An object expressed as a composition. "]
["RMODP_20","Composition","a) (of objects) A combination of two or more objects yielding a new object, at a different level of abstraction. The characteristics of the new object are determined by the objects being combined and by the way they are combined. The behaviour of a composite object is the corresponding composition of the behaviour of the component objects. b) (of behaviours) A combination of two or more behaviours yielding a new behaviour. The characteristics of the resulting behaviour are determined by the behaviours being combined and the way they are combined."]
["RMODP_21","Configuration (of objects)","A collection of objects able to interact at interfaces. A configuration determines the set of objects involved in each interaction. The specification of a configuration may be static or may be in terms of the operation of dynamic mechanisms which change the configuration, such as binding and unbinding (see 13.4)."]
["RMODP_22","Conformance point","A reference point at which behaviour may be observed for the purposes of conformance testing."]
["RMODP_23","Consumer object (with respect to communication)","An object which is a sink of the information conveyed.  The usage of this term does not imply any specific communication mechanism."]
["RMODP_24","Contractual behaviour","The concepts introduced here are illustrated in Figure 2."]
["RMODP_25","Contractual context","The knowledge that a particular contract is in place, and thus that a particular behaviour of a set of objects is required.  An object may be in a number of contractual contexts simultaneously; the behaviour is constrained to the intersection of the behaviours prescribed by each contractual context."]
["RMODP_26","Creation (of an <X>)","Instantiating an <X>, when it is achieved by an action of objects in the model. <X> can be anything that can be instantiated, in particular objects and interfaces. If <X> is an interface, it is either created as part of the creation of a given object, or as an additional interface to the creating object. As a result, any given interface must be part of an object."]
["RMODP_27","Data","The representation forms of information dealt with by information systems and users thereof."]
["RMODP_28","Decomposition","a) (of an object) The specification of a given object as a composition. b) (of a behaviour) The specification of a given behaviour as a composition. Composition and decomposition are dual terms and dual specification activities."]
["RMODP_29","Deletion (of an <X>)","The action of destroying an instantiated <X>. <X> can be anything that can be instantiated, in particular objects and interfaces. If <X> is an interface, it can only be deleted by the object to which it is associated."]
["RMODP_30","Derived class/base class","If a template A is an incremental modification of a template B, then the template class CA of instances of A is a derived class of the template class CB of instances of B, and the CB is a base class of CA.<BR><BR>The criteria for considering an arbitrary change to be an incremental modification would depend on metrics and conventions outside of this Recommendation | International Standard. If the criteria allow, a derived class may have several base classes.<BR><BR>The incremental modification relating templates must ensure that self-reference or recursion in the template of the base class becomes self-reference or recursion in the template of the derived class. <BR><BR>The incremental modification may, in general, involve adding to or altering the properties of the base template to obtain the derived template.<BR><BR>Classes can be arranged in an inheritance hierarchy according to derived class/base class relationships. This is the interpretation of inheritance in the ODP Reference Model. If classes can have several base classes, inheritance is said to be multiple. If the criteria prohibit suppression of properties from the base class, inheritance is said to be strict.<BR><BR>It is possible for one class to be a subclass of a second class without being a derived class, and to be a derived class without being a subclass. The inheritance hierarchy (where arcs denote the derived class relation) and the type hierarchy (where arcs denote the subtype or subclass relation) are therefore logically distinct, though they may coincide in whole or in part."]
["RMODP_31","Dividing action","An action which enables two or more chains.  There are two cases of a dividing action, depending on whether the enabled chains are required to join eventually."]
["RMODP_32","Enabled behaviour","The behaviour characterizing a set of objects which becomes possible as a result of establishing behaviour.  The enabled behaviour will not necessarily be the same for all objects."]
["RMODP_33","Entity","Any concrete or abstract thing of interest. While in general the word entity can be used to refer to anything, in the context of modelling it is reserved to refer to things in the universe of discourse being modelled."]
["RMODP_34","Environment (of an object)","The part of the model which is not part of that object."]
["RMODP_35","Epoch","A period of time for which an object displays a particular behaviour. Any one object is in a single epoch at one time, but interacting objects may be in different epochs at the time of interaction. A change of epoch may be associated with a change in the type of the object, so as to support type evolution. Alternatively, a change of epoch may be associated with a phase in the behaviour of an object of constant type. For a distributed system to function correctly, the objects composing its configuration must be consistent. Thus, as the whole system evolves through a series of epochs, the individual objects which interact must never be in epochs in which their behaviours are sufficiently different that their concurrent composition leads to a failure. This concept will support the formalization of concepts of version and extensibility."]
["RMODP_36","Error","Part of an object state which is liable to lead to failures. A manifestation of a fault (see 13.5.3) in an object."]
["RMODP_37","Establishing behaviour","The behaviour by which a given contract is put in place between given objects. An establishing behaviour can be  a) explicit, resulting from the interactions of objects that will take part in the contract; or  b) implicit, being performed by an external agency (e.g. a third party object, not taking part in the contract) or having been performed in a previous epoch."]
["RMODP_38","Failure","Violation of a contract."]
["RMODP_39","Fault","A situation that may cause errors to occur in an object."]
["RMODP_40","Forking action","A dividing action, where the enabled chains must (subject to failure) eventually join each other, i.e. the enabled chains cannot join other chains and they cannot terminate separately."]
["RMODP_41","Function","Expressed formally in terms of the specification of the behavior of objects, which they support.   The expression \"use of a function”, is a shorthand for the interaction with an object which performs the function."]
["RMODP_42","Head action","In a given activity, an action that has no predecessor."]
["RMODP_43","Information","Any kind of knowledge, that is exchangeable amongst users, about things, facts, concepts and so on, in a universe of discourse.  Although information will necessarily have a representation form to make it communicable, it is the interpretation of this representation (the meaning) that is relevant in the first place."]
["RMODP_44","Initiating object (with respect to a communication)","An object causing a communication."]
["RMODP_45","Instance (of a type)","An <X> that satisfies the type."]
["RMODP_46","Instantiation (of an <X> template)","An <X> produced from a given <X> template and other necessary information. This <X> exhibits the features specified in the <X> template. <X> can be anything that has a type (see 9.7). The definition given here is generic: how to instantiate an <X> template depends on the specification language used. Instantiating an <X> template may involve actualization of parameters, which may in turn involve instantiating other <X> templates or binding of existing interfaces (see 12.4)."]
["RMODP_47","Interaction point","A location at which there exists a set of interfaces .  At any given location in time, an interaction point is associated with a location in space, within the specificity allowed by the specification language in use. Several interaction points may exist at the same location. An interaction point may be mobile."]
["RMODP_48","Interface","An abstraction of the behaviour of an object that consists of a subset of the interactions of that object together with a set of constraints on when they may occur.  Each interaction of an object belongs to a unique interface. Thus the interfaces of an object form a partition of the interactions of that object."]
["RMODP_49","Interface signature","The set of action templates associated with the interactions of an interface. An object may have many interfaces with the same signature."]
["RMODP_50","Introduction (of an <X>)","Instantiating an <X> when it is not achieved by an action of objects in the model."]
["RMODP_51","Invariant","A predicate that a specification requires to be true for the entire life time of a set of objects."]
["RMODP_52","Joining action","An action shared between two or more chains resulting in a single chain."]
["RMODP_53","Liaison","The relationship between a set of objects which results from the performance of some establishing behaviour; the state of having a contractual context in common.  A liaison is characterized by the corresponding enabled behaviour."]
["RMODP_54","Location in space","An interval of arbitrary size in space at which an action can occur."]
["RMODP_55","Location in time","An interval of arbitrary size in time at which an action can occur."]
["RMODP_56","Object","A model of an entity. An object is characterized by its behaviour (see 8.6) and, dually, by its state (see 8.7). An object is distinct from any other object. An object is encapsulated, i.e. any change in its state can only occur as a result of an internal action or as a result of an interaction (see 8.3) with its environment (see 8.2). <BR><BR>An object interacts with its environment at its interaction points (see 8.11). <BR><BR>Depending on the viewpoint, the emphasis may be placed on behaviour or on state. When the emphasis is placed on behaviour, an object is informally said to perform functions and offer services (an object which makes a function available is said to offer a service). For modelling purposes, these functions and services are specified in terms of the behaviour of the object and of its interfaces (see 8.4). An object can perform more than one function. A function can be performed by the cooperation of several objects."]
["RMODP_57","Postcondition","A predicate that a specification requires to be true immediately after the occurrence of an action."]
["RMODP_58","Precondition","A predicate that a specification requires to be true for an action to occur."]
["RMODP_59","Producer object (with respect to communication)","An object which is the source of the information conveyed.  The usage of this term does not imply any specific communication mechanism."]
["RMODP_60","Proposition","An observable fact or state of affairs involving one or more entities, of which it is possible to assert or deny that it holds for those entities."]
["RMODP_61","Reference point","An interaction point defined in an architecture for selection as a conformance point in a specification which is compliant with that architecture. Significant classes of reference point are identified in ODP; details of these, and of the relationship of modelling to conformance, are given in clause 15."]
["RMODP_62","Refinement","The process of transforming one specification into a more detailed specification. The new specification can be referred to as a refinement of the original one. Specifications and their refinements typically do not coexist in the same system description. Precisely what is meant by a more detailed specification will depend on the chosen specification language. For each meaning of behavioural compatibility determined by some set of criteria (see 9.4), a specification technique will permit the definition of a refinement relationship. If template X refines a template Y, it will be possible to replace an object instantiated from Y by one instantiated from X in the set of environments determined by the selected definition of behavioural compatibility. Refinement relationships are not necessarily either symmetric or transitive."]
["RMODP_63","Responding object","An object taking part in a communication, which is not the initiating object."]
["RMODP_64","Role","Identifier for a behaviour, which may appear as a parameter in a template for a composite object, and which is associated with one of the component objects of the composite object. Specification of a template as a composition of roles enables the instantiation process to be explained as the association of a specific component of the resultant composite object with each role. The association of a component object with a role may result from the actualization of a parameter."]
["RMODP_65","Server object","An object which performs some function on behalf of a client object.  Client/server relationships of a different nature (or level of abstraction) may exist between an object and different compositions of the objects with which it communicates."]
["RMODP_66","Service","Expressed formally in terms of the specification of the behavior of the interfaces, which they support.  A particular abstraction of behavior expressing the guarantees offered by a service provider."]
["RMODP_67","Spawn action","A dividing action, where the enabled chains will not join. The enabled chains may interact and they may terminate separately."]
["RMODP_68","Stability","The property that an object has with respect to a given failure mode if it cannot exhibit that failure mode. "]
["RMODP_69","State (of an object)","At a given instant in time, the condition of an object that determines the set of all sequences of actions in which the object can take part.  Since, in general, behaviour includes many possible series of actions in which the object might take part, knowledge of state does not necessarily allow the prediction of the sequence of actions which will actually occur.  State changes are effected by actions; hence a state is partially determined by the previous actions in which the object took part.  Since an object is encapsulated, its state cannot be changed directly from the environment, but only indirectly as a result of the interactions in which the object takes part."]
["RMODP_70","Subactivity","A subgraph of an activity which is itself an activity and which satisfies the following condition. For any pair of fork-join actions in the parent acitivity, if one of these actions is included in the subgraph, then both must be included in the subgraph."]
["RMODP_71","Subclass/superclass","One class A is a subclass of another class B, and B is a superclass of A, precisely when the type associated with A is a subtype of the type associated with B."]
["RMODP_72","Subdomain","A domain which is a subset of a given domain."]
["RMODP_73","Subtype/supertype","A type A is a subtype of a type B, and B is a supertype of A, if every <X> which satisfies A also satisfies B. The subtype and supertype relations are reflexive, transitive and anti-symmetric."]
["RMODP_74","System","Something of interest as a whole or as comprised of parts. Therefore a system may be referred to as an entity. A component of a system may itself be a system, in which case it may be called a subsystem."]
["RMODP_75","Template class (of an <X>)","The set of all <X>s satisfying an <X> template type, i.e. the set of <X>s which are instances of the <X> template. <X> can be anything that has a type (see 9.7). Each template defines a single template class, so we may refer to instances of the template as instances of the template-class. The notion of class is used to refer to a general classification of <X>s. Template class is a more restrictive notion where the members of a template class are limited to those instantiated from the template (or any of its subtypes), i.e. those <X>s which satisfy the <X> template type."]
["RMODP_76","Template type (of an <X>)","A predicate defined in a template that holds for all the instantiations of the template and that expresses the requirements the instantiations of the template are intended to fulfill. The object template subtype/supertype relation does not necessarily coincide with behavioural compatibility. Instances of a template type need not be behaviourally compatible with instantiations of the associated template. They do coincide if a) a transitive behavioural compatibility relation is considered, and b) template subtypes are behaviourally compatible with their template supertypes."]
["RMODP_77","Terminating behaviour","The behaviour which breaks down a liaison and repudiates the corresponding contractual context and the corresponding contract.  A terminating behaviour must be explicitly identified as such in the contract if the establishing behaviour was explicit."]
["RMODP_78","Thread","A chain of actions, where at least one object participates in all the actions of the chain.  An object may have associated with it one single thread or many threads simultaneously."]
["RMODP_79","Trace","A record of an object's interactions, from its initial state to some other state. A trace of an object is thus a finite sequence of interactions. The behaviour uniquely determines the set of all possible traces, but not vice versa. A trace contains no record of an object's internal actions."]
["RMODP_80","Trading","The interaction between objects in which information about new or potential contracts is exchanged via a third party object. It involves:  a) exporting: the provision of an identifier to an interface which is claimed to meet some statement of requirements (i.e. offer a potential contract);  b) importing: the provision of an identifier to an interface which matches a given statement of requirements, allowing a future binding behaviour to take place (i.e. the establishment of a contract)."]
["RMODP_81","Type (of an <X>)","A predicate characterizing a collection of <X>s. An <X> is of the type, or satisfies the type, if the predicate holds for that <X>. A specification defines which of the terms it uses have types, i.e. are <X>s. In RM-ODP, types are needed for, at least, objects, interfaces and actions.  The notion of type classifies the entities into categories, some of which may be of interest to the specifier (see the concept of class in 9.8)."]
["RMODP_82","Unbinding behaviour","A behaviour that terminates a binding, i.e. a terminating behaviour for the binding."]
["RMODP_83","Viewpoint (on a system)","A form of abstraction achieved using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within a system."]

{"sheet":"IDEF0","index":7,"n_rows":7,"n_cols":3,"rows_kept":7,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition"]
["IDEF0_1","call","enable sharing of detail in other boxes, to provide additional information."]
["IDEF0_2","control","specificy conditions to product correct output."]
["IDEF0_3","function","transforms the inputs into the outputs."]
["IDEF0_4","input","transformed or consumed to produce outputs."]
["IDEF0_5","mechanism","means that support execution."]
["IDEF0_6","output","data or objects produced."]

{"sheet":"DERA","index":8,"n_rows":71,"n_cols":3,"rows_kept":71,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition"]
["DERA_1","abstraction","a view of a system that has a consistent level of behavioural and compositional detail in each branch of the architecture and hides finer, lower level detail."]
["DERA_2","acquirer","the party who acts on behalf of an enterprise organization to procure or obtain a system that accords with stakeholder/market needs."]
["DERA_3","acquisition management","the role encompassing the topmost level of project management and engineering management in the acquisition life cycle."]
["DERA_4","agreement package","the requirements, consideration and trading terms and conditions that formalise an acquirer/supplier relationship."]
["DERA_5","agreement","the activity or result of acceptance to supply product, service or information in response to and agreement package, irrespective of the level of formality."]
["DERA_6","application domain","a distinguishable class of operational environment that is characterised by its nature and/or by the interests of the owners and users of a system."]
["DERA_7","architecture","the structure of levels and/or branches that partition a system into its constituent parts or components."]
["DERA_8","behaviour","the inherent actions and the responses to the external events in the operational environment that characterise a system."]
["DERA_9","commercial requirements","the requirements introduced by an enterprise process to ensure that enterprise organization stakeholder interests are met."]
["DERA_10","component development","the process that results in the supply a component to a the developer of a system or subsystem in response to a specification."]
["DERA_11","component","a discrete, configured, essentially homogeneous part of a system that is supplied by a technology- or discipline-specific organization."]
["DERA_12","configuration management","a method of controlling storages, accesses and changes to the related, discrete, defined parts of a system at any time during its lifetime."]
["DERA_13","constraint","a requirement self-imposed by the supplier that does not modify the contracted requirements for the deliverable subsystem, system."]
["DERA_14","constraint","bounds expressed through local user or stakeholder needs that exclude specified system solution options."]
["DERA_15","creation life cycle","the structured set of processes, activities and tasks which may be tailor ed to define the specific sequence of actions throughout the creation phase of a specific system."]
["DERA_16","creation phase","the period that spans the expression of a user requirement to the transfer of a system to an owner, operator or user."]
["DERA_17","development life cycle","a tailored set of processes."]
["DERA_18","development","those activities that transform a user requirement into a system delivered to an acquirer."]
["DERA_19","end user","the user who directly benefits from a system in its operational environment."]
["DERA_20","enterprise life cycle","the period during which a system evolves from a market/application domain opportunity to an operational solution transferred to an owner."]
["DERA_21","enterprise organization","an organization that identifies a market opportunity, or has a statutory obligation, to fulfil the need for a system."]
["DERA_22","evolutionary life cycle","an enterprise life cycle in which the system's complete functionality is enhanced in each successive delivery."]
["DERA_23","fabrication","the realisation or formation from raw materials of a component in accordance with its stated design."]
["DERA_24","functional requirement","an expressed need for a system to exhibit specific, often quantified, behaviour as a result of its interaction with its operational environment."]
["DERA_25","incremental life cycle","an enterprise life cycle in which a system's existing functionality is added to in each successive delivery."]
["DERA_26","life cycle","a set of processes and their temporal relationships that describe a continuous flow of actions and states associated with the existence of system.  the linear sequence of phases of a system's existence that span an initiating action to a closing action, with an implied future re-execution of the sequence."]
["DERA_27","linear life cycle","a life cycle in which different processes are not executed concurrently."]
["DERA_28","local user requirements","requirements that are expressed by a system development organization that are not present in the user requirement or in requirements allocated in a contract."]
["DERA_29","manufacture","the complete sequence of actions that construct systems from specifications and raw materials."]
["DERA_30","non-functional requirement","the expressed need for a system to exhibit characteristics that are not functional requirements but which still contribute to stakeholder satisfaction with the solution."]
["DERA_31","operation","the process that enables the continued availability of services or capabilities of a system during its utilization phase."]
["DERA_32","operational environment","the set of external stimuli, responses and prevailing conditions that interact with a system during its utilization phase by virtue of its location or situation."]
["DERA_33","operator","the organization or party who is conferred with the responsibility for operation of a system."]
["DERA_34","organization","a business trading in, or administrative concern conferred with the authority to supply, a system/subsystem/component, a service based on a system or an associated enabling service."]
["DERA_35","owner","the organization that derives the ultimate benefit from, and incurs the highest level of obligation for, a system following its acceptance from an enterprise organization."]
["DERA_36","ownership life cycle","the period during which a system is utilized and disposed of."]
["DERA_37","phase","a characteristic, primary period in the sequence of events that comprise a life cycle."]
["DERA_38","practice","a corporate or commonly held view of actions and controls, drawn from experience, that permits successful execution of business and technical processes."]
["DERA_39","prime contractor","the system development organization that makes a contract with an acquisition process to supply a system."]
["DERA_40","problem domain","the problem space that contains pre-existing, operational systems and a need for a new system to be created."]
["DERA_41","process","a set of actions that receives an information, material or artefact input and operates on it or transforms it in a specified manner to create a new information, material or artefact product."]
["DERA_42","procurement organization","an organization or enterprise that is conferred with the authority to acquire a system on behalf of an ownership organization or an enterprise organization."]
["DERA_43","product system","the integrated, validated system that is transferred from an enterprise organization to an ownership organization."]
["DERA_44","product","the supplied output of a process or group of processes."]
["DERA_45","production","the assembly of components and subsystems into specified and verified configurations."]
["DERA_46","project management","the role that is responsible to each and every enterprise organization for the planning, monitoring and control of resources and capabilities in order to supply an agreed product or service to an acquirer."]
["DERA_47","project","the structure of authorities, resources and capabilities that plans, monitors and controls assets on behalf of an enterprise organization in order to supply a product or service."]
["DERA_48","requirement","an expression of need, demand or obligation."]
["DERA_49","risk management","the identification, actions and control of the factors that can minimise the adverse consequences of uncertainty throughout the system life cycle."]
["DERA_50","single shot","the attainment of a goal in a single attempt, thus excluding repetition or iteration."]
["DERA_51","specification","a description of the criteria that define the performance, attributes and constituents of a system or its parts or its associated enabling systems or services."]
["DERA_52","stage","a period of the enterprise life cycle comprising a complete system creation process and the associated enterprise process controlling actions."]
["DERA_53","stakeholder","a person or party with an interest in a system by virtue of their commercial, organisational or technical interaction with it."]
["DERA_54","subcontractor","a supplier to a prime contractor."]
["DERA_55","subsystem","a system viewed and defined as being a discrete part of a larger system."]
["DERA_56","supersystem","the integrated system comprising product system and all its neighbouring systems in the operational environment."]
["DERA_57","supplier","the party to an agreement who delivers a solution to an acquirer's need."]
["DERA_58","system","a homogeneous entity that exhibits predefined behaviour in the real world and is composed of heterogeneous parts that do not individually exhibit that behaviour.  an integrated configuration of components and/or subsystems."]
["DERA_59","system acquisition process","the set of process and activities that result in the supply of a system in accordance with agreed user requirements and enterprise organization constraints."]
["DERA_60","system design","the complete sequence of actions that creates a specification of components and their relationships that when manufactured conform to a user requirement."]
["DERA_61","system integration","the sequenced assembly and validation of delivered configurations of component/subsystem."]
["DERA_62","system reference model","a generalised representation of the processes and activities and the terminology that structure actions and aid communication during the creation of systems."]
["DERA_63","systems engineering","the subject of man-made systems or the engineering activity that is undertaken during the system life cycle."]
["DERA_64","tailor","modify a standard or preferred sequence of processes to meet specific circumstances."]
["DERA_65","user requirement","the totality of requirements derived from the needs of users and stakeholders in a product system's ownership phases."]
["DERA_66","user","a beneficiary of the capability or service provided by a system in its operational environment."]
["DERA_67","utilization life cycle","the generic set of processes, activities and tasks which may be tailor ed to describe the specific sequence of actions throughout the utilization phase of a specific system."]
["DERA_68","utilization phase","the period during which a system is productively used to the benefit of owners and users."]
["DERA_69","validation","the actions giving confirmatory evidence of the compliant operational behaviour of a system with its user requirement."]
["DERA_70","verification","the actions giving confirmatory evidence of the correctness of a specified system/subsystem/component."]

{"sheet":"MethH","index":9,"n_rows":35,"n_cols":3,"rows_kept":35,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition"]
["MetaH_1","Events","Events are enumeration literals in the source code that are used to name events that can be raised by software at run-time. MetaH event descriptions are included as part of the MetaH specification of any code module that refers to that event, where the event description gives the enumeration literal used in the source code."]
["MetaH_2","Ports","Ports are statically declared variables in a code module. MetaH port descriptions are included as part of the MetaH specification of the containing code module. Port variables are used as message buffers, and the executive configured from a MetaH specification will move values in real-time between port variables according to connections made between port objects in the MetaH specification."]
["MetaH_3","Types","Types are declarations of the types that have been used in the source code to declare port variables. MetaH type package specifications describe code modules that contain declarations of the types used for port variables. Port objects are typed in MetaH specifications just like the port variables are typed in the source code, and port-to-port connections specified in MetaH are type checked."]
["MetaH_4","Type packages","Type packages are the code modules that contain declarations of types used for port variables. A MetaH specification of a type package includes descriptions of the individual types declared in that module. These code modules must obey certain coding guidelines. The tools will check for consistency between and type correctness within the source code and the MetaH specifications."]
["MetaH_5","Subprograms","Subprograms are source code functions, procedures or subprograms. A subprogram is any- thing that a thread of control can enter and, after executing for some specified time, exit. Subprograms are code modules (independently compileable units often stored in individual source files), and MetaH subprogram specifications can describe source objects of interest in a subprogram (e.g. events)."]
["MetaH_6","Packages","Packages are collections of subprograms and declarations of static (persistent) data objects. Packages are code modules (independently compileable units often stored in individual source files), and MetaH package specifications can describe source objects of interest in a package (e.g. subprograms, ports, events)."]
["MetaH_7","Monitors","Monitors are packages that obey certain special coding guidelines and for which special runtime semantics are provided. A monitor declares internal data structures and exports subprograms to manipulate those data structures (the recommended coding guideline is to write a monitor as an abstract data type object). Monitors normally would be shared by multiple processes. Unlike a shared package, a real-time semaphore will be created in the executive for each monitor in an application. The application source code can include calls to standard services to lock and unlock this semaphore. Among other things, a MetaH monitor description can specify the real-time semaphore protocol used for a monitor."]
["MetaH_8","Events","Events are hardware interrupts that might be raised by a processor, or events that hardware will respond to when raised by software. MetaH specifications of processors, devices and systems may include event descriptions, where hardware events can be connected to software objects in a MetaH specification."]
["MetaH_9","Ports","Ports can also be described in MetaH specifications of processors and systems and can be connected to software ports. The underlying hardware-dependent device driver code modules are named in the MetaH hardware specification."]
["MetaH_10","Types and type packages","Types and type packages must be coded and specified for hardware ports. These code modules are with'ed by the device driver code modules and are also named in the MetaH hardware specifications."]
["MetaH_11","Monitors","Monitors are collections of subprograms that provide an interface to hardware-dependent services, e.g. commands for a specialized coprocessor. Monitor source code comes in two pieces, the interface code to be included in an application process and the driver code to be included with the executive. The monitor specification names these code modules, and the MetaH software specifications identify which application processes are allowed access to that hardware monitor."]
["MetaH_12","Memories","Memories are passive blocks of physical memory. These may be shared between processors."]
["MetaH_13","Processors","Processors are active hardware entities that are capable of executing software processes. Developing a detailed MetaH processor specification requires writing some standardized interface code between the underlying real-time operating system or hardware and the executives configured from a MetaH specification. These interface code modules are named in the MetaH processor specification."]
["MetaH_14","Devices","Devices are active hardware entities that cannot host software processes but that may send or receive messages via ports, and may share memories with processors."]
["MetaH_15","Channels","Channels are hardware entities that connect processors and devices and are capable of supporting port-to-port message passing. Various kinds of hardware can perform this function, including portions of shared memory set aside for this purpose."]
["MetaH_16","Processes","Processes have their own virtual address spaces and are the fundamental units of scheduling, computation, safe/secure partitioning and fault containment. A process is typically an executable unit that can be individually compiled and linked by the underlying programming language toolset (i.e. process code modules can be compiled and linked into a program). In addition to any source objects specified as component objects of a process, a root code module must be written to control overall initialization and schedule sequencing.1"]
["MetaH_17","Macros","Macros are collections of processes, together with specifications of how the ports and events of those processes are connected together and specifications of how packages and monitors are shared between processes. Port connections are used to connect an output port to an input port. Event connections are used to connect an output event to an input event, to an aperiodic process, or to a mode (explained shortly). Monitor and package sharing is specified using an equivalence connection."]
["MetaH_18","Modes","Modes are also collections of processes, together with specifications of how the ports and events of those processes are connected together and specifications of how packages and monitors are shared between processes. The difference between a macro and a mode is that multiple macros are like multiple processes: they are all active concurrently with each other. In contrast, modes are mutually exclusive. An application can only execute in one mode at a time. Event connections are used to specify how events raised by software cause run-time changes between modes. A mode change may cause processes to be stopped, may cause processes to be started and initialized, and/or may change the pattern of port and event connections. It is possible to nest macros and modes within each other in a way that specifies submodes of operation, i.e. it is possible to specify a mode change that affects only a part of the application."]
["MetaH_19","Connections","Connections are used to specify how messages flow between ports, how events flow between processes and other objects, and how objects may be equivalenced and thus shared by other objects."]
["MetaH_20","Paths","Paths specify characteristics of an application that are used for various analysis purposes. A path of execution through component subprograms of a process is an example of something described using a path specification."]
["MetaH_21","Systems","Systems are the higher-level hardware objects used to describe groups of hardware entities. A system is a collection of processors, channels, memories and devices. Connection specifications are used to show how memories are shared among processors and how channels are used to connect processors."]
["MetaH_22","Error models","Error models declare fault events that can occur in objects, error states that objects can be in, and error state transitions that objects may undergo in response to fault events. The particular error model used for source and hardware objects is an attribute of those objects."]
["MetaH_23","Applications","Applications are the highest-level objects in MetaH. An application identifies a software object and the hardware object on which that software is to be executed. Connections can be made between software and hardware ports, events and monitors."]
["MetaH_24","Memory","Memories are contiguous blocks of storage that may be contained exclusively within a single processor or may be shared by multiple processors. Memories are specified by the number of bytes and by the addressing scheme (i.e. byte addressed or word addressed)."]
["MetaH_25","Processor","Processor specifications describe a computer board built around a particular type of CPU, running a particular microkernel or real-time operating system, with a particular language cross development toolset. The processor interface denotes the interface to the board available for application software (I/O ports, interrupt events, monitors that provide hardware-specific service calls)."]
["MetaH_26","Device","A device is similar to a processor in the way that it can be connected to other hardware objects via shared channels and memories. A device cannot host any executable code. However, a device may share memory with one or more processors, so that code hosted on a processor may access device memory."]
["MetaH_27","Channel","A channel is a piece of hardware usable for bi-directional point-to-point communication between two processors or between a processor and a device. Ideally, channels provide contention-free communication with precisely characterizable timing properties. At each hardware clock interrupt, a processor will load a buffer with data, indicate to a channel that it should begin transmitting that data, then enter a busy-wait to receive notice that transmissions over that channel have completed. Because of this busy-wait, channel bandwidths must be relatively high in the current version."]
["MetaH_28","System","A system is a collection of processors and devices, together with declarations of connections between the ports and events of those processors and devices; and declarations of equivalences between the memories, channels and monitors of those processors."]
["MetaH_29","Port","This provides one mechanism for communication between software and hardware devices.  Ports may be declared in the interfaces to systems, processors and devices. Hardware ports produce and consume streams of data that may be connected to identically-typed ports declared in the software architecture specification."]
["MetaH_30","Event","An out event should be declared for each hardware interrupt made available in the internal executive TARGET package (see the Software Design Document for the Honeywell Aerospace Compiled Kernel). In the absence of any explicit SourceName specification for a hardware event FOO, the hardware interrupt will be assumed to have been given the name TARGET.FOO during retarget of the executive. This event can be connected to an aperiodic process or mode in the software architecture specification, causing an occurrance of the hardware interrupt to dispatch an aperiodic process or change to a new mode. Interrupts are enabled only during those modes of operation in which the associated events are connected to something. This is in the process of changing so interrupt events are declared in code modules associated with devices."]
["MetaH_31","Monitor","Monitors included as part of the hardware specification allow software to make target-specific subprogram calls to target-specific service routines."]
["MetaH_32","Port Connections","Port connection declarations are used to identify the processor port(s) that correspond to a port in a system interface specification. Each software port connected to a hardware port may be ultimately connected to either a processor port, a system port, or a device port. If the ultimate destination is a system port, then the standard executive software on every processor in that configuration is generally required to support input and output via that system port.  Port connection declarations must obey the same rules as in software specifications."]
["MetaH_33","Event Connections","Event connection declarations are used to identify the processor event(s) that correspond to an event in a system interface specification. Each software event connected to a hardware event may be ultimately connected to either a processor event or a system event. If the ultimate destination is a system event, then the standard executive software on every processor in that configuration is generally required to be able to raise or respond to that system event.  Event connection declarations must obey the same rules as in software specifications."]
["MetaH_34","Equivalence Connections","In a hardware specification, equivalence connections can appear within a system implementation specification between pairs of memories, pairs of channels, or pairs of monitors.  Equivalence connections must obey the same rules as in software specifications."]

{"sheet":"Spiby SS","index":10,"n_rows":81,"n_cols":3,"rows_kept":81,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Term","definition"]
["SED ESP5409","requirement","A condition or capability that must be met or possessed by a system or system component to satisfy a contract standard specification or other formally imposed document. "]
["EIA 632-1.1","requirement","(1) Something that governs what, how well, and under what conditions a product will achieve a given purpose.\n(2) Normative elements that govern implementation of this Standard, including certain documents such as agreements, plans, or specifications. "]
["Janes86.1","requirement","Predicted future need spelt out by armed force, usually after long process of refinement and assessment of alternatives."]
["AP233req v12d.1","requirement","Simplistically, a requirement is a statement (however expressed) of what is required [by a user, customer, or stakeholder]. Requirements are statements of measurable characteristics that a system shall exhibit or shall not exhibit when completed. "]
["DWOemail1.2","requirement","A test statement or model that asserts a property that shall be exhibited by an element."]
["PLCSApr01.1","requirement","Specified attributes"]
["PLCSApr01.2","characteristic","Distinguishing feature."]
["SED IEEE1063","function","A specific purpose of an entity or its characteristic action"]
["SED IEEE 729.1","function","A subprogram that is invoked during the evaluation of an expression in which its name appears and that returns a value to the point of invocation, Contrast with subroutine."]
["EIA 632-1.2","function","A task, action, or activity performed to achieve a desired outcome.  "]
["AP233req v12d.2","function","A function is a task, action or activity that must be performed to achieve a desired outcome [INCOSE 98]."]
["MDE.1","function","1. C43A quantity of value that depends upon the value of one or more other quantities.\n2. A specific purpose of an entity, or of its characteristic action.\n3. A means of referring to a type or sequence of calculations within an arithmetic statement."]
["DWOemail2.1","function","In the general context of text documents the words “Function” or “Functionality” mean Behavior as defined above."]
["DWOemail2.2","Function","The element in the context of modeling that transforms an input set of elements into a set of output elements that may be the same or measurably different from the input set."]
["PLCSApr01.3","Analysis","The resolution or breaking up of something complex into its various simple elements; the exact determination of the elements or components of something complex.A statement of the result of such an operation. "]
["SEDRES.1","Functional Requirements","The stated required active functionality of a system or product"]
["EIA 632-1.3","Functional Requirements","A requirement that defines what system products must do and their desired behavior in terms of an effect produced, or an action or service to be performed."]
["AP233req v12d.3","functional allocation","Allocation is both a process step and captured via a set of information. The process step is to form a mapping between functionality and architectural components to unambiguously identify the architectural components that perform each function. The allocation information is the set of allocation relationships between functions and architectural components (the latter in the following section are referred to as ‘product and process solutions’)."]
["AP233req v12d.4","functional analysis","Examination of a defined function to identify all of the sub-functions necessary to the accomplishment of that function. The sub-functions are arrayed in a functional architecture to show their relationships and interfaces (internal and external). Upper-level performance requirements are flowed down and allocated to lower-level sub-functions [INCOSE 98]."]
["AP233req v12d.5","functional architecture","The arrangement of functions and their subfunctions and interfaces (internal and external) that defines the execution sequencing, conditions for control or data flow, and the relative performance requirements to satisfy the requirements baseline [IEEE P1220-98]."]
["AP210.1","functional object","a type of product design representation described as an assembly of functions or implied function."]
["PLCSApr01.4","functional attributes","Measurable performance parameters including reliability, maintainability, and safety."]
["PLCSApr01.5","physical attributes","Quantitative and qualitative expressions of material features, such as composition, dimensions, finishes, form, fit, and their respective tolerances."]
["PLCSApr01.6","functional characteristics","Designed scope (i.e. sequence and essential qualities) of the operations to be performed by an item. Functional characteristics are expressed in terms of quantitative performance parameters such as range, speed, lethality, reliability, maintainability, safety; and operating and logistics parameters and their respective tolerances."]
["SED IEEE P1061","functionality","The existence of certain properties and functions that satisfy stated or implied needs of users. "]
["AP210.2","functionality","the degree to which an object is designed or adapted to a particular function or use."]
["SEDRES.2","Dynamic Functionality","A description of a set of requirements of the design which includes timing and behavioural information."]
["SEDRES.3","behaviour","The dynamic properties of a function or a system."]
["AP233req v12d.6","behaviour","Behaviour for a system describes what the system is to do [a required behaviour] or what it is intended to do  (designed behaviour) or what it does do (measured or observed behaviour), independent of how the system will do it. [derived from Oliver 97]."]
["AP233req v12d.7","behaviour","The collection of related properties that describe how a system or product interacts with its environment. [STEP99]"]
["SEDRES.4","system","An assembly of interacting, active components or elements forming a whole."]
["EIA 632-1.4","system","An aggregation of end products and enabling products to achieve a given purpose. "]
["DICST90","system","In general, a group or combination of interrelated or interacting elements forming a collective entity."]
["Janes86.2","system","1.  Generalized term for any dynamically functioning organization of man-made devices.\n2.  Portion of vehicle, eg aircraft, missile, etc, forming integral network of related and intercontrolled devices to accomplish set of specific related functions\n3.  Composite of equipment, skills and techniques capable of performing and/or supporting operational role (USAF)\n4.  Often used to mean (1) plus supporting equipment, documents, training devices, and all other products and services, as in weapon.\n5.  Incorrectly used to mean mere assemblage of mechanical parts, such as \"engine\"."]
["DICST","system","One of the principal functioning entities comprising the project hardware and related operational services within a project or flight mission.  Ordinarily, a system is the first major subdivision of a project work.  Similarly, a subsystem is a major functioning entity within a system.  A system may also be an organized and disciplined approach to accomplish a task; e.g. a failure-reporting system.\n1.  Any organized arrangement in which each component part acts, reacts or interacts in accordance with an verall design inherent in the arrangement.\n2.  Specifically, a major component of a given vehicle such as a propulsion system or a guidance system.  Usually called a major system to distinguish it from the systems subordinate or auxiliary to it."]
["AP233req v12d.8","system","An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective [MIL499B 94]."]
["AP233req v12d.9","system","A set or arrangement of elements [people, products (hardware and software) and processes (facilities, equipment, material and procedures) that are related and whose behaviour satisfies customer/operational needs, and provides for the life cycle sustainment of the products. [IEEE P1220-98]"]
["MDE.2","system","1. An assembly of component parts linked together by some form of regulated interaction into an organized whole."]
["MDE.3","system","2. A collection of consecutive operations and procedures required to accomplish a specific objective."]
["MDE.4","system","3. A collection of units combined to work a larger integrated unit having the capabilities of all the separate units."]
["MDE.5","system","4. The complete computer assembly, with CPU, memory, I/O, plus any required devices or peripherals for the application intended."]
["MDE.6","system","5. A set of interconnected elements constituted to achieve a given objective by performing a specific function."]
["PLCSApr01.7","system","A set of interrelated or interacting elements"]
["PLCSApr01.8","system","Composite of subsystems, assemblies (or sets), skills, and techniques capable of performing and/or supporting an operational or non-operational role. A complete system includes related facilities, items, materiel, services and personnel required for its operation to the degree that it can be considered a self-sufficient item in its intended operational or non-operational and/or support environment."]
["AP233req v12d.10","subsystem","A grouping of items satisfying a logical group of functions within a particular system. [MIL499B 94]"]
["SED IEEE 729.2","System Architecture","The structure and relationship among the components of the system. The system architecture may also include the system’s interface with its operational environment. "]
["SED IEEE 729.3","System Design","The process of defining the hardware and software architectures, components modules, interfaces and data for a system to satisfy specified system requirements. "]
["SEDRES Ref 1:","Systems Engineering","The application of methods and tools to the development and production of (reliable and maintainable) systems. "]
["SED 499A","Systems Engineering","the application of scientific and engineering efforts to:\n transform an operational need into a description of system performance parameters and a system configuration through the use of an iterative process of definition, synthesis, analysis, design, test and evaluation.\n Integrate related technical parameters and ensure compatibility of all physical, functional and program interfaces in a manner that optimises the total system definition and design.\n Integrate reliability, maintainability, safety, survivabiltiy, human engineering and other such factors into the total engineering effort to meet cost, schedule, supportability and technical performance objectives."]
["SED 499B","Systems Engineering","Systems engineering is an interdisciplinary approach to evolve and verify an integrated and optimally balanced set of product and process designs that satisfy user needs and provide information for management decision making. "]
["SED MP","Systems Engineering","is a hybrid methodology that combines policy analysis, design and management. It aims to ensure that a complex man-made system, selected from the range of options on offer, is the one most likely to satisfy the owner’s objectives in the context of long term future operational or market environments"]
["MDE.7","system engineering","A method of engineering analysis whereby all the elements in a system, including the process itself, are considered."]
["EIA 632-1.5","system technical requirement","A requirement derived from one or more stakeholder requirements and stated in technical terms."]
["AP233req v12d.11","system view","A concept for capturing information (requirements, behaviour, physical architecture, ...) from a particular viewpoint (i.e. Design, Maintenance, Recycling, User Interface, ...) on the system under development [AP233]"]
["AP233req v12d.12","Validation","Validation involves evaluation of the stakeholder requirements against customer needs and expectations, and evaluation of the delivered system to meet the customer’s operational need in the most representative environment achievable [adopted from SE CMM 95]."]
["AP233req v12d.13","Validation","Actions to confirm that the developed system meets user needs.  “Have you done the right job?”"]
["MDE.8","Validation","The process of verifying that execution of a system in its specified environment causes no operational problems.  Includes prevention, diagnosis, recovery, and correction of errors."]
["PLCSApr01.9","Validation","Confirmation and provision of objective evidence that the requirements for a specific intended use or application have been fulfilled"]
["AP233req v12d.14","Verification","The process of determining whether or not the products of a given phase of development fulfil the requirements established during the previous phase [IEEE P1220-94]."]
["AP233req v12d.15","Verification","Actions to confirm that the product of a system development meets its specification, “Have you done the job right?”"]
["MDE.9","Verification","The process of checking the results of one data transcription against those of another, both transcriptions usually involving manual operations."]
["PLCSApr01.10","Verification","Confirmation and provision of objective evidence that specified requirements have been fulfilled. "]
["MDE.10","test","A procedure or sequence of operations for determining the manner in which equipment is functioning or the existence, type, and location of any trouble."]
["DWOemail1.2","element","That which is discernable by reproducible measurement."]
["DWOemail1.3","Subclasses of Element:","(original text: )\nMatter: That which exhibits mass and dimensional extent\nEnergy: The ability to do work\nInformation: Knowledge about elements."]
["PLCSApr01.11","product","Anything that is used or produced to satisfy a need (e.g., facilities, systems, hardware, software, firmware, data, processes, materials, services).  "]
["PLCSApr01.12","attribute","A characteristic of a product, can be either functional, physical or performance or a combination of these. "]
["DWOemail1.4","property","A Property is any measurable characteristic of an element."]
["DWOemail2.3","physical property","What an element exhibits or does not exhibit in response to excitation and stimulation from auxiliary measurement entities that are not part of its context."]
["DWOemail2.4","behavior","What an element is to do or is not to do in response to excitations it receives from the external elements in its context."]
["DWOemail1.5","Whole Part Relationship","The decomposition of a whole element into its constituent components."]
["DWOemail1.6","Subclasses of Whole_Part_Relationship","Has classes:\n  All_The_Parts_Relationship\n  Some_Of_The_Parts_Relationship\n  None_Of_The_Parts_Relationship"]
["DWOemail1.7","All_The_Parts_Relationship","Has Superclass: Whole Part Relationship\nDecomposition of the whole into all of its parts."]
["DWOemail1.8","Some_Of_The_Parts_Relationship","Has Superclass: Whole Part Relationship\nDecomposition of the whole into some of its parts."]
["DWOemail1.9","None_Of_The_Parts_Relationship","Has Superclass: Whole Part Relationship\nA decomposition that lists all the elements that have a particular relationship to the whole, but are not parts of the whole."]
["DWOemail1.10","Component","One of the several elements that are parts assembled to make a whole element composed of those parts."]
["DWOemail1.11","Part Interconnection","(has subclasses: )\n  Assembly\n  Context (Nearest Neighbors)\n  Next higher assembly"]
["DWOemail1.12","Assembly","Has Superclass: Part Interconnection\nThe relationships that exist among all of the parts of a whole such that they may be assembled to constitute the whole and result in the desired properties of the whole."]
["DWOemail1.13","Context (Nearest Neighbors)","Has Superclass: Part Interconnection\nthe relationships that exist among some of the parts of a whole such that the next nearest neighbor connection to one of the parts is defined."]
["DWOemail1.14","Next higher assembly","???"]

{"sheet":"SECMv8","index":11,"n_rows":67,"n_cols":3,"rows_kept":67,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition"]
["SECMv8_1 ","Decomposition","In the Concept Model an aggregationn symbol is used with the letter \"C\" imposed on it. This has the meaning that the decomposition is complete in the sense that all of the parts that comprise the whole are listed. "]
["SECMv8_2 ","se_thing","That which is discernable by reproducible measurement of its characteristics."]
["SECMv8_3 ","category","Categories provide the grouping of SE_Things into a set based on defined properties that serve as selection criteria for which SE_Things of all those in the universe belong in that set. "]
["SECMv8_4 ","Inclusive/Complete Category","Any SE_Thing of the super category may reside in any number of the sub-categories and all members of the super-category are members of at least one of the sub-categories."]
["SECMv8_5 ","Inclusive/Incomplete Category","Any SE_Thing of the super category may reside in any number of the sub-categories and only some members of the super-category are members of the sub-categories."]
["SECMv8_6 ","Exclusive/Complete Category","Any SE_Thing of the super-category may reside in one and only one of the sub-categories and all members of the super-category are members of at least one of the sub-categories."]
["SECMv8_7 ","Exclusive/ Incomplete Category","Any SE_Thing of the super-category may reside in one and only one of the sub-categories and only some members of the super-category are members of the sub-categories."]
["SECMv8_8 ","domain-of-Interest","All SE_things of interest to the problem at hand. "]
["SECMv8_9 ","system","SE_Things with a well defined interface, both static and dynamic, with respect to the Domain of Interest."]
["SECMv8_10 ","system _view","A collection of SE_Things and related information about the system that are useful and defined for a particular purpose in a particular context. "]
["SECMv8_11 ","environment","All SE_Things external to the system that interact with it. "]
["SECMv8_12 ","stakeholder","The people, organizations and institutions that are a part of the system environment because the System provides some benefit to them and they have an interest in the system."]
["SECMv8_13 ","stakeholder _need","The benefits That the Stakeholders wish to be satisfied by or delivered by the system when it is implemented and functioning."]
["SECMv8_14 ","property","Any named measurable or observable attribute, quality or characteristic of an se_thing."]
["SECMv8_15 ","system_requirement","A statement of properties that a system shall exhibit or shall not exhibit when completed. "]
["SECMv8_16 ","property_reference","A statement of the sources of information concerning the property, its trensor characteristics, its units, its value, variance, or probability distribution."]
["SECMv8_17 ","behavior","What an SE_Thing is to do or is not to do in response to excitations it receives from the external SE_Things in its environment.."]
["SECMv8_18 ","physical _property","What an SE_Thing exhibits or does not exhibit in response to excitation and stimulation from auxiliary measurement entities that are not part of its context. "]
["SECMv8_19 ","structure","The decomposition, interconnection and other static relationship among the parts of the system."]
["SECMv8_20 ","system_assembly","The static parts of the system including their interconnection and inerconnection descriptions."]
["SECMv8_21 ","link","A particular kind of system assembly that is used when it is helpful not to model or specify its details."]
["SECMv8_22 ","port","A connection point on a system assembly in the system assembly decomposition hierarchy. "]
["SECMv8_23 ","interconnection","A listing of the ports that interconnect with one another."]
["SECMv8_24 ","interface_description"," A description of a Port of a System Assembly that includes the geometric description, I/O description, protocols that must be met, assemblies of parts required to join two ports, allowable defect characteristics, etc. "]
["SECMv8_25 ","function","The entity in the context of modeling that transforms an input set of SE_Things into a set of output SE_Things that may be the same or measurably different from the input set."]
["SECMv8_26 ","input_output","SE_Things consumed by a function are Inputs and those generated by a function are Outputs. "]
["SECMv8_27 ","function_ordering","Function Ordering imposes how functions execute, which may be sequential, concurrent, traversed iteratively, or lie on separate alternative paths."]
["SECMv8_28 ","internal _function","A kind of function that is allocated to and implemented by System/Structure."]
["SECMv8_29 ","external_ function","A kind of function that is allocated to and implemented by SE_Things in the environment. "]
["SECMv8_30 ","unit","Establishes the standard of measure against which the values of physical_properties shall be stated."]
["SECMv8_31 ","property_value","A numeric value assigned to  a physical_property"]
["SECMv8_32 ","required_budgeted_property_value","A property value aloocated to a system_assembly by a requirement, or budgeted to that system_assembly by analysis."]
["SECMv8_33 ","calculated_property_value","A property value of a whole calculated or estimated from the values of the parts that assemble to make the whole."]
["SECMv8_34 ","target_budget_property_value","A temporary property value used by a designer as the design work proceeds and different design alternatives are considered. "]
["SECMv8_35 "]
["SECMv8_36 ","measured_property_vsalue","A property_value established by measurement of an actual part."]
["SECMv8_37 ","model_parameter","a formally declared variable of the analytical model provided for an external application to populate at execution time in a computing environment"]
["SECMv8_38 ","parameter_assignment","Provides actual values for characteristics declared formally by the model_parameter."]
["SECMv8_39 ","analytical_representation","Is the association of specific properties of specific system assemblies with an analytical_model in order to unambiguously characterize the performance of a specific system_assembly."]
["SECMv8_40 ","analytical_model","Provides a mathematical description of the properties of a system. "]
["SECMv8_41 ","functional_requirement","States what the shall be done by the system to which it is allocated."]
["SECMv8_42 ","temporal_requriement","States a time duration or a time probability for the completion of a functional requirement"]
["SECMv8_43 ","physical_property_requirement","States a Physical Property that shall be exhibited by the System or System Asseembly to which it is assigned."]
["SECMv8_44 ","interface_requirement","States the characteristics of the Interface to which it is assigned. Note that it includes the geometric description, I/O description, protocols that must be met, assemblies of parts required to join two ports, allowable defect characteristics, etc."]
["SECMv8_45 ","imposed_design_requirement","States particular SE_Things that shall be used in the desiign oof the System or System Assembly"]
["SECMv8_46 ","reference_requirement","States a reference to a source of additional requirements that shall be met by the System or System Assembly. Note that the referenced source may be a requirements document, government requirements for safety, security, environmental quality, etc., or a state or federal law."]
["SECMv8_47 ","reference_source","Any requirements document, government regulation or law that contains applicable requirement."]
["SECMv8_48 ","effectiveness_measure","States an optimization condition that a system shall meet. Note that Requirements_S define the domain of the solution, the solution space. The Effectiveness Measures drive the solution to a particular region in that space. The effectiveness measures are tightly related to stakeholder Needs. Example: the requirements differences between a PC and a laptop are largely in the laptop optimization conditions for lminimum weight, minimum thickness, and maximum battery life. These critiera are some of those that customers (one of the kinds of stakeholder) consider in deciding what to purchase. "]
["SECMv8_49 ","optimization_direction","States the direction of optimization, maximize or minimize, for an Effectiveness Measure. Example: for a laptop computer weight and thickness are minimized and battery life is maximized. "]
["SECMv8_50 ","weight","Relative importance of a particular Effectriveness Measure. Note; weights are often expressed in a numerical form. Example: they fix the relative importance in trade off weight, thickness, and battery life. How many minutes of battery life are worth how many tenths of a pound in weight."]
["SECMv8_51 ","regularization_function","an analytic expression that combines effectiveness measures with weights to produce a simgle number for the goodness of a design option. Note: this corresponds to the regularization function used in optimal control design and in statistical optimization of processes. "]
["SECMv8_52 ","verification_requirement","Statement of how a system design or instance shall be shown by the development organization using test, analysis, inspection ,  demonstration, simulation, similarity, sampling, or other method to meet a requirement allocated to the system. Note that this is a requirement on the development organization and not on the system. Note that this is performed to confirm that the deployed system will meet the requirements."]
["SECMv8_53 ","verification _event","Occurrence (with date, performer and result) of a comparison of a requirement against the test, analysis, or inspection results of a design or instance of a system."]
["SECMv8_54 ","verification_procedure","Describes the process used to compare a requirement against the test, analysis, or inspection results of a design or instance of a system. Example: for a complex digital system the procedure may require the application of a suite of test vectors to the digital system along with environmental tests involving temperature stress and vibration. Example: for a complex metal system the the procedure may require the application of several nondestructuve tests to ensure that there are no flaws preset that will cause failure."]
["SECMv8_55 ","verification_configuration","Arrangement of system and infrastructure necessary to perform the test, analysis, or inspection of a design or instance of a system."]
["SECMv8_56 ","verification_plan","The schedule of tasks, task durations, start times, end times, task inputs, task outputs, goals, and resources (both personnel and infrastructure) to perform the test, analysis, or inspection of a design or instance of a system."]
["SECMv8_57 ","organization"," Description of the roles of persons in a group or team. Note that this is a subclass of System Assembly, definition (19)."]
["SECMv8_58 ","issue","Any question raised concerning the system or the system development."]
["SECMv8_59 ","risk","Likelihood and impact of failure to meet any technical or development program goal. "]
["SECMv8_60 ","verification_status","Describes the state of a Verification Requirement as Not Yet Planned, Planned, In Progress, Completed - Satisfactory,or  Completed - Unsatisfactory. Example: for a complex digital system the procedure may require the application of a suite of test vectors to the digital system along with environmental tests involving temperature stress and vibration. Example: for a complex metal system the the procedure may require the application of several nondestructuve tests to ensure that there are no flaws preset that will cause failure."]
["SECMv8_61 ","validation_requirement","Statement of how a system requirement, design or instance shall be shown by the development organization to meet Stakeholder Needs. Note that this is to confirm that the requirements are suitable for the marketplace. "]
["SECMv8_62 ","validation_event","Occurrence (with date, performer and result) of a comparison of a Requirement against the stakeholder needs."]
["SECMv8_63 ","validation_procedure","Describes the process used to compare a Requirement against Stakeholder Needs. Note that this is a requirement on the development organization and not on the system. Note that the procedures may include stakeholder and market surveys, and test marketing."]
["SECMv8_64 ","validation_infrastructure","Arrangement of requirement information and related infrastructure necessary to asses corresondance with stakeholder needs and market realities."]
["SECMv8_65 ","validation_plan","The schedule of tasks, inputs, outputs, goals, and resources, both personnel and infrastructure to perform the comparison of Requirements against Stakeholder Needs.."]
["SECMv8_66 ","validation_status","Describes the state of a Validation Requirement as Not Yet Planned, Planned, In Progress, Completed - Satisfactory, or  Completed - Unsatisfactory. Note: entire new product lines have been abandoned after completed development because of unsatisfactory consumer panel responses and unsatisfactory test marketing. "]

{"sheet":"All terms","index":12,"n_rows":474,"n_cols":6,"rows_kept":474,"cut":false,"hidden":false,"merged":[],"flags":["formulas_cached_only"]}
["ID","Concept","Definition","CM8","Comparison","Comment"]
[" IEEE_100_1","architecture","A logical or physical representation of a product which depicts its structure, but, provides few or no implementation details."]
[" IEEE_100_10","environment","The natural conditions (weather, climate, ocean conditions, terrain, vegetation, dust, etc.) which define the utilization environment in which the system will be expected to operate within."]
[" IEEE_100_11","external system","The system or product interfaces to other systems, communication networks, power supplies, resource connectors, etc., which affect the design of the product under consideration."]
[" IEEE_100_12","external system interface","The system or product interfaces to other systems, platforms, or products which influence the design solutions for consumer products and their life-cycle processes."]
[" IEEE_100_13","function","A task, action or activity that must be accomplished to achieve a desired outcome, or to provide a desired capability."]
[" IEEE_100_14","functional architecture","The arrangement of functions, their decomposition, and interfaces (internal and external) which defines the execution sequencing, conditions for control or data flow, and the relative performance levels of achievement for a desired outcome, or for providing a desired capability."]
[" IEEE_100_15","functional architecture","An arrangement of functions and their sub-functions and interfaces (internal and external) which defines the execution sequencing, conditions for control or data-flow, and the performance requirements to satisfy the requirements baseline."]
[" IEEE_100_16","mode","An operating condition of a function or sub-function or physical element of the system."]
[" IEEE_100_17","part","The lowest element of a physical or system architecture, specification tree, or system breakdown structure that is not partitionable (bolt, nut, bracket, computer software unit)."]
[" IEEE_100_18","performance measure","(measure of performance) A performance measure that provides design requirements which are necessary to satisfy a measure of effectiveness."]
[" IEEE_100_19","physical architecture","An arrangement of physical elements which provides the design solution for a consumer product or life-cycle process intended to satisfy the requirements of the functional architecture and the requirements baseline."]
[" IEEE_100_2","assembly","An element of the physical or system architecture, specification tree, and system breakdown structure that is a subordinate element to a subsystem and is comprised of two or more components."]
[" IEEE_100_20","physical characteristic","The physical design attributes or distinguishing features which pertain to a measurable description of a product or process."]
[" IEEE_100_21","physical element","A product, subsystem, assembly, component, sub-component, subassembly, or part of the physical architecture defined by its designs, interfaces (internal and external), and requirements (functional, performance, constraints, and physical characteristics)."]
[" IEEE_100_22","product","The result of a human, mechanical or natural effort or process, such as, a manufacturing process."]
[" IEEE_100_23","service","The delivery, installation, maintenance, training, and other labor intensive activities providing life-cycle support associated with the products and processes of the system."]
[" IEEE_100_24","specification","A document which fully describes a physical element or its interfaces in terms of requirements (functional, performance, constraints and physical characteristics) and the qualification conditions and procedures for each requirement."]
[" IEEE_100_25","subassembly","An element of the physical or system architecture, specification tree, and system breakdown structure that is subordinate to a complex component and is comprised of two or more sub-components."]
[" IEEE_100_26","subcomponent","An element of the physical or system architecture, specification tree, and system breakdown structure that is subordinate to a noncomplex component, or a subassembly, and is comprised of two or more parts."]
[" IEEE_100_27","subsystem","An element of the physical or system architecture, specification tree or system breakdown structure that is a subordinate element to a product and is comprised of one or more assemblies and their associated life-cycle processes."]
[" IEEE_100_28","system architecture","The composite of the physical architectures for consumer products and their life-cycle processes."]
[" IEEE_100_29","system design","The product of the development process which provides sufficient details, drawings, or other pertinent information, on the system components, elements, parts, interfaces, etc., to permit the fabrication, production, assembly, integration and testing of the system under development."]
[" IEEE_100_3","behavior","The analysis of the logical (stimulus/response) and physical (resource consumption, event timing, throughput etc.) execution of a system to assess the functional and physical."]
[" IEEE_100_30","system element","A product, subsystem, assembly, component, sub-component, subassembly, or part of the system breakdown structure which includes the specifications, configuration baseline, budget, schedule, and work tasks."]
[" IEEE_100_31","system requirement","Provides a description of desired capabilities, constraints, and other details which pertain to the product's functional, performance, and physical characteristics."]
[" IEEE_100_4","change management","The process of evaluating the impact of a requirement or design change on the system, analyzing the effects of a proposed change in terms of the system foundation architecture, performance, costs, and schedule criteria."]
[" IEEE_100_5","component","An element of the physical or system architecture, specification tree, and system breakdown structure that is a subordinate element to an assembly and may be composed of two or more sub-components, or parts; or one or more subassemblies and their associated life-cycle processes."]
[" IEEE_100_6","design","The results of the synthesis process which provides sufficient details, drawings, or other pertinent information for a physical element that permits further development; or fabrication, assembly, and integration; or production of a product."]
[" IEEE_100_7","design architecture","The arrangement of elements or components, their decomposition, interfaces (internal and external), and physical constraints, which form the basis of a system design."]
[" IEEE_100_8","effectiveness measure","(measure of effectiveness) The figure-of-merit which provide a quantitative means for comparing alternative system solutions."]
[" IEEE_100_9","environment","The natural (weather, climate, ocean conditions, terrain, vegetation, dust, etc.) and induced (electromagnetic, interference, heat, vibration, etc.) conditions which constrain the design solutions for consumer products and their life-cycle processes."]
["AP210.1","functional object","a type of product design representation described as an assembly of functions or implied function."]
["AP210.2","functionality","the degree to which an object is designed or adapted to a particular function or use."]
["AP233req v12d.1","requirement","Simplistically, a requirement is a statement (however expressed) of what is required [by a user, customer, or stakeholder]. Requirements are statements of measurable characteristics that a system shall exhibit or shall not exhibit when completed. "]
["AP233req v12d.10","subsystem","A grouping of items satisfying a logical group of functions within a particular system. [MIL499B 94]"]
["AP233req v12d.11","system view","A concept for capturing information (requirements, behaviour, physical architecture, ...) from a particular viewpoint (i.e. Design, Maintenance, Recycling, User Interface, ...) on the system under development [AP233]"]
["AP233req v12d.12","Validation","Validation involves evaluation of the stakeholder requirements against customer needs and expectations, and evaluation of the delivered system to meet the customer’s operational need in the most representative environment achievable [adopted from SE CMM 95]."]
["AP233req v12d.13","Validation","Actions to confirm that the developed system meets user needs.  “Have you done the right job?”"]
["AP233req v12d.14","Verification","The process of determining whether or not the products of a given phase of development fulfil the requirements established during the previous phase [IEEE P1220-94]."]
["AP233req v12d.15","Verification","Actions to confirm that the product of a system development meets its specification, “Have you done the job right?”"]
["AP233req v12d.2","function","A function is a task, action or activity that must be performed to achieve a desired outcome [INCOSE 98]."]
["AP233req v12d.3","functional allocation","Allocation is both a process step and captured via a set of information. The process step is to form a mapping between functionality and architectural components to unambiguously identify the architectural components that perform each function. The allocation information is the set of allocation relationships between functions and architectural components (the latter in the following section are referred to as ‘product and process solutions’)."]
["AP233req v12d.4","functional analysis","Examination of a defined function to identify all of the sub-functions necessary to the accomplishment of that function. The sub-functions are arrayed in a functional architecture to show their relationships and interfaces (internal and external). Upper-level performance requirements are flowed down and allocated to lower-level sub-functions [INCOSE 98]."]
["AP233req v12d.5","functional architecture","The arrangement of functions and their subfunctions and interfaces (internal and external) that defines the execution sequencing, conditions for control or data flow, and the relative performance requirements to satisfy the requirements baseline [IEEE P1220-98]."]
["AP233req v12d.6","behavior","Behaviour for a system describes what the system is to do [a required behaviour] or what it is intended to do  (designed behaviour) or what it does do (measured or observed behaviour), independent of how the system will do it. [derived from Oliver 97].",null,null,"Verbatum \"behaviour\""]
["AP233req v12d.7","behavior","The collection of related properties that describe how a system or product interacts with its environment. [STEP99]",null,null,"Verbatum \"behaviour\""]
["AP233req v12d.8","system","An integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective [MIL499B 94]."]
["AP233req v12d.9","system","A set or arrangement of elements [people, products (hardware and software) and processes (facilities, equipment, material and procedures) that are related and whose behaviour satisfies customer/operational needs, and provides for the life cycle sustainment of the products. [IEEE P1220-98]"]
["DERA_1","abstraction","a view of a system that has a consistent level of behavioural and compositional detail in each branch of the architecture and hides finer, lower level detail."]
["DERA_10","component development","the process that results in the supply a component to a the developer of a system or subsystem in response to a specification."]
["DERA_11","component","a discrete, configured, essentially homogeneous part of a system that is supplied by a technology- or discipline-specific organization."]
["DERA_12","configuration management","a method of controlling storages, accesses and changes to the related, discrete, defined parts of a system at any time during its lifetime."]
["DERA_13","constraint","a requirement self-imposed by the supplier that does not modify the contracted requirements for the deliverable subsystem, system."]
["DERA_14","constraint","bounds expressed through local user or stakeholder needs that exclude specified system solution options."]
["DERA_15","creation life cycle","the structured set of processes, activities and tasks which may be tailor ed to define the specific sequence of actions throughout the creation phase of a specific system."]
["DERA_16","creation phase","the period that spans the expression of a user requirement to the transfer of a system to an owner, operator or user."]
["DERA_17","development life cycle","a tailored set of processes."]
["DERA_18","development","those activities that transform a user requirement into a system delivered to an acquirer."]
["DERA_19","end user","the user who directly benefits from a system in its operational environment."]
["DERA_2","acquirer","the party who acts on behalf of an enterprise organization to procure or obtain a system that accords with stakeholder/market needs."]
["DERA_20","enterprise life cycle","the period during which a system evolves from a market/application domain opportunity to an operational solution transferred to an owner."]
["DERA_21","enterprise organization","an organization that identifies a market opportunity, or has a statutory obligation, to fulfil the need for a system."]
["DERA_22","evolutionary life cycle","an enterprise life cycle in which the system's complete functionality is enhanced in each successive delivery."]
["DERA_23","fabrication","the realisation or formation from raw materials of a component in accordance with its stated design."]
["DERA_24","functional requirement","an expressed need for a system to exhibit specific, often quantified, behaviour as a result of its interaction with its operational environment."]
["DERA_25","incremental life cycle","an enterprise life cycle in which a system's existing functionality is added to in each successive delivery."]
["DERA_26","life cycle","a set of processes and their temporal relationships that describe a continuous flow of actions and states associated with the existence of system.  the linear sequence of phases of a system's existence that span an initiating action to a closing action, with an implied future re-execution of the sequence."]
["DERA_27","linear life cycle","a life cycle in which different processes are not executed concurrently."]
["DERA_28","local user requirements","requirements that are expressed by a system development organization that are not present in the user requirement or in requirements allocated in a contract."]
["DERA_29","manufacture","the complete sequence of actions that construct systems from specifications and raw materials."]
["DERA_3","acquisition management","the role encompassing the topmost level of project management and engineering management in the acquisition life cycle."]
["DERA_30","non-functional requirement","the expressed need for a system to exhibit characteristics that are not functional requirements but which still contribute to stakeholder satisfaction with the solution."]
["DERA_31","operation","the process that enables the continued availability of services or capabilities of a system during its utilization phase."]
["DERA_32","operational environment","the set of external stimuli, responses and prevailing conditions that interact with a system during its utilization phase by virtue of its location or situation."]
["DERA_33","operator","the organization or party who is conferred with the responsibility for operation of a system."]
["DERA_34","organization","a business trading in, or administrative concern conferred with the authority to supply, a system/subsystem/component, a service based on a system or an associated enabling service."]
["DERA_35","owner","the organization that derives the ultimate benefit from, and incurs the highest level of obligation for, a system following its acceptance from an enterprise organization."]
["DERA_36","ownership life cycle","the period during which a system is utilized and disposed of."]
["DERA_37","phase","a characteristic, primary period in the sequence of events that comprise a life cycle."]
["DERA_38","practice","a corporate or commonly held view of actions and controls, drawn from experience, that permits successful execution of business and technical processes."]
["DERA_39","prime contractor","the system development organization that makes a contract with an acquisition process to supply a system."]
["DERA_4","agreement package","the requirements, consideration and trading terms and conditions that formalise an acquirer/supplier relationship."]
["DERA_40","problem domain","the problem space that contains pre-existing, operational systems and a need for a new system to be created."]
["DERA_41","process","a set of actions that receives an information, material or artefact input and operates on it or transforms it in a specified manner to create a new information, material or artefact product."]
["DERA_42","procurement organization","an organization or enterprise that is conferred with the authority to acquire a system on behalf of an ownership organization or an enterprise organization."]
["DERA_43","product system","the integrated, validated system that is transferred from an enterprise organization to an ownership organization."]
["DERA_44","product","the supplied output of a process or group of processes."]
["DERA_45","production","the assembly of components and subsystems into specified and verified configurations."]
["DERA_46","project management","the role that is responsible to each and every enterprise organization for the planning, monitoring and control of resources and capabilities in order to supply an agreed product or service to an acquirer."]
["DERA_47","project","the structure of authorities, resources and capabilities that plans, monitors and controls assets on behalf of an enterprise organization in order to supply a product or service."]
["DERA_48","requirement","an expression of need, demand or obligation."]
["DERA_49","risk management","the identification, actions and control of the factors that can minimise the adverse consequences of uncertainty throughout the system life cycle."]
["DERA_5","agreement","the activity or result of acceptance to supply product, service or information in response to and agreement package, irrespective of the level of formality."]
["DERA_50","single shot","the attainment of a goal in a single attempt, thus excluding repetition or iteration."]
["DERA_51","specification","a description of the criteria that define the performance, attributes and constituents of a system or its parts or its associated enabling systems or services."]
["DERA_52","stage","a period of the enterprise life cycle comprising a complete system creation process and the associated enterprise process controlling actions."]
["DERA_53","stakeholder","a person or party with an interest in a system by virtue of their commercial, organisational or technical interaction with it."]
["DERA_54","subcontractor","a supplier to a prime contractor."]
["DERA_55","subsystem","a system viewed and defined as being a discrete part of a larger system."]
["DERA_56","supersystem","the integrated system comprising product system and all its neighbouring systems in the operational environment."]
["DERA_57","supplier","the party to an agreement who delivers a solution to an acquirer's need."]
["DERA_58","system","a homogeneous entity that exhibits predefined behaviour in the real world and is composed of heterogeneous parts that do not individually exhibit that behaviour.  an integrated configuration of components and/or subsystems."]
["DERA_59","system acquisition process","the set of process and activities that result in the supply of a system in accordance with agreed user requirements and enterprise organization constraints."]
["DERA_6","application domain","a distinguishable class of operational environment that is characterised by its nature and/or by the interests of the owners and users of a system."]
["DERA_60","system design","the complete sequence of actions that creates a specification of components and their relationships that when manufactured conform to a user requirement."]
["DERA_61","system integration","the sequenced assembly and validation of delivered configurations of component/subsystem."]
["DERA_62","system reference model","a generalised representation of the processes and activities and the terminology that structure actions and aid communication during the creation of systems."]
["DERA_63","systems engineering","the subject of man-made systems or the engineering activity that is undertaken during the system life cycle."]
["DERA_64","tailor","modify a standard or preferred sequence of processes to meet specific circumstances."]
["DERA_65","user requirement","the totality of requirements derived from the needs of users and stakeholders in a product system's ownership phases."]
["DERA_66","user","a beneficiary of the capability or service provided by a system in its operational environment."]
["DERA_67","utilization life cycle","the generic set of processes, activities and tasks which may be tailor ed to describe the specific sequence of actions throughout the utilization phase of a specific system."]
["DERA_68","utilization phase","the period during which a system is productively used to the benefit of owners and users."]
["DERA_69","validation","the actions giving confirmatory evidence of the compliant operational behaviour of a system with its user requirement."]
["DERA_7","architecture","the structure of levels and/or branches that partition a system into its constituent parts or components."]
["DERA_70","verification","the actions giving confirmatory evidence of the correctness of a specified system/subsystem/component."]
["DERA_8","behavior","the inherent actions and the responses to the external events in the operational environment that characterise a system.",null,null,"Verbatum \"behaviour\""]
["DERA_9","commercial requirements","the requirements introduced by an enterprise process to ensure that enterprise organization stakeholder interests are met."]
["DICST","system","One of the principal functioning entities comprising the project hardware and related operational services within a project or flight mission.  Ordinarily, a system is the first major subdivision of a project work.  Similarly, a subsystem is a major functioning entity within a system.  A system may also be an organized and disciplined approach to accomplish a task; e.g. a failure-reporting system.\n1.  Any organized arrangement in which each component part acts, reacts or interacts in accordance with an verall design inherent in the arrangement.\n2.  Specifically, a major component of a given vehicle such as a propulsion system or a guidance system.  Usually called a major system to distinguish it from the systems subordinate or auxiliary to it."]
["DICST90","system","In general, a group or combination of interrelated or interacting elements forming a collective entity."]
["DWOemail1.10","Component","One of the several elements that are parts assembled to make a whole element composed of those parts."]
["DWOemail1.11","Part Interconnection","(has subclasses: )\n  Assembly\n  Context (Nearest Neighbors)\n  Next higher assembly"]
["DWOemail1.12","Assembly","Has Superclass: Part Interconnection\nThe relationships that exist among all of the parts of a whole such that they may be assembled to constitute the whole and result in the desired properties of the whole."]
["DWOemail1.13","Context (Nearest Neighbors)","Has Superclass: Part Interconnection\nthe relationships that exist among some of the parts of a whole such that the next nearest neighbor connection to one of the parts is defined."]
["DWOemail1.14","Next higher assembly","???"]
["DWOemail1.2","element","That which is discernable by reproducible measurement."]
["DWOemail1.2","requirement","A test statement or model that asserts a property that shall be exhibited by an element."]
["DWOemail1.3","Subclasses of Element:","(original text: )\nMatter: That which exhibits mass and dimensional extent\nEnergy: The ability to do work\nInformation: Knowledge about elements."]
["DWOemail1.4","property","A Property is any measurable characteristic of an element."]
["DWOemail1.5","Whole Part Relationship","The decomposition of a whole element into its constituent components."]
["DWOemail1.6","Subclasses of Whole_Part_Relationship","Has classes:\n  All_The_Parts_Relationship\n  Some_Of_The_Parts_Relationship\n  None_Of_The_Parts_Relationship"]
["DWOemail1.7","All_The_Parts_Relationship","Has Superclass: Whole Part Relationship\nDecomposition of the whole into all of its parts."]
["DWOemail1.8","Some_Of_The_Parts_Relationship","Has Superclass: Whole Part Relationship\nDecomposition of the whole into some of its parts."]
["DWOemail1.9","None_Of_The_Parts_Relationship","Has Superclass: Whole Part Relationship\nA decomposition that lists all the elements that have a particular relationship to the whole, but are not parts of the whole."]
["DWOemail2.1","function","In the general context of text documents the words “Function” or “Functionality” mean Behavior as defined above."]
["DWOemail2.2","Function","The element in the context of modeling that transforms an input set of elements into a set of output elements that may be the same or measurably different from the input set."]
["DWOemail2.3","physical property","What an element exhibits or does not exhibit in response to excitation and stimulation from auxiliary measurement entities that are not part of its context."]
["DWOemail2.4","behavior","What an element is to do or is not to do in response to excitations it receives from the external elements in its context."]
["EIA 632-1.1","requirement","(1) Something that governs what, how well, and under what conditions a product will achieve a given purpose.\n(2) Normative elements that govern implementation of this Standard, including certain documents such as agreements, plans, or specifications. "]
["EIA 632-1.2","function","A task, action, or activity performed to achieve a desired outcome.  "]
["EIA 632-1.3","functional requirement","A requirement that defines what system products must do and their desired behavior in terms of an effect produced, or an action or service to be performed.",null,null,"Verbatum 'Functional Requirements'"]
["EIA 632-1.4","system","An aggregation of end products and enabling products to achieve a given purpose. "]
["EIA 632-1.5","system technical requirement","A requirement derived from one or more stakeholder requirements and stated in technical terms."]
["EIA632v11d7_1","acquirer"," An enterprise, organization, or individual that obtains a product (good or service) from a supplier.  "]
["EIA632v11d7_10","derivative system"," A special type of precedented system derived from a previously operational system through the use of major elements, but whose requirements have been modified to meet new objectives."]
["EIA632v11d7_11","derived requirement"," (1) A requirement that is further refined from a primary source requirement or a higher-level derived requirement. (2) A requirement that results from a design decision for a logical or physical solution representation. "]
["EIA632v11d7_12","developer","An enterprise or organization that performs the process requirements of this Standard."]
["EIA632v11d7_13","development"," The action by which a set of requirements is translated into a solution definition for a set of products that satisfy stakeholders."]
["EIA632v11d7_14","document"," A collection of data, regardless of the medium on which it is recorded, that generally has permanence and can be read by humans or machines.  "]
["EIA632v11d7_15","effectiveness analysis"," An assessment of how well a product associated with an alternative logical, physical, or design solution is expected to perform or operate, given an anticipated usage scenario."]
["EIA632v11d7_16","enabling product"," Item that provides the means for a) getting an end product into service, b) keeping it in service, or c) ending its service."]
["EIA632v11d7_17","end product"," The portion of a system that performs the operational functions and is delivered to an acquirer."]
["EIA632v11d7_18","end product validation"," Confirmation by examination and provision of objective evidence that the specific intended use of an end product (developed or purchased), or an aggregation of end products, is accomplished in an intended usage environment."]
["EIA632v11d7_19","end product verification"," Confirmation by examination and provision of objective evidence that the specified requirements to which an end product is built, coded, or assembled have been fulfilled. "]
["EIA632v11d7_2","agreement"," An arrangement, not necessarily contractual, between two parties (an acquirer and a supplier) that defines the tasks to be performed, the items to be delivered, the acceptance criteria to be applied to delivered items, and other requirements affecting the development or procurement of system products."]
["EIA632v11d7_20","engineering life cycle"," A sequence of phases that evolves an instance of a system from a concept to a set of products consistent with the exit criteria established for an enterprise-based life cycle phase."]
["EIA632v11d7_21","engineering plan"," The plan for implementing the processes for engineering a system.  The engineering plan reflects an integrated technical effort that balances all factors associated with meeting life cycle requirements."]
["EIA632v11d7_22","enterprise","The entity that has governance over a set projects, or over organizations in which projects are carried out."]
["EIA632v11d7_23","enterprise-based life cycle"," The incremental progress of a system from conception through disposal, marked by management-established milestones with assigned exit criteria."]
["EIA632v11d7_24","environment"," (1) The natural conditions (weather, climate, ocean conditions, terrain, vegetation, dust, etc.) and induced conditions (electromagnetic interference, heat, vibration, etc.) that constrain the design definitions for end products and their enabling products. (2) External factors affecting an enterprise or project. (3) External factors affecting development tools, methods, or processes."]
["EIA632v11d7_25","function","A task, action, or activity performed to achieve a desired outcome.  "]
["EIA632v11d7_26","functional requirement","A requirement that defines what system products must do and their desired behavior in terms of an effect produced, or an action or service to be performed."]
["EIA632v11d7_27","information database"," A repository that provides a capacity to maintain work products and outcomes from implementation of the processes for engineering a system in a controlled manner."]
["EIA632v11d7_28","interface requirement","A requirement that defines the conditions of interaction between items.  "]
["EIA632v11d7_29","layer of development"," (1) A level of abstraction as it relates to the system structure made up of building blocks. (2) A level of system decomposition."]
["EIA632v11d7_3","assign"," Designate a function, product, process, or other item as accountable for a particular purpose."]
["EIA632v11d7_30","method"," Techniques that support implementation of process tasks.  "]
["EIA632v11d7_31","multidisciplinary teamwork"," The cooperative application of all appropriate disciplines by people functioning as a team to achieve solutions that balance the contributions of the disciplines effectively.  "]
["EIA632v11d7_32","normative"," That portion of a standard or specification that governs  implementation."]
["EIA632v11d7_33","operational scenario"," A sequence of events expected during operation of system products.  Includes the environmental conditions and usage rates as well as expected stimuli (inputs) and responses (outputs).  "]
["EIA632v11d7_34","performance requirement"," A requirement that defines how well the system products are required to perform a function, along with the conditions under which the function is performed."]
["EIA632v11d7_35","precedented","An end product that is a legacy product undergoing modification or a product that the enterprise both has the expertise to make and has similar products already in the market place."]
["EIA632v11d7_36","process"," A set of interrelated tasks that, together, transform inputs into outputs."]
["EIA632v11d7_37","product"," (1) An item that consists of one or more of the followinghardware, software, firmware, facilities, data, materials, personnel, services, techniques, and processes. (2) A constituent part of a system.  "]
["EIA632v11d7_38","project"," A development effort consisting of both technical and management activities for the purpose of engineering a system.  "]
["EIA632v11d7_39","prototype"," A model (physical, electronic, digital, analytical, etc.) of a product built for the purpose of a) assessing the feasibility of a new or unfamiliar technology; b) assessing or mitigating technical risk; c) validating requirements; d) demonstrating critical features; e) verifying a product; f) validating a product; g) determining enabling product readiness; h) characterizing performance or product features; or i) discovering physical principles.  "]
["EIA632v11d7_4","associated processes"," Processes that enable one or more end products to be put into service, maintained in service, or retired from service."]
["EIA632v11d7_40","requirement"," (1) Something that governs what, how well, and under what conditions a product will achieve a given purpose. (2) Normative elements that govern implementation of this Standard, including certain documents such as agreements, plans, or specifications. "]
["EIA632v11d7_41","requirements validation"," Confirmation by examination that requirements (individually and as a set) are well formulated and are usable for intended use. "]
["EIA632v11d7_42","risk","(1) A measure combining the uncertainty of reaching a goal with the consequences of failing to reach the goal. (2) The probability of suffering injury or loss."]
["EIA632v11d7_43","risk aversion"," The act of averting risk.  Averting risk can be through various means mitigation, avoidance, transfer, or acceptance."]
["EIA632v11d7_44","risk management"," An organized process for identifying and assessing risks, and for implementing means to avoid them or mitigate their effect if they occur.  "]
["EIA632v11d7_45","specification"," A document that contains specified requirements for a product and the means to be used to determine that the product satisfies these requirements.  "]
["EIA632v11d7_46","stakeholder","An enterprise, organization, or individual having an interest or a stake in the outcome of the engineering of a system.  "]
["EIA632v11d7_47","stakeholder requirement"," A requirement that represents what stakeholders of a system need or expect of the system products."]
["EIA632v11d7_48","standard"," A document that establishes engineering and technical requirements for products, processes, procedures, practices, and methods that have been decreed by authority or adopted by consensus."]
["EIA632v11d7_49","subsystem"," A grouping of items that perform a set of functions within a particular end product."]
["EIA632v11d7_5","building block"," A representation of the conceptual framework of a system that is used for organizing the requirements, work, and other information associated with the engineering of a system.  An element in the structured decomposition of the system."]
["EIA632v11d7_50","supplier"," Provides a product (either end products, enabling products, or both) or a group of products to an acquirer.  The supplier (external or internal to the acquirer’s organization) can be a vendor that has a product that does not need development, or a developer that must develop the desired system product or products."]
["EIA632v11d7_51","system","An aggregation of end products and enabling products to achieve a given purpose. "]
["EIA632v11d7_52","system technical requirement"," A requirement derived from one or more stakeholder requirements and stated in technical terms."]
["EIA632v11d7_53","technical performance measurement"," (TPM) The technique of predicting the future value of a key technical parameter of the higher-level end product under development, based on current assessments of products lower in the system structure."]
["EIA632v11d7_54","technical review","  An event at which the progress of the technical effort is assessed relative to its governing plans and technical requirements.  "]
["EIA632v11d7_55","test article"," An item built, constructed, coded, or otherwise implemented, for checking conformance to specified requirements or for checking validation against acquirer requirements for the item."]
["EIA632v11d7_56","traceability","The ability to identify the relationship between various artifacts of the development process, i.e., the lineage of requirements, the relationship between a design decision and the affected requirements and design features, the assignment of requirements to design features, the relationship of test results to the original source of requirements."]
["EIA632v11d7_57","unprecedented","A specific end product that is not known a priori, or the enterprise has limited experience in developing this type of system."]
["EIA632v11d7_58","user"," Individual, organization, or enterprise that uses, applies, or operates system products."]
["EIA632v11d7_59","validation","See end product validation and requirements validation."]
["EIA632v11d7_6","configuration management","  A management process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational management information throughout its life. ReferenceANSI/EIA-649."]
["EIA632v11d7_60","verification","See end product verification."]
["EIA632v11d7_7","constraint"," (1) A restriction, limit, or regulation imposed on a product, project, or process.   (2) A type of requirement or design feature that cannot be traded off."]
["EIA632v11d7_8","customer"," An individual, organization, or enterprise that (1) commissions the engineering of a system; (2) is a prospective purchaser of the end products of a system, or portions thereof; or (3) is an acquirer of a product."]
["EIA632v11d7_9","deliverable"," An item agreed to be delivered to an acquirer as specified in an agreement.  This item can be a document, a hardware item, a software item, a service, or any type of work product."]
["IDEF0_1","call","enable sharing of detail in other boxes, to provide additional information."]
["IDEF0_2","control","specificy conditions to product correct output."]
["IDEF0_3","function"]
["IDEF0_4","input","transformed or consumed to produce outputs."]
["IDEF0_5","mechanism","means that support execution."]
["IDEF0_6","output","data or objects produced."]
["IEEE_1220_1","constraint","A limitation or implied requirement which constrains the design solution or implementation of the systems engineering process, is not changeable by the performing activity, and is generally non allocable."]
["IEEE_1220_10","operations","The tasks, actions, and activities that are associated the use of the product or a life-cycle process."]
["IEEE_1220_11","part","The lowest element of a physical or system architecture, specification tree, or system breakdown structure that is not partitionable (bolt, nut, bracket, computer software unit)."]
["IEEE_1220_12","requirement","A statement which identifies a product or process limitation, capability, or physical characteristic."]
["IEEE_1220_13","state","A condition which characterizes the behavior of a function/sub-function or element at a point in time."]
["IEEE_1220_14","support","The tasks, actions, and activities to provide supply, maintenance, and support material and facility management for sustaining operations."]
["IEEE_1220_15","synthesis","The combining of information, concepts, constraints, components or elements to establish a complete and consistent system architecture, or to identify conflicts or deficiencies in established requirements or design solutions."]
["IEEE_1220_16","system","A set or arrangement of elements [people, products (hardware and software) and processes(facilities, equipment, material, and procedures)] that are related and whose behavior satisfies customer/operational needs, and provides for the life cycle sustainent of the products."]
["IEEE_1220_17","system architecture","The composite of the design architectures for products and their life cycle processes."]
["IEEE_1220_18","test","The tasks, actions, and activities for evaluating synthesis products against the functional architecture or requirements baseline, or the functional architecture against the requirements baseline."]
["IEEE_1220_19","training","The measurable tasks, actions, and activities (including instruction and applied exercises) required to achieve and maintain the knowledge, skills, and abilities necessary to efficiently and effectively perform operations, support, and disposal throughout the system life cycle."]
["IEEE_1220_2","development","The planning and execution of system and subsystem definition tasks required to evolve the system from customer needs to consumer product solutions and their life-cycle processes."]
["IEEE_1220_3","disposal","The tasks, actions, and activities to ensure that disposal or recycling of destroyed or irreparable consumer and life-cycle process products and by-products comply with applicable environmental regulations and directives."]
["IEEE_1220_4","distribution","The tasks, actions, and activities to initially transport, deliver, assemble, install, test, and checkout products to effect proper transition to users, operators, or consumers."]
["IEEE_1220_5","foundation architecture","The elements of the product design, including interfaces, which should be designed in such a manner that the adoption of new technologies or changes to the product design may be accomplished without major impacts to the system architecture."]
["IEEE_1220_6","interface","A contractual or area of responsibility boundary between/among systems and/or subsystems. (derived from interface specification)"]
["IEEE_1220_7","interface specification","The description of essential functional, performance, and design requirements and constraints at a common boundary between two or more system elements."]
["IEEE_1220_8","life cycle process","The eight essential functional processes (development, manufacturing, test, distribution, operations, support, training, disposal) that may be necessary to provide total consumer satisfaction and meet public acceptance. (abbrev)"]
["IEEE_1220_9","manufacturing","The tasks, actions, and activities for fabrication and assembly of engineering test models and brassboards, prototypes, and production of product solutions and their life cycle process products."]
["ISO15288_1 ","acquirer","the stakeholder that acquires or procures a system, product or service, from a supplier"]
["ISO15288_10 ","process","set of interrelated activities which transform inputs to outputs"]
["ISO15288_11 ","project","unique process, consisting of a set of co-ordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources"]
["ISO15288_12 ","resource","an entity that is utilized or consumed during the execution of a process"]
["ISO15288_13 ","stage","a period within the life cycle of a system that relates to the state of system description and/or the system itself"]
["ISO15288_14 ","stakeholder","an interested party having a right, share or claim in the system or in its possession of characteristics that meet that party’s needs and/or expectations"]
["ISO15288_15 ","supplier","an organization or an individual that enters into an agreement with the acquirer for the supply of a system, product or service"]
["ISO15288_16 ","system","a combination of interacting elements organized to achieve one or more stated purposes"]
["ISO15288_17 ","system element","any part of a system structure below the level of the current system"]
["ISO15288_18 ","system entity","any part of a system, in part or whole"]
["ISO15288_19 ","system-of-interest","the system whose life cycle is under consideration in the context of this International Standard"]
["ISO15288_2 ","activity","a set of actions that consume time and resources and whose performance is necessary to achieve, or contribute to, the realization of one or more outcomes"]
["ISO15288_20 ","system life cycle","the evolution with time of the system from conception through to retirement"]
["ISO15288_21 ","trade-off","decision-making actions that select from various requirements and alternative solutions on the basis of net benefit to the stakeholders"]
["ISO15288_22 ","user","individual or group who/that benefits from the system-of-interest in an operational capacity"]
["ISO15288_23 ","validation","confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled"]
["ISO15288_24 ","verification","confirmation, through the provision of objective evidence, that specified requirements have been fulfilled"]
["ISO15288_3 ","agreement","the mutual acknowledgement of terms and conditions under which a working relationship is conducted"]
["ISO15288_4 ","baseline","a specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures"]
["ISO15288_5 ","enabling system","a system that complements the system-of-interest during its life cycle stages"]
["ISO15288_6 ","enterprise","that part of an organization with responsibility to acquire and to supply products and/or services according to agreements"]
["ISO15288_7 ","facility","the physical means or equipment for facilitating the performance of an action, e.g. buildings, instruments, tools"]
["ISO15288_8 ","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"]
["ISO15288_9 ","operator","an individual or an organization who/that contributes to the functionality of a system and draws on knowledge, skills and/or procedures to contribute the function"]
["Janes86.1","requirement","Predicted future need spelt out by armed force, usually after long process of refinement and assessment of alternatives."]
["Janes86.2","system","1.  Generalized term for any dynamically functioning organization of man-made devices.\n2.  Portion of vehicle, eg aircraft, missile, etc, forming integral network of related and intercontrolled devices to accomplish set of specific related functions\n3.  Composite of equipment, skills and techniques capable of performing and/or supporting operational role (USAF)\n4.  Often used to mean (1) plus supporting equipment, documents, training devices, and all other products and services, as in weapon.\n5.  Incorrectly used to mean mere assemblage of mechanical parts, such as \"engine\"."]
["MDE.1","function","1. C43A quantity of value that depends upon the value of one or more other quantities.\n2. A specific purpose of an entity, or of its characteristic action.\n3. A means of referring to a type or sequence of calculations within an arithmetic statement."]
["MDE.10","test","A procedure or sequence of operations for determining the manner in which equipment is functioning or the existence, type, and location of any trouble."]
["MDE.2","system","1. An assembly of component parts linked together by some form of regulated interaction into an organized whole."]
["MDE.3","system","2. A collection of consecutive operations and procedures required to accomplish a specific objective."]
["MDE.4","system","3. A collection of units combined to work a larger integrated unit having the capabilities of all the separate units."]
["MDE.5","system","4. The complete computer assembly, with CPU, memory, I/O, plus any required devices or peripherals for the application intended."]
["MDE.6","system","5. A set of interconnected elements constituted to achieve a given objective by performing a specific function."]
["MDE.7","system engineering","A method of engineering analysis whereby all the elements in a system, including the process itself, are considered."]
["MDE.8","Validation","The process of verifying that execution of a system in its specified environment causes no operational problems.  Includes prevention, diagnosis, recovery, and correction of errors."]
["MDE.9","Verification","The process of checking the results of one data transcription against those of another, both transcriptions usually involving manual operations."]
["MetaH_1","Events","Events are enumeration literals in the source code that are used to name events that can be raised by software at run-time. MetaH event descriptions are included as part of the MetaH specification of any code module that refers to that event, where the event description gives the enumeration literal used in the source code."]
["MetaH_10","Types and type packages","Types and type packages must be coded and specified for hardware ports. These code modules are with'ed by the device driver code modules and are also named in the MetaH hardware specifications."]
["MetaH_11","Monitors","Monitors are collections of subprograms that provide an interface to hardware-dependent services, e.g. commands for a specialized coprocessor. Monitor source code comes in two pieces, the interface code to be included in an application process and the driver code to be included with the executive. The monitor specification names these code modules, and the MetaH software specifications identify which application processes are allowed access to that hardware monitor."]
["MetaH_12","Memories","Memories are passive blocks of physical memory. These may be shared between processors."]
["MetaH_13","Processors","Processors are active hardware entities that are capable of executing software processes. Developing a detailed MetaH processor specification requires writing some standardized interface code between the underlying real-time operating system or hardware and the executives configured from a MetaH specification. These interface code modules are named in the MetaH processor specification."]
["MetaH_14","Devices","Devices are active hardware entities that cannot host software processes but that may send or receive messages via ports, and may share memories with processors."]
["MetaH_15","Channels","Channels are hardware entities that connect processors and devices and are capable of supporting port-to-port message passing. Various kinds of hardware can perform this function, including portions of shared memory set aside for this purpose."]
["MetaH_16","Processes","Processes have their own virtual address spaces and are the fundamental units of scheduling, computation, safe/secure partitioning and fault containment. A process is typically an executable unit that can be individually compiled and linked by the underlying programming language toolset (i.e. process code modules can be compiled and linked into a program). In addition to any source objects specified as component objects of a process, a root code module must be written to control overall initialization and schedule sequencing.1"]
["MetaH_17","Macros","Macros are collections of processes, together with specifications of how the ports and events of those processes are connected together and specifications of how packages and monitors are shared between processes. Port connections are used to connect an output port to an input port. Event connections are used to connect an output event to an input event, to an aperiodic process, or to a mode (explained shortly). Monitor and package sharing is specified using an equivalence connection."]
["MetaH_18","Modes","Modes are also collections of processes, together with specifications of how the ports and events of those processes are connected together and specifications of how packages and monitors are shared between processes. The difference between a macro and a mode is that multiple macros are like multiple processes: they are all active concurrently with each other. In contrast, modes are mutually exclusive. An application can only execute in one mode at a time. Event connections are used to specify how events raised by software cause run-time changes between modes. A mode change may cause processes to be stopped, may cause processes to be started and initialized, and/or may change the pattern of port and event connections. It is possible to nest macros and modes within each other in a way that specifies submodes of operation, i.e. it is possible to specify a mode change that affects only a part of the application."]
["MetaH_19","Connections","Connections are used to specify how messages flow between ports, how events flow between processes and other objects, and how objects may be equivalenced and thus shared by other objects."]
["MetaH_2","Ports","Ports are statically declared variables in a code module. MetaH port descriptions are included as part of the MetaH specification of the containing code module. Port variables are used as message buffers, and the executive configured from a MetaH specification will move values in real-time between port variables according to connections made between port objects in the MetaH specification."]
["MetaH_20","Paths","Paths specify characteristics of an application that are used for various analysis purposes. A path of execution through component subprograms of a process is an example of something described using a path specification."]
["MetaH_21","system","Systems are the higher-level hardware objects used to describe groups of hardware entities. A system is a collection of processors, channels, memories and devices. Connection specifications are used to show how memories are shared among processors and how channels are used to connect processors.",null,null,"Verbatum \"systems\""]
["MetaH_22","Error models","Error models declare fault events that can occur in objects, error states that objects can be in, and error state transitions that objects may undergo in response to fault events. The particular error model used for source and hardware objects is an attribute of those objects."]
["MetaH_23","Applications","Applications are the highest-level objects in MetaH. An application identifies a software object and the hardware object on which that software is to be executed. Connections can be made between software and hardware ports, events and monitors."]
["MetaH_24","Memory","Memories are contiguous blocks of storage that may be contained exclusively within a single processor or may be shared by multiple processors. Memories are specified by the number of bytes and by the addressing scheme (i.e. byte addressed or word addressed)."]
["MetaH_25","Processor","Processor specifications describe a computer board built around a particular type of CPU, running a particular microkernel or real-time operating system, with a particular language cross development toolset. The processor interface denotes the interface to the board available for application software (I/O ports, interrupt events, monitors that provide hardware-specific service calls)."]
["MetaH_26","Device","A device is similar to a processor in the way that it can be connected to other hardware objects via shared channels and memories. A device cannot host any executable code. However, a device may share memory with one or more processors, so that code hosted on a processor may access device memory."]
["MetaH_27","Channel","A channel is a piece of hardware usable for bi-directional point-to-point communication between two processors or between a processor and a device. Ideally, channels provide contention-free communication with precisely characterizable timing properties. At each hardware clock interrupt, a processor will load a buffer with data, indicate to a channel that it should begin transmitting that data, then enter a busy-wait to receive notice that transmissions over that channel have completed. Because of this busy-wait, channel bandwidths must be relatively high in the current version."]
["MetaH_28","System","A system is a collection of processors and devices, together with declarations of connections between the ports and events of those processors and devices; and declarations of equivalences between the memories, channels and monitors of those processors."]
["MetaH_29","Port","This provides one mechanism for communication between software and hardware devices.  Ports may be declared in the interfaces to systems, processors and devices. Hardware ports produce and consume streams of data that may be connected to identically-typed ports declared in the software architecture specification."]
["MetaH_3","Types","Types are declarations of the types that have been used in the source code to declare port variables. MetaH type package specifications describe code modules that contain declarations of the types used for port variables. Port objects are typed in MetaH specifications just like the port variables are typed in the source code, and port-to-port connections specified in MetaH are type checked."]
["MetaH_30","Event","An out event should be declared for each hardware interrupt made available in the internal executive TARGET package (see the Software Design Document for the Honeywell Aerospace Compiled Kernel). In the absence of any explicit SourceName specification for a hardware event FOO, the hardware interrupt will be assumed to have been given the name TARGET.FOO during retarget of the executive. This event can be connected to an aperiodic process or mode in the software architecture specification, causing an occurrance of the hardware interrupt to dispatch an aperiodic process or change to a new mode. Interrupts are enabled only during those modes of operation in which the associated events are connected to something. This is in the process of changing so interrupt events are declared in code modules associated with devices."]
["MetaH_31","Monitor","Monitors included as part of the hardware specification allow software to make target-specific subprogram calls to target-specific service routines."]
["MetaH_32","Port Connections","Port connection declarations are used to identify the processor port(s) that correspond to a port in a system interface specification. Each software port connected to a hardware port may be ultimately connected to either a processor port, a system port, or a device port. If the ultimate destination is a system port, then the standard executive software on every processor in that configuration is generally required to support input and output via that system port.  Port connection declarations must obey the same rules as in software specifications."]
["MetaH_33","Event Connections","Event connection declarations are used to identify the processor event(s) that correspond to an event in a system interface specification. Each software event connected to a hardware event may be ultimately connected to either a processor event or a system event. If the ultimate destination is a system event, then the standard executive software on every processor in that configuration is generally required to be able to raise or respond to that system event.  Event connection declarations must obey the same rules as in software specifications."]
["MetaH_34","Equivalence Connections","In a hardware specification, equivalence connections can appear within a system implementation specification between pairs of memories, pairs of channels, or pairs of monitors.  Equivalence connections must obey the same rules as in software specifications."]
["MetaH_4","Type packages","Type packages are the code modules that contain declarations of types used for port variables. A MetaH specification of a type package includes descriptions of the individual types declared in that module. These code modules must obey certain coding guidelines. The tools will check for consistency between and type correctness within the source code and the MetaH specifications."]
["MetaH_5","Subprograms","Subprograms are source code functions, procedures or subprograms. A subprogram is any- thing that a thread of control can enter and, after executing for some specified time, exit. Subprograms are code modules (independently compileable units often stored in individual source files), and MetaH subprogram specifications can describe source objects of interest in a subprogram (e.g. events)."]
["MetaH_6","Packages","Packages are collections of subprograms and declarations of static (persistent) data objects. Packages are code modules (independently compileable units often stored in individual source files), and MetaH package specifications can describe source objects of interest in a package (e.g. subprograms, ports, events)."]
["MetaH_7","Monitors","Monitors are packages that obey certain special coding guidelines and for which special runtime semantics are provided. A monitor declares internal data structures and exports subprograms to manipulate those data structures (the recommended coding guideline is to write a monitor as an abstract data type object). Monitors normally would be shared by multiple processes. Unlike a shared package, a real-time semaphore will be created in the executive for each monitor in an application. The application source code can include calls to standard services to lock and unlock this semaphore. Among other things, a MetaH monitor description can specify the real-time semaphore protocol used for a monitor."]
["MetaH_8","Events","Events are hardware interrupts that might be raised by a processor, or events that hardware will respond to when raised by software. MetaH specifications of processors, devices and systems may include event descriptions, where hardware events can be connected to software objects in a MetaH specification."]
["MetaH_9","Ports","Ports can also be described in MetaH specifications of processors and systems and can be connected to software ports. The underlying hardware-dependent device driver code modules are named in the MetaH hardware specification."]
["PLCSApr01.1","requirement","Specified attributes"]
["PLCSApr01.10","Verification","Confirmation and provision of objective evidence that specified requirements have been fulfilled. "]
["PLCSApr01.11","product","Anything that is used or produced to satisfy a need (e.g., facilities, systems, hardware, software, firmware, data, processes, materials, services).  "]
["PLCSApr01.12","attribute","A characteristic of a product, can be either functional, physical or performance or a combination of these. "]
["PLCSApr01.2","characteristic","Distinguishing feature."]
["PLCSApr01.3","Analysis","The resolution or breaking up of something complex into its various simple elements; the exact determination of the elements or components of something complex.A statement of the result of such an operation. "]
["PLCSApr01.4","functional attributes","Measurable performance parameters including reliability, maintainability, and safety."]
["PLCSApr01.5","physical attributes","Quantitative and qualitative expressions of material features, such as composition, dimensions, finishes, form, fit, and their respective tolerances."]
["PLCSApr01.6","functional characteristics","Designed scope (i.e. sequence and essential qualities) of the operations to be performed by an item. Functional characteristics are expressed in terms of quantitative performance parameters such as range, speed, lethality, reliability, maintainability, safety; and operating and logistics parameters and their respective tolerances."]
["PLCSApr01.7","system","A set of interrelated or interacting elements"]
["PLCSApr01.8","system","Composite of subsystems, assemblies (or sets), skills, and techniques capable of performing and/or supporting an operational or non-operational role. A complete system includes related facilities, items, materiel, services and personnel required for its operation to the degree that it can be considered a self-sufficient item in its intended operational or non-operational and/or support environment."]
["PLCSApr01.9","Validation","Confirmation and provision of objective evidence that the requirements for a specific intended use or application have been fulfilled"]
["RMODP_1","<X> Domain","A set of objects, each of which is related by a characterizing relationship <X> to a controlling object. Every domain has a controlling object associated with it. The controlling object can determine the identities of the collection of objects which comprises the associated domain. The controlling object may communicate with a controlled object dynamically or it may be considered to have communicated in an earlier epoch (see 10.5) of the controlling object. Generally, the controlling object is not a member of the associated domain."]
["RMODP_10","Behavioural compatibility","An object is behaviourally compatible with a second object with respect to a set of criteria (see notes) if the first object can replace the second object without the environment being able to notice the difference in the objects' behaviour on the basis of the set of criteria.<BR><BR>Typically, the criteria impose constraints on the allowed behaviour of the environment. If the criteria are such that the environment behaves as a tester for the original object, i.e. the environment defines the smallest behaviour that does not constrain the behaviour of the original object, the resulting behavioural compatibility relation is called extension.<BR><BR>The criteria may allow the replacement object to be derived by modification of an otherwise incompatible object in order that it should be an acceptable replacement. An example of such a modification might be hiding of additional parameters on certain interactions. In this way, an interaction of the new object can be made to look like an interaction of the original object. In such cases behavioural compatibility is called coerced behavioural compatibility. If no modification is necessary, behavioural compatibility is called natural behavioural compatibility.<BR><BR>The concept of behavioural compatibility defined above on objects applies equally well to the behavioural compatibility of templates and of template types.<BR><BR>Behavioural compatibility is reflexive, but not necessarily symmetric or transitive (though it may be either or both)."]
["RMODP_11","Binding","A contractual context, resulting from a given establishing behaviour.  Establishing behaviour, contractual context and enabled behaviour may involve just two object interfaces or more than two.  An object which initiates an establishing behaviour may or may not take part in the subsequent enabled behaviour.  Enabled behaviour (and, by analogy, contractual context) may be uniform (i.e. each participating object can do the same as every other) or non-uniform (i.e. one participating object has a different role from another, as in client and server).  There is no necessary correspondence between an object which initiates establishing behaviour and a particular role in non-uniform enabled behaviours (e.g. in a client-server contractual context, either object could validly have initiated the establishing behaviour)."]
["RMODP_12","Binding behaviour","An establishing behaviour between two or more interfaces (and hence between their supporting objects)."]
["RMODP_13","Binding precondition","A set of conditions required for the successful execution of a binding behaviour.  The objects performing the binding behaviour must possess identifiers for all the interfaces involved in the binding. There may be additional preconditions."]
["RMODP_14","Causality","Identification of causality allows the categorization of roles of interacting objects. This clause gives a basic set of roles. ~~br~~Causality implies a constraint on each behaviour of the participating objects while they are interacting. Causality will be identified in the definition of classes (or sub classes) to which interacting objects belong, or in the refinement of templates for their classes (or subclasses)."]
["RMODP_15","Chain (of actions)","A sequence of actions within an activity where, for each adjacent pair of actions, occurrence of the first action is necessary for the occurrence of the second action."]
["RMODP_16","Class (of <X>s)","The set of all <X>s satisfying a type (see 9.7). The elements of the set are referred to as members of the class."]
["RMODP_17","Client object","An object which requests that a function be performed by another object."]
["RMODP_18","Communication","The conveyance of information between two or more objects as a result of one or more interactions, possibly involving some intermediate objects."]
["RMODP_19","Composite object","An object expressed as a composition. "]
["RMODP_2","<X> Group","A set of objects with a particular characterizing relationship <X>. The relationship <X> characterizes either the structural relationship among objects or an expected common behaviour of the objects."]
["RMODP_20","Composition","a) (of objects) A combination of two or more objects yielding a new object, at a different level of abstraction. The characteristics of the new object are determined by the objects being combined and by the way they are combined. The behaviour of a composite object is the corresponding composition of the behaviour of the component objects. b) (of behaviours) A combination of two or more behaviours yielding a new behaviour. The characteristics of the resulting behaviour are determined by the behaviours being combined and the way they are combined."]
["RMODP_21","Configuration (of objects)","A collection of objects able to interact at interfaces. A configuration determines the set of objects involved in each interaction. The specification of a configuration may be static or may be in terms of the operation of dynamic mechanisms which change the configuration, such as binding and unbinding (see 13.4)."]
["RMODP_22","Conformance point","A reference point at which behaviour may be observed for the purposes of conformance testing."]
["RMODP_23","Consumer object (with respect to communication)","An object which is a sink of the information conveyed.  The usage of this term does not imply any specific communication mechanism."]
["RMODP_24","Contractual behaviour","The concepts introduced here are illustrated in Figure 2."]
["RMODP_25","Contractual context","The knowledge that a particular contract is in place, and thus that a particular behaviour of a set of objects is required.  An object may be in a number of contractual contexts simultaneously; the behaviour is constrained to the intersection of the behaviours prescribed by each contractual context."]
["RMODP_26","Creation (of an <X>)","Instantiating an <X>, when it is achieved by an action of objects in the model. <X> can be anything that can be instantiated, in particular objects and interfaces. If <X> is an interface, it is either created as part of the creation of a given object, or as an additional interface to the creating object. As a result, any given interface must be part of an object."]
["RMODP_27","Data","The representation forms of information dealt with by information systems and users thereof."]
["RMODP_28","Decomposition","a) (of an object) The specification of a given object as a composition. b) (of a behaviour) The specification of a given behaviour as a composition. Composition and decomposition are dual terms and dual specification activities."]
["RMODP_29","Deletion (of an <X>)","The action of destroying an instantiated <X>. <X> can be anything that can be instantiated, in particular objects and interfaces. If <X> is an interface, it can only be deleted by the object to which it is associated."]
["RMODP_3","<X> Template","The specification of the common features of a collection of <X>s in sufficient detail that an <X> can be instantiated using it. <X> can be anything that has a type (see 9.7). An <X> template is an abstraction of a collection of <X>s. A template may specify parameters to be bound at instantiation time. The definition given here is generic; the precise form of a template will depend on the specification technique used. The parameter types (where applicable) will also depend on the specification technique used. Templates may be combined according to some calculus. The precise form of template combination will depend on the specification language used."]
["RMODP_30","Derived class/base class","If a template A is an incremental modification of a template B, then the template class CA of instances of A is a derived class of the template class CB of instances of B, and the CB is a base class of CA.<BR><BR>The criteria for considering an arbitrary change to be an incremental modification would depend on metrics and conventions outside of this Recommendation | International Standard. If the criteria allow, a derived class may have several base classes.<BR><BR>The incremental modification relating templates must ensure that self-reference or recursion in the template of the base class becomes self-reference or recursion in the template of the derived class. <BR><BR>The incremental modification may, in general, involve adding to or altering the properties of the base template to obtain the derived template.<BR><BR>Classes can be arranged in an inheritance hierarchy according to derived class/base class relationships. This is the interpretation of inheritance in the ODP Reference Model. If classes can have several base classes, inheritance is said to be multiple. If the criteria prohibit suppression of properties from the base class, inheritance is said to be strict.<BR><BR>It is possible for one class to be a subclass of a second class without being a derived class, and to be a derived class without being a subclass. The inheritance hierarchy (where arcs denote the derived class relation) and the type hierarchy (where arcs denote the subtype or subclass relation) are therefore logically distinct, though they may coincide in whole or in part."]
["RMODP_31","Dividing action","An action which enables two or more chains.  There are two cases of a dividing action, depending on whether the enabled chains are required to join eventually."]
["RMODP_32","Enabled behaviour","The behaviour characterizing a set of objects which becomes possible as a result of establishing behaviour.  The enabled behaviour will not necessarily be the same for all objects."]
["RMODP_33","Entity","Any concrete or abstract thing of interest. While in general the word entity can be used to refer to anything, in the context of modelling it is reserved to refer to things in the universe of discourse being modelled."]
["RMODP_34","Environment (of an object)","The part of the model which is not part of that object."]
["RMODP_35","Epoch","A period of time for which an object displays a particular behaviour. Any one object is in a single epoch at one time, but interacting objects may be in different epochs at the time of interaction. A change of epoch may be associated with a change in the type of the object, so as to support type evolution. Alternatively, a change of epoch may be associated with a phase in the behaviour of an object of constant type. For a distributed system to function correctly, the objects composing its configuration must be consistent. Thus, as the whole system evolves through a series of epochs, the individual objects which interact must never be in epochs in which their behaviours are sufficiently different that their concurrent composition leads to a failure. This concept will support the formalization of concepts of version and extensibility."]
["RMODP_36","Error","Part of an object state which is liable to lead to failures. A manifestation of a fault (see 13.5.3) in an object."]
["RMODP_37","Establishing behaviour","The behaviour by which a given contract is put in place between given objects. An establishing behaviour can be  a) explicit, resulting from the interactions of objects that will take part in the contract; or  b) implicit, being performed by an external agency (e.g. a third party object, not taking part in the contract) or having been performed in a previous epoch."]
["RMODP_38","Failure","Violation of a contract."]
["RMODP_39","Fault","A situation that may cause errors to occur in an object."]
["RMODP_4","Abstraction","The process of suppressing irrelevant detail to establish a simplified model, or the result of that process."]
["RMODP_40","Forking action","A dividing action, where the enabled chains must (subject to failure) eventually join each other, i.e. the enabled chains cannot join other chains and they cannot terminate separately."]
["RMODP_41","Function","Expressed formally in terms of the specification of the behavior of objects, which they support.   The expression \"use of a function”, is a shorthand for the interaction with an object which performs the function."]
["RMODP_42","Head action","In a given activity, an action that has no predecessor."]
["RMODP_43","Information","Any kind of knowledge, that is exchangeable amongst users, about things, facts, concepts and so on, in a universe of discourse.  Although information will necessarily have a representation form to make it communicable, it is the interpretation of this representation (the meaning) that is relevant in the first place."]
["RMODP_44","Initiating object (with respect to a communication)","An object causing a communication."]
["RMODP_45","Instance (of a type)","An <X> that satisfies the type."]
["RMODP_46","Instantiation (of an <X> template)","An <X> produced from a given <X> template and other necessary information. This <X> exhibits the features specified in the <X> template. <X> can be anything that has a type (see 9.7). The definition given here is generic: how to instantiate an <X> template depends on the specification language used. Instantiating an <X> template may involve actualization of parameters, which may in turn involve instantiating other <X> templates or binding of existing interfaces (see 12.4)."]
["RMODP_47","Interaction point","A location at which there exists a set of interfaces .  At any given location in time, an interaction point is associated with a location in space, within the specificity allowed by the specification language in use. Several interaction points may exist at the same location. An interaction point may be mobile."]
["RMODP_48","Interface","An abstraction of the behaviour of an object that consists of a subset of the interactions of that object together with a set of constraints on when they may occur.  Each interaction of an object belongs to a unique interface. Thus the interfaces of an object form a partition of the interactions of that object."]
["RMODP_49","Interface signature","The set of action templates associated with the interactions of an interface. An object may have many interfaces with the same signature."]
["RMODP_5","Action","Something which happens.  Every action of interest for modelling purposes is associated with at least one object.  The set of actions associated with an object is partitioned into internal actions and interactions. An internal action always takes place without the participation of the environment of the object. An interaction takes place with the participation of the environment of the object."]
["RMODP_50","Introduction (of an <X>)","Instantiating an <X> when it is not achieved by an action of objects in the model."]
["RMODP_51","Invariant","A predicate that a specification requires to be true for the entire life time of a set of objects."]
["RMODP_52","Joining action","An action shared between two or more chains resulting in a single chain."]
["RMODP_53","Liaison","The relationship between a set of objects which results from the performance of some establishing behaviour; the state of having a contractual context in common.  A liaison is characterized by the corresponding enabled behaviour."]
["RMODP_54","Location in space","An interval of arbitrary size in space at which an action can occur."]
["RMODP_55","Location in time","An interval of arbitrary size in time at which an action can occur."]
["RMODP_56","Object","A model of an entity. An object is characterized by its behaviour (see 8.6) and, dually, by its state (see 8.7). An object is distinct from any other object. An object is encapsulated, i.e. any change in its state can only occur as a result of an internal action or as a result of an interaction (see 8.3) with its environment (see 8.2). <BR><BR>An object interacts with its environment at its interaction points (see 8.11). <BR><BR>Depending on the viewpoint, the emphasis may be placed on behaviour or on state. When the emphasis is placed on behaviour, an object is informally said to perform functions and offer services (an object which makes a function available is said to offer a service). For modelling purposes, these functions and services are specified in terms of the behaviour of the object and of its interfaces (see 8.4). An object can perform more than one function. A function can be performed by the cooperation of several objects."]
["RMODP_57","Postcondition","A predicate that a specification requires to be true immediately after the occurrence of an action."]
["RMODP_58","Precondition","A predicate that a specification requires to be true for an action to occur."]
["RMODP_59","Producer object (with respect to communication)","An object which is the source of the information conveyed.  The usage of this term does not imply any specific communication mechanism."]
["RMODP_6","Activity","A single-headed directed acyclic graph of actions, where occurrence of each action in the graph is made possible by the occurrence of all immediately preceding actions (i.e. by all adjacent actions which are closer to the head)."]
["RMODP_60","Proposition","An observable fact or state of affairs involving one or more entities, of which it is possible to assert or deny that it holds for those entities."]
["RMODP_61","Reference point","An interaction point defined in an architecture for selection as a conformance point in a specification which is compliant with that architecture. Significant classes of reference point are identified in ODP; details of these, and of the relationship of modelling to conformance, are given in clause 15."]
["RMODP_62","Refinement","The process of transforming one specification into a more detailed specification. The new specification can be referred to as a refinement of the original one. Specifications and their refinements typically do not coexist in the same system description. Precisely what is meant by a more detailed specification will depend on the chosen specification language. For each meaning of behavioural compatibility determined by some set of criteria (see 9.4), a specification technique will permit the definition of a refinement relationship. If template X refines a template Y, it will be possible to replace an object instantiated from Y by one instantiated from X in the set of environments determined by the selected definition of behavioural compatibility. Refinement relationships are not necessarily either symmetric or transitive."]
["RMODP_63","Responding object","An object taking part in a communication, which is not the initiating object."]
["RMODP_64","Role","Identifier for a behaviour, which may appear as a parameter in a template for a composite object, and which is associated with one of the component objects of the composite object. Specification of a template as a composition of roles enables the instantiation process to be explained as the association of a specific component of the resultant composite object with each role. The association of a component object with a role may result from the actualization of a parameter."]
["RMODP_65","Server object","An object which performs some function on behalf of a client object.  Client/server relationships of a different nature (or level of abstraction) may exist between an object and different compositions of the objects with which it communicates."]
["RMODP_66","Service","Expressed formally in terms of the specification of the behavior of the interfaces, which they support.  A particular abstraction of behavior expressing the guarantees offered by a service provider."]
["RMODP_67","Spawn action","A dividing action, where the enabled chains will not join. The enabled chains may interact and they may terminate separately."]
["RMODP_68","Stability","The property that an object has with respect to a given failure mode if it cannot exhibit that failure mode. "]
["RMODP_69","State (of an object)","At a given instant in time, the condition of an object that determines the set of all sequences of actions in which the object can take part.  Since, in general, behaviour includes many possible series of actions in which the object might take part, knowledge of state does not necessarily allow the prediction of the sequence of actions which will actually occur.  State changes are effected by actions; hence a state is partially determined by the previous actions in which the object took part.  Since an object is encapsulated, its state cannot be changed directly from the environment, but only indirectly as a result of the interactions in which the object takes part."]
["RMODP_7","Architecture (of a system)","A set of rules to define the structure of a system and the interrelationships between its parts."]
["RMODP_70","Subactivity","A subgraph of an activity which is itself an activity and which satisfies the following condition. For any pair of fork-join actions in the parent acitivity, if one of these actions is included in the subgraph, then both must be included in the subgraph."]
["RMODP_71","Subclass/superclass","One class A is a subclass of another class B, and B is a superclass of A, precisely when the type associated with A is a subtype of the type associated with B."]
["RMODP_72","Subdomain","A domain which is a subset of a given domain."]
["RMODP_73","Subtype/supertype","A type A is a subtype of a type B, and B is a supertype of A, if every <X> which satisfies A also satisfies B. The subtype and supertype relations are reflexive, transitive and anti-symmetric."]
["RMODP_74","System","Something of interest as a whole or as comprised of parts. Therefore a system may be referred to as an entity. A component of a system may itself be a system, in which case it may be called a subsystem."]
["RMODP_75","Template class (of an <X>)","The set of all <X>s satisfying an <X> template type, i.e. the set of <X>s which are instances of the <X> template. <X> can be anything that has a type (see 9.7). Each template defines a single template class, so we may refer to instances of the template as instances of the template-class. The notion of class is used to refer to a general classification of <X>s. Template class is a more restrictive notion where the members of a template class are limited to those instantiated from the template (or any of its subtypes), i.e. those <X>s which satisfy the <X> template type."]
["RMODP_76","Template type (of an <X>)","A predicate defined in a template that holds for all the instantiations of the template and that expresses the requirements the instantiations of the template are intended to fulfill. The object template subtype/supertype relation does not necessarily coincide with behavioural compatibility. Instances of a template type need not be behaviourally compatible with instantiations of the associated template. They do coincide if a) a transitive behavioural compatibility relation is considered, and b) template subtypes are behaviourally compatible with their template supertypes."]
["RMODP_77","Terminating behaviour","The behaviour which breaks down a liaison and repudiates the corresponding contractual context and the corresponding contract.  A terminating behaviour must be explicitly identified as such in the contract if the establishing behaviour was explicit."]
["RMODP_78","Thread","A chain of actions, where at least one object participates in all the actions of the chain.  An object may have associated with it one single thread or many threads simultaneously."]
["RMODP_79","Trace","A record of an object's interactions, from its initial state to some other state. A trace of an object is thus a finite sequence of interactions. The behaviour uniquely determines the set of all possible traces, but not vice versa. A trace contains no record of an object's internal actions."]
["RMODP_8","Atomicity","An entity is atomic at a given level of abstraction if it cannot be subdivided at that level of abstraction.  Fixing a given level of abstraction may involve identifying which elements are atomic."]
["RMODP_80","Trading","The interaction between objects in which information about new or potential contracts is exchanged via a third party object. It involves:  a) exporting: the provision of an identifier to an interface which is claimed to meet some statement of requirements (i.e. offer a potential contract);  b) importing: the provision of an identifier to an interface which matches a given statement of requirements, allowing a future binding behaviour to take place (i.e. the establishment of a contract)."]
["RMODP_81","Type (of an <X>)","A predicate characterizing a collection of <X>s. An <X> is of the type, or satisfies the type, if the predicate holds for that <X>. A specification defines which of the terms it uses have types, i.e. are <X>s. In RM-ODP, types are needed for, at least, objects, interfaces and actions.  The notion of type classifies the entities into categories, some of which may be of interest to the specifier (see the concept of class in 9.8)."]
["RMODP_82","Unbinding behaviour","A behaviour that terminates a binding, i.e. a terminating behaviour for the binding."]
["RMODP_83","Viewpoint (on a system)","A form of abstraction achieved using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within a system."]
["RMODP_9","Behaviour (of an object)","A collection of actions with a set of constraints on when they may occur.  The specification language in use determines the constraints which may be expressed. Constraints may include for example sequentiality, non-determinism, concurrency or real-time constraints.  A behaviour may include internal actions.  The actions that actually take place are restricted by the environment in which the object is placed."]
["SED 499A","Systems Engineering","the application of scientific and engineering efforts to:\n transform an operational need into a description of system performance parameters and a system configuration through the use of an iterative process of definition, synthesis, analysis, design, test and evaluation.\n Integrate related technical parameters and ensure compatibility of all physical, functional and program interfaces in a manner that optimises the total system definition and design.\n Integrate reliability, maintainability, safety, survivabiltiy, human engineering and other such factors into the total engineering effort to meet cost, schedule, supportability and technical performance objectives."]
["SED 499B","Systems Engineering","Systems engineering is an interdisciplinary approach to evolve and verify an integrated and optimally balanced set of product and process designs that satisfy user needs and provide information for management decision making. "]
["SED ESP5409","requirement","A condition or capability that must be met or possessed by a system or system component to satisfy a contract standard specification or other formally imposed document. "]
["SED IEEE 729.1","function","A subprogram that is invoked during the evaluation of an expression in which its name appears and that returns a value to the point of invocation, Contrast with subroutine."]
["SED IEEE 729.2","System Architecture","The structure and relationship among the components of the system. The system architecture may also include the system’s interface with its operational environment. "]
["SED IEEE 729.3","System Design","The process of defining the hardware and software architectures, components modules, interfaces and data for a system to satisfy specified system requirements. "]
["SED IEEE P1061","functionality","The existence of certain properties and functions that satisfy stated or implied needs of users. "]
["SED IEEE1063","function","A specific purpose of an entity or its characteristic action"]
["SED MP","Systems Engineering","is a hybrid methodology that combines policy analysis, design and management. It aims to ensure that a complex man-made system, selected from the range of options on offer, is the one most likely to satisfy the owner’s objectives in the context of long term future operational or market environments"]
["SEDRES Ref 1:","Systems Engineering","The application of methods and tools to the development and production of (reliable and maintainable) systems. "]
["SEDRES.1","functional requirement","The stated required active functionality of a system or product",null,null,"Verbatum 'Functional Requirements'"]
["SEDRES.2","Dynamic Functionality","A description of a set of requirements of the design which includes timing and behavioural information."]
["SEDRES.3","behavior","The dynamic properties of a function or a system.",null,null,"Verbatum \"behaviour\""]
["SEDRES.4","system","An assembly of interacting, active components or elements forming a whole."]
["SECMv8_1 ","Decomposition","In the Concept Model an aggregationn symbol is used with the letter \"C\" imposed on it. This has the meaning that the decomposition is complete in the sense that all of the parts that comprise the whole are listed. ","x","Conflict","With RMODP"]
["SECMv8_2 ","se_thing","That which is discernable by reproducible measurement of its characteristics.","x","No ref"]
["SECMv8_3 ","category","Categories provide the grouping of SE_Things into a set based on defined properties that serve as selection criteria for which SE_Things of all those in the universe belong in that set. ","x","No ref"]
["SECMv8_4 ","Inclusive/Complete Category","Any SE_Thing of the super category may reside in any number of the sub-categories and all members of the super-category are members of at least one of the sub-categories.","x","No ref"]
["SECMv8_5 ","Inclusive/Incomplete Category","Any SE_Thing of the super category may reside in any number of the sub-categories and only some members of the super-category are members of the sub-categories.","x","No ref"]
["SECMv8_6 ","Exclusive/Complete Category","Any SE_Thing of the super-category may reside in one and only one of the sub-categories and all members of the super-category are members of at least one of the sub-categories.","x","No ref"]
["SECMv8_7 ","Exclusive/ Incomplete Category","Any SE_Thing of the super-category may reside in one and only one of the sub-categories and only some members of the super-category are members of the sub-categories.","x","No ref"]
["SECMv8_8 ","domain-of-Interest","All SE_things of interest to the problem at hand. ","x","No ref"]
["SECMv8_9 ","system","SE_Things with a well defined interface, both static and dynamic, with respect to the Domain of Interest.","x","Conflict","a) Definition misses key aspects\nb) Other better definitions e.g. ISO15288, EIA632"]
["SECMv8_10 ","system _view","A collection of SE_Things and related information about the system that are useful and defined for a particular purpose in a particular context. ","x","No ref"]
["SECMv8_11 ","environment","All SE_Things external to the system that interact with it. ","x","Conflict","SECM definition uses SE_thing, while 632 definition says same thing without using the specific term. RMODP_34 definition too specific."]
["SECMv8_12 ","stakeholder","The people, organizations and institutions that are a part of the system environment because the System provides some benefit to them and they have an interest in the system.","x","Conflict","a) Definition is obscure\nb) DERA_53, EIA632, ISO15288 all better and more succinct."]
["SECMv8_13 ","stakeholder_need","The benefits That the Stakeholders wish to be satisfied by or delivered by the system when it is implemented and functioning.","x","No ref"]
["SECMv8_14 ","property","Any named measurable or observable attribute, quality or characteristic of an se_thing.","x","Conflict","DWO's previous definition avoids use of SE_thing"]
["SECMv8_15 ","system requirement","A statement of properties that a system shall exhibit or shall not exhibit when completed. ","x","Conflict","a) Verbatum system_requirement\nb) see IEEE_100_31"]
["SECMv8_16 ","property_reference","A statement of the sources of information concerning the property, its trensor characteristics, its units, its value, variance, or probability distribution.","x","No ref"]
["SECMv8_17 ","behavior","What an SE_Thing is to do or is not to do in response to excitations it receives from the external SE_Things in its environment..","x","Conflict","a) Do you need stimulus to exhibit behaviour? No.\nb) other definitions preferable, see DERA_8"]
["SECMv8_18 ","physical property","What an SE_Thing exhibits or does not exhibit in response to excitation and stimulation from auxiliary measurement entities that are not part of its context. ","x","No ref","Verbatum \"physical_property\""]
["SECMv8_19 ","structure","The decomposition, interconnection and other static relationship among the parts of the system.","x","No ref"]
["SECMv8_20 ","system_assembly","The static parts of the system including their interconnection and inerconnection descriptions.","x","Conflict","Although no direct ref exists (to system_assembly) the definition is uncannily similar to 'system architecture' definitions from IEEE100, IEEE1220, SED IEEE 729 (although 'static' appears in this definition)."]
["SECMv8_21 ","link","A particular kind of system assembly that is used when it is helpful not to model or specify its details.","x","No ref"]
["SECMv8_22 ","port","A connection point on a system assembly in the system assembly decomposition hierarchy. ","x","Conflict","See MetaH-29, although it is 'wordy'. MetaH also has 'ports' (twice)."]
["SECMv8_23 ","interconnection","A listing of the ports that interconnect with one another.","x","No ref"]
["SECMv8_24 ","interface_description"," A description of a Port of a System Assembly that includes the geometric description, I/O description, protocols that must be met, assemblies of parts required to join two ports, allowable defect characteristics, etc. ","x","Conflict","a) See Interface specification from IEEE1220\nb) should focus on definition of 'interface', 'interface description' then follows."]
["SECMv8_25 ","function","The entity in the context of modeling that transforms an input set of SE_Things into a set of output SE_Things that may be the same or measurably different from the input set.","x","Conflict","1) Unnecessary reference to SE_things, \n2) last clause unnecessary\n3) has 'transforming' focus on function (can have functions that maintain status quo)\n4) several adequate definitions exist (e.g. IEEE100, INCOSE98/AP233reqv12, EIA632)"]
["SECMv8_26 ","input_output","SE_Things consumed by a function are Inputs and those generated by a function are Outputs. ","x","Conflict","IDEF0 has (separate) definitions for input and output."]
["SECMv8_27 ","function_ordering","Function Ordering imposes how functions execute, which may be sequential, concurrent, traversed iteratively, or lie on separate alternative paths.","x","No ref"]
["SECMv8_28 ","internal _function","A kind of function that is allocated to and implemented by System/Structure.","x","No ref","However, should follow simply from definnition of function, and how we scope what is internal versus external."]
["SECMv8_29 ","external_ function","A kind of function that is allocated to and implemented by SE_Things in the environment. ","x","No ref","However, should follow simply from definnition of function, and how we scope what is internal versus external."]
["SECMv8_30 ","unit","Establishes the standard of measure against which the values of physical_properties shall be stated.","x","No ref","Establishes'? Delete the word."]
["SECMv8_31 ","property_value","A numeric value assigned to  a physical_property","x","No ref","Assigned to'? The value (numeric, vector, discrete valued term or other representation) of the property in the defined units."]
["SECMv8_32 ","required_budgeted_property_value","A property value aloocated to a system_assembly by a requirement, or budgeted to that system_assembly by analysis.","x","No ref"]
["SECMv8_33 ","calculated_property_value","A property value of a whole calculated or estimated from the values of the parts that assemble to make the whole.","x","No ref"]
["SECMv8_34 ","target_budget_property_value","A temporary property value used by a designer as the design work proceeds and different design alternatives are considered. ","x","No ref"]
["SECMv8_35 ",null,null,"x","No ref","Duff entry by JJ"]
["SECMv8_36 ","measured_property_vsalue","A property_value established by measurement of an actual part.","x","No ref"]
["SECMv8_37 ","model_parameter","a formally declared variable of the analytical model provided for an external application to populate at execution time in a computing environment","x","No ref","Seems a very specific interpretation of 'model_parameter', why all the 'provided for…' text?"]
["SECMv8_38 ","parameter_assignment","Provides actual values for characteristics declared formally by the model_parameter.","x","No ref","A process? A concept?"]
["SECMv8_39 ","analytical_representation","Is the association of specific properties of specific system assemblies with an analytical_model in order to unambiguously characterize the performance of a specific system_assembly.","x","No ref","Definition with 'the association of' appears not consistent with that inferred from the concept name."]
["SECMv8_40 ","analytical_model","Provides a mathematical description of the properties of a system. ","x","No ref","Should be 'of selected properties…'."]
["SECMv8_41 ","functional requirement","States what the shall be done by the system to which it is allocated.","x","Conflict","a) Verbatum was 'functional_requirement'\nb) …to which it is allocated superfluous\nc) other definitions preferable (DERA, or EIA632)"]
["SECMv8_42 ","temporal_requirement","States a time duration or a time probability for the completion of a functional requirement","x","No ref","Verbatum 'temporal_requriement'"]
["SECMv8_43 ","physical_property_requirement","States a Physical Property that shall be exhibited by the System or System Asseembly to which it is assigned.","x","No ref"]
["SECMv8_44 ","interface requirement","States the characteristics of the Interface to which it is assigned. Note that it includes the geometric description, I/O description, protocols that must be met, assemblies of parts required to join two ports, allowable defect characteristics, etc.","x","Conflict","a) verbatum 'interface_requirement' \nb) First part of current definition ignores it is a requirement (statement of need), implies statement of fact.\nc) although there is one other definition (EIA632), this definition more comprehensive"]
["SECMv8_45 ","imposed_design_requirement","States particular SE_Things that shall be used in the desiign oof the System or System Assembly","x","No ref"]
["SECMv8_46 ","reference_requirement","States a reference to a source of additional requirements that shall be met by the System or System Assembly. Note that the referenced source may be a requirements document, government requirements for safety, security, environmental quality, etc., or a state or federal law.","x","No ref","Difficult to distinguish from reference_source"]
["SECMv8_47 ","reference_source","Any requirements document, government regulation or law that contains applicable requirement.","x","No ref","Difficult to distinguish from reference_requirement"]
["SECMv8_48 ","effectiveness measure","States an optimization condition that a system shall meet. Note that Requirements_S define the domain of the solution, the solution space. The Effectiveness Measures drive the solution to a particular region in that space. The effectiveness measures are tightly related to stakeholder Needs. Example: the requirements differences between a PC and a laptop are largely in the laptop optimization conditions for lminimum weight, minimum thickness, and maximum battery life. These critiera are some of those that customers (one of the kinds of stakeholder) consider in deciding what to purchase. ","x","Conflict","a) Verbatum was 'effectiveness_measure'\nb) much of 'definition' is explanation or example.\nc) although one other (IEEE100) definition exists, it could be improved."]
["SECMv8_49 ","optimization_direction","States the direction of optimization, maximize or minimize, for an Effectiveness Measure. Example: for a laptop computer weight and thickness are minimized and battery life is maximized. ","x","No ref","Part of 'definition' is an example."]
["SECMv8_50 ","weight","Relative importance of a particular Effectriveness Measure. Note; weights are often expressed in a numerical form. Example: they fix the relative importance in trade off weight, thickness, and battery life. How many minutes of battery life are worth how many tenths of a pound in weight.","x","No ref","Grammar in Example suspect."]
["SECMv8_51 ","regularization_function","an analytic expression that combines effectiveness measures with weights to produce a simgle number for the goodness of a design option. Note: this corresponds to the regularization function used in optimal control design and in statistical optimization of processes. ","x","No ref","JJ: still struggling to find evidence that this is an accepted 'industry term'."]
["SECMv8_52 ","verification_requirement","Statement of how a system design or instance shall be shown by the development organization using test, analysis, inspection ,  demonstration, simulation, similarity, sampling, or other method to meet a requirement allocated to the system. Note that this is a requirement on the development organization and not on the system. Note that this is performed to confirm that the deployed system will meet the requirements.","x","No ref","There are Notes in definition text."]
["SECMv8_53 ","verification_event","Occurrence (with date, performer and result) of a comparison of a requirement against the test, analysis, or inspection results of a design or instance of a system.","x","No ref","Verbatum 'verification _event'"]
["SECMv8_54 ","verification_procedure","Describes the process used to compare a requirement against the test, analysis, or inspection results of a design or instance of a system. Example: for a complex digital system the procedure may require the application of a suite of test vectors to the digital system along with environmental tests involving temperature stress and vibration. Example: for a complex metal system the the procedure may require the application of several nondestructuve tests to ensure that there are no flaws preset that will cause failure.","x","No ref","But pseudonym for 'verification', the more widely used term."]
["SECMv8_55 ","verification_configuration","Arrangement of system and infrastructure necessary to perform the test, analysis, or inspection of a design or instance of a system.","x","No ref","What does this add? All aspects of the design, verification, use, maintenance and disposal are subject to configuration control."]
["SECMv8_56 ","verification_plan","The schedule of tasks, task durations, start times, end times, task inputs, task outputs, goals, and resources (both personnel and infrastructure) to perform the test, analysis, or inspection of a design or instance of a system.","x","No ref"]
["SECMv8_57 ","organization","Description of the roles of persons in a group or team. Note that this is a subclass of System Assembly, definition (19).","x","Conflict","a) See DERA_34\nb) Organisation is the concept, not the description of the organisation."]
["SECMv8_58 ","issue","Any question raised concerning the system or the system development.","x","No ref"]
["SECMv8_59 ","risk","Likelihood and impact of failure to meet any technical or development program goal. ","x","Conflict","See EIA632v11d7_42 (1)"]
["SECMv8_60 ","verification_status","Describes the state of a Verification Requirement as Not Yet Planned, Planned, In Progress, Completed - Satisfactory,or  Completed - Unsatisfactory. Example: for a complex digital system the procedure may require the application of a suite of test vectors to the digital system along with environmental tests involving temperature stress and vibration. Example: for a complex metal system the the procedure may require the application of several nondestructuve tests to ensure that there are no flaws preset that will cause failure.","x","No ref"]
["SECMv8_61 ","validation_requirement","Statement of how a system requirement, design or instance shall be shown by the development organization to meet Stakeholder Needs. Note that this is to confirm that the requirements are suitable for the marketplace. ","x","No ref"]
["SECMv8_62 ","validation_event","Occurrence (with date, performer and result) of a comparison of a Requirement against the stakeholder needs.","x","No ref"]
["SECMv8_63 ","validation_procedure","Describes the process used to compare a Requirement against Stakeholder Needs. Note that this is a requirement on the development organization and not on the system. Note that the procedures may include stakeholder and market surveys, and test marketing.","x","Conflict","The term 'validation' appears more widespread."]
["SECMv8_64 ","validation_infrastructure","Arrangement of requirement information and related infrastructure necessary to asses corresondance with stakeholder needs and market realities.","x","No ref"]
["SECMv8_65 ","validation_plan","The schedule of tasks, inputs, outputs, goals, and resources, both personnel and infrastructure to perform the comparison of Requirements against Stakeholder Needs..","x"]
["SECMv8_66 ","validation_status","Describes the state of a Validation Requirement as Not Yet Planned, Planned, In Progress, Completed - Satisfactory, or  Completed - Unsatisfactory. Note: entire new product lines have been abandoned after completed development because of unsatisfactory consumer panel responses and unsatisfactory test marketing. ","x","No ref"]