-----Original Message-----

From: Friedenthal, Sanford

Sent: Tuesday, August 13, 2002 8:57 PM

To: 'doliver106@cox.net'; 'Michael.L.Dickerson@jpl.nasa.gov'

Cc: Rick Steiner; Regina Gonzales; Peter Denno; Julian Johnson; Joseph Skipper; James D. Baker; James A U'Ren; Harold P Frisch; Harald Eisenmann; Erik Herzog; Dwayne Hardy; Roger Burkhart; Stan Hendryx; Moore, Alan

Subject: Proposed Update to SE Conceptual Model Draft 6 & Definitions



Dave, Mike


The following is a response to an action item from the SE Conceptual Model review at INCOSE 2002 on August 1, 2002. The action was to provide definitions corresponding to the proposed update to the SE Conceptual Model draft 6 that I presented at the review. This update is intended to address the general and specific set of issues which I submitted as part of Dwayne Hardy's input to the issue log from the OMG SE DSIG meeting. This model attempts to simplify and refine some of the concepts in the current model (Draft 6).  Other concepts, along with their definitions, which are included in the SE UML Requirements Analysis *, are not included here, so as to focus primarily on those concepts that we have already been discussing. It may be appropriate to introduce some of the additional concepts after we get further along.


The attachments include:


a)The proposed update to the model (Draft 6), which I presented at the INCOSE review, is included as slide 2 in the power point charts. (I made a few minor changes including adding component back in, and changing parameter back to property).


b)Slide 3 in the power point charts reflect a possible modular packaging of the SE Technical Concepts in terms of behavior, structure, properties, requirements, and verification. The lines between the packages represent dependencies. We had briefly discussed this at the meeting, and Alan Moore had initiated a similar concept, although a different packaging. I have not tried to partition the proposed updated model explicitly into these packages, but this should be fairly straightforward if we proceed down this path.


c)The proposed updates to the semantic dictionary for Draft 6 are included in the excel spreadsheet. I have shown the mapping between the current terms and definitions from Draft 6 in the left 2 columns, and the proposed terms and definitions in the right two columns.



I have also included a brief text summary of the model below to aid in its interpretation, but the semantic dictionary includes the more complete set of definitions to address your original model. I hope this is helpful.






Sanford Friedenthal


Lockheed Martin Corporation


(703) 293-5557







Note: Refer to the more complete set of definitions in the attached proposed update to the semantic dictionary.



The "Domain of Interest" is the set of entities which are of interest to the system modeler.(Replaces Universe)


A "View" is the relationship between a subset of the entities in the domain of interest. (Replaces System View)


"Domain of interest" is composed of "Entities"


"Entities" are a generalization which represents anything of interest with a defined set of properties (Replaces SE Thing)


"Entity" can be an "I/O entity" or a "System" (or component)


"I/O entities" represent an entity which flows between systems/components, and may include signals, mass flow, etc


"System" represents an entity, which is a composite of components, which interact with one another to exhibit observable properties and behaviors.


There may be multiple levels of "System" (i.e. "System" composed of



Systems are composed of "Components"


"Components" are physically replaceable part of a system, which are implemented in hardware, software, data, personnel/user/operator, procedure, facility, etc.



"Environment" os the set of all entities which impact or are impacted by the system of interest. External environment is all entities external to the system, and the internal environment is all entities internal to the system. Environment includes both the system/components and the I/O entities which flow between them.


"Functions/action" is a transformation of input/ouptut entities that a system/component or the environment perform.


"Control Flow" emab;e/disable functions resulting from triggering events and conditions.


"Physical Connections" or "Ports" are the physical surfaces which connects systems/components to one another (including the physical environment) to enable the flow of inputs and outputs.


A "Boundary" is the set of all physical connections (I.e. ports) which separates a system and/or component from its external environment.


"I/O entities" flow in/our of "Ports"


" Properties" are measurable characteristics, or characteristics which can be derived from other measurable characteristics.


"Properties" have "Values", which may be continuous or discrete and deterministic or probabilistic.


"Property relationships" define relationships between properties and values, which is generally expressed in terms of mathematical equations. (Note: sets of equations which are typically used in an analysis model)


Time is a "Property", which all other properties are dependent on. Time can be represented by continuous or discrete values as can all other properties. (Not shown)


Time has value. (not shown)


"Requirement" is a declarative which specifies expectations of a system, component, and/or the environment, and may include functional, interface, control, performance, physical, verification, other types of non-functional requirements, and design constraints.  (NOTE: The model shows that a requirement specifies an entity versus the system to give more flexibility).



"Verification results" is an assessment of compliance with requirements, by comparing requirements and observations using a prescribed method of observation.


"Need" is a type of requirement, which is intended to address a problem or inadequacy.as preceived by a stakeholder.


"Stakeholders" are individuals, groups, and/or institutions which may be impacted by the system throughout its life cycle, including acquisition, development, production, deployment, operations, support, and disposal.




*Other concepts in the SE UML Requirements Analysis V0.3 include problem, logical/physical entities, nodes/distribution of resources, geometric relationships, problem, state, event, failure, etc, but are not included here to focus primarily on those concepts that we have already been discussing.