Loading...
 

definition-Constraint

Definition:

A Constraint is a Requirement that explicitly and intentionally tries to directly restrict any System or Process.

Alternative Names

Concept Number: *218
English Master: Condition
Synonyms, Variations & Acronyms: none

Detailing

A key property of a Constraint is that a penalty or loss of some kind applies if the Constraint is not respected.

Constraints include limitations on the Engineering Process, a System's operation, or its lifecycle.

A Constraint is "something that restricts" -The American Heritage Dictionary (Dell).


Illustrations


Illustration: noneXXXXXill


Type

Requirement Class, Parameter.


Examples

C1: Constraint: A Design-Idea must not be made of material, components or products only produced outside the European Market, if there is any EU material which can be used.
C2: Constraint: The design must contain ideas based on our own patents whenever possible.
C3:
Type: Constraint.
Defined As: All Stakeholder critical Product-Values must be planned and delivered so that they are viewed as obviously and significantly better than any competitor in the same price range.

An example of a Global-Constraint:
Availability Criteria: Constraint: No Company Product shall ever be designed with less than 99.5% availability.
A corresponding local Constraint setting a higher Constraint Level:
Tolerable [US Market, Military Systems]: 99.98%.


Notes

Notes:
1. There are two kinds of Constraints: Binary and Scalar.
Binary Constraints are statements that tend to include the words “must” or “must not”: that is, they tend to make demands about what is mandatory for the System or what is prohibited for the System. Binary Constraints are declared either by using a Constraint Parameter or by specifying “Type: Constraint.”
Examples:

C1: Constraint: A Design-Idea must not be made of material, components or products only produced outside the European Market, if there is any EU material which can be used.
C2: Constraint: The design must contain ideas based on our own patents whenever possible.
C3:
Type: Constraint.
Defined As: All Stakeholder critical Product-Values must be planned and delivered so that they are viewed as obviously and significantly better than any competitor in the same price range.

From an Attribute viewpoint, Binary Constraints are Function-Constraints, Design-Constraints or Condition-Constraints.
Scalar-Constraints are specified for performance or Resource Attributes. They are specified using Tolerable and Survival Parameters, which set the Constraint Levels on a Quantification-Scale.

2. All Engineering specifications (Requirements and design) and management plans, once stated, potentially and probably have some constraining influence on the rest of the Planning or Engineering Process. So all specifications and plans are “Constraints” in this sense.
However, we can clearly distinguish between specifications where the primary intent is to constrain (like a mandatory Constraint or a Level for Survival), and those specifications where the primary Idea is not to constrain, but to motivate positively (for example, a Binary Function-Target or, a Scalar Performance- Target, such as a Goal or Stretch Level). We could classify the former as “intentional and Direct-Constraints” and the latter as “unintentional and InDirect-Constraints”.
So, we only classify specifications and Concepts as “Constraints” when the clear intent and primary purpose is to restrain, limit, restrict constrain, or stop.

3. You have to look at Constraints from a “Stakeholder” viewpoint. As with any Requirement or design, what is a Requirement for one Level of System Stakeholder, is a Constraint as viewed by sub-ordinate Stakeholder Levels.

One Stakeholder”s Requirement is another Stakeholder”s Constraint.

4. All Constraints are valid for their associated defined Conditions. Sometimes the Constraint Conditions are stated explicitly, sometimes they are implied or inherited from more global specifications.
A “global” Constraint is usually imposed by higher Levels of Authority, or by earlier Planning Processes. For example: by company Policy, law, contract, strategic Planning or Systems-Architecture.
Examples:
An example of a Global-Constraint:
Availability Criteria: Constraint: No Company Product shall ever be designed with less than 99.5% availability.
A corresponding local Constraint setting a higher Constraint Level:
Tolerable [US Market, Military Systems]: 99.98%.

5. Constraints can be classified by the “relative Level of organization” they apply to, as proposed by Ralph Keeney [KEENEY92]:
• Fundamental-Constraints: handed down to us from higher Authority
• Strategic-Constraints: ones we have imposed at our own Level, over which we have control
• Means-Constraints: Constraints imposed at Levels supporting us, which we can therefore overRule.

6. All Requirements, including all Constraints, have different “priority”. This Priority (or “power”) is determined by the Conditions (the qualifiers) and by their related specifications (for example, by Parameters like “Authority”). It is a Complex Process to determine Constraint Priority, and the “answer” is dynamically Changing. There is probably no absolute Constraint that must be respected “no matter what”. That is, there might always be a higher Priority consideration that overrides a given Constraint. For example, “Thou shalt not kill (except in self-defense)”.

7. Constraints always represent, in some way, some of the values of some Stakeholders. But a given Constraint does not necessarily agree with the values of all Stakeholders. The Constraint of one Stakeholder might be in direct conflict with the Requirements of another Stakeholder.

8. Any set of categories (including no categories!) can be specified for classifying Constraints. System, performance, Budget and design are an arbitrary few such categories.

9. I view Constraints as borders around a problem. We can do anything we like within the borders, but we must not wander outside them.

Figure *218: Constraints impose restrictions on both other Requirements and designs. But the remaining space (“OK”) gives considerable freedom to set more-exact Requirements and to specify more-exact designs.

10. A Requirement is a “Constraint on succeeding Engineering Processes” in fact, if and only if it has an Authority, or another form of Priority, which in fact Means that:
• you must stay within its guidelines (when making later decisions or specifications)
• you cannot change it yourself (in order to avoid obeying it), without Authority to do so.

11. On the dynamics of Constraints (Dec 2007)
1. there is always a relevant and perhaps critical set of Constraints, for any endeavor (project, organization, Process)
2. the applicable set of Constraints will change
3. the recognized set will change
4. our priorities that determine which Constraints are applicable may change
5. the Priority of a particular Constraint may cause that Constraint to be ignored (given lower Priority than another Requirement).


Keyed-Icons

none


Drawn-Icons

to Add


Requirement *026
Function-Constraint *469
• Performance-Constraint *438
Resource-Constraint *478 • Design-Constraint *181
Condition-Constraint *498 • Survival *440
• Fail *098


History-of-Concept

none









This Concept entered by Jon Bundy.

Created by system. Last Modification: Tuesday 13 of November, 2018 23:29:42 CET by Admin (Kai).