There’s been a lot written about software requirements gathering as a component of the software development life cycle. Proper requirements are critical to being able to build the right piece of software for the right cost on the right schedule.

But what about software that you are going to buy? Does gathering requirements still make sense?

Requirements gathering still has a significant role to play when a company is considering purchasing software. However, it’s interesting to look at some of the differences between requirements being gathered in support of a software purchase vs requirements being gathered in support of building software.

Let’s look at some of the key differences in the context of a non-software company that is looking to deploy a large, complicated piece of software to run a factory.

1. The software “life cycle” is different.

Traditional software life cycle might look like:

Requirements -> Development -> Testing

…with possible iterations depending on what model you are using.

When you are buying a piece of software, the life cycle looks more like:

Requirements -> Evaluation -> Purchasing Decision

In this case, the evaluation is similar to, but not identical to the testing phase of a more traditional software development effort. In a traditional software development effort, testing is done to ensure 100% compliance with requirements. In the evaluation phase, tests are used to evaluate the degree to which a piece of software meets your needs.

Note that some software purchasing will require software development in order to cross gaps left by purchased software. I don’t want to discuss this case here, since that only adds a traditional software development cycle to the end of the purchasing decision.

2. You probably won’t get exactly what you want.

Unlike software that you are developing or having developed, a commercial piece of software probably won’t meet all of your needs, because it wasn’t developed using your requirements. This means that you’ll be faced with trade-offs in making a decision between different software suppliers.

3. Prioritization becomes much more important.

In order to make a sensible analysis of the trade-offs between suppliers, you need to have a much clearer understanding of how your requirements are prioritized. You’ll need to clearly delineate not only which requirements absolutely must be met, but also the relative weightings of requirements that aren’t as important to you. The traditional “high”, “medium” and “low” prioritizations may no longer be sufficient.

4. Cost may not relate to complexity

In traditional cost analysis of requirements, you analyze the requirements, run the requirements by your developers to make an estimate of the cost based on complexity, and determine the feasibility of the requirement based on its cost. If you are analyzing requirements for a piece of software being purchased, the cost comes from the supplier, not from the complexity of the requirement.

5. It is possible to over specify the requirements

At some point in any requirements gathering process, you reach a point of diminishing returns (fewer real requirements gathered per time spent). In gathering requirements for a piece of software you are purchasing, it’s likely that you’ll hit this point earlier than you would if you were gathering requirements for building software. Since the supplier software wasn’t built to your requirements, getting more detailed requirements won’t necessarily improve your ability to get the piece of software you want. Detailed requirements may still be important for performing gap analysis with a potential software purchase, but the value of that gap analysis should be weighed into the decision on when to stop gathering requirements.