Relational Diagram

Purpose: The purpose of the Relational Diagram is to document the relationship between different types of information on a physical level. Below, you can see an example of a Relational Diagram showing the relationship an Order in a booking system to related data.

Core concerns: The Relational Diagram is a physical data model and consists of Tables and Physical Foreign Keys. Inside each table, information about Indexes, the related Data Entity, Columns and Physical keys.

Relation to other templates: The Relational Diagram offers a more detailed view on data and its interrelationships than for example the Conceptual Data Model and the Business Object Model. Other physical data models include the Data Mapping Diagram, the Class Diagram, the Data Model Diagram and the Data Replication Diagram.

Properties and metadata: The Relational Diagram can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Relational Diagram’s properties dialogue window, where the properties can be viewed and edited:

Data Model Diagram

Purpose: The Purpose of the Data Model Diagram template is to model the structure of data entities of an Information System and their relationships. Documenting the structure of information is a very important part of the preliminary analysis before implementing any Information System.

Core concerns: The Data Model Diagram template enables the user to document the structure of the information, that an Information System is supposed to store. The template allows you to model using Data Entities, Subject Area, Data Entity View, Model View and inheritance. The Connection types available are: Data Relation, Inheritance Connection, Complex Relation and Generalization. Below you can see an example of a Data Model Diagram describing the information structure related to an order:

DataModelDiagram_1

Relation to other templates: The Data Model Diagram template should not be used to document data flows. In that case the Data Flow Diagram template should be used.

Properties and metadata: The Data Model Diagram can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

The above picture shows the properties dialogue window for the Data Model Diagram where you can view and edit the diagram’s properties.

 

 

Data Flow Diagram

Purpose: The purpose of the Data Flow Diagram is to document a system’s or part of a system’s data flows; the data input the system (or a process within the system) consumes and the data output the system produces.

Core concerns: The Data Flow Diagram enables you to model Processes, Data Stores, External Entities, Control Processes and Control Stores. These elements can then be connected by either Data Flows or Control Flows.

Graphical representation of the elements:

The Data Flow Diagram can show different levels of processes within a system that exchange data, and illustrate how those exchanges occur. As such, the model can document a system’s functional hierarchies.

Below, you can see an example of a Data Flow Diagram showing the Data Flows between several Data Stores, Processes and External Entities in a Bookshop:

DataFlowDiagram_2

The next example shows the Data Flow between process, Data Stores and External Entities for a Highway Repair Service:

DataFlowDiagram_1

The final example shows the Data Flows between Processes, Datastores and External Entities in an Outlook Mailbox:

dfd

Relation to other templates: The Processes in the Data Flow Diagram can be decomposed into more detailed Data Flow Diagrams to comprise the total functional model. The top level of a Data Flow Diagram is sometimes called a Context Diagram. However, in QLM we use the Data Flow Diagram template for the higher levels as well as the more detailed ones.

The Data Flow Diagram can be a decomposition of an Information System. It can offer a more detailed view of Data Flows than, for example, the Application Architecture Diagram.

An Information System could likewise be decomposed into a Business Process Diagram which offers a complimentary view less concerned with Data Stores and Data Flow, and more concerned with Activity Flow.

Properties and metadata: The Data Flow Diagram template ­­­­can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Data Flow Diagram template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Conceptual Data Model

Purpose: The Conceptual Data Model template is used to describe a high-level business oriented structure of the information concept used in a specific business area. Below yo can se an example of a Conceptual Data Model where the data is divided into data for internal and external use:

ConceptualDataModel_2

Core concerns: The conceptual data model template enables you to model a preliminary high level data model. It may be abstract in content and sparse in attributes. Its preliminary structure allows for many-to-many relationships. When using the Conceptual Data Model, you can model Information Concepts, Subject Areas, and their interrelationships. Below, you can see a car rental service’s Conceptual Data Model for a customer’s data.

ConceptualDataModel_1

Relation to other templates: The conceptual data model is a means of communicating information structures between participants in a project or documenting the overall Information Concept of a specific organization. For a more detailed model you should use a Data Model Diagram.

Properties and metadata: The Conceptual Data Model can for example retain the following metadata:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Conceptual Data Model’s properties dialogue window, where the information can be viewed and edited:

Concept Model

Purpose: The purpose of a Concept Model is to organize an enterprise’s vocabulary to support cPonsistent and unambiguous communication about specific problem domains across business units.

Core concerns: The Concept Model template enables you to model Concepts, Specialization Aspects and Subject Areas. They can be linked by Concept Associations, Concept Aggregations, Concept Generalizations, Type Relationships, and Relationship Constraints.

You are also able to link the diagram to its area of usage through the model’s property dialogue. This area of usage can by default be set to be either an Organization Unit, Role, Actor or External Entity.

Below you can see some examples of Concept Models from a healthcare domain:

The model above shows the concepts related to the healthcare activity ‘knee arthroplasty’. The model below shows the concepts related to a signature in the healthcare domain:

ConceptModel_1

The model above shows the concepts related to the healthcare activity ‘knee arthroplasty’.

The model below shows the concepts related to a signature in the healthcare domain:

ConceptModel_2

Relation to other templates: A Concept Model should enable the identification of the right terms to use in communications where high precision is needed. This is useful when creating large sets of business rules or processes that need to fit together without ambiguity and when creating complex Data Models. As such, it could be advantageous to link to a concept model from the affected Business Process Networks, Workflow Diagrams, Requirements Models and Regulation Diagrams.

Properties and metadata: The Concept Model can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the model
  • Link to the one responsible for the model
  • Link to view of area of usage
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Concept Model, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: to learn more about Concept Models, you can read the following article:

Ronald G. Ross , “What Is a Concept Model?” Business Rules Journal Vol. 15, No. 10, (Oct. 2014). URL: http://www.brcommunity.com/a2014/b779.html

Business Object Model

Purpose: The purpose of the Business Object Model is to present a structured view of an organization’s products and services.

Core concerns: The focus of this template is the Business Object that can be described through Decomposition, Generalization, Association and Dependency with other Business Objects. Notes can be used to group Business Objects, for example as High-Growth Revenue Products, as seen in the below model:

BusinessObjectModel

The modelling syntax can be extended to also include strategic elements such as: Requirements, Problems, Change Requests, Goals, Performance Indicators and policies. They can be connected to the Business Objects through Strategic Alignment.

Relation to other templates: The Business Object Model belongs to the Information domain where it offers a conceptual and logical view of an organizations products and services. As such, it is related to templates such as Product Canvas, Product Roadmap and Product Variant Master

Properties and metadata: The Business Object Model can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Business Object Model, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Requirements Realization Viewpoint

Concerns: Architecture strategy and tactics, motivation
Purpose: Designing, deciding, informing
Scope: Motivation

The requirements realization viewpoint allows the designer to model the realization of requirements by the core elements, such as business actors, business services, business processes, application services, application components, etc. Typically, the requirements result from the goal refinement viewpoint.

In addition, this viewpoint can be used to refine requirements into more detailed requirements. The aggregation relationship is used for this purpose.