449Proc. 10th Australasian Conferenceon Information Systems, 1999

Extending and Validating the Business Rules Diagram Method

Michael N JohnstoneDonald C McDermid

School of Information SystemsCurtin University of Technology

Perth, Western Australiamnj@resources.curtin.edu.au

Abstract

This paper describes an action research study whose focus was assisting in the selection of acommercial "off the shelf" (COTS) software system. During the study the semantic gapbetween different representations of the problem domain was recognised as a potential issuewhich might affect the effectiveness of the process thus an intellectual framework based on aparticular set of ontological ideas was used to guide the study. Two notable issues that arosefrom the study were how to implement feedback mechanisms into the process and how tomanage the complexity of a real-world problem domain by using abstraction without losingimportant details.

Keywords

Information Requirements Determination; IS Research Issues; Action Research.

BUSINESS RULES IN REQUIREMENTS ENGINEERINGThere is a lack of consensus within the information systems community as to what actually constitutesa business rule (Loosley 1992). Appleton (1988, p49) describes a business rule as 'an explicitstatement which stipulates a condition that must exist in an information environment forinformation 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 goalsat 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 businessrule. It is important that the definition of a business rule stipulates something of the context andnature of a business rule as well as identifying its constructs. McDermid (1998, p20) defines abusiness rule as ‘…an explicit state change context in an organisation which describes thestates, conditions and signals associated with events that either change the state of a humanactivity system so that subsequently it will respond differently to external stimuli or reinforcethe constraints which govern a human activity system’, a definition we shall use from hereonwards.

THE BUSINESS RULES DIAGRAMSibelius (1992) considers that the problem of conceptual modelling is twofold in that an accurateway must be found to describe the observable features of an object and that a minimum set ofconcepts 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 processingcapabilities and thus use various knowledge structures such as frames, scripts cognitive maps and

450

schemata to represent abstractions of reality. Johnson-Laird (1983 p10) described such models asfollows: "human beings understand the world by constructing working models of it in theirminds. Since these models are incomplete, they are simpler than the entities that theyrepresent. 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 proceduresthat mimic their behavior.". This is a point well-made by Wand and Weber (1993) who considerthe mappings between the real world and the machine world (figure 1) to be approximations to thereal world.

Machine world

Script #n Program

Script #1 Requirements

documentReality • • • • • • •

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 constructsmake up a Business Rule Diagram (BRD). States reflect the status of an object of interest at anygiven time, for example a furniture item order might traverse the states confirmed, delivered andpaid. Events are actions carried out internally by the organisation. They are considered to beinstantaneous occurrences that reflect the organisation’s policy on what should happen in a particularcircumstance e.g. cancel order. One important role of the event is to avoid specifying processingdetail. Rather, such “processing” detail is best kept separate from “policy” rules as will be discussedlater. Conditions define the criteria by which objects of interest in the business move from one stateto the next as events take place. Sometimes, many conditions must met in order for an event to takeplace, thus increasing complexity. It is argued that modelling conditions without the context of statesand events (and vice versa) is far less powerful or useful. Lastly, signals either enter or leave thehuman activity system. Signals that enter the system typically initiate activity within the system andare called triggers. Triggers may be external such as a customer sending an order or internal such asone 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 endof a month. Those signals which leave the system serve to inform those outside the system boundaryabout what has occurred inside the system and are called messages. An important additionalconstruct is the Harel blob (Harel 1988), represented by a rounded rectangle, which acts as anencapsulator 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 figure3. Policy rules are the most general and are represented by externally verifiable state to statetransitions. An example of a policy rule is: "an order is generated only when a customer accepts aquote". Typically, the states here would be solution accepted and order prepared with theintervening 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 orderdetails (a message). Such a business rule tends to encompass several "partial" rules, which are not inthemselves completely externally verifiable but act to provide a business domain or context for thepolicy rule. Examples of such partial rules relating to the abovementioned policy rule include "a

451

request form shall contain a complete list of customer requirements", "only approved quotations areordered" and "a customer solution must be in the form of a written quotation".

PolicyRule

state event condition signal blob

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 beconsiderably more complex. Examples of processing rules include: "a sales tax exemption numberneeds to be quoted on every purchase order" and "a commission of 6% will apply to all jobs". Thelowest level, implementation rules, describe the system in detail and are beyond the scope of thisstudy. To date, studies have been carried out concerning policy rules (McDermid, 1988) but this isthe first study to examine the BRD method at a lower level, in this case, processing rules.

ImplementationRules

Rules/conditions which describe theimplementation of the informationsystem processes

ProcessingRules

PolicyRules

Rules/conditions which describe howprocesses are executed (e.g. formulae)

Rules/conditions that determinewhich processes are executed orthe way that objects (e.g.customers, orders) are treated

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).

452

THE ACTION RESEARCH STUDYThe BRD method is a new technique and as such is still emerging. This suggests that any researchinto the BRD should use a method that recognises the variability inherent in human interaction, fosterscollaboration between the researcher and participants and encourages a dynamic learningenvironment. 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 isa general problem with social science research rather than action research itself according toBaskerville and Wood-Harper (1992). The particular advantages of action research over otherresearch methods that made it suitable for this study were: involvement of the researcher in theproblem 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 rigourthe FMA research structure (figure 4), as proposed by Checkland (1985), was used to guide thestudy.

F

Intellectual Framework

Learning about F, M and Afrom the use of M

Methodology Mfor using F

Area of application

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) andWand and Weber (1993, 1995) which provided a basis for reasoning about real worldconstructs. The constructs in this case are the components of a Business Rule and the syntaxand semantics associated with the use of the Business Rules Diagram.

• Methodology (M) – The methodology chosen for using the framework of ideas is ActionResearch.

• Application (A) – The area of application is the Furnishings/Interior Design section of a largeUniversity.

The aim of the study was threefold: to use the BRD method in a more complex problem situation thathad been done previously; to explore the business processes of a client, with the ultimate aim beingto provide input into the software selection phase for a commercial “off the shelf” system, and; toexamine, in a research context, the effectiveness of the BRD notation for representing processingrules via a Processing Rules Diagram (PRD).

453

Intellectual Framework

Before discussing the details of the action research study a brief outline of the ontological modelwhich 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 aframework for the BRD as in Bunge's ontology systems are portrayed in terms of a tuple consistingof 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 asystem) 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 stablestates, events and a law. It is this representation which provides a basis for reasoning about theBRD. For example, the Wand and Weber (1993) model embodies the concept of state to statetransitions, 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, fora state to change, an event must take place. Clearly, such concepts map well into the Wand andWeber 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 inthe study were: a business analyst with 15 years experience in information systems development anda group of five users with experience varying from one to seven years in the area of Interior Designand furniture purchase, maintenance and disposal. The analyst was experienced in data modellingand structured design techniques, and was trained in the use of the BRD method by the researcherprior to the commencement of the study.

The Interiors group co-ordinates the purchase, disposal, recycling, maintenance and storage offurniture on both a project-oriented and an ad-hoc basis. The group has recognised that they haveno mechanism for tagging and tracking the location of furniture and that they maintain duplicaterecords of transactions for requests, orders and deliveries in unconnected spreadsheets. The groupwished to eliminate or reduce the duplication of data possibly by using a centralised workflowcapability which would allow customer requests to be tracked easily. The first step towards such asystem was for the group, with the analyst acting as facilitator, to model their existing businessprocess using the BRD method.

The study was staged to ensure that the participants did not suffer from “information overload” andthus 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.

454

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 considerablediscussion about the appropriate category (policy, processing or implementation) in which to placecertain rules. This was perhaps because of the widely differing roles that each team memberperformed in the work environment, as each would tend to have a different “world-view” of thecomplete business process. This was, however, a very fruitful unstructured “brainstorming” sessionthat assisted in reinforcing team ownership and control of the BRD process.

ProblemStatement(unstructured)

BusinessRules Business

RulesDiagram(BRD)

SoftwareRequirementsSpecification

(SRS)

EventSpecification

Table(EST)

UBRD/OLH

Use Cases

Check functionalrequirements against rules

Check rows intable againstrules

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 thephases. In the first phase, conducted over a period of seven weeks, the team created the BRD, thenthe researcher interviewed the entire team in a semi-structured interview situation. Following this, theanalyst created a second BRD, based on feedback received from the interviews and discussions withthe 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 beexpected from a motivated group who all have different roles within that business process. At theconclusion of this phase, the researcher conducted semi-structured interviews with each member ofthe team, including the analyst.

The interview questions were structured in such a way as to examine and draw out the participant’sperceptions and attitudes about each of the Framework of ideas, Methodology and Area ofapplication, recalling Checkland’s (1985) research structure, within the context of thehypotheses/aims of the study.

455

During the interview sessions it became clear that the analyst was not entirely comfortable with thefirst version of the BRD and he expressed that he did not feel it accurately represented the teamsbusiness process. This is supported by the fact that the EST generated from this BRD wasincomplete. Conversely, the remainder of the team all agreed that the BRD represented the team’sbusiness process at a policy level but were unable to explain why this was so or to be more explicitabout how they knew this to be so. Figure 6 shows the (user) BRD used to model the request stageof the business process. This level of diagram was notated "level 0" by the analyst. The statetransition is externally verifiable because the customer initiates the request (trigger) and receives thequote (message).

T1 Request

S1Requirement

listed

E2AssessClientNeeds

S2Solutionprepared

M1 QuoteM5 Disposal

E1List

Requirements

Figure 6: Request UBRD

The second phase generated both a set of three BRDs and a corresponding set of seven PRDs (withcorresponding ESTs), using the same notation. The analyst indicated that to show the completemodel on a single diagram, while perhaps convenient, appeared to overwhelm the other members ofthe team. Using multiple diagrams is not an unusual result for a complex system. This phasevalidated one research hypothesis of the study, which was to explore whether the BRD notationwould be suitable and/or expressive enough for rules that were not policy rules. Figure 7 shows partof the processing rules diagram that represents the furniture layout preparation or design stage of thebusiness process. An idea of the complexity involved at the processing level can be gained byconsidering 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 statetransition is from S21 (request prepared) to S17 (furniture identified), through event E10 (identifyfurnishings), initiated by trigger T5 (project request). The pre-state is externally verifiable, as therequest is initiated by a customer but both the event and the post-state are internal (as are themessages), suggesting that in a PRD states may be either internal or external. This indicates that oneof the basic assertions of the BRD model, that policy rules are represented by externally verifiablestate to state transitions has a suitable analogue at the next level: processing rules are represented byinternally (or possibly externally) verifiable state to state transitions.

456

It was particularly interesting that the analyst chose to use levelling in manner roughly analogous tolevelling in data flow diagrams as a means of managing the level of detail required. It was alsonotable that the analyst appeared to shift from an object-oriented perspective in the first phase to amore function-oriented perspective in the second phase but was unaware of having done so. Thismay have been a natural progression for the analyst but a model which accounts for this change instructure 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 modelbe modified to explicitly provide validation between the EST and the precursor BRD. To facilitatethis, an extra column was added to the EST which indicated the business rule(s) represented by eachof the events or state-to-state transitions (table rows). Interview feedback obtained from the analystindicated that this was an extremely useful device in terms of validating that all of the business ruleswere represented in the table, verifying that the BRD captured all rules accurately and ensuring thatsurplus or spurious states or events were removed. Table 1 shows a portion of the EST from thestudy.

C13Requiresketch?

T5 Projectrequest

S21Request

prepared

C14Require

furnishings?

M9 U/stockrequest

M8 Purchaserequest

M17 Usedstock

E10Identify

Furnishings

S17Furnitureidentified

Complex

Figure 7: Partial Design PRD

Referring back to figure 7, the Design PRD, and to line 2 of Table 1, for event E10 (identifyfurnishings) to take place, conditions C13 (require sketch) and C14 (require furnishings) must bemet. The state transition is from S21 (request prepared) to S17 (furniture identified), initiated bytrigger T5 (project request). This “use case” relates to the business rules notated in the last columnof table 1. If a row did not have at least one rule associated with it, then this indicated that the eventor state transition was not explicitly related to the business rules generated by the team. Clearly, atransition without an accompanying business rule is either redundant (a phantom) or it indicates that abusiness rule is missing or incomplete. It is difficult at this stage of maturity of the BRD method toascertain 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

457

number of possible use cases. The analyst also found it useful to check that the complete ESTcontained all of the business rules generated, thus this simple device provided bi-directional validationof 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 therequirements 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 thepurposes of this study) to the more common forms of requirements specifications was to ensure thateach functional requirement was linked to the business rules. The result of this linkage was that eachrequirement represented an aggregate of several business rules and further, each requirement tendedto be associated with one policy rule and many processing rules. An example of this is shown intable 2.

Event Trigger Message Condition Pre-State Post-State

BusinessRule(s)

E1 T1

T2 M3

C1, [C2]

[C3], C4, C7, C1, [C2]

S17S18S11

S1

S1

3, 21, 41

E10 T5 M8 C14, C13 S21 S17 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 receivesconfirmation (a quote) before the job proceeds. The states, in this case for a quote object, might beblank, filled and confirmed, while the event would be provide quote. Not all of the processingrules are externally verifiable e.g. a customer would not be aware that there is a catalogue ofstandard furniture. This indicates that processing states may be (at least partially) internal, which is anot unexpected result. The natural clumping of rules in table 2 suggests that it would be useful toaggregate together rules that are associated with one another in some way as this would not onlyassist in generating the SRS but would also provide support in managing the complexity associatedwith handling many rules, an idea that will be discussed further in the next section.

FunctionalRequirement

To be able to record and select from standard lists of furniture items.

Policy Rule Customer requirements are defined in consultation with the customer andany resulting quotation confirmed with the customer before proceedingwith 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 thatscored best would be the one selected. This method might be appropriate if each of the competing

458

packages met each requirement to the same degree, an unlikely scenario given the productdifferentiation in the market. A more realistic strategy might be to conduct a comparative analysis ofthe features of each of the packages that match a minimum subset of the functional requirements.

ISSUES ARISING FROM THE STUDYDuring the course of the meetings it became clear that the team was confused, not by the explanationof the levels of rules, the notation or structure of the method, but by the decisions required tocategorise some of the rules that were generated. For example, one rule was that the sectioncharges a commission of 6% on each order that was processed. The team was unsure of the level orcategory 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 thisis externally verifiable and causes a state change), the amount that is charged is a processing rule andthe actual step-by-step process is an implementation rule. To address this issue, it was suggestedthat the rules should be sub-classed at the generation stage e.g. policy rule 1, that a commission ischarged 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 sheervolume of rules that are generated in a real problem situation. The purpose of such partitioningwould 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 didsuggest that the event construct could be “exploded” to provide further (processing-level) detail butthe analyst did not actually use a particular construct in the “levelling” performed. The idea ofexploding events was based upon careful thought about the original semantics of the constructs of theBRD, particularly that actions occur in events via state transitions. This meant that states, signals andconditions would not be suitable constructs for levelling or explosion as no action occurred in theseconstructs while the Harel blob performed another quite distinct role, that of encapsulation. In otherwords, since the state construct is the anchor or baseline for constructing the diagram, it would bedesirable, for the purpose of modelling process rules, to decompose events. In such a scenario, it isenvisaged that signals and conditions would be able to be embedded appropriately but notdecomposed.

Both of these issues, that of separating the rules and levelling the diagram are instances of the generalproblem of abstraction. Within the context of abstraction we would suggest that a real-world systemmay have a very large (possibly infinite) set of elements, depending on the level of abstraction used todefine the system but consider that there is a finite set of elements that capture the essence of thesystem for a given level of abstraction. These levels of abstraction correspond to policy, proceduraland implementation rules within the BRD method or alternatively to business rule and processing rulediagrams respectively.

A particularly interesting issue that arose during the study was that when the analyst changed themodel from an object perspective to a more functionally-oriented one this resulted in a cleaner, moreeffective model of the business process. Recent work by Nguyen and Swatman (1999) provides alikely explanation for this effect. The Requirements Engineering literature (for example, Christel andKang, 1992) indicates that the complexity of a given requirements model increases over time in someincremental 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, essentialcomplexity (which we wish to capture in order to have a representative model) and incidentalcomplexity (which hinders the modelling activity and arises because of the poor fit of the model toreality). Figure 8 shows this model of complexity.

459

In figure 8, a requirements model is built and then as new facts become available the complexity ofthe model increases rapidly as the old assumptions upon which the model is built are at variance withnew insights. At the "peak", the model is re-evaluated, stripped and reconstructed as a new modelwith reduced complexity. This cycle may repeat itself several times (as in figure 8) over the life of therequirements gathering process. This process appears not dissimilar to the paradigmatic view ofscientific 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 actionresearch study, where the analyst redeveloped the existing model when it did not accurately reflectreality, appear to fit the Nguyen and Swatman model of the evolution of the complexity ofrequirements models quite well.

Time

Complexity ofRequirementsModels

Figure 8: An Alternative View of the Complexity of Requirements Models

(Adapted from Nguyen and Swatman, 1999)

SUMMARYThis work set out to achieve three aims: to use the BRD method in a more complex problemsituation that had been done previously, to explore the business processes of a client, with theultimate 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 atthe processing rules level.

In terms of other IS methodologies, the BRD method can be positioned between the (simpler) use-case approach of Jacobsen et al. (1992) and more complex object models. As policy-levelbusiness rules represent business concepts, users appear to be comfortable manipulating them usingBusiness Rules Diagrams, although it must be said that a larger pool of cases must be developed andanalysed 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 studyhas assisted in testing the use of the BRD in solving a real-world problem, as part of a softwareselection process. This validation also assisted in associating the policy-level business rules with thefunctional requirements of the SRS.

This study has explored some of the guiding heuristics of the BRD method (e.g. state-state transitionsvia 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 generationtime 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 withprocessing rules diagrams. While these results concerning abstraction and levelling are not unique, itis useful to have these issues validated as this will extend the BRD method and assist in making it a

460

useful tool for requirements engineering. The next step will be to explore, refine and test thetaxonomy of business rule types. A further study, structured around these ideas, is underway andwill provide further insights into the BRD method.

REFERENCESAppleton, 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 aMethod for Information Systems Research’ (Technical Report MCS-92-13). New York: StateUniversity of New York.

Bunge, M. (1977). Treatise on Basic Philosophy. Vol. 3, Ontology I: The Furniture of theWorld. 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 the1990s’. Journal of the Operational Research Society, 36(9), pp757-67.

Christel, M. G. and Kang, K. C. (1992). ‘Issues in Requirements Elicitation’, Technical ReportCMU/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 SoftwareEngineering. Reading, MA: Addison-Wesley.

Johnson-Laird, P. N. (1983). Mental Models. Cambridge, Massachusetts: Harvard UniversityPress.

Jones, B. (1991). Letter to editor. Database Programming and Design, Nov. p9.

Kuhn, T. S. (1970). The Structure of Scientific Revolutions. Chicago: University of ChicagoPress.

Loosley, C. (1992). ‘Separation and Integration in the Zachman Framework’. Data BaseNewsletter, 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, CurtinUniversity of Technology.

Nguyen, L. and Swatman, P. (1999). ‘Essential and Incidental Complexity in RequirementsModels’, Working Paper 1999/15, School of Management Information Systems, DeakinUniversity.

Ramaprasad, A., Hill, M. E., and Salach, D. A. (1993). ‘Mental models, cognitive dissonance andexecutive information systems’ effectiveness’. Journal of Information Systems, 3, pp239-253.

Sandy, G. (1996). ‘The Nature and Structuring of Organisational Rules’. Proceedings of the 7thAustralasian Conference on Information Systems, Hobart, Australia.

461

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 andKnowledge Bases III: Foundations, Theory and Application. Amsterdam: IOS Press.

Wand, Y., and Weber, R. (1989). ‘An Ontological Evaluation of Systems Analysis and DesignMethods'. Pages 79-107 of: Falkenberg, E. D. and Lindgreen, P., (eds), Information SystemsConcepts: An In-depth Analysis: North-Holland.

Wand, Y., and Weber, R. (1993). ‘On the Ontological Expressiveness of Information SystemsAnalysis and Design Grammars’. Journal of Information Systems, 3, pp217-37.

Wand, Y., and Weber, R. (1995). ‘On the deep structure of information systems.’ InformationSystems Journal 5, pp203-223.

COPYRIGHTMichael N Johnstone and Donald C McDermid © 1999. The authors assign to ACIS andeducational and non-profit institutions a non-exclusive licence to use this document for personal useand in courses of instruction provided that the article is used in full and this copyright statement isreproduced. The authors also grant a non-exclusive license to ACIS to publish this document in fullin the Conference Papers and Proceedings. These documents may be published on the World WideWeb, CD-ROM, in printed form, and on mirror sites on the World Wide Web. Any other usage isprohibited without the express permission of the authors.