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

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. 

Project management for incremental delivery / iterative development projects by Johanna Rothman

A rolling wave plan is a continuous detailed schedule that's only a few weeks long. As you complete one week of detailed schedule, you add another week to the end of the schedule. With a four- week rolling wave schedule, I never have less than four weeks of detailed schedule, and I never have more than four weeks of detailed schedule.

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

Peter Merholz discusses sources of value to justify investment in design.

Managing prioritization with a whiteboard, and the Happy Brian List.

Provides comparison and understanding of looking at products in terms of what the products can do, versus what the user can do with the products.

By writing better requirements

An excellent introduction to, overview of and fairly comprehensive discussion on continuous integrations. Here's an excerpt from the page: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage."

Im Podcast Interview von Christian Höcht beleuchtet Dr. Gernot Starke die Aufgaben und das Zusammenspiel von Projektleiter, Software-Architekt und Analytiker. Ich finde das Interview hörenswert, weil Gernot Starke einige wichtige Aspekte der Projektarbeit in klaren Worten beschreibt. Außerdem der trockene Humor von Gernot Starke und die unkonventionellen Fragen von Christian Höcht.