Extending and Validating the Business Rules Diagram Method Michael N Johnstone Donald C McDermid School of Information Systems Curtin University of Technology Perth, Western Australia
[email protected] Abstract This paper describes an action research study whose focus was assisting in the selection of a commercial "off the shelf" (COTS) software system. During the study the semantic gap between different representations of the problem domain was recognised as a potential issue which might affect the effectiveness of the process thus an intellectual framework based on a particular set of ontological ideas was used to guide the study. Two notable issues that arose from the study were how to implement feedback mechanisms into the process and how to manage the complexity of a real-world problem domain by using abstraction without losing important details.
Keywords Information Requirements Determination; IS Research Issues; Action Research.
BUSINESS RULES IN REQUIREMENTS ENGINEERING There is a lack of consensus within the information systems community as to what actually constitutes a business rule (Loosley 1992). Appleton (1988, p49) describes a business rule as 'an explicit statement which stipulates a condition that must exist in an information environment for information extracted from that environment to be consistent with organisational policy’. Sandy (1996) notes that the diversity of opinion ranges from critical success factors and quality goals at the one extreme to database integrity constraints at the other. For example, Jones (1991, p9) uses ‘employee ID is a numeric field between 1,000 and 3,000’ as a sample of a typical business rule. It is important that the definition of a business rule stipulates something of the context and nature of a business rule as well as identifying its constructs. McDermid (1998, p20) defines a business rule as ‘…an explicit state change context in an organisation which describes the states, conditions and signals associated with events that either change the state of a human activity system so that subsequently it will respond differently to external stimuli or reinforce the constraints which govern a human activity system’, a definition we shall use from here onwards.
THE BUSINESS RULES DIAGRAM Sibelius (1992) considers that the problem of conceptual modelling is twofold in that an accurate way must be found to describe the observable features of an object and that a minimum set of concepts must be found that describe the modelled object concisely. Ramaprasad et al. (1993) state that mental models are based on the idea that humans have limited information processing capabilities and thus use various knowledge structures such as frames, scripts cognitive maps and
Proc. 10th Australasian Conference on Information Systems, 1999
449
schemata to represent abstractions of reality. Johnson-Laird (1983 p10) described such models as follows: "human beings understand the world by constructing working models of it in their minds. Since these models are incomplete, they are simpler than the entities that they represent. In consequence, models contain elements that are merely imitations of reality there is no working model of how their counterparts in the world operate, but only procedures that mimic their behavior.". This is a point well-made by Wand and Weber (1993) who consider the mappings between the real world and the machine world (figure 1) to be approximations to the real world.
Reality
Script #1 Requirements document
Script #n Program
•••••••
Machine world
Figure 1: A mapping of reality to the machine world as a set of scripts. A business rule, as defined by McDermid (1998), contains four explicit constructs. These are states, events, conditions and signals, as shown in figure 2. Connected combinations of these constructs make up a Business Rule Diagram (BRD). States reflect the status of an object of interest at any given time, for example a furniture item order might traverse the states confirmed, delivered and paid. Events are actions carried out internally by the organisation. They are considered to be instantaneous occurrences that reflect the organisation’s policy on what should happen in a particular circumstance e.g. cancel order. One important role of the event is to avoid specifying processing detail. Rather, such “processing” detail is best kept separate from “policy” rules as will be discussed later. Conditions define the criteria by which objects of interest in the business move from one state to the next as events take place. Sometimes, many conditions must met in order for an event to take place, thus increasing complexity. It is argued that modelling conditions without the context of states and events (and vice versa) is far less powerful or useful. Lastly, signals either enter or leave the human activity system. Signals that enter the system typically initiate activity within the system and are called triggers. Triggers may be external such as a customer sending an order or internal such as one department sending a document to another department which then "triggers" some activity. Further, a trigger may be time-based e.g. an activity beginning at the start of each day or at the end of a month. Those signals which leave the system serve to inform those outside the system boundary about what has occurred inside the system and are called messages. An important additional construct is the Harel blob (Harel 1988), represented by a rounded rectangle, which acts as an encapsulator of other constructs and is used to model selection or simultaneous action. Business rules are divided into policy, processing and implementation-level rules as indicated in figure 3. Policy rules are the most general and are represented by externally verifiable state to state transitions. An example of a policy rule is: "an order is generated only when a customer accepts a quote". Typically, the states here would be solution accepted and order prepared with the intervening event being "prepare order". Here, the states are externally verifiable as the customer, who is external to the system, accepts a solution (i.e. a trigger) and is sent a confirmation of the order details (a message). Such a business rule tends to encompass several "partial" rules, which are not in themselves completely externally verifiable but act to provide a business domain or context for the policy rule. Examples of such partial rules relating to the abovementioned policy rule include "a
450
request form shall contain a complete list of customer requirements", "only approved quotations are ordered" and "a customer solution must be in the form of a written quotation".
state
event
signal
condition
blob
Policy Rule Figure 2: Key Constructs of the Business Rule Diagram The next level, processing rules, are more akin to formulae than to policies and thus may be considerably more complex. Examples of processing rules include: "a sales tax exemption number needs to be quoted on every purchase order" and "a commission of 6% will apply to all jobs". The lowest level, implementation rules, describe the system in detail and are beyond the scope of this study. To date, studies have been carried out concerning policy rules (McDermid, 1988) but this is the first study to examine the BRD method at a lower level, in this case, processing rules.
Policy Rules Processing Rules
Rules/conditions that determine which processes are executed or the way that objects (e.g. customers, orders) are treated Rules/conditions which describe how processes are executed (e.g. formulae) Rules/conditions which describe the
Implementation implementation of the information Rules system processes Figure 3: Business Rule Types McDermid (1998) indicates that the steps used in the method to create a BRD are: • identify candidate business (policy) rules; • identify candidate events and signals; • identify candidate objects; • construct Object Life Histories (OLHs); • construct User Business Rule Diagrams (UBRDs); • construct Business Rules Diagram; and • construct Event Specification Table (EST).
451
THE ACTION RESEARCH STUDY The BRD method is a new technique and as such is still emerging. This suggests that any research into the BRD should use a method that recognises the variability inherent in human interaction, fosters collaboration between the researcher and participants and encourages a dynamic learning environment. Action research, from an interpretivist perspective, provides this type of method. Action research has been criticised in the past for having a lack of structure or rigour, although this is a general problem with social science research rather than action research itself according to Baskerville and Wood-Harper (1992). The particular advantages of action research over other research methods that made it suitable for this study were: involvement of the researcher in the problem situation; working with participants in a co-learning environment to achieve a common goal; and that it is set in a real-world context/problem situation. To ameliorate concerns of a lack of rigour the FMA research structure (figure 4), as proposed by Checkland (1985), was used to guide the study.
Area of application Methodology M for using F F Intellectual Framework
Learning about F, M and A from the use of M
Figure 4: The Organised Use of Rational Thought, after Checkland, (1985) The components for this study were identified as: •
Framework (F) – An ontological framework based on the work of Bunge (1977, 1979) and Wand and Weber (1993, 1995) which provided a basis for reasoning about real world constructs. The constructs in this case are the components of a Business Rule and the syntax and semantics associated with the use of the Business Rules Diagram.
•
Methodology (M) – The methodology chosen for using the framework of ideas is Action Research.
•
Application (A) – The area of application is the Furnishings/Interior Design section of a large University.
The aim of the study was threefold: to use the BRD method in a more complex problem situation that had been done previously; to explore the business processes of a client, with the ultimate aim being to provide input into the software selection phase for a commercial “off the shelf” system, and; to examine, in a research context, the effectiveness of the BRD notation for representing processing rules via a Processing Rules Diagram (PRD).
452
Intellectual Framework Before discussing the details of the action research study a brief outline of the ontological model which provided an intellectual framework for the study is useful. The ontology of Bunge (1977, 1979) as refined by Wand and Weber (1993, 1995) was felt to be particularly suitable as a framework for the BRD as in Bunge's ontology systems are portrayed in terms of a tuple consisting of their composition, environment and structure. The composition of a system is the list of its parts, the environment consists of the things that act upon a system (or are acted upon by things within a system) and structure is the set of relations between the components of a system. Furthermore, Wand and Weber (1989) propose that a system may be represented by a tuple consisting of stable states, events and a law. It is this representation which provides a basis for reasoning about the BRD. For example, the Wand and Weber (1993) model embodies the concept of state to state transitions, represented by events, governed by some "law". As has been mentioned previously, policy rules in the BRD are represented by externally verifiable state to state transitions. Further, for a state to change, an event must take place. Clearly, such concepts map well into the Wand and Weber model, especially if the notion of external verifiability is considered to be a law. Area of Application The client group was the Interior Design section of a large Australian university. The participants in the study were: a business analyst with 15 years experience in information systems development and a group of five users with experience varying from one to seven years in the area of Interior Design and furniture purchase, maintenance and disposal. The analyst was experienced in data modelling and structured design techniques, and was trained in the use of the BRD method by the researcher prior to the commencement of the study. The Interiors group co-ordinates the purchase, disposal, recycling, maintenance and storage of furniture on both a project-oriented and an ad-hoc basis. The group has recognised that they have no mechanism for tagging and tracking the location of furniture and that they maintain duplicate records of transactions for requests, orders and deliveries in unconnected spreadsheets. The group wished to eliminate or reduce the duplication of data possibly by using a centralised workflow capability which would allow customer requests to be tracked easily. The first step towards such a system was for the group, with the analyst acting as facilitator, to model their existing business process using the BRD method. The study was staged to ensure that the participants did not suffer from “information overload” and thus maintained control and ownership of their business process model. The stages were defined thus: Stage 0: Analyst trained in method, users’ agreement gained to conduct the study. Stage 1: Generation of Business Rules (Team). Stage 2: BRD created and rules validated against diagram [iterative] (Team). Stage 3: EST created and validated against BRD (Analyst). Stage 4: Software Requirements Specification (SRS) generated (Analyst). Figure 5 shows the flow of each stage and where feedback (validation) occurred.
453
Stage 1: Generation of Business Rules (Team). During this stage the team reconstructed or articulated (identified) a large number of business rules (over 50) that were classified as policy, process or implementation rules. There was considerable discussion about the appropriate category (policy, processing or implementation) in which to place certain rules. This was perhaps because of the widely differing roles that each team member performed in the work environment, as each would tend to have a different “world-view” of the complete business process. This was, however, a very fruitful unstructured “brainstorming” session that assisted in reinforcing team ownership and control of the BRD process.
Use Cases
Business Rules UBRD/ OLH
Business Rules Diagram (BRD) Check rows in table against rules
Problem Statement (unstructured)
Software Requirements Specification (SRS)
Check functional requirements against rules Event Specification Table (EST)
Figure 5: The Development Sequence Stage 2: Creation/Validation of BRD. This stage was conducted in two distinct phases with an intervention by the researcher between the phases. In the first phase, conducted over a period of seven weeks, the team created the BRD, then the researcher interviewed the entire team in a semi-structured interview situation. Following this, the analyst created a second BRD, based on feedback received from the interviews and discussions with the researcher. The first phase was interactive, with all team members contributing to the development of the BRD. Many different views of the business process were expressed and discussed thoroughly, as could be expected from a motivated group who all have different roles within that business process. At the conclusion of this phase, the researcher conducted semi-structured interviews with each member of the team, including the analyst. The interview questions were structured in such a way as to examine and draw out the participant’s perceptions and attitudes about each of the Framework of ideas, Methodology and Area of application, recalling Checkland’s (1985) research structure, within the context of the hypotheses/aims of the study.
454
During the interview sessions it became clear that the analyst was not entirely comfortable with the first version of the BRD and he expressed that he did not feel it accurately represented the teams business process. This is supported by the fact that the EST generated from this BRD was incomplete. Conversely, the remainder of the team all agreed that the BRD represented the team’s business process at a policy level but were unable to explain why this was so or to be more explicit about how they knew this to be so. Figure 6 shows the (user) BRD used to model the request stage of the business process. This level of diagram was notated "level 0" by the analyst. The state transition is externally verifiable because the customer initiates the request (trigger) and receives the quote (message).
T1 Request
E1 List Requirements
S1 Requirement listed
E2 Assess Client Needs
M5 Disposal
S2 Solution prepared
M1 Quote
Figure 6: Request UBRD The second phase generated both a set of three BRDs and a corresponding set of seven PRDs (with corresponding ESTs), using the same notation. The analyst indicated that to show the complete model on a single diagram, while perhaps convenient, appeared to overwhelm the other members of the team. Using multiple diagrams is not an unusual result for a complex system. This phase validated one research hypothesis of the study, which was to explore whether the BRD notation would be suitable and/or expressive enough for rules that were not policy rules. Figure 7 shows part of the processing rules diagram that represents the furniture layout preparation or design stage of the business process. An idea of the complexity involved at the processing level can be gained by considering that the full design stage (which was one PRD out of seven) consists of seven states, seven events, seven conditions, six signals and two complex blobs. In this diagram, the state transition is from S21 (request prepared) to S17 (furniture identified), through event E10 (identify furnishings), initiated by trigger T5 (project request). The pre-state is externally verifiable, as the request is initiated by a customer but both the event and the post-state are internal (as are the messages), suggesting that in a PRD states may be either internal or external. This indicates that one of the basic assertions of the BRD model, that policy rules are represented by externally verifiable state to state transitions has a suitable analogue at the next level: processing rules are represented by internally (or possibly externally) verifiable state to state transitions.
455
It was particularly interesting that the analyst chose to use levelling in manner roughly analogous to levelling in data flow diagrams as a means of managing the level of detail required. It was also notable that the analyst appeared to shift from an object-oriented perspective in the first phase to a more function-oriented perspective in the second phase but was unaware of having done so. This may have been a natural progression for the analyst but a model which accounts for this change in structure is discussed in a later section. Stage 3: Creation/Validation of EST. In order to assist with the validation of business rules, the researcher suggested that the BRD model be modified to explicitly provide validation between the EST and the precursor BRD. To facilitate this, an extra column was added to the EST which indicated the business rule(s) represented by each of the events or state-to-state transitions (table rows). Interview feedback obtained from the analyst indicated that this was an extremely useful device in terms of validating that all of the business rules were represented in the table, verifying that the BRD captured all rules accurately and ensuring that surplus or spurious states or events were removed. Table 1 shows a portion of the EST from the study.
Complex
T5 Project request
C13 Require sketch?
S21 Request prepared
M9 U/stock request
C14 Require furnishings?
E10 Identify Furnishings
M8 Purchase request
M17 Used stock
S17 Furniture identified
Figure 7: Partial Design PRD Referring back to figure 7, the Design PRD, and to line 2 of Table 1, for event E10 (identify furnishings) to take place, conditions C13 (require sketch) and C14 (require furnishings) must be met. The state transition is from S21 (request prepared) to S17 (furniture identified), initiated by trigger T5 (project request). This “use case” relates to the business rules notated in the last column of table 1. If a row did not have at least one rule associated with it, then this indicated that the event or state transition was not explicitly related to the business rules generated by the team. Clearly, a transition without an accompanying business rule is either redundant (a phantom) or it indicates that a business rule is missing or incomplete. It is difficult at this stage of maturity of the BRD method to ascertain precisely when the EST is complete, although the graph theoretic approach of McCabe (1976), which can be applied to Business Rules Diagrams, does provide an upper bound on the
456
number of possible use cases. The analyst also found it useful to check that the complete EST contained all of the business rules generated, thus this simple device provided bi-directional validation of the logic embedded into the BRD/PRD. Stage 4: Software Requirements Specification. The analyst used a combination of FastAPT™ and ANSI/IEEE Std-830 to generate the requirements specification from the BRD. The EST, while not formally part of the input to this stage, acted to validate assertions about the BRD, prior to generating the SRS. A change made (for the purposes of this study) to the more common forms of requirements specifications was to ensure that each functional requirement was linked to the business rules. The result of this linkage was that each requirement represented an aggregate of several business rules and further, each requirement tended to be associated with one policy rule and many processing rules. An example of this is shown in table 2. Event
Trigger
E1
T1
E10
T2 T5
Message
M3 M8
Condition
Pre-State
C1, [C2]
S17 S18 S11 S21
[C3], C4, C7, C1, [C2] C14, C13
PostState S1 S1 S17
Business Rule(s) 3, 21, 41
3, 16, 17, 23, 41
Table 1: Partial Event Specification Table (note: negated conditions are enclosed in square brackets, thus [C1] means "not condition C1")
The policy rule in table 2 is externally verifiable as the customer initiates the transaction and receives confirmation (a quote) before the job proceeds. The states, in this case for a quote object, might be blank, filled and confirmed, while the event would be provide quote. Not all of the processing rules are externally verifiable e.g. a customer would not be aware that there is a catalogue of standard furniture. This indicates that processing states may be (at least partially) internal, which is a not unexpected result. The natural clumping of rules in table 2 suggests that it would be useful to aggregate together rules that are associated with one another in some way as this would not only assist in generating the SRS but would also provide support in managing the complexity associated with handling many rules, an idea that will be discussed further in the next section. Functional Requirement
To be able to record and select from standard lists of furniture items.
Policy Rule
Customer requirements are defined in consultation with the customer and any resulting quotation confirmed with the customer before proceeding with the order.
Process Rules
A catalogue of standard furniture is kept and updated. Customers may only select furniture from the standard range. A quotation form is sent to the customer.
Table 2: Linkage of Business Rules to Requirements To aid in the software selection process, the analyst matched potential software solutions (packages) to each functional requirement contained in the SRS, the expectation being that the package that scored best would be the one selected. This method might be appropriate if each of the competing
457
packages met each requirement to the same degree, an unlikely scenario given the product differentiation in the market. A more realistic strategy might be to conduct a comparative analysis of the features of each of the packages that match a minimum subset of the functional requirements.
ISSUES ARISING FROM THE STUDY During the course of the meetings it became clear that the team was confused, not by the explanation of the levels of rules, the notation or structure of the method, but by the decisions required to categorise some of the rules that were generated. For example, one rule was that the section charges a commission of 6% on each order that was processed. The team was unsure of the level or category that was most appropriate for this rule and had trouble deciding whether this was a policy, process or implementation rule. Clearly, that a commission is charged is a policy (provided that this is externally verifiable and causes a state change), the amount that is charged is a processing rule and the actual step-by-step process is an implementation rule. To address this issue, it was suggested that the rules should be sub-classed at the generation stage e.g. policy rule 1, that a commission is charged on jobs, might have an associated processing rule 1.1, that the commission is set at 6% etc. This was not done by the analyst but is an obvious first step in managing the complexity and sheer volume of rules that are generated in a real problem situation. The purpose of such partitioning would serve to align the thinking of participants into levels of abstraction consistent with policy, processing and implementation rules. The concept of levelling within the BRD method should also be explored further. The researcher did suggest that the event construct could be “exploded” to provide further (processing-level) detail but the analyst did not actually use a particular construct in the “levelling” performed. The idea of exploding events was based upon careful thought about the original semantics of the constructs of the BRD, particularly that actions occur in events via state transitions. This meant that states, signals and conditions would not be suitable constructs for levelling or explosion as no action occurred in these constructs while the Harel blob performed another quite distinct role, that of encapsulation. In other words, since the state construct is the anchor or baseline for constructing the diagram, it would be desirable, for the purpose of modelling process rules, to decompose events. In such a scenario, it is envisaged that signals and conditions would be able to be embedded appropriately but not decomposed. Both of these issues, that of separating the rules and levelling the diagram are instances of the general problem of abstraction. Within the context of abstraction we would suggest that a real-world system may have a very large (possibly infinite) set of elements, depending on the level of abstraction used to define the system but consider that there is a finite set of elements that capture the essence of the system for a given level of abstraction. These levels of abstraction correspond to policy, procedural and implementation rules within the BRD method or alternatively to business rule and processing rule diagrams respectively. A particularly interesting issue that arose during the study was that when the analyst changed the model from an object perspective to a more functionally-oriented one this resulted in a cleaner, more effective model of the business process. Recent work by Nguyen and Swatman (1999) provides a likely explanation for this effect. The Requirements Engineering literature (for example, Christel and Kang, 1992) indicates that the complexity of a given requirements model increases over time in some incremental fashion, approaching, but never quite reaching, the complexity of the real world. A recent study by Nguyen and Swatman (1999) proposes that complexity has two parts, essential complexity (which we wish to capture in order to have a representative model) and incidental complexity (which hinders the modelling activity and arises because of the poor fit of the model to reality). Figure 8 shows this model of complexity.
458
In figure 8, a requirements model is built and then as new facts become available the complexity of the model increases rapidly as the old assumptions upon which the model is built are at variance with new insights. At the "peak", the model is re-evaluated, stripped and reconstructed as a new model with reduced complexity. This cycle may repeat itself several times (as in figure 8) over the life of the requirements gathering process. This process appears not dissimilar to the paradigmatic view of scientific theory building developed by Kuhn (1970) which can be summarised as: pre-science normal science - crisis/revolution - new normal science - new crisis. The results of the action research study, where the analyst redeveloped the existing model when it did not accurately reflect reality, appear to fit the Nguyen and Swatman model of the evolution of the complexity of requirements models quite well. Complexity of Requirements Models
Time
Figure 8: An Alternative View of the Complexity of Requirements Models (Adapted from Nguyen and Swatman, 1999)
SUMMARY This work set out to achieve three aims: to use the BRD method in a more complex problem situation that had been done previously, to explore the business processes of a client, with the ultimate aim being to provide input into the software selection phase for a commercial “off the shelf” system, and to test whether the notation of the BRD was sufficiently expressive enough to be used at the processing rules level. In terms of other IS methodologies, the BRD method can be positioned between the (simpler) usecase approach of Jacobsen et al. (1992) and more complex object models. As policy-level business rules represent business concepts, users appear to be comfortable manipulating them using Business Rules Diagrams, although it must be said that a larger pool of cases must be developed and analysed before the results can be generalised. By using validation procedures not defined in the original BRD method of McDermid (1998), particularly extending the event table to provide links back to the business rules, the research study has assisted in testing the use of the BRD in solving a real-world problem, as part of a software selection process. This validation also assisted in associating the policy-level business rules with the functional requirements of the SRS. This study has explored some of the guiding heuristics of the BRD method (e.g. state-state transitions via events) and has posited new ones based on the experiences gained in the action research study. In particular, processing rules should be associated with their governing policy rules at rule generation time to avoid confusion, the notation of the BRD is sufficient to represent a processing-level diagram (PRD) and the event construct could be used as an anchor to link business rules diagrams with processing rules diagrams. While these results concerning abstraction and levelling are not unique, it is useful to have these issues validated as this will extend the BRD method and assist in making it a
459
useful tool for requirements engineering. The next step will be to explore, refine and test the taxonomy of business rule types. A further study, structured around these ideas, is underway and will provide further insights into the BRD method.
REFERENCES Appleton, D. (1988). ‘Second Generation Applications’. Database Programming and Design (Feb), pp48-54. Baskerville, R., and Wood-Harper, T. (1992). ‘A Critical Perspective on Action Research as a Method for Information Systems Research’ (Technical Report MCS-92-13). New York: State University of New York. Bunge, M. (1977). Treatise on Basic Philosophy. Vol. 3, Ontology I: The Furniture of the World. Vol. 3. Dordrecht, Holland: D. Reidel. Bunge, M. (1979). Treatise on Basic Philosophy. Vol. 4, Ontology II: A World of Systems. Vol. 4. Dordrecht, Holland: D. Reidel. Checkland, P. (1985). ‘From Optimising to Learning: A Development of Systems Thinking for the 1990s’. Journal of the Operational Research Society, 36(9), pp757-67. Christel, M. G. and Kang, K. C. (1992). ‘Issues in Requirements Elicitation’, Technical Report CMU/SEI-92-TR-012, Software Engineering Institute, Carnegie Mellon University. Harel, D. (1988). ‘On Visual Formalisms’. Communications of the ACM, 31(5), pp514-30. Jacobson, I., Christerson, M., Jonsson, P., and Övergaard. G. (1992). Object-Oriented Software Engineering. Reading, MA: Addison-Wesley. Johnson-Laird, P. N. (1983). Mental Models. Cambridge, Massachusetts: Harvard University Press. Jones, B. (1991). Letter to editor. Database Programming and Design, Nov. p9. Kuhn, T. S. (1970). The Structure of Scientific Revolutions. Chicago: University of Chicago Press. Loosley, C. (1992). ‘Separation and Integration in the Zachman Framework’. Data Base Newsletter, 20(1). McCabe, T. J. (1976). ‘A Complexity Measure’. IEEE Trans. on Software Engineering, 2(4), pp308-20. McDermid, D. C. (1998). ‘The Development of the Business Rules Diagram’, PhD thesis, Curtin University of Technology. Nguyen, L. and Swatman, P. (1999). ‘Essential and Incidental Complexity in Requirements Models’, Working Paper 1999/15, School of Management Information Systems, Deakin University. Ramaprasad, A., Hill, M. E., and Salach, D. A. (1993). ‘Mental models, cognitive dissonance and executive information systems’ effectiveness’. Journal of Information Systems, 3, pp239-253. Sandy, G. (1996). ‘The Nature and Structuring of Organisational Rules’. Proceedings of the 7th Australasian Conference on Information Systems, Hobart, Australia.
460
Sibelius, P. (1992). ‘On Formal Semantics of First-Order Theories’. pages 229-246 of: Oshuga, S., Kangassalo, H., Jaakola, H., Hori, K., and Yonezaki, N. (eds), Information Modelling and Knowledge Bases III: Foundations, Theory and Application. Amsterdam: IOS Press. Wand, Y., and Weber, R. (1989). ‘An Ontological Evaluation of Systems Analysis and Design Methods'. Pages 79-107 of: Falkenberg, E. D. and Lindgreen, P., (eds), Information Systems Concepts: An In-depth Analysis: North-Holland. Wand, Y., and Weber, R. (1993). ‘On the Ontological Expressiveness of Information Systems Analysis and Design Grammars’. Journal of Information Systems, 3, pp217-37. Wand, Y., and Weber, R. (1995). ‘On the deep structure of information systems.’ Information Systems Journal 5, pp203-223.
COPYRIGHT Michael N Johnstone and Donald C McDermid © 1999. The authors assign to ACIS and educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive license to ACIS to publish this document in full in the Conference Papers and Proceedings. These documents may be published on the World Wide Web, CD-ROM, in printed form, and on mirror sites on the World Wide Web. Any other usage is prohibited without the express permission of the authors.
461
