Requirement management is the essence of Project’s Success. In simple words, it means that most of the problems that the projects encounter could have been avoided from the very begining by making it very simple and to understand the Customer’s expectations from the respective projects. Very often we hear the story of changing requirements. I was going through a project review; I came to know that the requirements were changing very often. May be that is a truth. But when we hear the customer’s side of the story you often get a different perspective. Customer often thinks that development teams lack the domain understanding and the ability to interpret requirements. There is always a fine line between understanding of requirement and seeking clarifications from customers. When you come across a story of frequent change in requirements and many requests for pending clarifications, it is time to look at your requirement elicitation process.
There are different stake holders in the Project. They view the requirements differently. They all may be right in their respective perceptions but collectively going by their understanding of requirements one cannot deliver a project to meet all their understanding.It reminds me of a very famous story of “Six Blind Men and the Elephant”.
Once upon a time, there lived six blind men in a village. One day an elephant came to the village. They had no idea what an elephant is. They decided, “Even though we would not be able to see the elephant, let us go and feel the elephant by touching it”. Each of the blind men touched the elephant. Perceptions emerged about the elephant. Hey, the elephant is a pillar," said the first man who touched his leg. "Oh, no! It is like a rope," said the second man who touched the tail. "Oh, no! It is like a thick branch of a tree," said the third man who touched the trunk of the elephant. "It is like a big hand fan" said the fourth man who touched the ear of the elephant. "It is like a huge wall," said the fifth man who touched the belly of the elephant. "It is like a solid pipe," Said the sixth man who touched the tusk of the elephant.
I think requirement process is very similar to the process of six blind men feeling the elephant. The designer, the developer, the tester and the user perceive the requirement differently. They are touching the requirements at a different point of time. They carry different perceptions and often get into a conflict about the requirement. Think of the situation where the six blind men had reconciled their respective observations. Obviously, a holistic picture about the elephant could have emerged.
Therefore it helps if different stakeholders sit together after their initial feel, reconcile their understanding and then come up with a unified view of the requirement. A simple three step process may be very useful in rationalizing requirements:
1. Every Stakeholder studies the requirement separately. They are Designer, Developer, Analyst, Tester etc
2. They come with their findings and questions and sit and discuss their understanding. Reconcile them and finally put a unified understanding to the customer.
3. Customer validates and rationalize the requirements.
These simple steps can avoid a confusion which crops in at a later state. Although these steps are simple and do not require great processes, we rarely implement them. These steps can be implemented in different flavor across different development methodologies.
These are Simple fundamentals but it works.
Subscribe to:
Post Comments (Atom)
Hi Bishram,
ReplyDeleteI have some thing to add here for a better requirement gathering process where you have less errors at later stages. Include a testing guy to your requirement gathering team. As far as possible he should participate in all the requirement gathering workshops or interviews. Then he takes the requirements in parts from the Requirement team to validate testability of every requirement and creates relevant test cases. This will help identify gaps at very early stage of requirement phase. The tester brings a different perspective to each line item in the requirement. The doubts brought out by the tester can be clarified from customer at the right time. Customer and the development team, both benefit from this exercise. It would help avoid the wrong interpretation of a requirement during development that leads to a defect. It is worth investing in a testing team member in the start of the project for which the ROI is much more, unbelievably high.
Regards
Banshidhar Rayaguru
rayaguru@yahoo.com