Requirements play a significant part in selecting a COTS (Commercial Off The Shelf) package. The requirements process for COTS selection is not the same as the requirements process for bespoke development. For COTS selection there is more emphasis on differentiation: identifying how your organization differs from other organizations, and identifying how the candidate COTS packages differ from each other.
If you want to select the most suitable COTS package for your business it is not enough to play golf with each of the sales representatives. While a round of golf may provide many useful insights, it is prudent to check the COTS package against a list of selection criteria. “Selection criteria” is just another phrase for “requirements”. The main difference is that selection criteria are often formulated as questions, whereas requirements are formulated as statements.
When running a project to select a suitable COTS package, one key concern is determining the right requirements (a.k.a. selection criteria) with the least effort. If you apply a typical requirements process, you may end up with too many requirements. Collecting large numbers of requirements that none of the available COTS packages support is inefficient and can undermine stakeholder acceptance. Collecting requirements that all the available COTS packages support may seem good but does not help achieve the project goal: to select a package.
Conversely, some key requirements for COTS selection are often ignored in the starting stages of a project. A prime example are interoperability requirements: which existing systems (hardware, software, processes) will the selected package have to interface with? To determine the level of suitability in this area you quite likely have to delve into details such as interface specifications, protocols, or hardware platforms. Put bluntly: your IT legacy could be one of the differentiators.
To avoid these pitfalls, the requirements manager must tailor the requirements process to focus on collecting those requirements that are key for package selection. What type of requirements would that be?
Assuming your list of candidate COTS packages contains relevant candidates, you don’t have to spend much time or effort to verify basic functionality: those candidate COTS packages wouldn’t be on the list if they didn’t offer the basics. Focus instead on the following areas:
- What makes your organization different from other organizations using such packages?
- What do the candidate packages have to offer? Knowing this means you don’t spend too much time talking about fancy features you’ll never get.
- What are the main differences between the packages, and which of these differences matter to you?
This focus on differentiating requirements is not just an issue for the requirements manager and his team. It is crucial that all stakeholders are aware of this focus, to ensure their contribution is focused too. You should still expect to collect some off-topic requirements, but significantly less than without this explicit focus. And it helps greatly with expectation management.
In summary: requirements for COTS package selection must focus on differentiation. What makes your business different? Which differences between candidate packages does your business care about? This does not mean you don’t need any other requirements, but you probably need less of them and they can be less detailed.