Business Analysts | QualiWare Center of Excellence

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:

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’):

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:

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:

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

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.

Rule Family Table

Purpose: The Rule Family Table template is used as an auxiliary template to document Rule Family symbols from Decision Models in more detail.

Core concerns: The Rule Family Table template should be used to model Rule Family symbols in more detail, describing the decision in more detail and listing each eventuality relevant to the Rule Family. Each row represents a possible combination of rules in the Rule Family. For example, in the eventuality that there are 3 rules with 2 possibilities each, there will be 2^3=8 rows in the Rule Family Table. Below are two examples of Rule Family Tables:

Relation to other templates: The Rule Family template is used to detail Decision Models and should not be used to document decisions in a stand-alone context. It should always be used as an extension to Rule Family symbols.

Properties and metadata: The Rule Family Table 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 Rule Family Table’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:

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:

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

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:

Regulation Diagram

Purpose: The purpose of the Regulation Diagram template is to document those regulations the enterprise is subject to in detail, so it can be identified how the enterprise must adhere to them.

Core concerns: The Regulation Diagram template can model Regulations, Licenses, Business Scopes, Activities, Business Objects and their Connections. With this pallet of objects, you can model an overview of the regulations your organization must adhere to and break them down to more detailed diagrams describing their paragraphs. We recommend you keep it simple and link the regulations to the relevant Business Processes rather than modelling them in a complex diagram. Below, you can see two example of how you could model a Regulation Diagram for the ISO 9001:2008 standard:

Relation to other templates: As mentioned, the regulations can be linked to the relevant Business Processes or Activities, that typically are detailed in a Workflow Diagram or Business Process Diagram. The Regulation could then be shown as a link below the relevant Business Process or Activity:

How the enterprise will live up to the requirements from the different regulations can also be modelled in a Requirement Model.

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

Product Rule Table

Purpose: The purpose of the Product Rule Table template is to document the rules pertaining to a specific product.

Core concerns: The Product Rule Table is used as an auxiliary template and functions like a matrix that contains Product Rules.

Below, you can see an example of a Product Rule Table for a balcony:

Relation to other templates: The Product Rule Table is related to templates such as Manufacturing Routing Network, Product Architecture, and Product Variant Master.

Properties and metadata: The Product Rule Table can for example retain the following information:

A description of the table
Audits (auto generated information regarding its current state and access rights)
Matrix Behavior

The above picture shows the properties dialogue window for the Product Rule Table where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Product Canvas

Purpose: The purpose of the Product Canvas template is to present the relevant information related to a specific product.

Core concerns: The Product Canvas template enables you to gather relevant Business Charts and model Personae, Product Demands, Markets, Locations and Products. Additionally, you can model a SWOT analysis that details the Strengths, Weaknesses, Opportunities and Threats the product is affected by.

Below, you can see two Product Canvases. The first has its focus on a product within two markets, showing the expectations two different customer segments have to the product.

The second example shows information related to a specific market, Poland, including product architecture and business assessment:

Relation to other templates:

The Product Canvas Template is inherently related to the Product Architecture, Product Roadmap and Product Variant Master, in the sense that all these models focus on different aspects of the lifecycle of a product. Furthermore, you can create additional Business Charts for the Product Canvas by using the dedicated template. Another view on projects and initiatives are provided from the Enterprise Investment Portfolio. There, the reasoning behind the investment in the project is visualized by connecting the initiative (in this case a new product) to the specific goals of the enterprise that it contributes to. Another view on how the product meets customer needs can be documented in the Value Proposition Canvas.

Properties and metadata: The Product Canvas can for example retain the following information:

A description of the diagram
Link to the owner of the canvas
Link to the one responsible for the canvas
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 Product Canvas where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

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:

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:

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:

Matrix

Purpose: The Matrix template is used as an auxiliary diagram type for other diagrams. It can either show the properties or links of and between existing objects.

Concerns: There can be generated three types of Matrix diagrams: Link Matrices, Property Matrices and Text Matrices.

Link Matrices are typically used to summarize the links of two different template types. For example, a Link Matrix can be created using Business Process as the rows and Information Systems as the columns to quickly get an overview over which Information Systems are linked to which Business Processes under IT -Support.
Property Matrices can be used to summarize the contents of many objects, for example, of a single template type in a single diagram. For example, a Property Matrix can be created for Information Systems to obtain an overview over the details describing all the relevant Information Systems and identify any gaps in the information. You could also choose to filter the items in the template, so only the Information Systems used in a specified process are shown.
Text Matrices function as a regular spreadsheet. This type of matrix can for example be used to store data used for KPIs

Below is an example of a property matrix detailing the risks and control processes related to the process called ‘Inventory’:

Below is an example of a link matrix detailing the relation between three identified risks and several controls (from the diagram, you can see that only two of three risks are addressed by the control processes):

Relation to other templates: Where the Matrix can be used as a backend tool, Query Result Views (QRV’s) are created to give an overview of specific objects and their attributes on the collaboration platform.

Properties and metadata: The Matrix template can for example retain the following information:

A description of the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects

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

You can also edit the properties of the Matrix in the properties dialogue window by changing the Matrix behavior, Row filter or Column filter.