How to know when you have all the requirements to properly select enterprise software

Spiraling costs and implementation delays are major problems when buying new cloud or commercial off-the-shelf (COTS) enterprise software. One of the biggest causes of these problems is discovering new requirements during the implementation phase of the project.

We’ve examined why it is worth taking the effort to discover those requirements up front during the analysis phase of the project. Now we’ll look at how you can know when you have all your requirements.

One of the first steps taken before writing software is to collect requirements. Functional requirements, i.e. what the software should do come mainly from asking users and business process analysis. There are other kinds of requirements like technical, security etc., but we are not concerned with those here.

In an ideal world, business analysts interview users to document the requirements. Since most users don’t really know their requirements other than their immediate pain points, business process analysis fills in the gaps. The specification is then handed over to the developers. Once users start thinking about new software, they are famous for dreaming up new requirements. This is called scope creep, and it makes estimating and managing software development very difficult. Unfortunately, there is no way you can KNOW when you have all the requirements for a software development project. There are always the “unknown unknowns”.

While requirements for purchasing software are superficially similar to those for coding, they tend to be simpler because, for example, there is little need to do process analysis. When considering a new enterprise application, it is usually better to start with a software evaluation, and only proceed to coding if you don’t find anything suitable. Under those circumstances, the purchasing requirements can be enhanced for coding, so the effort of creating them certainly isn’t wasted.

However, there is one huge difference between requirements for coding & those for buying software, namely that you can know all the requirements when buying. The reason is that when buying, you are limited to requirements that can be satisfied by the features of the software products you are considering. You don’t need to consider other requirements because they won’t be satisfied by any of the potential products. If users want a feature that is not present in the range of products being considered, that will not affect which product is selected (although, depending on their importance, new requirements could cause new products to be added to the list, or the project to be abandoned).

The process of getting requirements from potential products is that of reverse engineering features back into requirements (basically running software development in reverse.) A finite number of potential software products have a finite number of features, and there are a finite number of requirements that could be satisfied by those features. Although it is possible to capture all requirements, in practice time constraints usually mean taking a risk-based approach. The advantages of developing requirements using the reverse engineering technique are:

1. Minimize scope creep. When users are asked how important requirements are to them, their focus stays on the requirements at hand. You don’t give their imaginations free reign to dream up new requirements, and you keep the scope under control.
2. Find unknown requirements. When the users are looking at a list of requirements derived from features, they are forced to consider things they would otherwise have missed. This is how unknown requirements, i.e. requirements the users don’t know they need, are uncovered.
3. Speed. Users have little idea of what they want, but if presented with a framework in the form of a list of requirements they can very quickly say how important those requirements are to them. Starting with a list is a far faster and more thorough way to develop the requirements profile than simply by asking users what they want.
4. User buy-in. For every requirement rated for importance the user’s name is captured along with how important the requirement is, and why it is important. When users see this, they feel they are part of the software selection process and this builds buy-in which helps ensure the ultimate success of the software rollout.

To conclude, developing a list of requirements by reverse engineering them from the features of potential products allows you to identify all requirements, even unknown ones. When you have identified multiple potential products and reverse engineered all features into requirements, you have captured all requirements. This can even be tested: if research unearths another possible product, and the reverse engineering technique yields no new requirements, this confirms that all requirements have indeed been captured.

Capturing all requirements up front minimizes the risk of new requirements appearing during the implementation phase of the project, causing delays and cost increases.