You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 23, 2019. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
#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.
The text was updated successfully, but these errors were encountered: