Will the REAL requirement please stand up?
Sunday/01/07 2007 | Soapbox
When developers reflect their understanding of a client's requirements in language that supersedes words, results are faster and more accurate. Rapid prototyping, using fourth-generation desktop tools can make it happen.
Do you remember the old television show "To Tell the Truth"? In the show, one person was selected because of an interesting vocation or experience. Then, that person and two impostors would attempt to convincingly answer celebrities questions in hopes that they would be chosen as the real person of interest.
Within every data-driven project, one of the greatest struggles is discovering its real requirements. Each person in an organization offers a different idea of the requirements. Or, more likely, people have difficulties in articulating more than just an overview of the requirements that will make or break a project.
Entellic understands this difficulty. Gathering the details takes more than just asking questions off of a checklist. In most cases, requirements are learned by onsite observation and collection of sample input and output documents. Assuring that the real requirements are captured means repeating them back in the form of a requirements document.
Yet, as fourth-generation database technologies become more robust, another way of gathering requirements is taking shape: In some cases, rapid prototyping can be effective. With tools like FileMaker® in the hands of experts, there are cases in which the data dictionaries, workflow, and basic interfaces can be fleshed out in a matter of days...in the same amount of time it would take to create a requirements document.
The inherent value of rapid prototyping is apparent:
- People think visually. The ability to see the the project requirements assists them in communicating what they really want.
- Developers are usually better at communicating in tables, interfaces, and processes than they are in sentences and paragraphs. Rapid prototyping allows database programmers to quickly manifest what they think a client wants. Words don't stand in the way.
- A foundation is laid. If a project's intent is accurately portrayed in the prototype, some development tasks are already accomplished, ready to be built upon. When you recognize that the lifespan for many data projects is less than three years, this fraction of development time can hold costs down.
Of course, rapid prototyping is not intended to replace all pre-development documentation. And, it can be a total waste of time if the interpretation of a client's needs is completely missed in the prototype development. Even worse, it can foster laziness by developers and analysts.
Yet, even with these risks, the advent of desktop database development tools lends itself to move forward with this method of communicating requirements. Even a well-written requirements document can lead to disappointing results and rework due to human communication limitations. We believe that people really do think in pictures more than words. They know it when they see it. We believe rapid prototyping should be attempted.
What do you think? Send us an email with your experiences, biases, or ideas. Is this the way to make the real requirements stand up?
Watch for additional thoughts on rapid prototyping in future posts.