SOFTWARE MANAGEMENT

tial demo or prototype. But their needs

Requirements and desires change once they begin oper-

ating the system and gain a deeper under-
standing of how it could support their
mission. Thus, the requirements tend to

that Handle emerge with continued use and mission

understanding rather than be prespecifi-
able.

IKIWISI, COTS, COTS

Another fundamental tenet of the air-
tight-requirements approach is that the
prespecified requirements completely

and Rapid Change determine the system capabilities. How-

ever, with large, pervasive COTS prod-
ucts, the COTS capabilities effectively
determine the requirements.
Barry Boehm, University of Southern California For example, suppose you specify a
one-second response-time requirement

I
for a large transaction-processing system,
n the good old days, dealing with promised. As the project proceeded, a and the best available COTS database
software requirements was relatively requirement would occasionally need management system can only handle your
easy. Software requirements were changing, but some relatively straight- workload with two-second response
the first order of business and took forward change control procedures could time. Are you going to build your own
place before design, cost estimation, usually handle that. version of Oracle or Sybase and hope you
planning, or programming. Of course, it
wasn’t simple. Certain straightforward
criteria required satisfaction:
Requirements help you deal with
• completeness (no missing elements “I’ll know it when I see it” users,
and each element fully described);
• consistency (no mismatches among off-the-shelf components, and
the elements);
• traceability (back to the require-
rapid change.
ments for the system); and
• testability (specific enough to serve
as the basis for a pass/fail test for the SOME COMPLICATING FACTORS: can make it twice as fast? Hopefully, in
end product). IKIWISI, COTS, AND RAPID CHANGE this and similar situations, you’ll recog-
The recent developments of IKIWISI nize that it’s not a requirement if you can’t
And, while avoiding design decisions (I’ll know it when I see it), COTS (com- afford it. Let the best available COTS
about how all of this should be accom- mercial-off-the-shelf) software, and the capabilities determine your response time
plished, you had to ensure that the increasingly rapid change in information or other requirements—the reverse of the
requirements detailed the software’s technology have combined to unsettle the airtight-requirements approach.
capabilities and any quality levels it must foundations of the old airtight-require-
satisfy. ments approach. Rapid change
Completing these tasks might take As I discussed, specifying airtight re-
time, but it was the only way you could IKIWISI quirements takes time. But particularly for
guarantee that the delivered software Successfully specifying software require- Internet and Web-based systems, rapid
conformed to original specifications. ments in advance is difficult. But when change can create an impossible-to-win
And, if you were contracting for software user- or group-interactive systems are game of catch-up. As you slowly grind out
development, it was the only airtight way involved, it proves nearly impossible. and validate airtight requirements, rapid
to ensure that competitive bidders were Users asked to specify requirements gen- changes in COTS releases, competitive
bidding to produce the same product. It erally claim, “I don’t know how to tell threats, stakeholders, reorganizations, and
was also the only basis for negotiating an you, but I’ll know it when I see it.” price structures make these requirements
airtight contract to ensure that the win- Furthermore, users may initially feel increasingly obsolete. And by the time you
ning bidder would deliver what he that they “know it” when they see an ini- thoroughly change-control, update, and

July 2000 99
 Software Management

revalidate them, new developments make identify how your new system will oper- tem’s stakeholders frequently need to
them obsolete all over again. ate and add value over your existing sys- reassess and revise the system and soft-
tem. It should also identify the success- ware requirements. This means that it is
THE REQUIREMENTS QUANDARY critical stakeholders involved in transi- more important to emerge from the ini-
Should you then forgo requirements tioning to the new system, and how the tial requirements definition process with
completely? No—that would be like a new system will add value for each stake- a shared vision of the system’s goals and
convoy trying to navigate a complex route holder. The operational scenarios are values than with a precisely defined
without a road map. With so many deci- also useful for performing the business- requirements spec. The shared vision
sion branches, independent project stake- case analysis; they provide specific situa- helps all the stakeholders quickly adapt
holders can easily head in wrong or tions around which to quantify costs and to the new situation, while the precise
incompatible directions. Customers and benefits. spec takes more effort to change and
users still need a description of the prod- some stakeholders may not understand
uct destination assuring them that what it. Beyond a shared vision, however,
developers produce will do what they stakeholders must emerge with a set of
need. This means that developers need Forgoing requirements shared commitments to realizing the
some guiding principles—rather than completely would be like vision and its shared values.
inflexible rules—to help each project trying to navigate a Too often, software requirements oper-
determine the best combination of re- complex route without ate under a field-of-dreams assumption:
quirements rigor and flexibility for each a road map. “Build the software to the requirements,
technical and organizational situation and and the benefits will come.” John Thorp
environment. This situation-dependence cites extensive evidence that there is little
implies an overarching primary principle: correlation between a company’s level of
Avoid one-size-fits-all approaches to A particularly important consideration information technology investments and
requirements. for new product introduction is the time- its profitability or market value (The
The most significant problem with the dependent value of the product sequence. Information Paradox, McGraw-Hill,
airtight-requirements approach was its Arriving first to market with only a par- New York, 1998). His book provides con-
attempt to be a one-size-fits-all solution. tial capability is often preferable to arriv- vincing evidence that the field-of-dreams
Although this tactic fails for IKIWISI, ing later with a complete set of re- approach is responsible for many of the
COTS, and rapid change situations, the quirements. In some cases, such as de- lost opportunities leading to the informa-
airtight-requirements approach proves monstrations at major trade shows, the tion paradox—the disconnect between IT
valuable in many situations. Some exam- value may decrease dramatically if it’s not spending and business benefit.
ples are software-intensive safety-critical available on time. In such cases, using a The Thorp book also provides the best
autonomous control systems for rela- schedule-as-independent-variable (SAIV) approach I’ve seen for avoiding this
tively stable products, such as heart pace- rather than a complete-requirements-as- problem: the DMR Benefits Realization
makers, automotive steering systems, and independent-variable process model is Approach, represented by the results
nuclear power plants. preferable. A SAIV approach involves pri- chain in Figure 1. It establishes a frame-
oritizing the requirements, defining a core work that links initiatives, which con-
SURMOUNTING THE capability that is easily deliverable on sume resources (for instance, imple-
REQUIREMENTS QUANDARY: time, and architecting the system so menting a new order entry system for
FOUR GUIDING PRINCIPLES that lower-priority requirements can be sales), to contributions (not just the
Here are four guiding principles that dropped if they threaten on-time delivery. delivered system, but rather its effect on
help tailor a requirements strategy to fit Note that a value-driven requirements existing operations) and outcomes.
your situation. These ensure that your approach implies concurrent develop- Outcomes can lead to further contribu-
requirements are value-, shared-vision-, ment of the requirements, the architec- tions or to added value (like increased
change-, and risk-driven. ture, and the development plans. For sales). A particularly important contri-
cost-benefit and return-on-investment bution of the results chain is the link to
Value-driven requirements analysis, the requirements determine the assumptions, which are conditions nec-
Determining your most important benefits, but the architecture and plans essary to the realization of outcomes. For
requirements requires a business-case determine the cost and schedule. example, in Figure 1, if order-to-delivery
analysis. This shows the value added from time is not an important buying criterion
various combinations of requirements rel- Shared-vision-driven requirements for customers, the reduced delivery time
ative to the investment necessary to Rapid changes in the problem situa- will not result in increased sales.
achieve them. Analyzing the business case tion (market competition), solution situ- This framework is also good for iden-
also forces you to focus on determining ation (new technology), and value tifying non-software stakeholder initia-
your system’s operational concept. situation (price structures or organiza- tives (for instance, training, public
This concept should use scenarios to tional realignments) imply that the sys- relations, and order fulfillment speed-

100 Computer
ups), which are also necessary conditions
to realizing benefits. It also provides a
way to track progress on all the neces- Order-to-delivery time
sary initiatives and their effects on con- is an important criterion Assumption

tributions and outcomes. Tracking

realized benefits permits businesses to Reduce time to Reduce time to
apply necessary corrective actions if ben- process order deliver product
efits don’t materialize (including changes
to the software requirements).
Contribution Contribution
Initiative Outcome Outcome
Change-driven requirements
Another major problem with current
software requirements practice and Implement a Reduced order Increased
guidelines is that they only capture a new order processing cycle sales
snapshot of the requirements from any entry system (intermediate
given moment. Particularly in competi- outcome)
tive bidding, such snapshot requirements
specs lead to point solution architectures:
The winning bidder can satisfy the stated Figure 1. Benefits Realization Approach results chain.
requirements at lowest cost, but the soft-
ware will be expensive to adapt to later module reuse failed to pass the prime con- the designs on either side of the interfaces
requirements changes. tract’s requirements definition because of are still getting sorted out, it’s best to
More than 20 years ago, David portability or maintainability weak- spawn one or more risk-driven spiral
Parnas’s paper, “Designing Software for nesses. cycles to suitably define the interfaces.
Ease of Extension and Contraction” Several techniques are emerging for On the other hand, it’s very risky to
(IEEE Trans. Software Eng., Mar. 1979, capturing such rationale and facilitating prespecify the exact layout of a GUI in
pp. 128-137), provided an elegant solu- adaptation to change. These include the stiff prose. There’s too much risk of an
tion to this problem. It involves identify- results chain described earlier, the stake- IKIWISI phenomenon making the specs
ing the most likely directions of change holder win-win negotiation results cap- rapidly obsolete. And, with a GUI-
in the requirements (for instance, new tured in the MBASE (Model-Based builder package, there’s little risk
workstations on which to operate), and System Architecting and Software involved in changing the layout as new
encapsulating these sources of change in Engineering) Feasibility Rationale, and insights emerge. Thus, in this case, it’s
the design via Parnas’s information- scenario-based rationale capture. better to agree to a prototype as the ini-
hiding techniques. For example, you tial GUI requirements definition, and to
could hide workstation details in a work- Risk-driven requirements agree to evolve the GUI within the tech-
station-handler module. Then, when the Once they’ve done value-, shared- nical capabilities of the GUI-builder
changes come, they only affect a single vision-, and change-driven requirements, package.
module rather than the entire software developers still face the question, “How
product. much requirements specification detail is
Although information hiding has enough?” As with similar questions everal organizations have success-
become a widely adopted design tech-
nique, it is surprising how rarely devel-
opers practice its counterpart: specifying
regarding planning, prototyping, testing,
and change control, the best answer I’ve
found is to take a risk-driven approach.
S fully developed approaches that
work well in coping with IKIWISI,
COTS, and rapid change. Some particu-
and using evolution requirements to This basically says, “If it’s risky to leave larly good examples are e-commerce solu-
achieve a change-driven design. Most of it out, put it in. If it’s risky to put it in, tion builders such as C-bridge and the
today’s standards for specifying require- leave it out.” IBM and Oracle e-commerce divisions.
ments still do not have a section on evo- Thus, for example, anything less than The DMR Group has successfully applied
lution requirements. thoroughly specifying interface require- its Benefits Realization Approach across
Another problem with current require- ments between the software and a spe- a wide variety of application areas, as has
ments and design specs is that they cap- cialized hardware device, or between the Rational Inc. with its Rational Unified
ture only the surviving decisions, and not software in two large, integrated systems, Process.
the rationale by which other alternatives is risky. If these interfaces are ambiguous In over 100 requirements definitions of
failed. This often leads to misguided or undefined, there will be major risks of Web-based rapid-development applica-
change adaptation. For example, a pro- interface mismatches causing either seri- tions for University of Southern Cali-
grammer or subcontractor may reuse a ous operational problems or massive fornia and Columbia University clients
module to save time, even though the rework and delays during integration. If using the MBASE approach, my col-

July 2000 101

 Software Management

leagues and I find that the value-, shared-vision-, change-, and

risk-driven approaches to system and software requirements
definition are mutually reinforcing. Using a stakeholder win- Sources and Resources
win requirements negotiation approach, business-case analy- For value-driven requirements, the best source is
sis, and a benefits-realization approach all help stakeholders Thorp’s The Information Paradox (McGraw-Hill, New
prioritize their requirements and capture the rationale for their York, 1998). Besides Parnas’ paper, the best source for
decisions. The lower-priority requirements become evolution change-driven requirements is James Highsmith’s
requirements, providing the basis for architecting the system to Adaptive Software Development (Dorset House, 2000).
easily drop them (if necessary to meet schedule) or incorporate For shared-vision-driven requirements, Donald Gause and
them in later increments. And the risk analyses developed for the Gerald Weinberg’s Exploring Requirements: Quality
risk-driven spiral process help determine how much is enough Before Design (Dorset House, 1989) is excellent. Suzanne
for the requirements specs. Thus, there are good prospects for and James Robertson’s Mastering the Requirements
a mutually reinforcing set of requirements practices, providing Process (Addison Wesley, 1999) and Michael Jackson’s
a stronger sense of security than was previously achievable with Software Requirements and Specifications (Addison
airtight requirements. ✸ Wesley, 1995) both complement the Gause and Weinberg
book. For risk-driven requirements, the USC MBASE
Barry Boehm is director of the University of Southern Cali- approach (http://sunset.usc.edu/MBASE) has the most
fornia’s Center for Software Engineering. Contact him at specific coverage. Some good unified approaches of all
boehm@sunset.usc.edu. four principles are MBASE, Thorp’s Benefits Realization
Approach, and The Rational Unified Process (Phillippe
Editor: Barry Boehm, Computer Science Department, University of Kruchten, Addison Wesley, 1999).
Southern California, Los Angeles, CA 90089; boehm@sunset.usc.edu

Training You
Can Trust
From the IEEE Computer Society and five partner universities
Continuing education courses based on
software engineering standards.
Computer Society 2000 Authorized Training Centers
• California State University, Sacramento
• New Jersey Institute of Technology
• Oregon Graduate Institute
• Southern Polytechnic State University
• University of Strathclyde

Course descriptions and registration information are available

at computer.org/education/sestrain.htm

Software Engineering Standards-Based Training

Tr a i n i n g D o n e R i g h t

102 Computer