Identifies the assumptions most commonly made by business analysts.  Also provides high-level steps for how to avoid those assumptions

Peter Morville on information architecture and the user-experience honeycomb

I've been practicing information architecture since 1994, and from Gopher to Google have seen dramatic changes in the landscape of organization, search and retrieval.

Through these ten tempestuous years, I've found the infamous three circle diagram to be a great tool for explaining how and why we must strike a unique balance on each project between business goals and context, user needs and behavior, and the available mix of content.

 

Good explanation of how to create a decision tree as a visual artifact when gathering requirements

Article starts with good justification for why requirements should be managed.  Then presents the different types of requirements, and checklists of 'stuff to do' for functional and non-functional requirements.

Overview, explanations, and details from Scott Ambler.  This documentation approach can be used for agile and non-agile processes.  It can also be used for product management / development and for business analysis.

Pragmatic overview of agile, what makes it good, what makes it challenging.

Describing Scrum in eight steps - makes it very obvious what scrum is.

Lists and explains seven guiding precepts of good interface design.

Given a specific project with a reasonably defined charter and clear business goals you, the business analyst, set out to elicit and document the detailed business requirements. So when do you stop? How do you know when you are done gathering the requirements?

Have you tried the Popcorn Method?

Deep analysis of the tasks that must happen in an iteration - development, analysis, testing, etc.  Focus on the problems with staggering them too much, and suggestions on how to properly organize the team around those tasks.