Template Type: Diagrams

Decision Requirements Diagram DMN

The Decision Requirement Diagram shows how a set of decisions depend on each other, on input data, and on business knowledge models.

The Decision Requirement Diagram is a part of the Decision Model Notation (DMN) from OMG.

“The primary goal of DMN is to provide a common notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements and then more detailed decision models, to the technical developers responsible for automating the decisions in processes”.

 

 

Package Diagram

Purpose: The purpose of the Package Diagram is to group elements of a large system and illustrate the dependencies between them.

Core concerns: The Package Diagram can be used to organize a system’s parts and enables you to model Packages, Profiles and Annotations. These can be connected using Dependency, Profile Application, Package Merge, Package Import and Containment.

Below, you can see an example of a Package Diagram for a booking system for a car rental service:

 

Relation to other templates: The Package diagram offers a simplified view of for example a Class Diagram, grouping classes into packages. It should be used when a class diagram becomes too large and complex to easily read.

Properties and metadata: The Package 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 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 Package Diagram template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Production Site

Purpose: The purpose of the Production Site template is to provide a model over the content and flow of a production site.

Core Concerns: The Production Site template enables you to model Production Lines, Work Centers, Equipment, Inventory and Fixed Installations. These elements can then be connected by Logistical Flows, Wires or Transport Systems. Below, you can see an example of a ‘Job Shop’ Production Site:

The Production Site can in its property window have its production process environment classified as being either a:

  • “Job Shop” which is characterized by the organization of similar equipment by function such as drilling, welding, painting and assembly. As jobs flow from work center to work center a different type of operations is performed in each center.
  • “Continuous Flow” which is characterized by an uninterrupted flow in the production such as processing of fluids, wastes, powders and basic metals., e.g. and oil refinery.
  • “Dedicated Repetitive Flow” which is characterized by production of discrete parts in a production facility dedicated to only one product.
  • “Batch Flow” which is characterized as a flow shop design producing more than one product. Due to long setup time production is run in large batches, e.g. a brewery where production line needs to be cleaned up between each batch to avoid product contamination from previous product.
  • “Fixed Site” which is characterized by transportation of materials, tools and personnel to a fixed location where the product will be built, e.g. shipbuilding, construction and assembly of item that are difficult to move.

 

Relation to other templates: The Production Site template offers an additional perspective to the Product Architecture, Product Canvas, and Product Roadmap templates. Together, these templates illustrate the different aspects of the production process.

 

Properties and metadata: The Production Site 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 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 Production Site  where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Structure Chart

Purpose: The purpose of the Structure Chart is to show the physical design of a program. A subroutine or a module.

Core concerns: The Structure Chart template enables you to model Modules and Data Stores. These elements can then be linked by Module Parameters and Connections. The Structure Chart is built as a hierarchy of modules calling each other. The connections are Parameters that are transferred through these calls.

Below, you can see an example of a Structure Chart, where the data flows are illustrated by arrows:

Relation to other templates: The Structure Chart is part of the information domain. As such it is related to, for example, the Data Flow Diagram, Communication Diagram, Data Mapping Diagram, Data Model Diagram, and the Relational Diagram.

Properties and metadata: The Structure Chart template ­­­­can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the Chart
  • Link to the one responsible for the Chart
  • 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 Chart

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

Timing Diagram

Purpose: The purpose of the Timing Diagram is to show the change in state or the condition of a lifeline over time.

Core concerns: The Timing Diagram template enables you to model Lifelines, Duration Constraints, Time Constraints, Tick Marks and Annotations. These elements can be connected by Messages or Lifeline Changes.

The most common usage of a Timing Diagram is to show the change in state of an object over time in response to accepted events or stimuli.

Below, you can see an example of a simple Timing Diagram for the user of a ATM:

Relation to other templates: The Timing Diagram is part of the UML templates QualiWare supports along with the Activity Diagram, Communication Diagram, Deployment Diagram, Class Diagram, Composite Structure Diagram, State Diagram, Package Diagram, Component Diagram, Sequence Diagram, Use case diagram, and Composite structure Diagram.

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

  • A description of the diagram
  • Extensions (Stereotypes, Constraints and Tagged values)
  • 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 Timing Diagram template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: To learn more about the UML, please visit the Object Management Group’s Website, where you can find the complete specification.

Business Operating Model

Purpose: The purpose of the Business Operating Model is to visualize how an organization functions and delivers value to its customers. The model presents a ‘one-page-overview’ of the organization and offers a quick way to communicate an organization’s value structure to different types of stakeholders.

Core concerns: The Business Operating Model can be put together in numerous ways including information on Stakeholders, Business Processes, Products, Projects, Channels, Key Performance Indicators and more. This enables you to create a Business Operating Model that reflects your organization’s specific value chain in detail. Below is an example of a Business Operating Model that shows a business’s suppliers, high-level processes, products & services, channels and customer segments:

Relation to other templates: The Business Operating Model is a strategic model that can be supplied with more detailed models such as a Business Capability Model, Requirement Models, Stakeholder Models and the Business Ecosystem Model.

Properties and metadata: The Business Operating 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 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 Business Operating Model’s properties dialogue window, where the information can be viewed and edited:

Work Model

Purpose: The purpose of the Work Model template is to document development methods or project models.

Core concerns: The Work Model template enables you to model Project Activities, Milestones, Results, Quality Controls, Document Structures and Business Scopes. These objects are joined by Connections indicating a flow.

The Work Model template can, for example, be used by Enterprise Architects to document the Enterprise Architecture process from start to finish while covering all the project activities, milestones, and results. The Work Model helps ensure a standardized approach.

Below, you can see a few examples of Work Models utilizing a variety of the available objects:

 

The above model shows a simple project flow enriched with mile stones, results and a quality control.

The above model illustrates another generic model for a software development project – this example has more milestones inserted as well as added document structures containing project deliverable templates.

Relation to other templates: The Work Model template should be used to document project activities – to document business processes and workflows should be documented in Business Process Networks, Workflow Diagrams or Business Process Diagrams.

For a more detailed view of the structure of a project’s results and resources, a Work Breakdown Structure template should be used.

 

Properties and metadata: The Work 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
  • 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 Work Model, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

Workflow Diagram

Purpose: The purpose of the Workflow Diagram template is to document the Business Processes of an enterprise at the activity level.

Concerns: The Workflow Diagram template should be used to document the Activities, Roles, Business Events, Activity Paths and Workflow Conditions of a Business Process. Available in the default modeling syntax are also Business Objects, External Objects, Information Systems, Database, Inventory, Information Flow and Logistical Flow. The syntax can be easily extended to include more objects such as Requirements, Business Rules and Goals. Below you can see an example of a Workflow Diagram with multiple Roles that are modelled vertically:

WorkFlowDiagram_2

Relation to other templates: The Workflow Diagram does not support BPMN, if using that notation, you should model in the Business Process Diagram template. The Workflow Diagram can link to other Workflow Diagrams and are typically linked to by Business Process Networks. In the picture below, you can see another example of a Workflow Diagram. Here the Roles are modelled horizontally and you can see the links to and from other diagrams at two Business Events (‘ECR completed’ and ‘Rework’):WorkFlowDiagram_1

Other functionalities: In QLM, you can control which buttons related to risk management are shown below activities. You can choose to hide or show Risks, Controls and Key Controls. Both Controls and Key Controls are a type of Activity. From the Risk related toolbars (available via the “Actions” tab on the right-hand side of the Canvas in QLM) choose the following button to control what button panels appear on the Activity objects:

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

  • A description of the diagram
  • Information on cost and duration of the process
  • 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 Workflow Diagram’s properties dialogue window, where the diagram’s properties can be viewed and edited:

Use Case Diagram

Purpose: The purpose of the Use Case Diagram template is to document user interactions in a system context, as well as the context between different cases of user interactions. Below, you can see an example of a Use Case Diagram for the service at a restaurant:

UseCaseDiagram_2

Core concerns: The available objects you have to model use cases include: System Boundary, Actors, Use Cases, and connectors such as Association, Generalization, Include and Extend. Below, you can see an example of a Use Case Diagram for a booking system at a car rental service:

UseCaseDiagram_1

Relation to other diagrams: It is important to break down use cases into other diagrams such as Sequence Diagrams, Communication Diagrams, and Activity Diagrams templates for elaboration.

Properties and metadata: The Use Case 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 Use Case Diagram’s properties dialogue window, where the properties can be viewed and edited:

Transformation Plan

Purpose: The purpose of the Transformation Plan template is to document strategic transitions over time in the form of transformation plans. Below is an example of a Transformation Plan consisting of a sequence of projects:

TransformationPlan_2

Core concerns: The Transformation Plan template should be used to document the transformation of a part of an enterprise from a current to a future state. Additionally, a past state can be documented for reference. The template allows you to model Projects, Initiatives and Business Cases, and connect them with Activity paths and generic Connections. Below is an example of a Transformation Plan that specifies Initiatives, their related Projects and Business Case:

TransformationPlan_1

Relation to other templates: The Transformation Plan template should not be used to document project plans for calculating a Critical Path. The Critical Path Method Diagram should be used for that purpose. The Projects can be further detailed in a Work Model that includes Milestones in its syntax.

Properties and metadata: The Transformation Plan 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 Transformation Plan’s properties dialogue window, where the properties can be viewed and edited: