No Value can be determined without knowing something about the cost to produce that Value and the Time that Value will be arriving. †
In the presence of uncertainty, this knowing must be estimated to some acceptable level of confidence.
Value Theory Strategies deal with the value that a system provides to the stakeholders of the system.
System value is derived from the von Neumann-Morgenstern (vN-M) utility function. Von Neumann-Morgenstern utility functions were the starting point for the development of game theory, and are now the basis for ongoing research called value theory.
vN-M utility functions are based on the idea that to make rational decisions from human preferences, using a mathematical representation based on a single axis of scalar numbers. For example, money measured in dollars or some other comparable scale is a common way of using a single scale of value across a variety of preferences.
Von Neumann and Morgenstern showed if a value can be measured with a scalar metric (and a confidence interval), then mathematical operations can be performed and be used as the basis for a rational decision. This is a strict interpretation of what rational means, fitting the needs of mathematics and economics.
In our Software Intensive System of Systems project management domain, applying this approach to engineering is the means of rigorously specifying the purpose(s) of a system, and then assessing design alternative of the system (Analysis of Alternatives) against those purposes. The creation and selection of an optimal design among all possible design options is the outcome.
When it is not possible to construct vN-M utility, other goals, constraints, or uses of the system can be used to define system goals and preferences and the resulting Value
For systems, whose purposes can be clearly stated monetarily in terms of making profits, the application of vN-M utility is straightforward.
For any system in which profit is not the primary purpose, then some other scalar metric and its confidence interval can be selected and used as the measure of value for that system.
Specification of requirements should be delayed if practicable during system design and development, in favor of mathematical representation of preferences.
This concept is derived from the Principle where requirements are progressively defined as the design matures. Specifying requirements too early leads to unnecessary constraints on the system design and can lead to the failure or violation of system constraints during development.
† "Engineering Elegant Systems: Theory of Systems Engineering," 4th Draft, 9 February 2018 in Systems Engineering Postulates, Principles, Hypotheses
