Technology companies are moving toward Agile development. This is driven by the need to
improve productivity, boost product quality, and make delivery against business goals more
predictable. Product management is a crucial part of the move to Agile, calling for new skills and
new kinds of deliverables. Many product management organizations, however, do not have
experience with Agile deliverables, processes or communications styles.

This white paper briefly reviews Agile development, then identifies six levels of product
management and how Agile changes those levels. Roles, processes and deliverables are
increasingly divergent from waterfall models as we move from long-term strategy toward sprintlevel
and daily activities. We will use an outside-to-inside approach to examine Agile Product
Management responsibilities for:

1. Portfolio Management
2. Roadmaps and Release Plans
3. Requirements Management and Communication
4. Customer Input and Collaboration
5. Agile Product Teams
6. Communicating Information Up, Across and Out

Here is a blog post that "suggests a minimal way to gather requirements, one that produces a (minimum) requirements document in an iterative and agile manner.

Nick Malik blogs for the Inside Architecture blog on MSDN.

From Scott Ambler -

"Many organizations have an IT role called analyst, and will often differentiate between various types:

• Requirements analysts who are responsible for requirements elicitation
• Systems analysts who are responsible for analyzing the requirements to determine the system needs to fulfill those requirements
• Business analysts who are responsible for understanding the business and making recommendations for improvement
• Business system analysts whose responsibilities are a combination of those of a requirements analyst, business analyst, and a system analyst.

The focus of this discussion is on business system analysts (BSAs) even though many of the issues (or flavors thereof) are pertinent to the other analyst types.  BSAs typically have experience in a wide range of techniques, including interviewing, structured meeting approaches such as Joint Application Development (JAD), modeling sessions, and model reviews.  Good BSAs have a good understanding of the business domain and are typically “people persons”.  This article covers:

1. Why Have BSAs?
2. The Traditional Activities of an Analyst
3. Business Analysts Gone Awry
4. Towards Agile Analysts
5. BSA as Product Owner?"

Here is an article from agile expert Scott Ambler:

"This article presents a coherent strategy for bringing usability practices into agile project, summarizing Chapter 4 of Maturing Usability: Quality in Software, Interaction, and Value.  User experience (UEX) and agile practitioners need to learn about and respect each other?s philosophies and techniques, and then actively find ways to work together.  This requires both communities to make minor changes to the way that they work, but if they choose to make these changes I suspect that their work products will be much better for it."

And here's a glimpse at the conclusion:

"If the agile and UEX communities are going to work together effectively, they need to find a middle ground.  I believe that middle ground exists, but that both communities need to adopt several changes in order to succeed.  First, agile professionals must:

• Learn UEX skills.  Developers should be trained in, and adopt into their practices, UEX techniques.  This will enable developers to work more collaboratively and effectively with UEX practitioners.
• Accept that usability is a critical quality factor.  Luckily, agile practitioners are ?quality infected? ? they understand the importance of doing high-quality work and have a proven track record of adopting techniques such as test-first programming, code refactoring, and database refactoring.  Good usability of an end product can be ensured only by systematic usability engineering activities during the development iterations. 
• Adopt UI and usage style guidelines.  Developers must understand that not only should their code follow common guidelines, so should their UIs." 

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.