|Structured Programming, by O.-J. Dahl, E.W. Dijkstra, and C.A.R. Hoare. Academic Press, 1972.
This year (2012) is the 40th anniversary of this text, but it holds up well. It consists of three essays:
If you've been led to think "Structured Programming = No GOTOs", the first essay will change your mind. It's much more a consideration of design in the small than a focus on surface form.
"Data Structuring" considers how to structure types; Pascal's type structure (remember that?) of records, sets, enumerations etc. clearly embodies some of these ideas. You can see roots of the "object-based" approach (that never seemed to make it to the mainstream in the way object-oriented approaches did).
The final essay describes mechanisms from SIMULA 67, an early (if not the original) object-oriented programming language. You can see the early consideration of objects and coroutines, classes and subclasses.
There's definitely a "historical" air to these essays, but they hint at a path almost taken. Modern libraries and the modern rush to deliver let us ignore many ideas about software design, but they don't go away. These articles take a slower, more mathematical path than I've seen anybody apply in practice, but it brings clarity of thought about mapping problems and solutions that I'd like to imitate.
Structured Systems Analysis: Tools and Techniques. Chris Gane and Trish Sarson. Prentice Hall, 1979.
This is one of the classic books on systems analysis: data flow diagrams, data dictionary, and so on appear. It does a decent job explaining these (though heavier on the tools than the techniques). The description of a data dictionary is one of the better ones I’ve seen. There’s a nice distinction between system and organizational objectives. This is the earliest reference I’ve seen to the IRACIS model: that work is done because it will Increase Revenue, Avoid Costs, and/or Improve Service. Their explanation of decision tables is excellent. For those who trace the history of agile ideas, Gane and Sarson view systems development as following Boehm’s spiral model: “In each case and at each level we build a skeleton, first logical and then physical, see how well the skeleton works, and then go back to put the flesh on the bones.” (This is from 1979, and 30 years later we’re still working on it.)
Structured Design. Edward Yourdon and Larry L. Constantine. Prentice-Hall, 1979.
This was one of the early structured "standard works" that I've only just gotten to for the first time. I'd learned things like coupling and cohesion, afferent and efferent flows, and the concept of factoring, but it's much stronger coming directly from this source. Not everything here is compatible with the way I think about design, but this is one of those books that deserve repeated study.
A customer needs to know more than stories (including how to manage up-front analysis that might financially justify a product or feature, linkages to outside groups, innovation, and more.) But those aren’t this book’s topic: this book sets out to provide a clear, very well-written, and concise guide to using stories with a software team. It does a great job: I’m seeding copies with several people! (Reviewed June, ’04)