As I consider examples from my development career that showcase the benefits of pre-production design, one example that frequently comes to my mind really drove home for me the concept that requirements documents are often not enough. I was the technical lead on a project for a major agricultural company. We had a client who had a time-intensive daily process management system that involved interacting with numerous spreadsheets. I was given a solid requirements document that detailed the feature we would be adding to a web application to replace their existing process. The requirements were straightforward and made sense, so we began development.
As we were working on the development and the new feature began to take shape there were some concerns about whether is was truly going to provide the value that the client was hoping for. I requested to visit the client and watch them perform the daily tasks that we were replacing. As I did so it became very clear to me that what we were building (thought it matched the requirements) was not going to solve the problem at all, it was only going to move the existing problems into a new system.
We ended up setting aside the original requirements doc, completely redesigning the solution, and started over. The end result was not what had been originally requested, but was what the client needed -- and they were thrilled with the product!
I learned some valuable lessons here that have been continued to be reinforced over the years:
- It is not uncommon for the end user to not fully know or be able to express what they really need
- Often even a carefully thought-through requirements document is not sufficient for locating problems with the proposed solution
- Visualizing and testing the solution before spending time and money on development is a key part of a development process
Are you involved in a software project? Let's get designing!