Author: Joy Beatty

If you know ahead of time that your organization will be purchasing rather than building software, how can you use high-level requirements to ensure good outcomes? And how does the requirements process for purchased software differ from that of a standard development project?

The key difference in a supplier selection process: you are buying functionality that already exists. While you will likely customize and configure the software, that customization is not necessarily going to yield exactly the same end result as if you developed the software internally.

Given that difference, it makes sense to gather high-level requirements to short-list vendors, and select the winning supplier using that level of detail. You can then work with the supplier to specify the detailed requirements necessary to configure and implement the supplier solution, integrate it to existing systems and custom build any missing functionality.

Inherently, you will be forced to really focus on the core requirements and leave design out of the picture while you choose the supplier. Once you have selected a supplier, you will find it very challenging to speak about requirements without talking about the design of the solution you selected.

As you compare supplier software, you will probably have to make some tough decisions. For example, let’s say you have four features. One supplier may support features one through three. Another supplier supports features two through four. A decision maker on the project has to weigh all of the factors to make a choice, including (but not limited to) factors like: cost to buy and implement each solution, price to build the missing feature in each case, cost of not having one of the features, and time to implement.

Without scoping high-level requirements, you could be well into evaluation when end users or others decide that feature four wasn’t really a requirement after all!

Step-by-Step Approach to Selecting a Supplier

We use the following process to select our suppliers and minimize throwaway work:

1. Define the high-level requirements. This may take the form of named use cases or features.
2. Define the actors that will use the functionality.
3. Specify more detailed requirements based on the highest risk areas.
4. Research the marketplace to identify a list of potential suppliers. This can be done by surveying SMEs, doing web research or and/or speaking with peers, colleagues, and trusted advisors.
5. Narrow the list of suppliers down to the top three to five, based on how closely they match the requirements gathered.
6. Have the suppliers do high-level demos of the solution. Eliminate any that do not seem to be a fit at this point.
7. Create test cases using the requirements gathered to sufficiently demonstrate how each supplier measures against the requirements.
8. Have the suplliers demonstrate how their solution satisfies the detailed requirements, measured by execution of the test cases.
9. Create a comparison matrix with each test case (and all other measurement criteria you care about) to directly compare the suppliers.
10. Gather information from the supplier beyond just the functional capabilities.
    1. Gather pricing data – licenses, support, installation, training, etc.
    2. Ensure the supplier’s business operations are acceptable
    3. Determine if their support structure is acceptable
    4. Understand what their development roadmap looks like
    5. Perform reference checks with colleague
11. Decision maker chooses a supplier.

Once a supplier is selected, the detailed requirements gathering process should continue. Your detailed requirements should be focused on the scope dictated by the supplier you selected. In standard development projects you would expect to go into more detail on most areas of the system, to ensure you understood the requirements to build a complete solution. In supplier selection projects, however, there will likely be pieces of functionality they demonstrate to you, and, based on high-level requirements and risk, you realize their solution is sufficient and do not need to explore it further.

If there is an area in which there is a lot of flexibility in the supplier solution, you should specify that in more detail. Obviously if there is a gap between critical requirements and the solution the supplier provides, you should go into greater depth on those requirements. Points of integration should be explored in detail. It is worth noting that you will typically spend more time updating existing processes to work with the supplier solution, whereas in standard software development you may build software that fits into existing processes.

Don’t forget to leave your comments below.