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.

[abed12345]

the system must be able to keep time and track github comments and then relay that data to a database.

[smattingly]

I think you should include a link to the README in the code repo, where I laid out some requirement/design for the system. The main potential risk that I see here is tied in with possible conflicts between stakeholder win conditions.

[abed12345]

https://github.com/dewv/github-pomodoro/blob/master/README.md

[JStanley19]

same

[JStanley19]

reviewed

[JStanley19]

reviewed, but possibly could be moved to high risk.

[JStanley19]

reviewed

[JStanley19]

reviewed