Practicality (yes, another 'Tools' post)

There is a recent discussion on a LinkedIn group for information architects regarding requirements tools. The original poster asked for requirements analysis tool recommendations, and the responses have varied widely.

As the thread has gone on, it began to amuse me that here we are--business analysts and information architects--doing exactly what we shouldn't: recommending tools without knowing the requirements.

It's not a "one-size-fits-all" practice in which we work. Just like we as BA/IA/UXD folks wouldn't recommend a single technology solution or single user interface model for every business problem.

Many people swear by Axure, which is a great tool for developing high-fidelity prototypes. Rational is a great tool set for those who are using Rational Unified Process. For those using Agile, Rally can be a very effective tool. For us, a set of custom-designed Sharepoint web parts (in effect, spreadsheets on steroids) does the trick.

(A note on prototyping: I cannot recommend it enough as a technique for refining, as long as you identify the appropriate level of fidelity required to do the job. When we do high-fidelity prototypes, it can become challenging to manage customer expectations around delivery ("It looks like you're done, so why does detailed design and development take so much longer?"). Regarding the archaic tool set "Paper and Pen" (or "Pencil and Eraser", which are infinitely more efficient for people like me ), it may not be effective to rely on those for every situation. But the ubiquity of the digital camera makes taking a photo of a sketch--pencil or whiteboard--much more efficient for our internal processes than taking an extra hour or two creating a Visio wireframe or Axure mockup. And when you're charging your customer, an hour or two per use case can make a difference.) 

So, just like the work we do, I'd want to know more about the requirements of the organization or project before recommending a solution. So, as I try to boil it down, here are some key inquiry points:

- What processes do the tools need to support?

- How mature / flexible are those processes?

- What is the scope and scale of the projects you need to define?

- What are the types of requirements and level of detailed analysis you need to perform?

- Who is your audience for the outputs? Do you have capable, experienced developers and customers, or do they need a bit more hand-holding?

- How well-developed are your BA/IA skills? What techniques do you use for gathering requirements?

- What is your budget? We have none, so specialized tools aren't cost-effective for us. We are trying to be innovative by finding new uses for the enterprise tools we already have in place.

- Are there any regulatory or legal constraints that require a particular level of analysis or documentation rigor? That might prompt you to use a different toolset.

I'm sure there are several more....

So, the answer, as usual, is "It depends."