The Mindset

Every now and then, I hear architects and designers arguing that they cannot do a real analysis of the requirements, because the customer does not know exactly what he needs. This is often a reason for keeping things vague in the design of the product, or avoiding delving into the details. More often than not, however, these details are the ones that cause the design to break later in the development process.

The fact is that in most cases, you cannot avoid making a decision forever. At some point, you will have to make your mind and choose a certain implementation path. The only question is when to do so.

If you come across a vague (or missing) requirement in your analysis process, you can either repress it using some abstract entity, or you can deal with the problem and try to find out what it is your customer needs. Choosing the first option will make your job easier for the short run, but you should remember: soon, someone (either you or a developer implementing your design) will have to deal with the problem. No matter how vague the requirements are, when implementing them, someone has to decide whether to do it one way or the other. When the product will be tested by your QC staff, they will come across this arbitrary implementation decision. When they will refer to the requirements, they will reveal that this might have been what the customer wanted, although cannot really be sure. Depending on how good your QC is, they will either let the arbitrary implementation pass or not. Finally, when the customer receives the product, you might just get a change request, suggesting that your guess does not match yout customer’s expectations.

Why go through this entire cycle? The alternative is much easier. When you come across a vague requirement (or any dilemma regarding the requirements for that matter), do what ever is needed to find out what your customer really wants (and needs). If your customer cannot answer your question, you may have to help him make up his mind. Try explaining your customer the alternatives and their implications; use simple a prototype or mock implementation to help him get a sense of what you are proposing. No matter how long it takes you to get a clear answer, it is bound to be more cost effective than trying to read your customer’s mind, guessing what he wants, and investing your valuable resources in implementing it based on your guess.

The requirements analysis, and the design of the product that follows, are the last acceptable chances to identify problems in the requirements and solve them in a cost-effective manner. As soon as you avoid such problems or take an arbitrary guess regarding your customer’s needs, you are gambling. The stakes are your time and human resources. From that point on, you are taking a chance that your work (and the work of your development team) will be in vain. This is a huge gamble when you are already working under a tight schedule and with fewer resources than you really need.