Agile methods are designed to cope with changing or vague requirements, and posit that big design up-front (BDUF) is wasteful, as the shifting requirements will make the design obsolete. Too often though, analysis and requirements gathering are lumped together with BDUF and the baby gets thrown out with the bathwater.

Certain requirements can be captured early, and indeed, should be captured as early as possible. Ironically, these are often the requirements that receive the least attention – the so-called non-functional requirements. These include such things as low maintenance, responsiveness, reliability, ease of upgrade etc. Sometimes the non-functional requirements can turn out to be the most important ones. For example, if a project is designed to replace an existing system that is always breaking, then the most important requirement from the point of view of the CTO / key sponsor may be that it is easy and cheap to maintain. Problem is, sometimes the non-functional requirements are so obvious to the customer that they forget to tell the delivery team. This is what requirements analysis aims to address.

Finally, on the subject of changing requirements, how many projects really start out as stock trading applications and turn into an air traffic control system?

Its all about differentiating the real requirements from the (to the business) incidental details.