Here is a short summary of my experience in the wonderful world of 'Knowledge Auto-formalization'. Unfortunately, neither book nor other papers by the author were ever published in English.
Aleksey
1.1 Problem Area
In other words it is very hard to do mapping outside immediate technical area.
So, the problem is how to crack a hard unmappable application ?
1.2. Knowledge Auto-formalization Process
General idea is that the only way to solve it is by creating an environment where advanced user can express him/herself through programming. There devil is in the details.
1.2.1 Pilot User
It is generally possible to find a 'pilot-user': a user with advanced knowledge in the field who either has some programming experience (e.g. college course) or is able to be taught basics of programming.
1.2.2 Support Engineer
Support Engineer creates and maintains environment for a pilot-user. It is evident, that we cannot expect much from pilot-user beyond ability to arrange ready to use function calls into program flow. Key element is that he does not have to do anything beyond this very limited area. All hard software parts are done by support engineer.
1.2.3 Process
Support engineer evaluates initial needs of pilot-user e.g. what interface to hardware he has to have to start with, what functions he has to have to call etc.
For example, in my own experience I started from a simple menu program allowing pilot-user to perform elementary equipment control functions through a set of menus and pilot-user modified it step by step into fully functional prototype. (*)
Pilot-user goes on playing with the stuff. Every time he/she encounters sw/hw problem it is responsibility of support engineer to resolve it: add new stuff, improve performance, discuss results etc. After that goes another cycle of pilot-user development etc.
In other words, pilot-user is splitting problem into pieces. Some of them he resolves him/herself, some of them are passed to support engineer. The key is that support engineer does not have to understand the whole problem and pilot-user does not have to program well.
At the end there will be working (crude and slow, but working) prototype of the thing being developed which can be used a basis for formal specification and then a bunch of packers will hack away with it.
In my own experiences results were surprisingly good. I had very telling experiment in this area: There were guys who developed an advanced glass viscometer and they need to control it by a computer (it was loooong time ago, at the time some chemists were not that comfortable with computers as now). The problem was not so trivial because glass is a very strange liquid with strong temperature dependencies and big variations from sample to sample (in addition all processes are painfully slow, so it may took half an hour for a temperature to be distributed evenly over sample, for displacement to become linear with time etc).
I found a pilot-user who did a lot of FORTRAN programming doing scientific calculations, however, he never did any computer control stuff. As I said (*) I had assembled and calibrated all hw control units and wrote sub-routines to do user level operations with the stuff: change furnace power, measure temperature, apply load, measure set of displacements. And I made it into simple basic menu driven program. I was called to help him a few times to improve one or another part of the control/measurement system and this was it, he did rest himself working a few hours a day in a month. He got device which was working with any human intervention beyond entering geometry of the sample and which was adaptive enough handle wide range of temeperaturs/viscosities
At the same time I did not know and I am still do not know anything about glass viscosity beyond very basic understanding He did not know and he is still does not know anything about computer control stuff. And we were able to do the thing with truly minimal efforts from both sides.
Here comes an interesting part. By the time I started working on the project they were developing specs for other guys for a few months. After our project was over, I asked him to compare it the latest spec he was written with the actual program he developed. He found 13 differences:
He decided that he can live without a few things which do not provide much bang for the buck. It accounted for 2 differences.
Seven more were really trivial to figure out and he was sure that in the normal spec-test-spec-test process these items would be found rather easily.
Two more were less trivial, however, these items could still be discovered by spec-test-spec-test-spec-test process.
Two were non-trivial, his feelings were that he would not be able figure it out fast enough without playing with stuff by himself.
This project was really small, however, in my view it is a quite telling example.
Unix is a system designed by software developers for software developers, that is why it is so comfortable development environment.