When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.
Agile’s Biggest Strength is Agile’s Biggest Weakness
Agile works because it is designed to help teams adapt to changes in direction. Agile is designed to minimize the pain of changing requirements. Agile proponents believe the premise that requirements will change and no amount of upfront planning will impact that. They believe that the requirements simply do not exist until after something has been built. Agile processes save a lot of time by not doing big upfront requirements gathering or design work. They also don’t involve big up-front planning. They do small planning work. And they do it again and again, throughout the project. This works because they minimize wasted planning effort.
Joel Spolsky Speaks Specs
It seems that specs are like flossing: everybody knows they should be writing them, but nobody does.
Another for the wish I had said that list. Joel Sposky wrote a four part series on writing functional specifications in Oct 2000. Joel’s opening position is that all projects lasting more than a week, or with more than one developer, will be completed faster with specs than without them. He presents three giant reasons to use a requirements document as part of developing software
Three Giant Reasons
Challenging Requirements
The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.