The customer wanted some data in our system fixed. A prior bug fix did not resolve the underlying data corruption caused by the bug. They were demanding this be resolve as our top priority.
I got called in because I know the system well. We had a meeting where the customer told us the requirements. People get nervous when things like this are just rattled off. So a manager recommended we document the requirements as we heard them.
After a while I called up the manager to ask who was going to write up that documentation, and whether it was going to be a team effort. Good thing I called. He said he wanted me to do it. Better to hear about this when I called than as a surprise at the last minute.
Luckily I was fully engaged with the customer when we went through the requirements clarification. I put together the flow of how our data correction script would run. I added all the details so that somebody familiar with the system would know exactly what we were doing. Got a tech guy to peer review the work. Then a manager added section titles. This document was becoming a good looking thing.
Today we had our first set of meetings with the customer. This one was only with our sponsor to get the game plan for discussing the document with the end user. Our sponsor was very pleased with the document. It read easily. And it captured all the details of what we talked about during our requirements gathering. I was very proud of this document.
Backtrack Linux - Backtrack is a Linux distribution based off Ubuntu. It is used for penetration testing and forensics. The distro was a combination of WHAX and Auditor. It...