Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Arguably the most widely used tools today would be Microsoft Word or Excel simply because they are available, but they lack any specific features or integrations to make them appropriate to requirements. Also, it is helpful to understand what we mean when we say requirements gathering. Generally what is implied are both the definition of requirements and the management of changes to those requirements. There are some tools that do both, like Borland's Caliber Analyst, but generally you find most requirements tools focus on management.
However, recent entrants to the requirements arena are a class of tools for Prototyping / Simulation that emphasize good clear definition of requirements. These tools are targeted at business analyst, rather than the developer, and are meant to increase collaboration early in requirement creation. Currently there are three primary tools positioned in this space. Simunicator by Simunication, Prototype Composer by Serena, and iRise Studio by iRise. I am clearly biased towards Caliber Analyst since I work for Borland, but I encourage you to take a look at Simunicator for an easy to use prototyping tool that you can get started with almost immediately.
|
 |
More important than choosing a tool is figuring out the process for requirements gathering for your project and determining with whom you should be validating those requirements. Prioritizing the requirements that will generate revenue if you are building products or the requirements that will meet your users' needs if you are building software on a contractual basis is the hard part. The tools just make that job a bit easier and repeatable. Asking the right questions at the right time (process) is a human operation, and it takes practice and consistency to be good at it.
Of course any tool that you do purchase will need to work within your environment. Consider what other tools may already be in use and which of those will require integrations, so that you can pass along the requirements to the other vital members of the team. The obvious ones are defect management, configuration management, account management and case management tools, but also consider the business intelligence tools that you use in your organization. How will you frame your requirements relative to the business value (i.e., $$) that they will contribute to your enterprise in order to gain approval for resources?
This was first published in November 2007