citrus bulletin of information technology research
a citrus project - www.citrus.ac.nz
National Advisory Committee on Computing Qualifications


this issue  home  back issues  about BITR 

Specifying Business Rules: A Fact-Based Approach
Bulletin of Information Technology Research. Vol 1, Issue 1 (June 2003). ISSN 1176-3108.

Adrian Hargreaves
Department of Information Systems
Massey University
Wellington
A.J.Hargreaves@massey.ac.nz

Abstract

Numerous industry surveys have suggested that most IT projects still end in failure. Incomplete, ambiguous and inaccurate specifications are cited as a major causal factor. Traditional techniques for specifying requirements most often lack the expressiveness with which to model subtle but common features within organisations. As a consequence, many of the business rules that determines the structure and behaviour of organisations are simply not captured until the latter stages of the development lifecycle.

Business rules originate as policies that are adopted by organisations to achieve their higher-level goals. The Business Rules Group (BRG) has defined a conceptual model for these rules. The concepts and definitions within their report can guide analysts to seek appropriate information from domain experts. Most techniques that are currently employed for representing requirements, however, incorporate implementation details unfamiliar to these people. Unless domain experts can actively challenge the analyst's understanding of these rules, how can they be certain they are defining the required system?

The aim of this review, therefore, is to examine the evolution of the techniques employed by analysts for defining requirements. It investigates their ability to capture these details, the limitations they have overcome and their capacity for communication with the end-user community. The review highlights the fact that although many important advances have been made over the last 30 years, the techniques commonly used by analysts are still beset by significant problems.

Fact-based techniques are investigated as an alternative approach, and it is suggested that they could provide a mechanism for improving the quality of requirements. The ORM and KISS conceptual modelling approaches are presented. Their ability to capture and represent requirements rigorously, but still in a form comprehensible to business people, is analysed.

Finally, this review proposes that either of these alternative approaches could be synthesised with the concepts and definitions within the BRG report. This would provide a single conceptual framework meaningful to both business people and analysts. Integrating the expressive simplicity of these conceptual modelling techniques within the business rules framework may help to fill a significant requirements gap.

Introduction

Although computer systems have been developed for business and government organisations for more than 40 years, recent industry surveys (The Standish Group, 1995; OASIG, 1996; Whittaker, 1999; National Audit Office, 2001; Conference Board Survey, 2001) have all indicated that most I.T. projects still end in failure. Many of these surveys and the findings of other authors (Glass, 1997; Leffingwell, 1997) have concluded that inadequately specified requirements are one the primary causes of I.T. failures.

Perhaps these findings are not so surprising since many contemporary data modelling techniques simply cannot represent many important system requirements. In particular, the constraints that apply to data structures cannot be easily represented, if at all, in most data modelling techniques (ter hofstede, Proper, & van der Weide, 1994). Consequently, these requirements are often not discovered until the latter stages of the development lifecycle, possibly causing serious scheduling and budgetary problems for projects.

Not being able to represent the dynamic constraints that apply to static structural requirements could have other disadvantages. Capturing the business rules that define the structure and constrains the behaviour of business organisations has been presented by some as a new paradigm for systems development. Indeed, Date (2000, p.3) states, "business rules can be seen in some respects as the next (and giant) evolutionary step in implementing that [original relational] vision."

The Business Rules Group (formerly known as GUIDE) has defined a conceptual model for these rules. The concepts and definitions within this report can guide analysts to seek appropriate information from domain experts by knowing "what is, and is not, a business rule" (GUIDE, 1995, p.1). Business rules originate as the policies adopted by organisations in response to constraints that act upon them (GUIDE, 1995). As such, business people represent domain experts and so it is from these people that analysts must elicit the organisation's business rules. Since these rules can only be validated when business people can challenge the analyst's understanding of them, it suggests that they must be expressed in a form that facilitates such dialogue.

Conceptual modelling approaches such as ORM and KISS, exploit the expressiveness of natural language within the formality of an underlying mathematical framework. Both of these modelling techniques rely heavily on natural language analysis. This allows the application model to be defined at the conceptual level where the analyst and domain expert can communicate more effectively (Halpin, 2002). Their ability to verbalise elementary facts that describe an organisation, suggests business rules could be expressed within these models. This would allow domain experts to become actively involved in their validation. By integrating conceptual modelling techniques within the business rules model, analysts may have a mechanism for capturing requirements more completely and accurately. That ability could help to fill a requirements gap and thus reduce the risk of project failure.

Requirements Engineering (RE) Problems

The problems associated with RE have been well documented for many years. Researchers have noted (Bell & Thayer T.A., 1976; Meyer, 1985) incomplete, ambiguous and inconsistent requirements are commonplace in industry and recognised the significance of these inadequacies on software quality. More recently, various studies (The Standish Group, 1995; OASIG, 1996; National Audit Office, 2001; Conference Board Survey, 2001) have confirmed these findings and the magnitude of the problems caused by poorly defined requirements. The Standish Group (1995) discovered that less than 20% of the 8000 American IT projects they surveyed, delivered a system that was complete, on budget and within schedule. One third of I.T. projects they surveyed were never completed. The remaining projects were only partially completed and often well over schedule and budget. Managers attributed the cause of over 40% of project failures to problems relating to the gathering, specifying and validating of requirements. These findings suggest that improving the quality of requirements can significantly reduce the risk of project failure.

RE is a complex task requiring the analyst to bridge the gap between two specialist perspectives on a system (Ryan, 1993). The domain expert views the system at a high conceptual level and it is a business-orientated perspective. The analyst must transform this view into a complete and precise specification that is necessarily computer-system orientated (Pohl, 1993). Each of these perspectives is associated with concepts and a language used to express them. This presents a significant problem since in order to agree on what the required system should do, domain experts and analysts need to effectively communicate (Pohl, 1993). Unless the domain expert can challenge the analyst's understanding of a system, one would expect such an agreement to be difficult to attain.

Approaches to Requirements Engineering

Modelling of the existing system seems to be a key task of RE regardless of which particular methodology is adopted. Models form the basis of communication about a system and its refinement to meet the needs it has to fulfil. This suggests that the information contained in these models needs to accessible to domain experts so that a common understanding of the system can be shared and requirements agreed.

Pohl (1993. p.2) identifies two types of problems facing RE; "the original RE problems and the problems associated with approaches that attempt to resolve the original problems". In the next section, modelling techniques that have been used in RE are discussed. The focus of this discussion will be to examine what aspects they attempt to model and how they overcome the limitations of their predecessors.

Structured Approaches

One of the most popular and certainly one of the earliest techniques employed in RE are entity-relationships (ER) diagrams. This semi-formal technique attempts to model the data requirements of the system (Chen, 1976) and is often used in conjunction with structured analysis for defining processing requirements (DeMarco, 1978) and state transition diagrams for modelling user interaction (Wasserman, 1979).

Although simple to use, each of these techniques only model a single aspect of the system and lack the expressiveness of other techniques that followed. ER diagrams in particular have a limited capacity to model the constraints on data. For example, exclusion, equality and subset constraints are typically weakly supported (Halpin, 2002), as indeed are many of the rules that apply to data structures (ter Hofstede, Proper, & van der Weide, 1994). ER diagrams include thinly disguised implementation concepts such as tables (entities) and foreign keys rather than concepts more familiar to and thus more verifiable by, domain experts. Lacking a linguistic foundation compounds this problem since concepts cannot be easily verbalised to domain experts.

Requirements Modelling Languages

The limitations of ER diagrams to represent real-world concepts as appropriate data structures, lead some researchers to investigate alternative modelling approaches. Classification, generalisation and aggregation are concepts usually associated with object-orientation, but these techniques were first introduced in RML (Greenspan, Mylopoulos, & Borgida, 1982). This requirements modelling language was also one of the first to include formal semantics allowing requirements to be expressed more precisely than is possible using semi-formal techniques.

Agent-Based Reasoning

The techniques described above focus on modelling the static, structural qualities of systems. The representation of more dynamic aspects of the system such as behaviour and the constraints determining that behaviour were developed through agent-based reasoning (Feather, 1987). Agents are assigned responsibilities for achieving goals and constraints that limit their behaviour. Interactions between agents take place via interfaces and the formal foundations of the technique allow reasoning about agent behaviour and responsibility. This formality is achieved using a requirements specification language known as ALBERT in which requirements are expressed in terms of formal statements in temporal first order formulas (Yu, Du Bois, Dubois, & Mylopoulos, 1995). The capture of dynamic system qualities allows a more complete picture of domain knowledge to be represented, but its explicit formal framework could cause problems if business people are expected to validate the resulting models.

Goal-Based Reasoning

Systems development is more than just automating the current system. Re-engineering of existing practices may also be necessary if they are not sufficient to achieve business goals. The concept of requirements completeness was first incorporated into models through the explicit representation of goals (Yue, 1987). Goal-based reasoning allows analysts to exam the mechanisms in place for achieving business objectives. More formal approaches have been suggested (Manna & Pnueli, 1992) based on temporal logic that enable the completeness and correctness of requirements in attaining goals to be proved mathematically.

Scenario-Based Approaches

Even domain experts can have difficulty in identifying organisational goals and may require help to develop a deeper understanding of the system before these details can be documented. Scenario-based elicitation can be useful in these circumstances or when more traditional modelling techniques have failed (Weidenhaupt, Pohl, Jarke, & Haumer, 1998). A scenario is defined as "a description denoting similar parts of possible behaviours limited to a subset of purposeful state components, actions and communications taking place among two or several agents" ( Plihon, Ralyté, Benjamen, Maiden, Sutcliffe, Dubois et al., 1998, p.13). The analyst elicits these details as they walk through a particular process with the end user to understand its operations, agents and the event that triggers the process. Scenarios can be expressed formally using grammar-based modelling languages (Glinz, 1995). Semi-formal (Potts C., Takahashi, & Antòn, 1994) and informal approaches (Rolland & Ben Achour, 1998) can also be used based on structured and natural language notations, respectively.

Object-Orientated (OO) Approach

OO analysis combines a number of semi-formal techniques for capturing data (Class diagram, Object diagram) behaviour (Statechart diagram, Activity diagram) and interaction properties (Sequence and Collaboration diagram), which are now tending towards a standard set of notations (Rumbaugh, Jacobson, & Booch, 1999). The wide variety of techniques OO incorporates, allows it to be used from the modelling of requirements through to design activities. Improvements in the data structuring constructs available within Class diagrams over earlier data modelling techniques, allow more details to be represented including the constraints on data. However, these rules must be added as textual annotations to the model rather than symbolising these details graphically.

Since these techniques represent an abstraction of OO programming concepts (Mylopoulos, Chung, & Yu, 1999), implementation details are often present within models. This suggests that such models can be difficult for domain experts to conceptualise because the mechanisms and concepts underpinning the technique are unfamiliar to them (Halpin & Bloesch, 1999).

Finally, unlike several of the other approaches discussed above, OO focuses on addressing What type questions and ignores important Why type concerns associated with the early stages of R.E. (Mumford, 1981).

Conclusions Regarding RE Approaches

A number of conclusions can be drawn from the examination above. There has been a trend towards more expressive modelling techniques that can represent subtle data structuring features such as sub-typing and generalisation. Other, more dynamic facets of the system such as behaviour and constraints can now be modelled in addition to simply static, structural details. However, where such details are considered, they tend to be expressed formally within a requirements language based on first order logic, such as ALBERT. While this adds rigour and precision, requirements expressed in this form could be difficult to articulate and validate with domain experts.

There has also been increasing recognition of the importance of domain knowledge such as organisational goals and the mechanisms used to achieve them. Approaches have been developed to elicit that knowledge more effectively using scenarios and other informal techniques like natural language. However, it is equally recognised that formality is required in order to produce a complete, precise and unambiguous specification.

Requirements are represented in varying degrees of formality, depending on the approach adopted. The next section briefly identifies these and the raises the problem of how requirements are to be accurately translated between each of these representations.

The Representation and Translation of Requirements

According to Pohl (1993, p.4) the aim of R.E. "is to transform an operational need into a complete system specification through an iterative process of definition and validation." The representation of requirements should reflect this transformation in a process that begins informally and ends as a formal specification (Pohl, 1993).

Informal specifications tend to involve natural language or simple graphics, such as rich pictures (Checkland, 1981), which are user-orientated and expressive, but often contradictory and imprecise. Despite their imprecision, informal techniques can provide a mechanism for exploring system properties that need be understood first before they can be represented more formally.

Semi-formal techniques include Structured Systems Analysis and OO. They are popular techniques and provide useful graphical representations of system requirements. Since they possess a mathematical foundation, requirements expressed semi-formally are more precise and less prone to ambiguity than requirements expressed informally. Despite this, requirements expressed using semi-formal approaches cannot be proved correct to the same degree as more formal approaches.

Formal specification languages e.g. Z (Potter, Sinclair, & Till, 1996) and VDM (Jones, 1990) and knowledge representation languages e.g. RML (Greenspan, Mylopoulos, & Borgida, 1986) provide a much more rigorous and precise mechanism for representing requirements but are more difficult to use than less formal approaches. The mathematical framework, based on first order logic that underpins formal languages does, however, allow deductive reasoning on requirements to prove their validity and completeness (Manna & Pnueli, 1992).

Unfortunately, there is little in literature that actually describes how analysts should translate requirements between these levels of formality. As Pohl, K. concedes that, although the knowledge expressed in different representation formats should be integrated to achieve consistency, "The relationship between formal and informal is much less understood" (1993, p. 10). Even techniques within the same methodology do not have a defined mechanism that facilitates the translation process. For example, how does the analyst transform a series of Use Cases into a Class Diagram? Certainly, no automated tool support is currently available to achieve this task.

Requirements specified using formal languages often have no informal precursor. However, since formal specifications simply prove that the program produced from such a specification will work correctly, this approach cannot guarantee that the program specified is in fact the required program (Le Charlier & Flener, 1998). Further, since the fundamental purpose of a specification is to transmit information, the specification "must be comprehensible in itself and therefore must be written in the only language adapted to this purpose: natural language." (Le Charlier& Flener, 1998, p. 281). But how can requirements specified in natural language be translated into more formal descriptions of what the system will do?

The next section of this review examines two similar but distinct approaches to RE that support this transition from natural language to a formal representation of requirements. In addition, their method of exploiting natural language demonstrates that requirements expressed in this form are not necessarily informal.

Conceptual Approaches to RE using Natural Language

Natural language (NL) is a valuable tool for communicating with domain experts (Nijssen & Halpin, 1989; Hoppenbrouwers, Hoppenbrouwers, & Vos, 1996; Mazza, Fairclough, & Melton, 1994). However, NL is currently not widely used in industry for two major reasons. Firstly, NL does not lend itself for the expression of implementation concepts such as data retrieval and storage (Kristen, 1994). Secondly, NL possesses an inherent tendency towards informality and imprecision (Gamut, 1991). Despite these apparent shortcomings, a number of NL approaches to RE have been developed as a mechanism for defining a conceptual model of a system. Two NL approaches are discussed and how they attempt overcome the two problems highlighted above are explained.

The KISS Approach

The KISS approach begins with the collection of textual descriptions of the organisation domain. Grammatical analysis is then performed upon these with a view of extracting specifications that will be used in lower level modelling (Kristen, 1994). Throughout this process, NL is extensively employed as the means of communication with domain experts.

Originally, experienced analysts performed grammatical analysis manually. However, since heuristics were the only guide for analysts conducting this analysis, differences in approaches were bound to occur (Hoppenbrouwers, van der Vos, & Hoppenbrouwers, 1997). This reflects the problem of translation between informal and formal specifications previously identified. In addition, the textual descriptions elicited from domain experts often-contained details that were not pertinent in the context of conceptual modelling or were semantically inaccurate. These problems highlight the misconceptions and omissions concerning domain knowledge that even domain experts possess (Hoppenbrouwers et al., 1997).

These problems have been alleviated to some extent by the introduction of CASE tool support in the form of the Grammarlizer (Grammatical Analyser) (Hoppenbrouwers, van den Heuvel, Hoppenbrouwers, Weigand, & de Troyer, 1997). This tool supports semantic tagging; a process that facilitates the partial interpretation of text from which a set of elementary sentences are generated. From these elementary sentences, the CASE tool constructs 'KISS-structured sentences' that only contain information relevant for the generation of KISS conceptual models. The analyst must still examine each KISS sentence to determine its relevance within a conceptual model of the domain, but once performed, the CASE tool will create a Subject Communication (SC) and Object Interaction (OI) Model.

The SC model focuses on subjects, human or machine, that exchange messages providing a useful mechanism for depicting data flow. A typical SC model sentence would be 'The bank forwards a statement to the customer.' The details captured in SC models are dynamic in nature and therefore need to change as the business evolves.

The OI model defines the action types that can be applied to a particular object type and the synchronisation of those actions. A typical OI sentence would be, 'The reservation of a seat from a booking agency.' In this example, the action 'to reserve' is applied to both the seat and the booking agency concurrently. OI models capture more static components of the domain and tend to remain stable even after significant changes in the organisation.

An important component of the Grammarlizer architecture is the lexicon that allows both lexical and semantic knowledge to be captured and used for paraphrasing in NL. Currently, the Grammarlizer uses WordNet; a generic lexicon developed by Princeton University (Fellbaum, 1998), as a repository of all domain terminology and related linguistic elements. The lexicon contains the concepts and their relationship to other concepts in the domain and is therefore much more than a simple thesaurus or list of terms. Using NL paraphrasing as a validation technique, which exploits the domain knowledge captured within the lexicon, assists analysts to overcome two conflicting concerns; developing a formal model of requirements and communicating these requirements in the language of the domain expert (Dalianis, 1995).

The ORM Approach

Object Role Modelling (ORM) is a well-established approach for conceptual modelling and is associated with a methodology known as Natural language Information Analysis Methodology (NIAM), (Nijssen & Halpin, 1989) and Formal Object Role Modelling Language FORML (Halpin & Orlowska, 1992). A central concept within ORM is the idea of objects (entities or values) playing roles (parts in relationships). Unlike ER and OO modelling, ORM makes no initial use of the attribute construct and this approach tends make conceptual models more stable (Halpin, 1996). Instead, what would have been represented as attributes in other modelling approaches, are expressed as relationship types in ORM. As new facts are discovered, these details are simply added to the model as an additional role that is played by that object. Using an ER modelling approach, new discoveries concerning the application domain can mean that, concepts originally represented as attributes, need to be re-modelled as entity types (Halpin, 1996).

The application domain is modelled at a high conceptual level using terms familiar to domain experts in the form of elementary facts, constraints and derivation rules. Implementation issues, both logical and physical are ignored, allowing analysts to focus on the problem domain and to communicate effectively with domain experts.

Elementary sentences are constructed from discussions with domain experts that describe the roles played by objects e.g. 'Customer confirms Order'. In this example, there are two objects; 'Customer' and 'Order' that are associated via the role 'confirms'.

Natural language, in the form of elementary sentences, is often too ambiguous for further manipulation and therefore needs to be transformed into a notation with a formal mathematical framework. FORML (Formal Object Role Modelling Language) (Halpin, 2001) is the mechanism used to express elementary sentences formally in a process called verbalisation. Despite the mathematical foundations of this language, sentences constructed within this framework are still recognisable to domain experts. Using the above example, the equivalent FORML statement would be; 'Customer with CustNr 123 confirms Order with OrderNr 456.' The only significant difference between these two forms in this example is the use of a reference scheme for each object. The reference scheme gives a value that represents a unique instance of an object and provides a useful mechanism for validation against an actual population of such objects.

In the above example, the elementary fact is binary. However, ORM will support the expression of any type of arity. This allows facts to be expressed in more naturally, e.g. 'Customer with CustNr 789 at Time '9am' rents a Car with RegNr 'AB1234', represents a ternary fact type since it involves 3 objects.

Although a conceptual data model of the domain can be represented entirely within FORML statements, the ORM approach includes a step that allows analysts to symbolise elementary facts graphically. This is a useful mechanism since diagrammatical representation has the advantage of conveying domain knowledge much more succinctly than simple verbalisation. This conciseness is bought at the expense of clarity, however. A graphical ORM representation would probably not be the appropriate tool with which to conduct validation by domain experts. In fact, as the number of requirements increases, the clarity of these graphical models diminishes rapidly (Feldman & Miller, 1986). This problem is known as the Database Comprehension Problem (Carlson, Ji, & Arora, 1990) and affects all 'flat' data models in which objects are viewed at a single level of abstraction (Campbell & Halpin, 1994). Since ORM explicitly represents concepts that would be modelled as attributes in an ER diagram, however, this Database Comprehension problem affects ORM more than most other graphical modelling techniques. To reduce complexity, it has been suggested that ORM models should be constructed using a number of levels of abstraction (Campbell, Halpin, & Proper, 1996). At the highest level of abstraction, a model would contain only the most important application details. These details are then successively decomposed into lower level diagrams in much the same way as data flow diagrams are levelled when using a structured approach.

ORM allows analysts to capture many more constraints, enforcing data integrity, than is possible is most other modelling approaches (Halpin, 2002). This ability allows analysts to explicitly represent these details at a conceptual level, not only facilitating validation by domain experts, but also allowing automatic code generation of these rules. Uniqueness and role constraints have a parallel in all other data modelling approaches, but ORM allows many others to be expressed, such as:

  • Subset - where the population of one role is a subset of another
  • Equality - equivalent to a subset constraint, but in both directions
  • Exclusion - where the populations of two roles are mutually exclusive
  • Ring - applied to roles played by the same object i.e. recursive relationships. Includes asymmetric, intransitivity and acyclicity
  • Subtype - ORM also supports multiple inheritance

These constraints are added to the model as graphical annotations to structural details previously captured. As such, ORM appears to support the expression of many of the constraints that affect the behaviour of organisations. Details that are typically weakly supported, if at all, by many other modelling techniques (Halpin, 2002).

Details captured within ORM are mapped into table structures by using an algorithm incorporated into Visio Modeller, ORM's automated tool support. The algorithm transforms the conceptual model into Optimal Normal Form, which is equivalent to fifth normal form (Halpin, 2001). After mapping, the database can be generated into a number of target database formats including Oracle, Ingress and Access. Data integrity details, as specified by the constraints annotating the conceptual model, are also implemented in the target database. However, the degree to which these details appear as features within the target database are dictated by the limitations associated with the DBMS employed.

Conclusions Regarding Natural Language Approaches

Both KISS and ORM rely heavily on natural language paraphrasing techniques to communicate domain knowledge to domain experts. This is a useful approach in that knowledge is expressed in terms more familiar to those experts. The analyst's perceptions can then be actively challenged and thus validated by these people. Each approach resolves one of the major difficulties usually associated with the use of natural language: the inherent tendency towards informality and imprecision (Gamut, 1991). In both cases, this is achieved by adopting a restrictive grammar whose syntax and structure have a formal mathematical foundation. The KISS approach differs however, in the use of an automated tool (the Grammarlizer) that attempts to partially interpret textual information and transform these informal descriptions into formal expressions. By contrast, the ORM approach allows analysts to create graphical models, provide sample populations and facts, or to enter FORML statements directly into Visio Modeller. In this sense, precision and formality is achieved immediately, although still in a form comprehensible to domain experts, rather than being preceded by a phase where requirements are expressed informally.

The second problem associated with the use of natural language concerns its weakness for expressing implementation concepts (Kristen, 1994). In both the ORM and KISS approach, the domain is modelled at a high conceptual level in a fact-finding process. Implementation concepts, both logical and physical are simply not present within the models associated with each approach. However, Visio Modeller is still capable of generating databases from ORM models. Implementation issues are addressed internally, out of sight of even the analyst, by using algorithms to normalise ORM models and to implement them as relational tables and constraints (where supported by the target DBMS). The KISS approach lacks the tool support to deal with these implementation issues and is primarily a technique for representing domain knowledge within a series of conceptual models.

Of the two approaches, only KISS attempts to capture semantic and linguistic knowledge using WordNet. WordNet can provide a mechanism that allows analysts to seek agreement amongst domain experts as to the particular meaning of domain specific terminology. Since these terms appear as the names of objects or roles within ORM models, it seems reasonable that capturing their meaning, as in the KISS approach, would add to completeness and consistency of these models (Hoppenbrouwers et al., 1997).

Neither approach addresses why type concerns by explicitly relating requirements to higher-level organisational goals. Both techniques could benefit by adopting mechanisms that address this issue, thereby improving the completeness of requirements they capture. Using goal and scenario-based approaches to augment these techniques could provide such a mechanism.

Modelling Business Rules

Conceptual modelling techniques such as ORM and KISS distinguish themselves from many other modelling approaches in the degree of separation from technological aspects in which the application domain is described. Most other popular techniques, such ER and OO modelling define requirements that incorporate implementation concepts (Mylopoulos, Chung, & Nixon, 1992) not familiar to domain experts. By modelling the domain at a high conceptual level and using natural language to describe that domain, both KISS and ORM approaches allows people within these organisations to comprehend and challenge the analyst's understanding.

The business rules approach for defining organisations and their behaviour is possibly complementary to these conceptual modelling techniques. This approach describes the organisation in terms of 'the rules that define the structure and control the operation of an enterprise' (GUIDE, 1995, p.1). Since many of these business rules originate as policies implemented by organisations to achieve higher-level goals, the approach views the organisation from a similar conceptual perspective, independent of any technological considerations.

A project initiated by the Business Rules Group (formerly known as GUIDE), consisting of E.F. Codd, Charles Bachman and John Zachman amongst others, had as its major objective the goal of "formalising an approach for identifying and articulating business rules", (GUIDE, 1995, p.1). They see these rules falling into one of four major categories; definitions of business terms, facts relating terms to one another (which they call structural assertions), constraints that limit the behaviour of organisations (referred to as action assertions) and derivations (calculations). As such, the business rules approach does not present any new concepts unfamiliar to system developers. However, by defining the organisation and its behaviour as a collection of atomic business rules, the approach provides a framework for describing the organisation that is meaningful to both analysts and domain experts.

The group achieved two main goals: to define and describe business rules and their related concepts and to define a conceptual model of business rules (see Appendix One). Within this framework it is now possible to 'express what is, and is not, a business rule' (GUIDE, 1995, p.1) guiding analysts to seek appropriate and complete information from domain experts.

Business rules themselves are declarative in nature, rather than procedural. They define states that are required or prohibited, which maybe conditional, rather than the steps taken to move from one state to another. As such, other, process-orientated techniques, are required to the define sequence in which they are executed.

The group argue that many techniques are available for representing the rules that define the structure of organisations (structural assertions), for example ER and OO approaches, but very few are able to describe how the behaviour of organisations are constrained (action assertions) (GUIDE, 1995). This argument is reflected in this review with only a few notable exceptions such as ORM, KISS and to a limited extent, UML. Consequently, action assertions are often neglected, but important requirements. These details may not be discovered until an attempt is made to implement these requirements as program code (GUIDE, 1995).

Recent industry surveys, such as that conducted by the Standish Group (1995), have identified inadequately specified requirements as the cause of 40% of all I.T. project failures. These surveys do not explicitly identify constraints as the source of these missing requirements. However, if analysts do not possess the tools to formally articulate them, it seems reasonable to suggest that this inability could contribute to at least some of the problems encountered.

This raises an interesting possibility. ORM or KISS constructs could be used as the language to formally articulate the constraints (action assertions) on organisations, or indeed, any other types of business rule. Further, since these conceptual modelling techniques employ natural language, it suggests that these business rules can be expressed in terms familiar to domain experts. This would allow them to become actively involved in their validation. Therefore, by synthesising these two approaches into a single conceptual framework, analysts may have a mechanism for capturing requirements more completely and with greater accuracy. That ability could help to reduce the risk of project failure.

Conclusions and Future Research

This review has highlighted that the IT industry faces a number of challenges that must be overcome if the current high level of project failure is to be addressed. Central to this problem is the inability of many popular techniques to represent important categories of system requirements and to express those requirements in a form meaningful to domain experts. It has been argued that unless business people can actively participate in the validation process, a common understanding of the system and its requirements would be difficult to achieve.

The business rules model provides a conceptual framework for understanding the structure and behaviour of systems within a paradigm meaningful to both analysts and domain experts. To apply the concepts contained within the model, this approach requires a language to accurately express business rules.

Conceptual modelling approaches such as ORM and KISS exploit the expressiveness of natural language within the formality of an underlying mathematical framework. Either of these conceptual approaches could be synthesised with the concepts and definitions within the BRG report. In doing so, they should provide a rigorous mechanism for expressing business rules. It will be focus of future research to make such an attempt with ORM. The attempt will be limited to the examination of Action Assertions (constraints) to determine whether ORM can be used for the expression of this rule type. Future research will also suggest how linguistic knowledge in the form of semantic analysis could be used to further promote data model quality.

Appendix One

Sourced from GUIDE - The Business Rules Project, Final Report, 1995 (44K GIF)

Reference List

  • Alavi, M., & Carlson, P. (1992). A review of MIS research and disciplinary development. Journal of Management Information Systems, 8(4), 45-62.
  • Bell, T. E., & Thayer T.A. (1976). Software Requirements: Are They Really a Problem? Second International Conference on Software Enginering, San Francisco, pp. 61-68.
  • Campbell, L. J., & Halpin, T. A. (1994). Abstraction Techniques for Conceptual Schemas. Proceedings of the 5th Australasian Database Conference, Christchurch, 16, 374-388.
  • Campbell, L. J., Halpin, T. A., & Proper H.A. (1996). Conceptual Schemas with Abstractions - Making flat conceptual schemas more comprehensible. Data & Knowledge Engineering, 20(1), 39-85.
  • Carlson, C. R., Ji, W., & Arora, A. K. (1990). The Nested Entity-Relationship Model. Proceedings of the Eighth International Conference on Entity-Relationship Approach, Toronto, pp. 43-57.
  • Checkland, P. (1981). Systems Thinking, Systems Practice. Chichester: John Wiley.
  • Chen, P. 1. (1976). The Entity Relationship Model - Towards a Unified View of Data. ACM Transactions on Database Systems, 1(1), 9-36.
  • Conference Board Survey. (2001). ERP Trends Research Report (Report No. R-1292-01-RR). New York: ERP Trends.
  • Dalianis, H. (1995). Aggregation, formal specification and natural language generation. First International Workshop on the Application of Natural Language to Data Bases Versailles, pp. 39-49.
  • Date, C. J. (2000). What, Not How: The Business Rules Approach to Application Development. Reading, Massachusetts: Addison-Wesley.
  • DeMarco, T. (1978). Structured Analysis and System Specification. New Jersey: Yourdon Press.
  • Feather, M. (1987). Language Support for the Specification and Development of Composite Systems. ACM Transactions on Programming Languages and Systems, 9(2), 198-234.
  • Feldman, P., & Miller, D. (1986). Entity Model Clustering: Structuring a Data Model by Abstractions. The Computer Journal, 29(4), 348-360.
  • Fellbaum, C. Ed. (1998). WordNet: An Electronic Lexical Database. Cambridge, Massachusetts: MIT Press.
  • Gamut, L. (1991). Logic, Language, and Meaning. Chicago: University of Chicago Press.
  • Glass, R. L. (1997). Software Runaways. New Jersey: Prentice Hall.
  • Glinz, M. (1995). An Integrated Formal Model of Scenarios Based on Statecharts. The Fifth European Software Engineering Conference, Barcelona, pp. 254-271.
  • Greenspan, S. J., Mylopoulos, J., & Borgida, A. (1982). Capturing More World Knowledge in the Requirements Specification. Sixth International Conference on Software Enginering, Tokyo, pp. 225-234.
  • Greenspan, S. J., Mylopoulos, J., & Borgida, A. (1986). A Requirements Modelling Language and its Logic. Information Systems, 11(1), 9-23.
  • GUIDE Business Rules Project. (1995) Defining Business Rules ~ What Are They Really? Retrieved March 14th, 2003 from http://www.businessrulesgroup.org/first_paper/br01c0.htm.
  • Halpin, T. A. (1996, October). Business rules and object role modelling. Database Programming and Design, pp. 16-22.
  • Halpin, T. A. (2001). Information modeling and relational databases. San Diego: Academic Press.
  • Halpin, T. A. (2002). Join Constraints. Seventh International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design, Toronto, pp. 121-131
  • Halpin, T. A., & Bloesch, A. C. (1999). Data modeling in UML and ORM: a comparison. Journal of Database Management, 10(4), 4-13.
  • Halpin, T. A., & Orlowska, M. E. (1992). Fact-orientated modelling for data analysis. Journal of Information Systems, 2(2), 97-119.
  • Hirschheim, R., & Newman, M. (1991). Symbolism and Information Systems Development: Myth, Metaphor and Magic. Information Systems Research, 2(1), 29-62.
  • Hoppenbrouwers, J., van den Heuvel, W. J., Hoppenbrouwers, S., Weigand, H., & de Troyer, O. (1997) The grammalizer: A case tool based on textual analysis. Retrieved March 2nd, 2003, from http://citeseer.nj.nec.com/article/hoppenbrouwers97grammalizer.html.
  • Hoppenbrouwers, J., van der Vos, B., & Hoppenbrouwers, S. (1997). NL Structures and Conceptual Modelling: Grammalizing for KISS. Data & Knowledge Engineering, 23(1), 79-82.
  • Hoppenbrouwers, J. J., Hoppenbrouwers, S. J., & Vos, J. v. d. (1996). NL structures and conceptual modelling: The KISS case. In Riet, R.P. van de, Burg, J.F., Vos, A.J. van der (Ed.). Applications of Natural Language to Information Systems, pp. 197-209.
  • Jones, C. B. (1990). Systematic Software using VDM. (2nd ed.). New York: Prentice Hall.
  • Kristen, G. (1994). Object-Orientation: The Kiss Method : From Information Architecture to Information System. Boston: Addison-Wesley Longman.
  • Le Charlier, B., & Flener, P. (1998). Specifications are necessarily informal, or: Some more myths of formal methods. Journal of Systems and Software, 40(3), 275-296.
  • Leffingwell, D. (1997). Calculating the return on investment from more effective requirements management. American Programmer, 10(4), 13-16.
  • Manna, Z., & Pnueli, A. (1992). The Temporal Logic of Reactive and Concurrent Systems. Heidelberg: Springer-Verlag.
  • Martin, P. Y., & Turner, B. A. (1986). Grounded Theory and Organizational Research. The Journal of Applied Behavioral Science, 22(2), 141-157.
  • Mazza, C., Fairclough, J., & Melton, B. (1994). Software engineering standards. New York: Prentice Hall.
  • Meyer, B. (1985). On Formalism in Specifications. IEEE Software, 2(1), 6-26.
  • Mumford, E. (1981). Systems, Objectives, Solutions. Participative Systems Design: Structure and Method, 1(1), 5-19.
  • Mylopoulos, J., Chung, L., & Nixon, B. (1992). Representing and using non functional requirements: A process-orientated approach. IEEE Transactions on Software Enineering, 18(6), 483-497.
  • Mylopoulos, J., Chung, L., & Yu, E. (1999). From Object-Oriented to Goal-Oriented Requirements Analysis. Communications of the ACM, 42(1), 31-37.
  • National Audit Office. (2001). Why IT Projects Fail. UK National Audit Review of IT Projects. Retrieved April 25th, 2003 from http://www.nao.gov.uk/intosai/edp/pas/010105ukpaperv2.1.pdf.
  • Nijssen, G. M., & Halpin, T. A. (1989). Conceptual Schema and Relational Database Design: A fact oriented approach. Sydney: Prentice-Hall.
  • OASIG. (1996). The performance of Information Technology and the role of human and organisational factors. Sheffield: Institute of Work Psychology, Sheffield University.
  • Plihon, V., Ralyté, J., Benjamen, A., Maiden, N., Sutcliffe, A., Dubois, E., & Heymans, P. (1998). A Reuse-Oriented Approach for the Construction of Scenario Based Methods. International Software Process Association's Fifth International Conference on Software Process, Chicago.
  • Pohl, K. (1993). The Three Dimensions of Requirements Engineering. Fifth International Conference of Advanced Information Systems Engineering, Paris, pp. 275-292.
  • Potter, B., Sinclair, J., & Till, D. (1996). An Introduction to Formal Specification and Z (2nd ed.). London, New York: Prentice Hall.
  • Potts C., Takahashi, K., & Antnn, A. I. (1994). Inquiry-based Requirements Analysis. IEEE Software, 11(2), 21-32.
  • Rolland, C., & Ben Achour, C. (1998). Guiding the Construction of Textual Use Case Specifications. Data and Knowledge Engineering, 25(1), 125-150.
  • Rumbaugh, J. , Jacobson, I., & Booch, G. (1999). The Unified Modeling Language Reference Manual. Reading, M.A.: Addison-Wesley.
  • Ryan, K. (1993). The Role of Natural Language in Requirements Engineering. IEEE International Symposium on Requirements Engineering, San Diego, pp. 240-242.
  • ter Hofstede, A. H., Proper, A. H., & van der Weide, Th. P. (1994). A conceptual language for the description and manipulation of complex information models. Seventeenth Annual Computer Science Conference, Australia, 16, 157-167.
  • The Standish Group. (1995). The CHAOS Report. Dennis, MA: The Standish Group International.
  • Walsham, G. (1993). Interpreting Information Systems in Organisations. Chichester: Wiley.
  • Wasserman, A. (1979). A Specification Method for Interactive Information Systems. Proceedings of the Specification of Reliable Software Conference, New York, pp. 68-79.
  • Weidenhaupt, K., Pohl, K., Jarke, M., & Haumer, P. (1998). Scenario Usage in System Development: A Report on Current Practice. Third IEEE International Conference on Requirements Engineering, Colorado, 15, 34-45.
  • Whittaker, B. (1999). What Went Wrong? Unsuccessful Information Technology Projects. Information Management & Computer Security, 7(1), 23-30.
  • Yu, E., Du Bois, P., Dubois, E., & Mylopoulos, J. (1995). From organization models to system requirements: a 'cooperating agents' approach. Third International Conference on Cooperative Information Systems, Vienna, pp. 293-312.
  • Yue, K. (1987). What Does It Mean to Say that a Specification is Complete? Fourth International Workshop on Software Specification and Design, Monterey, pp. 34-41.



this issue | home | back issues index | about bitr  | about citrus

Copyright © 2003 The CITRUS Charitable Trust. All rights reserved.
Individual articles remain the property of the authors.