Abstract:
Method and apparatus for warning the user of potential limitations of a database request or the results provided thereby and for warning the user of potential limitations of a database request and the results provided thereby. Preferably, the identified limitations are provided in a number of caveats. The caveats may warn the user that a survey request and/or survey result may be improper, invalid or otherwise deficient in some way. This may prevent the user from basing important business decisions on misrepresentative database results.

Description:
CROSS REFERENCE TO CO-PENDING APPLICATIONS 
     The present application is related to U.S. patent application Ser. No. 08/937,024, filed Sep. 23, 1997, entitled “Survey Analysis System and Method”; U.S. patent application Ser. No. 08/937,354, filed Sep. 23, 1997, entitled “Method and Apparatus for Using Prior Results When Processing Successive Database Requests”; U.S. patent application Ser. No. 08/937,351, filed Sep. 24, 1997, entitled “Method and Apparatus for Validating a Survey Database”; U.S. patent application Ser. No. 08/937,352, filed Sep. 23, 1997, entitled “Method and Apparatus for Identifying the Coverage of a Test Sequence in a Rules-Based Expert System”; and U.S. patent application Ser. No. 08/937,353, filed Sep. 23, 1997, entitled “Method and Apparatus for Detecting an Endless Loop in a Rules-Based Expert System”, all of which are assigned to the assignee of the present invention and incorporated herein by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention generally relates to data processing systems and more particularly relates to such systems that analyze survey data. 
     2. Description of the Prior Art 
     Many businesses have adopted the concept of Total Quality Management (TQM) to help improve profitability, ensure sustained customer loyalty, improve quality of products, etc. Originally developed by E. Deming and others, TQM is now widely accepted in many business circles throughout the world. A cornerstone of most total quality management (TQM) systems is the periodic measurement of identified parameters that relate to various aspects of the business. Through these measurements, managers can identify the areas within the organization that need improvement. Because the measurements are made on a “periodic” basis, managers can gauge the effects of various changes made within the organization over time. The goal of most TQM systems is to make continuous improvement within the organization. 
     Businesses often generate and manage an array of measurements for purposes of analyzing the performance of individual operations in relationship to productivity, resource utilization, profitability, etc. One of the most important measurements in many TQM systems is that of customer satisfaction. To measure customer satisfaction, periodic customer feedback is required, usually obtained through customer surveys. 
     In many surveys, customers are asked a number of survey questions that are related to various products and/or services provided by a business. For many questions, the customers can respond both with a satisfaction rating and an importance rating. By analyzing the answers to these questions, managers can obtain insights into many areas, including customer loyalty, overall satisfaction, potential weakness, etc. 
     It is not uncommon for businesses to conduct their own customer surveys. However, it is increasingly popular to outsource this function to outside vendors who specialize in conducting customer surveys. Today, there are a number of vendors who conduct customer surveys, and provide a survey database to the subscribing business. One such company is Prognostics Inc., located in Menlo Park, Calif. An advantage of using such a vendor is that customer survey data for other companies, including competing companies, can often be obtained. This enables a business to perform comparisons between itself and its competitors. 
     Some of the vendors of customer surveys provide the survey data in electronic form, and often provide a software program for accessing the survey database. The software programs facilitate the generation of reports or the like, which can then be used by management. Prognostics is one such vendor. Prognostics provides survey data in a proprietary electronic format, and provides a software program called the Research Analysis Program (RAP) which can access the survey data. RAP can read the survey database, perform data requests, and provide a number of reports. 
     A limitation of many of the survey analysis programs is that the survey results may mislead the user. For example, survey results may be based on a statistically insignificant sample size, thereby misleading the user. Similarly, survey results may be based on data elements that skew the results in an undesirable way. Often, the user is unaware that the survey results have these deficiencies, and may base important business decisions on the misrepresentative survey results. 
     Misrepresentative results can often be traced to portions of the survey database that are either under-represented, or otherwise different from the user&#39;s expectations. The underline assumption when using a typical survey analysis program is that the survey database is fully represented in all respects, and that all data elements fall within the user&#39;s expectations. It has been found that this is often not the case. 
     For example, it is known that many survey analysis programs allow the user to make qualified user requests that select and operate only on a portion of the database. Using such a qualified request, a user may request the overall satisfaction for those respondents that are in a particular industry sector, that are located in a particular geographic region, and that use a particular product. The number of respondents represented in the survey database that meet all of these criteria may be relatively small. Thus, in this case, the corresponding results may be based on a statistically insignificant sample size. The user may not recognize this, and may make important business decisions based upon the misrepresentative results. 
     In another example, the survey database may include data elements that skew the results in an undesirable way. For example, it is known that many questions in a customer survey may solicit two answers, such as an overall importance question and an overall satisfaction question. Those responses that indicate a high degree of satisfaction but a low degree of importance may skew the results provided by an overall satisfaction request. In addition, some respondents may only answer one of the two questions, such as the satisfaction question but not the importance question. This may also skew the results of certain user requests. 
     SUMMARY OF THE INVENTION 
     The present invention overcomes many of the disadvantages of the prior art by providing a method and apparatus for warning the user of potential limitations of a database request and/or the results provided thereby. Preferably, the identified limitations are provided in a number of caveats. The caveats may warn the user that a survey request and/or survey result may be improper, invalid or otherwise deficient in some way. This may prevent the user from basing important business decisions on misrepresentative results. 
     In accordance with the present invention, these and other advantages are preferably accomplished by using a rules-based expert system for forming and executing requests to a survey database. In a rules-based expert system, a number of rules are provided wherein the rules contain much of the “knowledge” of the experts, and the insights of “decision makers”. This allows “non-expert” users to perform “expert” analysis of client satisfaction data in an accurate and repeatable fashion. This may make data analysis of a survey database faster, more reliable, and cheaper than in the prior art. Moreover, additional request types and/or caveats can be added to the system by simply adding additional rules, and linking the additional rules into the system. 
     Preferably, the rules-based expert system uses a number of predefined rules to process a request. Each rule is similar to a conditional statement in a conventional computer program (such as C++). However, the rules-based expert system is equipped with an inference engine, which is a special program for managing rules and applying them as appropriate. By contrast, a conventional program must indicate explicitly when a given conditional statement should be applied. 
     In one embodiment of the present invention, a system is provided that has an interface module for accepting a request from a user, and a knowledge module that communicates with the interface module and is capable of accessing the survey database. The knowledge module processes the request and provides a number of data requests to the survey database. This is accomplished, at least in part, by executing selected ones of a number of predefined rules. An inference engine selects which of the number of predefined rules are actually applied for a particular request. The knowledge module then receives the request data elements from the survey database, and derives the desired result therefrom. This is also preferably accomplished, at least in part, by executing selected ones of a number of predefined rules. The desired result is then provided to the interface module for viewing by the user. 
     It is contemplated that the knowledge module may execute a number of request caveat rules to identify any request caveats for a particular user request. Preferably, a request caveat may indicate if the request is a valid request, as determined by the “experts” of a business organization. This knowledge may be included in the request caveat rules. For example, the “experts” of a business organization may determine that a comparison of customer satisfaction between a mainframe computer system and a personal computer system does not provide any valid or useful information. In this instance, this request may be labeled as invalid or improper. Because the rules in a rules-based expert system include knowledge provided by the “experts”, the rules may also provide a number of reasons why the user request is determined to be improper or invalid. 
     In a preferred embodiment, the user request is formed by selecting a combination of available selections via a graphical user interface. The present invention determines if the user request is an appropriate or proper request by determining if the combination of selections made by the user corresponds to one of a number of predetermined appropriate combination of selections. Even though the user request may be in a proper form (e.g. proper syntax), the present invention may identify the request as improper if it is determined that it will provide misrepresentative or otherwise improper results. Despite any request caveats that are provided, it is contemplated that the user may still elect to process the user request, and view the results as desired. 
     A second illustrative type of caveat is a result caveat. A result caveat preferably provides an indication of confidence in the result. A low indication of confidence may indicate that the results should be viewed with caution by the user. Preferably, the knowledge module identifies those portions of the survey database that are potentially problematic, including those portions that are under-represented or otherwise capable of skewing the results in an undesirable way. To accomplish this, the knowledge module may execute a number of result caveat rules. The result caveat rules include the knowledge of the “experts”, and operates on the data elements received from the survey database. 
     In one example, the result caveat rules may determine if the data elements retrieved by the knowledge module are sufficient to derive a statistically significant response to the user request. That is, if there are insufficient data elements in the survey database to produce a statistically significant result for a particular user request, a result caveat may be provided, indicating that the results should be viewed with caution. The result caveats may also identify a group of selected data elements within the survey database that caused the result to be statistically insignificant. 
     In another example, the result caveats may provide an explanation of the result. The explanation may identify the algorithm used to produce the result, and if any irregularities occurred during the analysis, etc. The irregularities may include the identification of portions of the survey database that differ from a predetermined expectation. As indicated above, a user typically expects that the survey database is fully represented, has a certain distribution of responses for various survey questions, etc. The result caveats may identify those irregularities, and provide an explanation thereof. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     Other objects of the present invention and many of the attendant advantages of the present invention will be readily appreciated as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, in which like reference numerals designate like parts throughout the figures thereof and wherein: 
     FIG. 1 is a block diagram of the computer-based environment of the present invention; 
     FIG. 2 is a block diagram showing a first illustrative embodiment of the present invention; 
     FIG. 3 is a block diagram showing an illustrative data processing system in accordance the present invention; 
     FIG. 4 is a block diagram showing in more detail the execution and control module  58  of FIG. 3; 
     FIG. 5 is a block diagram showing in more detail the interface module  52  of FIG. 3; 
     FIG. 6 is a block diagram showing a second illustrative embodiment of the present invention; 
     FIG. 7 is a block diagram showing an illustrative data processing system in accordance with another embodiment of the present invention; 
     FIG. 8 is a diagram showing a preferred analysis control window in accordance with the present invention; 
     FIG. 9 is a diagram showing the preferred analysis control window of FIG. 8, with the type of analysis window expanded; 
     FIG. 10 is a diagram showing a preferred transaction viewer window, which is displaying the results of a strength type analysis; 
     FIG. 11 is a diagram showing the transaction viewer window of FIG. 10, with the Result Caveats button selected; 
     FIG. 12 is a diagram showing a preferred explanation viewer window; 
     FIG. 13 is a diagram showing the preferred transaction viewer window of FIG. 10, after a subsequent weakness request has been executed; 
     FIG. 14 is a diagram showing the preferred analysis control window of FIG. 8, with the survey question selected to be Product Vender, and a response of Unisys; 
     FIG. 15 is a diagram showing the resulting transaction viewer window after the execute request button of FIG. 14 is depressed; 
     FIG. 16 is a diagram showing the preferred analysis control window with an opportunity analysis type selected; 
     FIG. 17 is a diagram showing a preferred SWOT editor window for editing SWOT parameters; 
     FIG. 18 is a diagram showing a preferred script editor window in accordance with the present invention; 
     FIG. 19 is a table showing an illustrative correlation table; 
     FIG. 20 is a functional diagram showing the interaction of the interface module, knowledge module and data module of the preferred embodiment of the present invention; 
     FIG. 21 is a flow diagram showing the general execution of a request in accordance with the preferred embodiment of the present invention; 
     FIG. 22 is a low level object model of the preferred interface module; 
     FIG. 23 is a composite object model for the preferred knowledge module; 
     FIG. 24 is a diagram showing a functional model for a SWOT analysis; 
     FIG. 25 is a diagram showing a functional model of a strength analysis; 
     FIG. 26 is a diagram showing a functional model of a weakness analysis; 
     FIG. 27 is a diagram showing a functional model of an opportunity analysis; 
     FIG. 28 is a diagram showing a functional model of a threat analysis; 
     FIG. 29 is a diagram showing a functional model of a survey validation analysis; 
     FIG. 30 is a diagram showing a functional model of the preferred data module; 
     FIG. 31 is a diagram showing a consolidated low level object model of the preferred data module; 
     FIG. 32 is a diagram showing a functional model of a preferred correlation table manager; 
     FIG. 33 is a table showing the execution of an illustrative direct RAP request, with a problem detected in the request; 
     FIGS. 34A-34B show the execution of an illustrative direct RAP request, when no problems are detected in the request or when the user indicates that the request should be executed despite the detected problem; 
     FIGS. 35A-35B show the execution of an illustrative strength or weakness analysis, when problems are detected in the request; 
     FIGS. 36A-36C show the execution of an illustrative strength or weakness analysis, when no problems are detected in the request or when the user indicates that the request should be executed despite the detected problem; 
     FIGS. 37A-37C show the execution of an illustrative threat or opportunity analysis, when no problems are detected in the request or when the user indicates that the request should be executed despite the detected problem; 
     FIG. 38 is a table showing the execution of an illustrative survey validation request, with request problems detected; 
     FIGS. 39A-39B show the execution of an illustrative survey validation request, when no request problems are detected or when the user indicates that the request should be executed despite the detected problems; 
     FIG. 40 is a table showing the execution of an illustrative SWOT parameter update using the SWOT editor of FIG. 17; 
     FIG. 41 is a flow diagram showing an illustrative method of the present invention; 
     FIG. 42 is a flow diagram showing another illustrative method of the present invention; 
     FIG. 43 is a flow diagram showing the method of FIG. 42, with elements  1206 ,  1208  and  1210  of FIG. 42 replaced with elements  1220  and  1222  of FIG. 43; 
     FIG. 44 is a flow diagram showing another variation of the method shown in FIG. 42, with element  1206  of FIG. 42 replaced with element  1228  of FIG. 44; 
     FIG. 45 is a flow diagram showing another illustrative method of the present invention, including providing a request caveat in response to a user request; 
     FIG. 46 is a diagram showing the preferred analysis control window selecting a “gap” RAP command without selecting a corresponding survey question; 
     FIG. 47 is a diagram showing the resulting transaction viewer window after the continue query window of FIG. 46 is affirmed; 
     FIG. 48 is a flow diagram showing another illustrative method of the present invention, including providing a result caveat in response to a user request; 
     FIG. 49 is a flow diagram showing another illustrative method of the present invention, including providing a result caveat in response to a user request; 
     FIG. 50 is a flow diagram showing yet another illustrative method of the present invention, including providing a result caveat in response to a user request; 
     FIG. 51 is a flow diagram showing another illustrative method of the present invention, including providing a result caveat in response to a user request; 
     FIG. 52 is a flow diagram showing an illustrative. method of the present invention for processing a survey validation request; 
     FIG. 53 is a flow diagram showing the method of FIG. 52, with element  1234  of FIG. 52 replaced with elements  1242 ,  1244  and  1246  of FIG. 53; 
     FIG. 54A shows an illustrative survey database  1250 , including a number of surveys  1252 ,  1254  and  1256 ; 
     FIG. 54B shows the distribution of responses for the available answers for the industry sector question; 
     FIG. 54C is a diagram that shows the number of responses for each of the four answers to the geographic region question; 
     FIG. 55 shows a survey database  1320 , including a number of surveys  1322 ,  1324  and  1326 ; 
     FIG. 56 is a flow diagram showing another illustrative method of the present invention, including providing a number of result caveats in response to a survey validation request; 
     FIG. 57 is a flow diagram showing the method of FIG. 56 with element  1354  of FIG. 56 replaced with element  1364  of FIG. 57; 
     FIG. 58 is a flow diagram showing the method of FIG. 56 with element  1354  of FIG. 56 replaced with element  1368  of FIG. 58; 
     FIG. 59 shows a survey database  1400  including surveys  1402 ,  1404  and  1406 ; 
     FIG. 60 is a flow diagram showing another illustrative method of the present invention, including validating a survey database that has paired responses therein; 
     FIG. 61 is a flow diagram showing another illustrative method of the present invention, including validating a survey database that has paired responses therein; 
     FIG. 62 is a flow diagram showing a number of checks that may replace element  1454  of FIG. 61, or executed in addition thereto; 
     FIG. 63 is a table showing illustrative analysis types, and the corresponding rule sets that are associated therewith; 
     FIGS. 64A-64C show a table of preferred rule sets, and the corresponding rules that are associated therewith; 
     FIGS. 65A-65O show a table of preferred rule names along with corresponding rule comments; 
     FIGS. 66A-66F shows an illustrative listing of the object oriented database before any analysis runs are executed; and 
     FIGS. 67A-67G shows an illustrative listing of the object oriented database before after a strength analysis type is executed. 
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The detailed descriptions which follow are presented largely in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. 
     An algorithm is here, generally, conceived to be a self-consistent sequence of steps leading to a desired result. These steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It proves convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers or the like. It should be kept in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. 
     Furthermore, the manipulations performed are often referred to in terms, such as adding or comparing, which are commonly associated with mental operations performed by a human operator. No such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention; the operations are machine operations. Useful machines for performing the operations of the present invention include general purpose digital computers or other similar devices. In all cases, it should be kept in mind the distinction between the method of operations in operating a computer and the method of computation itself. The present invention relates to method steps for operating a computer in processing electrical or other (e.g., mechanical, chemical) physical signals to generate other desired physical signals. 
     The present invention also relates to apparatus for performing these operations. This apparatus may be specially constructed for the required purposes or it may comprise a general purpose computer as selectively activated or reconfigured by a computer program stored in the computer. The algorithms presented herein are not inherently related to a particular computer system or other apparatus. In particular, various general purpose computer systems may be used with computer programs written in accordance with the teachings of the present invention, or it may prove more convenient to construct more specialized apparatus, to perform the required method steps. The required structure for such machines will be apparent from the description given below. 
     In sum, the present invention preferably is implemented for practice by a computer, e.g., a source code expression of the present invention is input to the computer to control operations therein. It is contemplated that a number of source code expressions, in one of many computer languages, could be utilized to implement the present invention. A variety of computer systems can be used to practice the present invention, including, for example, a personal computer, an engineering work station, an enterprise server, etc. The present invention, however, is not limited to practice on any one particular computer system, and the selection of a particular computer system (including a computer network) can be made for many reasons. 
     FIG. 1 is a block diagram of the computer-based environment of the present invention. A user  10  interacts with the data processing system  12 , which includes a processor  14 , which executes operating system software, as well as application programs including the present invention. The processor is found in all general purpose computers and almost all special purpose computers. The data processing system  12  is intended to be representative of a category of data processors suitable for supporting survey analysis operations. In the preferred embodiment, the data processing system  12  is an IBM compatible personal computer (PC) running Windows 3.1, 95 or NT. 
     The user  10  enters information into the data processing system by using a well-known input device  16 , such as a mouse, keyboard, or a combination of the two devices. It should be understood, however, that the input device may actually consist of a card reader, magnetic or paper tape reader, or other well-known input devices (including another computer system). A mouse or other cursor control device is typically used as an input device as a convenient means to input information to the data processing system to select command modes, edit input data, and the like. Visual feedback is given to the user by showing characters, graphical symbols, windows, buttons or the like on display  18 . The display is used to display messages and symbols to the user. Such a display  18  may take the form of any of several well-known varieties of CRT displays. Display  18  may also be in the form of a printer, file storage system, magnetic tape, etc. The software executed by the processor  14  stores information relating to the operation thereof in memory  20 . The memory may take the form of a semiconductor memory, magnetic disks, optical disks, magnetic tape or other storage device. 
     FIG. 2 is a block diagram showing a first illustrative embodiment of the present invention. The block diagram is generally shown at  30 , and includes an expert system  32 , which communicates with a survey database  42 . The expert system  32  includes an interface module  34 , a knowledge module  36 , and a data module  38 . A user  40  communicates with the system via interface module  34 , as shown. The interface module  34  helps the user  40  assemble a user request, which is provided to knowledge module  36 . 
     Knowledge module  36  checks the user request both for syntax and content. This is preferably done using an inference engine (not shown), which executes a number of rules. The rules contain “knowledge” provided by a number of survey database analysis experts. Knowledge module  36  then stores a number of request caveats for later reference. The request caveats indicate if the user request provided by the interface module is a proper request based on the knowledge within the rules. Knowledge module  36  then assembles an appropriate survey request, and provides the request to data module  38 . 
     Data module  38  accesses the survey database  42  and provides the requested data objects back to knowledge module  36 . Knowledge module  36  processes the requested data objects and provides a number of reports back to interface module  34 . Knowledge module  36  may also assemble a number of result caveats, and provide the result caveats to interface module  34 . Knowledge module  36  preferably processes the requested data objects using an inference engine within a rules-based expert system. The user  40  can view the request caveats, reports and result caveats via interface module  34 . 
     When a number of survey results are included in survey database  42 , it may be necessary to provide a correlation table  44  which correlates the various questions of each of the surveys. Data module  38  may read the correlation table  44 , and determine the appropriate requested data objects therefrom. This may occur, for instance, when the request provided by knowledge module  36  requires access to survey data from two separate years. The surveys used during these two separate years may have different questions or the questions may be in a different order relative to one another. In this instance, correlation table  44  may provide a correlation between the survey questions in the various surveys. 
     In addition, it is contemplated that the interface module  34  may display a listing of the generic questions, which may be selected by the user when forming the user request. To determine the appropriate generic questions for a selected survey, the interface module may access the correlation table  44  via the data module, and retrieve the generic questions that correspond to the actual questions in the selected survey. 
     Once a user request is formed, the knowledge module  36  may access the correlation table  44  to identify the actual question numbers and the appropriate surveys that correspond to the generic questions provided in the user request. The data requests provided by the knowledge module  36  to the data module  38  preferably specify the actual questions numbers, and the corresponding survey names in the survey database  42  to access. The data requests provided by the knowledge module  36  thus may identify selected data elements within the survey database  42  for analysis. 
     The data module  38  accesses the survey database  42  and provides the resulting data objects to knowledge module  36 . Knowledge module  36  determines the requested response and provides the results to interface module  34 . 
     FIG. 3 is a block diagram showing an illustrative data processing system in accordance with the present invention. The data processing system includes an interface module  52 , a knowledge module  56 , and a file storage area  83 . The interface module  52  communicates with a user via interface  54 . The interface module  52  may aid the user in assembling a survey database request. 
     Interface module  52  provides the resulting request to execution and control module  58  of knowledge module  56 . The execution and control module  58  may check the requests received from interface module  52  by initiating execution of a number of rules  72  via inference engine  60 . That is, execution and control module  58  may initiate inference engine  60  via interface  78 , wherein inference engine  60  may execute a number of rules to check the request. 
     Execution and control module  58  may then receive the results from inference engine  60  via interface  80 , wherein execution and control module  58  may assemble a number of request caveats. Execution and control module  58  provides these request caveats to request caveat generator  64  via interface  82 . Request caveat generator  64  stores the request caveats in the file storage area  83 , as shown at  86 . 
     Execution and control module  58  may also read survey database  68  via interface  70 . After the appropriate data elements are read from the survey database  68 , execution and control module  58  may again direct inference engine  60  to execute a number of rules  72 . The rules may generate the desired results, and may further check the validity of the results. Execution and control module  58  may then provide the results to report generator  62  via interface  82 , and any result caveats to result caveat generator  66 . Report generator  62  and result caveat generator  66  may store the reports  84  and result caveats  88  in the file storage area  83 , respectively. 
     As indicated above, when a request from interface module  52  requires data from more than one survey, it may be desirable to correlate various questions of the various surveys. To do so, execution and control module  58  may provide a request to correlation module  90  via interface  91 . Correlation module  90  may read correlation tables  92  via interface  94 , and provide the desired correlation data between the various survey questions. 
     In addition, the interface module  52  preferably displays a listing of the generic questions for selection by the user when forming the user request. To determine the appropriate generic questions for a selected survey, the interface module  52  may access the correlation module  90  via execution and control module  58 , and retrieve the generic questions that correspond to the actual questions in the selected survey. 
     Once a user request is formed, the knowledge module may identify the actual question numbers and the appropriate surveys that correspond to the generic questions provided in the user request. The data requests provided by the knowledge module, either directly or indirectly to the survey database, preferably specify the actual questions numbers and the corresponding surveys to access. The data requests provided by the knowledge module may thus identify selected data elements within the survey database for analysis. 
     The execution and control module  58  may operate as a validation module when responding to a validation request. That is, in response to a survey validation request, execution and control module  58  may assemble a number of data requests. The data requests may request distribution reports, statistics reports, MGAP reports, etc. After the appropriate data elements and/or reports are read from the survey database  68 , execution and control module  58  may direct inference engine  60  to execute a number of rules  72 . The rules may generate the desired validation results. Execution and control module  58  may then provide the validation results to report generator  62  via interface  82 , and any result caveats to result caveat generator  66 . Report generator  62  and result caveat generator  66  may store the reports  84  and result caveats  88  in the file storage area  83 , respectively. 
     FIG. 4 is a block diagram showing in more detail the execution and control module  58  of FIG.  3 . The execution and control module  58  may include an analysis type module  122 , a data element determining module  124 , and a response determining module  128 . The analysis type module  122  determines the analysis type of the user request provided by the interface module. In a preferred embodiment, the analysis types include a strength analysis type, a weakness analysis type, an opportunity analysis type, a threat analysis type, a survey validation analysis type, etc. 
     Once the analysis type is determined, data element determining module  124  determines which of the data elements in the survey database are to be accessed. For some requests, the request itself may identify the data elements to be accessed. That is, the user request may indicate which questions from which surveys are to be processed. For other requests, however, the correlation table may be required to identify the appropriate questions within each of the surveys. 
     Data element determining module  124  provides a corresponding request to data module  126 , as shown. Data module  126  accesses the survey database and provides the resulting data objects to response determining module  128 . Response determining module  128  determines the requested response and provides the results to the report and caveat generators (see FIG.  3 ). 
     The desired response can be dependent upon a number of analysis parameters  130 . In accordance with one feature of the present invention, the analysis parameters  130  are user programmable. It is contemplated that response determining module  128  may determine the appropriate response by executing a number of rules via inference engine  60 . The analysis parameters  130  preferably are referenced by a number of these rules. Thus, the analysis parameters  130  may affect the results provided by the rules, and therefore, the response provided by response determining module  128 . 
     For each request, data module  126  may store the results in prior results file  134 . A search block  132  may be used to search the prior results file  134  before accessing the survey database. If a request from data element determining module  124  requires access to results that were already generated for a previous request, data module  126  may read the appropriate prior results file  134  and provide the appropriate results directly to response determining module  128 . Because accessing the survey database may require more time than simply accessing the prior results file  134 , this feature can save considerable time in processing a request. This is particularly true when data module  126  accesses the survey database via a survey analysis program, which must calculate and assemble a number of intermediate reports which are provided to response determining module  128 . 
     FIG. 5 is a block diagram showing in more detail the interface module  52  of FIG.  3 . Interface module  52  may include a request module  140 , and a response module  142 . The request module may aid the user in assembling the user requests which are provided to knowledge module  56  via interface  76 . The response module  142  aids the user in reading and viewing the reports and various caveats received via interface  98 . 
     It is contemplated that interface module  52  may include a script module  144 . Script module  144  is preferably coupled to request module  140 , as shown. In a scripting mode, request module  140  may provide the assembled user request to script module  144 , rather than to knowledge module  56 . Script module  144  may store a number of assembled user requests in a number of script files  146 , as shown. Upon a user&#39;s command, the assembled requests within a script file  146  may then be provided to knowledge module  56  from request module  140  via interface  76 . 
     Accordingly, this feature may allow a user to build a number of script files  146  without having to wait for the knowledge module to process the results. Thereafter, the user may execute all of the assembled requests within a script by simply executing one of the script files  146 . The request module  140  may then sequentially provide the assembled user requests within a selected script file to the knowledge module  56  in a batch like mode. 
     FIG. 6 is a block diagram showing a second illustrative embodiment of the present invention. In this embodiment, a rules based expert system is utilized. Rules are similar to conditional statements in a conventional computer program. However, rules are typically executed using an inference engine, which manages the application of the rules. A conventional program, by contrast, has to indicate explicitly when given conditional statements should be applied. The rules are defined by the application developer and are incorporated into the rules-based expert system. 
     The preferred rules based expert system is the KAPPA-PC programming environment. KAPPA-PC is available from IntelliCorp, Inc., and provides an object-oriented programming environment with an inference engine for rule-based reasoning. A further discussion of the KAPPA-PC programming environment can be found in the KAPPA-PC on-line help files, which are incorporated herein by reference. 
     The interface module  168 , knowledge module  170  and data module  196  are all preferably implemented using the KAPPA-PC programming language KAL. The interface module  168  helps a user  174  assemble a desired survey request, and preferably includes all necessary objects and methods to interact with the user including all input screens, RAP command prompts, analysis processing values (object attributes), response windows, etc. 
     To help the user focus the requests, the interface module  168  may allow the user to select one of a number of surveys, and any number of certain questions from the selected survey. Because corresponding questions in selected surveys may differ from one survey to another, the interface module  168  preferably displays a listing of generic questions for selection by the user when forming the user request. To determine the appropriate generic questions for a selected survey, the interface module  168  may access the correlation table  184  via data module  172 , and retrieve the generic questions that correspond to the actual questions in the selected survey. 
     After a request is assembled, the interface module  168  provides the user requests to knowledge module  170 . Knowledge module  170  determines which RAP reports will be required to derive the desired result. Knowledge module  170  may also determine a number of request caveats, as described above. After determining which RAP report are required to derive the desired result, the knowledge module  170  provides appropriate data requests to data module  172  via interface  182 . Data module  172  provides the data requests to survey analysis module  164  via interface  188 . Survey analysis module  164  executes the data requests. This typically includes accessing the survey database  166  and providing the requested RAP reports back to data module  172  via interface  190 . 
     Data module  172  may then parse the RAP reports received from the survey analysis module  164 , and provide a number of data objects to knowledge module  170 . Knowledge module  170 , using a number of rules, may then determine the requested results, and provide the requested results to interface module  168 . Knowledge module  170  may also provide a number of result caveats to interface module  168  via interface  194 . The user  174  may then view the request caveats, the desired results, and the result caveats. 
     In a preferred embodiment, the survey analysis module is implemented using the Research Analysis Program (RAP) available from Prognostics, Inc., located in Menlo Park, Calif. RAP is a software program developed by Prognostics to access a survey database and provide a number of reports. These reports often include a correlation report, a distribution report, a GAP report, a multi-GAP report, etc. The RAP manual, available from Prognostics, Inc., describes these various reports and the proper format for the corresponding data request provided by the knowledge module, and is incorporated herein by reference. 
     Generally, the correlation report determines the correlation between the importance and/or satisfaction in one segment of the survey database with the importance and/or satisfaction in another. The distribution report provides the number of responses in a segment of the survey database. The GAP report identifies the gaps between the importance and satisfaction responses for a particular segment of the survey database. The multi-GAP report identifies the gaps between the importance and satisfaction responses for a range of questions in the survey database. 
     While these RAP reports can be useful in analyzing survey data, it has been found that more complex reports are often desired. To produce these more complex reports, it has been necessary to generate selected reports offered by the RAP program, and then manually calculate the desired data elements therefrom. This is often tedious and error prone, particularly since the desired reports may have to be updated each time a new survey database is received. 
     For those situations where the reports provided by the RAP program are sufficient, the interface module  168  may allow a user  174  to provide direct RAP requests to knowledge module  170 . Knowledge module  170  may pass the direct RAP requests to data module  172 . Data module  172  may then pass the direct RAP requests to the RAP program  164 . The RAP program may execute the direct RAP requests, and provide corresponding reports to data module  172 . Data module  172  may then provide the reports to the interface module  168 , via knowledge module  170 . It is contemplated that the knowledge module  170  may generate request caveats and/or result caveats for the direct RAP requests. 
     For complex requests, interface module  168  may assemble a user request and provide the user request to knowledge module  170  via interface  180 . Knowledge module  170  performs a check of the user request and provides a number of request caveats to interface module  168  via interface  194 . Preferably, knowledge module  170  determines the request caveats by executing a number of rules using the inference engine within the KAPPA-PC environment. 
     Thereafter, the knowledge module  170  determines the appropriate data elements that are required to respond to the user request by executing a number of rules. The Knowledge Module may include references to a number of rules, some of which are generic (executed for each complex command), and others that are intended to be executed only for certain commands. For this reason, the knowledge module uses the KAPPA-PC notion of a rule-set for rule-based execution. 
     In addition, an object called “inference_network” may be provided in the object oriented database (see FIG.  54 D and FIG.  55 E). The inference network objects may contain many multi-valued slots (lists), where each slot corresponds to a rule set. The list of rules to be executed in each instance may be stored in the slot name, and the knowledge module may determine which rule sets to invoke. 
     As indicated above, the user request provided by the interface module preferably includes the text of a generic question. To identify the actual question number within the selected survey, the knowledge module  170  may access the correlation table  184  via the data module  172 . The correlation table may provide a cross-reference between the generic question text and the corresponding actual question numbers in each of the surveys. In this way, the knowledge module  170  may identify the data elements within the survey database that are required to respond to the user request. A further discussion of the correlation table  184  can be found with reference to FIG.  32 . 
     The knowledge module  170  provides a number of data requests to data module  172 , preferably identifying the appropriate data elements within the survey database. Data module  173  forwards the data requests to the survey analysis module  164 , wherein the data requests are executed. The survey analysis module  164  provides a number of resulting reports to data module  172 . In the preferred embodiment, the reports provided by the survey analysis module  164  are in an ASCII format. Data module  172  may parse the reports into a number of data objects, and provides the data objects to knowledge module  170 . 
     Using the data objects, knowledge module  170  determines the requested results. Knowledge module  170  may also determine a number of result caveats. The results and result caveats may then be provided to interface module  168 . 
     It is contemplated that data module  172  may store the data objects received from survey analysis module  164  in a prior results file  198 . Once a request is received by data module  172  from knowledge module  170 , data module  172  may search the prior results file  198  via search engine  196  to determine whether the requested data objects have already been generated and stored. If so, data module  172  may provide the requested data objects from prior results file  198  directly to knowledge module  170 , rather than regenerating the data objects via survey analysis module  164 . This may decrease the execution time for a corresponding request, particularly since the re-use of prior results objects can occur for different request types. 
     FIG. 7 is a block diagram showing an illustrative data processing system  210  in accordance with another embodiment of the present invention. The data processing system  210  includes an interface module  212 , a knowledge module  216 , and a file storage area  246 . The interface module  212  communicates with a user via interface  214 . The interface module  212  aids the user in assembling survey database requests, as described above. Interface module  212  provides the resulting request to execution and control module  218  of knowledge module  216 . 
     Preferably, execution and control module  218  checks the requests received from interface module  212  by initiating execution of a number of rules  236  via inference engine  220 . That is, execution and control module  218  may provide a request to inference engine  220  via interface  232 , wherein inference engine  220  may execute a number of selected rules. Execution and control module  218  may then receive the results from inference engine  220  via interface  234 , wherein execution and control module  218  may determine a number of request caveats. Execution and control module  218  provides these request caveats to request caveat generator  224  via interface  244 . Request caveat generator  224  stores the request caveats in the file storage area  246 , as shown at  250 . 
     Execution and control module  218  may also provide a corresponding request to data module  228 . Data module  228  determines the appropriate requests to submit to survey analysis module  240 . Survey analysis module  240  receives the requests from data module  228 , and performs the requests on the survey database  242 . The survey analysis module receives the results and provides the results to data module  228 . Data module  228  forwards the results to execution and control module  218 . It is contemplated that data module  228  may process the results prior to forwarding the results to execution and control module  218 . 
     Execution and control module  218  may initiate execution of the inference engine  220  to check the results. The inference engine  220 , by executing a number of the rules  236 , may provide a number of result caveats. Execution and control module  218  may then either provide the results directly to report generator  222  via interface  244 , or perform further processing on the results and provide those results to report generator  222 . Also, execution and control module  218  may provide the result to result caveat generator  226 . Report generator  222  and result caveat generator  226  may store reports  248  and result caveats  252  in the file storage area  246 . 
     As indicated above, when a request from interface module  212  requires data from more than one survey, it may be desirable to correlate various questions of the various surveys. To do so, execution and control module  218  may provide a request to data module  228 , which may then access correlation module  254 . Correlation module  254  may read correlation tables  256 , and provide the desired correlation data between the various survey questions. 
     In addition, the interface module  212  preferably displays a listing of the generic questions for selection by the user when forming the user request. To determine the appropriate generic questions for a selected survey, the interface module  212  may access the correlation module  254  via data module  228 , and retrieve the generic questions that correspond to the actual questions in the selected survey. 
     The execution and control module  218  may operate as a validation module when responding to a validation request. That is, in response to a survey validation request, execution and control module  218  may assemble a number of data requests. The data requests may request distribution reports, statistics reports, MGAP reports, etc. After the appropriate data elements and/or reports are read from the survey database  242 , execution and control module  218  may direct inference engine  220  to execute a number of rules  236 . The rules may generate the desired validation results. Execution and control module  218  may then provide the validation results to report generator  222  via interface  244 , and any result caveats to result caveat generator  226 . Report generator  222  and result caveat generator  226  may store the reports  248  and result caveats  252  in the file storage area  246 , respectively. 
     Finally, it is contemplated that execution and control module  218  may have a count block  258 . Count block  258  may count the number of times each rule or rule set is executed by inference engine  220 . If a rule or rule set is executed more than a predetermined number of times, the count block  258  interrupts the inference engine  220 . This provides an efficient way to detect when the inference engine  220  is stuck in a loop. 
     FIG. 8 is a diagram showing a preferred analysis control window in accordance with the present invention. The control window is generally shown at  300 , and includes a number of regions. A first region is the command mode region  302 . The command mode region  302  includes a direct RAP request selection and a complex request selection. The direct RAP request selection allows direct RAP requests to be provided to the research analysis program (RAP). When the direct RAP request is selected and the execute request button  310  is depressed, a direct RAP request is executed by RAP, and the corresponding RAP reports are generated. 
     In the illustrative diagram, the command mode region  302  shows the complex request mode selected. In this mode, analysis type region  306  provides a number of complex mode analysis types for selection (see, for example, FIG.  9 ). In the illustrative diagram, a strength type analysis is selected. 
     A survey name region  304  is also provided. The survey name region  304  allows a user to select one of a number of surveys from a survey database. In the illustrative diagram, a survey named CS96NA is selected. The survey question region  308  displays the survey questions that correspond to the selected survey. Preferably, the survey question region  308  displays a listing of generic questions that correspond to the actual question in the selected survey. This provides consistency to the questions listed in the survey question region  308 , regardless of the selected survey. The user may identify one or more of the items in survey question region  308  to further focus the analysis. None are selected in the illustrative diagram of FIG.  8 . 
     FIG. 9 is a diagram showing the analysis control window of FIG. 8, with the type of analysis region  306  expanded. As indicated above, a number of analysis types can be selected by the user. In the illustrative diagram, a strength analysis is selected, as shown at  320 . The resulting request is shown in the request region  322 . Other complex analysis types include weakness, opportunity, threat, behavior, GAP, importance, satisfaction, etc. 
     FIG. 10 is a diagram showing a preferred transaction viewer window, which is displaying the results of the strength analysis request of FIG.  9 . The execution of each request produces a transaction. The transaction viewer window  330  displays the results of each transaction. In the illustrative diagram, a transaction which has been given the name TR_ 0  is displayed, as shown at  332 . The request information that was used to generate the transaction is shown in the request region  338 . The request region  338  indicates that the results shown correspond to a strength type analysis, using a survey named CS96NA, and using the corporate baseline algorithm. 
     A view selection region is provided at  335 . The results button  334  is shown highlighted, indicating that the results are shown in the response transcript region  336 , rather than the request caveats or result caveats. 
     FIG. 11 is a diagram showing the transaction viewer window of FIG. 10, with the Result Caveats button selected. When the result caveat button  340  is selected, the response transcript region  342  displays the result caveats for the selected transaction. The request caveat button  341 , if selected, would display the request caveats for the selected transaction. 
     The transaction viewer window also may include an explain button  344 , as shown. The explain button, when selected, displays the rule sets and rules that were activated by the inference engine during the execution of the selected transaction. The display provided by the explain button is further described with reference to FIG.  12 . 
     FIG. 12 is a diagram showing an explanation viewer window. The explanation viewer window is activated by the explain button of the transaction viewer window (see, FIG.  11 ). The explanation viewer window has a rule set region  350  that shows the rule sets that were activated during a selected transaction. When a particular rule set is selected within the rule set region  350 , such as RS_XQT_STRENGTH_ 4  as shown at  352 , the rules within that rule set are displayed in rules region  354 . For example, the rules in rule set RS_XQT_STRENGTH_ 4  are shown at  354 . 
     By selecting a particular rule, for example, rule S_SET_REPORT as shown at  356 , the corresponding comment for that rule is displayed in the rule comments region  358 . Accordingly, the user can determine which rule sets and rules were activated for a selected transaction, and can further view the comments for each of the rules. 
     Each rule typically includes an IF clause, THEN clause, and a COMMENT. As indicated above, the comment is accessed through the Explain button by selecting a rule within a rule set. An “Explain” object instance is created for every transaction, and includes the list of rule sets invoked during the transaction. 
     FIG. 13 is a diagram showing the transaction viewer window of FIG. 10 after a subsequent weakness request is executed. The transaction region now shows two transactions including TR_ 0  and TR_ 1 , with TR_ 1  selected. The corresponding results are shown at  366  in the response transcript region  366 . By selecting the appropriate transaction in the transaction region, the corresponding results are displayed in the response transcript region  366 . 
     FIG. 14 is a diagram showing the analysis control window of FIG. 8, with the Product Vendor question selected. As can be seen, a complex request is selected at  372 , and a strength analysis type is selected at  376 . The survey name CS96NA is selected at  374 , which provides a number of survey question selections in the survey question region. As indicated above, a number of generic questions are displayed in the survey question region. 
     In the illustrative diagram, the generic question “product vendor” is selected at  378 . The available answers to the product vendor question for the survey CS96NA are displayed in the response region adjacent to the survey question region. The available answers are obtained by accessing a MQA routine. Preferably, the MQA routine accesses a MQA table that is provided by the survey database vendor. The MQA table stores the available answers to each question in a survey. 
     The user may select one or more of the product vendor responses. In the illustrative diagram, the UNISYS product vendor is selected at  380 . The request region  382  displays the resulting request. The user may execute the request by depressing the Execute Request button  384 . 
     FIG. 15 is a diagram showing the resulting transaction viewer window after the execute request button of FIG. 14 is depressed. A description of the request is shown at  394 , indicating that a product vendor of Unisys is selected. The corresponding results are shown in the response transcript region  398 . 
     FIG. 16 is a diagram showing an illustrative analysis control window with an opportunity analysis type selected. The complex request command mode is selected at  402 , and an opportunity analysis type is selected as shown at  406 . An opportunity analysis determines those areas that a particular vendor has an opportunity for gaining market share over other vendors. In the example shown, the primary request selects the survey name CS96NA at  404 , and a Product Vendor of UNISYS at  408  and  410 , respectively. 
     The secondary request selects survey CS96NA as shown at  412 , and a Product Vendor of IBM at  414 . The resulting opportunity request is shown in the request region  418 . 
     If a product vendor is selected that is not in competition with, or is otherwise determined to be not compatible with UNISYS, for example, then the system may generate a request caveat indicating the incompatibility. In another example, if an opportunity request is assembled which compares two product types which are incompatible (like a main frame versus a PC), then the system may generate a request caveat indicating the incompatibility. It is contemplated that a user may select a different survey name, survey question and/or survey answer. 
     FIG. 17 is a diagram showing a SWOT editor window for editing SWOT parameters. Preferably, some of the rules within the expert system have parameters or variables that can be set or changed by the user. The SWOT editor window  440  provides an interface for changing these variables and/or parameters. The SWOT editor window first allows a user to select one of a number of SWOT algorithms. The acronym “SWOT” refers to one of the Strength, Weakness, Opportunity or Threat analysis types. 
     The first SWOT algorithm shown is entitled client significant. The client significant algorithm (importance×satisfaction) analyzes the client satisfaction data using the hypothesis that the relationship between importance and satisfaction reveals whether the vendor is meeting the client&#39;s expectations. On the opposite end of the continuum, a client that rates a vendor low on both importance and satisfaction, thus having a low satisfaction and importance product, is indicating to the vendor that the vendor is systematically out of sync with the client&#39;s expectations. The result of the client significant algorithm is a continuum of questions ordered on the cumulative effect of the importance/satisfaction product, and allows the user to evaluate the need for changes in business unit strategy. 
     The second SWOT algorithm is entitled repurchase contributors. The repurchase contributors algorithm (using MGAP times correlation to repurchase, filtered for high importance, low GAP, and high correlation to purchase intent) provides the vendor with an analysis of the client&#39;s importance/satisfaction GAP and the correlation with the client&#39;s intent to repurchase the vendor&#39;s products. This algorithm uses only paired responses (questions that have both importance and satisfaction responses) to perform the analysis. The hypothesis used by this analysis type is that the most important things to improve are those things that correlate with the client&#39;s intent to repurchase. 
     The next algorithm selection is entitled client satisfiers. The client satisfiers algorithm (using MGAP times correlation to repurchase filtered for high importance, low GAP and high correlation to satisfaction) provides the vendor with the client&#39;s importance/satisfaction GAP in a particular area, and the correlation thereof with the client&#39;s overall satisfaction with the vendor. This algorithm also only uses paired responses to perform the analysis. The hypothesis of the client satisfiers analysis type is that the most important things to improve are those things that correlate with the client&#39;s overall satisfaction. 
     The next algorithm selection is entitled corporate baseline (overall satisfaction). The corporate baseline algorithm (overall satisfaction) uses the STAT GAP times correlation to repurchase filtered for high importance, low GAP, and high correlation to satisfaction. The corporate baseline algorithm (overall satisfaction) provides the vendor with the client&#39;s importance/satisfaction GAP, and the correlation thereof with the client&#39;s overall satisfaction with UNISYS. This algorithm uses all importance and satisfaction responses in the sample set in order to perform the analysis. The hypothesis of this analysis is that the most important areas to improve are those things that correlate with the client&#39;s overall satisfaction. 
     The next algorithm selection is entitled corporate baseline (repurchase). The corporate baseline (repurchase) algorithm uses MGAP times correlation to repurchase filtered for high performance, low GAP, and high correlation to repurchase intent. The corporate baseline algorithm (repurchase) provides the vendor with the client&#39;s importance/satisfaction GAP, and the correlation thereof with the client&#39;s intent to repurchase the vendor&#39;s products. This algorithm uses all importance and satisfaction responses in the sample set in order to perform the analysis. The hypothesis is that the most important areas to improve are those things that correlate with the client&#39;s intent to repurchase. 
     The last algorithm selection is entitled custom. The custom analysis type allows the vendor to configure the analysis based on various SWOT parameters including the correlation question, correlation cut-off, GAP, importance, etc. 
     The SWOT editor window  440  shows the corporate baseline (overall satisfaction) selected at  442 . With this selected, a number of corresponding system settings and/or parameters may be changed by the user, including the report cardinality  440 , the minimum value answers  446 , the strength composite  450 , and the weakness composite  448 . These parameters may be used by selected rules when a request is executed. 
     Each of the algorithms in the SWOT editor screen is assigned a unique number, X=1. . . n, which corresponds with rule sets RS_init_strength_X, RS_xqt_strength_X, etc. Each algorithm therefore may have an unlimited number of rules associated with initialization and execution in order to generate the desired composite value. The “Custom” or “build-your-own” algorithm uses the values from the SWOT Editor objects as parameters in the rules associated with that selection. 
     FIG. 18 is a diagram showing a script editor window in accordance with the present invention. The script editor window allows the user to manage scripts of requests. Referring briefly back to FIG. 16, the analysis control window allows the user to copy a request to a script via button  489 , rather than execute the request. Thus, a number of requests can be assembled by the user and saved to a script file. At a later date, for example when a subsequent survey database arrives, the user may execute one or more of the script files. 
     Referring specifically to FIG. 18, a script entity may be selected at  472 . Once selected, the contents of the script entity are displayed in the request window  474 . The script can be cleared via button  476 . The order of the requests within the script entity can be rearranged by deleting or moving a currently selected request via buttons  478 ,  480 , and  482 . The resulting script may be saved via button  486 . Finally, a particular script may be loaded or appended to a current script via button  484 . The script may be executed by simply depressing the execute script button  488 . 
     FIG. 19 is a table showing an illustrative correlation table. The correlation table is generally shown at  500  and includes a generic heading column  502 , and a number of survey columns  504 ,  506 ,  508  and  510 . Each of the survey columns corresponds to a particular survey within the survey database. For example, the survey shown in column  504  may have been taken in 1995, while the survey shown in column  506  may have been taken in 1996. On one embodiment of the present invention, the correlation table correlates each of the questions within each survey to a generic question. For example, generic heading- 1  corresponds to question  122  for surveys S- 1  and S- 2 , and question  143  for surveys S- 3  and S- 4 . 
     Under some circumstances, some of the surveys may not have a question that correspond to a generic heading. For example, surveys S- 1  and S- 2  do not have questions that correspond to generic heading- 2 . By using such a correlation table, questions within a particular survey can be identified as corresponding to a request that relates to a particular generic heading. 
     As indicated above, a result caveat may be provided when a comparison is requested between, for example, surveys S- 2  and S- 3  with respect to the area addressed by heading- 2 . That is, the system may provide a result caveat that indicates there is insufficient data in survey S- 2  to provide a statistically significant result, if appropriate. 
     FIG. 20 is a functional diagram showing the interaction of the interface module, knowledge module and data module of the preferred embodiment of the present invention. The diagram is generally shown at  548 . The interface module  552  receives user inputs, user script inputs, server batch requests, etc., as shown. 
     To help the user focus the requests, the interface module  552  may allow the user to select one of a number of surveys, and certain questions from the selected survey. Because corresponding questions in selected surveys may differ from one survey to another, the interface module  552  preferably displays a listing of generic questions for selection by the user when forming the user request. To determine the appropriate generic questions for a selected survey, the interface module  552  may access the correlation table  559  via data module  554  and interface  556 , and retrieve the generic questions that correspond to the actual questions in the selected survey via interface  557 . 
     Likewise, the interface module  552  may allow the user to select one of a number of answers to a selected question. The available answers are obtained by accessing a RAP MQA file  563  via data module  554  and interfaces  556  and  557 . The RAP MQA file includes the available answers to each question in a survey. 
     After a request is assembled, the interface module  552  provides the requests to knowledge module  558  via interface  560 . Knowledge module  558  may then determine a number of request caveats for the user request, preferably using a number of rules executed by a rules-based expert system. The request caveats may then be provided back to interface module  552  via interface  572 . 
     Knowledge module  558  determines which data requests are required to provide the requested results. When determining the appropriate data requests to access the survey database, knowledge module  558  may gain access to the correlation table  559  via data module  554 . Correlation table  559  may provide a correlation between generic questions provided in the user request to question numbers in the various surveys. Thus, knowledge module  558  may determine which data elements in the survey database to access. Knowledge module  558  provides a number of data requests to data module  554 , via interface  562 . 
     Data module  554  submits the data requests provided by the knowledge module  558  to a survey analysis program, and preferably to the RAP survey analysis program. Data module  554  may submit the data requests as a batch RAP command  556 , which may execute the RAP requests in a batch mode. The RAP survey analysis program may then provide a number of intermediate RAP reports  561  to data module  554 . The intermediate RAP reports  561  may be in an ASCII text format. Data module  554  may then parse the intermediate RAP reports  561  into a number of data objects, and may send the resulting data objects to knowledge module  558  via interface  570 . 
     Knowledge module  558  uses the parsed intermediate reports and/or data objects to calculate and/or assemble the desired reports. Preferably, this is accomplished by executing a number of rules in a rules-based expert system. The desired reports are then provided to interface module  552  via interface  572 , and stored as a number of analysis reports  576 . 
     It is contemplated that knowledge module  558  may determine a number of result caveats, preferably by executing a number of rules on a rules-based expert system. The result caveats may indicate if the desired results should be viewed with caution. For example, the result caveats may indicate if the results provided to the user are based on a statistically insignificant sample size. 
     FIG. 21 is a flow diagram showing the general execution of a request in accordance with the preferred embodiment of the present invention. Initializing block  600  clears the transaction viewer and attaches a first user request. The first user request is sent to the knowledge module for verification. Verifying block  602  verifies the user request and appends any appropriate request caveats to a list of request caveats. If the user request is determined to be appropriate, control is passed directly to executing block  606 . If the user request is not determined to be appropriate, verifying block  602  asks whether the user request should be executed anyway. If the user indicates that the user request should be executed anyway, control is passed to executing block  606 . If, the user indicates that the user request should not be executed anyway, control is passed to viewing block  604 . 
     Executing block  606  executes the user request, and generates a number of results and result caveats. Control is then passed to viewing element  604 . Viewing element  604  displays the user request, the request caveats, the results, and the result caveats. 
     FIG. 22 is a low level object model of the preferred interface module. For illustration purposes, each transaction  622  may include a query class  624  and a result class  626 . It should be understood, however, that in the preferred embodiment, the query class  624  and the result class  626  are not actually provided, and are only shown for illustrative purposes. The query class  624  may include a SWOT entity class  628 , a request class  630  and a number of request caveat objects  632 . Preferably, the request caveat objects  632  are built by the knowledge module, and can be viewed by the user. 
     The request class  630  can be saved, independent of any system settings or parameters to support the scripting feature of the present invention. The request class  630  may include a simple RAP request class  634  and/or a complex request class  636 . The simple RAP request class  634  identifies specific RAP reports that are requested. The complex request class  636  identifies a specific SWOT request or survey analysis request. The result class  622  includes result data class  638  and a number of result caveats objects  640 . The results are preferably built using data objects provided to the knowledge module from the data module. 
     FIG. 23 is a composite object model for the preferred embodiment of the knowledge module. The knowledge module is shown at  650 , and may include query analysis class  652 , KM_AGENDA objects  654 , inference network class  656 , KM_REQUESTS class  658  and KM_RESULTS class  660 . Query analysis class  652  may include query execute class  662  and a query validation class  664 . Query execute class  662  builds the result objects, and sends the result caveats to the interface module. Query validation class  664  builds the request caveats and sends them to the interface module. KM_AGENDA objects  654  may store agenda objects which control the rule driven report generation and rule-set application by the inference network  656 . 
     The inference network class  656  may include rule-set objects  668  and explain objects  670 . Preferably, the inference network class contains a number of multi-valued slots (lists), where each slot corresponds to a rule set. The list of rules to be executed in each instance is stored in the slot name, and the knowledge module determines which rule sets to invoke. A list of rule sets for each type of SWOT analysis is shown in FIG. 51. A list of rules for each rule set is shown in FIGS. 52A-52C. A description of each rule is shown in FIGS. 55A-55O. Finally, inference network class  656  preferably stores a number of explanation objects  670  which correspond to each request. The explanation objects  670  are returned to the interface module to support the “explain” function. 
     KM_REQUEST class  658  preferably stores a number of objects that correspond to the knowledge module requests. The request objects are sent to the data module for processing. KM_RESULTS class  660  includes a SWOT results class  672 , a number of RAP result objects  674  and a survey results class  676 . SWOT results class  672  stores strength objects  686 , weakness objects  688 , opportunity objects  690  and threat objects  692 . The executed queries indicated at  662  provide the strength objects  686 , weakness objects  688 , opportunity objects  690  and threat objects  692 , as indicated by line  694 . 
     The survey results class  676  includes correlation objects  678 , GAP objects  680 , MGAP objects  682  and distribution objects  684 . The correlation objects  678 , GAP objects  680 , MGAP objects  682  and distribution objects  684  are created as a result of RAP requests made to the survey database. The strength objects  686 , weakness objects  688 , opportunity objects  690 , threat objects  692 , correlation objects  678 , GAP objects  680 , MGAP objects  682  and distribution objects  684  can be returned to the interface module. 
     FIG. 24 is a diagram showing a functional model of a SWOT (Strength/Weakness/Opportunity/Threat) analysis  700 . SWOT analysis  700  is initiated by a complex query  702 . The complex query  702  indicates whether a strength, weakness, opportunity or threat analysis is to be performed. SWOT analysis  700  determines the type of analysis to be performed, analyzes the request, and provides a number of request caveats  724 . This is preferably done by executing a number of rules in a rules-based expert system. 
     SWOT analysis  700  then provides a number of report requests to the data module, as shown at  720 . The data module  720  may generate a distribution report  704 , a MGAP report  706  and/or a correlation report  708 . The data module may either execute the requests directly on a survey database, or provide the request to a survey analysis program, as described above. SWOT analysis  700  then reads the distribution report  704 , MGAP report  706  and/or correlation report  708  returned as data objects from data module. From these reports, SWOT analysis  700  generates the appropriate results as shown at  710  through  718 , depending on the type of analysis performed. For example, if the request provided by the complex query  702  is a strength analysis, SWOT analysis  700  provides strength results  712 . In addition to providing the results, SWOT analysis  700  may provide a number of result caveats, as shown at  724 . Further, SWOT analysis  700  may indicate which rules and rule sets were executed during the SWOT analysis as shown at  722 . 
     FIG. 25 is a diagram showing a functional model of a strength analysis. The complex query is formed at  730  and provided to analyze request block  732 . Analyze request block  732  determines the type of request that has been provided. In the illustrative diagram, analyze request block  732  determines that the request provided by complex query  730  is a strength request, as indicated at  736 . Thereafter, analyze request block  732  creates the appropriate result objects, as shown at  734 . 
     Generate strength block  736  requests the appropriate reports from data module  738 . Data module  738  either directly access the survey database, or provides a request to a survey analysis program. In either case, the MGAP report  740 , distribution report  742  and correlation report  744  may be created. The generate strength block  736  reads the MGAP report  740 , distribution report  742  and/or correlation report  744 , and determines the requested strengths. The generate strength block  736  then stores the strengths under the proper strength instance, as shown at  746 . The strength data is then provided to send results block  748 , which sends the results to results block  750 . 
     Generate strength block  736  also checks the survey data at  756  and provides a number of result caveats, as shown at  758 . Finally, generate strength block  736  creates explanation objects, as shown at  752 , and provides the rules and rule sets that were executed during the strength analysis including comments therefor, as shown at  754 . 
     FIG. 26 is a diagram showing a functional model of a weakness analysis. The complex query is formed at  770  and provided to analyze request block  772 . Analyze request block  772  determines the type of request that has been provided. In the illustrative diagram, analyze request block  772  determines that the request provided by complex query  770  is a weakness request, as indicated at  776 . Thereafter, analyze request block  772  creates the appropriate result objects, as shown at  774 . 
     Generate weakness block  776  requests the appropriate reports from data module  778 . Data module  778  either directly access the survey database, or provides a request to a survey analysis program. In either case, the MGAP report  780 , distribution report  782  and correlation report  784  may be created. The generate weakness block  776  reads the MGAP report  780 , distribution report  782  and/or correlation report  784 , and determines the requested weaknesses. The generate weakness block  776  then stores the weaknesses under the proper weakness instance, as shown at  786 . The weakness data is then provided to send results block  788 , which sends the results to results block  790 . 
     Generate weakness block  776  also checks the survey data at  796  and provides a number of result caveats, as shown at  798 . Finally, generate weakness block  776  creates explanation objects, as shown at  792 , and provides the rules and rule sets that were executed during the weakness analysis including comments therefor, as shown at  794 . 
     FIG. 27 is a diagram showing a functional model of an opportunity analysis. The complex query is formed at  800  and provided to analyze request block  802 . Analyze request block  802  determines the type of request that has been provided. In the illustrative diagram, analyze request block  802  determines that the request provided by complex query  800  is an opportunity request, as indicated at  804 . Thereafter, analyze request block  802  creates the appropriate result objects. 
     Generate opportunity block  804  requests the appropriate reports from the data module. For an opportunity request, this includes both a strength analysis  806  for selection- 1  and a weakness analysis  808  for selection- 2 . Selection- 1  and selection- 2  may correspond to any selection set including selected vendors, geographic regions, products, years, etc. 
     The generate opportunity block  804  reads the results from the strength analysis  806  for selection- 1  and from the weakness analysis  808  for selection- 2 , and determines the requested opportunities for selection- 1 . The generate opportunity block  804  then stores the opportunities under the proper opportunity instance, as shown at  810 . The opportunity data is then provided to send results block  812 , which sends the results to results block  814 . 
     Generate opportunity block  804  also checks the survey data at  820  and provides a number of result caveats, as shown at  822 . Finally, generate opportunity block  804  creates explanation objects, as shown at  816 , and provides the rules and rule sets that were executed during the opportunity analysis including comments therefor, as shown at  818 . 
     FIG. 28 is a diagram showing a functional model of a threat analysis. The complex query is formed at  830  and provided to analyze request block  832 . Analyze request block  832  determines the type of request that has been provided. In the illustrative diagram, analyze request block  832  determines that the request provided by complex query  830  is a threat request, as indicated at  834 . Thereafter, analyze request block  832  creates the appropriate result objects. 
     Generate threat block  834  requests the appropriate strength and weakness analysis, as described above. For a threat request, this includes both a weakness analysis  836  for selection- 1  and a strength analysis  838  for selection- 2 . Selection- 1  and selection- 2  may correspond to any selection set including selected vendors, geographic regions, products, years, etc. 
     The generate threat block  834  reads the results from the weakness analysis  836  for selection- 1  and from the strength analysis  838  for selection- 2 , and determines the requested threats for selection- 1 . The generate threat block  804  then stores the threats under the proper threat instance, as shown at  840 . The threat data is then provided to send results block  842 , which sends the results to results block  844 . 
     Generate threat block  834  also checks the survey data at  850  and provides a number of result caveats, as shown at  852 . Finally, generate threat block  834  creates explanation objects, as shown at  846 , and provides the rules and rule sets that were executed during the threat analysis including comments therefor, as shown at  848 . 
     FIG. 29 is a diagram showing a functional model of a survey validation analysis. A survey validation request is a form of a complex request described above, and is shown at  870 . Using the survey validation request, block  872  requests the appropriate reports from the data module. The data requests are provided to the data module, as shown at  874 . In a preferred embodiment, the survey validation request causes the data module to submit the appropriate data requests to the RAP program, thereby generating distribution reports  876 , MGAP reports  892 , Correlation reports  894 , and/or other reports  900 . 
     The distribution reports  876  are provided to distribution checks block  878  and to demographic checks block  880 . Distribution checks block  878  checks the distribution of the respondents to various survey questions. For example, the distribution checks block  878  may check the distribution of survey respondents among several customer groups including financial customers, government customers, commercial customers, etc. The results are provided to results block  890 . If the number of respondents from any group is outside of a predetermined range, the distribution checks block  878  may provide a result caveat to caveats block  891 . 
     The demographic checks block  880  may check the distribution of respondents on a geographical basis. The results are provided to results block  890 . If the number of respondents from any geographic area is outside of a predetermined range, the distribution checks block  878  may provide a result caveat to caveats block  891 . 
     The MGAP reports  892  are provided to paired response check block  896 . Paired response check block  896  checks the gaps between importance and satisfaction for various survey questions. The results are provided to results block  890 . If the gaps are outside of a predetermined range, the paired response check block  896  may provide result caveats to caveats block  891 . 
     The statistics reports  894  are also provided to paired response check block  896 . Using the statistics reports  894 , paired response check block  896  may determine if only one answer is provided for a paired response. For example, the paired response check block  896  may determine if the respondent only answered the importance question, but not the satisfaction question for a paired response type question in a survey. The results are provided to results block  890 . If only one answer is provided for a paired response, the paired response check block  896  may provide a result caveat to caveats block  891 . 
     Finally, other reports block  900  provides other report to additional surveys check block  902 . Like above, additional survey check block  902  provides the results to results block  890 , and further provides a number of result caveats to caveats block  891 . 
     FIG. 30 is a diagram showing a functional model of the preferred data module. The data module is illustrated at  930  and receives requests from both the knowledge module  932  and the interface module  952 . 
     As indicated above, interface module  952  may display a listing of generic questions, which may be selected by the user when forming a user request. To determine the appropriate generic questions for a selected survey, the interface module may access the correlation data  946  via the data module  930 , and retrieve the generic questions that correspond to the actual questions in the selected survey. 
     Likewise, the interface module  952  may allow a user to select one of a number of answers to a selected question. The available answers are obtained by accessing the question/answer (MQA) data block  950  via data module  930 , as shown. The question/answer data block  950  includes the available answers to each question in a survey. 
     Once a user request is formed, the request is provided to knowledge module  932 . Knowledge module  932  may identify the actual question numbers and the appropriate surveys that correspond to the generic questions provided in the user request. This is preferably accomplished by accessing correlation data  946  via data module  930 , as described above. 
     The knowledge module  932  assembles a number of requests, and provides the requests to the data module  930 . Preferably, the requests identifies the appropriate data elements within the RAP report data  940  by specifying the actual question numbers and the corresponding survey. 
     It is contemplated that some requests may only request RAP reports from the RAP program. These requests are specified by selecting the RAP command mode in the analysis control window, shown for example in FIG.  8 . For these requests, the data module  930  may provide the requests directly to RAP activity manager  936  via interface  931 . The RAP activity manager may execute the requests, preferably in a batch mode as shown at  944 . The resulting RAP reports may then be provided back to data module  930  via interface  933 , and returned to the interface module  952  via knowledge module  932 . 
     For complex requests, knowledge module  932  may determine which RAP requests are required to derive the desired results. The knowledge module  932  sends the resulting RAP requests to data module  930 . When data module  930  receives the RAP requests from knowledge module  932 , data module  930  provides the requests to report block  934 . Report block  934  provides the RAP requests to RAP activity manager  936 . 
     RAP activity manager  936  accesses the RAP report data  940  and provides the requested RAP reports to RAP activity manager  936 . Preferably, the RAP activity manager  936  provides a batch RAP request  944  to RAP for batch processing. The RAP activity manager  936  receives the requested reports from RAP, and provides the RAP report data to the report block  934 . Report block  934  then preferably parses the RAP reports, which are typically in an ASCII format, into a number of requested data objects. The request data objects are then returned to knowledge module  932  via data module  930  for further processing. 
     FIG. 31 is a diagram showing a consolidated low level object model of the preferred data module. RAP activity manager  936  includes RAP batch interface  960  and RAP file manager  962 . RAP batch interface  960  allows batch execution of RAP requests, as shown at  944 . The output of the batch execution of RAP requests is provided to RAP report data store  961 . RAP file manager  962  may read the RAP report data store  961  and provide the results to RAP report parser  964 . RAP activity manager  936  may control RAP report parser  964 . RAP report parser  964  parses the survey data  966  into a number of data objects. For example, RAP report parser  964  may provide distribution objects  968 , correlation objects  970 , statistics objects  972 , direct objects  974  and GAP objects  976 , as shown. 
     As indicated above, a correlation table manager  978  may access a correlation table  980  to provide a correlation between questions in various surveys. Correlation table  980  may include question strings  982  and survey translation objects  984 . 
     FIG. 32 is a diagram showing a functional model of a preferred correlation table manager. Correlation table manager  1040  receives correlation data requests  1042  from the data module. Correlation table manager  1040  provides the survey correlation request to correlation table  1044 . Correlation table  1044  is updated from the correlation table data store  1046  whenever a new correlation table is generated, for example, whenever a new survey is received and incorporated into the system. 
     A correlation data request  1042  may provide a generic question, and may request an actual question number in a selected survey. As indicated above, this type of request is often provided by the knowledge module. The correlation table manager provides the request to correlation table  1044 . Correlation table provides a text-to-question correlation request to survey-xlation block  1052 . In response, survey-xlation block  1052  provides the corresponding question number to correlation table  1044 . The corresponding question number is then provided to the requester via correlation table manager  1040 . 
     Another type of correlation data request  1042  is a generic text request. It is often desirable for both the data module and knowledge module to translate from a question number to a corresponding generic question. For example, the data module may receive a number of RAP reports in response to a RAP request. The RAP reports only include the question text from a specific survey. Before transferring the RAP reports, it may be desirable to translate the question text in the RAP reports to a corresponding generic question string. 
     To do this, the data module may provide a correlation data request to correlation table manager  1040 . The correlation table manager  1040  provides the request to correlation table  1044 . Correlation table  1044  provides a generic question request to question string block  1050 . The generic question request may identify both the question number and the specific survey. In response, the question string block  1050  may provide the corresponding generic question string to correlation table  1044 . The corresponding generic question string may then be provided to the requestor via correlation table manager  1040 . 
     Likewise, it may be desirable for the knowledge module to translate from a question number to a generic question string. For example, the knowledge module may perform a strength type analysis. The data module may parse the resulting RAP reports into a number of data objects, and provide the resulting data objects to the knowledge module. It may be desirable for the knowledge module to translate the question text within the reports to the corresponding generic question string before providing the results to the interface module. This translation operates similar to that described above with respect to the data module. 
     FIG. 33 is a table showing the execution of an illustrative direct RAP request, with a problem detected in the request. The user first enters a direct RAP command via the interface module. The interface module creates a simple RAP object for further analysis. The simple RAP object is sent to the knowledge module for verification. The knowledge module receives the simple RAP object and uses rules to check for problems in the request. Problems that are detected include syntax errors or requests that are determined to be not appropriate. The problems are noted and a number of request caveats provided. The request caveats are sent back to the interface module. The interface module appends the request caveats to a listing. The user then views the request caveats. 
     FIGS. 34A-34B show the execution of an illustrative direct RAP request, when no problems are detected in the request or when the user indicates that the request should be executed despite the detected problem. The user enters the RAP command, and the interface module accepts the RAP command. The interface module creates a simple RAP object for further analysis. The simple RAP object is then sent to the knowledge module for verification. 
     The knowledge module receives the simple RAP object and uses rules to check for problems in the request. The knowledge module notes any problems, and updates the request caveats. The request caveats are sent back to the interface module. The interface module then appends the request caveats to a listing. 
     The knowledge module also sends the RAP command to the data module. The data module receives the RAP command object, and creates batch commands therefrom. The data module executes the batch command and returns the direct RAP objects. The knowledge module previews the RAP results and sends the RAP results to the interface module. The interface module appends the results, and displays the results to the user. The user then views the results, and the result and request caveats. 
     FIGS. 35A-35B show the execution of an illustrative strength/weakness/opportunity/threat analysis, when problems are detected in the request. The user selects one or more surveys and request a strength, weakness opportunity or threat analysis. The interface module accepts and checks the request. The interface module also creates a complex query object and sends the complex query object to the knowledge module. 
     The knowledge module receives the complex query object, and evaluates the analysis inputs. The knowledge module determines the type of reports needed to validate the request, and creates the knowledge module request for the data module. 
     The data module receives the knowledge module request object and checks for existing reports/objects that correspond to the knowledge module request. If not found, the data module runs the appropriate RAP report, and generates the corresponding objects. In either case, the data module returns the requested objects to the knowledge module. 
     The knowledge module examines the returned objects and generates request caveats based on knowledge module rules. The knowledge module also creates a number of result caveat objects and sends them to the interface module. The interface module receives the results, request caveats, and result caveats, and displays them to the user. 
     FIGS. 36A-36C show the execution of an illustrative strength or weakness analysis, when no problems are detected in the request or when the user indicates that the request should be executed despite the detected problem. The user selects one or more data survey databases and requests a strength or weakness analysis. The interface module accepts and checks the command, and creates a complex query object. The interface module then sends the complex query object to the knowledge module. 
     The knowledge module receives the complex query object, and determines the type of reports needed. For example, the complex query object may indicate to which products or vendors the request is directed. The knowledge module creates knowledge module request objects for the data module and sends the knowledge module request objects to the data module. 
     The data module receives the knowledge module request objects. The data module checks existing reports and objects to determine if these objects have been previously generated. If not, the data module runs the appropriate RAP reports and generates appropriate objects. In either case, the data module returns the appropriate results objects to the knowledge module. 
     In a preferred embodiment, the result objects includes MGAP objects. The knowledge module looks through the MGAP objects and determines which of the MGAP objects are strengths or weaknesses based on a number of rules. The knowledge module then creates a result object stream and sends it to the interface module. The interface module receives the appended result and displays it to the user. The user receives the strength or weakness analysis results, and the corresponding request and result caveats, if any. 
     FIGS. 37A-37C show the execution of an illustrative threat or opportunity analysis, when no problems are detected in the request or when the user indicates that the request should be executed despite the detected problem. The user selects the appropriate survey information. This may include one or more surveys, vendors, products, etc. The user also selects an opportunity or threat analysis type. The interface module accepts and checks the command and creates a complex query object. The interface module sends the complex query object to the knowledge module. 
     The knowledge module receives the complex query object and determines the type of reports needed based on the products, vendors, etc. that are selected. The knowledge module creates multiple knowledge module requests for the data module based on vendor and product knowledge (e.g. rules). The knowledge module then sends the multiple knowledge module requests to the data module. 
     The data module receives the knowledge module request objects and checks existing reports and objects to see if these objects have been generated by a previous request. If not found, the data module runs the appropriate RAP reports and generates the appropriate objects. In either case, the data module returns the result objects to the knowledge module. 
     In a preferred embodiment, the result objects include MGAP objects. The knowledge module looks through the MGAP objects and determines which are strengths or weaknesses based on predefined rules. The knowledge module compares these strengths and weaknesses, based on the selected vendors and/or products, and determines which are threats and which are opportunities. The knowledge module creates a result object stream and sends the result object stream to the interface module. 
     The interface module receives the appended results and displays the results to the user. The user receives the threats or opportunities analysis results, and the corresponding request and result caveats, if any. 
     FIG. 38 is a table showing the execution of an illustrative survey validation request, with request problems detected. The user enters a survey validation request. The interface module accepts the survey validation request, and creates survey validation objects for further analysis. The survey validation objects are sent to the knowledge module for verification. 
     The knowledge module receives the survey validation objects, and uses a number of rules to check for problems in the request. The knowledge module notes any problems and updates the request caveats. The knowledge module sends the request caveats back to the interface module. The interface module appends the request caveats, and the user views the appended survey validation request caveats. 
     FIGS. 39A-39B show the execution of an illustrative survey validation request, when no query problems are detected or when the user indicates that the request should be executed despite the detected problems. The user enters the appropriate survey information and requests a survey validation. The survey validation request is a form of a complex request. The appropriate survey information may include the selection of a particular survey. The interface module accepts and checks the survey validation request, and creates a survey validation object. The survey validation object is sent to the knowledge module. 
     The knowledge module receives the survey validation object and determines the type of reports needed based on the products, vendors, etc. The knowledge module then creates a number of data request objects, and provides the data request objects to the data module. 
     The data module receives the data request objects and checks existing reports/objects to determine if the requested reports/objects were already generated by a previous request. If not found, the data module runs the appropriate RAP reports and generates the appropriate result objects. In either case, the data module returns the appropriate result objects to the knowledge module. 
     The knowledge module looks through the result objects that were returned, and used rules to generates survey validation results. The knowledge module creates a result objects stream and sends the result object stream to the interface module. The interface module receives the appended results, and displays the results to the user. 
     FIG. 40 is a table showing the execution of an illustrative SWOT parameter update using the SWOT editor of FIG.  17 . The user enters SWOT and/or analysis parameters via the SWOT editor. The interface module accepts and checks the parameters entered by the user. The interface module informs the user of nonacceptable parameter values, if any. The interface module then allows the user to store or retrieve these parameters upon request. The user receives an updated display. 
     FIG. 41 is a flow diagram showing an illustrative method of the present invention. The algorithm is entered at element  1060  and control is passed to element  1062 . Element  1062  accepts a user request. Control is then passed to element  1064 . Element  1064  processes the request by executing selected ones of a number of predefined rules in a rules based expert system to provide a survey data request. Control is then passed to element  1066 . Element  1066  accesses the survey database in accordance with the survey data request, and provides a number of selected survey data elements. Control is then passed to element  1068 . Element  1068  processes selected ones of the selected survey data elements by executing selected ones of a number of predefined rules in a rules based expert system. Control is then passed to element  1070 . Element  1070  provides a result. Control is then passed to element  1072 , wherein the algorithm is exited. 
     FIG. 42 is a flow diagram showing another illustrative method of the present invention. The algorithm is entered at element  1200  and control is passed to element  1202 . Element  1202  provides a user request. Element  1204  checks the user request to determine if it is a valid request. If the request is not valid or otherwise questionable, a request caveat may be provided. Control is passed to element  1206 . Element  1206  determines which of the data elements in the survey data base are required to derive a response to the user request by, at least in part, executing a number of predefined rules in a rules-based expert system, thereby resulting in a number of selected data elements. Control is then passed to element  1208 . 
     Element  1208  reads the selected data elements from the survey data base, and passes control to element  1210 . Element  1210  determines the response to the request at least in part by executing a number of predefined rules in a rules-based expert system. Control is then passed to element  1212 . Element  1212  determines if the survey database has a sufficient number of selected data elements to derive a statistically significant response to the user request. Control is then passed to element  1214 , wherein the algorithm is exited. 
     FIG. 43 is a flow diagram showing the method of FIG. 42, with elements  1206 ,  1208  and  1210  of FIG. 42 replaced with elements  1220  and  1222  of FIG.  43 . Referring back to FIG. 42, after element  1204  checks the user request, element  1220  of FIG. 43 assembles a number of data requests using the rules-based expert system. Element  1220  further submits the number of data requests to a data module, and provides a number of requested intermediate reports to the rules-based expert system. Element  1222  uses the number of requested intermediate reports to calculate a number of entries in one or more reports that are provided to the user. Control is then passed to element  1212  of FIG.  42 . It is contemplated that element  1220  and element  1222  may be combined, wherein the data module may access the survey database and provides one or more reports that are then provided to the user. 
     FIG. 44 is a flow diagram showing another variation of the method shown in FIG. 42, with element  1206  of FIG. 42 is replaced with element  1228  of FIG.  44 . Element  1228  determines an analysis type of the user request, and determines which of the data elements in the survey database are required to derive a response to the analysis type of the user request. This is done, at least in part, by executing a number of predefined rules in a rules-based expert system, thereby resulting in a number of selected data elements. 
     FIG. 45 is a flow diagram showing another illustrative method of the present invention, including providing a request caveat in response to a user request. The algorithm is entered at element  1230 , and control is passed to element  1232 . Element  1232  provides a user request. Preferably, the user request identifies a predetermined algorithm and is formed by selecting a combination of a number of available selections via a graphical user interface. Control is then passed to element  1234 . 
     Element  1234  determines if the user request is an appropriate user request, even if the user request has a proper syntax. This may be accomplished by determining if the combination of selections made when forming the user request corresponds to one of a number of predetermined appropriate combination of selections. Control is then passed to element  1236 . Element  1236  reports if the user request is not an appropriate user request in one or more request caveats. This may include providing one or more reasons why the user request was determined to be not appropriate. Control is then passed to element  1238 . Element  1238  analyzes the database using the predetermined algorithm including accessing selected data elements. Control is then passed to element  1240 . Element  1240  provides a result. Elements  1238  and  1240  may be bypassed if the user wishes to change the user request before generating a result. Control is then passed to element  1242 , wherein the algorithm is exited. 
     FIG. 46 is a diagram showing a preferred analysis control window when a “gap” RAP command is selected without selecting a corresponding survey question. The control window is generally shown at  1250 . In the command mode region, a direct RAP request is selected, as shown at  1252 . A gap analysis type is selected at  1254 . In the illustrative diagram, a corresponding survey question is not selected as shown at  1256 . In accordance with a preferred embodiment, a gap analysis type requires at least one satisfaction/importance question to be selected before the GAP request is deemed proper. The resulting request is shown at  1258 . Note that the satisfaction/importance question has a value of null. 
     Once the request is formed by making the above selections, the user depresses the execute request button  1260 . Once the execute request button  1260  is depressed, the knowledge module analyzes the user request by executing a number of request caveat rules. In this case, the user request is determined to be improper. Thus, a continue query window  1262  is displayed. The continue query window  1262  indicates that the user request has at least one request caveat, and queries the user whether the analysis should still be continued. If the user desires to modify the user request, the user may select the “no” option. If, however, the user desires to process the request despite the request caveats, the user may select the “yes” selection. 
     FIG. 47 is a diagram showing the resulting transaction viewer window after the continue query window of FIG. 46 is affirmed. The transaction viewer window is generally shown at  1270 . The user request is displayed at  1272 . The request caveats button  1274  is shown selected to display the request caveats generated by the knowledge module. The corresponding request caveats are displayed in the response transcript window  1276 . In the illustrative diagram, the request caveat indicates that an importance question has not been specified, but is required. The results are preferably still provided to the user and may be displayed by depressing the results button  1278 . 
     FIG. 48 is a flow diagram,showing another illustrative method of the present invention, including providing a result caveat in response to a user request. The algorithm is entered at element  1290 , and control is passed to element  1292 . Element  1292  analyzes a survey database using a predetermined algorithm, including accessing selected data elements of the survey database. Control is then passed to element  1294 . Element  1294  provides a result. Control is then passed to element  1296 . 
     Element  1296  provides an indication of confidence in the result in one or more result caveats. Preferably, the number of result caveats are stored and displayed separately from the result. The indication of confidence may indicate, for example, if the number of selected data elements used in the analyzing step is insufficient to produce a statistically significant result. The indication of confidence may further indicate if the number of selected data elements is above a predetermined threshold, below a predetermined threshold, etc. Control is then passed to element  1298 , wherein the algorithm is exited. 
     FIG. 49 is a flow diagram showing another illustrative method of the present invention, including providing a result caveat in response to a user request. The algorithm is entered at element  1310 , and control is passed to element  1312 . Element  1312  analyzes a survey database using a predetermined algorithm, including accessing selected data elements of the survey database. Control is then passed to element  1314 . Element  1314  provides a result. Control is then passed to element  1316 . 
     Element  1316  provides an explanation of the result in one or more result caveats. Preferably, the one or more result caveats are provided separate from the result. The explanation of the result may identify, for example, the predetermined algorithm used, if any of a number of predetermined irregularities occurred during the analysis step, etc. The predetermined irregularities may include identifying selected portions of the database that are determined to differ from a predetermined expectation. A predetermined expectation may include having a database with sufficient data elements to produce a statistically significant result in response to a user request; having a certain distribution of responses for various survey questions, etc. Control is then passed to element  1318 , wherein the algorithm is exited. 
     FIG. 50 is a flow diagram showing yet another illustrative method of the present invention, including providing a result caveat in response to a user request. The algorithm is entered at element  1330 , and control is passed to element  1332 . Element  1332  provides a user request. Control is then passed to element  1334 . Element  1334  determines which of the data elements in the survey database are required to derive a response to the user request, thereby resulting in a number of selected data elements. Control is then passed to element  1336 . Element  1336  reads the selected data elements from the survey database. Control is then passed to element  1338 . Element  1338  determines the response to the user request. Control is then passed to element  1340 . 
     Element  1340  determines if the response should be viewed with caution. This is preferably accomplished by examining the selected data elements using a number of predetermined rules in a rules based expert system. Control is then passed to element  1342 . Element  1342  determines a number of reasons for viewing the response with caution if the determining step  1340  determines that the response should be viewed with caution. Control is then passed to element  1344 . Element  1344  provides the number of reasons for viewing the response with caution to one or more result caveats. Control is then passed to element  1346 , wherein the algorithm is exited. 
     FIG. 51 is a flow diagram showing another illustrative method of the present invention, including providing a result caveat in response to a user request. The algorithm is entered at element  1350 , and control is passed to element  1352 . Element  1352  provides a user request. Control is then passed to element  1354 . Element  1354  determines which of the data elements in the survey database are required to derive a response to the user request, thereby resulting in a number of selected data elements. Control is then passed to element  1356 . Element  1356  reads the selected data elements from the survey database. Control is then passed to element  1358 . Element  1358  determines a response to the user request. Control is then passed to element  1360 . 
     Element  1360  determines if the selected data elements read from the survey database are sufficient to derive a statistically significant response to the user request. Control is then passed to element  1362 . Element  1362  provides one or more result caveats if the selected data elements are determined to be insufficient to derive a statistically significant response to the user request. Control is then passed to element  1364 , wherein the algorithm is exited. 
     FIG. 52 is a flow diagram showing an illustrative method of the present invention for processing a survey validation request. The algorithm is entered at element  1430 , wherein control is passed to element  1432 . Element  1432  provides a survey validation user request. Control is then passed to element  1434  via interface  1438 . Element  1434  validates the survey database by performing a number of predetermined checks thereon, preferably by executing a number of predetermined rules in a rules-based expert system. Control is then passed to element  1436  via interface  1440 , wherein the algorithm is exited. 
     FIG. 53 is a flow diagram showing the method of FIG. 52, with element  1434  of FIG. 52 replaced with elements  1442 ,  1444  and  1446  of FIG.  53 . Referring back to FIG. 52, after element  1432  provides a survey validation user request, element  1442  of FIG. 53 accesses the survey database via a survey analysis module. Control is then passed to element  1444 . Element  1444  generates a number of intermediate reports. The intermediate reports may include distribution reports, MGAP reports, statistic reports, etc. Control is then passed to element  1446 . Element  1446  processes the number of intermediate reports to provide a number of validation results. This may include an indication of whether the survey database would provide misrepresentative results in response to selected user requests. Control is then passed to element  1436  of FIG. 52 via interface  1440 , wherein the algorithm is exited. 
     FIG. 54A shows an illustrative survey database  1450  including a number of surveys  1452 ,  1454  and  1456 . Each of the surveys is shown having a number of questions and a number of available answers. For example, survey  1452  has a question “IS”, indicated the industry sector of the respondent of the survey. The available answers include “G” for government, “C” for commercial, “F” for financial, and “S” for scientific. The respondent of survey  1452  has selected an industry sector of commercial. The other surveys  1454  and  1456  also include the industry sector question with the selected answers selected by the corresponding respondents. 
     Each of the surveys  1452 ,  1454  and  1456  also show a question labeled “GR”, indicating the graphical location of the corresponding respondent. The available answers include “N” for north, “S” for south, “E” for east, and “W” for west. As shown in survey  1452 , the eastern graphical region has been selected by the respondent. 
     FIG. 54B shows the distribution of responses for the available answers for the industry sector question. In the illustrative diagram, the number of respondents that selected the “G” government as their industry sector is shown at  1472 . The number of respondents that selected “C” commercial as their industry is shown at  1474 . The number of respondents that selected “F” financial as their industry sector is shown at  1476 . Finally, the number of respondents that selected “S” scientific as their industry sector is shown at  1480 . 
     The present invention may calculate a baseline distribution as shown at  1482 . This can be accomplished by dividing the number of survey respondents in the survey database by the number of available answers for a particular question. For example, if there are 1,000 surveys in the survey database and there are four available answers to the industry sector question, the baseline distribution  1482  for the industry sector question would equal 250 (1000/4). 
     The present invention may determine whether any of the available answers have more responses than is expected, based upon previous knowledge and previous survey results. For example, the present invention may determine whether the number of responses to an available answer is above an upper limit  1484 . Upper limit  1484  is determined by rules using knowledge gained from previous survey databases. 
     In the diagram shown, the number of respondents that selected the “C” commercial answer to the industry sector question is greater than the upper limit  1484 . The present invention may flag this condition and provide a result caveat to the user. The upper limit  1484  may be, for example, five times the baseline distribution  1482 . 
     The present invention may also determine if the number of responses to an available answer is less than a predetermined lower limit  1486 . If the number of responses of an available question is less than a predetermined lower limit  1486 , than a user request that uses that data may be based on a statistically insignificant sample size. In the diagram shown, the number of respondents that selected the answer “F” financial for the industry sector question falls below the predetermined lower limit  1486 . Thus, the present invention may flag this condition and report a result caveat to the user. 
     As indicated above, a user request can specify specific questions and specific answers for processing. For example, a user may select a product vendor of UNISYS and a product selection of 2200/900. The number of respondents that select the answer “F” financial to the industry sector question, and utilize a UNISYS 2200/900 computer system may be relatively small. The present invention may check the number of responses for selected answers in the survey database to ensure that corresponding user requests are based on a statistically significant sample size, or the user is notified otherwise. 
     FIG. 54C is a diagram that shows the number of responses for each of the four answers to the geographic region question. In the illustrative diagram, the number of respondents that selected “N” north as their geographic region is shown at  1502 . The number of respondents that selected “S” south as their geographic region is shown at  1504 . The number of respondents that selected “E” east as their geographic region is shown at  1506 . Finally, the number of respondents that selected “W” west as their geographic region is shown at  1508 . 
     The present invention may calculate a baseline distribution as shown at  1510 . Like above, this can be accomplished by dividing the number of survey respondents in the survey database by the number of available answers for a particular question. For example, if there are 1,000 surveys in the survey database and there are four available answers to the geographic region question, the baseline distribution  1510  for the geographic region question would equal 250 (1000/4). 
     The present invention may determine whether any of the available answers have more or less responses than is expected, based upon previous knowledge and previous survey results. For example, the present invention may determine whether the number of responses to an available answer is above an upper limit  1512  or lower limit  1514 . Like above, upper limit  1512  and lower limit  1514  are determined by experts using knowledge from previous survey databases and can be incorporated in a number of rules. 
     In the diagram shown, the number of respondents that selected the “S” south answer to the geographic region question is greater than the upper limit  1512 . The present invention may flag this condition and provide a result caveat to the user. Likewise, the number of respondents that selected the answer “E” east for the geographic question falls below the predetermined lower limit  1514 . Thus, the present invention may flag this condition and report a result caveat to the user. The lower limit  1514  may be set by the user, and preferably has a default value of 25. 
     FIG. 55 shows a survey database  1520 , including a number of surveys  1522 ,  1524  and  1526 . Each of the surveys has a first question and a second question, as shown. Survey  1522  includes answers to both question  1  and question  2 . However, surveys  1524  and  1526  only include answers to question  2 . Thus, it is contemplated that the present invention may identify those questions in the survey database  1522  that do not include answers. This may further help identify those portions of the database that may cause the user request to be based on any statistically insignificant sample size or otherwise skew the results thereof. 
     FIG. 56 is a flow diagram showing another illustrative method of the present invention, including providing a number of result caveats in response to a survey validation requests. The algorithm is entered at  1550 , and control is passed to element  1552 . Element  1552  provides a survey database that includes a number of surveys. Each of the surveys have a number of corresponding data elements, wherein selected data elements represent a selected one of a number of responses to a number of corresponding survey questions. Control is then passed to element  1554  via interface  1560 . Element  1564  checks the survey database by performing a number of checks on the survey database. Selected ones of the number of checks determine a selected distribution of the responses represented by selected data elements. Control is then passed to element  1556  via interface  1562 . 
     Element  1556  provides a number of validation results, and a number of result caveats. The result caveats preferably identify one or more portions of the survey database that are misrepresentative. Control is then passed to element  1558 , wherein the algorithm is exited. 
     FIG. 57 is a flow diagram showing the method of FIG. 56 with element  1554  of FIG. 56 replaced with element  1564  of FIG.  57 . Element  1564  checks the survey database by performing a number of checks on the survey database. Selected ones of the number of checks determine a selected distribution of the responses that correspond to a number of geographical locations. 
     FIG. 58 is a flow diagram showing the method of FIG. 56 with element  1554  of FIG. 56 replaced with element  1568  of FIG.  58 . Element  1568  checks the survey database by performing a number of checks on the survey database. Selected ones of the number of checks determine a selected distribution of the responses that correspond to a number of predetermined customer groups. 
     FIG. 59 shows a survey database  1600  including surveys  1602 ,  1604  and  1606 . Each of the surveys  1602 ,  1604  and  1606  show a category entitled “reliability”. For each category, each of the surveys  1602 ,  1604  and  1606  includes a question that solicits two responses. The first response indicates the overall importance of the category to the corresponding respondent. The second response indicates the overall satisfaction that the respondent has relative to the corresponding vendor, for example. In the example shown, the respondent that corresponds to survey  1602  has selected the response “3” for the importance response and “4” for the satisfaction response. Thus, the respondent of survey  1602  has indicated that reliability is fairly high in importance, and has further indicted a high satisfaction with the reliability provided by the vendor. In contrast, the respondent of survey  1604  has selected “1” for the importance response, and “4” for the satisfaction response. Thus, the respondent of survey  1604  has indicated that reliability is not real important, and has further indicated a fairly high satisfaction with the reliability provided by the vendor. 
     The difference between the importance selection and the satisfaction selection is often called a gap. It is contemplated that the present invention may identify those categories where the gap between the importance selection and the satisfaction selection is greater than a predetermined value. The predetermined value is based on knowledge assembled from previous surveys. Experts may determined that categories having a high gap may skew the results of selected user requests. Thus, it may be desirable to eliminate satisfaction data for a category that has a low importance response from a respondent. 
     FIG. 60 is a flow diagram showing another illustrative method of the present invention, including validating a survey database that has paired responses therein. The algorithm is entered at  1620  and control is passed to element  1622 . Element  1622  provides a system for analyzing a survey database via a number of user requests. In response to a user request, the system accesses the survey database and generates a corresponding result. The survey database has a number of surveys, wherein selected surveys have a number of common categories. Preferably, selected categories have at least one survey question that solicits two responses, such as importance and satisfaction. Control is then passed to element  1624 . Element  1624  checks the survey database by performing a number of checks thereon. Control is then passed to element  1626 . Element  1626  provides a number of validation results. Control is then passed to element  1628 , wherein the algorithm is exited. 
     FIG. 61 is a flow diagram showing another illustrative method of the present invention, including validating a survey database that has paired responses therein. The algorithm is entered at  1650 , and control is passed to element  1652 . Element  1652  provides a system for analyzing a survey database via a number of user requests. In response to a user request, the system accesses the survey database and generates a corresponding results. The survey database has a number of surveys, wherein selected surveys have a number of common categories. Each of the categories may have at least one survey question that solicits at least two responses from the corresponding respondent of each survey. Preferably, the first response elicits the perceived importance of that category to the survey respondent. The second response preferably elicits the perceived satisfaction of that category to the survey respondent. Control is then passed to element  1654 . Element  1654  checks if a gap between the perceived importance and perceived satisfaction exceeds a predetermined amount. Control is then passes to element  1656 , wherein the algorithm is exited. 
     FIG. 62 is a flow diagram showing a number of checks that may replace element  1654  of FIG. 61, or executed in addition thereto. Also, it is contemplated that each of the checks shown in FIG. 62 may be implemented alone or in combination with the other checks described therein. Element  1680  checks if any of the survey questions have less than a predefined number of responses. This check is further described with reference to FIGS. 54A-54C. Control is then passed to element  1682 . Element  1682  checks if any of the survey questions have greater than a predetermined number of responses. This check is further described with reference to FIGS. 54A-54C. Control is then passed to element  1684 . Element  1684  checks if the number of times a first response is selected exceeds the number of times a second response is selected by a predetermined amount, for a particular survey question. Control is then passes to element  1686 . Element  1686  checks if a selected survey question has a statistically insignificant number of responses associated therewith in the survey database. Control is then passed to element  1688 . Element  1688  checks if a selected category does not have a response for selected survey questions that correspond to the selected category. Control is then passes to element  1656  of FIG. 61, wherein the algorithm is exited. 
     For each of the checks described herein, a result caveat may be provided to the user. The result caveat may identify those portions of the survey database that caused the check to fail or otherwise be questionable. This may enable the user to identify those portions of the survey database that may provide misrepresentative results. 
     FIG. 63 is a table showing illustrative analysis types, and the corresponding rule sets that are associated therewith. In the left column, the preferred complex analysis types are shown. In the right column, the preferred rule sets are identified for each analysis type. When a particular analysis type is requested, the knowledge module executes each of the corresponding rule sets in the order indicated. 
     As indicated above, a number of request caveat rules may be executed to determine if the user request is proper. For example, the strength analysis type execute a rule set called RS_ver_analysis. The RS_ver_analysis rule set include a number of rules that check the user request to determine if the user request is proper, and provides a number of request caveats if necessary. 
     Likewise, a number of result caveat rules may be executed to determine if the results are misrepresentative or otherwise improper. For example, the survey validation analysis type executes a rule set called RS_xqt_val_dist. Both the RS_ver_analysis rule set and the RS_xqt_val_dist rule set are defined further with reference to FIGS. 64A-64C. 
     FIGS. 64A-64C show a table of preferred rule sets, and the corresponding rules that are associated therewith. In the left column, a number of rule set names are shown. In the right column, the preferred rules are identified for each rule set. When a particular rule set is executed by the knowledge module, the corresponding rules are executed by the inference engine as required. 
     As indicated above with reference to FIG. 63, the RS_ver_analysis rule set, for example, include a number of rules that check the user request to determine if the user request is proper, and provide a request caveat if necessary. The RS_ver_analysis rule set is shown in FIG. 64A, and includes, for example, a RAP_chk_importance rule. The RAP_chk_importance rule is defined below in FIG. 65B, and provides a request caveat if the command requires an importance selection, but one has not been selected (NULL). 
     Likewise, the rule set RS_xqt_val_dist includes a number of rules that check for misrepresentative or otherwise improper results. The RS_xqt_val_dist rule set is shown in FIG. 64C, and includes, for example, a v_chk_gt — 50pct rule. The v_chk_gt — 50pct rule is defined below in FIG. 65J, and provides a request caveat if a check for high concentration (more than 50 percent of all responses in this case) is being performed. 
     Many other rule sets shown in FIGS. 64A-64C provide either request caveats or result caveats, depending on the circumstances that the corresponding rule set is invoked. 
     FIGS. 65A-65O show a table of the preferred rules, along with corresponding rule comments. In the left column, a number of rule names are shown. In the right column, the corresponding rule comments are shown. The rule comments describe the action performed by the corresponding rule. 
     Many of the rules described in FIGS. 65A-65O provide either request caveats or result caveats. For example, and with reference to FIGS. 46-47, the rule RAP_chk_of_name shown in FIG. 65B provides a request caveat if a RAP command is selected but the ‘Analysis of’ value has not been supplied. That is, if proper selections are not made, the present invention may provide a request caveat to the user. 
     Likewise, each rule beginning with “v_chk_” may provide a result caveat to the user. For example, the rule v_chk_decrease provides a result caveat if the responses to a corresponding distribution are not increasing. Thus, as can readily be seen, the present invention contemplates providing a number of result caveats to the user. In addition to the rules specifically discussed above, 
     FIGS. 66A-66F shows an illustrative listing of the object oriented database before any analysis runs are executed. FIGS. 67A-67G shows an illustrative listing of the object oriented database before after a strength analysis type is executed. When comparing FIG.  66 D and FIG. 67D, it can be seen that a number of strength results are generated in the KM/KM_results/SWOT_results/strength class. 
     Having thus described the preferred embodiments of the present invention, those of skill in the art will readily appreciate that the teachings found herein may be applied to yet other embodiments within the scope of the claims hereto attached.