Intelligence Dashboard Overview

Innoslate's heuristics are separated into six different categories and are used in Innoslate to assess model quality: Global, Action, Asset, Conduit, Input/Output, and Requirements by class name.

As an Innoslate project grows in size and complexity, so does identifying its overall score. In the software domain, many tools exist to maintain performance: 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, known as heuristics.

These heuristics are separated into six different categories and are used in Innoslate to assess model score: 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.

Navigating to Intelligence Tool

1. From within a project, 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.
   
   

The ‘Intelligence’ tool 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. There are 6 Settings that impact the Overall Analysis % in Intelligence View:

The following details each heuristic and its default setting:

Global Settings

• Entities in the same class have different names (Warning): 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.
• Entity Names begin with a capital letter (Warning): Entity names should be capitalized consistently throughout the model. Note Statements/Requirements are ignored and checked by the Requirements Quality Checker.
• Entity Numbers are unique within a class (Warning): 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.
• Entity Names and Descriptions do not contain ambiguous words (Warning): 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.
• Every entity is related to some other entity (Warning): 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.

Action Settings

• All Actions begin with a Verb (Warning): 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.
• Action Names begin with a capital letter (Ignore All): Action names should be capitalized consistently throughout the model.
• Each action has a name (Error): All actions should have a name identifying what it represents.
• Each action has a number (Warning): All actions should have a number to catalog it in the database.
• Each action has a description (Ignore All): All actions should have a description that elaborates on its meaning for the benefit of team members and other reviewers.
• Each action has a child or parent (Warning): 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.
• No action has exactly one child (Warning): 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.
• No action has more than 12 children (Warning): 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).
• No actions have more than one parent (Warning): 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.
• Each action is performed by some asset (Warning): 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).
• Each action generates at least one input/output (Warning): 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.
• Each action receives at least one input/output (Ignore All): 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.
• If any action generates an input/output, it also receives an input/output (Ignore All): 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 un-modeled input is assumed, and not explicitly shown because it is beyond the scope of the model.
• If any action receives an input/output, it also generates an input/output (Ignore All): 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 un-modeled output is assumed, and not explicitly shown because it is beyond the scope of the model.
• 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 (Error): 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.
• Each action is related to some requirement (Error): 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.

Asset Settings

• All Asset Names are a noun phrase (Warning): Asset names should be nouns or noun phrases, preferably using the common, collective, or compound noun type.
• Asset Names begin with a capital letter (Ignore All): Action names should be capitalized consistently throughout the model.
• Each asset has a name (Error): All assets should have a name identifying what it represents.
• Each asset has a number (Warning): All assets should have a number to catalog it in the database.
• Each asset has a description (Ignore All): All assets should have a description that elaborates on its meaning for the benefit of team members and other reviewers.
• No assets have more than one parent (Warning): 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.
• Each asset has a child or parent (Warning): 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.
• No asset has exactly one child (Warning): 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.
• No asset has more than 12 children (Error): 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).
• Each asset performs at least one action (Warning): 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.
• Each asset is connected by at least one conduit (Warning): To support interactions with other assets of any sort, a non-root asset needs to be connected to at least one conduit.
• If any two assets exchange some input/output, those assets are connected to at least one common conduit (Warning): Assets that interact through their performed actions should have at least one conduit in common.
• If any two assets exchange some input/output, those assets reference a common standard Artifact (Warning): 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.
• Each asset generates an input/output to or receives an input/output from at least one other disjoint asset (Warning): 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.

Conduit Settings

• All Conduits begin with a Noun (Warning): Conduit names should be nouns or noun phrases, and may use a common, collective, compound, abstract or concrete noun type.
• Each conduit has a name (Warning): Action names should be capitalized consistently throughout the model.
• Each conduit has a number (Ignore All): All conduits should have a number to catalog it in the database.
• Each conduit has a description (Ignore All): All conduits should have a description that elaborates on its meaning for the benefit of team members and other reviewers.
• Each conduit connects to no more than two distinct assets (Error): 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.
• Each conduit connects to at least two disjoint assets (Warning): 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.
• 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 (Warning): 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.
• Each conduit transfers at least one input/output (Warning): A conduit with no input/outputs assigned to it may be unnecessary or incomplete.
• Each conduit is related to some requirement (Warning): Any conduits that do not satisfy/trace/verify some requirement may be unnecessary or outside the scope of what is needed.

Input/Output Settings

• Each input/output has a name (Error): All input/outputs should have a name identifying what it represents.
• Each input/output has a number (Ignore All): All input/outputs should have a number to catalog it in the database.
• Each input/output has a description (Ignore All): All input/outputs should have a description that elaborates on its meaning for the benefit of team members and other reviewers.
• No input/output has more than one parent (Warning): 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.
• Each input/output is generated by some action (Warning): 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.
• Each input/output is received by some action (Warning): 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.
• Each input/output is generated or received by some action (Warning): An input/output that is generated but not received is missing a destination, or received but not generated is missing a source.
• No action generates and receives the same input/output (Error): 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.
• Every exchanged input/output between any two assets references some standard that is referenced by those assets (Warning): 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.
• Each input/output is related to some requirement (Error): Any input/outputs that do not satisfy/trace/verify some requirement may be unnecessary or outside the scope of what is needed. 

Requirement Settings

• An IO/Asset/Action called out in a requirement should be related to that requirement (Error): 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.
• Shall use in leaf level requirements (Warning): 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...".
• Each requirement has a name (Warning): All requirements should have a name identifying what it represents.
• Each requirement has a number (Warning): All requirements should have a number to catalog it in the database.
• Each requirement has a description (Warning): All requirements should have a description that elaborates on its meaning for the benefit of team members and other reviewers.
• Each requirement has a child or parent (Warning): 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.
• No requirement has more than one parent (Warning): 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.
• All leaf-level requirements are related to at least one entity in the Action, Conduit, Asset, or Input/Output class (Error): A requirement that is not satisfied by any modeled entity is either unnecessary or has not yet been specified in the architecture model.
• No requirement is satisfied by more than one input/output (Warning): 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.