"Getting the Requirements Right Up Front"

Brian Marick posted this to the Agile-Testing Yahoo Group Today. I thought it was interesting ...


1. It's the job of the team to be able to respond well to requirements they didn't anticipate. That will allow the business to adapt more quickly to a business environment that won't stand still.

2. Something like 50 years of trying has demonstrated that mere mortals are not very good at designing a system that can accept unanticipated requirements.

3. The alternative that seems to work - the alternative the Agile methods take - is that both the team and the code have to be trained, over time, to accept the unexpected with aplomb.

4. The way you get trained is through practice. Therefore, taking a lot of time to get the requirements right is actually a disservice to the project - it will make them less effective when it really matters.

5. For this reason, a lot of teams make a point of not anticipating the requirements they know are coming. By treating them as unexpected, they speed up their own training.

You can read the entire post here.