4 May 2009

Occams razor & Specification

William was right.  We need to keep things simple.

Requirements documents have 2 purposes;
  1. Explain what capability is required 
  2. Describe the contraints that need to be adhered to
Whatever you can do to trim your documentation?  What are you saying that is unnecessary?  How can you use less words (and images) to deliver a clearer message?

Simplicity is the method.  Clarity is the goal.

Jonathan and Albert also agree.

Picture by alles-schlumpf, CC @ Flickr


  1. Now the REAL challenge comes.
    What is "simeple enough?"

    The answers to the question you pose are the starting point, but they are the carriers of the message.

    What about the underlying "object" of that message?

    What is the "simplist" set of requirements for process health insurance claims?

    What is the simplist set of requirements for autonomous docking of the Hubble Robotic Service module?

    What is the simplist set of requirements of integrating a SOA portal with the US Air Force's Net Centric Warfare procurement site?

    These are actual requirments elicitation domains from recent years.

    Once we scale past the obvious and some might say trivial examples of requirements specifications, the non-linear aspects come into play.

    The role of the systems engineering contributes to the solution in those three examples. INCOSE (the SE society) has much to say about "recognizing" simplicity and reducing complexity. The Design Structure Matrix approach found at:



    are some starting points.

    But in the end the answers to your questions are non-trivial for non-trivial problems.

  2. That reminds me of a classic quote from Albert Einstein. "Everything should be made as simple as possible, but not simpler."

    The problem is how to tell the difference between too complex and too simple. How do you retrain your SMEs from treating requirements as some kind of kitchen sink repository with which to house all of their wishes? How do you retrain corporations from the bloatware model of software development where it's a feature race with your competitors? The word No becomes very important when less is more.

  3. Anonymous9:22 am


    One of the things that I think we all relise by now is that the idea of one pm method/framework or model that fits all industries is a pipe dream.

    Even within the context of creating software one model doesn't fit all situations.

    I think I have to go back to earlier incarnations of the PMBOK and think about that. It was simpler but also didn't complexify the perspective either.

  4. The difference between PMBOK and a software development method needs to be made clear.
    PMBOK contains Knowledge Areas and Process Groups that are generally applicable to every project.

    As well there are a set of immutable project principles that are independent of all projects - meaning that no matter what domain or context, these principles are in effect.

    Until this notion becomes clear, the discussion of method, methodology, process, principles will continue to cycle.