A Resource-Saving-Requirement is expressed as either:
• a ratio defined in a direct “saving” Quantification-Scale.
1. The Scales used for Resource-Saving-Requirements must concern Resource utilization: that is, a Resource-Saving-Requirement is specified only if the target or Constraint is defined in terms of Resources (for example, as Maintenance Cost as opposed to Maintenance Effectiveness) needed.
2. A Resource-Saving-Requirement is about a desired recurrent event (a Resource-Saving) in the future, in connection with some current expenditure of Resource (Cost). For example:
• Cost to manufacture
• Cost to hire a new employee
• Cost to repair a System
• Cost to do a form of Service
3. A Resource-Saving-Requirement is not about saving Resources needed to do the current project, as expressed in the Resource Budgets for the project (---->>---->O). It is about developing a System capable of saving Resources when applied.
4. Performance-Requirements are not really absolutely different in their types (Product-Value, Resource-Savings, Workload-Capacity). And these are not the only possible types of classification, which might be interesting. There is no critical consequence of this classification. It is quite possible that some objectives are mixtures (Resource-Saving-Requirements and Product-Value-Requirements) and there is no harm in declaring that they are both. So, if the decision-making about exactly which Type an Attribute actually is, gets too difficult, don”t worry! Use your best feeling and even allow mixed classifications. Or, invent your own useful classifications for your particular domain.
• “Ease of Learning”, such as “Scale: Time to learn a defined Task”, a usability Concept, is a “Product-Value” value, not a Resource-Saving, even if the Product-Value Goals are better than the Benchmarks (in other words, an “improvement”).
• “Time needed to Train” is a Workload-Capacity Attribute of a System. But, if it is specified with a Resource Scale (space, time, money, data, effort, materials) and the Benchmark value is less than the target value; then we have specified a Resource-Saving-Requirement. We can make our intent clear by specifying Type: Resource-Saving-Requirement.
Manufacturing Labour Cost Savings:
Scale: Human Effort needed for each defined [Product] manufactured in hours taken for each Product.
Past [Old Product]: 300 hours/Product.
Goal [New Product]: 100 hours/Product.
Note: Implied savings is 200 hours/Product.
Impacted-By: Production Process Design.
Impacts: Product Cost -> Pricing -> Competitiveness.
Note the strong relationship between these two Concepts (Ease of Learning: Product-Value and Time Needed to Train: Workload-Capacity) does not mean they are identical! The ease of learning is a general potential in the System itself (a Product-Value). The time needed to train an employee is partly due to the ease of learning of the System itself, but is finally determined by other factors such as the individual learning ability, interruptions and motivation.
Rationale [Resource-Saving-Requirement *622]: Why establish this classification of “Resource-Saving-Requirement”? I developed this Concept (Resource-Saving-Requirement) as a separate category of Performance-Requirement to provide a chance to increase the Clarity of purpose.
With Resource-Saving-Requirements, the intent to save is the “main idea” behind the specification of the Requirement. It is not that a specific Level of performance has to be exhibited – it is that a certain Level of saving has to be achieved.
See icons for Performance-Requirement *100, Performance-Target *439 or Performance-Constraint *438, as applicable.
This Concept entered by Diane O'Brien.