Monday, May 18, 2009

Categorising Tools for BAs

People talk a lot about "BA tools" and "Requirement Management" without really defining terms.

I think it's worth at least defining some of the different types of tools that are out there so you can compare apples with apples. As a candidate list:

  • Collaboration: Systems that help groups of people work together to build a body of knowledge. Word documents on share drives, Wikis, doc management systems, etc in this area. These sort of tools can be used for everything.

  • Requirement Tracking: Systems that allow BAs to collect "requirements" as a list of statements and then track which are in and out of scope, which are included in a release, who approved them, and the like. These tools are primarily used in the Elicitation and Requirements Analysis knowledge areas. As mentioned Adam's "Bright Green Projects" looks like a great pre-rolled offering in this space. Requisite Pro falls mainly into this camp.

  • Solution Modelling: Systems that assist you in building a rigorous description of the systems functionality. This covers tools like Enterprise Architect, any of the BPM tools, ERWin, etc. These tools are primarily used in the Solution, Assessment, and Validation knowledge area

  • Solution Validation: All of the testing tools, coverage, execution, automation that this conversation has been conveniently ignoring.

    All of these are "Requirement" management according to the BABOK definition of a requirement - and no tool falls neatly into any camp, but neither does any tool adequately cover all areas.

    IBM's suite probably covers every area but it really is a behemoth.

    P.S. Tools are the caps one of BA Capability improvement - not the foundation. Tools can often do more harm than good in an immature environment.

    BA work is about building bridges between different domains, and tools (almost) invariably hurting in one domain, as much as they help in another. Microsoft office is worse in a completely different way though. Wiki & Issue tracker is a decent compromise - but is also not without problems.

    Changing tools without a mature BA practice will likely just leave you with a new set of problems and higher monthly licensing costs. I would strongly suggest that the money and time you could spend on tool setup is better spent setting up a BA Community of Practice and put on a spread so your BAs can tell War Stories to each other over lunch.
  • No comments:

    Post a Comment