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?

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..."

An article on testing strategy for non-functional requirements that stimulated a fantastic discussion about functional vs. non-functional requirements. Great points are made both to eliminate and to highlight the distinctions. The strategy for developing a test plan is good, and worth reading alone, but this article is fun in that it went in a completely different direction with a very well informed debate.

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.

Article detailing prep work needed before a meeting to make it more effective.  The article is targeted at business analysts holding review meetings, but applies just as well to general team organizational / approval meetings.

Article offers suggestions about how to assure participation by attendees to meetings.  Continuation of previous article on meeting prep.

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?

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