Bus Conductor: Ticket, please.
You: Give me a ticket?
Bus Conductor: Where do you want to go?
You: Isn't necessary to board a bus knowing the destination?
Bus Conductor: Hey.. are you a crack?
In previous part of the series of article on "Becoming a better Programmer", we discussed the basic steps of software development. In this part, we are going to discuss on "Understanding the problem". This is very critical for the successful completion of the software. Not knowing what needs to be done is something like boarding a bus without knowing where go. If you like to travel aimlessly, you will have to waste your time/effort and end up nowhere. Understanding the problem is nothing but knowing what the users of the software want. Before evening solving the problem, you have to know the problem. Understanding the problem is known as "Requirement Analysis".
The requirement analysis typically consists of two phases - requirements collection/gathering and analyzing the requirements. In the requirements collection/gathering phase, you will typically sit with the users of the application and know what the requirements are. To put it simply it is something like "Write a program to identify whether the given string is palindrome or not, without using buffer (additional memory)". In this example, there are two requirements given to you. First one is "Writing a program to check whether the string is palindrome or not" and the second requirement is "without using any additional buffer/memory". With this problem statement, what would be your score when you understand the problem partially. Let us say that you have written a program that works perfectly fine but you have neglected the requirement "without using buffer". May be, you will lose 25% of your score (if your examiner happen to be so liberal). So the requirement collection plays a very critical role in the successful completion of any software. In the case of lab exercise, the requirements will be so explicit and given by the examiner. But in the software development the onus of collecting the requirements lies with the development team. So, the capability of understanding the problem and collecting it properly is a much needed skill. When you have that skill, the other things come to you automatically.
After collecting the requirements, you need to analyze the requirements, find out whether the requirements are feasible, prioritize the requirements and redefine requirements if they are not clear. For example, if you are an astute developer, you will ask probing questions to understand the requirements. Considering our "Palindrome" example, you could ask the examiner that whether giving input through command line (argc, argv stuff) is one of the requirements. If that is one of the requirements, you need to redefine the requirement of getting the input from the users. The second phase is all about logically reasoning and problem solving skills which are must to complete the first stage "Understanding the problem" or "Requirement Analysis" successfully.
This is very simplistic way to tell you about "Requirements Analysis". At this point of time, it is sufficient to know that "Requirement analysis" or "Understanding the problem" plays a vital role in Software Development and it has to be done with due care. If you imbibe that, you have passed the first step and rest of the other steps will come to you automatically.
As an end note, please note that the requirements can be of few subtypes such as "Functional Requirements" which tells how the software should work or should not work, "Performance Requirements" which tells the maximum resources that can be used to achieve the functionality etc. If you correlate with "Palindrome" example, you can say "Checking for palindrome" is functional requirement and "without using any additional buffer" is performance requirement. These are details and will come naturally to you as you move along. So, please pay due care when you do your lab exercise or mini-project or your final year project.
Exercise
Take out any of your lab exercise such as PALINDROME or FACTORIAL, do the requirement gathering and analysis of the requirements. Ensure that you ask so many questions to understand how Palindrome/Factorial has to be developed. Write down the requirements that are related to functionality and requirements related to performance.
