Engineered element is something that is “brought about” by engineers working on issues associated with the engineered element.

For example:

  • One engineer may be trained by another engineer,
  • Persona definition and goals my be elicited by interviewing persona representatives.
  • Software Module source code can be modified to add new functionality.
  • Document can be updated by adding new sections or elaborating existing content.
  • Directory can be populated with resources.
  • Organization can improve its efficiency by formally defining its services as activities and journeys.

Engineered element may have owning engineers, who have authority over the element, and expert engineers, who know how to use the element, but do not have authority. E.g. a software library can be owned by a team of engineers and have experts who use the library in their solutions.

Engineered element can define principles to support decision making and align engineered capabilities, e.g. issues. Published formally documented principles are important for Open and Inner Source projects to ensure contribution process efficiency.

Engineers may be allocated some capacity to work on the engineered element’s issues for a particular endeavor and issue category.

Engineered element is a a subclass of Period and can have start, duration, and end. Semantics of those features depend on a subclass of engineered element. For example:

  • JourneyElement - duration specifies how long it takes to complete an activity. E.g. P1D - one day, or PT2H15M - two hours and 15 minutes.
  • Document, Module and Product - inception and retirement.
  • Persona - when support of a given persona shall start and end.
  • Engineer - when an engineer starts and ends their engagement.
  • Organization - organization formation and disbandment.

Supertypes

Subtypes

Referrers

Issues (work items) for this element.

Type Issue
Cardinality 0..*
Changeable false
Derived true

Allocations of engineer’s capacity to work on this engineered element issues for a particular endeavor and issue category.

Type Allocation
Cardinality 0..*
Changeable true
Derived false

Experts have expertise with the element, but no authority. E.g. they can help others with using the element, but cannot make changes in the element without owners’ approval.

Type Engineer
Cardinality 0..*
Changeable true
Derived false
Opposite expertise

Issues (work items) for this element.

Type Issue
Cardinality 0..*
Changeable true
Derived false
Key path

Element owners have both expertise and authority over the element.

Type Engineer
Cardinality 0..*
Changeable true
Derived false
Opposite owns

Principles associated with this element to support decision making.

Type Principle
Cardinality 0..*
Changeable true
Derived false
Key path