TRAK Architecture Viewpoints

• SourceForge Project Summary

trakviewpoints project

• Introduction
• What is an Architecture Viewpoint?
• Architecture Viewpoints & Views
  • Architecture Viewpoint Concerns
  • Enterprise Perspective
  • Concept Perspective
  • Procurement Perspective
  • Solution Perspective
  • Management Perspective
• Why Use Triples?
• Modelling TRAK Viewpoints
• Open Source
• Download
• Get Support / Join
• Discussion Forums
• Report Bug
• Support Request
• Keep Informed

TRAK SourceForge Projects

Definition

• TRAK
• TRAK Metamodel
• TRAK Viewpoints

Implementation

• Implementations of TRAK
• UML Profile for TRAK
• Rail Symbols
• MDG Technology for TRAK (Sparx Enterprise Architect)
• TRAK MooD 2010 Template
• TRAK OmniGraffle Stencil
• TRAK Visio Template

TRAK Information

• TRAK - Important Ideas
• TRAK FAQs (SF - trak project)
• Projects Using TRAK
• Demo Model
• Supporting Links
• Blog - "The Residual World"
• TRAK Community Wiki
• Community Discussion Forums

 

 

 

 

 

 

 

 

 

 

 

EVp-02 Capability Hierarchy

This page reproduces part of the EVp-02 Capability Hierarchy architecture viewpoint definition from the specification - TRAK00001. TRAK. Architecture Framework. Viewpoints. The page content is therefore subject to the same GNU Free Documentation License terms and conditions - see https://www.gnu.org/licenses/fdl-1.3.html

Most of the content is produced from a model of TRAK produced using a different set of architecture viewpoints!

Version

The TRAK EVp-02 Capability Hierarchy architecture viewpoint is one of 24 architecture viewpoints defined in TRAK00001. TRAK. Architecture Framework. Viewpoints - current release is dated 2024_07_10.

Summary

The TRAK EVp-02 Capability Hierarchy architecture viewpoint defines the requirements for the TRAK EV-02 Capability Hierarchy architecture view. This involves allowed content and minimum acceptable content ('well-formedness' criteria). The TRAK00001. TRAK. Architecture Framework. Viewpoints specification also defines consistency rules that apply to a set of architecture views (an Architecture Description).

The TRAK EVp-02 Capability Hierarchy architecture viewpoint content is summarised under the following sections:

• stakeholder concerns
• description
• allowed content
• well-formedness criteria
• presentation methods
• comments

The TRAK Architecture Viewpoints specification provides are complete definition not only of the EVp-02 Capability Hierarchy architecture viewpoint but considerations for the architecture description formed from a set of architecture views.

Something needs fixing?

Return to the Architecture Viewpoints list or Summary of Architecture Viewpoint Concerns.

Description

Describes the capabilities required by the Enterprise / Enterprise Goal(s) and dependencies on other Capabilities.

Allowed Content

TRAK architecture view content is defined in terms of triples - Node - connector - Node e.g. 'Enterprise Goal requires Capability' that form short statements about the thing(s) being described.

'Enterprise Goal requires Capability' is a Statement or Assertion in a EV-02 Architecture View

The rationale for this is explained separately.

Subject Statements (Triples)

These are statements (triples) that describe the subject of the EV-02 Capability Hierarchy architecture view. Specifically these statements address the concerns for this EVp-02 Capability Hierarchy architecture viewpoint. These form the basis for the well-formedness section of the EVp-02 Capability Hierarchy architecture viewpoint.

There are 5 possible subject statements in total which include 4 metamodel elements ( Capability , Enterprise , Enterprise Goal and Metric ).

Return to the top of the Capability Hierarchy page.

Optional Statements (Triples)

These optional statements (triples) for the EV-02 Capability Hierarchy architecture view provide useful context with respect to a subject or universally allowed statements involving the subject or object (start or finish) elements in the Subject Statements (triples).

Universal statements may be added to any TRAK architecture view and describe typical concepts such as compliance or traceability:

• ... traces to Argument, Contract, Requirement, Document or Standard
• ... satisfies Contract, Requirement, Document or Standard
• Concern or Claim about ...
• Contract, Requirement, Document or Standard governs ...

'Requirement governs Metric' - an optional statement or assertion for the EV-02 Architecture View

These statements address the concerns of their respective architecture viewpoint and will have been created first on these other architecture views.

There are 54 possible statements which may be used to augment the EV-02 Capability Hierarchy architecture view, split into 6 groups:

• Context
• Universal - Applicable Requirements
• Universal - Assurance
• Universal - Concern Identified
• Universal - Requirement Compliance
• Universal - Traceability or Reference

Return to the top of the Capability Hierarchy page.

Well-Formedness Criteria

Well-formedness criteria define the minimum acceptable view content based on the subject statements (triples). These criteria are not yet represented within the model of TRAK. Please refer to the EVp-02 Capability Hierarchy definition within the TRAK00001. TRAK. Architecture Framework. Viewpoints specification.

Presentation Methods

The EV-02 Capability Hierarchy architecture view may use any of following means to the statements (triples):

• block diagram (blocks to represent Enterprise, Capability, Metric and Enterprise Goal)

Note that a textual presentation is acceptable for any TRAK architecture view.

Comments

The EV-02 Capability Hierarchy architecture view is the master source (origin) on which you first create the following elements or statements:

• Capability
• Capability is quantified by Metric

The creation of taxonomies is more concerned with organisation of collections of any architecture description element, not just capability, and associated with repository management.

Taxonomy diagrams of any type of architecture description element can be included with an architecture description either as a non-conforming product where non-TRAK elements are used (see Conformance with TRAK in TRAK Enterprise Architecture Description document) or using the relevant master architecture view for the TRAK element and the MV-01 definitions to support.

Neighbouring Architecture Views

The EV-02 Capability Hierarchy architecture view content may overlap that of the following neighbouring architecture views:

• CV-04 Concept Activity to Capability Mapping
• EV-01 Enterprise Goal
• EV-03 Capability Phasing
• MV-01 Architecture Description Dictionary
• MV-02 Architecture Description Design Record
• MV-03 Requirements and Standards
• MV-04 Assurance

Navigation & Website Tracker

Spotted an error or want to suggest something - create a ticket

Return to the Architecture Viewpoints list or Summary of Architecture Viewpoint Concerns..