A flat-out specification list is not economical. This is because in reality the features actually requested are not all-or-nothing. Some are necessary and some are "nice to have".  But because a specification usually makes no distinction, one will pay for features even if they are expensive to implement (and also skip features that may otherwise be cheap).

A more economical approach would use give-and-take, using a formula similar to:

   rank = need / cost

This would reduce the probability of implementing expensive features that are not really needed or have cheaper alternatives.

However, this also complicates the negotiation process. An all-or-nothing fixed-bid list is much easier to administer and compare across vendors/contractors. 

Further, each vendor/contractor's different approach may produce different ranks. Different techniques make different things easy or hard.

A systematic way to apply this formula to get the best fit for each party has yet to be established.

-top

Unfortunately, such an approach does not account well for FeatureInteraction. Both the cost of a feature AND the need for a feature can change based on the features already involved. Supposing you had the following set of specifications, it would be extremely difficult to attach a cost to each one without knowing ''which'' other features are to also be met:

  can traverse stairs
  can maneuver inside a building and through doors
  can operate at under 40 dB for normal movements
  desired: automatic cartography (can reproduce model of areas traversed)
  required: can follow a human through a forest, around brush, up hills in rough terrain
  required: can obey commands to stand still or to continue following
  movement rate > 8 MPH (desired 15 MPH) 
  load bearing capacity: at least 300 lbs
  payload power support: 12V DC 3Amp required for duration of missions (desired 5Amp).
  range between fueling: > 60 miles under 300 lb load (desired 100 miles)
  cost for repairs and refuel: < $20000/year of operation
  cost per unit: <$100,000 after 10 years assuming 1000 units per year
  mean time between failure: > 10 days (desired > 2 weeks)
  mean time to repair: < 2 days
  not required to be capable of field repair (but may want in future spiral)
  ...
  operational vibration limitations (frequency, amplitude)
  operational temperature limitations (min, max)
  weather: handling in rain, fog, wind, sand, sea spray, etc.
  and so on

FeatureInteraction can make nearly impossible the assignment of 'costs' to features as though they were optional and independent of one another. That you happen to be discussing software instead of hardware doesn't much diminish the impact of FeatureInteraction.

Given 10 binary features, one could presumably rank each of 1024 feature-sets for 'anticipated cost' vs. 'anticipated need'... supposing one can effectively predict the feature interactions. Usually such predictions would be made by examining what work has already been done on the subject... which requires that the effort break less new ground.

--------------

I have been forced to study and learn basic DOD Acquisition. I can say for certain that the DOD approach to negotiations and specifications has criterion to vary based on what sort of 'research' is involved in a contract.  And custom software, unlike purchasing nuts and bolts and COTS products, is very 'researchy'. As a consequence, the acquisition of custom software is much more interactive. And instead of "hard specifications" there is usually a pair of feature sets: a set of required features, and a (strictly larger) set of desired features, with both sets updated periodically in accordance with a SpiralModel.  Meeting required features is necessary to continue receiving funding. Meeting desired features is useful to compete against other projects.  Incumbent tools of any sort (including software) has a considerable advantage due to the cost of retraining (MindOverhaulEconomics), but there are always competing projects (with the 'default' seeming to be that programs would rather 'do it themselves' even if it is much more expensive).

Anyhow, I'd say that a "flat out specifications list" can be quite economic '''under the condition''' that you already have mechanisms that achieve these specifications. That is, if you are putting a contract out to ''replace'' existing software/forms/tools/procedures/etc., then it is clear what can be done and more likely that you won't feel these capabilities are merely "nice to have" - the incumbent advantage really does require meeting these capabilities (which may already be trimming unused features from the incumbent) before you can replace it.