Requirements Engineering for Software and Systems

189

10Chapter

Value Engineering

of Requirements

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,

verification, and so on. Another reason for avoiding the issue is that it is a tricky

one.

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 affecting the others. For example,

you have already finished writing and agreeing the specification 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 inflated 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 tradeoffs 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 effort and estimations. e activities

related to managing expectations and estimating and managing costs are called

value engineering.

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

final costs of the delivered system and the feasibility or infeasibility of delivering

certain features.

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 tradeoff 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 effort estimation tools is Boehm’s

COCOMO model, first 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.