Last month I urged readers to include in every package of user requirements documentation rigorous definitions of the outputs that the proposed new or changed system is to produce. Not everything that's displayed on a screen or printed on paper, however, is a bona-fide system output. In particular, these are not system outputs:
No user has ever required a system to produce error messages or progress indicators. The above categories are simply means of obtaining system input or managing the status of processing.
I regret having to report that some of the most extreme examples (hundreds of extraneous pages of "output" specifications) were generated by people who probably knew better. False outputs are sometimes specified by:
Dozens or hundreds of pages of unnecessary documentation, whether generated through naiveté or through deliberate deception, serve mainly to obscure the important content and seriously impair understandability. In addition, they may limit design choices, including use of purchased application software products.
We occasionally see such documented requirements as these:
As a developer/reviewer I have the urge to reply:
"Thanks for the guidance. I had been planning on producing meaningless error diagnostics (or none at all) and designing awkward and obscure data-entry forms.".Haven't we gotten past such silliness?
Return to Requirements Guidelines
Return to IDI Home Page