« Back to blog

Requirements

Every project is a result of a set of requirements. The success and the failure that project depends upon the extent to which those requirements are satisfied with the project. This is not another piece of literature that will tell you the importance of understanding a client's or consumer's requirements because it is important for the consumer. I am a coder, and i will like to, for a change, try and point out the issues a coder has if the requirements are not clearly defined. To be more explicit, i really do not care about how poor requirement analysis usually effects the consumer, i am more concerned about how it effects the coder, who is expected to transform those requirements to a finished product and machine. My point being, if the coder himself is unclear about the specs., then we have bigger concerns, bigger than the client. Live the consumer's World. - When a requirement analysis is being carried out, there should always be a certain degree of clarity between the one who is conveying the requirements, and the one trying to understand them. In an ideal world, the one who is trying to the understanding should also be able to convey those in their precise element, and also be a part of the coding fraternity. Also, there can never be a situation, when you are apprehensive about asking questions about a particular aspect about the requirements. It is always good to try and understand the purpose of what the client is trying to achieve with the final product. There is no point making assumptions based on what the client has told you. Remember, the client lives in that world, where the requirements exist, you do not. Live that world. Only then will you be able to truly see the intricacies of the problems you will face while actually developing the product, even before you get into the whole whirlpool of development. Avoid the Negative Trickle. - Information, like rations in India, suffers from the trickle down effect. When it starts from the source, it is rich and abundant. But, by the time it comes down to the individual who has to make sense out of it, and use it, there is hardly any left. The reason this is normal  is due to one simple thing: a lack of form in the information that is being generated at the source. Because, it is very abstract, and largely based on the consumer's experiences and not on a well thought off scheme of things, the information needs to be organized. And there is the loss of information begins. In the process of organization, we loose of several key elements, which might not seem important at the inception, but becomes important, as the project grows. We negate those elements, in the early phase of our project and thus, loose them for ever. Many come back to haunt us, many revive quietly. The idea should be to preserve everything. Do not loose any thing, even if it may seem to mean nothing to the project. See reason, not instructions. - In any team, there will always be someone telling someone else what to do. And since not everyone in a development team can meet the client, the "telling" will be more while trying to convey the requirements and hence the goals. In this whole process, one tends to take everything as an order or a blatant instruction, to be performed blindly. This is specifically true to coders. Don't do that. Listen to what your mentor has to say. Try and see the reason in the goals and requirements. What might seem right to you may not be so for the consumer. Adjust your thought accordingly. And until you are clear and confident of the fact that your understanding of the requirements are same as that of the client, don't stop asking questions. But the bigger thing is to always find the right reason behind your goals. Don't develop something blindly. Try looking at the Big Picture. The moment you start taking a holistic view to things, you understand the context of your work, which allows natural synchronization with the team that you are working with. When these things are not followed things get tough for a coder. He has no context for his work. His code is a result of an instruction from his superiors. And more often than not, he has little or no understanding of the requirements and ends up coming out with good code for the wrong place.