Adequate requirements are the foundation of successful software selection

If you don’t know what you want, how will you know when you find it? When selecting new enterprise software, most people completely underestimate the importance of requirements. You often hear things like "Identify your requirements, and focus on the most important ones". How easy to say, but how difficult to do! Like foundations are to a building, requirements are to software selection. If your requirements are defective, anything built on them is at risk.

Recently the US Air Force scrapped a massive ERP project after racking up $1B in costs. When the Senate probe into the failure has been completed, inadequate requirements can almost be guaranteed to have been a major contributor to this software disaster. An appropriate web search shows industry is replete with these software selection failures, but this is only the tip of the iceberg. Most of the time these problems don’t bubble up into the press or lawsuits, rather they simmer in the background, quietly corroding business productivity and sometimes destroying careers.

So how do you develop an adequate set of requirements that ensures you select the best software for your specific needs? The advice often given is "Interview your users". Necessary, but very incomplete. While users know their immediate pain points, without a framework to guide them they really cannot go much further. To find the software that best fits your specific needs, a thorough requirements analysis is necessary.

Where does a Requirements Analysis Start?

Any requirements analysis starts by gathering requirements, and the usual way to collect requirements is, of course, from the web. You can often find vendors and consulting companies offering free requirements lists for the software in question. Bias is unavoidable, so you should collect and merge lists from several sources. Bear in mind that it often takes many hours of research to uncover useful information on the web.

The next step is to gather requirements based on product features. Most software evaluations start with a few product candidates in mind. Reverse engineer features from these products to derive business and technical requirements. Since vendors add product features in response to customer requirements, this is a great way to uncover requirements you didn’t even know you needed. This also helps capture the latest advances in the market, and helps you avoid buying end-of-life products (because end-of-life products do not have the latest features).

Types of Requirements

Do not make the mistake of thinking that business and technical requirements are all you need. When buying software, you enter a relationship with the vendor and should consider contract and vendor requirements. For example:

Contract

  • Is the licensing flexible enough to meet your needs, e.g. when increasing or decreasing user count? Can the system archive users (e.g. departed employees) and not charge for those inactive accounts? (This preserves audit trails for compliance.) Can third parties like outsourced support use the system at no extra charge?
  • Performance: What evidence can they offer proving they meet their SLAs? Are there any real penalties if they don’t? For cloud-based products, what uptime is acceptable? Does the vendor have hot failovers for the inevitable problems?
  • Termination: No contract lasts forever. For SaaS software, does the vendor allow you access to the terminated account and data? Can you maintain a disused account in a dormant state on their system at a reasonable cost? (You might need this for regulatory reasons.) Do they give you the tools to extract your data to port it to another system?

Vendor

  • Legal: Has the vendor been involved in any recent civil or criminal lawsuits? Any recent mergers or acquisitions?
  • Social: Does the product have an active online community? Does the vendor host product forums? Is there an ecosystem of third party consultants who can help support the product?
  • Financial: Is the vendor profitable? Does the vendor invest a significant percentage of retained earnings in the business? Are there any investors behind the vendor, and are they aligned with the company? Is there any hint of a takeover, or the company being sold?
  • Employees: Any signs of rapid turnover with employees or with the management team?  Does the vendor have a reasonable number of active positions advertised on sites like Indeed.com? What do employees say about the company on sites like GlassDoor.com?
  • References: Vendors always find glowing references, but you want more. You can find potential references yourself by looking in the forums. Another useful technique is to search for the product name on job sites like Indeed.com. Companies that post jobs listing product based experience requirements are potential unbiased references. Use this and sites like LinkedIn or Jigsaw.com to find such companies, and approach them for references.

There are many more vendor and contract requirements, but this should convey the idea. Depending of the nature of the software, you may also want to add implementation requirements to your list.

Writing Requirements

The art of writing good requirements is to make them measurable and achievable. For example, "The software must be easy to use" is a very poorly written requirement because it is so hard to measure. You also have no real idea of when a product achieves it. This type of requirement should be broken down into things like:

  • Does data entry include things like keyboard shortcuts, calculators on numeric fields, calendars on date fields, zip code lookups on address fields, etc.?
  • Does the online help include things like context sensitive help, field level help, video tutorials, training for new employees after product launch, FAQs, etc.?
  • Does search include things like Boolean, keyword, natural language, phrase and proximity searches? Can you save and reuse searches?

However interesting the answers may be, requirements that need a short essay to answer are not measurable, and therefore have no place in a purchasing specification. Often such requirements just need to be rephrased. For example, a requirement like "Describe the company’s vision for the next 5 years" can’t be mathematically factored into a purchasing decision. Rewriting this to something like "The Company’s vision for the next 5 years is deemed adequate" allows you to rate it on a numerical scale, and then factor it into the purchasing decision.

Part of the enterprise software selection process sometimes involves submitting an RFP (Request For Proposal) to vendors. Sometimes there are hundreds of short essay type requirements, and vendors find them just too much work to answer. No response from the vendor can mean the best product is overlooked. Instead, making it easy for a vendor to answer the RFP questions means more vendors will respond. It also makes it easier for you to evaluate the vendor answers.

The Anatomy of a Good Requirement

A good requirement is made up of the following parts:

Every requirement deserves a good NAME. Preferably, no longer than about four or five words, the name should capture the essence of the requirement.

The DESCRIPTION explains the requirement name in detail, and prevents misunderstandings when evaluating products. This leads to evaluations that are more accurate.

For traceability, you need to know WHO the requirement is important to. When evaluating products, you sometimes need to refine a requirement. Knowing whom the requirement came from allows you to go back to the source for clarification.

You need to know how IMPORTANT the requirement is to that person. Every requirement should mathematically factor into the purchasing decision. This means requirements should have a measurable importance, e.g. the importance could be rated on a scale of 0 to 5.

You also must record the reason WHY the requirement is important (or not). For example, the person who specified the requirement is a specialist in that area. However, they left the company shortly after defining their requirements. Later in the evaluation, if you have no idea why the requirement is important, you may be tempted to skip that one. When you finally implement the software product, you may find out just how important that requirement was which can lead to buyers’ remorse.

Finally, each requirement should have a unique ID that does not change. Occasionally during the evaluation requirement, names and descriptions are refined and changed. The ID ensures a requirement is uniquely identifiable across all versions of the evaluation.

Simple or Compound Requirements?

Although breaking down compound requirements into simpler requirements can dramatically increase the number of requirements, it actually makes them a lot easier to manage. Also, it is  easier to evaluate products against those simpler requirements because you change from a judgment of how well a product meets the compound requirement to a series of "yes or no" for several simpler requirements.

For example, suppose the requirement is for pre-defined report templates. One product may have only 5 templates while another has 50. Both products meet the requirement of report templates, but clearly one product is much better than the other. To capture this difference, it may be better to list out the individual report templates expected. Note that splitting a compound requirement into simpler requirements is a judgment call, and depends on the level detail desired in the evaluation.

How do you Manage Requirements?

A requirements analysis starts by collecting a laundry list of requirements. Even unimportant requirements need to be captured so they can be managed, e.g. if something is not important you should capture the reason why it is not important. If you keep finding new potential requirements while evaluating products, this suggests your requirements list is incomplete.  On the other hand, if you find very few new potential requirements while evaluating products, you know your requirements list is comprehensive (at least in the area of business and technical requirements).

The next step is to rate requirements for importance, e.g. using a numerical scale of 0-5 with 5 being the most important. When you rate requirements for importance, be sure to record who the requirement is important to, and why. Rating the requirements creates a Requirements Profile, which is unique to every organization. The key to successful software selection is evaluating software products against this organization specific requirements profile.

Once requirements are rated, those requirements of lesser importance are usually filtered out. To reduce the work in an evaluation project, the evaluation focuses only on those requirements that really matter to the organization.

You can manage small requirement collections with a spreadsheet, but be aware that spreadsheets do not scale. Once you start going over a few hundred requirements, spreadsheets get very difficult to work with, and errors creep in. Software selection projects like ERP sometimes have as many as ten thousand requirements. For these larger evaluations, you need some sort of Requirements Management System. While purchasing requirements and software development requirements are similar on the surface, they have a very different emphasis. Thus, requirements management designed for software development is unlikely to satisfy your purchasing needs. Make sure that any Requirements Management System (RMS) includes most of the following:

  • For a web based RMS, you should be able to create an account that you can use over several months. This is because enterprise software evaluation projects usually take months to complete. Those web sites that promise to give you the answer in an afternoon just by filling out lots of checkboxes or tweaking sliders do little more than give you an idea of where to start.
  • Large evaluations are a team effort, and multiple people should be able to log in to the RMS to collaborate on the evaluation.
  • Even though pre-selected requirements can help tremendously, the RMS must have the ability to allow you to add your own specific requirements.
  • Large evaluations like ERP can approach ten thousand requirements. The RMS should be able to handle at an unlimited number of requirements.
  • The RMS should have the ability to record all the fields listed above in "The anatomy of a good requirement".
  • The RMS should have a way to filter out requirements of lesser importance. You do not want to waste time evaluating products against requirements that don’t mean very much.
  • The RMS should have a way to group related requirements in some form of hierarchy, and a way to weight those groups. Some groups, like security, are just more important than other groups.
  • Some requirements really do belong in multiple groups, and the RMS should allow this. If one requirement is in multiple groups, you only need evaluate products against the requirement once, not once per group as happens with spreadsheets.

Wrap Up

This article describes a simple methodology that can guarantee a comprehensive set of requirements for selecting enterprise software. In particular, the technique of reverse engineering product features helps find requirements that other approaches may have missed.

Don’t be put off by the fact that it can take months to develop requirements for large enterprise projects like ERP. A thorough requirements analysis helps avoid situations like the US Air Force wasting $1 billion on the wrong software. Following the techniques described in this article will lay the foundations for a successful enterprise software selection project. This can take your organization to the next level, and even enhance your own career.

Photo Credit: Rafal Olechowski/Shutterstock

Chris Doig is the CEO and cofounder of Wayferry, a company that has developed a purchasing decision support system to help enterprise buyers select the best software for their specific needs. For more information, please visit wayferry.com

© 1998-2014 BetaNews, Inc. All Rights Reserved. Privacy Policy.