Recently our customer informed us that one of our trouble tickets was very important to them. I let them know that I would have a developer assigned to work exclusively on this problem. This developer was able to duplicate the behavior that the users experienced. However the developer was not sure what the correct behavior of the application should be.I was monitoring the work on this task. And I immediately jumped in and send this to our Requirements Analysis Team. They are supposed to have all the business rules documented. The answer I got back from them was that the requirements do not state what the customer expects the software to do. So I had our developer communicate this to the customer.
The customer did some research and came back with a requirement number from the appendix of our requirements document. There indeed was a requirement that stated exactly what the customer was asking for. This was all we needed to charge forward and modify the code to match this requirement. Some people may question why this level of documented requirements is even needed. And for some instances it is not. However we often have various members of our customer organization with different ideas of how the software should be run. We also have some same individuals changing their minds based on who know what factors. This creates the need to capture requirements. Otherwise developers would not know what to do in any given situation.
It seems the only thing our team did wrong in the current scenario was not know the existing requirements well enough. If I were on the requirement team, I would know the rules inside and out. Having been on the project for a very long time, I actually do know what a lot of the requirement say. The customer is a long term one as well. They know what is required of the software better than most developers on my team. I guess this is what you would call a very educated customer. Sometimes this is a good thing.
