Deep and unique - I feel I've really come to understand what a requirement is and how to communicate it to non-technical people. The reader, however, will have to be familiar with the concepts and terminology of software engineering or will miss some of the theoretical points. The only drawback for me, was the concentration on Jackson's approach. While the book ties the subject matter well to methodological components, I would suggest getting your methodology education elsewhere. Skip the theoretical "why", chapter 12 and beyond (Part III on style) is where the value of the book lies and justifies the cost.
Hands down the best book I have ever read on requirements. If you can look past the dated examples, absolutely every recommendation in this book is worth taking if you're interested in writing high quality requirements.
I read this in 1999 or 2000, shortly after publication, as I was simultaneously immersing myself in eXtreme Programming (now generally called 'Agile.')
Practical Software Requirements is simply the best book ever written on the subject, and should be the foundational text for anyone involved in software.
We might not build big documentation up front anymore, but the principles Kovitz provides, and the clear examples, pave the way for excellent story cards. One example I use every day, even 24 years later, is the list of all possible values. You wouldn't believe how many times this simple technique prevented disaster--nor how many disasters could have been averted by using it.
If you have to tell a developer what you want, first read Practical Software Requirements.