TRAK-Community

Title

MVp-03 - Requirements and Standards Viewpoint

Version

8

Date

6th August 2011

Overview

The MVp-03 - Requirements and StandardsViewpoint is part of the Management Perspective and one of the 21 TRAK Architecture Viewpoints.

The MVp-03 Architecture Description Design Record Viewpoint provides a way of capturing normative requirements whether standards, requirement documents, government acts, or individual requirements.

It is the specification for the TRAK::MV-03 - Requirements and Standards architecture view.

Stakeholders Addressed

• Builder of Architecture Task
• Developer of Architecture Task
• Owner of Architecture Task
• User of Architecture Task
• Builder of Enterprise
• Developer of Enterprise
• Maintainer of Enterprise
• Owner of Enterprise
• Owner of Concept
• User of Concept
• Developer of Concept
• Acquirer of Solution
• Builder of Solution
• Developer of Solution
• Disposer of Solution
• Maintainer of Solution
• Operator of Solution
• Owner of Solution
• Trainer of Solution
• User of Solution

Full size:File:mvp03StakeholderConcern.pdf

Concerns Addressed

What other constraints/requirements through normative documents/ standards apply (or will apply) to the system, project, enterprise?

Covered by TRAK IPR and licenses

Description

Describes the constraints that apply to an architecture element through requirements and standards or how standards depend on one another.

Covered by TRAK IPR and licenses

Mandatory Metamodel Tuples

The 2 TRAK metamodel stereotypes that represent a requirement or a constraint are Requirement and Standard, both of which can be applied to any architecture description element. It is useful to break down the sets of tuples by the TRAK perspective as these represent typical application scopes.

Enterprise Constraints

These represent enterprise or capability requirements/constraints:

• Enterprise traces to Requirement
• Enterprise Goal traces to Requirement
• Capability traces to Requirement

Concept Constraints

These represent concept requirements/constraints:

• Need traces to Requirement
• Node traces to Requirement
• Concept Activity traces to Requirement
• Item traces to Requirement

Procurement constraints

These represent requirements/constraints placed on the procurement of solution(s):

• Project traces to Requirement
• Project Activity traces to Requirement
• Milestone traces to Requirement

Solution Constraints

These represent requirements/constraints placed on the solution(s):

• Resource traces to Requirement
• Resource Interaction traces to Requirement
• Port Connection traces to Requirement
• Interaction Element traces to Requirement
• Function traces to Requirement
• Protocol traces to Requirement

where Resource = System, Physical, Software, Organisation, Job or Role

Management Constraints

These represent general (multiple perspective) constraints or requirements i.e. those that are of a general nature or those that apply to elements within the management perspective:

• Requirement traces to Requirement
• Requirement has part Requirement
• Standard governs Architecture Task
• Standard governs Architecture Description
• Standard governs View
• Standard governs Concern

Standards Applicable

Where the applicability of a standard to an element or where the precedence chain between standards needs to be shown:

• Standard has part Requirement
• Standard traces to Requirement
• Standard governs Architecture Description Element
• Standard has part Standard
• Standard equivalent to Standard
• Standard governs Standard
• Standard enacts Standard
• Standard supersedes Standard
• Standard issued by Organisation

Contract Standards Assessment

Where an assessment needs to be made of the standards being mandated in a contract:

Standards Applicable +

• Contract applies Standard
• Contract has part Contract
• Standard has part Requirement

Full size:File:MVp 03 mandatoryTuples contractStandardsAssessment.gif

Covered by TRAK IPR and licenses

Optional Metamodel Tuples

• Concern about Standard
• Concern about Contract
• Concern about Organisation
• Architecture Description Element traces to Document
• Architecture Description Element traces to Requirement

Covered by TRAK IPR and licenses

Well-Formedness

The MV-03 must contain:

• at least one (Requirement or Standard)
• every Requirement must be connected to at least one other Architecture Description Element
• every Standard must be connected to at least one other Architecture Description Element
• every Architecture Description Element must be uniquely identified

Note:

• If no issue or version number for Standard is identified it is assumed that the latest version applies (even if subsequently withdrawn). This allows an architect to declare that a standard applies before they’ve identified the version.
• attributes should be used to add appropriate detail (TRAK Metamodel document)
  • Requirement has attributes that include requirement ID, compliance level (e.g. mandatory or desirable), priority, paragraph number, type (e.g. legal, commercial or technical)
  • Architecture Description Element has attributes that include security descriptors
  • Document has attributes that include Dublin Core Metadata elements
  • Standard has attributes that include issue date, part, number and withdrawal date

Covered by TRAK IPR and licenses

Presentation

• block diagram
• table

Showing constraints - requirements:

Contract applying standards:

Covered by TRAK IPR and licenses

Examples

Views Needed to Construct

The MV-03 will usually, but not always, be constructed after other views.  Depending on the area in which the constraints apply the following views will precede the MV-03 as they provide the ‘things’ to which the constraints attach to.

Capability constraints

• EV-01 - master architecture view for Enterprise, Enterprise Goal
• EV-02 - master architecture view for Capability

Concept Constraints

• CV-01 - master architecture view for Node, Need
• CV-03 - master architecture view for Item, Item Exchange
• CV-05 - master architecture view for Concept Activity

Procurement Constraints

• PrV-01 - master architecture view for Project
• PrV-02 - master architecture view for Milestone, Project Activity

Solution Constraints

• SV-01 - master architecture view for Resource (Job, Organisation, Physical, Role, Software, System)
• SV-02 - master architecture view for Interaction Element, Port, Port Connection, Protocol, Resource Interaction
• SV-04 - master architecture view for Function
• SV-06 - master architecture view for Competence

Management Constraints

• MV-02 - master architecture view for Architecture Description, Architecture Task, Architecture View, Concern, Document
• MV-03 - master architecture view for Contract, Requirement, Standard.

See Minimum Allowed View Sets

Covered by TRAK IPR and licenses

Consistency Rules

Configuration History

The TRAK Viewpoints project on Sourceforge (trakviewpoints.sourceforge.net) maintains a version-controlled repository. The change record is at trakviewpoints.svn.sourceforge.net/viewvc/trakviewpoints/trunk/?view=log

Comments

The MV-03 is the master architecture view for Contract, Requirement, Standard.

The views produced are expected to focus primarily on standards or on requirements. Requirement-focussed views will make it possible to show how the architecture description links to products from requirement management tools such as DOORS and also act as a justification for the way in which the architecture has been represented in the architecture description.  It is not the purpose of an architecture framework to manage requirements. Is it the purpose of TRAK to provide a means of integrating architecture description with dedicated requirement management tools.

In selecting by TRAK perspective views can be used to correspond to Capability Requirement Documents, Operational Requirement Documents and System Requirement Documents. Requirements aren’t just technical - they may be commercial. Any constraint has at some stage to be formally captured by a requirement.

More complicated forms are possible by using the date of issue of the standard as a filter. Note that usually, with the exception of national law and safety, once a standard has been applied by contract it will preserve the issue of the standard applied irrespective of an more recent issues.

Covered by TRAK IPR and licenses

References

• TRAK Enterprise Architecture Framework Viewpoints. trakviewpoints.sourceforge.net
• TRAK Enterprise Architecture Framework Metamodel. trakmetamodel.sourceforge.net

Other Frameworks

Representation of logical/operational or implementation-free constraints:

• DNDAF::OV-6a Operational Rules Model Subview
• DODAF::OV-6a Operational Rules Model
• MODAF::OV-6a Operational Rules Model View
• NAF::NOV-6a Operational Rule Model Subview

Constraints on services:

• DODAF::SvcV-10a Services Rules Model
• MODAF::SOV-4a Service Constraints View

Representation of implementation or solution constraints:

Solution Performance characterisation:

• DNDAF::SV-7 Systems Performance Parameters Matrix Subview
• DODAF::SV-7 Systems Measures Matrix Model (deprecated in favour of DODAF::SvcV-7 Services Measures Matrix Model)
• MODAF::SV-7 Resource Performance Parameters Matrix View
• NAF::NSV-7 System Quality Requirements Description Subview

or rules:

• DNDAF::SV-10a Systems Rules Model Subview
• DODAF::SV-10a Systems Rules Model
• MODAF::SV-10a Resource Constraints Specification View
• NAF::NSV-10a Systems Rule Model Subview

Representation of collections of constraints in Standards:

• DNDAF::TV-1 Standards Profile Subview and DNDAF::TV-2 Standards Forecast Subview
• DODAF::StdV-1 Standards Profile Model and DODAF::StdV-2 Standards Forecast Model
• MODAF::TV-1 Standards Profile View
• NAF::NTV-1 Technical Standards Profile Subview

Category:Framework -> Viewpoint
Category:Framework -> Specification
Category:Management
Category:Architecture Perspective -> Management

Categories:

• Architecture Perspective
  • Management
• Framework
  • Specification
• Viewpoint

Management