The first step in creating your expert system is defining your problem domain. Just as in programming, you must determine what you are going to reason about and why you need to. Before starting to build an expert system, you need to clearly identify the problem and the end-users of the expert system. In addition, you must identify the expert that will supply the knowledge to be infused into the system. Typically, you as the programmer are not going to be the expert.
Once you identify what and why in general, you need to start focusing the problem. In general, you, as a programmer or program designer, are going to have access to more information in your program than what you want to include in your expert system. Just because you have access to a piece of information does not mean you should include it in your expert system. Including unnecessary details will not only slow down the inference engine and consume more memory, it will also make your expert system harder to debug and modify.
You must define the scope and the granularity of the problem. The scope defines how wide or broad of a domain you are going to represent and reason about. Generally, narrower and more focused domains enable the creation of better, more robust, and faster expert systems. The granularity defines the depth of the problem, to what detail are you going to represent and reason about objects in your domain. For example, if you are writing an expert system to assess mortgage risks for clients, you would in general want information about the client, their credit history, jobs, etc. However, it would make no sense to represent in the expert system their shoe size or hair color. In general, you need to restrict the properties of objects in your expert system to what the expert system needs to reason correctly about the objects. Just as important is the granularity of the rules. Too fine a rule granularity makes expert systems hard to understand as multiple rules need to be considered to encapsulate a concept. Too much granularity makes the expert system brittle and hard to modify as one rule mixes several chunks of knowledge (similar to having one procedure or method performing multiple tasks).
Finally, separate expert systems working together may be better than one monolithic expert system. Unfortunately, making an expert system is still very much an art, even more than programming. Extensive experimentation and testing (and retesting) will be required to find the appropriate mix for your problem.
After you have defined exactly what you want your expert system to do, you need to define the objects or classes that will represent your domain.
