Trade in your item
Get a £0.29
Gift Card.
Have one to sell?
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See this image

Practical Software Requirements: Manual of Content and Style (PowerBuilder Developer's Library) Paperback – 31 Jul 1998


See all formats and editions Hide other formats and editions
Amazon Price New from Used from
Paperback
"Please retry"
£50.26 £3.52


Trade In this Item for up to £0.29
Trade in Practical Software Requirements: Manual of Content and Style (PowerBuilder Developer's Library) for an Amazon Gift Card of up to £0.29, which you can then spend on millions of items across the site. Trade-in values may vary (terms apply). Learn more

Product details

  • Paperback: 426 pages
  • Publisher: Manning (31 July 1998)
  • Language: English
  • ISBN-10: 1884777597
  • ISBN-13: 978-1884777592
  • Product Dimensions: 19.1 x 2.6 x 22.9 cm
  • Average Customer Review: 5.0 out of 5 stars  See all reviews (2 customer reviews)
  • Amazon Bestsellers Rank: 1,342,052 in Books (See Top 100 in Books)
  • See Complete Table of Contents

More About the Author

Discover books, learn about writers, and more.

Customer Reviews

5.0 out of 5 stars
5 star
2
4 star
0
3 star
0
2 star
0
1 star
0
See both customer reviews
Share your thoughts with other customers

Most Helpful Customer Reviews

11 of 11 people found the following review helpful By A Customer on 16 May 1999
Format: Paperback
I would recommend this book for everybody, who is involved in sw product creation. It is so CLEARLY and engagingly written, that any reader (student, business manager, programmer...) can take advantage of information. There is no 'water' in this book. You will read and almost on every page you can make a discovery: 'A-a-a... That's how we document it!' It will make clear for many people the grey area between the conception of software idea and actual sw design. Unfortunately, in (almost) all design books the technique of documenting 'what is to be done' is glossed over.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
8 of 8 people found the following review helpful By A Customer on 27 Aug. 1999
Format: Paperback
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.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Most Helpful Customer Reviews on Amazon.com (beta)

Amazon.com: 14 reviews
78 of 78 people found the following review helpful
If you have to write a requirements document, read this! 27 April 1999
By A Customer - Published on Amazon.com
Format: Paperback
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...
20 of 21 people found the following review helpful
A Terrific Book 2 Mar. 2002
By Elizabeth L Mead - Published on Amazon.com
Format: Paperback
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.
18 of 19 people found the following review helpful
The definitive requirements book. Learn it. Live it. 27 Aug. 1999
By David Stengle - Published on Amazon.com
Format: Paperback Verified Purchase
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.
11 of 11 people found the following review helpful
Good for experienced practictioner 17 Feb. 2000
By Auckland Kiwi - Published on Amazon.com
Format: Paperback
I enjoyed this book and got a lot from it, Kovitz focuses not on a standard "join the dots" methodology but rather on outlining an overall approach followed by good detailed advice on possible analysis/documentation techniques and how to write clear, concise requirements. Hence I would say that its best for the experienced analyst who is already familiar with the concepts and various techniques described in section 2 and knows when to use/ when not to use them. He is truthful in what he says about needing to adapt requirements style and content to what the situation needs but in some development shops you would need to be an senior analyst to be able to vary from their standards. I would recommend it for any analyst with 2+ years experience who wants to improve and polish their ability to write requirements/specifications
9 of 9 people found the following review helpful
Requirements and Specifications that People Read! 5 Oct. 2004
By Adrian Kok - Published on Amazon.com
Format: Paperback
Writing requirements as a product manager has always been a black art to me. It's not impossible but it normally involves a lot of fudging and reading it always make me feel that there's something missing. I often end up putting specifications inside the requirements document. How do I make it complete without ending up writing the specifications itself?

Kovitz's <em>Practical Software Requirements</em> provides a clear and concise guide to writing requirements by looking at the problem of developing software. By examining how we frame a problem and its domains, the book explains how the reader can extract elements of the requirements and specifications documents and present them in a concise manner.

Throughout the book, he proposes how its content can be written and provides clear examples. His approach is direct and concise, and he teaches the reader how to write without any hint of legalese that permeate traditional corporate requirements documents. His examples are practical and he addresses common mistakes that writers make.

I've thoroughly enjoyed reading this book, and it has been an invaluable tool in helping me write better requirements and specifications at work.
Were these reviews helpful? Let us know


Feedback