1.2 Requirements

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 

In the last ten years or so, the absoluteness of requirements has been set aside.

This is particularly true in the software world. The reasons requirements have

softened are several. First, the demands of the marketplace have insisted that we

bring a product to market before our competition—the mantra of the 1980s

and 1990s was ‘‘greed and speed.’’ This has meant eliminating the front end of

many projects to try to get a jump on the competition. The pace of the marketplace

demanded so-called ‘‘rapid prototyping’’ to get there first. Second, eliminating

hard requirements allowed more latitude in developing new and different

products. Products that were, in some cases, not even envisioned at the

outset of the project evolved or appeared during the process. Finally, the culture

of ‘‘generation X’’ created a ‘‘Leave me alone and let me do my own thing’’

attitude. The results? Some miraculous strides in progress, particularly software,

and some colossal failures. The analysis? The less control, the greater the art,

but the greater the risk. We are now at a point where we are trying to figure out

how to lower the risk and still have the grand advances. I’m not sure we’ve

figured all that out quite yet, but that’s a big reason for this book. With all the

failures we’ve suffered, we need some ways to try to prevent the failures and to

recover when we do fail.

It appears a compromise is needed in the definition and how it is applied.

For those projects you consider artful or creative in nature, how about at least

establishing a charter at the outset to guide the project and establish some

boundaries. If the project begins to falter, use the concepts of this book to back

up and redefine those parts of the project that are going wrong. This will become

an iterative process. It won’t solve all the problems, but it will capture the

best of each process and allow maximum advances. Whenever you go back,

document the change, and update the charter to include your new findings. Tie

these elements together and voila`! You have a crude requirements document.

Now that you have more visibility, use the opportunity to try to extend to the

next failing and shortstop it as well. This thing we have established as the charter

now takes the place of the requirements document (contract), and you can read

the following cause descriptions with that in mind.