Michael Jackson.compiled by Tom Verhoeff in October 2003.
Software Specifications and Requirements: a lexicon of practice, principles and prejudices
ISBN 0-201-87712-0 [ See this book at Amazon.com]
Machine, simply by describing it. This is one good reason for regarding software development as engineering. ... The parts of the world that will affect the machine and will be affected by it are its
Application Domain. ..."
"This distinction between the machine and the application domain is the
key to the much-cited (but little understood) distinction between
What and How:
what the system does is to be sought in the application domain,
while how it does it is to be sought in the machine itself.
The problem is in the application domain.
The machine is the solution."
"An inability to discuss problems explicitly has been one of the most glaring deficiencies of software practice and theory. ... writers on development method claim to offer an analysis of a problem when in fact they offer only an outline of a solution, leaving the problem unexplored and unexplained."
"`What do you think?' he asked. He was asking me to tell him my impressions of his operation and his staff. `Pretty good,' I said. `You've got some good people there.' Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.
"`What did you think of Fred?' he asked. `We all think Fred is brilliant.' `He's very clever,' I said. `He's not very enthusiastic about methods, but he knows a lot about programming.' `Yes,' said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. `Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it.' His voice dropped to a reverent hush. `Fred tells me that he's not sure he understands it himself.'
"`Terrific,' I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. `But what about Jane?' I said. `I thought Jane was very good. She picked up the program design ideas very fast.'
"`Yes,' said the DP Manager. `Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet --- if you see what I mean?'
"I saw what he meant."
`Programming is, among other things, a kind of writing. One way to learning to write is to write, but in all other forms of writing, one also reads. We read examples --- both good and bad --- to facilitate learning.'...
"... Nothing will improve your ability to write good descriptions more than the habit of careful and critical reading."
Problem Contextin which the machine must function. Above all it is not on calculation, but rather on description. Software describes a machine that must fit into the world of concrete reality, not into a world of Platonic abstractions and ideals."
"The Greeks divided mathematical problems into two classes: problems to prove and problems to find. A problem to prove requires the solver to prove something. ... A problem to find requires the solver to find or construct something. ..."
"Each kind of problem has its principal parts related
in a characteristic
Problem Frame or structure,
and a solution task posed in terms of those parts.
The principal parts of a problem to prove are the
hypothesis and conclusion.
The solution task is to demonstrate that the conclusion follows
from the hypothesis --- or, perhaps, that it does not."
"In a problem to find, the principal parts are the unknown, the data, and the condition. The solution task is to find the unknown, which must be of the right kind and related to the data by the condition."
Methodsfor solving problems of the class that fit the frame. Polya gives many recommendations. For problems to prove his suggestions include:
"For problems to find, he suggests:
"All these recommendations are given in terms of the problem's principal parts. Without the problem frames and their named parts you couldn't talk about problem solving at all in such general terms."
"Requirements are all about --- and only about --- the environment phenomena..."
"Programs, on the other hand, are all about --- and only about --- the machine phenomena..."
"The second difficulty is that the real world ... hardly ever has a single hierarchical structure."
"In short, my advice to those about to work top-down is like Mr Punch's advice to those about to marry: Don't."