F03xx02
333Figure 3-2
334
Activities will overlap to some degree on most projects, even those that are highly 335
sequential. 336
Another alternative is to specify only the most important 20 percent of the re-
337
quirements up front and plan to develop the rest of the software in small incre-
338
ments, specifying additional requirements and designs as you go.
339
Error! Objects cannot be created from editing field codes.
340F03xx03
341Figure 3-3
342
On other projects, activities will overlap for the duration of the project. One key to 343
successful construction is understanding the degree to which prerequisites have been 344
completed and adjusting your approach accordingly. 345
The extent to which prerequisites need to be satisfied up front will vary with the
346
project type indicated in Table 3-2, project formality, technical environment,
347
staff capabilities, and project business goals. You might choose a more sequen-
348
tial (up-front) approach when:
349
● The requirements are fairly stable
350
● The design is straightforward and fairly well understood
351
● The development team is familiar with the applications area
352
● The project contains little risk
353
● Long-term predictability is important
354
● The cost of changing requirements, design, and code downstream is likely to
355
be high
356
You might choose a more iterative (as-you-go) approach when:
357
● The requirements are not well understood or you expect them to be unstable
358
for other reasons
359
● The design is complex, challenging, or both
360
● The development team is unfamiliar with the applications area
361
● The project contains a lot of risk
362
● Long-term predictability is not important
363
● The cost of changing requirements, design, and code downstream is likely to
364
be low
365
You can adapt the prerequisites to your specific project by making them more or
366
less formal and more or less complete, as you see fit. For a detailed discussion of
367
different approaches to large and small projects (also known as the different ap-
368
proaches to formal and informal projects), see Chapter 27, “How Program Size
369
Affects Construction.”
370
The net impact on construction prerequisites is that you should first determine
371
what construction prerequisites are well-suited to your project. Some projects
372
spend too little time on prerequisites, which exposes construction to an unneces-
373
sarily high rate of destabilizing changes and prevents the project from making
374
consistent progress. Some project do too much up front; they doggedly adhere to
375
requirements and plans that have been invalidated by downstream discoveries,
376
and that can also impede progress during construction.
377
Now that you’ve studied Table 3-2 and determined what prerequisites are appro-
378
priate for your project, the rest of this chapter describes how to determine
379
CROSS-REFERENCE For
details on how to adapt your development approach for programs of different sizes, see Chapter 27, “How Pro- gram Size Affects Construc- tion.”
whether each specific construction prerequisite has been “prereq’d” or “pre- 380 wrecked.” 381
3.3 Problem-Definition Prerequisite
382The first prerequisite you need to fulfill before beginning construction is a clear
383
statement of the problem that the system is supposed to solve. This is sometimes
384
called “product vision,” “mission statement,” and “product definition.” Here it’s
385
called “problem definition.” Since this book is about construction, this section
386
doesn’t tell you how to write a problem definition; it tells you how to recognize
387
whether one has been written at all and whether the one that’s written will form a
388
good foundation for construction.
389
A problem definition defines what the problem is without any reference to possi-
390
ble solutions. It’s a simple statement, maybe one or two pages, and it should
391
sound like a problem. The statement “We can’t keep up with orders for the Giga-
392
tron” sounds like a problem and is a good problem definition. The statement
393
“We need to optimize our automated data-entry system to keep up with orders
394
for the Gigatron” is a poor problem definition. It doesn’t sound like a problem; it
395
sounds like a solution.
396
Problem definition comes before detailed requirements work, which is a more in-
397
depth investigation of the problem.
398 Problem Definition Requirements Architecture Construction System testing Future Improvements 399
F03xx02
400 Figure 3-2 401The problem definition lays the foundation for the rest of the programming process. 402
If the ‘box’ is the bound- ary of constraints and conditions, then the trick is to find the box.... Don’t think outside the box— find the box.”
—Andy Hunt and Dave Thomas
The problem definition should be in user language, and the problem should be
403
described from a user’s point of view. It usually should not be stated in technical
404
computer terms. The best solution might not be a computer program. Suppose
405
you need a report that shows your annual profit. You already have computerized
406
reports that show quarterly profits. If you’re locked into the programmer mind-
407
set, you’ll reason that adding an annual report to a system that already does quar-
408
terly reports should be easy. Then you’ll pay a programmer to write and debug a
409
time-consuming program that calculates annual profits. If you’re not locked into
410
the computer mind-set, you’ll pay your secretary to create the annual figures by
411
taking one minute to add up the quarterly figures on a pocket calculator.
412
The exception to this rule applies when the problem is with the computer: com-
413
pile times are too slow or the programming tools are buggy. Then it’s appropri-
414
ate to state the problem in computer or programmer terms.
415 416
F03xx03
417 Figure 3-3 418Without a good problem definition, you might put effort into solving the wrong prob- 419
lem. Be sure you know what you’re aiming at before you shoot. 420
The penalty for failing to define the problem is that you can waste a lot of time
421
solving the wrong problem. This is a double-barreled penalty because you also
422
don’t solve the right problem.
423
3.4 Requirements Prerequisite
424
Requirements describe in detail what a software system is supposed to do, and
425
they are the first step toward a solution. The requirements activity is also known
426
as “requirements development,” “requirements analysis,” “analysis,” “‘require-
427
ments definition,” “software requirements,” “specification,” “functional spec,”
428
and “spec.”
429