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:

State Machine Diagram

Purpose: The purpose of the State Machine Diagram template is to document the dynamic behavior of a class or an object.

Core concerns: The State Machine Diagram template enables you to model States, Pseudo States, History States, Lines and Annotations. These can be connected by Transitions.

As such, the State Machine Diagram can be used to show the different states of a class or an object and how the class or object responds to various events by changing from one state to another.

Below, you can see an example of a State Machine Diagram for an ATM:

StateMachineDiagram_1

Relation to other templates: The State Machine Diagram can be a decomposition of a State and can also be derived from a Class. The State Machine Diagram template is related to, but cannot replace the State Event Diagram, which is used to document Event States and time dependent behavior of systems.

Properties and metadata: The State Machine 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
  • Link to a specific State of an object the diagram specializes
  • 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 State Machine Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

 

 

State Event Diagram

Purpose: The purpose of the State Event Diagram template is to document the time dependent behavior of a system by showing the different States and State Transitions a system can go through.

Core concerns: The State Event Diagram enables you to model States and connect them with State Transitions. The State can be manipulated by opening its properties dialog and chose ‘Final State’ to illustrate the end of the state. The Start event is created by choosing ‘Start’ in the properties of the State Transition.

Below, you can see an example of a State Event Diagram for an ordering system:

StateEventDiagram_1

Relation to other templates: The State Event Diagram template should not be used to model Machines States. The State Machine Diagram template should be used to model these types of diagrams instead. The State Event Diagram offers a view of a system which is complimentary to those presented by for example, Use Case Diagrams Communication Diagrams, Component diagrams and Sequence Diagrams.

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

Sequence Diagram

Purpose: The purpose of the Sequence Diagram template is to document interactions between processes over time. Below you can see a Sequence Diagram for a car rental’s booking system:

SquenceDiagram_1

Core concerns: Sequence Diagrams are typically used to document object interactions over time in a use case for an Information System. Objects are situated along vertical Lifelines. Horizontal arrows that travel between the lifelines in a set sequence are used to illustrate how message exchanges occur at a specific point in time. The objects available in this model are Lifelines, Combined Fragments, Interaction Use, Gates, Time Constraints and Duration Constraints and Messages. Below, you can see an alternate example of a Sequence Diagram for a car rental’s booking system:

SquenceDiagram_2

Relation to other templates: Though the customer can be included in this type of diagram, you should use the Customer Journey Map to document and analyze the customers’ interactions with your organization. If you want to map a simpler view of actors’ interactions with a system without details on time constraints, you can use a Use Case Diagram.

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

Requirement Model

Purpose: The purpose of the Requirement Model template is to document goals, objectives and other requirements for the enterprise or a specific project. Below, you can see an example of a Requirement Model showing the Policies and Business Rules of an organization:

RequirementModel_1

Core concerns: With the Requirement Model template, you can for example model Requirements, Goals, Change Requests, Policies, Business Rules, Critical Success Factors and Problems. This enables you to illustrate the interrelationships of requirements, for example showing which goals influence or contribute to each other, as the example below shows:

RequirementModel_3

You can also divide goals up in different areas that may for example be subject to different regulations as below:

RequirementModel_2

Relation to other templates: The Requirement Model offers a more detailed view on Requirements and Goals filtering out elements such as vision and mission compared to the Strategy Model. It can be used to detail how your organization live up to requirements specified in a Regulation Diagram or Requirements indicated in a Stakeholder Model.

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

 

 

Product Architecture

Purpose: The purpose of the Product Architecture template is to document the building blocks of a product. Below is an example of a product architecture:

ProductArchitecture_1

Core concerns: The Product Architecture template enables you to model a Product and connect different parts of it with three different connection types: Part of Product, Kind of Product, and Product Interface. See below for an example of a Product Architecture where each Product object is represented graphically:

 ProductArchitecture_2

Relation to other templates: Depending on whether the product is in production or in its development phase, it could be further described in a Product Viewpoint template, have a Product Variant Master, Product Rule Table or be represented in a Product Canvas. It may also be illustrated along with other products in a Product Roadmap, just as its production may be detailed in a Manufacturing Routing Network.

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

Lifecycle Assessment Diagram

Purpose: The purpose of the Life Cycle Assessment Diagram template is to document the relations for an activity or product in a lifecycle context.

Core concerns: The Lifecycle Assessment Diagram concerns itself with modelling elements in a company that interact with the environment. The template enables you to model Environmental Aspects and Objectives for Activities in your organization. This template allows you to model Business Objects, Activities, Performance Indicators, Business Connection, Goals, Policies, Critical Success Factors, Change Requests and Problems. These elements can be grouped into Categories and connected by Impact Quantity, Recycling, Logistical Flows, Information Flows, and Activity Paths.

Below, you can see an example of a Lifecycle Assessment Diagram for a Product, from production to packaging, focusing on reducing unbiodegradable waste:

The elements used in this example are Business Objects as input and output, Activities showing Logistical Flows and Recycle under Process. Under the Environment Category, Environmental Aspects, Impact and Objectives are identified and Policies for reaching the Objectives are also included. The diagram focus on a single Environmental impact: Waste. You can also choose to map out several Environmental impacts that are relevant to a specific activity or product.

Relation to other templates: The Environmental Aspects and Impacts from the Lifecycle Assessment Diagram can be further explored in the Environmental Impact Diagram. The Lifecycle Assessment Diagram is also related to the Business Process Diagram and Workflow Diagram, in the sense that they all are related to detailing aspects of processes. The Lifecycle Assessment Diagram can also be decomposed from the Inventory object shown in, for example, the Production Site template.

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

For more information: You can learn more about Lifecycle Assessment on the US Sustainable Facilities Tool website or turn to ISO standard 14040.

Environmental Impact Diagram

Purpose: The purpose of the Environmental Impact Diagram template is to document the environmental aspects and impacts for an Activity or Business Process.

Core concerns: The Environmental Impact Diagram enables you to model Business Functions, Activities, Business Objects, Environmental Aspects (Environmental Aspect, Environmental Impact, Health and safety impact) and Business Scopes. These elements can then be connected by Impact Quantities.

Below, you can see an example of an Environmental Impact Diagram, detailing the Environmental aspects and Health and safety impact:

EnvironmentalImpactDiagram_1

The diagram shows all identified aspects and modes of impact for one or more specific processes.

Relation to other templates: The Environmental Impact Diagram is related to the Lifecycle Assessment diagram as well as templates containing Activities, Business Functions, Lines of Business, and Logistical Flows. As such, it is related to, for example, Business Process Diagrams, Workflow Diagrams, Business Diagrams, and Strategy Models.

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

  • A description of the diagram
  • Link to the owner
  • Link to the responsible
  • 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 Environmental Impact Diagram, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Decision Model

Purpose: The purpose of the Decision Model template is to document complex decisions by modelling decision trees that illustrates decision gates. Below you can see an example of a Decision Model:

DecisionModel_1

Core concerns: Complex decisions can be documented as decision trees. The model illustrates the Business Decision and its underlying Rule Families. The Rule Families can contain Rule Family Tables, that precisely describe the outcome of a given set of variables. Below you can see an example of a Rule Family Table:

DecisionModel_2

Relation to other templates: Where the Decision Model template illustrates the decision gates, the end to end process is described in either a Work Flow Diagram or a Business Process Diagram.

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