|There's more than one way to do things|
Re: requirement documents?by vladb (Vicar)
|on May 12, 2003 at 19:23 UTC||Need Help??|
Good that you asked... I'm now working on both the specifications and design documentation for a medium-sized project. This project involves development in both Java (for the front-end Tomcat/Velocity VCC framework) and Perl (for the back-end feed parser / manager). The perl component was there before and one objective of this project is to re-design the whole piece and hopefully make it a lot more simpler.
I started out by building a functional flow-chart for the original Perl feed parser process. On it, I tried to concetrate on particular areas of interest. One example is where/how parsed data is being stored into the database. Once ready, I submitted it for a review by my colleagues and immediate boss. As soon as I had received a favourable responce, I proceeded with my work on a revised copy of the flow chart. This one had to reflect the inner-workings of a simplified/improved version of the feed parser process. In their final shape and form, the two flow charts and accompanying specification are expected to provide a clear picture of the system and any work that might be required to improve it as per project requirements.
Following my work on the flow-charts, I then was able to identify specific tasks that would take the project from start to finish. The detailed design doc was key in determining those tasks. Having to come up with an hourly project time schedule is a hard task all in itself. However, having to do this without a thorough and detailed design document is virtually impossible.
update: Added a *missing* sentence (2nd paragraph) and fixed a few shameful grammatical errors :)
"We've all heard that a million monkeys banging on a million typewriters will eventually reproduce
the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true."
Robert Wilensky, University of California