I had the opportunity recently to write a tongue-in-cheek piece with the not-so-brief title Top Ten Reasons You Don't Need a Requirements Document when upgrading software. At the conclusion of that article, I offered to provide a realistic counter-point -- my list of ten reasons why you MUST have a requirements document in hand before you invest money in upgrading or purchasing software.

With all due respect to another and far better known David who offers his top ten lists much more frequently, here are my top ten reasons that creating a requirements document is in your best interests -- and your organization's:

1. Requirements are not features. You simply must know what your users must have to do their jobs. Distinguish thoughtfully and carefully between what is needed and what the vendor is offering. At the same time, you must be able to factor into the requirements documentation other considerations, such as budget limitations and regulatory constraints. You will need to train your users how to specify their requirements, which takes tact, training, and patience. A request usually starts with: "All I really need is.." and then wanders away. A vague or ambiguous statement -- regardless of its intent -- will consume user time, IT time and cause some other loss, such as the opportunity to do another project. This issue is methodology neutral: Agile methods will have the same problem if user time is not focused and users are not trained. You cannot fulfill the requirements until they're precise and complete and you understand why they're important to the business.

2. Features are not requirements. Eliminate decisions made by squeaky wheels --- sometimes referred to as "design by whine" -- where the loudest department gets the most resources. Your goal is to make certain that business decisions made with regard to requirements (and their associated expenditures) will generate the return you're expecting. Start by working backward, to match the problems solved with existing software to identify the problems that must be and can be solved only with new software. Don't lose anything you have now that is essential to the business; it's easy to forget "hidden" requirements that oftentimes are taken for granted or ignored.
3. Work with your resources and manage with discipline. Developing an effective requirements document costs money and managing resources requires discipline. A politically expedient decision, even if it's cost effective in the short run but is not the right decision in the long run, will cost time and money - eventually. From a strategic point of view, ask if the requirements process itself is going to cost more than it's worth. You will find that using the enterprise requirements documentation process will help you avoid useless meetings, which saves time and money, but more about that later. When the appropriate constituents are communicating with each other, they accept the value of their participation because they can track the project's payback to the entire organization.
4. On-going documentation is essential. It's necessary that you continue to manage your requirements, because sometimes internal departments continue to push for a project application or feature that was denied in the last upgrade or purchase. Perhaps it wasn't worth the cost, or its payback wasn't acceptable to the enterprise as a whole. By maintaining continuity in your requirements documentation, you can see why a prior request was denied. If the reason hasn't changed, it's likely there is no need to investigate it again -- and you can avoid bringing in a "new" solution to solve an equally "new" problem. Referencing prior documentation also can help you eliminate ongoing costs for applications and hardware that are no longer used.
5. Identify and understand the workarounds and desk drawer systems. You need to understand what in your current application made a workaround or desk drawer system an attractive solution. Then, make certain the upgrade eliminates these systems and their causes, with this caveat: You might learn, in the course of such an investigation, that a certain desk drawer system has a unique function or user, and that it's best left alone.
6. Focus your users' attention. You want to learn from them what can be done better, faster or more efficiently, but realize that users don't always know their current business needs. In fact, users at different levels of an organization have different perceptions of business needs, priority and urgency. They tend to segregate by department or management level, dismissing problems because "it's not an IT issue." However, an effective requirements document requires integration and impact analysis for all departments. Know, too, that the needs of other stakeholders (senior management, operations personnel and human resources, for example) must be considered. User frustration comes from asking for one thing, and receiving another; help them articulate their needs carefully and fully. When what a user asks for is not possible, feasible or within budget, say so, because unmet expectations foster dissatisfaction. Always ask, what's the relative value of a new "requirement" to avoid spending $10 to save a dime?. And don't forget: users take what they have for granted, so make sure it's carried forward in the new request.
7. Benefit from "outside" expertise. An objective outsider, can, will and should ask the questions an insider cannot. What works? What doesn't? What frequent requests create problems because they're difficult to meet with the existing application? That's the outsider's function; to have no vested interest in how the problem is solved. It's a common pitfall in requirements documentation to describe a problem in terms of its supposed solution, which might not be the best, or most cost effective, approach. An outsider also can provide useful guidance on how to handle regulatory requirements that affect information systems but that most business people are not aware of, such as the prohibition against retail businesses retaining credit card numbers after a transaction.
8. Consider your upgrade as an investment and apply metrics to it. A comprehensive requirements document will help you decide if the benefits of the new application or upgrade justify the cost. How much more productive can the organization be with the upgrade, compared to the current application? Track paybacks for projects and information assets to determine when to re-invest or stop further investment. It's possible that an application was a good investment -- at the time. When it was installed, perhaps it saved every one of your 5,000 clerks 30 minutes a day. But today, you have five clerks and it saves them three minutes a day. That feature probably isn't worth the cost. And some stand-alone features -- such as desktop publishing -- aren't needed now, thanks to the tools available in word processing applications.
9. Save time. Reduce rework by spending time in the requirements gathering and analysis process, where it's much cheaper to eliminate a "need" than realizing it costs too much (or isn't cost effective) downstream in the design, development or application stage. Time invested in the initial steps of the process provides more time for decision making at the right time. More control of the process will help keep it moving; participants will know what to expect as you move from blue sky thinking to brainstorming to understanding to decision making. Tracking the results of your meetings will document what you've agreed to do and what you've agreed not to do and who made the decision.
10. Save money. To start, you will eliminate ongoing costs for applications and hardware that your requirements information gathering tells you are used no longer. With the right subject matter experts and decision makers involved at the right time, you will not be able to move forward on ideas that sound promising but contain potentially expensive problems that would have to be solved later in the process, and at a greater cost. You will open many avenues to managing costs, whether it's eliminating unnecessary systems, consolidating a value-added system or evaluating long-term versus short-term value. You might learn, for example, that in the year required to acquire and install a new system the opportunity to use it will disappear. One of the most promising benefits of developing enterprise requirements is the strong possibility you will establish standard solutions to many of your seemingly "unique" problems, obviating the need for custom solutions. And that can be a real time and money saver.

Posted on Dr. Dobb's Journal at www.ddj.com/codetalk and available at www.nuevista.com

© Copyright 2009. David De Witte

Don't forget to leave your comments below

Comments (6)

Subscribe to this comment's feed

...
written by Connie Love, October 27, 2009

interesting article

• 
• -1
• 
• 

...
written by leslie munday, October 27, 2009

Benefit from "outside" expertise.

IME, the worst person to write requirements for a system is a person was a user of that system.

Les.

• 
• +2
• 
• 

...
written by KERRY DIRKS, October 27, 2009

Your timing on this type of a requirements document is impeccable. I wrote the following to the management of our company this morning ...

I think it would be most helpful to understand what our business users are wanting to do with these Adobe products before we provide them with any adobe product (new or upgrade). This would provide us information from a couple of perspectives:

1.product usage (i.e.; statistics – who is using what)
2.role (i.e.; demographics – Arch, Engr, Corp, Support)
3.user type (i.e.; occasional, power, production)
4.justification (i.e.; visibility of responsibilities – alignment of tool w/role)
5.licensing (i.e.; the above 4 steps would drive our options)

I recommend that a re-evaluation of usage precede the requisition approval step for the following reasons:
•Adobe Tools continue to change in functionality and in scope
* the tool that previously accomplished X, no longer does X
* the tool that previously accomplished X, is now a part of tool G
* the tool that previously accomplished X, is obsolete
* the functionality that previously accomplished X, is now handled differently
•Adobe Tools > 10 years old reside on some user machines
* same reasons as last bullet
•Great place to survey User Experience
* what tools do you use
* what tasks do they perform with each tool
* what worked
* what didn’t work
* what needs improvement
* what is your wish list for each tool you use (… I wish it did … )
* what other recommendations do you have for IT on Adobe products
* what tasks do Adobe products not do or not do well
* what related tasks do you perform with non-Adobe products (i.e.; Corel)
•We can interject some additional value points that don’t cost anything extra
* training opportunities for users
* webinars available
* etc.

• 
• +0
• 
• 

...
written by Craig, October 28, 2009

Perversely a requirements doc seems even more mprtant when looking at COTS than building in house from scratch.

• 
• +1
• 
• 

...
written by John Talbot, October 28, 2009

I agree about an outsider writing the requirements document. Users are inclined to take a functional view, concentrating on how things are done now, while a BA, whether employed by the firm or not, ought to be thinking at an abstract level. That's obvious though.

It's hardly perverse to have requirements doc's when you are looking at COTS! You can be totally at the mercy of sales staff if you don't know exactly what you must have and what you would like to have, resulting in shiny kit that doesn't do the job.

• 
• +0
• 
• 

...
written by Christopher Burd, October 29, 2009

Maybe it's obvious, but I'd also say that "requests aren't requirements". Requests are the starting point for requirements, but are very much from a user or client viewpoint. Typically, I help them write define their requests, then I build a matrix mapping requests onto requirements, which evolves as the requirements evolve. Multiple requests may map to one requirement, and a single request may spin off multiple requirements.

• 
• +1
• 
•