Use reverse engineering to help users set requirements for big software purchases

When buying enterprise software, conventional wisdom says that users are the ultimate source of functional requirements. While this seems logical, it is incomplete because, apart from their pain points, few users know what they want from the software. The question is why does this happen and what can you do about it?

Why users can’t articulate their requirements

While every software selection should start with user interviews, because this builds rapport, most users only know the pain points of their existing software. Users focus on their jobs, and their software is a tool to get that job done. They know what doesn’t work well, what takes too many steps, everything that makes their work life more difficult. The context of their jobs prevents them from articulating requirements too far removed from their current pains.

They may be working extra hours to overcome the limitations of current software and don’t have much time to look at alternatives. Few users are aware of what is on the market and how it could make their lives easier. Users also tend to specify the ability to replicate existing processes as requirements when, in reality, those processes may be far from optimized.

Sometimes a user will have been in several companies over the course of a few years, and will know the software those companies use. Given the rate of change in the software market, experience that’s more than three years old is likely to be of limited value. Also, the fact that a certain software product worked well at one company doesn’t mean it will work well at another company.

If a company has outgrown its existing software and users only have a rudimentary idea of their requirements, how do you find the requirements to select new software? How do you find requirements you don’t know you need? Too many missed requirements can mean software that doesn’t meet expectations, and that leads to all sorts of pains for the organization.

How to develop requirements

Requirements are satisfied by features of software products. The goal of a software evaluation is to identify all significant requirements and then to find the product that best matches those requirements. A requirement not satisfied by a feature in any potential product will not influence the software selection in any way, although it could cause the project to be abandoned in rare cases.

Think about the converse for a moment: The features of potential products adequately describe the requirements for that particular type of software. Thus, if you rewrite the features of multiple software products as requirements, you can gather all the requirements for a particular software purchase. This is essentially running the software development process backward; it’s called reverse engineering.

A key benefit of the reverse-engineering process is that it identifies requirements you don’t know you need. For example, several years ago a civil engineering client was considering new project management software. Some of the potential products allowed users in the field to access project plans via a smartphone. At the time, this was a relatively new feature, something they had never considered — but it was appealing enough to change the outcome of the software selection.

Reverse-engineering features from multiple potential products into requirements is a systematic way to develop a comprehensive list of functional requirements, including unknown requirements. Be aware that this is a slow process. For example, on average it takes about 10 to 15 minutes to capture a well-written requirement from a feature. When you consider that a typical enterprise software project can have thousands of requirements, this can add up to hundreds of hours of work. Remember, it’s far better to capture too many requirements up front than to discover “new” requirements during implementation where they cause delays and excessive costs.

User contribution

Reverse engineering is a way to build a comprehensive requirements list without input from users. What, then, do users contribute to the process? A comprehensive list of requirements is only halfway there. You need to know how important those requirements are to the organization, and that is the critical information provided by the users. While users may not know their requirements, when faced with a list they can usually tell you how important each requirement is to them.

If user teams have limited experience, bring in consultants with the relevant experience for that type of software. Subject matter experts help users think through the issues by asking questions like “Have you considered the case of…”

For each requirement, users say who wants it, why they want it and how important it is to them. When users see their information being captured on individual requirements, they feel the organization is listening to them. This builds a tremendous sense of buy-in, which is essential to a successful production rollout of the new software.

Wrapping up

Use the reverse-engineering process to develop a comprehensive list of requirements. Users then tell you how important those requirements are to their jobs, and this creates a requirements profile unique to the organization. While functional requirements are concerned with specific behaviors of the software, remember that you also need nonfunctional requirements like legal, license, security, vendor due diligence, support, etc.

Use this requirements profile to generate the RFI or RFP, and then evaluate vendor responses against it with a gap analysis. That allows you to measure how well the products meet your requirements. If none of the potential products score well enough, adjust the scope of the project. You don’t want to buy a product that does everything but isn’t particularly good at anything.

Follow this process to measure how well competing software products meet your needs. Selecting the software that best fits your particular needs is a critical step to maximizing the ROI of a major software investment.