Yesterday a high priority problem was reported by our customer. My manager asked me to step in and work the problem because the responsible parties were out of the office. I have a good rapport with the customer. So I spoke to them and established expected software behavior.Then I got down to work querying the database. Turns out most of the problems were misunderstanding of how the software was supposed to work, or certain settings mean. However there were two issues that seemed like they might have been bugs.
I kicked some specific questions back to our requirements team. They are responsible for eliciting customer requirements, generating system requirements, and confirming requirements with the customer. The analyst I spoke with had to defer to a subject matter expect to get the answer. But in the end it turns out the software had some bugs.
So I identified the files and the functions in those files that were broken. Then I forwarded the details to the team that handles that portion of the application. When everybody came back to work the next day, I found out more information as to why these problems popped up in the first place. Apparently development had spoken to the customer and got direction to code up the software that way. In complex systems such as ours, where there are documented requirements and multiple levels of test, this informal requirements gathering just does not work.
Right now were are in the processing of putting together a fix for these problems. Since they are high priority, there is a lot of pressure for status updates around the clock. Somehow I think these problems could have been avoided altogether. But implementing a process to ensure this is much work. And it is pretty much too late now.
