View DNDAF:OV-6a Operational Rules Model Subview



OV-6a Operational Rules Model Subview

Version & Date

1.6 See DNDAF Release History


The OV-6a subview is part of the DNDAF Operational View.

The Operations View-6a (OV-6a): the Operational Rules Model describes rules that dictate what the operation “must” do, or what it “cannot” do. Rules are statements that define or constrain some aspect of the architecture. Operational rules can include guidance such as the conditions under which operational control passes from one entity to another, or the conditions under which a human role is authorized to proceed with a specific activity.

Other operational sub-views may describe what the business can do. For the most part, they do not describe what the business “must” do, or what it “cannot” do. These are addressed by OV-6a.


The purpose of OV-6a is to describe what the business must do, or what it cannot do.


Management needs to understand the governance elements that impact the architecture project. What are the “rules of engagement”? What constraints apply? Important characteristics of the architecture project are only discovered when its dynamic behaviours are defined and described. The dynamic behaviour concerns the timing and sequencing of events that capture the operational behaviour of a process.

Three types of models are needed to refine and extend the project architecture’s operational view to adequately describe the dynamic behaviour and performance characteristics of the architecture project. These three models are:

Software-based project architectures will typically use the suite of OV-6 sub-views to describe and define the pertinent operational rules. The OV-6a captures additional Concept of Operations information introduced by the Operational Process Model (OV-5b) and/or the Logical Data Model (OV-7).



The Operational Rules Model specifies operational or business rules that are constraints on the architecture project.

Detailed Description

Detailed rules can become quite complex, and the structuring of the rules themselves can often be challenging. OV-6a extends the representation of business requirements and concept of operations by capturing both action assertions and derivations; this may be done in the form of operational rules that are expressed in a formal language. Action assertions are constraints on the results that actions produce, such as if-then and integrity constraints. Derivations are algorithmically derived facts based on other terms, facts, derivations and/or action assertions.

Operational rules can be grouped into the following categories:

  • Structural Assertions: These rules concern mission or business domain terms and facts that are usually captured by the entities and relationships of Entity-Relationship (E/R) models. They reflect static aspects of business rules that may also be captured in the Logical Data Model (OV- 7).
    • Terms: Entities
    • Facts: Association between two or more terms (i.e., relationship)
  • Action Assertions: These rules concern some dynamic aspects of the business and specify constraints on the results that actions produce. There are three types of action assertions:

    • Condition: This is a guard or if portion of an if-then statement. If the condition is true, it may signal the need to enforce or test additional action assertions.
    • Integrity Constraint: These must always be true (e.g., a declarative statement).
    • Authorization: This restricts certain actions to certain human roles or users.
  • Derivations: These rules concern algorithms used to compute a derivable fact from other terms, facts, derivations, or action assertions.

OV-6a can concentrate on the more dynamic Action Assertions and Derivations rules, because the Structural Assertion rules are usually captured in OV-7.

Operational rules exhibit the following characteristics:

  • Independent of the modeling paradigm used;
  • Declarative (non-procedural);
  • Atomic (indivisible yet inclusive);
  • Expressed in a formal language such as:
    • Decision trees and tables
    • Structured English
    • Mathematical logic
    • Distinct, independent constructs;
    • Mission/business-oriented.
  • OV-6a can be associated with the appropriate activities described in the OV-5b sub-view. rule might prescribe the specific set of inputs required to produce a given output. OV-6a can also be used to extend the capture of business requirements by constraining the structure and validity of certain OV-7 data elements.

    The OV-6a is the follow-on from the OV-7. The OV-7 defines the high-level inter-relationships and rules while the OV-6a concentrates on the internal rules. Both products use the same template and modelling method such as IDEF1X.

    CV-2 should capture information about the rules specified in OV-6a. For example, the Meta Data Repository (MDR) should have information on the type of rule (i.e., Structural Assertion, Action Assertion, or Derivation), the text for the rule, and the relationship between the rules and other architecture product architecture data elements, such as activities from OV-5b or entities from OV-7.

Subview DADM Elements

The DADM entities and attributes provided below are the elements that this sub-view is responsible for creating:




  • text, structured text
  • IDEF0 process logic diagram
  • UML Activity Diagram
  • Business Process Management (BPM) diagrams
  • SysML Requirements Diagram



  • p57 Figure 3.11.1 in DND/CF Architecture Framework (DNDAF)  Volume 2: DND/CF Views and Sub-Views


The OV-5b is the prerequisite for this sub-view:

  • OV-5b. OV-5b provides the context for specifying operational rules such as: “if (these conditions) exist, and (this event) occurs, then (don’t perform these activities).”.


See DNDAF Subview Dependencies




Other Frameworks

See also:


Category:Framework -> Specification
Category:Framework -> Subview



© 2010 Eclectica Systems Ltd.