25 April 2008

Requirements Management - the Six C's explained

I am putting up straw man ideas about requirements management and communication prior to me reviewing the draft chapter in version 2 ofthe BABOK. This is so that I can get my ideas straight before I go and review what the commitee have put together.

So far I have run through my ideas on Requirements Communication an am now looking at Requirements Management processes. Last post I put forward a model for requirements management called the Six C's.

This post I want to explain the six Cs of Requirements Management in a bit more detail. When you have read my thoughts I am very interested in your comments.

Each of these ideas (Cs) is described below, followed by putting them into the context of both Waterfall and Agile development processes.
  • Concept - High level ideas about what the product will do.
  • Clarity - Requirements elicitation, and analysis. Defining the requirements through workshops, interviews and so on, and then documenting them or implementing them into a system that can track changes and act as a control point.
  • Consensus - Socialisation and approvals. Get stakeholders, the sponsor and project team to agree that, yes, these are the requirements.
  • Commitment - Addressing requirements in the solution design and allocating resources to build the solution.
  • Control - Control process applied to requirements; understanding the impact of changes (and possibly making sure the developers stay focused on the requirements while building the solution.)
  • Confirmation - Validating requirements in testing and implementation. Audit solution design; check that the requirements have been addressed in the solution design, and if not, what are the impact to the business case and what is being done about them.
So, let’s apply these concepts to the Waterfall and Agile processes. I figure that Waterfall and Agile are opposite ends of a methodology spectrum and so applying the 6c concept to both processes will illustrate the universality of the concept.


  1. Anonymous1:37 am

    Good comparison. I've started using the term "conventional" when comparing processes. "Waterfall" implies the circa 1970's TRW Development Lifecycle and all its attendent issues. But even if it is not used, the "conventional" approaches to PM still have the echo of those bad olde days.
    If I go down the list (a good list btw) - it seems to me the differences between conventional and agile are in the granularity of the information, and the degree of formality. Alistair Cocokburn has an article in the current issue of CrossTalk (a defense sw journal) about iterative and incremental that clarifies some misconceptions. Even in large defense development programs, requirements emerge as the maturity of the program moves from left to right. At each "assessment point" details become clearer, and even the top level requirements change. "We were going to the moon with Orion, now we're not, we're going to Space Station." That's a big change.
    Your matrix is a great starting point that can reveal the similarities between conventional and agile.
    Brookhaven National labs uses a "graded" project management method similar to this. Maybe the vocabularity is becoming normalized to "just good project management"

  2. Thanks for the feedback Glen.

    It's always a pleasure to have respected peers give positive feedback.

    We are in agreement about frameworks coming together.

    I saw a good post on this topic at PM HUT recently. It was a reminder that the software developmet process is a subset of most prohjects, and while this work stream may be run to a poject framework is often a sub component or a broader project.

  3. And Stephen at Requirements Network Group has suggested we add CAUSE as a precendent to the other 6Cs.

    Great idea. We now have 7 Cs.