A ‘Budget’ Parameter is used to specify a primary Scalar Resource-Target.
The implication of a Budget Parameter-Specification is that there is, or will probably be, a commitment to stay within the Budget-Level (something which is not true of a Stretch or Wish Resource-Target specification).
Scale: Total annual Maintenance Engineering Hours per thousand lines of software code supported.
Budget [First Four Years Average] 10 hours.
Stretch [First Four Years Average] 8 hours.
Wish [First Four Years Average] 2 hours.
Tolerable [Any Single Operational Year] 100 hours <- Client payment limit in contract §6.7.
1. A Budget Level is often arrived at through a formal Budgeting Process: the Budget Levels usually being set with regard to priorities, and available financial Resources. Sometimes a Budget Level is determined by Cost estimation, or it is determined by using competitive bidding and contracting. In some cases, the Budget is absolutely fixed in advance, and we have to try to keep within it by making Requirement tradeoffs or by using 'Design-To-Cost'.
2. At the very least a warning signal should be noted when a Budgeted Level is exceeded by a design, by an Evolutionary step, or when there is a Risk or Threat that the Budget might be exceeded. For example, we need to react if a Resource Threat to the Budget Level is discovered while evaluating potential Alternative-Designs.
> “A single arrowhead pointing towards the future. The same icon as for Goal *109.” In context: --->--->O Always use an input arrow to a function oval to represent a Resource attribute. The Budget icon is the ‘>’ on the arrow. If other Levels for the Resource are shown on the same arrow, the positioning of the tips of the icon symbols reflects the Levels relative to each other.