Heuristic Analysis Widget

Last modified on May 4th, 2022.


For information on widgets in dashboards go here.

Header Toolbar

IconNameDescription
LockLocks the widget from being moved.
Unignore AllShows all issues that were manually ignored using the red ignore button. This Unignore All button will not appear unless an issue was manually ignored.
Maximize/MinimizeExpands/Minimizes all heuristic sections in the widget.
Edit WidgetOpens 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.
RemoveRemoves Widget from the Intelligence Dashboard.

Heuristic

Issues

Issues contain the entity name and number as well as two options fix and Ignore. The name and number can be clicked to go the entity view of that given entity. Fix allows the correction of the issue based on its given heuristic section. Once the issue has been fixed it will be grayed out until the "Run" button is pressed again. The ignore allows the hiding of specific issues. Ignore can be undone by clicking the "Unignore All button" on the header toolbar.

Heuristic Levels

Heuristic Sections

A table detailing each heuristic section and its default level:

Global

NameDescriptionDefault
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
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 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
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
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

NameDescriptionDefault
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 Names begin with a capital letter.Action names should be capitalized consistently throughout the model.Ignore All
Each action has a name.All actions should have a name identifying what it represents.Error
Each action has a number.All actions should have a number to catalog it in the database.Warning
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
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
No action has exactly one childActions (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
No action has more than 12 childrenFor 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
No actions have more than one parentActions 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
Each action is performed by some assetActions 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
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 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
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

NameDescriptionDefault
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 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 parentAs 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 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
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

NameDescriptionDefault
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 its 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 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
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

NameDescriptionDefault
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 it in the database.Ignore All
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
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

NameDescriptionDefault
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 used in leaf level requirementsA 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 it in the database.Warning
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
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 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

Heuristic Analysis Widget

Last modified on May 4th, 2022. 


For information on widgets in dashboards go here.

Header Toolbar

IconNameDescription
LockLocks the widget from being moved.
Unignore AllShows all issues that were manually ignored using the red ignore button. This Unignore All button will not appear unless an issue was manually ignored.
Maximize/MinimizeExpands/Minimizes all heuristic sections in the widget.
Edit WidgetOpens 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.
RemoveRemoves Widget from the Intelligence Dashboard.

Heuristic

Issues

Issues contain the entity name and number as well as two options fix and Ignore. The name and number can be clicked to go the entity view of that given entity. Fix allows the correction of the issue based on its given heuristic section. Once the issue has been fixed it will be grayed out until the “Run” button is pressed again. The ignore allows the hiding of specific issues. Ignore can be undone by clicking the “Unignore All button” on the header toolbar.

Heuristic Levels

  • Error (Red)
  • Warning (Yellow)
  • Ignore All (Not Visible)

Heuristic Sections

A table detailing each heuristic section and its default level:

Global

NameDescriptionDefault
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
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 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
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
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

NameDescriptionDefault
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 Names begin with a capital letter.Action names should be capitalized consistently throughout the model.Ignore All
Each action has a name.All actions should have a name identifying what it represents.Error
Each action has a number.All actions should have a number to catalog it in the database.Warning
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
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
No action has exactly one childActions (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
No action has more than 12 childrenFor 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
No actions have more than one parentActions 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
Each action is performed by some assetActions 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
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 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
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

NameDescriptionDefault
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 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 parentAs 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 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
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

NameDescriptionDefault
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 its 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 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
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

NameDescriptionDefault
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 it in the database.Ignore All
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
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

NameDescriptionDefault
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 used in leaf level requirementsA 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 it in the database.Warning
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
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 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