Introduction
If you are looking for a requirements management tool, you probably don't need to be told how important requirements management is and you've already accepted the inconvenient truth that requirements management on your project(s) is not as good as it could be.
There are a number of standard questions to be asked when selecting any software product for your organization. However, here we shall primarily address questions that are specifically applicable to requirements management tools. The exceptions are questions relating to the vendor of the product, an equally important consideration as the tool itself.
This is not intended to be a list of desirable features in a requirements management tool; that may differ according to project and organization and so is best determined by asking question 1.
1. Understanding Your Needs
Do you have a clear definition of what you are looking for? If you are not sure, you're not ready to buy. It can be an educational experience to see what vendors in the marketplace are offering, but if your organizational needs are unclear, the multitude of features on offer is likely to add to the disarray. Don't put the cart before the horse by looking at tools and then deciding whether you need that functionality. If you don't know where you are going to drive your car, can you say whether you need 4-wheel drive?
While it is true that you can't really be sure of the long-term direction of your organization, planning for all eventualities will lead to the perceived need for every feature possible. At the same time you need a product that will be a real benefit. It's a fine line to walk, but in reality you want to keep your needs simple and avoid an over-engineered solution that will be expensive and more difficult to deploy. Don't be led by the vendor into adding requirements to your list; this is a good opportunity to practice the prevention of scope creep.
2. Flexible Process Support
Is the tool flexible in supporting processes and procedures? Unless you are a start-up, you probably have some methodology in use already. One common approach is to look for a software solution that can support your current process, however, one of the probable reasons you are looking for software support is that things are not going so well, in which case you should also seriously consider reviewing and improving your process.
Looking for a software solution that fully and precisely supports your current way of working is likely to be a fruitless search and it narrows your vision, effectively eliminating the opportunity for change. So, you need a tool that can adapt to the new process you probably haven't implemented yet, and may have not even devised. The process you implement is unlikely to remain static so, can the tool change with you? Is the tool you are considering configurable? Beware of tools that offer support for “any process you like, provided it's ours!”
A couple of supplementary questions can help you here. In what direction is your organization headed? Are you planning for today or tomorrow? Is the tool primarily designed for Agile projects or those following a waterfall methodology?
While it is important to consider the future, trying to anticipate every eventuality might prove to be a costly and implausible task.
3. Requirements Formats
Are multiple requirements formats supported? You might easily imagine the need to label various requirements differently using textual attributes, but it is almost certain that textual requirements statements will become insufficient at some point.
Will you have the need to show requirements graphically? If a tool cannot support visual requirements representation in some form, it could quickly become a limiting factor in your success.
Some tools only allow you to enter information in plain text, others (as illustrated above) let you enter in rich text, with formatting, lists, tables, and images. You should decide what type of text formats your users will need to use. Another question, would be, do your users need to be able to attach documents, screenshots, and diagrams to the requirements? Not all tools provide this feature.
Support for requirements elicitation is particularly important if you are to avoid additional work importing original requirements from some other product. Gathering requirements using a word processor is simply creating more work, as well as opportunities for introducing errors. Consider how you would use the product during a conversation with your customers when you will want to capture the ideas as they arise. By directly entering the ideas into your formal RM tool you can see what supplementary information is required, leading you to ask further pertinent questions right then and there and making the elicitation session more productive.
4. Change Management
Anyone who thinks that their requirements will remain unchanged is in serious denial. Even the most rigid of government procurement projects is going to change more than anyone would like. Consequently, an important question must be, How well does the tool support change? Change has two perspectives: looking forward, and looking backward.
Changes of the future need to go through some kind of approval process which, should at a minimum, consider the impact of that potential change. How would this be achieved in your tool of choice? Be careful not to make the mistake of believing this can be managed by your existing configuration management tool as that will make the task of relating changes to individual requirements almost certainly impractical.
For changes of the past, you need to have a good record of what happened, and why. Does the tool support change logging and query so that future generations understand 'why'? – provided your products last that long!
Finally, good change management requires some kind of baselining. Make sure you can easily define sets of requirements applicable to a specific time, version or release.
5. Linking Requirements to Tests
How well is the requirements function integrated with the testing function (and even defect tracking)? The relationship between requirements and tests is a subject worthy of greater and more serious discussion than we are able to give here, but what we can say is that this relationship is the most critical of all. Without it, not only is the project likely to fail, but worse, you won't know it has failed until you have delivered.
It should be easy to create links between requirements and tests as well as to derive tests quickly and easily, directly from the requirements. A good software solution will support both ends of that equation equally well. Avoid the requirements management tool with some 'tacked on' test capability and, equally, beware the test management tool with some rudimentary requirements capability added to get the 'tick-in-the-box' for on-paper product comparisons.
Also, show caution if the tool supplier is promoting a third-party vendor to provide one or other of either requirements and test management. As well as higher costs, you double the dependence on vendors, and place your trust in the future good standing of their relationship. This is especially worrying with vendors of requirements tools and test tools as the close synergy of these two disciplines could easily lead one or both vendors to become competitors at a later time.
Finally, if you do choose so-called best-of-breed solutions, one for each of requirements and test management, pay close attention to the program level interface between them. Not only does this need to work well (which they often don't), but it will probably require some added level of administrative effort to keep it operational. If you are unable to upgrade both tools at the same time, you do run the risk of having incompatible versions.
6. Flexibility of Relationships
Traceability is a 'must have' for any decent requirement management tool, but it is rarely simple. How flexible are the traceability features? Ideally, the possible relationships would be arbitrary, that is, any piece of information should be linkable to any other piece of information. That is not to say the tool shouldn't provide relationship rules, but we want control of those rules and not have the software limit the ability to create whatever traceability we see fit.
Consider also, the ability to create a relationship or link to an artifact not in the tool itself. Can you create a relationship to a PowerPoint presentation or a web page should you need to? Don't expect the tool to understand all external artifacts, but at it should at least be capable of knowing they exist.
7. Collaboration
How well does the software support collaboration? It is highly inefficient to rely on email, text messages or even worse, group meetings, to facilitate the communication of team members in real time. Information may be out of context and afterward, no reliable record of the interchange exists, leaving other team members in a vacuum with no good way to discover what is going on. Look for tools that support some kind of communication, even if it is only notification of change or allocation of tasks.
Today's projects are rarely staffed in a single location. Even if you don't have distributed teams now, that time may come sooner than you think. Any required installation on the client-side is going to raise the cost of ownership of your chosen product, whereas a tool that supports remote access with a zero client footprint is going to serve you well whether your teams are co-located or distributed.
8. Product Roll-out
Once you have selected your tool of choice, then comes the hard part; putting it to work. A product may look simple and easy to use in a demo, but then it's being used by a tool expert. During the roll out of your new product, you will have few, if any, experts on your project. Is the product going to be as easy to use as it appeared? One good way to find out is to do an evaluation before you buy and many vendors offer this option. The trial period can be very telling; do your evaluators get excited or concerned? Do they get up to speed quickly or is there a greater than expected learning curve? Consider the implications if the vendor recommends training; does this mean the product is complex? Does the tool impose an overly involved process?
Even if you are considering a product that only covers management of requirements or testing, evaluate the product from both the requirements and the testing perspective, as the product will seriously impact both regardless of its primary function. Ideally, involve both requirements managers and test engineers in the evaluation.
9. Customer Commitment
With the selection of a requirement or test management tool, you make a serious commitment to the vendor. Is the vendor willing to make a commitment to you? We've all had the experience of wonderful service while in the buying process, only to have vendors disappear into another dimension, never to be seen again, as soon as money has changed hands. I have even experienced this with so-called 'Premium Support' where it actually became harder to get help than it did as a regular customer.
Look for customer involvement. Is it easy to get help? Call the hotline before you buy, just to find out. Does the vendor offer a rich educational environment to help users get started and develop their requirements and/or test management skills?
Does the vendor facilitate client meetings where the product and its future can be discussed? We don't necessarily need to get everyone into a physical room at the same time, on-line forums can also be effective.
10. What tools does the vendor use?
Does the vendor use its own tools? A simple question perhaps, but the answer can be very revealing. Do they use the tool fully, or do they supplement it with other software? For example, at one time, Telelogic (since acquired by IBM) used TestDirector, now part of HP's Quality Center, to manage its testing. DOORS users should have concluded that any test management capability within DOORS was minimal.
While we wouldn't expect a software vendor to be keen to admit they use a tool from its competitors, we also wouldn't expect a lengthy explanation of how they do things, using their tool in an unorthodox way. Every organization likes to think their operation is somehow unique, but in truth, the differences are marginal and a vendor's description of how it uses its own tools should be straightforward and easy to understand.
Summary
Before choosing any new product, whether it be a car or a software tool, decide what you need. If you decide to choose a requirements tool based on a set of defined criteria then make sure you include both the functional and non-functional requirements. Does the tool support remote working? What problems are you likely to face during the product roll-out? Is the product vendor committed to you as a customer. If you are not sure how well the product really works, try putting your requirements for a tool, into the tool. There's nothing like using a product to evaluate itself.
PowerPoint is a registered trademark of Microsoft Corporation.
DOORS is a trademark of IBM, Corporation.
HP Quality Center is a trademark of HP Corporation.
All other trademarks are the property of their respective owners.