Braude's book tries to bridge that gap. The book is clearly meant for a classroom, and is built around a term-long team project. It drives home the point that a project is bigger than any one person. Its documentation is what holds it together and gives it continuity. What's written down is the project's memory.

This is where computing professionals step ahead of the children. Face it: programming is the fun part, and project documentation is not. The paycheck is not for play-time, though. Grown-ups understand their responsibilities to their employers, to their teams, and to their project's future. This book helps instil that understanding.

Braude's text uses the IEEE software documentation standards as the basis for project organization. It's easy to nit-pick the that huge, dry body of standards - I've done so myself. Still, they are the product of long thought and experience, and they provide a complete, well-tested framework. Braude summarizes that corpus of standards, and makes it clear that hair-splitting compliance is not useful. Instead, the standards act as a checklist, making sure that no major points are forgotten. Practitioners can then add or omit as needed, based on knowledge their projects' needs.

For its intended purpose, I can't imagine any book being much better. As an extra, Braude gives a sample project and other class materials at the publisher's web site. I've had real success teaching from this book. Toward the end of the term, one student declared himself a convert and said the standards were "worth their weight in gold."

The bad points:
He is in love with the big document approach. He bases these documents on the IEEE standards which are about as current as a web site that hasn't been updated in three years. The IEEE has spent no effort keeping their software standards up and should step up or get out of the business. The author seems to have never heard the "what versus how" rule for requirements. Requirements should never be "object-oriented", you are trying to define the problem not solve it. Good requirements should allow you to follow any approach to design a solution. Use cases are not object-oriented.