The Business Analysis “Artist” and the Requirement Tools of the Trade

Just wanted to share and comment on a post I came across the other day that points out the potential drawback of requirements management tools. Per Jeff Levinson at Northwest Cadence:

There seems to be a growing move towards using tools … to subsitute for processes. Tools are great, they really are. They help make our lives, as software developers (using the term loosely to cover anyone who deals with software development) easier. They make our customers lives easier. But there’s a coming problem that relates to an over-reliance on tools. Our industry needs to step back and realize that soft skills are more important than tools – especially in the requirements area! Being able to talk to someone and write and take good and accurate notes and being able to read body language are more important than any tool. Tools make communication, traceability and monitoring of requriements easier but they don’t make the requirements any more accurate. It might even be nice if schools, on top of teaching all of the technical subjects, started teaching better communication skills (both written and spoken).

What they do..

First off, I agree with Jeff 100%. Requirements management tools are great in that they really help with the organization and reuse of requirements. They automate traceability – which, if you’ve ever done a traceability matrix manually, you know that having it done automatically is a huge savings in time and tedious effort. RM tools provide search and reporting functions and collaboration options that you just don’t get from a directory tree full project-specific specs in MS Word. They allow you to associate useful meta data (attributes) to your requirements and use them to further slice and dice them for reporting or tracking purposes. These are just a few of many great reasons to use a requirements management tool.

What they don’t do..

What RM tools don’t – and I’d argue that they can’t do – is help the analyst ask the right questions to draw out customer need. They don’t help the analyst articulate the requirements that they gather in a way that is accurate, precise, and understandable by the folks that will be using them to design and build the solution. It’s basically a “garbage in, garbage out” scenario. The requirements in your tool will never be better than the analyst’s ability to elicit and document them allows.

What they’re hoping to do..

We’re seeing – and I’ve spoken about it here – the emergence of the concept of the requirements workbench. Vendors are striving now to couple their requirements management tools with new tools that will help analysts capture and model requirements (see Blueprint, Borland Caliber DefineIT, etc.). I think that’s a neat idea. I think that being able to sit down with a customer and model the requirements within a tool is a great, time-saving capability that may also have some positive affect on the quality of requirements, and it puts them in a form which can be easily used by downstream designers, developers, and QA analysts.

The “art” of the matter..

The bottom line, though, is that business analysis – and in this case, requirements elicitation in specific – is an art. There is an art to being able to direct the flow of discussion/questioning to draw out true stakeholder need. There is an art to cutting through “symptoms” and false trails and identifying actual business problems. There is an art to being able to sense false consensus in a group or panel setting and to tactfully draw out participants’ true thoughts.

In the end, it’s the art of business analysis that just can’t be replicated by tools.

About the Author

Jonathan Babcock is a management and IT consultant with expertise in business analysis, process optimization and solution delivery methodology. Practical Analyst is his outlet for sharing what he’s learned, and for interacting with solution delivery professionals across the globe.

Author Archive Page

8 Comments

  1. I completely agree. We had a product implementation process that was for a highly customized software product and tried to "streamline" the implementation by automating the requirements gathering (first through a MS Word survey and then through an MS Excel workbook). Neither worked and ended up adding to the cost of the process as we had to go back and confirm everything (and find most of it to be incorrect/ill-structured or just blank due to misunderstanding of the question). The face to face/voice to voice requirements gathering just cannot be replaced. It can be enhanced by tools that the BA uses to document the results of the conversation, but you can't "take out the middleman" (ie the BA) by replacing them with a couple of documents…it just plain doesn't work.

  2. Largely, I think this post is spot on. However, I beg to differ on your interpretation of "what they're hoping to do".

    In some limited cases, tool collaboration may enable some interaction that was not previously possible. For example, capturing structured scenarios or UI mock-ups in a tool may enable remote participation. With large, geographically distributed businesses it is not always possible to use more effective in-person communication.

    More importantly, I consider the "requirements workbench" idea as a supplement to the in-person work of a BA. I fully expect BAs to use paper and whiteboard tools in direct interaction with stakeholders. On the other hand, the traditional RM tools have made it hard to effectively capture the structure and visualization of these techniques. Hence, I see the requirements workbench as the tool the BA uses to digitize the artifacts generated by interaction with stakeholders.

    As such, I share your concern that BAs should become too reliant on the tools as the mode of interaction with stakeholders.

  3. I agree that great tools to not make great BAs. I also wonder if the focus on tools can get in the way of great business analysis. I don't know much about requirements workbenches, but if you are expected to work within a tool (in collaboration with business stakeholders, no less) and the tool doesn't do what you expect, I would think there is a danger of the meeting becoming about getting the tool to do what you want instead of eliciting requirements. I've seen this happen in project management, where the team spends more energy figuring out how to get Microsoft Project to do what is wanted instead of actually engaging in project planning.

    Best,
    Laura Brandau
    http://www.bridging-the-gap.com

  4. What they don' do…
    What they are hoping to do…

    Requirements management tools help. Would we consider additional assistance?

    NASA IVV recently completed a study on tools that analyze requirements,
    written in a natural language. A report of the study is available from
    valerie.s.jones@ivv.nasa.gov
    One of the results of the study was, that a domain expert found four major issues in a set of requirements. With RA, a junior Requirements analyst found the same four issues, and she found six additional major issues. She found these ten issues in less time than the domain expert needed.

    Because the study was so successful, NASA IVV is using Requirements Assistant (RA) to analyze requirements for their Orion and Juno programs.

    A recent GAO report on DOD system development programs concluded that "indepth requirements analysis" left a lot to be desired. Here is a potential answer!

    The Website provides more information on RA, and when you would like to know
    more, please let me know.

    http://www.requirementsassistant.nl

  5. I agree that great tools to not make great BAs. I also wonder if the focus on tools can get in the way of great business analysis. I don't know much about requirements workbenches, but if you are expected to work within a tool (in collaboration with business stakeholders, no less) and the tool doesn't do what you expect, I would think there is a danger of the meeting becoming about getting the tool to do what you want instead of eliciting requirements. I've seen this happen in project management, where the team spends more energy figuring out how to get Microsoft Project to do what is wanted instead of actually engaging in project planning.

    Best,
    Laura Brandau
    http://www.bridging-the-gap.com

  6. Hi, Laura!

    Yeah, I've heard of similar stories to the PM example you mentioned in the requirements management space.

    I think you really have to treat selection of an RM tool the way you would treat any other project. You need to be specific about what points of pain you expect it to alleviate, and realistic about what it can and should be expected to add to the requirements gathering and management process.

Post a Reply to Jonathan Cancel Comment

Your email address will not be published. Required fields are marked *