Software Requirements Definition – Be Careful with "Boilerplate" Requirements

One of the ways that many organizations try to shortcut the requirements gathering process is by finding/buying a long list of requirements that they can use as a template for their software requirements. In fact, even many consultants develop boilerplate requirements that they just re-use with each client. While we feel this is a good place to start, there is danger with relying solely on these long requirements lists for your software evaluation.

We have seen organizations do this for 4 reasons: 1) they are looking to jump start the requirements gathering process to save time, 2) they are worried that they might miss a requirement, 3) they want to make sure that all of their bases are covered, 4) they want to have the ability to nail the vendor to the wall if they don’t deliver every requirement they say they can.

While these are valid reasons for using a long list of requirements, we urge caution because this approach can also drive your project awry. The following are the biggest dangers of approaching your requirements in this manner:

1. You develop a long list of requirements that is difficult to manage.
2. You end up including requirements that do not apply to your situation.
3. Vendors do not respond to your Request for Proposal/Information because the requirements document is too large.
4. You find it difficult to evaluate vendors because of the long vendor responses.
5. You lose sight of the most important requirements and can get bogged down in detailed requirements that are not important.
6. Software vendor lawsuits are not the goal of the software selection project. Plus, vendors find ways to “interpret” the written requirement to protect themselves.

We recently saw an organization create a long requirements document and as we were working with them to make sure the vendors could handle the functionality required, we asked why some of the requirements were included as they did not seem to apply to their situation. Their reply was that they were “boilerplate” requirements and they were not really interested in the identified requirements, but they hadn’t properly vetted the requirements to delete them. The result was that the vendor had to respond to a non-existent requirement, the client had to sift through these non-existent requirements and then they had to eliminate the unnecessary requirements for the contract. Because they did not develop a proper requirements document up front – more time was lost in the back end evaluation.

Make sure that your requirements document fits your organization. While lists of requirements can be helpful to start your requirements document, you need to carefully pore through the requirements, make sure they apply and are important to your organization. The work you do up front in the requirements process has a direct impact on the success of your software selection project. By concentrating on the most important criteria – you will not only focus on the criteria that are most important, but also save you a lot of work over the life of the project.