Requirements Analysis for Social Technology
When I first began thinking about social technology I tried looking for applications in the most serious social problems, and at the time the most serious problem of all was clearly the threat of global thermonuclear war. Thinking about ways to solve this problem led me eventually to a consideration of the role of requirements analysis in systems engineering. That seems like quite an intellectual leap, so baldly stated, but I think I can reconstruct how I got from one idea to the other.
One of the causes of war can be seen whenever people get together to discuss things, even if what they are talking about is “Putting an End to War”. One person has a proposed solution, say, World Federalism, and will argue vehemently (almost violently) with someone else, who is more of an anarchist, blaming the world’s problems on governments, and violently (!) opposed to the creation of a new, bigger, and “better” one.
Such arguments remind me of something. In several years of working as a software/systems engineer/analyst, I often witnessed arguments in which people passionately disagreed over some software design issue, i.e. some solution to a problem. Almost always the root cause of the argument was poor (or nonexistant) requirements analysis.
There is a very deep psychological tendancy for people who have a design in mind to become blind to requirements which would be hard to satisfy with the design they envision. If adequate requirements analyis has not been done (or if the result has not been written down for all to see), each person will end up defending his or her own pet solution, feeling certain it meets the (unstated) requirements.
To stop all this talking at cross purposes, do the analysis first!
It works. People find it much easier to agree on goals or requirements than they do on ways of achieving these goals. Once the goals are clearly stated, a much more calm and rational measurement of proposed designs against the stated set of requirements usually follows.
Therefore, one of my pet solutions to severe social problems is the idea that we should put more effort in figuring out and stating our common goals.
The problem is, requirements analysis is hard. When you ask someone for a set of goals or requirements, they will usually come back with a very vague design, or something expressed almost entirely in terms of one possible design. Pure design-free requirements analysis is very hard to do, and the temptation to express requirements in terms of existing design concepts, or to bias a set of requirements to favour a particular design is almost overwhelming.
I have read hundreds of software and systems requirements documents, and never yet seen one which was not at least 80 percent design.
Typically, a requirements document will include a supposed requirement such as:
“The system shall print a message on the terminal screen whenever there is a disk drive I/O error.”
Upon being pressed, the analyst will (sometimes) admit that the actual requirement is to inform the user of any hardware problems that may need his or her attention, but that whether this is done with a message on the screen or with an indicator light, an audible alarm, or a printed message on a system console printer is entirely a matter of design.
(Note: there are several other problems with this requirements statement, which trespasses on design territory in several respects.)
Even though most requirements documents are not very good, the effort to separate analysis from design and separately document the requirments to be met by the design is almost invariably worth the effort because it helps catch errors sooner.
Errors in the requirements for a system that are actually caught in the requirements analysis phase may be corrected quite inexpensively, for perhaps a few percent of the cost of the project. If the same errors make it to the design phase before being caught, they will cost several times as much to fix, and if they make it to the implementation phase they may double the cost of the project.
If we are talking about war and peace, the “cost of the project” is measured in human lives.
In my view, the treaties, ceasefires, international conventions and agreements, and all the other pieces of paper produced in trying to stop specific wars or reduce international tension are items of software. Some work. Some don’t. Some seem to help make things better. Some actually make things worse.
Whether one of these pieces of software is any good or not depends on the quality of the software engineering that went into it.
Let me generalize this further: I have come to think of laws, rules, and administrative procedures as software, and view the legislators and bureaucrats that make up our governments as doing software engineering, whether they realize it or not.
Since we are all affected by the legal software governments produce, we should all take some interest in what the computer industry has to teach us about the nature of the software engineering process.
When I first began to write computer programs I started by typing in examples from books, then making small changes in them to suit my immediate needs. Before long I was writing programs from scratch, but they were all loosely based on programs I had seen in books. Later I found taht I could write more original programs through a sort of trial and error process.
Like many of the self-taught hackers of the early years of microcomputers, I successfully wrote all my own programs for several years without any significant use of flowcharts, context diagrams, pseudocode, or any of the other tools of software design.
The early years of the computer software industry was dominated by individual programmers, often self-taught, usually somewhat eccentric, who wrote programs at the computer keyboard without the benefit of any design committed to paper. Now, in the 1990’s, such individuals are rare in industry, which has turned to a more-or-less rigorous methodology involving requirements analysis and many levels of design.
Partly, this change is due to a number of spectacular failures, where highly paid programmers worked for years, wrote mountains of code, but produced nothing successful. A shocking amount of money, billions of dollars, has been wasted on failed software development projects. In response, there have been several complete overhauls of the process and many deep soul-searching studies of the very nature of engineering.
The results are not final yet, and many bitter arguments over methodology still rage, but I can summarize the basic conclusions, which most would accept.
The core problem in software engineering is minimizing the effects of human errors. The many failures and huge cost overruns are the results of human beings making mistakes. You cannot stop people from making mistakes or find super-humans who don’t make mistakes, so the only way to solve the problem is to find reliable ways of finding and correcting the mistakes.
Originally, computer programs were written in machine language which consisted of long sequences of numbers. A single wrong number usually meant a bad program that would crash the system or produce spurious results. Later came assemblers and compilers which were pieces of software that translated some more human-readable computer language into the sequences of numbers computers used. Obviously it was an enormous advantage to be able to write programs in a language that was better adapted to human needs, but there was another, more subtle advantage as well, a way of catching human errors.
A compiler accepts programs written in a computer language which has a well-defined syntax. If the human programmer makes a mistake, there is a good chance it will result in somthing the compiler will reject as a syntax error. If the compiler rejects the program because of a syntax error, it will not produce the sequence of numbers that constitutes the machine language equivalent of the program, so this particular human error will not result in a machine crash nor any spurious results.
Thus, a compiler is not only a piece of software that we use in writing other pieces of software, but it is a piece of software that helps us catch and correct human errors.
Early compilers such as the Fortran compiler written in 1957 were primarily designed as translating tools, and their error-correction function was not well understood. As a result, errors in Fortran programs caused multi-million dollar accidents, such as the satellite probe which missed the planet Venus and flew into the Sun. Later compilers, such as Nickaus Wirth’s Pascal compiler were specifically designed with a very rigorous syntax which would catch the more common human errors.
But compilers could only catch certain types of errors, such as spelling mistakes, they could not help when what a programmer intended to do was wrong, where the ideas behind the program were mistaken. In the 1970s and 80s it became recognized that these were the most costly errors, and the hardest to detect. To date we have no completely reliable way of detecting and correcting these most fundamental kinds of error, but we have developed ways of minimizing their effects.
In order to understand how we can minimize the effect of human error in software engineering, it’s important to understand a number of basic notions about the engineering process.
Most important is the idea that there are a number of logically separate and sequential steps that must be undertaken in software development and in any other kind of engineering. The exact number of steps is in dispute, but one of the first is called requirements analysis, which attempts to discover and codify the exact goals and requirements that the software or system must meet, independent of any actual design.
After the software is designed, the actually writing of programs in some computer language is called implementation, and this must be followed by various stages of testing and integration.
It is generally accepted that requirements analysis must precede design, which in turn must precede implementation, although it is quite usual to go back and fix up a design after trying to implement it, and occasionally to fix up a requirements specification after trying to find a design that satisfies it.
I think we now realize that these basic steps have always been a part of engineering, even when not formally recognized or written down. The hacker who sits down at a terminal and writes code without any visible preparation has either done some mental preparation which must have included analysis and design, or he is doing it as works on the code. Logically, the steps of analysis, design, implementation and testing are separate steps. In practice they may be merged or interleaved.
In civil engineering and building construction there are analogous steps that are usually undertaken separately, but may be combined in a “fast-track” approach in which sites are prepared and foundations excavated before the final plans are drawn up.
While it is possible to take such shortcuts, they increase the risks associated with human error. One fundamental way of minimizing risk is to keep the various steps of the development process quite distinct. In particular, it seems to be especially important to separate requirements analysis from design, even to the point of having different people doing the work.
Designs have a peculiar way of seizing the imagination of those who invent them. If a person has a particular design in mind, he or she most often develops a certain blindness to the advantages of other designs, and an inability to perceive the importance of requirements not met by this design.
This is a very powerful psychological tendancy, which even the most experienced engineers are prone to. If the same engineer does both analysis and design for the same project, there is an overwhelming probability that requirements not easily met by the design will turn out to have been omitted from the analysis.
During the 1970s many well known software projects involving air traffic control, national defense, and international banking software cost ten times the original estimates because errors in the requirements which were not caught until final integration and test, because of poor requirements analysis.
In general, the trend in software engineering has been to focus less and less upon the implementation phase of development and more upon the phases that precede and follow it. During the 50’s and 60’s most of the time and effort was spend on implementation. During the 70’s, design was stressed, and more recently the emphasis has been on analysis before design and testing after implementation. The result has been an overall increase in software quality and a decrease in its cost. (There are some interesting exceptions to this trend!)
As I explained above, I view all of the formal regulatory apparatus of government, including all laws, regulations, and administrative procedures as a form of software. My purpose in stating this is not to provoke an argument, but to provide a useful tool for understanding how our society works and doing something to fix it. Even those who disagree or feel uncomfortable with the analogy may find it a useful heuristic device, a new way of thinking about law and government which can suggest new approaches to making it work.
Canada recently experience a prolonged and heated constitutional debate which reminded me of the sort of acrimonious design discussion that occurs in an engineering project when there does not exist an adequate requirements document.
I think of the attempt to write an acceptable national constitution as very much like the attempt to write computer software. As with software, some of the more successful constitutions have been the result of a single brilliant individual who just sat down and wrote it without much preliminary design work. Also, as with software, there have been spectacular failures, massive expenditures which produced nothing, or worse, the failed constitutions of some countries which have led to terrible “system crashes”.
In Canada and other liberal democracies, constitutional change is attempted only after public hearings which are apparently supposed to serve a role somewhat analoguous to the requirements analysis phase of software engineering. In the recent Canadian case, the actual creation of a final legal text was done by constitutional lawyers after the various concerned politicians had sketched out the basic form of the document in closed-door meetings. I think that what the politicians created was very much like the kind of pseudo-code which often serves as a low-level software design, while the actual legal text is much like the formal code which implements the design.
But these rough analogies should not be taken as any indication that the process of creating a proposed Canadian constitution was in any way correct or adequate. The results of public hearings was not in any way a requirements document. Politicians argued bitterly over design issues, making compromises and concessions for political reasons instead of honestly trying to meet some previously agreed upon requirements. And the final document was a curious mixture of requirements, design, and implementation.
The fact that millions of dollars was spent in attempting to produce a constitution and in the end nothing was achieved is not at all surprising — as with many of the failed projects of the early years of software engineering, no reliable process was established to meet the desired goals, so they were not met. In this example, as in many other cases, I feel that the politicians and administrators that run our nations have much to learn from the experience of software and systems engineers, who have learned how to make things work.
We often refer to our governments and other people in positions of power as “The System”, usually in pointing out ways in which “The System doesn’t work.” I believe the relevent expertise required to make systems that work is the that of the systems engineer. I have discussed here briefly the software engineering component of systems engineering, and suggested that legislative and administrative processes of government are essentially the same thing in a different context.
But what about the other major component of systems engineering, the hardware part?
Briefly, the hardware systems engineer is concerned with connecting together hardware components to form functioning systems. As with software, this implementation of systems must follow system design, which in turn must follow requirements analysis. Although the connections between people which form marriages and friendships, let co-workers work together, and link teachers with students are formed primarily with words, such connections have a strength and permanance which make them most analogous to the connections between hardware components in a computer system.
This is a harder analogy to make and understand, but it is also a more important one. Computer hardware is a very high technology, which is generally more successful than computer software. In contrast, connections between individuals in our society are often very poor, to the point that people are sometimes driven to kill those they are connected with. The ways in which people form connections with one another are important, and we should think about what the hardware systems engineering process can teach us about interconnecting things.
Modern integrated circuit chips are extremely complicated, some of them are probably the most complicated things ever produced by human beings. Not all this complexity can be managed by human engineers working unaided, and so some form of combinatorial optimization software is commonly used in to help the designers.
If you read some of my other pages you will find arguments to support my view that a great many social problems boil down to problems in the ways people are interconnected. As in the c case of integrated circuit design, forming the connections between the components (human beings) of the system (human society) is a very difficult optimization process, and so I have argued that most social problems can be solved by combinatorial optimization. I sometimes (over-)generalize this to say “All social problems are optimization problems.”
Let me restate that, less concisely but more clearly: underlying almost all the social ills of our society is the combinatorial explosion of possibilities for social connections between people. Currently we lack of adequate techniques for reducing the size of that search space, and social choices end up being mostly accidental. But the discipline of combinatorial optimization theory, a branch of graph theory, and part of discrete mathematics does include ways around such problems.
Like all optimization problems, social problems can and must be factored into two sub-problems: defining what is meant by optimum, and finding the optimal solutions.
To many people, such wording is so highly technical as to cause confusion and misunderstanding, but some people quite capable of understanding it nevertheless find it offensive. Such people have developed an aversion to “high technology” because of the bad example set by military and industrial examples of technology, e.g. the bomb, Chernobyl, etc.
But technology is just the study and application of techniques.
All techniques used to organize and manage our society, including all political and financial techniques are part of technology. What led us to Chernobyl and the nuclear arms race was not so much the very high technology of nuclear engineering, as the very low technology of politics and industrial decision-making. Bad decisions were made because our ways of linking people together and getting a decision out of them are very poor, prone to error and corruption.
But all of politics and business management is technology and can benefit from the enormously improved understanding of the nature of technology that has arisen with the discipline of systems engineering.
The requirements analysis stage of systems engineering is essentially the same thing as defining what is meant by optimum, as is done in numerical optimization by defining an objective function.
The design, implementation, and test stages of systems engineering are essentially finding an optimal solution to a problem defined during requirements analysis.
Bad engineering, which is very common, usually results from inadequate or biased requirements analysis that allows the engineers doing design or implementation to build in their own preferences instead of trying to satisfy the end-user of the system. In politics this is variously called conflict-of-interest, patronage, or corruption.
Bad engineering, in whatever field of human endevour, can be avoided by recursive systems engineering, which applies good systems engineering methods to the engineering methodology itself: setting forth the requirements to be met by a set of requirements, and designing a requirements analysis stage that will really work, so that whatever requirements specifications are produced actually do meet the requirements for a set of requirements, and are not just somebody’s pet design in disguise.
Ultimately, requirements analysis, or defining the optimum, is the much harder part of the problem, and is less susceptible to machine help since it is utterly dependent on communication with the people who will use the system.
The subtle but vital distinction between requirements and design is usually unknown to end-users, who tend to talk in terms of designs they are familiar with, if asked. Therefore, you cannot find out the users’ requirements by just asking them. Instead the end-user should be considered as a person with an expert knowledge of his or her own desires, but not necessarily as an expert in expressing those desires. This is the basic approach that a knowledge engineer takes in dealing with the experts consulted during the creation of an expert system: their expertise is valued and must be extracted carefully, but rarely emerges in their own words.
In my words, what most people want from society is a good social environment, in which they are optimally matched to the tasks they perform, the people they work with, the friends, lovers, or mates they have relationships with, the goods and services they consume, and the physical environment in which all this takes place.
Because of the large numbers of human beings, the large number of tasks to be performed, and the diversity of physical environments, these matching problems are difficult in the extreme, and require much more attention and effort than they ever receive.
The current “system” in which a badly fragmented social network forces us all into contact with strangers and incompatable people, relying on a uniform code of laws to maintain some amount of order, can be replaced by a truly integrated system in which the social network maintains order without coercion by having tight links between truly compatible people. This is what I call social network optimization.
If you really understand what optimization means, you will not object that you don’t want to live in an optimized society, since what is optimum for you is by definition the closest possible thing to what you want. What you can and should object to is having to live in a society optimized according to somebody else’s definitiion of optimum. In other words, you can and should object to anything in social requirements analysis that is not consistent with your own personal requirements.
I have often thought of forming a non-profit organization to begin the requirements analysis work suggested here, and I have also suggested that such an organization could be something of a prototype for social organization — for rapid-prototyping is also an important part of systems engineering.
Good engineering does not only consist of careful analysis and design, but also includes rapid-prototyping of possible designs, under controlled conditions — an exploration of the space of possible designs. Any organization designed to link together and integrate the various people who respond to the ideas expressed here, or who have similar or compatible ideas of their own, should be considered a prototype, and should attempt to set an example, through good legal/organizational-software engineering. It must include all the safeguards, fail-safes, and other techniques we know of to avoid emergence as anything whose self-interest could make it in any way hostile to some portion of humanity.
Given appropriate safeguards, it should be possible to get the transitional process underway by finding people who are interested in this general approach, and linking them up with other compatible individuals to form a stable, efficient, and well integrated sub-network within human society. In doing so we can test and perfect the optimization process as it applies in the human context, doing whatever is possible to meet and satisfy the personal goals of all individuals involved.
Now this proposol for an organization of people with similar ideas is a design idea, and anyone who has followed my argument should berate me for talking design at this point, instead of keeping my attention on goals and requirments. Well, consider this a bit of rapid-prototyping, or brainstorming, or an operational concepts sketch.
Good systems engineering should be recursive, that is to say it should include the engineering of its own systems engineering processes. This page is something of a sketch for the systems engineering of society — an application of social technology. I cannot yet go into enough detail about that technology to write its requirements, but I have written this small (and rapid) prototype.
For more information on social technology, please see my social technology page .
If you are interested in this subject please consider subscribing to the The Social Technology Mailing List . It’s free, easy to use, and will contain lots of news and new ideas. You might also visit the The Social Technology Pavillion at Frontiers which is a new forum for the expression of these ideas and for discussing other aspects of social technology.
Copyright © 1995 and 1998 by Douglas P. Wilson
Copyright © 2009 Douglas Pardoe Wilson
Other relevant content:
Please see these web pages:
The main Social Technology page.
Find Compatibles , the key page, with the real solution to all other problems explained
Technological Fantasies , a page about future technology
Social Tech a page about Social Technology, technology for social purposes. I think I was the first person to use this phrase on the Internet, quite a long time ago.
Roughly corresponding to these web pages are the following blogs :
Social Technology the main blog, hosted on this site, with posts imported from the following blogger.com blogs, which still exist and are useable.
Find Compatibles devoted to matching people with friends, lovers, jobs, places to live and so on, but doing so in ways that will actually work, using good math, good algorithms, good analysis.
Technological Fantasies devoted to future stuff, new ideas, things that might be invented or might happen, such as what is listed above and below.
Sex-Politics-Religion is a blog about these important topics, which I have been told should never be mentioned in polite conversation. Alright that advice does seem a bit dated, but many people are still told not to bring up these subjects around the dinner table.
I believe I was the first person on the Internet to use the phrase Social Technology — years before the Web existed.
Those were the good old days, when the number of people using the net exceeed the amount of content on it, so that it was easy to start a discussion about such an upopular topic. Now things are different. There are so many web pages that the chances of anyone finding this page are low, even with good search engines like Google. Oh, well.
By Social Technology I mean the technology for organizing and maintaining human society. The example I had most firmly in mind is the subject of Find Compatibles , what I consider to be the key page, the one with the real solution to all other problems explained.
As I explained on my early mailing lists and later webpages, I find that social technology has hardly improved at all over the years. We still use representative democracy, exactly the same as it was used in the 18th century. By contrast, horse and buggy transporation has been replaced by automobiles and airplanes, enormous changes.
In the picture below you will see some 18th century technology, such as the ox-plow in the middle of the picture. How things have changed since then in agricultural technology. But we still use chance encounters, engagements and marriages to organize our home life and the raising of children.
I claim that great advances in social technology are not only possible but inevitable. I have written three novels about this, one preposterously long, 5000 pages, another merely very very long, 1500 pages. The third is short enough at 340 pages to be published some day. Maybe. The topic is still not interesting to most people. I will excerpt small parts of these novels on the web sometime, maybe even post the raw text for the larger two.
This site includes many pages dating from 1997 to 2008 which are quite out of date. They are included here partly to show the development of these ideas and partly to cover things the newer pages do not. There will be broken links where these pages referenced external sites. I’ve tried to fix up or maiintain all internal links, but some will probably have been missed. One may wish to look at an earlier version of this page , rather longer, and at an overview of most parts of what can be called a bigger project.
Type in this address to e-mail me. The image is interesting. See Status of Social Technology
Copyright © 2007, 2008, 2009, Douglas Pardoe Wilson
I have used a series of e-mail address over the years, each of which eventually became out of date because of a change of Internet services or became almost useless because of spam. Eventually I stuck with a Yahoo address, but my inbox still fills up with spam and their spam filter still removes messages I wanted to see. So I have switched to a new e-mail service. Web spiders should not be able to find it, since it is hidden in a jpeg picture. I have also made it difficult to reach me. The picture is not a clickable link. To send me e-mail you must want to do so badly enough to type this address in. That is a nuisance, for which I do apologize, but I just don’t want a lot of mail from people who do not care about what I have to say.
Copyright © 2009 Douglas Pardoe Wilson