Heuristic Analysis Widget

Intelligence View Dashboard Hueristics Widgets overview.

Header Toolbar

Icon	Name	Description
	Lock	Locks the widget from being moved.
	Maximize/Minimize	Expands/Minimizes all heuristic sections in the widget.
	Edit Widget	Opens the settings modal of the widget. Where you can see the descriptions of each heuristic section. As well as decide the level of the heuristic level.
	Remove	Removes Widget from the Intelligence Dashboard.

Heuristic

Issues

Issues contain the entity name and number as well as two options, Fix or Ignore. Click the issue’s name and number in order to navigate to its Entity View. Click ‘Fix’ to allow the issue correction. Once the issue has been corrected, the entity will be greyed out until the ‘Run’ button is clicked again. Click ‘Ignore’ to allow the issue to continue without correction. Ignore can be undone by clicking the ‘Unignore All’ button in the header toolbar.

Note: The correction to be made by clicking ‘Fix’ is based on the given heuristic section.

Heuristic Levels

There are three levels to the heuristic evaluation.

Errors are identified in red.
Warnings are identified in yellow.
Ignored are not visible.

Heuristic Sections

The following table details each heuristic section and its default level.

Global

Name	Description	Default
Entities in the same class have different names.	Entities with similar or identical names make it difficult to differentiate when selecting the entities for relationships. Selecting the wrong entity can cause significant damage. 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
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
Entity Numbers are unique within a class.	Entities with identical numbers in the same 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
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 they should be replaced with more precise language lower down in a hierarchy. Note: Statements/Requirements are ignored and checked by the Requirements Quality Checker.	Warning
Every entity is related to some other entity.	Entities that have no relationships to other entities may be unnecessary. Note: If an entity fails this check most other checks will be automatically omitted.	Warning

Action

Name	Description	Default
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 the action represents a use case, add the ‘Use Case’ label to exempt the entity from this rule.	Warning
Action Names begin with a capital letter.	Action names should be capitalized consistently.	Ignore All
Each action has a name.	All actions should have a name identifying what they represent.	Error
Each action has a number.	All actions should have a number for cataloging in the database.	Warning
Each action has a description.	All actions should have a description to elaborate their purpose.	Ignore All
Each action has a child or parent.	As models mature, actions typically will not stand on their own, but rather form a hierarchy. Each entity will either decompose a parent action or be decomposed by a child action. A hierarchy of actions is useful for grouping and organizing related actions.	Warning
No action has exactly one child	Actions are usually decomposed into two or more children or no children at all. Decomposing an action into just one action implies an equivalency between the two actions that are often redundant. This warning may be ignored if this hierarchy is a work in progress or if the one-to-one decomposition is intentional for style reasons.	Warning
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 of actions at a single level is between three and six actions; Miller (a psychologist referring to pieces of information in general) recommends a user can best work with a maximum of seven plus or minus two. Decompose further if the number of entities at any given level exceeds these recommendations.	Warning
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 actions being reused or mapped to multiple taxonomies. However, sometimes it is accidental and results in ambiguity. The path of parentage to follow when opening parent diagrams is disrupted when there is more than one parent.	Warning
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 should eventually be specified. If an action cannot be mapped to a single asset, consider regrouping the entities 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
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
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
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
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
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 exceptions 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
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
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

Name	Description	Default
All Asset Names are noun phrases.	Asset names should be nouns or noun phrases, preferably using the common, collective, or compound noun type.	Warning
Asset Names begin with a capital letter.	Action names should be capitalized consistently throughout the model.	Ignore All
Each asset has a name.	All assets should have a name identifying what it represents.	Error
Each asset has a number.	All assets should have a number to catalog it in the database.	Warning
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
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
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
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 are often redundant. This flag may be ignored if this is a work in progress (more assets will be added) or if the one-to-one decomposition relationship is intentional for style reasons.	Warning
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
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
Each asset is connected by at least one conduit.	To support interactions with other assets of any sort, a non-root asset needs to be connected to at least one conduit.	Warning
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
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
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

Name	Description	Default
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
Each conduit has a name.	All conduits should have a name identifying what it represents.	Warning
Each conduit has a number.	All conduits should have a number to catalog it in the database.	Ignore All
Each conduit has a description.	All conduits should have a description that elaborates on their meaning for the benefit of team members and other reviewers.	Ignore All
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
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
Every conduit that connects any two assets and transfers an input/output between those assets references 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
Each conduit transfers at least one input/output.	A conduit with no input/outputs assigned to it may be unnecessary or incomplete.	Warning
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

I/O

Name	Description	Default
Each input/output has a name.	All input/outputs should have a name identifying what it represents.	Error
Each input/output has a number.	All input/outputs should have a number to catalog them in the database.	Ignore All
Each input/output has a description.	All input/outputs should have a description that elaborates on their meaning for the benefit of team members and other reviewers.	Ignore All
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
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
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
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
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
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
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

Name	Description	Default
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
Shall be 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
Each requirement has a name.	All requirements should have a name identifying what it represents.	Warning
Each requirement has a number.	All requirements should have a number to catalog them in the database.	Warning
Each requirement has a description.	All requirements should have a description that elaborates on their meaning for the benefit of team members and other reviewers.	Warning
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
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
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
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 inputs/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

To continue learning about Analysis Widgets, Click Here.

(Next Article: Bar Chart Analysis Widget)