Setting Software Requirements

Recently, a company came to me for advice after having spent several hundred thousand dollars on a made to order software system. A system which was several hundred thousand dollars more than they had originally been quoted and had taken two years of frustrating trial and error to complete. Sound familiar? What went wrong in this situation and how can you avoid it?

Well, like all “I wish we hadn’t done that” stories in business, there are a number of contributing factors, each of which teaches us a useful lesson in buying software. Today we’re going to focus on the first lesson: Setting Software Requirements – Be Specific.

The company’s issue was the User Requirements, on which the contract was based, read like a sales brochure rather than a detailed and clear description of the specific requirement needed to accomplish the objective.

What do I mean by sales brochure?

1. The User Requirements Specification described how the software looked, rather than what it enabled the user to do.

For Example:
It said -“The ….. entry screen has drop-down list for … and …”
It should have said “The user shall be able to enter …. and … information from a controlled list of options.”

You don’t tell your mechanic how to fix your car, so don’t tell your software vendor how to solve your business needs. That’s their job!

Hold them accountable to give you the capability you need.

Rule of thumb: if you are describing the software rather than what someone can do with the software, you are getting it wrong. If the words “Shall” or “Must” don’t appear in the sentence, you are not specifying clearly enough for the software vendor to solve your issue.


2. It was almost impossible to measure whether any of the specifications had been met.


Using the previous example: once the “….. entry screen” existed and had some drop-down lists on it, how could the client hold the vendor accountable for anything else?

If it took 10 mouse clicks to get to the screen, 2 minutes to get it to load and the data was not always saved correctly, the “requirement” had still been met. When setting software requirements, think of how you set “SMART” objectives for your employees — Specific, Measurable, Achievable, Relevant and Time-bound. Do the same for your software vendor, but at this stage leave out the “Achievable”: your job is to communicate what your business needs are, it’s their job to say if they can help you achieve it. If they cannot, then maybe someone else can, or maybe you compromise. But ask for what you need first — see my previous post on How Does Your Business Work?


3. Finally, Number your requirements! Separately!

Sounds obvious, but the easiest way to make your vendor accountable is by taking your narrative of what you want the system to do and breaking it down into numbered items.  This will produce a set of specific requirements that you can hold a vendor accountable to; assign value and importance to; test against; pass or fail against; and decide whether or not to pay against. Deciding whether you’ll pay or not is the only leverage you have: don’t throw it away!