Practical Software Requirements: A Manual of Content and Style (Paperback)

by Benjamin L. Kovitz (Author)

Editorial Reviews

Review
"Authored with an eye toward the novice, Practical Software Requirements is a comprehensive guidebook for drafting project requirements. The author's in-depth examination includes non-hierarchical ways to break down complex problems, elements of the problem domain, and different information needed to address different problem types.

An extensive style section addresses the detail of making information understandable focusing on how to group and sequence topics, writing definitions, and how to avoid boring the reader. Filled with examples this title should be considered required reading BEFORE graduation!" -- CompBookReview.com, October 99

"It takes an outstanding writer to bring an unexciting topic to life, and in this era of hype-ridden tomes about Java, open source software, Microsoft lawsuits, Year 2000, and .com "best practices," I was frankly skeptical about staying awake through a book on software requirements. However, Kovitz pulled it off in a way that's thorough as well as captivating, with copious examples." -- Alan Zeichick for Software Development, July, 1999

"Kovitz presents a very different view of requirements engineering from the prevailing view. I found the book to be quite excellent. This is quite a refreshing view. In addition, the author has an online discussion forum where readers can ask questions and receive direct help from the author. I found this to be an excellent resource, and the author is to be commended for such participation and dedication." -- Slashdot.org, October 99

"Kovitz starts by demolishing "the myth of functional decomposition" (which is actually the title of Section 1.1). As he points out, a good engineer is one who knows a lot about problems that have been solved in the past, and can use that knowledge to figure out which of those proven solutions should be applied to the present problem. Defining a problem's requirements is therefore really about gathering the information needed to choose, and customize, a solution (or set of solutions).

All of this is good stuff, and I learned quite a bit from the first few chapters of this book -- especially Chapter 5, which describes five common kinds of problems, and the sorts of questions that a requirements document should answer for each." -- Gregory V. Wilson for Dr. Dobb's Journal, August, 1999

Kovitz has written a fresh, lively, honest, funny, and provocative book on a serious engineering topic.... -- Ian Alexander's Reviews of Books on Requirements Engineering

The book is well organized, literate, and readable...a delightful discovery. -- ACM Computing Reviews

Product Description
By following the techniques in this book, it is possible to write requirements and specifications that customers, testers, programmers and technical writers will actually read, understand and use. These pages provide precise, practical instructions on how to distinguish requirements from design to produce clear solutions.

Product Details

• Paperback: 426 pages
• Publisher: Manning Publications (October 1998)
• Language: English
• ISBN-10: 1884777597
• ISBN-13: 978-1884777592
• Product Dimensions: 9 x 7.5 x 1 inches
• Shipping Weight: 1.6 pounds
• Average Customer Review: 4.2 out of 5 stars See all reviews (14 customer reviews)
• Amazon.com Sales Rank: #727,209 in Books (See Bestsellers in Books)

Customer Reviews

Most Helpful Customer Reviews

77 of 77 people found the following review helpful:

5.0 out of 5 stars If you have to write a requirements document, read this!, April 26, 1999

By A Customer

Kovitz's book is one of the best works I've ever seen on writing software requirements.

Most books focus on a method of analysis (usually one that translates neatly into a software development methodology) but can be totally incomprehensible to the poor end-user who is supposed to understand and approve the project. I've seen a number of attempts to remedy this: the most promising was to create the user manual as the first step in the requirements process. Tempting, but there are dozens of decisions in most business applications that need to be exposed up front but don't belong in user documentation--error messages, to give just one example.

Kovitz takes a different approach: he focuses on what needs to actually be in the text of a requirements document to make it effectively understood by both developers and end users. This is, as the subtitle makes clear, a manual of content and style. The focus of the book is how to present the results of your analysis rather than on how to conduct the analysis itself. As a result, this book contains useful advice whether you use SA/SD or the latest object-oriented methodology.

The first third of the book is devoted to determining the scope of the problem to be solved. Kovitz's approach is heavily influenced by Michael Jackson's Software Requirements and Specifications--another book I loved but sometimes found difficult to make practical use of. Jackson devotes a fair amount of his book to the topic of framing problems and how to fit your method to the problem, rather than distorting the problem to fit the method. Kovitz takes this a step further by describing in detail five common types of problems solved by software systems, outlines the different information required to solve each kind of problem, and shows how multiple kinds of problems can be solved in the same information system.

The next section details means of describing the information contained in a system, event sequences, and causation and control patterns.

The book finishes up with a section on wirting style and sample requirements and specification documents so you can actually see his advice in use. The documents come from a real program and not some toy problem--and they're a lot clearer than anything I've read at work.

It takes a lot of effort to write clearly, and where requirements and specifications are concerned, it's perhaps vital to the success of the project. Understanding and applying the advice of this book can probably do more for you than attempting to apply the latest lifecycle methodology.

Of course, I always have been a sucker for good books on writing, and I guess that this gushing shows it, but still...

17 of 17 people found the following review helpful:

5.0 out of 5 stars The definitive requirements book. Learn it. Live it., August 26, 1999

By	David Stengle (Princeton, NJ USA) - See all my reviews (REAL NAME)

Wow! The more years I spend in software, the more I am convinced that requirements documents are consistently weak. Reading this book will help. Good advice. Strong theoretical justification. Great, real-world examples. Don't do software without it.

17 of 18 people found the following review helpful:

5.0 out of 5 stars A Terrific Book, March 2, 2002

By	Elizabeth L Mead (Oakland, CA United States) - See all my reviews

This is a great book for anyone whose job includes:
* Business Analysis (for software)
* Application Programming
* Technical Writing

The book is about techniques for describing a problem to be solved by a piece of software without describing the design of software components. In other words, providing the information that the software designer needs at the correct level of detail, without trying to specify a software design.

Designing software involves joining informal, real-world problems to the formal world of computers. In the real world problems are messy, vague, and unbounded. Unfortunately, computers only solve problems that are well-defined, unambiguous and well-bounded. Requirements writing is the art of reducing a messy-real world problem to a neat, well-defined, unambiguous description which can be used to drive development of a computerized solution.

This is one of the first books to effectively bridge that gap. I say "effectively", because it is certainly not the first try--every software methodology has techniques for capturing requirements. However, the methodologies hopelessly intertwine requirements gathering with system interface specification and even system design. This inevitably results in requirements being given short-shrift.

Many of the techniques this book teaches are equally applicable to creating documentation for existing software. Every technical writer should learn to create models of the problem their software solves and then explain software functions using only the terms defined within the model.

I highly recommend this book. However, I do know some people who did not like it. If you find it disappointing, I suggest that you try practicing with one or two techniques, then give it another read. The ideas are often more subtle than they appear at first glance. Expect that you may need months to really absorb its advice.