Requirements are constraints on the creativity of creative people. That sounds harsh, but it is true. Business owners and those that finance software projects don’t want just any system built – they want their system built. This means they have some preconceived notion on what the system has to do and, in many cases, how it does it.
The question then arises, how severe should the constraints be? How much interpretation should be left in the requirements for the developers and interface designers?
It depends.
An opinion I often see expressed is that you should specify the bare minimum of ‘design’ in the requirements. While I agree that this is true in a perfect world, it isn’t always possible given time and resource constraints.
Two approaches to specification are described by the diagram to the right. One approach, designated by the blue arrows, says that you should try and discover all of the true ‘requirements’ of the business. This will lead to a confined space wherein several different designs meet all of the requirements. Any of these designs, represented by the orange and green dots, will be acceptable to the users.
The benefit to this approach is that you are 100% sure your solution falls within the bounds of the business needs and it allows the creative team members to come up with some truly novel solutions in the software. This works extremely well when the problem is well-known but the solution is not understood well by the business.
The drawback to this approach is that it can take a great deal of time and effort. If even one requirement is missed, some aspect of the design may not satisfy the unspoken needs of the users and may therefore be unacceptable.
Another approach says that if the business knows what they want, you should capture that and describe it as well as you can. This is represented by the dots in the middle of the diagram. In this approach, the business knows their problem and they know how they’d like to solve it. This leads to a very detailed specification on what exactly the software will look like and do. You may not get the perfect design (represented by the orange dot), but you’ll probably get close (green dot).
The benefit here is that your specification will provide the users with a very clear understanding of the system and can provide a great deal of comfort to those that are footing the bill. Everyone can agree and sign off on something that gives a very clear picture of the future system. It also takes less time to describe a solution in this way.
The drawback here is that users often know what they want but don’t understand what they really need. By specifying the system in this way, you limit the creative choices available to the designers and developers and you may miss the mark completely (yellow dot) and produce something that doesn’t meet the requirements.
When do you use each of these approaches? They both have some utility. It all boils down to margin of error. If your margin of error is at or close to zero, there is probably only one design that will meet all of the requirements and your only safe bet is to use the first method to define the solution space. The interface designers can then have total latitude to design the software the way they see fit.
If, on the other hand, the solution space is quite large (e.g., users don’t really care that much about the implementation, they just want the broad functionality to be present), it can be much more efficient to use the second method and describe the system in as much detail as possible so it can be agreed upon before development begins. In this case, there really is no need for a dedicated design resource. Putting dollars into that effort is overkill.
So, what’s my opinion on who should ‘design’ the software? The answer is, as with almost anything else in the real world –
It depends.
