What the agile community doesn't do with requirements

I posted this in a response to a message on the Requirements Engineering mailing list 081012. It has been mildly edited for the blog.

Here are a couple of examples of things that the Agile community tends to ignore (or perhaps does not realise) about requirements:

• Use cases (or user stories) are not requirements. Each can lead to many requirements, many of which are shared by other use cases.
• Users often don't know what they want
• What users want is often not what they need
• What users say they want is often not what they really want
• Users aren't the only stakeholders (nor are customers, the only other group commonly mentioned, nor is the combination of users and customers)
• It is important to record the requirements, why they are there and where they came from. Joe at the next desk who wrote the code based on a user story may be working for a competitor in six months (as could the customer whose user story it was). Then you can't use the "wisdom of the team".
  

There is a lot of good in the agile approach, but we must not forget that it came from the coding and design community, who tend to assume that requirements are things done by other people, if they get done at all. Therefore, not unnaturally, it is light on requirements thinking.