Tips for Developing Software Requirements

View Our Posts

It seems so simple: Pick the right ERP, implement and all your business problems will be solved. But all too often this turns into a software disaster. The question is why, and what can be done about it?

There are several places where people run into trouble selecting and implementing enterprise software such as ERP. This article focuses on building the requirements profile.

The first mistake people make is skimping on requirements. How do you know when you have identified the right software product? That answer comes straight from your requirements, which is why it is so important to define them properly. You could say that requirements are to software selection as foundations are to a building: If you don’t get them right there will be problems.

Reading software reviews is an excellent place to start, but bear in mind that when somebody reviews a product, it is being evaluated against their requirements not yours. Likewise, selecting software because somebody else uses it does not mean it will work for you, simply because their requirements are never going to be the same as yours. And if they are your competitor, they are hardly likely to tell you all the problems they have with the software.

Everybody in your industry will have similar requirements, but your particular mix of requirements will be unique to you. That can be called your “Requirements Profile”. Those requirements are the standard you measure against when evaluating software.

The next mistake people make is not defining requirements properly. Every requirement has at least five parts:

  1. A unique NAME that concisely labels the requirement.
  2. A short DESCRIPTION that amplifies the name and removes ambiguity. This avoids the problem where later even the author of the requirement is not quite sure what they meant.
  3. A measure of how IMPORTANT the requirement is. This is used with a scoring system to measure how well products meet you requirements.
  4. A list of WHO the requirement is important to. This is used when a requirement needs modifying or clarification, which often happens in the evaluation phase.
  5. The reason WHY the requirement is important to them, which provides the context when evaluating products against that requirement.

Where a requirement comes from does not matter, what matters is that the requirements adequately define your specific needs. Assembling a requirements list is a lot of work and there are several ways to do this. Most people will start with Google searches, but you seldom find good quality requirements that way. Possibly the fastest is to buy requirements from vendors or consultants, but you have to watch out for the quality of the list. The most thorough way is to reverse engineer requirements from the features of potential products. This has the advantage of identifying requirements you didn’t know you needed, and of capturing the latest innovations on the market. To avoid biases it is a good idea to build your requirements list using all of these methods. Depending on the size of the ERP project and how much detail you go into, your list can be anything from two to ten thousand requirements.

The next step is to rate requirements for importance to your organization. This is where the larger team provides their input. You will need a scale, e.g. 0 – 6. It is a good idea to associate words with the scale, e.g.

“3 – Important. Without this feature there is some noticeable inconvenience but that can be worked around with some effort.”

You will sit down with teams from finance, production, purchasing etc. and rate requirements for importance with those groups. For each meeting, give team members a sheet that lists all the requirements importance values, and what each value means. This ensures all people rate requirements from the same scale and are consistent. There are a number of advantages to this process:

  1. Requirements are already defined so the process is far faster than if the team had to come up with the requirements from scratch.
  2. Your list will force team members to properly think through requirements, and consider things they would never normally bother with.
  3. As you rate requirements, you can regularly update the team on progress, e.g. 55% of requirements are rated. This helps develop a sense of momentum with the project.

Once your team has rated all requirements you will have developed a Requirements Profile that accurately defines what matters to your organization. Now you have a yardstick against which you can measure how well potential software products meet your specific needs.

Adequate requirements are the secret to picking the right ERP product. Make no mistake; defining them is a lot of work. But when you pick the product that fits your organization like a hand fits a glove, the ROI can significantly exceed expectations.

Chris DoigChris Doig is the CEO and cofounder of Wayferry. With a unique web based application, Wayferry helps buyers evaluate enterprise software, and identify the best possible match for their specific needs. For more information, please visit

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Show Buttons
Hide Buttons