This past year our customer gave us a list of new feature they needed in the applications. I was initially not a part of gathering the requirements since I had not joined the company yet. However a requirements analysis team had produced a requirements document. There was one requirement that was suspiciously vague. I asked the requirements team a bunch of questions about what was needed. They could not answer any of the questions definitively.
The requirements team set up a conference call with the customer. I voiced my concerns that we did not understand one of the requirements at all. It was a dreaded one liner that did not mean anything to development. The customer quickly explained what they needed. I then tried to confirm my understanding. They concurred this is what they wanted. I then proceeded to design and implement a solution.
After we had delivered our changes to internal test, we scheduled a design review with the customer. I walked them through most of the design for the new changes. When we got to the design for the requirement that had previously been a mystery to me, the customer said we got it wrong. I said that I was sure we followed what we discussed at the conference call where we clarified the requirement. The customer was adamant that this was nothing like what they had previously discussed before I joined the project.
Once again we had to go back to the drawing board. This time around, I told the requirements team that we needed to write everything down in detail about the new requirements. And we needed to get the customer to agree in advance before we spend a lot of time in redesign and rewriting of the application. Another senior developer and myself worked closely with the requirements team. We thought up all kinds of questions that we then proceeded to hash out with the customer. That’s what requirements gathering and analysis are all about.
Currently we have a draft set of new requirements for this piece. Development is going to wait until these detailed requirements get customer sign off. Then we need to figure out how to schedule all these changes this late in the year before we go live in production. That story is one for a subsequent post.
Newbie Gets Confused
-
A relatively younger developer got tasked with doing some performance tests
on a lot of new code. First task was to get a lot of data ready for the new
c...