What do you think are the most important things that should be looked for when selecting a requirements management ALM tool?
I am very jaded on this topic, as for more than 20 years I have worked with nearly every flavor of requirements management tools and techniques. I have watched organizations spend fortunes on tools, processes, etc., to try and achieve the ‘holy grail’ of requirements -- traceability. To accomplish this goal, I witnessed product managers manically working with documents and spreadsheets, followed by crazy efforts to keep the requirements management system up to date. So, what do I think should take highest priority when selecting a requirements management tool?
First, I recommend that you ponder whether or not you are actually able to capture accurate requirements for your specific domain. In my experience, this is a major problem, as defining accurate requirements in most cases is quite difficult, if not impossible. This is why new development approaches, like Agile, have grown (and continue to grow) in popularity. For example, consider the domain of business applications, specifically custom apps that attempt to automate new, innovative processes; compiling accurate requirements for a brand new, never-before-tried application is impossible. The business is simply evolving too rapidly to accurately define specific business needs/outcomes. So in this case, stick to a lightweight backlog management process, using spreadsheets or a Web application that allows for an iterative, Agile approach for requirements management.
If you are addressing a problem domain that does allow for well-defined requirements, then you need to understand the key players involved with capturing, refining, prioritizing and approving requirements, as well as how you know when a requirement is actually implemented. Defining this will put you on the path to finding a tool that gives you traceability. Also, don’t forget that you need to consider everything that happens when a requirement changes.
Once you have your process and stakeholders defined, I recommend that you look for an ALM requirements management tool that facilitates:
- Requirements capture -- Does the tool easily support the nature of your requirements needs, written, use cases, diagrams, etc.?
- Stakeholder collaboration -- This should be easy to do for the stakeholders, for which I recommend a Web-based solution.
- Easy organization, classification and prioritization -- This should include defining who does what and as well as workflow automation.
- Built-in change auditing and notification -- This needs to be carefully controlled, as over-notification is sometimes worse than none at all, resulting in inattention to changes in general.
- Reporting -- A key component, as it actually lets you show the value of your work to other business units.
If you are going down the formal requirements management path as part of your ALM tooling, consider this: start small, using a lightweight approach with few restrictions and lots of auditing. This allows you to have a very flexible process, but still have enough information to analyze and improve the process. As the process starts to get tested and proven, then look for or build a tool that enforces this process.
This was first published in March 2011