11 March 2010

What tools do you use?

Posted by
In Jan and Derek's article I linked to yesterday there is a set of statistics from the IIBA 'Practices survey" from 2008.

"Whilst the most regularly used diagramming technique was flowcharting (63%), when it came to formal diagramming notations, use case led the way (55%) followed by data flow diagrams (42%), activity diagrams (38%) and context diagrams (34%). Entity relationship diagrams were still widely used (30%) and BPMN came in at 13%."

These tools and their spread is interesting. Something to consider is the likely response bias. The IIBA is still a relatively new organsaition and so the respondents are likely to be people who are particularly engaged in the development of the BA community.

I suspect the respondents are a little more experienced than the average, probably a little older as well.

Does this mean the survey is biased towards older, less modern techniques?

And if so, does this mean that there are a set of proven and pragmatic tools that are being ignored by the newer generations of Business Analyst?
Labels:

3 comments:

  1. Hi Craig,

    Your supposition (that the responses skewed towards more senior/older BAs) is correct. Younger BAs were somewhat less likely to use formal notations and more interestingly used a much narrower set of techniques.

    For BAs with less than 3 years experience, the numbers were:

    Flowchart: 51%
    Use Case: 50%
    DFD: 34%
    Activity Diagram: 26%
    Context Diagram: 20%
    ERD: 22%
    BPMN: 9%

    We're probably going to run another survey this year and it will be interesting to see what changes.
    ReplyDelete
  2. I'd be interested in how the question was asked. For instance if the question were which diagram technique is used in each Business Requirements Document produced we might find different popularity. For instance in a BRD you might have 1 context diagram, 1 UML Use case diagram, 1 ERD but many DFD's and Use cases narratives.
    ReplyDelete
  3. The question was simply whether you use the technique regularly, occasionally, or not at all. We would never ask which document it was used in because that's methodology specific. For instance, I personally never developed separate "business" and "systems" requirements documents.
    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 ...