Save time. Compiling a requirements document takes so much time. You have to talk to the people who collect data, input it and use it. Besides the time required just to talk to them, you'll have to compile the information, analyze it and then decide what you already know -- the old system is not as good as the upgrade will be.

Save money. Well, time is money, so the time you save in point one, above, is money saved. Think short-term efficiency and productivity.

An upgrade is a one-time expense. Look at the cost of the upgrade as an investment in the business and you'll have to consider your return on investment. Such a calculation requires you to consider how much more productive the organization will be with the upgrade -- and at what cost -- compared to the current application. This can open Pandora's box or a can of worms; it's your choice.

Eliminates outside interference. More often than not, a good requirements document will involve an objective outsider, who will ask all kinds of questions: What do you use most? Who uses the data? What reports are necessary? What doesn't work as well as you'd like? What do you use in this system that must be in an upgrade? This can lead to too many suggestions for changes, too much anticipation about correcting shortcomings in the current version and too many cross-functional contradictions. And remember: too many cooks spoil the broth.

Diverts your users' attention. Asking users what they want in an updated software application can be counter-productive. It takes their attention away from the real work they're doing and it forces them to think about what could be done better, faster or more efficiently on the updated version. That process takes time, costs money and could postpone installation while your software vendor makes the requested changes to make the program work the way our users want it to. See points 1 and 2 above.

Users are very good at creating workarounds and desk drawer systems. If it's not broken, don't fix it, right? Your users know this system so well and they've used it for so long they've developed their own ways to manipulate the data and generate reports the business requires. By learning that your users have developed their own "features" -- an inevitable outcome of the requirements development process - you will be forced to ask some serious questions. Why the workaround or desk drawer system? What in the current system made either one a solution? Are these problems or situations addressed -- some might say resolved -- in the upgrade? How? Why? Or why not?

Documentation is unnecessary. Let's take the bull by the horns on this one. If you're going to do a costly and time-consuming requirements document, you simply must compare the documentation for the old system with the documentation for the new system. What matches? What doesn't? Why? Why not? Reviewing the documentation also might tell you how some of the old functionalities have been changed, or omitted. Can your business live with those changes or without those functionalities? The answers to these thorny questions can take your eye off that impressive list of features in the upgrade. And once you start asking yourself "how can we use this or that feature?" instead of focusing on what your business requires of the software, you're on a slippery slope. Ignoring the questions, however, does provide a great opportunity for the business and your users to live and learn later.

Listen to your vendor. The new version will be easier to maintain, the vendor says. And besides that, the vendor won't support the old version. Accept these promises on good faith, so your IT department won't be inconvenienced by costly and time-consuming maintenance - and your users will be able to use the upgrade (it's just a few tweaks to the old system they know so well, right?) with ease and confidence.

Features are not requirements. Features that come with the update are free, aren't they? It's a no-brainer: even if you don't need them right away, who knows -- you might use them later, and you've already paid for them. On the other hand, you'll probably have to pay for specific functionalities you've identified in a requirements document. But remember: If the folks who must use all the "new and improved" features in the upgrade can't do their jobs because the features don't meet their requirements, the new upgrade won't work.

Requirements are not features. Asking your users to identify all the features they like will simplify your task, for sure. But asking them to tell you what their requirements are won't make your job any easier at all -- see points 6, 7 and 8. Think of features as all the expensive options on a new car that has no battery -- they're nice to have but they're of no use until you can start the car and drive away. Such a situation creates new opportunities, however, for your users to create new workarounds and desk drawer systems, and that will help you justify the absence of a pesky requirements document.