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

rather a database than an article. useful, however!

If you read the article I linked to in my last post you read that Peter Morris thinks the PMBOK is too limited and that a more holistic framework of managing projects for success is required. He believes the body of knowledge must go beyond the pure PM techniques and include what is necessary for success for it to be a truly useful PMBOK. Extending the idea further for business analysts; Is the IIBA making a mistake by constraining the BABOK to what is unique about the role. Is it unique anyway - see the SWEBOK as an example of overlap. Shouldn't the IIBA work out what the key success criteria are for BAs and make that the foundation of the BABOK?

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.

A short article on stakeholders for PMs and BAs. Covers what is a stakeholder, the cyclical approach to stakeholder management and the influence engagement model. "The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtual teams, across matrix companies, they may be stakeholders, as their roles extend to beyond the project. They are thus committed more to their local business unit than the project’s success and have an impact on whether the project goes ahead and whether it is considered successful..."

Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline - and we can apply it to any form of project-status. In this article, we will apply it to documenting business processes.

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.

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.

A short article on stakeholders for PMs and BAs. Covers what is a stakeholder, the cyclical approach to stakeholder management and the influence engagement model.

"The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtual teams, across matrix companies, they may be stakeholders, as their roles extend to beyond the project. They are thus committed more to their local business unit than the project’s success and have an impact on whether the project goes ahead and whether it is considered successful..."