Once upon a time, people built pyramids, space shuttles, VCRs, and tons of software—all without requirements management tools. Some of these projects were unsuccessful, but a lot of them were. So, why are there dozens of companies selling requirements management tools? Why should you use one? They can be expensive, take time to learn, and the value that you gain by using one can be difficult to comprehend.
This post isn’t about why you should use one tool over another—this is about why you should use a requirements management tool at all. There are several RM tools out there, and I’m not going to recommend one in this post. (We have research available to download here if you’d like to learn how ArgonDigital evaluated requirements management tools.) The following are reasons why you should manage your requirements in something other than Microsoft Word or Microsoft Excel:
1. Your memory stinks.
Face it—human beings are limited in the number of things they can hold in their heads at the same time. We begin to shut down around 9 things or so. If this is true, then how are you going to remember which requirements you will need to update after you change a related process flow step or use case? A tool can maintain these relationships for you and even tell you when you have changed a requirement which affects other requirements (the good ones can, anyway). The difficulty of maintaining these relationships increases drastically with the number of requirements on your project, but even if you only have a dozen requirements, wouldn’t it be better to have a tool that tells you which related things change so you can go update them?
2. Developers will love you for it.
If you want to score brownie points with your dev team—give them the ability to be notified when a requirement changes automatically without having to interact with actual people. They can continue to code away in their cube or tweet about why Battlestar Galactica was cancelled without being bothered to attend meetings to discuss which requirements changed this week. Most requirements tools allow users to subscribe to changes—so when the requirements that someone actually care about change, the subscribers get an email. If the developer was in the middle of estimating or coding the feature, she will know right away to look for the change, avoiding rework later.
3. You will be the QA team’s hero.
Your Quality Assurance team will be a fan of you for much the same reason that your development team will. Not only will testers receive notifications when requirements change, allowing them to update their test scripts right away, but they will also easily be able to manage their work by focusing on requirements coverage in their testing. In many tools, the test cases can be traced directly to requirements, so everyone on the project can determine which requirements were implemented successfully, and which still require some work to do.
4. They are great for “stakeholder CYA.”
Have you ever had a stakeholder insist that there is NO WAY they approved a certain requirement? In fact, not only did they not approve the requirement, but there is no way they would have EVER approved it, even though you called a meeting where they did, in fact, review the requirement and nod their head in approval. A tool will maintain a paper trail for you, by recording the review and approvals of specific requirements. So, when your stakeholders back-peddle and attack you for never listening to them because there is NO WAY they would have EVER approved THAT requirement, all you need to do is pull up the history trail of the requirement in the tool and say “BAM! Look right here—you indicated your approval on September 23rd at 3pm. How you like them apples?”
5. Because you shouldn’t be implementing every requirement on a project.
Most requirements specs are full of requirements that will never, ever be implemented—maybe they were descoped early in the project, or maybe the related business objective is no longer part of the company’s strategy. If you’re using Word for your review, you have to awkwardly explain how “these two requirements in this section and these four in this section aren’t in the release so we’re just ignoring them from now.” This often causes stakeholders to get nervous and wonder—did I really descope that? Why? Wait a minute—I would never descope that, which brings us back to reason (4) above. However, a requirements management tool also allows you to find and prioritize or descope requirements correctly and appropriately. Since all requirements should be traced through features to business objectives, you can determine which requirements will provide the best ROI. If a business objective is cut, then you can revisit the requirements related to that business objective and determine whether it should still be in scope.
6. Because Microsoft Excel just can’t do everything you need a requirements management tool to do.
Excel is horrible at visually representing one-to-many or many-to-many relationships. Imagine you had 3 use cases that were related to 2 or 3 process flows related to 2 or 3 requirements. How could you build something in Excel that told you which requirements and process flows you had to go update based on a single use case update? Or what if you updated one of the process flows and had to find which use case you needed to update? The overhead you add by maintaining all those columns in Excel is eliminated in a tool. How much overhead would it take to get Excel to send emails to people when something in a spreadsheet changed? If you’re able to do all the things I’ve mentioned above in Excel, then you’ve already invested in developing an Excel-based requirements management tool and could probably sell whatever you’ve created. But most RM tools already show you the relationships between requirements artifacts in a much cleaner and more navigable way than Excel.
