Some people have pointed out that the reason I don’t like agile methods is because I am trying to sell services which depend on “traditional” requirements. The reason I like “traditional” requirements is because I don’t like screwed up projects. Everyone is trying to sell something and the Agile gurus are no different. The problem is that Agile methods and “traditional” requirements gathering are not necessarily clearly defined and both sides use a lot of straw men to prove their points. In addition, I feel that agile methods with their focus on waiting until the last minute to make decisions will doom many projects to failure. We have run into a number of companies with large IT organizations that tried Extreme Programming only to abandon it after a multitude of spectacular project failures.

Agilemodeling.com (https://www.agilemodeling.com/essays/agileRequirements.htm) has a pretty well written set of techniques for requirements gathering that I really like, however the author starts out by stating

Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains. The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it, the requirements change anyway, and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant). Agilists know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information. They also know that any investment in detailed documentation early in the project will be wasted when the requirements inevitably change. Agilists choose to not waste time early in the project writing detailed requirements documents because they know that this is a very poor way to work.

I disagree pretty strongly with the comments.

Many traditional project teams run into trouble when they try to define all of the requirements up front, often the result of a misguided idea that developers will actually read and follow what the requirements document contains.

I simply don’t think it is misguided to ask developers to understand what needs to be built and to build it to a specification. The developers we work with are professionals. They take part in the requirements definition and absolutely develop what is agreed upon.

The reality is that the requirements document is usually insufficient, regardless of how much effort goes into it,

A requirements document can never completely specify a system. However for the highest risk areas, getting all parties to agree on the way the system should work is crucial. The easiest way to ensure that all items are reviewed is by using a list in the form of requirements. If you have a small project maybe you don’t need this, but for the projects we work on with many stakeholders it is absolutely critical.

the requirements change anyway,

We have found that true requirements don’t change often at all, in the same way that true business needs don’t change that often. If you find that your requirements are changing a lot, then you probably did not define the right requirements originally or maybe you incorporated too much design.

and the developers eventually end up going directly to their stakeholders for information anyway (or they simply guess what their stakeholders meant).

When the stakeholder/user population is large, I think we would all agree that this method does not work. It can take a significant amount of time to distill what actually needs to be done on large projects. Most developers lack the facilitation skills to drive these conversations.

Agilists know that if they have the ability to elicit detailed requirements up front then they can also do the same when they actually need the information.

This comment simply doesn’t make sense. The key question is when do you actually need the information? Well if you have multiple business stakeholders who have to come to agreement on how something should work, you would want the information as early as possible because you simply don’t know how long it may take to get agreement. Simply put, why wouldn’t you plan up front?

This wait until the last minute philosophy of Agile fits right into the personality of many developers. It is the same philosophy that drives most people to procrastinate. Planning is hard work, but there is no doubt in my mind that using detailed planning is the right method to run a software project.