Requirements Gathering and Assumptions

Those of us with experience gathering software requirements from a customer/client, then translating that to a design and a finished product, know full well how important it is to gather and define requirements carefully. The requirements dictated by a customer/client translate directly to how you design the user interface, the underlying data structures, and the database tables. When requirements are misunderstood, or even changed, the effect on your design could be anywhere from mostly harmless to entirely harmful. On the painful end of the spectrum, this leads to redesigns which cost time and money now, or hacks of your original design which costs time and money later in maintenance and upgrading.

During a recent project, I was asked/expected to begin development of a project prior to getting the full requirements. We had partial requirements, and I wrongly assumed that the requirements-to-be-named-later would be follow the same model/outline of these early requirements. So, resting on that assumption, I felt it was safe to go ahead and do this.

What I didn't do was communicate to the customer that I was expecting the next set of requirements to follow the same model of the previous requirements. I just assumed this is what we agreed on, so I didn't make clear that my design now depended upon that fact (which was only a fact in my eyes - so that makes it an assumption). Ouch.

As the later requirements rolled in, they were (of course) not like the earlier requirements. My design was cracking. Hacks were being added. The logical placement and design of code was getting looser. I cringed the whole time, but in the face of a deadline, had to keep going. No time for a redesign at that point. I lost time figuring out the hacks, and developers later will lose time understanding what is needed to modify the code and debugging it. But a redesign would've cost more time, and there would be no guarantee that more requirements would make further alterations necessary. So hacking it was.

It's not the customer's fault. The customer isn't the one experienced in the software process. The customer doesn't know that I'm making that assumption - he or she doesn't have the software knowledge to know that these details matter. I find that mostly, for non-software professionals, it's all kind of mysterious. A black box, really.

The lesson here is the assumption. I didn't recognize it, and it cost me. I've written customer quotes before with a full page of assumptions written right into the quote, but this unfortunately did not happen this time. One question to ask yourself as you are designing software is, "what assumptions am I making about the requirements?". Had I asked myself this question, I may have realized that I assumed all requirements would follow the same model, then confirmed that with the customer before finishing the design and writing the code.

There's plenty of research out there on how much time and money mistakes cost depending upon where the are found in the project life cycle. The earlier they're found, the easier it is to fix. The later they are found, the more costly and time-consuming they are to fix. Luckily for me, this project was on a smaller scale, so not much harm as been done as far as clock-time. If I looked at the delays as a percentage of total project time, I wouldn't be to happy - something like a 5-10% delay. But it's a good lesson to learn without much harm done.