Practical Software Requirements: A Manual of Content and Style [Paperback]

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.

this tells you all you need to know about requirements.

indeed, it tells a lot more than that because it explains things not just state them.

it kills some urban legends and myths about requirements that everyone should know but most people do not. but then most people do not know what they don't know. scare your phb, impress your colleagues with your wisdom after reading this book.

if you work with requirements, software, systems engineering, and especially systems architecture you need to read this book. even if you have read others and or think you know all about requirements you can still learn things that you didn't know or why what you thought was true actually is.

this book would work symbiotically with the art of systems architecture by rechtin and maier. read them both.

. .

.