Understanding specifications and requirements
David Megginson
It’s easy to write specifications and #requirements , and it’s only moderately difficult to nag people about them. The real work (maybe 80% of it) is sitting down and helping people understand and use them, and (more importantly) updating and correcting the design documents based on feedback from the people who will have to use them.
I think that’s one reason people hate so-called waterfall design so much — not just that it doesn’t iterate, but that there’s often a lost connection between the designers and the implementers. Like most project problems, it’s a human thing. Real architects set up trailers, put on hard hats, and get their boots muddy at construction sites, but “business architects” and “software architects” sometimes lack the same level of collaboration and cooperation. It’s too easy just to hurl design documents over the developer’s cubicle wall, then complain when the specs aren’t followed properly.
Imported from Google+ — content and formatting may not be reliable