I'm with ya. A lot of people make the HUGE mistake that the requirements document should be a plan for the code and, patently, it should not! It might contain a "process" chart but it shouldn't describe how the code will be written. Too many people think that the requirements document needs to describe the "How" instead of the "What" and the "Why" and that's when you end up spending 9 months on such a document.
Then, there's what some folks call the "design document". It's an incredibly useful document if done the right way (living document rather than a rule document) but too many people don't get that, either. There's only so much you can write about before you have something to write about. 😉 It should start out as a high level document at the functional level to be able to hand to the Developers to write code to fill in the blocks. If they come across improvements, optimizations, realizations, cancellations, impossibilities, or alternatives, then that can be fed back to the design document so that everyone knows what's going on. It should never be a gating document except for the first blush and that should come out very rapidly and define any any resources that may help the Developers excel at what they're good at..
is pronounced "ree-bar
" and is a "Modenism
" for R
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
"If you think its expensive to hire a professional to do the job, wait until you hire an amateur."--Red Adair
"Change is inevitable... change for the better is not."
When you put the right degree of spin on it, the number 3|8
is also a glyph that describes the nature of a DBAs job. 😉
How to post code problems
Create a Tally Function (fnTally)