Comments on: How do you ensure full coverage for your design/spec reviews? http://www.embeddedinsights.com/channels/2011/04/27/how-do-you-ensure-full-coverage-for-your-designspec-reviews/ Shedding Light on the Hidden World of Embedded Systems Mon, 28 Jul 2014 16:18:37 -0400 hourly 1 http://wordpress.org/?v=3.0 By: E.M. @ LI http://www.embeddedinsights.com/channels/2011/04/27/how-do-you-ensure-full-coverage-for-your-designspec-reviews/#comment-6552 E.M. @ LI Sat, 07 May 2011 01:05:21 +0000 http://www.embeddedinsights.com/channels/?p=536#comment-6552 If there is an SOP that describes what the roles and responsibilities of the signing authorities, then there is not really much more a spec/design review should do. As far as traceability is concerned, generally requirements have a corresponding validation/verification effort that proves the design works as intended. The spec/design review is just a first step in the process that will catch some issues, but not all of them. If there is an SOP that describes what the roles and responsibilities of the signing authorities, then there is not really much more a spec/design review should do. As far as traceability is concerned, generally requirements have a corresponding validation/verification effort that proves the design works as intended. The spec/design review is just a first step in the process that will catch some issues, but not all of them.

]]> By: D.G. @ LI http://www.embeddedinsights.com/channels/2011/04/27/how-do-you-ensure-full-coverage-for-your-designspec-reviews/#comment-6551 D.G. @ LI Sat, 07 May 2011 01:05:04 +0000 http://www.embeddedinsights.com/channels/?p=536#comment-6551 Presumably, each reviewer in the long list had a reason to use the document in the future. Some users would be using the document as a basis for design. Some would be using the document to see if they had asked for the right product. No one is going to have the complete picture but they all should have an interest in certain content. Due to the lack of interest described, either the real users of the document were not on the list or no one intends to use the document. If the list was made up of managers then it is likely the real document users never saw it. If the list included actual document users then the downstream process does not incorporate the document enough for them to care. If the downstream process doesn't incorporate the document then perhaps the process needs improvement. If the process is already optimized then the document has no purpose and should be eliminated. Utility, not coverage, is the goal. Supply side economics doesn't work for documentation. Contracts often call out certain documents as deliverables. That encourages write-only document creation. What should be called out is evidence that certain documents were actually used. I say this now as if it is obvious but if it is so obvious why have I, and many others, create so many write-only documents? Presumably, each reviewer in the long list had a reason to use the document in the future. Some users would be using the document as a basis for design. Some would be using the document to see if they had asked for the right product. No one is going to have the complete picture but they all should have an interest in certain content. Due to the lack of interest described, either the real users of the document were not on the list or no one intends to use the document. If the list was made up of managers then it is likely the real document users never saw it. If the list included actual document users then the downstream process does not incorporate the document enough for them to care. If the downstream process doesn’t incorporate the document then perhaps the process needs improvement. If the process is already optimized then the document has no purpose and should be eliminated.

Utility, not coverage, is the goal. Supply side economics doesn’t work for documentation. Contracts often call out certain documents as deliverables. That encourages write-only document creation. What should be called out is evidence that certain documents were actually used. I say this now as if it is obvious but if it is so obvious why have I, and many others, create so many write-only documents?

]]> By: L.R. @ LI http://www.embeddedinsights.com/channels/2011/04/27/how-do-you-ensure-full-coverage-for-your-designspec-reviews/#comment-6550 L.R. @ LI Sat, 07 May 2011 01:04:41 +0000 http://www.embeddedinsights.com/channels/?p=536#comment-6550 This reminds me of a book I have recently been reading - "Freakonomics" - it tells a story about a group of people witnessing a crime, yet no one called the authorities - each one thought that the others have probably already did that, so they did not bother. When you divide responsibility among a large enough group, no one in particular feels responsible, and assumes the others have already checked most of the details. This is not to say that all team work is bad, just that one person must "own" a project and be completely accountable for its results, and in full authority of making decisions, to get something done well. The owner should still get critical advise from peers and subordinates, consider opposing views to his own, but have the guts to call the shots. This reminds me of a book I have recently been reading – “Freakonomics” – it tells a story about a group of people witnessing a crime, yet no one called the authorities – each one thought that the others have probably already did that, so they did not bother.
When you divide responsibility among a large enough group, no one in particular feels responsible, and assumes the others have already checked most of the details.
This is not to say that all team work is bad, just that one person must “own” a project and be completely accountable for its results, and in full authority of making decisions, to get something done well. The owner should still get critical advise from peers and subordinates, consider opposing views to his own, but have the guts to call the shots.

]]> By: N.M. @ LI http://www.embeddedinsights.com/channels/2011/04/27/how-do-you-ensure-full-coverage-for-your-designspec-reviews/#comment-6549 N.M. @ LI Sat, 07 May 2011 01:04:25 +0000 http://www.embeddedinsights.com/channels/?p=536#comment-6549 I don't want to hurt anybody's feelings but the quality of the answer has a lot to do with the quality of the question. If you give a group of people a large free text document and you say "Is this okay" you will not get any good answers. There has been some fascinating research on this phenomenon (as observed by Leonid, above): if you stage a mugging with one by-stander on the street, that person is likely to try to intervene but if you stage a mugging with lots of people on the street, it is likely that nobody will intervene because there is confusion about who, if anybody, is responsible. If you structure the specification into tables of requirements so that certain completeness properties can be easily checked (excellent research done on tabular requirements by David Gries, if I recall correctly) and you make each reviewer responsible for checking or approving specific aspects (and make it clear that their effort is not redundant and duplicated by other reviewers), you can expect to get MUCH better answers. I don’t want to hurt anybody’s feelings but the quality of the answer has a lot to do with the quality of the question. If you give a group of people a large free text document and you say “Is this okay” you will not get any good answers. There has been some fascinating research on this phenomenon (as observed by Leonid, above): if you stage a mugging with one by-stander on the street, that person is likely to try to intervene but if you stage a mugging with lots of people on the street, it is likely that nobody will intervene because there is confusion about who, if anybody, is responsible.

If you structure the specification into tables of requirements so that certain completeness properties can be easily checked (excellent research done on tabular requirements by David Gries, if I recall correctly) and you make each reviewer responsible for checking or approving specific aspects (and make it clear that their effort is not redundant and duplicated by other reviewers), you can expect to get MUCH better answers.

]]> By: A.T. @ LI http://www.embeddedinsights.com/channels/2011/04/27/how-do-you-ensure-full-coverage-for-your-designspec-reviews/#comment-6458 A.T. @ LI Thu, 28 Apr 2011 17:30:43 +0000 http://www.embeddedinsights.com/channels/?p=536#comment-6458 Bringing a Louisville Slugger to meetings helps Bringing a Louisville Slugger to meetings helps

]]> By: J.L. @ LI http://www.embeddedinsights.com/channels/2011/04/27/how-do-you-ensure-full-coverage-for-your-designspec-reviews/#comment-6457 J.L. @ LI Thu, 28 Apr 2011 17:30:17 +0000 http://www.embeddedinsights.com/channels/?p=536#comment-6457 Be absolutely resolute and aggressive with a "You snooze, you lose" policy. Write up meeting notes with lists of attendees and invited absentees, topics, resolutions, to-dos, and do-by dates. Be hardheaded about refusing to allow changes after the meeting without forcing management buy-in of cost and schedule impact. Make people that ignore you pay a price of embarrassment and justification for it. Be absolutely resolute and aggressive with a “You snooze, you lose” policy. Write up meeting notes with lists of attendees and invited absentees, topics, resolutions, to-dos, and do-by dates. Be hardheaded about refusing to allow changes after the meeting without forcing management buy-in of cost and schedule impact. Make people that ignore you pay a price of embarrassment and justification for it.

]]>