What, Why, When, and How of Value Engineering?
What Is Value Engineering?
Up until this point we have had very little discussion of the costs of certain fea-
tures that customers may wish to include in the system requirements. Part of the
reason is that it made sense to separate that very complex issue from all of the other
problems surrounding requirements elicitation, analysis, representation, validation,
veriﬁcation, and so on. Another reason for avoiding the issue is that it is a tricky
ere is a fundamental relationship between time, cost, and functionality.
Project managers sometimes refer to this triad as the three legs of the project man-
agement stool. at is, you can’t tip one without aﬀecting the others. For example,
you have already ﬁnished writing and agreeing the speciﬁcation and have provided
an estimated cost to complete in response to some RFP (request for proposal). If
the customer asks you to incorporate more features into the system, shouldn’t the
price and estimated time to complete increase? If not, then you were likely padding
the original proposal, and the customer will not like that. Conversely, if you pro-
pose to build an agreed-upon system for a price, say $1 million, and the customer
balks, should you then respond by giving her a lower price, say $800,000? Of course
not, because if you lower the price without reducing the feature set or increasing
190 Requirements Engineering for Software and Systems
the time to complete, the customer will think that you gave her an inﬂated price
originally. e correct response, in this case, would be to agree to build the system
for $800,000, but with fewer features (or taking much longer time).
To properly manage customer expectations, deal with tradeoﬀs between func-
tionality, time, and cost, it is therefore necessary to have some way of estimating
costs for system features. Making such estimations is not easy to do accurately at
the early stages of a project, such as during the requirements engineering activities.
However, it is necessary to make such cost eﬀort and estimations. e activities
related to managing expectations and estimating and managing costs are called
When Does Value Engineering Occur?
Value engineering occurs throughout the system lifecycle and is typically consid-
ered a project management activity. But for the requirements engineer value engi-
neering has to take place to help manage customer expectations concerning the
ﬁnal costs of the delivered system and the feasibility or infeasibility of delivering
During the early stages of elicitation, it is probably worthwhile to entertain
some value engineering activities—but not too much. For example, you may wish
to temper a customer’s expectations about the possibility of delivering an elaborate
feature if it will break the budget. On the other hand, if you are too harsh in pro-
viding cost assessments early, you can curtail the customer’s creativity and frustrate
them. erefore, be cautious when conducting value engineering when working
with user-level requirements.
e best time to conduct the cost analysis is at the time when the systems-level
requirements are being put together. It is at this time that better cost estimates are avail-
able, and this is a time at which tradeoﬀ decisions can be discussed more successfully
with the customer, using some of the negotiating principles previously mentioned.
In the following sections, we’ll look at some simple approaches to assist in the
value engineering activity for requirements engineers. ese sections provide only
an introduction to these very complex activities that marry project management,
cost accounting, and system engineering. Really, a set of experts with these skills is
needed to provide the most accurate information for decision making.
Estimating Using COCOMO and Its Derivatives*
One of the most widely used software cost and eﬀort estimation tools is Boehm’s
COCOMO model, ﬁrst introduced in 1981. COCOMO is an acronym for con-
is section is adapted from Phillip A. Laplante, Software Engineering for Image Processing
Systems, CRC Press, September 2003, with permission.