4 May 2009

Occams razor & Specification

Posted by
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
Labels:

4 comments:

  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:

    http://www.dsmweb.org/

    http://en.wikipedia.org/wiki/Dependency_Structure_Matrix

    are some starting points.

    But in the end the answers to your questions are non-trivial for non-trivial problems.
    ReplyDelete
  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.
    ReplyDelete
  3. Guys

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

Subscribe to: Post Comments (Atom)

Popular Posts

  • What is Project Scope? What should it be?
    I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ...
  • User Story Template
    Due to popular demand I have aggregated some information on User Stories and created a simple template.  If you feel this would be useful to...
  • Change Request template
    Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
  • BCS forum on "Making Projects Work"
    You've heard many reasons why project fail.  Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
  • PDMs - Precedence Diagram Method
    The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
  • Snowbird; Agile 2011 discussion on the BA
    In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
  • Email, Whiteboards and Well-Caffeinated Wits
    This is a guest post by Jeff Hobbs.  Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
  • 7 Requirements Analysis techniques
    In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n...
  • An Introduction to Stakeholder Management
    The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
  • The V-Model: Table of Contents
    I have written about the V-Model across several posts. The V model is a testing focused expansion of the software development lifecycle. In ...