This session had been billed as a tutorial on Expert Systems Development. Murali Dharan was not able to present at SHARE 70, so he and two others in the AI project talked about rule-based systems and took questions from the audience. The session was surprisingly good, considering that they were winging it.
They talked about "domain selection" for awhile. This is a fancy term for picking the problem. The concensus was that you should select a problem that is an information bottleneck in your business. Knowledge engineering is expensive to do, and you should choose areas that will give you the best payback. Murali suggested the "telephone test". If your human expert is on the telephone answering queries all day long, and each call takes 10-30 minutes then his job is a candidate for an expert system.
Domain selection is also strongly influenced by the tools available to you. Some expert system shells do forward chaining (goal directed systems), and others do backward chaining. Some shells provide graphics. Others can provide explanations for their reasoning. Some deal with uncertainty very well, and some not at all.
If you are just starting out, do a literature survey first, and see what other people have done, what sorts of problems can be solved. Don't do a real-time system as your first project. Real-time systems are hard. Integrating sensor data into any system is hard. Do the rule-based parts first, then work on trying to make the system run in real-time.
I have OPS5 at home on my AT clone. It is a rule-based system that runs very slowly, but is good for experimentation. Unfortunately, it is becoming aged; the panel described it as "primitive" and said they "wouldn't call it a shell". Sigh. So much for OPS5.
Many books caution against having the Knowledge Engineer (the programmer) be his own expert. The panel disagreed; they said that it is indeed OK for the programmer to be the Expert just as long as he IS an expert.