Requirements and Analysis

The customer on our project has their own software acceptance team. Recently they have been finding a lot of problems with our applications. A few recent problems got a lot of visibility. Some VIP from our company said we needed to fix these problems. My team lead called me up and asked if I had any extra time in my schedule. I just laughed.

In the end, my manager informed me I had to drop what I was doing and fix the problems. The first one was easy. I disregarded some of the information that had been collected so far on the problem. I honed into the specific facts that pointed to a certain module not working. There were some protests until I demonstrated that previous information about the problem was incorrect. Next I went to another problem. This second one had a lot of parts to it. The first two parts were easy. They were coding errors. I fixed them with little trouble. The last part was difficult.

Requirements were gathered on some changes to the system. A technical customer helped specify the requirements. Unfortunately he started getting into the design of the solution, and those specifics were documented as part of the design. We subsequently ignored this external design when we actually designed the system. The came back to bite us. The customer's test team validated our implementation based on the letter of the documented requirements (as they should be doing). The problem was that the system did not match those requirements. I thought this was no problem. We could just change the requirements to match the implemented design. This proved a lot harder than it sounds. More on that later.