The Business Analysts Handbook has been launched by myself and a handful of friends and colleagues. From it's homepage; "This is a wiki for busness analysts to post thir knowledge. It is designed to be an evolving repository of knowledge for and about business analysts, or BAs." This site can be viewed as a business analysts body of knowledge, although rather that a formal and rigidly version controlled document such as PMIs PMBOK (or the proposed BABOK) my hope is that the wiki format will enable a broader contribution from practitioners and be a (cliché warning) live document, that evolves as the knowledge base grows.

To be successful, a product must not only do a better job on the process than what it is replacing (by a factor of 10 in some dimension), but also connect to the preceding and following processes without an impedance mismatch.

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.

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.

This article is an informed and wide ranging history of the profession/role of the business analyst.  Written by a developer for developers to help understand the role and how to work with them.

…Is another man’s treasure. There are many different ways to document requirements when developing software. And there is a proliferation of requirements documents - MRD, PRD, SRS, FRS and design documents. Everyone has a perspective on what each document represents, and each person on the team has a unique perspective on what questions the document answers.

From the article (by Scott Ambler):

UML 2 activity diagrams are typically used for business process modeling, for modeling the logic captured by a single  use case or usage scenario, or for modeling the detailed logic of a  business rule.  Although UML activity diagrams could potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so that it is simple enough that you don’t require an activity diagram. In many ways UML activity diagrams are the object-oriented equivalent of  flow charts and  data flow diagrams (DFDs) from structured development. 

High level overview of the processes that make up the bulk of requirements management work.

Article provides an overview of twelve rules for writing good requirements. Each rule has its own page (linked from this one).

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?