What Makes a Good Design Document?

dnnrly asks: "I've been writing software professionaly for a couple of years now for more than 1 company and I've noticed a recurring pattern: I get put on a new project that already has a bit of history and I get told to read the design documents and then implement XYZ. What happens is I read the document, find that it gives me a lot of information about certain aspects of the system we are building, but leaves huge gaps in others. We're going to be rewriting some of the procedures very soon and I'll be able to influence the software side so I wanted to ask Slashdot readers what sort of things have they seen in design documents that they've liked/thought are a good idea? What have they found works and what doesn't? If all else fails, where's a good place to find all this stuff out?" "There's usually a very defined and rigid format for every design document and the writers have obviously tried very hard to make sure that procedure has been followed, generally leading to an almost unreadable doc or a design for the sake of it. Part of the issue is that these guys have written the design after 2 or more years exposure to the problem so they tend to forget just how much they know."

Comments

Re:Mythical Creatures

[GIL_Dude]

I always thought the horn was to attact the virgins... Wait, maybe that was the other way around...

Re:Existence

[Rick the Red]

How can the first post be redundant?!?!

As of when I post this, it has the following moderation:

Starting Score: 1 point
Moderation +1
40% Underrated
20% Offtopic
20% Redundant
Extra 'Insightful' Modifier 0 (Edit)
Total Score: 2

Please tell me how that adds up to "+1 Insightful"