Risk: too much or too little requirements definition

[smattingly]

#9 Issue by smattingly,

At one extreme, a pure waterfall process expects to fully define all requirements before pursuing other activities. IEEE and other standards provide guidance and outlines for Software Requirements Specification documents.

Government agencies and government contractor organizations frequently assume this approach by default. However, Boehm has identified six assumptions (p. 8) underlying the waterfall process.

For projects that conform to these assumptions, failure to use the waterfall process increases project risk. However, most projects do not conform to these assumptions. In these cases, it increases project risk to specify a complete set of requirements before exploring other activities, especially risk resolution.

The other extreme for requirements definition would be the "Code and Test" process, as described by the old joke: "you guys start coding, and I'll go find out what they want."

A more realistic approach to requirements definition might be user stories or use cases.

[JereomyAyres]

Reviewed 9/5/18

[JereomyAyres]

After discussion of needing to reevaluate technical details to implement.

[JereomyAyres]

Reviewed 10/10/18