Archives: Templates

Templates and model types in the QualiWare platform.

Report

A report executed from a Document Fragment.

Requirement

A Requirement is a prioritized demand placed on the project by one of its interested parties. Often it is the buyer the user or the management that have Requirements to the scope or results of the projects. But it can also technical requirements that appears because of constraints in the physical equipment or the algorithmic solutions chosen.

It is recommended to build a Requirement hierarchy by relating one Requirement to the sub requirements that composes it.

Requirement can be modelled in a Requirement Model.

Requirement:Archimate

In the end, a business goal must be realized by a plan or concrete change goal, which may or may not require a new system or changes to an existing system.

The term “system” is used in its general meaning; i.e., as a group of (functionally) related elements, where each element may be considered as a system again. Therefore, a system may refer to any active structural element, behavior element, or passive structural element of some organization, such as a business actor, application component, business process, application service, business object, or data object.

Requirements model the properties of these elements that are needed to achieve the “ends” that are modeled by the goals. In this respect, requirements represent the “means” to realize goals.
During the design process, goals may be decomposed until the resulting sub-goals are sufficiently detailed to enable their realization by properties that can be exhibited by systems. At this point, goals can be realized by requirements that demand these properties from the systems.
For example, one may identify two alternative requirements to realize the goal to improve portfolio management:

  • By assigning a personal assistant to each customer, or
  • By introducing online portfolio management

The former requirement can be realized by a human actor and the latter by a software application. These requirements can be decomposed further to define the requirements on the human actor and the software application in more detail.

Resource:Archimate

Resources are a central concept in the field of strategic management, economics, computer science, portfolio management, and more. They are often considered, together with capabilities, to be sources of competitive advantage for organizations. Resources are analyzed in terms of strengths and weaknesses, and they are considered when implementing strategies. Due to resources being limited, they can often be a deciding factor for choosing which strategy, goal, and project to implement and in which order. Resources can be classified into tangible assets – financial assets (e.g., cash, securities, borrowing capacity), physical assets (e.g., plant, equipment, land, mineral reserves), intangible assets (technology; e.g., patents, copyrights, trade secrets; reputation; e.g., brand, relationships; culture), and human assets (skills/know-how, capacity for communication and collaboration, motivation). Resources are realized by active and passive structure elements. The name of a resource should preferably be a noun.

Responsibility

Responsibility refers to the assignment of tasks or duties to specific individuals or teams within a larger system or organization. Responsibility can include a range of activities, such as decision-making, task completion, quality assurance, or management.

Arrows or lines may be used to show the relationships and connections between these components. For example, a line might connect a manager to a team to represent how the manager is responsible for overseeing the work of the team. Similarly, a line might connect a team to a task to represent how the team is responsible for completing the task.

Result

A result is a collection of components which are to be produced during a specific project. With the result entity a description of the result is created and links to the tools that are used to produce the result are made. When the links to the tools (e.g. different diagram types or external applications) are made, a double click with the mouse on the result symbol in the Work Model will make the tools accessible to the user through a menu.

The Result object is also available on the diagram type Work Breakdown Structure, where it is used to calculate the cost of a specific project, during the early stages of the project lifecycle. The calculation is based on the principles of “successive calculation” as described in the “Implementation Guide”. When the this approach is used, the project is seen from the project deliverable view point rather than work procedure view point as it is the case with the Work Model approach. A Result will therefore tend to take the role of a work package, aggregating the result and the activities that need to be performed to produce the result. A Result in this situation can be of both material and non material form. This approach is well known from project management theory.