Hacker News new | past | comments | ask | show | jobs | submit login

The point of gathering requirements is not to "know everything". It's often taken that way because people like to blame the requirements: "We didn't build that because no-one gave us a requirement". You can have three reactions to that;

1. accept the blame - beef up the requirements gathering process, attempt to gather ever more

2. reject the blame - move to an agile process where everything is learned on-the-hoof

3. reject the premise.

People tend to either land in 1) or 2) above, but I think 3) is the correct place. Gathering requirements is about figuring out how much we know, identifying what we don't know, and working the risks. On some projects the risk is that we don't know enough about what customers really need (= agile engagement required). On others, the risk is literally all about delivery.

Iterative development is great at addressing some risks. It doesn't address other risks at all; it's not well-suited in many instances where the information known up-front is substantial, or where it's difficult to engage users.

The key is to recognise what problems you need to manage, and choose a suitable methodology to do it.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact