Intelligence

Last modified on February 21st, 2017.


As an Innoslate project grows in size and complexity so does identifying its overall quality. In the software domain many tools exist to maintain quality: compilers, static code analysis tools, and even automatic graders.

To address this issue professors at some of the world’s leading research institutions  (NPS and Stevens Institute of Technology) developed formal representations of a well-defined system architecture as heuristics. These heuristics are used in Innoslate to assess model quality.

These heuristics are separated into six different categories: Global, Action, Asset, Conduit, Input/Output, and Requirements by class name. The percentage score within each category is calculated as the number of successful passes over the total number of entity heuristics tested and displayed as a percentage.

To navigate to 'Intelligence View':

  1. Open the ‘MENU’ drop-down and click the ‘Intelligence’ menu item under the “Tools” section.
  2. Once in the ‘Intelligence’ tool, the analysis will begin automatically, the first time you open the view. To rerun the analysis (after model changes), click on the ‘Run Analysis’ button.

Intelligence View

The Intelligence View can be customized to change the default settings by clicking ‘Settings’ in the toolbar. Issues found as errors are flagged as red, issues found as warnings are flagged as yellow, whereas ignored issues are not displayed.

A table detailing each heuristic and its default setting follows:

Global Heuristics

Name Number Description Default
Global.1 Entities in the same class have different names. Entities having similar or identical names make it difficult to tell them apart when selecting them for relationships, and may result in mistaken identities and the consequential errors. Unique entity names are strongly recommended, except in cases where different instances of the same entity (as needed for representing different relationships) are genuinely necessary. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.2 Entity Names begin with a capital letter. Entity names should be capitalized consistently throughout the model. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.3 Entity Descriptions are complete sentences. Descriptions are intended to elaborate on an entity to provide team members and other reviewers more background on what the entity represents. Complete sentences are recommended over sentence fragments for clarity. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.4 Entity Numbers are unique within a class. Entities having identical numbers within a class is most likely an error. Numbers within a class should be unique. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.5 Entity Names and Descriptions do not contain ambiguous words. Word choices that leave ample room for interpretation are usually fine (and even necessary) at the high level, but should be replaced with more precise language lower down in the hierarchy. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.6 Every entity is related to some other entity. Entities that have no relations to other entities may be artifacts of early editing and are usually unnecessary to keep around. Deletion after verifying there is no longer any need for them is usually recommended. Note if an entity fails this check most other checks will be automatically omitted. Warning

Action Heuristics

Number Name Description Default
Action.1 All Actions begin with a Verb. With the possible exception of use cases, action names should be verbs or verb phrases, preferably using the simple present tense. If this action represents a use case, add the "Use Case" label to except it from this rule. Warning
Action.2 Action Names begin with a capital letter. Action names should be capitalized consistently throughout the model. Ignore All
Action.3 Each action has a name. All actions should have a name identifying what it represents. Error
Action.4 Each action has a number. All actions should have a number to catalog it in the database. Warning
Action.5 Each action has a description. All actions should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Ignore All
Action.6 Each action has a child or parent. As the model matures, actions typically will not stand on their own, but appear as part of a hierarchy (either decomposing a parent action, or being decomposed by a child action). A hierarchy of actions is useful for grouping and organizing related actions. Warning
Action.7 No action has exactly one child Actions (and, in general any, entity) are usually decomposed into two or more children, or no children at all (if they are the lowest level entity intended). Decomposing an action into just one other action implies an equivalency between the two actions that is often redundant. This flag may be ignored if this is a work in progress (more actions will be added) or the one to one decomposition relationship is intentional for style reasons. Warning
Action.8 No action is decomposed by itself. An action decomposing itself is an error that can cause logical problems. Actions can only decompose or be decomposed by other actions. Error
Action.9 No action has more than 12 children For model comprehension, it is strongly recommended to limit the number of actions that appear at a given level. Buede (an engineer referring directly to model diagrams) recommends the optimum number is between 3 and 6 actions; Miller (a psychologist referring to pieces of information in general) finds a human can best work with a maximum of 7 plus or minus 2. Try deepening the hierarchy by further grouping the actions (for example, decompose an action with 24 child actions into 4 new actions, each with 6 child actions. The 4 new assets are used to group the otherwise large number of entities). Warning
Action.10 No actions have more than one parent Actions that have more than one parent belong to multiple hierarchies. This may be desired in some cases, such as when actions are being reused or mapped to multiple taxonomies. Sometimes, however, it is accidental, and results in ambiguity about which path of parentage to follow when opening parent diagrams. Warning
Action.11 Each action is performed by some asset Actions that have not been allocated to an asset lack a physical embodiment. The physical object that will perform the action must eventually be specified. If an action cannot be mapped to a single asset, consider regrouping the actions / assets to support the assignment of actions to specific assets. This will enable a clear work breakdown structure that delineates "who or what" (asset) is responsible for "doing what" (action). Warning
Action.12 Each action generates at least one input/output. Actions that do not generate any outputs are unproductive, or do have an output that was just overlooked. It is important for any action that appears on an IDEF0 diagram to generate at least one output. Actions that are part of a pick list or catalog, such as a standard hierarchical task list, do not require outputs to be specified unless they are used in a functional flow model. If you know that the action has an output but left it out because the destination action for that output is not included in your model, you should consider creating an action to receive that output. The destination may be an external action that was overlooked or left out. Warning
Action.13 Each action receives at least one input/output. Actions that do not receive any inputs may have at least one input that was overlooked, especially if it appears on an IDEF0 diagram. Actions that are part of a pick list or catalog, such as a standard hierarchical task list, do not require inputs to be specified unless they are used in a functional flow model. If you know that the action has an input but left it out because the source action for that input is not included in your model, you should consider creating an action to generate that input. The source may be an external action that was overlooked or left out. Warning
Action.14 Each action generates or receives at least one input/output. An action that does not generate or receive any input/outputs is either idle, or intended to define a closed process. More realistically, all actions will interact with at least one other action at some point. Even undesired interactions should be modeled, to help the specification of counteractions. Ignore All
Action.15 If any action generates an input/output, it also receives an input/output. To preserve the Law of Conservation of Matter and Energy, an action should not be able to generate an output without having received some input at some point in the past. A couple of known exception cases in modeling are 1) the use of "stub" actions, during executable modeling development or for simulation debugging, and 2) on a top-level context diagram where the unmodeled input is assumed, and not explicitly shown because it is beyond the scope of the model. Ignore All
Action.16 If any action receives an input/output, it also generates an input/output. To preserve equilibrium and the Law of Conservation of Matter and Energy, an action should not be able to receive an input without eventually generating some output. A couple of known exception in modeling are 1) the use of "stub" actions, during executable modeling development or for simulation debugging, and 2) on a top-level context diagram where the unmodeled output is assumed, and not explicitly shown because it is beyond the scope of the model. Ignore All
Action.17 No action (a1) is triggered by any input/output that is output by any other action (a2) that is triggered by an output of a1. An action that occurs later on the timeline than a prior action cannot trigger the prior action, because it has not yet occurred. Time-traveling input/outputs are not permitted. Error
Action.18 Each action is related to some requirement. Any actions that do not satisfy some requirement may be unnecessary or outside the scope of what is needed. Exceptions may apply to modeled actions or functions of external systems outside the scope of the requirement specification for the system under design. Another exception case is made for a root action at the top of an action or function hierarchy, since such an entity is typically used for context only. Error

Asset Heuristics

Number Name Description Default
Asset.1 All Asset Names are a noun phrase. Asset names should be nouns or noun phrases, preferably using the common, collective, or compound noun type. Warning
Asset.2 Asset Names begin with a capital letter. Action names should be capitalized consistently throughout the model. Ignore All
Asset.3 Each asset has a name. All assets should have a name identifying what it represents. Error
Asset.4 Each asset has a number. All assets should have a number to catalog it in the database. Warning
Asset.5 Each asset has a description. All assets should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Ignore All
Asset.6 Each asset has a child or parent As the model matures, assets typically will not stand on their own, but appear as part of a hierarchy (either decomposing a parent asset, or being decomposed by a child asset). A hierarchy of assets is useful for grouping and organizing related assets. Warning
Asset.7 No asset has exactly one child. Assets (and, in general any, entity) are usually decomposed into two or more children, or no children at all (if they are the lowest level entity intended). Decomposing an asset into just one other asset implies an equivalency between the two assets that is often redundant. This flag may be ignored if this is a work in progress (more assets will be added) or the one to one decomposition relationship is intentional for style reasons. Warning
Asset.8 No asset is decomposed by itself. An asset decomposing itself is an error that can cause logical problems. Assets can only decompose or be decomposed by other assets. Error
Asset.9 No asset has more than 12 children. For model comprehension, it is strongly recommended to limit the number of assets that appear at a given level. Buede (an engineer referring directly to model diagrams) recommends the optimum number is between 3 and 6 actions; Miller (a psychologist referring to pieces of information in general) finds a human can best work with a maximum of 7 plus or minus 2. Try deepening the hierarchy by further grouping the assets (for example, decompose an asset with 24 child assets into 4 new assets, each with 6 child assets. The 4 new assets are used to group the otherwise large number of entities). Warning
Asset.10 No assets have more than one parent. Assets that have more than one parent belong to multiple hierarchies. This may be desired in some cases, such as when assets are being reused or mapped to multiple taxonomies. Sometimes, however, it is accidental, and results in ambiguity about which path of parentage to follow when opening parent diagrams. Warning
Asset.11 Each asset performs at least one action. Assets that have not been allocated any action lack functionality. If an asset exists without an associated action, it may be unnecessary, or it may be that its action has been overlooked. Each physical form should be allocated to a corresponding function. Warning
Asset.12 Each asset is connected by at least one conduit. To support interactions with other assets of any sort, an asset needs to be connected to at least one conduit. Warning
Asset.13 If any two assets exchange some input/output, those assets are connected to at least one common conduit. Assets that interact through their performed actions should have at least one conduit in common. Warning
Asset.14 If any two assets exchange some input/output, those assets reference a common standard. Assets that interact through their performed actions should have at least one standard in common, so that they are consistently constrained to support the interaction. Warning
Asset.15 Each asset generates an input/output to or receives an input/output from at least one other disjoint asset. Assets that do not have any interactions are either idle, or intended to define a closed system. More realistically, all assets will interact with at least one other asset at some point. Even undesired interactions should be modeled, to help the specification of counteractions. Warning

Conduit Heuristics

Number Name Description Default
Conduit.1 All Conduits begin with a Noun. Conduit names should be nouns or noun phrases, and may use a common, collective, compound, abstract or concrete noun type. Warning
Conduit.2 Each conduit has a name. All conduits should have a name identifying what it represents. Warning
Conduit.3 Each conduit has a number. All conduits should have a number to catalog it in the database. Ignore All
Conduit.4 Each conduit has a description. All conduits should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Ignore All
Conduit.5 Each conduit connects to no more than two distinct assets. A conduit is a point-to-point concept that applies a pairwise relationship between connected assets. If a conduit seems to need more than two connection points, consider modeling the conduit as an asset instead. Error
Conduit.6 Each conduit connects to at least two disjoint assets. A conduit is a point-to-point concept that applies a pairwise relationship between connected assets. If a conduit is only connected to less than two assets, its specification is incomplete. Warning
Conduit.7 Every conduit that connects any two assets and transfers an input/output between those assets reference some standard that is also referenced by those assets. A conduit that connects interacting assets should have at least one standard in common with the assets that they connect, so that the conduit and connected assets are consistently constrained to support the interaction. Warning
Conduit.8 Each conduit transfers at least one input/output. A conduit with no input/outputs assigned to it may be unnecessary or incomplete. Warning
Conduit.9 Each conduit is related to some requirement. Any conduits that do not satisfy/trace/verify some requirement may be unnecessary or outside the scope of what is needed. Warning

Input/Output Heuristics

Number Name Description Default
IO.1 Each input/output has a name. All input/outputs should have a name identifying what it represents. Error
IO.2 Each input/output has a number. All input/outputs should have a number to catalog it in the database. Ignore All
IO.3 Each input/output has a description. All input/outputs should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Ignore All
IO.4 No input/output has more than one parent. Input/outputs that have more than one parent belong to multiple hierarchies. This may be desired in some cases, such as when the same input/outputs are being packaged or bundled differently. Sometimes, however, it is accidental, and results in ambiguity about which path of parentage to follow when opening parent diagrams. Warning
IO.5 Each input/output is generated by some action. An input/output that is not generated by any action is missing a source. If there is no source for the input/output, the implication is that appears out of thin air, or is never generated by any source action. Warning
IO.6 Each input/output is received by some action. An input/output that is not received by any action is missing a destination. If there is no destination for the input/output, the implication is that disappears into thin air, or is never received by any destination action. Warning
IO.7 Each input/output is generated or received by some action. An input/output that is generated but not received is missing a destination, or received but not generated is missing a source. Warning
IO.8 No action generates and receives the same input/output. A looping input/output is generated by the same action that consumes it. At an abstract level this may be ok, but at a detailed level is not executable. Try moving the looping input/output one level down into the decomposed view of the action it is leaving and re-entering, to show the distinct sub-actions that generated and receive it. Error
IO.9 Every exchanged input/output between any two assets references some standard that is referenced by those assets. An input/output exchanged between interacting assets should have at least one standard in common with its source and destination assets, so that the input/output and the assets are consistently constrained to support the interaction. Warning
IO.10 Each input/output is related to some requirement. Any input/outputs that do not satisfy/trace/verify some requirement may be unnecessary or outside the scope of what is needed. Error

Requirement Heuristics

Number Name Description Default
Requirement.1 An IO/Asset/Action called out in a requirement should be related to that requirement. A requirement that refers to the name of another entity may be related to that entity with a "traced to,""satisfied by," or "verified by" relation, as appropriate. Error
Requirement.2 Shall used in leaf level requirements A leaf-level requirement has no children, and is typically the level at which test cases are written. These requirements are typically written in the form "The [system name] shall..." or, for component specifications, "The [component name] shall...". Warning
Requirement.3 Each requirement has a name. All requirements should have a name identifying what it represents. Warning
Requirement.4 Each requirement has a number. All requirements should have a number to catalog it in the database. Warning
Requirement.5 Each requirement has a description. All requirements should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Warning
Requirement.6 Each requirement has a child or parent. Requirements typically do not stand on their own, but appear as part of a hierarchy (either decomposing a parent requirement, or being decomposed by a child requirement). A hierarchy of requirements is useful for grouping and organizing related requirements. Warning
Requirement.7 No requirement has more than one parent. Requirements that have more than one parent belong to multiple hierarchies. This may be desired in some cases, such as when requirements are being reorganized or repackaged. Sometimes, however, it is accidental, and results in ambiguity about which path of parentage to follow when opening parent diagrams. Warning
Requirement.8 All leaf-level requirements are related to at least one entity in the Action, Conduit, Asset, or Input/Output class. A requirement that is not satisfied by any modeled entity is either unnecessary or has not yet been specified in the architecture model. Error
Requirement.9 No requirement is satisfied by more than one input/output. A more than one-to-one mapping between requirement and input/output leaves potential room for ambiguity and inconsistency. If a single requirement is used to cover multiple input/outputs, care must be taken to manually inspect each requirement against the input/outputs satisfying it, and ensure these mappings remain consistent over time as the architecture model changes. If a one-to-one mapping is followed, each input/output satisfies exactly one requirement and traceability changes are easier to check automatically. Warning

Intelligence

Last modified on February 21st, 2017. 


As an Innoslate project grows in size and complexity so does identifying its overall quality. In the software domain many tools exist to maintain quality: compilers, static code analysis tools, and even automatic graders.

To address this issue professors at some of the world’s leading research institutions  (NPS and Stevens Institute of Technology) developed formal representations of a well-defined system architecture as heuristics. These heuristics are used in Innoslate to assess model quality.

These heuristics are separated into six different categories: Global, Action, Asset, Conduit, Input/Output, and Requirements by class name. The percentage score within each category is calculated as the number of successful passes over the total number of entity heuristics tested and displayed as a percentage.

To navigate to ‘Intelligence View’:

  1. Open the ‘MENU’ drop-down and click the ‘Intelligence’ menu item under the “Tools” section.
  2. Once in the ‘Intelligence’ tool, the analysis will begin automatically, the first time you open the view. To rerun the analysis (after model changes), click on the ‘Run Analysis’ button.

Intelligence View

The Intelligence View can be customized to change the default settings by clicking ‘Settings’ in the toolbar. Issues found as errors are flagged as red, issues found as warnings are flagged as yellow, whereas ignored issues are not displayed.

A table detailing each heuristic and its default setting follows:

Global Heuristics

Name Number Description Default
Global.1 Entities in the same class have different names. Entities having similar or identical names make it difficult to tell them apart when selecting them for relationships, and may result in mistaken identities and the consequential errors. Unique entity names are strongly recommended, except in cases where different instances of the same entity (as needed for representing different relationships) are genuinely necessary. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.2 Entity Names begin with a capital letter. Entity names should be capitalized consistently throughout the model. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.3 Entity Descriptions are complete sentences. Descriptions are intended to elaborate on an entity to provide team members and other reviewers more background on what the entity represents. Complete sentences are recommended over sentence fragments for clarity. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.4 Entity Numbers are unique within a class. Entities having identical numbers within a class is most likely an error. Numbers within a class should be unique. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.5 Entity Names and Descriptions do not contain ambiguous words. Word choices that leave ample room for interpretation are usually fine (and even necessary) at the high level, but should be replaced with more precise language lower down in the hierarchy. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker. Warning
Global.6 Every entity is related to some other entity. Entities that have no relations to other entities may be artifacts of early editing and are usually unnecessary to keep around. Deletion after verifying there is no longer any need for them is usually recommended. Note if an entity fails this check most other checks will be automatically omitted. Warning

Action Heuristics

Number Name Description Default
Action.1 All Actions begin with a Verb. With the possible exception of use cases, action names should be verbs or verb phrases, preferably using the simple present tense. If this action represents a use case, add the “Use Case” label to except it from this rule. Warning
Action.2 Action Names begin with a capital letter. Action names should be capitalized consistently throughout the model. Ignore All
Action.3 Each action has a name. All actions should have a name identifying what it represents. Error
Action.4 Each action has a number. All actions should have a number to catalog it in the database. Warning
Action.5 Each action has a description. All actions should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Ignore All
Action.6 Each action has a child or parent. As the model matures, actions typically will not stand on their own, but appear as part of a hierarchy (either decomposing a parent action, or being decomposed by a child action). A hierarchy of actions is useful for grouping and organizing related actions. Warning
Action.7 No action has exactly one child Actions (and, in general any, entity) are usually decomposed into two or more children, or no children at all (if they are the lowest level entity intended). Decomposing an action into just one other action implies an equivalency between the two actions that is often redundant. This flag may be ignored if this is a work in progress (more actions will be added) or the one to one decomposition relationship is intentional for style reasons. Warning
Action.8 No action is decomposed by itself. An action decomposing itself is an error that can cause logical problems. Actions can only decompose or be decomposed by other actions. Error
Action.9 No action has more than 12 children For model comprehension, it is strongly recommended to limit the number of actions that appear at a given level. Buede (an engineer referring directly to model diagrams) recommends the optimum number is between 3 and 6 actions; Miller (a psychologist referring to pieces of information in general) finds a human can best work with a maximum of 7 plus or minus 2. Try deepening the hierarchy by further grouping the actions (for example, decompose an action with 24 child actions into 4 new actions, each with 6 child actions. The 4 new assets are used to group the otherwise large number of entities). Warning
Action.10 No actions have more than one parent Actions that have more than one parent belong to multiple hierarchies. This may be desired in some cases, such as when actions are being reused or mapped to multiple taxonomies. Sometimes, however, it is accidental, and results in ambiguity about which path of parentage to follow when opening parent diagrams. Warning
Action.11 Each action is performed by some asset Actions that have not been allocated to an asset lack a physical embodiment. The physical object that will perform the action must eventually be specified. If an action cannot be mapped to a single asset, consider regrouping the actions / assets to support the assignment of actions to specific assets. This will enable a clear work breakdown structure that delineates “who or what” (asset) is responsible for “doing what” (action). Warning
Action.12 Each action generates at least one input/output. Actions that do not generate any outputs are unproductive, or do have an output that was just overlooked. It is important for any action that appears on an IDEF0 diagram to generate at least one output. Actions that are part of a pick list or catalog, such as a standard hierarchical task list, do not require outputs to be specified unless they are used in a functional flow model. If you know that the action has an output but left it out because the destination action for that output is not included in your model, you should consider creating an action to receive that output. The destination may be an external action that was overlooked or left out. Warning
Action.13 Each action receives at least one input/output. Actions that do not receive any inputs may have at least one input that was overlooked, especially if it appears on an IDEF0 diagram. Actions that are part of a pick list or catalog, such as a standard hierarchical task list, do not require inputs to be specified unless they are used in a functional flow model. If you know that the action has an input but left it out because the source action for that input is not included in your model, you should consider creating an action to generate that input. The source may be an external action that was overlooked or left out. Warning
Action.14 Each action generates or receives at least one input/output. An action that does not generate or receive any input/outputs is either idle, or intended to define a closed process. More realistically, all actions will interact with at least one other action at some point. Even undesired interactions should be modeled, to help the specification of counteractions. Ignore All
Action.15 If any action generates an input/output, it also receives an input/output. To preserve the Law of Conservation of Matter and Energy, an action should not be able to generate an output without having received some input at some point in the past. A couple of known exception cases in modeling are 1) the use of “stub” actions, during executable modeling development or for simulation debugging, and 2) on a top-level context diagram where the unmodeled input is assumed, and not explicitly shown because it is beyond the scope of the model. Ignore All
Action.16 If any action receives an input/output, it also generates an input/output. To preserve equilibrium and the Law of Conservation of Matter and Energy, an action should not be able to receive an input without eventually generating some output. A couple of known exception in modeling are 1) the use of “stub” actions, during executable modeling development or for simulation debugging, and 2) on a top-level context diagram where the unmodeled output is assumed, and not explicitly shown because it is beyond the scope of the model. Ignore All
Action.17 No action (a1) is triggered by any input/output that is output by any other action (a2) that is triggered by an output of a1. An action that occurs later on the timeline than a prior action cannot trigger the prior action, because it has not yet occurred. Time-traveling input/outputs are not permitted. Error
Action.18 Each action is related to some requirement. Any actions that do not satisfy some requirement may be unnecessary or outside the scope of what is needed. Exceptions may apply to modeled actions or functions of external systems outside the scope of the requirement specification for the system under design. Another exception case is made for a root action at the top of an action or function hierarchy, since such an entity is typically used for context only. Error

Asset Heuristics

Number Name Description Default
Asset.1 All Asset Names are a noun phrase. Asset names should be nouns or noun phrases, preferably using the common, collective, or compound noun type. Warning
Asset.2 Asset Names begin with a capital letter. Action names should be capitalized consistently throughout the model. Ignore All
Asset.3 Each asset has a name. All assets should have a name identifying what it represents. Error
Asset.4 Each asset has a number. All assets should have a number to catalog it in the database. Warning
Asset.5 Each asset has a description. All assets should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Ignore All
Asset.6 Each asset has a child or parent As the model matures, assets typically will not stand on their own, but appear as part of a hierarchy (either decomposing a parent asset, or being decomposed by a child asset). A hierarchy of assets is useful for grouping and organizing related assets. Warning
Asset.7 No asset has exactly one child. Assets (and, in general any, entity) are usually decomposed into two or more children, or no children at all (if they are the lowest level entity intended). Decomposing an asset into just one other asset implies an equivalency between the two assets that is often redundant. This flag may be ignored if this is a work in progress (more assets will be added) or the one to one decomposition relationship is intentional for style reasons. Warning
Asset.8 No asset is decomposed by itself. An asset decomposing itself is an error that can cause logical problems. Assets can only decompose or be decomposed by other assets. Error
Asset.9 No asset has more than 12 children. For model comprehension, it is strongly recommended to limit the number of assets that appear at a given level. Buede (an engineer referring directly to model diagrams) recommends the optimum number is between 3 and 6 actions; Miller (a psychologist referring to pieces of information in general) finds a human can best work with a maximum of 7 plus or minus 2. Try deepening the hierarchy by further grouping the assets (for example, decompose an asset with 24 child assets into 4 new assets, each with 6 child assets. The 4 new assets are used to group the otherwise large number of entities). Warning
Asset.10 No assets have more than one parent. Assets that have more than one parent belong to multiple hierarchies. This may be desired in some cases, such as when assets are being reused or mapped to multiple taxonomies. Sometimes, however, it is accidental, and results in ambiguity about which path of parentage to follow when opening parent diagrams. Warning
Asset.11 Each asset performs at least one action. Assets that have not been allocated any action lack functionality. If an asset exists without an associated action, it may be unnecessary, or it may be that its action has been overlooked. Each physical form should be allocated to a corresponding function. Warning
Asset.12 Each asset is connected by at least one conduit. To support interactions with other assets of any sort, an asset needs to be connected to at least one conduit. Warning
Asset.13 If any two assets exchange some input/output, those assets are connected to at least one common conduit. Assets that interact through their performed actions should have at least one conduit in common. Warning
Asset.14 If any two assets exchange some input/output, those assets reference a common standard. Assets that interact through their performed actions should have at least one standard in common, so that they are consistently constrained to support the interaction. Warning
Asset.15 Each asset generates an input/output to or receives an input/output from at least one other disjoint asset. Assets that do not have any interactions are either idle, or intended to define a closed system. More realistically, all assets will interact with at least one other asset at some point. Even undesired interactions should be modeled, to help the specification of counteractions. Warning

Conduit Heuristics

Number Name Description Default
Conduit.1 All Conduits begin with a Noun. Conduit names should be nouns or noun phrases, and may use a common, collective, compound, abstract or concrete noun type. Warning
Conduit.2 Each conduit has a name. All conduits should have a name identifying what it represents. Warning
Conduit.3 Each conduit has a number. All conduits should have a number to catalog it in the database. Ignore All
Conduit.4 Each conduit has a description. All conduits should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Ignore All
Conduit.5 Each conduit connects to no more than two distinct assets. A conduit is a point-to-point concept that applies a pairwise relationship between connected assets. If a conduit seems to need more than two connection points, consider modeling the conduit as an asset instead. Error
Conduit.6 Each conduit connects to at least two disjoint assets. A conduit is a point-to-point concept that applies a pairwise relationship between connected assets. If a conduit is only connected to less than two assets, its specification is incomplete. Warning
Conduit.7 Every conduit that connects any two assets and transfers an input/output between those assets reference some standard that is also referenced by those assets. A conduit that connects interacting assets should have at least one standard in common with the assets that they connect, so that the conduit and connected assets are consistently constrained to support the interaction. Warning
Conduit.8 Each conduit transfers at least one input/output. A conduit with no input/outputs assigned to it may be unnecessary or incomplete. Warning
Conduit.9 Each conduit is related to some requirement. Any conduits that do not satisfy/trace/verify some requirement may be unnecessary or outside the scope of what is needed. Warning

Input/Output Heuristics

Number Name Description Default
IO.1 Each input/output has a name. All input/outputs should have a name identifying what it represents. Error
IO.2 Each input/output has a number. All input/outputs should have a number to catalog it in the database. Ignore All
IO.3 Each input/output has a description. All input/outputs should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Ignore All
IO.4 No input/output has more than one parent. Input/outputs that have more than one parent belong to multiple hierarchies. This may be desired in some cases, such as when the same input/outputs are being packaged or bundled differently. Sometimes, however, it is accidental, and results in ambiguity about which path of parentage to follow when opening parent diagrams. Warning
IO.5 Each input/output is generated by some action. An input/output that is not generated by any action is missing a source. If there is no source for the input/output, the implication is that appears out of thin air, or is never generated by any source action. Warning
IO.6 Each input/output is received by some action. An input/output that is not received by any action is missing a destination. If there is no destination for the input/output, the implication is that disappears into thin air, or is never received by any destination action. Warning
IO.7 Each input/output is generated or received by some action. An input/output that is generated but not received is missing a destination, or received but not generated is missing a source. Warning
IO.8 No action generates and receives the same input/output. A looping input/output is generated by the same action that consumes it. At an abstract level this may be ok, but at a detailed level is not executable. Try moving the looping input/output one level down into the decomposed view of the action it is leaving and re-entering, to show the distinct sub-actions that generated and receive it. Error
IO.9 Every exchanged input/output between any two assets references some standard that is referenced by those assets. An input/output exchanged between interacting assets should have at least one standard in common with its source and destination assets, so that the input/output and the assets are consistently constrained to support the interaction. Warning
IO.10 Each input/output is related to some requirement. Any input/outputs that do not satisfy/trace/verify some requirement may be unnecessary or outside the scope of what is needed. Error

Requirement Heuristics

Number Name Description Default
Requirement.1 An IO/Asset/Action called out in a requirement should be related to that requirement. A requirement that refers to the name of another entity may be related to that entity with a “traced to,””satisfied by,” or “verified by” relation, as appropriate. Error
Requirement.2 Shall used in leaf level requirements A leaf-level requirement has no children, and is typically the level at which test cases are written. These requirements are typically written in the form “The [system name] shall…” or, for component specifications, “The [component name] shall…”. Warning
Requirement.3 Each requirement has a name. All requirements should have a name identifying what it represents. Warning
Requirement.4 Each requirement has a number. All requirements should have a number to catalog it in the database. Warning
Requirement.5 Each requirement has a description. All requirements should have a description that elaborates on its meaning for the benefit of team members and other reviewers. Warning
Requirement.6 Each requirement has a child or parent. Requirements typically do not stand on their own, but appear as part of a hierarchy (either decomposing a parent requirement, or being decomposed by a child requirement). A hierarchy of requirements is useful for grouping and organizing related requirements. Warning
Requirement.7 No requirement has more than one parent. Requirements that have more than one parent belong to multiple hierarchies. This may be desired in some cases, such as when requirements are being reorganized or repackaged. Sometimes, however, it is accidental, and results in ambiguity about which path of parentage to follow when opening parent diagrams. Warning
Requirement.8 All leaf-level requirements are related to at least one entity in the Action, Conduit, Asset, or Input/Output class. A requirement that is not satisfied by any modeled entity is either unnecessary or has not yet been specified in the architecture model. Error
Requirement.9 No requirement is satisfied by more than one input/output. A more than one-to-one mapping between requirement and input/output leaves potential room for ambiguity and inconsistency. If a single requirement is used to cover multiple input/outputs, care must be taken to manually inspect each requirement against the input/outputs satisfying it, and ensure these mappings remain consistent over time as the architecture model changes. If a one-to-one mapping is followed, each input/output satisfies exactly one requirement and traceability changes are easier to check automatically. Warning