Software Requirements & Specifications: A Lexicon of Practice, Principles and Prejudices
, Addison-Wesley 1995
The book is, as it says, in lexicon form, with short sections such as WhatAndHow?
and Method with (nonhyper-)links between them. It would be highly wikiable therefore. If you like this book's concept of problem frames, see also MichaelJackson
Problem Frames: Analyzing and Structuring Software Development Problems ISBN 020159627X .
When we've all learnt as much as we can from practicing ExtremeProgramming
and other lightweight methods of today there will still be value in a few other books on software. This is one of them in my view.
Michael deals wittily with our DisciplineEnvy
but makes the case for calling our particular discipline SoftwareEngineering
. He makes the helpful point that, like physical engineering, it's far too much to expect one individual to be expert in all aspects of our field. So "I'm a software engineer" is always likely to be pretty contentless. When people start to say things like "I'm a compiler engineer" we may be getting closer to an appropriate parity with other engineers. But not through pretending that software is not software.
Seconded. This is one of my desert-island books
Dittos for sure. I am using Jackson's book in my class this semester CS665 Software Engineering I at James Madison University. The book has a series of "tours" which begin to be defined on page xiii in the preface and they are a good way to get started reading the book. Since it is a lexicon, it does not necessarily read best in a linear fashion. More insights per page than any other book except maybe FredBrooks
See also ClarityUpFront