Why reverse engineering is a powerful requirements gathering technique

We like to say that requirements are to enterprise software selection as foundations are to a building. Mostly out of sight, but very necessary. Get them wrong and there will be problems. Every time. When the software disasters that so regularly appear in the IT press are examined, almost without exception inadequate requirements were a significant contributor to the problem. Bear in mind that those cases appearing in the press are only the tip of the iceberg. Most cases, especially the smaller ones or the partial failures where the promised ROI never comes close to being realized, are never reported.

A thorough enterprise software evaluation is more difficult and more work than most people realize. Surprisingly, few organizations have a robust evaluation methodology. When evaluation projects run into difficulty or run out of time, shortcuts are taken and it is all downhill from there.

So let’s start by defining an adequate list of requirements that comprehensively covers all aspects of the problem area, and where those requirements are rated for importance to the organization. We call this the requirements profile.

This raises the question: How is an adequate list of requirements developed? The reigning belief is that users should be asked what they want, but the problem is they don’t know the answers. Most users have limited perspectives, and apart from their pain points have little idea of what is needed. However, don’t get me wrong. It is very important to start with the users, and for the evaluation team to create a rapport with them. Just don’t expect too much in the way of requirements.

One surprising thing we discovered is that for any given software type, most organizations have essentially the same requirements. It is the relative importance of those requirements that makes each organization unique. This means that requirements can be gathered from any source, for example by searching the Web, purchasing lists, asking vendors etc. However, the most powerful technique of all is to reverse engineer requirements from the features of potential software products. The idea is to examine the user documentation; demo videos etc. for product features, and then rewrite those features as requirements. Done thoroughly across multiple software products this captures all requirements in a problem space. Most importantly, it captures unknown requirements and the latest innovations on the market.

Since enterprise software requirements are similar across organizations, libraries of common requirements can be assembled. These would be used across multiple evaluation projects, saving significant time. Typically these libraries lean towards non-functional requirements, for example security, usability, training, contractual, vendor due diligence etc.

Some people argue requirements should be tied to processes. That is true if software is being written, but when purchasing off the shelf enterprise software this is an unnecessary level of detail. The processes are already built into the software, or can be configured. What is needed is a list of requirements where related requirements are grouped together. Then you ask the owners of those processes how important the requirements are to them.

When gathering requirements for writing software, you can never be sure you have them all. However, when gathering requirements for purchasing commercial off the shelf software you can, in principle. The reason is this: a finite list of potential software products has a finite list of features that can be reverse engineered into requirements. Requirements that are not satisfied by any software products being considered (i.e. requirements not found by reverse engineering features) will not affect the software selection, although they may change a project’s scope or stop it from going ahead. When all potential software products have been examined and no significant new features remain to reverse engineer into requirements, then you have gathered all requirements for that particular evaluation. The next step is to meet with users and have them rate the requirements for importance.

Reverse engineering product features into requirements allows you to build a comprehensive requirements profile, which is the foundation for a successful software evaluation. This requirements profile is unique to an organization, and is the basis against which potential software products are evaluated. It is also used when implementing the software, that will be the subject of a future post.