08/31/2002, DWO	Semantic Dictionary for Concept Model, Draft #7
Number	Name	Definition
	Decomposition	One of the aggregation operations used here is not included in UML1.X. It is indicated with the usual open diamond with the letter C imposed on it. It has the meaning that the decomposition is complete in the sense that all of the parts that comprise the whole are listed. If all of the parts are taken away there is nothing left. If the mass of all the parts is added it is the mass of the whole. this concept of aggregation is essential in giving parts lists to manufacturing - they must know all the parts.
	Category	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. Explanation: It is categorization that enables us to define alternatives and create taxonomies for libraries. This is one of the forms of generalization/specialization. Note that this is NOT INHERITANCE as found in object-oriented software languages. Physical SE_Things, matter and energy, do not inherit their properties. Rather they posses the properties of themselves and can be identified by measurement of those properties. For a discussion of these issues in computer science see the work of Barbara Liskov on abstract data types and the CLU language. See set theory.
	Sub-categories of Category
	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.
	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.
	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.
	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.
(1)	SE_Thing	That which is discernable by reproducible measurement of its characteristics. Note: The semantic term SE_Thing includes matter, energy and information. Examples: Any thing from microscopic particles to galaxy clusters is an SE_Thing.  Any thing with a finite existence from galaxies with billion-year lives to trans-uranic elements with lifetimes less than nano-seconds. Counter-example: Things like ghosts, devils, the Loch Ness Monster, the city of Atlantis are not discernable by reproducible measurement and are excluded. Things under R&D that do not yet have reproducible measurements and process control are excluded. Silicon for electronic devices would be excluded in 1900.
		Product relationship to SE_Thing is discussed next. Product from ISO 10303-Part 1 STEP definitions provide product: a thing or substance produced by a natural or artificial process. We need to define the informational attributes associated with the entity named "product" as defined within Product Identification Module 1017. This entity named "product" has attributes that enable one to capture: id, name and description.  AM 1017 provides the definition: A Product is the identification of a product or of a type of product. It is a collector of data common to all revisions of the Product. SE_thing appears to be a legitimate subclass of product because AP233 requires reproducible measurement of SE_Thing.
(2)	Domain of Interest	All SE_things of interest to the problem at hand. Note: these include the system, the environment, external systems of interest in the environment, stakeholders, enabling things, things that may cause failure, and all other things of interests.
(3)	System	SE_Things with a well defined interface, both static and dynamic, with respect to the Domain of Interest. Explanation: A system is composed of interacting components and the emergent behaviors and properties of the system are the result of the properties and behaviors of the components and their interactions. These interactions may be highly nonlinear. Note systems decompose hierarchically; they are systems of systems. this is inherited from SE_Thing.
(4)	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. Examples: Engineers involved in specification, design, manufacturing and maintenance need a particular collection of information to do their work. An engineer working on the cooling system of an engine needs information about a particular set of parts, behaviors and properties that are particular to that engineering problem. The set of possibly useful system views is very large.
(5)	Environment	All SE_Things external to the system that interact with it. Note: It is often possible to limit the parts of the environment needed for development purposes to those external systems that are neighbors to the system. Note that the environment includes not only the external systems that couple with it for useful purposes, but they also include all external systems that may interact in a manner that causes failure.
(6)	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. Note: They include, for example, the producers, owners, operators, users, and maintainers of the system.
(7)	Stakeholder Need	The benefits That the Stakeholders wish to be satisfied by or delivered by the system when it is implemented and functioning. Note: At the top level of development these needs drive the requirements for the system and the optimization criteria for its development.
(8)	Property	Any named measurable or observable attribute, quality or characteristic of an se_thing.
(9)	Requirement_S	A statement of properties that a system shall exhibit or shall not exhibit when completed. Note: requirements are derived from requirements in a many-to-many relationship.
(10)	Property Reference	A statement of the sources of information concerning the property, its trensor characteristics, its units, its value, variance, or probability distribution.
	The following three entities are subclasses of Property based on what is measured.	Rationale: Property is usefully decomposed into several categories – the measurable characteristics in normal use, the measurable characteristics that require additional instrumentation for measurement, and the observable structure. Acceleration of a car is in the first category, behavior, and can be observed in normal operation of the car. Weight of the car is not directly observable in the use of the car and requires that the car be placed on a large scale to make the observation. That a car has four wheels, steering wheel on the left, and a sun roof are directly observable structural properties.
(11)	System 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. Example: Make a fender is a behavior with several function steps, inputs of sheet steel, power, paint primer, and paint and the out put of a fender. Note: it is a systems engineering best practice to separate behavior from structure (function from form) and to allocate behavior to structure based on trade studies.
(12)	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. Explanation and examples: Responses of an SE_Thing like mass, power consumption, MTBF, etc. are critically important and appear in requirements. They cannot be measured by observation of the SE_Thing in use without the aid of auxiliary equipment.
(13)	System Static Structure	The decomposition, interconnection and other static relationship among the parts of the system. Note: physical properties are budgeted to structure using analysis methods, and the emergent performance is calculated using the same methods. Behavior is allocated to the structure. Form and function are separated conceptually so that the design can be optimized by considering several different structures that can provide the desired emergent behavior and properties.
(14)	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. It is a part of Behavior. Explanation: This is what functions do in mathematics where the I/O are variables and constants. In software the I/O is data. In systems engineering the I/O are SE_Things. Example for systems engineering: The function may be “burn gasses” with an input of two moles of hydrogen and one mole of oxygen. The output will be one mole of water, distinctly different from the inputs and a lot of energy. This function may be followed by a function “cool to 90 degrees centigrade”. The input had pressure and volume proportional to temperature; the output is now liquid with a well-defined volume, an isotropic compressibility and a viscosity. If the next function is “cool to –10 degrees centigrade”, then the viscosity goes away and the compressibility becomes a fourth rank tensor relating stress to strain.
		Note that in the general case outputs are different things than inputs, and physical_properties, behaviors, values, variances and probability distributions can all change. Note that in this general definition “Function” is an SE_Thing of type information and cannot be realized in the physical world except through SE_Things of type matter or energy that exhibit that function. In the physical world things transform other things. It is this fact of reality that results in the allocation of Function to structure which is really a statement that this particular structure entity exhibits this particular function and it will be used to provide that transformation. The thought pattern is to think of the desired transformation, Function, to consider alternative things that might be used to provide it, and to select among these, using a trade study based on optimization.
(15)	Input/Output	SE_Things consumed by a function are Inputs and those generated by a function are Outputs. The name Input/Output or I/O is used because a given I/O entity is generated by one function and consumed by another. It is a part of Behavior.
(16)	Function Ordering	Function Ordering imposes how functions execute, which may be sequential, concurrent, traversed iteratively, or lie on separate alternative paths. It is a part of Behavior. Note that there are several ways to represent function ordering. It may be done with ordering operators and triggering I/O as in classical behavior diagrams or it may be done with events, states, and transitions as done in state machines and state charts. For this fine level of detail it is necessary to intercompare the detailed models in SEDRES and those emerging from UML 2.0 development.
(17)	Internal Function	A kind of function that is allocated to and implemented by System/Structure. For each I/O there are two such functions, one that generates it and one that consumes it.
17)
(18)	External function	A kind of function that is allocated to and implemented by SE_Things in the environment. These functions act as sources and sinks of I/O and hence I/O is associated with one function.
(19)	System Assembly	The static parts of the system. Physical Property is assigned to them. Note that many persons think of these as components, but manufacturing thinks of them as assemblies because they build assemblies. Assembly is a standard ISO naming convention. It may be desirable to alias this name. Note: physical properties are budgeted to structure using analysis methods, and the emergent performance is calculated using the same methods. Behavior is allocated to the structure. Form and function are separated conceptually so that the design can be optimized by considering several different structures that can provide the desired emergent behavior and properties.
(20)	Port	A connection point on a system assembly in the system assembly decomposition hierarchy. Ports connect to ports. Explanation: systems interconnect with one another port-to-port. Example: Consider a ultrasonic transmitting transducer coupled to a water tank and a receiver transducer coupled to the tank. The transmitter port connects to a water port and couples sound energy into the water. The intensity at any point is a result of the impedance match between the two ports, the radiation pattern of the transducer, and the attenuation and dispersion in the water. The receiving transducer is attached to another port of the water. The received signal is dependant on the relative impedance of the two ports, the sound distribution in the water, and the radiation pattern of the receiving transducer. This example is often oversimplified as "broadcast" neglecting the port to port conditions and the properties of the medium and neglecting the ports. Note ports couple to desired things in the environment and also to the ports of things that cause failure, threaten security or safety.
(21)	Interface	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. Examples: Parts interact physically through direct physical contact, exchange of SE_Things, and through forces they exert such as gravity, compression or torque. Thus I/O is bound to ports and described by interfaces. The interface may consist of more than the two ports and may involve an assembly of parts as in the case of two flanges that are assembled with six bolts and an O-ring. The interface may also require detailed description to define what occurs there or how it is maintained. For two ports to connect, their interfaces must be compatible.
(22)	Functional Requirement	States what the shall be done by the system to which it is allocated.
(23)	Temporal Requriement	States a time duration or a time probability for the completion of a functional requirement
(24)	Physical Property Requirement	States a Physical Property that shall be exhibited by the System or System Asseembly to which it is assigned.
(25)	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.
(26)	Imposed Design Requirement	States particular SE_Things that shall be used in the desiign oof the System or System Assembly
(27)	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.
(28)	Reference Source	Any requirements document, government regulation or law that contains applicable requirement.
(29)	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.
(30)	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.
(31)	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.
(32)	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.
		The following definitions apply to Systems Engineering Management
(33)	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.
(34)	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.
(35)	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.
(36)	Verification Configuration	Arrangement of system and infrastructure necessary to perform the test, analysis, or inspection of a design or instance of a system.
(37)	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.
(38)	Organization	Description of the roles of persons in a group or team. Note that this is a subclass of System Assembly, definition (19).
(39)	Issue	Any question raised concerning the system or the system development.
(40)	Risk	Likelihood and impact of failure to meet any technical or development program goal.
(41)	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.
(42)	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. Example: Proctor and Gamble recently acquired an electric toothbrush product, SpinBrush, from four cleveland area entrepreneurs. Out of a panel of twenty four consumerws, twenty three raved about the product. Sasles have been sufficient to boost P&G to #1 sosition in US oral care.
(43)	Validation Event	Occurrence (with date, performer and result) of a comparison of a Requirement against the stakeholder needs.
(44)	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.
(45)	Validation Infrastructure	Arrangement of requirement information and related infrastructure necessary to asses corresondance with stakeholder needs and market realities.
(46)	Validation Plan	The schedule of tasks, inputs, outputs, goals, and resources, both personnel and infrastructure to perform the comparison of Requirements against Stakeholder Needs..
(47)	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.