Loading...
 

definition-Resource-Saving-Requirement

Definition:

A Resource-Saving-Requirement is a “Resource reduction” Performance-Requirement. It specifies the specific savings in Resource utilization that are needed: “how much” is to be saved.

Alternative Names

Concept Number: *622
English Master: Resource Saving Requirement
Synonyms, Variations & Acronyms: Saving-Requirement

Detailing

The focus is that it is, the specific Level of saving that is the Requirement (as opposed to the improvement in Product-Value or Workload-Capacity being the driving motivation).


Illustrations

ResourceSavingRequirement.png


Type

Performance-Requirement


Examples

A Resource-Saving-Requirement is expressed as either:

• a performance Level (a target or Constraint Level) compared to a defined Benchmark Level for a Resource-related Concept

Example:
X:
Type: Resource-Saving-Requirement.
Scale: Minutes.
Past: 30, Goal: 20.

Or as
• a ratio defined in a direct “saving” Quantification-Scale.

Example:
Y:
Scale: Percentage Relative Cost Reduction comparing Old Cost to New Cost.
Goal: 20% reduction. “A 20% saving.”


Notes

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.

For example:
• “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.

Example:

Manufacturing Labour Cost Savings:
Type: Resource-Saving-Requirement.
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.


Keyed-Icons

See icons for Performance-Requirement *100, Performance-Target *439 or Performance-Constraint *438, as applicable.


Drawn-Icons

none


Resource-Saving
Performance-Requirement(Objective)
Resource


History-of-Concept

none









This Concept entered by Diane O'Brien.

Created by system. Last Modification: Thursday 11 of July, 2019 20:17:06 CEST by Admin (Kai).
(Cached)

Concept Search