Automatically Acquiring the Requirements of ... - Semantic Scholar

Automatically Acquiring the Requirements of Business Information Systems by using Business Ontology∗ Z.Jin, D.Bell and F.G.Wilkie School of Information and Software Engineering, University of Ulster, the United Kingdom email: {[email protected]}

Abstract Requirement elicitation is the most important parts in the development process of the Business Information Systems(BIS). Errors made at this stage are extremely expensive to correct when they are discovered during testing or during actual working. No ideal methods have been presented up to now. This paper proposes an approach for automatically acquiring the customers’ requirement by reusing the domain knowledge. Our knowledge base contains a business ontology and a set of generic domain models. By using this approach, the customers can describe their business information in a restricted natural language which do not contain any software terminology. And then, the construction of the application requirement specification can be divided into: selection of the domain, creation of the instance concepts, inheritance of the attributes and production of the specification. The construction algorithm has been given in this paper. Keywords: Requirement Elicitation, Business Information Systems, Knowledge-based Approach, Ontology, Generic Domain Model, Conceptual Graphs, Knowledge Representation, Reuse

1 1.1

Introduction Problems and Motivations

The development of the Business Information Systems (BIS) is based on the three-step process: requirement elicitation, system design and implementation. Of which, requirement elicitation is the most important and problematical stage. As we know, requirement elicitation is a time-consuming and prone to errors task. During this stage, the software analysts need to understand the business and produce a specification for the target system. There are many sources can be used in this stage. The first and most important of these is the interview with the customers, e.g. the senior business managers or the executives. Usually, an interview is driven by a number of questions designed by the analysts. And few businesses can be well-defined through only one interview. Whether the collected information is useful or not depends on the analysts’ skills and experiences and the customers’ expertise. Unfortunately, many errors can be made at this stage. And errors made at this stage are extremely expensive to correct when they are discovered during testing or during actual working. Many studies on formal specification languages have been done for making requirement specification precise and consistent. But with the formal languages, how to translate the customers’ description into the formal representation becomes prone to errors. However, it is extremely difficult to judge whether a requirement specification is correct or not during the stage of requirement elicitation. This is an open question which can noly be answered when the application system being put into use. But we can make the requirement specification as close as possible with the needs of the customers and let the unmatched parts be smaller and smaller. A variety of techniques to enhance requirements have been developed during the past years: SADT[7, 6], objectoriented analysis[3, 13], and rapid prototyping[14, 23] ect. Recently because of the acknowledge that multiple participants are necessarily involved in system development, multiple-viewed approaches have been studied[1, 22, ∗ This work is partly supported by the Royal Society of the UK, the National Key Project of China, the National Natural Science Foundation of China, the National Hi-Technology Project of China and the lab of MADIS

1

12, 15, 2]. And some integrated multiple-viewed methods[19, 20, 24] for the software requirements development has also been proposed. It aims to combine multiple views of participants with the ability for the participants to gain feedback from other views. The key issues in these approaches are (1)there may be multiple participants involved in requirement development; (2)each participant constitutes a viewpoint; (3)within a viewpoint, there may be multiple perspectives; (4)the process of software requirements development is the process of conceptual integration of the multiple views.

1.2

Our Solution

But, these approaches do not solve all the problems. As we know, requirement elicitation refers to those activities which attemp to understand the exact needs of the customers of a software intensive system and to translate such needs into precise and unambiguous statements which will subsequently be used in the development of the system. Therefore, requirement elicitation is a very intellectual and creative activity. This activity is far more knowledge intensive than any other system development activities. So, in our opinion, the biggest problem in the requirement step is the lack of background knowledge of the terget domain for both the customers and the analysts. There are two folds of reasons. On the one hand, the analysts can not suppose that the customers can provide their requirement in a systematical and consistent manner. On the other hand, there is misunderstanding between the analysts and the customers. This misunderstanding is due to their different needs and background contexts. They have widely varying viewpoints and assumptions regarding what is essential for the same subject matter. Each uses different jargon. Each may have differing, overlapping and/or mis-matched concepts, structures and methods. This lack of a shared understanding leads to difficulties in identifying requirement and thus in the defining of a specification of the system. Thus, the knowledge-based approach will be very useful in this activity. Our solution is to build a domain knowledge base to assist specification of BIS besides following the spirit of others in combining multiple views. This knowledge base provides a shared understanding of the current problem and the task at hand. It has at least two aspects of roles. First, it serves as the knowledge backgroud and context to help the analysts to understand the customers’ statements. It provides the declarative specification of the concepts in the business domain, which allows the analysts to reason about what the system is designed for. We also view the process of requirement elicitation as the conceptual integration of multiple views. But our multiple-viewed approach is along the other line, i.e. we organize the multiple viewpoints in terms of different aspects of the logical business framework, not different participants. For example, we create a view of activities, a view of organization, a view of resources etc., as parts of the knowledge base. On the other hand, it can be used to guide the customers to furnish their needs in a systematical manner. It also can supply the detail requirement by using the default knowledge, which sometimes are the commonsense knowledge in the application domain, when the customers describe them in an abstract level. And it provides unambiguous definitions for terms used in the business domain. In one word, this knowledge base serves as the bridge between the analysts and the customers. It reduces the conceptual and terminological confusion by providing a unifying framework within a business domain. In this way, it enable shared understanding and communication between the analysts and the customers. This knowledge base serves to be a normative model of the business domain. This creates a semantics for the business domain and an extendible model that can be refined later. The other main feature of our approach is that it can facilitate the process of automatically identifying requirements of the application with a formal knowledge representation. It supports the reusability of requirement. In other words, this knowledge base provides an “easy to reuse” library of class objects for the application in a given domain. This library can be reused and adapted to different application, i.e. it can be customized. Furthermore, it has an extendible architecture allowing the incorporation of new classes of constraints and the specification of concepts etc. The utmost aim of our approach is to let the customers make their specifiation for themselves and then give them the key of developing the their own BIS. In summary, we present an approach which uses a domain ontology as well as the multiple views to assist the automated acquisition of the application requirement. This domain ontology contains the business ontology and the generic domain model. The business ontology provides the top-level classes for integrating the various aspects of various businesses. And a generic domain model describes the organisation and information processing model of a given domain. Then a requirement model of a special application can be constructed by the customers, who

2

are usually not the professional system analysts, by reusing these knowledge.

1.3

Conceptual Graphs

During the last decade, conceptual graphs, as a form of knowledge representation, have been well-studied. We propose using the representation of conceptual graphs[11] as a formal basis of our approach. Conceptual graphs, an extension of semantic networks, provide a very useful tool for representing meaning and combining knowledge or meaning. Their power for representing meaning rests in their kinship with semantic networks, which their power for reasoning is derived from their origins in the formal logic (exstential graphs) of C.S.Peirce[5] and by formal mappings from conceptual graphs to logic formulas. This subsection main summarizes some notations used in this paper. A conceptual graph is a finite and connected grph concsiting of a set of labeled concept nodes, a set of labeled conceptual relation nodes and a set of directed arcs linking concept and relation nodes. Conceptual graphs can be given in a graphical form, called the display form, or as text, called the linear form. This paper mainly adopts the linear form. In summary, the key issues in conceptual graphs includes: • concept node: representing individual concept or abstract concept, declarative concept or procedural concept, containing a type (class) identifier, a referent showing concept names and cardinality and (sometimes) a behavior schema; • relation node: representing relationships between concepts, with arc directions denoting their conceptual dependency. Relation node contains a type identifier and a referent; • conceptual graph: a finite and connected graph consisting of labeled nodes, labeled directed arcs and unlabeled directed arcs. The labels in labeled directed arcs may be necessary, default or optional. Usually, a labeled directed arc is used to be the link from a concept node to a relation node; • nested conceptual graph: an entire graph can serve as a single higher-level concept; • canonical graphs: a conceptual graph that is meaningful, or represents something that is considered true in the domain of interest; • type hierarchy: the set of concept types with the partial ordering, ≤, on them forms a lattice called the type hierarchy, where ⊤ is the universal type and ⊥ is the absurd type; • canonical formation operation: a set of operations which may be applied to conceptual graphs to form new conceptual graphs. The four common canonical formation operations defined on conceptual graphs are:copy(reproducing a graph), restrict(specializing a concept by replacing its type by a subtype if the concept is generic, or by replacing a generic referent by an individual referent), join(uniting two conceptual graphs on matching concepts), and simplify(deleting any redundant conceptual relations in a graph which resulted from a join operation); • defined nodes and undefined nodes: in a conceptual graphs, we call those nodes with ⇒ fanning out the defined nodes and others the undefined nodes; • co-referents: two or more concepts that represent the same instance or occurrence. Such concepts can be connected directly by a dashed line called a line of identity or a co-referent link • degree of important we attach a degree of importance to a dominate concept node and a relation node, to represent the possibility of the occurrences of the concept or the relation In which, the meanings of the referent markers are defined in Table 1. Compared with the previous conceptual graphs, our conceptual graphs have two additional features: 1. it introduces a degree to represent the importance of the concept in the current domain. Now, the degree may be necessary(N), optional(O) or conditional(C) which means “must have”, “if selected” or “if the specified condition C is true, then have” respectively; and 3

Table 1: Referent Markers Referent notation Meaning anonymous variable − ∗ complete inheritance X,Y,Z,· · · variable a,b,c,· · · constant @int measure {a,b,c,...} collective set {a|b|c|...} disjunctive set | or ¬ empty 2. it supports the representation of the behavior concepts. There are two cases. First, each class of atomic activities may have a program schema which is an abstraction of these activities and describes their data-flow and control-flow, but does not contain (all) their actual computations or (all) their actual data structures. Secondly, some concept nodes (other than the activity nodes) may have demons which may be activated when the concepts are involved. For example, the testing for the low level of some resource depository is a demon. The second feature is important for automated system development. Previous conceptual graphs focus on only the declarative knowledge. So, they can only support the conceptualization but not the automated software design and development.

1.4

Organization of this paper

This paper is organized as follows. Section 2 presents the architecture of our requirement elicitation. Section 3 describes the structure of the meta knowledge – the business ontology. The generic domain model, the domain ontology, is defined in Section 4. Section 5 presents the procedure of automated contruction of the application requirement by reusing the business ontology and the generic domain model. Some conclusions will be presented in Section 6.

2

Architecture of the Requirement Elicitation based on Business Ontology

Recently, ontology becomes a very hot topic in almost every fields of computer science. According to the Webster’s dictionary[8], ontology is a particular theory about the nature of being or the kinds of existents. This definition is in a very general level. We prefer a more special one. In [21], the authors report the defintion:“Knowledge engineering aims to represent formally the above existents. Conceptualization is the key issue in knowledge representation which consists of a set of objects, concepts and other entities about which knowledge is being expressed and of relationships that hold among them. Every knowledge model is committed to some implicit or explicit conceptualization. An explicit specification of this conceptualization is called ontology”. In other words, ontologies are agreements about shared conceptualizations which include conceptual frameworks for the domain knowledge of interest. We propose an approach for automatically acquiring the application requirement based on an ontology. This approach is based on the promise that the domain knowledge can be separated from the application systems and it can be captured, represented and then reused in the application systems. In this approach, we divide the knowledge in a BIS requirements into three levels. The first level, which is called “business ontology”, is the general knowledge which can cover all the business domains. The second level, which is

4

called “domain ontology”, contains the shared conceptualizations of a certain domain. And the third level, which is called “application representation”, provides the detailed information about the current application. For different application in the same domain, the application representations may be different but the knowledge in the business ontology and the domain ontology are the same. So, given a certain domain, a BIS requirements specification can be built by instantiating and reusing the components in the business ontology and the domain ontology with the application representation, i.e. customizing the general knowledge. The architecture of the knowledge-based requirement elicitation can be shown as Figure 1. In this figure, the knowledge base consists of the business ontology and a set of domain models. The business ontology is a general ontology which defines a taxonomy of fundamental concepts which are shared by various business domains. It serves as our basic views concerned with the description of the domain models. It organizes a domain model into several knowledge thunks. Each domain model comes from the thoroughly analyzing of the special domain and be organized by the business ontology. We can use an interactive interface or a document analyzor to acquire the customers’ needs. The process flow for developing a requirement specification is: 1. selecting the appropriate domain; 2. recognizing all the entities (or the concepts) the customers have mentioned; 3. constructing the instantiated nodes for those concepts appeared in the knowledge base. And inheriting all the necessary attributes and relationship links for these nodes; 4. creating the nodes for those concepts which are not concerned in the knowledge base. And defining the attributes and the relationship links for these nodes by asking the customers or by analysing the input relevent sentences; 5. joining all the concept nodes into a conceptual graphs of the requirements; 6. checking the consistence and the completeness of the conceptual graphs; 7. evolving the behavior scheme for all the atomic activity nodes; And 8. producing the specification in a formal form.

3

Business Ontology

The business ontology serves as our basic views concerned with the description of the domain models. In order to fully capture specific aspects of the domain models, we define four different views – the Organisation, the Resource, the Activity and the External Organisation. Figure 2 shows the logical structure of business. The main points in this logical structure are: • any business enterprise is an organisation; • some organisations may be divided into small ones. All of the organisations form a hierarchy; • each organisation unit possesses some resources and processes them to produce products or provide services; • products are also a special kind of resources. The organisation sells its products to customers; • the organisation gets resources from suppliers; • some organisation units may exchange some information or resources with some external organisations, such as taxation bureau etc.

5

In the rest of this section, we will present the simplified conceptual graphs representation of the concepts in business ontology. Organisation Ontology An organisation is a stable, formal social structure which has some resources and processes them to achieve its goal. The organisation ontology is modelled by the following framework: [organisation:X] ⇒ {(goal) → [organisation−goal:Y]}+ {(sub− unit) → [organisation:Z]}∗ {(member) → [organisation−agent:U]}+ {(has− resource) → [resource:V]}+ [organisation−agent:X] ⇒ [N](position) → [organization−position:Y] [organisation−position:X] ⇒ [N](role) → [organisation−role:Y] [N](filled−by) → [organisation−agent:Z] [organisation−role:X] ⇒ [O](skill) → [role−skill:Y] {(process) → [activity:Z]}+ ∗ + {} and {} indicate possible repetition of relations attached to a concept. The + means that many relations with the same type may be attached and an asterisk (*) indicates zero or more repetitions. Activity Ontology The activity ontology is represented as: [activity:X] ⇒ {(sub− activity) →[activity:Y]}+ [activity:X] ⇒ [N](enables) →[states:Y:Schema] [N](causes) →[states:Z:Schema] [N](agent) →[organisation−agent:U]|[organisation−unit:V] {(trigger) →[activity:S]}+ In which, an enabling state defines what has to be true in order for the activity to be performed. A caused state defines what is true once the activity has been completed. There are five primitive states which are (in these predicates, r indicates the name of the resource and q represents the amount of the resource that is required for a state to be enabled): • true, false boolean values • consume(r,q), concume(r) signifies that an idle resource is to be used up by the activity and will not exist once the activity is completed • use(r,q), use(r) signifies that an idle resource will be occupied by the activity • release(r,q), release(r) signifies that an occupied resource will be released by the activity • produce(r,q), produce(r) signfies that a resource, that did not exist prior to the performance of the activity, has been created by the activity A composition state can be the conjunction or disjunction of states or the negation of a primitive state. Usually, testing a state may change the status of a resource. For example, after consume(r, q) successes, the amount of available resource r will be decreased. In fact, we define use and consume states to be enabling states since the preconditions for activities refer to the properties of these states, while we define release and produce state to be caused states, since their properties are the result of the activity. Intuitively, a resource is used and released by an activity if none of the properties of a resource are changed when the activity is successfully terminated and the resource is released. A resource is consumed or produced if some property of the resource is changed after termination of the activity; this includes the existence and quantity of the resource, or some arbitrary property. An agent means the actor of the activity. In BIS, an actor usually is a person or an organisation unit. When the actor is an organisation unit, we mean that the actor may be any person that is a member of the organisation unit. 6

A trigger defines what need to be done immediately after the activity has been completed. Resource Ontology The resource taxonomy could be Figure 3. We can use a resource state diagram (see Figure 4) to simulate the resource model. This figure means that resources can be used and released and can be consumed and produced by some activities. Some of them (e.g. the raw material) are allocated into the current business enterprise by inventing from the other enterprises (while consuming some money) and some of them (e.g. the products) can be sold to customers (while making some money). But, in BIS, all of the resources can be captured by a set of information structures. For example, a person A can be identified and represented by a set of attributes, e.g. name, age, degree, salary, · · ·. Materials can be represented by another set of attributes and these attributes may be different for different materials. These attributes usually depend on the domain. The resource ontology is rather simple: [resource:X] ⇒ {(attribute) → [feature− name: Y]}+

4

Domain Ontology

The domain model can be built by domain analysis. Domain analysis is “the process of identifying, collecting, organizing and representing the relevant information in a domain, based upon the study of existing systems and their development histories, knowledge captured from domain experts, underlying theory, and emerging technology within a domain”[4]. Our aims for building domain ontology are understanding the domain in terms of the multiple viewpoints in business ontology and representing this understanding in a reusable form. Our domain ontology contains several parts which are: domain data dictionary, domain organisation ontology, domain activity ontology and domain information ontology.

4.1

Domain Data Dictionary

Domain data dictionary is one of the most useful products of a domain analysis. In a certain domain, the domain data dictionary usually contains two parts: definitions of the data elements and defintions of the data structures. Data elements can be defined by [data− element: X] ⇒ {(attribute) → [feature: Y]}+ Table 2 summarizes the features that might be recorded in the data dictionary for each data element. Table 3 shows a few typical data dictionary entries in retail company domain.

General name alias decription ···

Format data− type data− length units ···

Table 2: features for Dictionary Elements Control Information Usage Characteristics source value− range change− authorization input/output/local security conditional−value access− authorization default− value ··· formation ···

Relationships parent− structure processes reports forms ···

Data structures, also called group or composite data items e.g. forms and reports, are defined by showing the elements and substructures that compose them. The conceptual graph representations for data structures could be: [form:X] ⇒ {(field) → [Form:Y] | [Data−element:Z]}+ [report:X:valid−check] ⇒ 7

Table 3: Some typical data elements in retail company alias UPC, product ID, product code description a key field that uniquely identifies an item of merchandise. Assigned, in sequential order, by the inventory clerk when shipment arrives data− type character data− length 13 ··· ··· product description alias description, product name description a brief verbal description of a product data− type character data− length 40 ··· ··· unit price alias retail price, selling price, customer price description the amount of money a customer pays for a single unit of merchandise data− type money data− length 6 ··· ··· sales tax data− type money data− length 6 definition subtotal*5.5% ··· ··· stock number

[N](report− name) → [string:Y] [N](above−title) → [column−array(M1):T1] [O](left−title) → [column−array(M2):T2] [N](report− body) → [array(m1,m2):B] [column−array(M):X:measure− dimension1(M)] ⇒ (single− field:@M) → [char:Y] [column−array(M):X:measure− dimension2(M)] ⇒ {(multiple−field) → [char:Y] (sub− field) → [column−array(M1):Z:measure− dimension(M1)]}+ [array(M1,M2):X:valid−check] ⇒ (sub− array) → [sub− array((M11,M12),(M21,M22)):Y:CP]+ In which, valid− check, measure− dimension1(M), measure− dimension2(M) and CP are schemas. valid− check for report checks if the dimension of the report title is equal to the dimension of the report body (i.e. M1 = m1 and M2 = m2). valid−check for array check if the definition of the sub− array is valid (i.e. all of the M11,M21∈1,M1, M12,M22∈1,M2, and all of the sub− array do not overlap). measure− dimension(M) produces the dimension of the columns (i.e. computing the number of relation single−field in the graph). And CP is a variable process which is used to computer the value of the elements in the current array. For example, sale receipt and sale report are typical reports in retail company.

4.2

Domain Organisation Ontology

Domain organisation ontology mainly defines the organisation concepts in the domain of interest. It may include several parts: Organisation Unit an organisation unit is a common units in the domain. For example, personel department is an organisation unit in almost all companies, (although it is not a mandatory unit in BIS). Organisation Position an organisation position defines a formal position that can be filled by an organisation agent. Examples of positions in the retail domain include “manager”, “sales clerk”, “accounter”, etc. 8

Organisation Role an organisation role defines a prototypical function of an organisation position and the role skill. For example, position sale clerk’s task is ‘dealing with the sales transactions’, etc. The role skill means that the prerequisite for the agent filling the position, such as ‘has a MS degree’, etc. A conceptual graph for sales clerks in retail domain could be: [N][organisation−position: sales clerk] ⇒ (role) → [organisation−role: sales− dealing] ⇒ (skill) → [role− skill: computation] [N](process) → [activity: dealing−sales− transaction]

4.3

Domain Activity Ontology

Domain activity ontology describes all the possible activities in this domain. It includes the complex domain activities such as dealing− sales− transaction and the atomic domain activities such as fill− out(sales receipt) and prepare(sales report). For example, [N][activity: dealing−sales− transaction] ⇒ [N](sub− activity) → [activity: fill−out(sales receipt)] [O](sub− activity) → [activity: prepare(sales report)] [N][activity: fill−out(sales receipt): computing− total−due(Total−due)] ⇒ (enables) → consume(item1 ,amount1 ) and · · · and consume(itemn ,amountn) (causes) → produce(finance, Total−due) (agent) → [organisation−agent: X] ⇒ (position) → [organisation−position: sales clerk] In which, itemi s,amounti s are the purchase items and the amounts of these items respectively.

4.4

Domain Information Model

Domain information model represents the features of the resource depository, i.e. the features of the individual resources (i.e. entities) and the relationships between them. There are several approaches to build the representation of the domain entities and their relationships by the domain information analysis. The information model may take the form of an entity-relationship (ER) model[16], an object-oriented model[9] or other representations. All of these forms are to ensure the proper data abstractions and decompositions. Apart from these, the information model also defines data that is assumed to come from external sources.

4.5

Other Domain Knowledge

Other domain knowledge includes the synonymous relationships, subsumptive relationships, aggregation relationships and specification/generalization relationships between concepts in this domain.

5 5.1

Construction of Application Requirement Customers’ Needs

We allow the customers writing their needs in a restricted natural language[18, 17]. Our sublanguage has limited vocabulary and only contains the context-free sentences. Some troublesome constructions have been restricted. For example, the interrogatiove and imperative sentences are not allowed to occur in customers’ documennt. A simple example in the retail domain could be: Mini-Tesco is a retail company. Mini-Tesco has a manager and a sales clerk. The sales clerk deals with the sales transactions. The manager deals with the inventory transaction apart from the daily duty as a manager. 9

Commnet: the first sentence means that a company named mini-Tesco is a retail company. This sentence is for selecting the appropriate domain. The second sentence said there are two organisation agents in this supermarket which fill the positions of the manager and the sales clerk respectively. The third sentence defines the tasks of its sales clerk. And the fourth sentence states the tasks of its manager.

5.2 5.2.1

Algorithm skeleton for generating an application requirement graph Recognizing concepts

An extension of concetual dependency theory[25, 26] has been used to build the conceptual dependency structure for each sentence in the customers’ document. Table 4 shows the concept entities in the above example.

domain supermarket

5.2.2

Table 4: Concept Entity agent tasks (manager, 1) daily tasks inventory transaction (sales clerk, 1) sales transaction

Creating concept nodes

For each concept entity stated by the customers, create one or more concept nodes or conceptual graphs in terms of the type of the concept. For example, the concept nodes for the above example requirement document include: [domain: retail] [organisation: mini-Tesco] [organisation−position: manager] ⇒ (process) → [activity: inventory] [organisation−position: manager] ⇒ (process) → [activity: *] [organisation−position: sales clerk] (process) → [activity: dealing−sales− transaction] [manager: @1] [sales clerk: @1] 5.2.3

Inheriting nodes and attributes

First, selecting a appropriate domain for current application in terms of concept node [domain: node− name]. Secondly, inheriting all necessary nodes which do not appear in the application description. Thirdly, for each concept node of the application description, finding the corresponding node in the canonical graphs (we call the conceptual graphs in knowledge base the canonical graphs). Do the graphs inheritance operations. Those newly introduced nodes will be treated as the concept nodes in application description. Some graphs inheritance operations are shown in Table 5. There may be the case that the two concepts can not be exactly matched. We can use some other tools on words meaning, e.g. Wordnet[10], to handle the synonym problem, the homonym problem, the subclass problem and the generality problem. 5.2.4

Creating objects

10

Table 5: canonical graphs [type1:A](nondefined node) [type1:A] ⇒ [N](arc)→[type2:*] [type1:A] ⇒ [N](arc)→[type:X] [type1:A] ⇒ [N](arc)→[type:X] [type1:A] ⇒ [N](arc)→[type:other− value] [type1:A] ⇒ [N](arc)→[type:other− value] [type1:A] ⇒ [O](arc)→[type:*] [type1:A] ⇒ [O](arc)→[type:other− value] ···

Some Graphs Inheritance Operations application description graphs application requirement graphs [type1:A] [type1:A] No/Yes nonsense [type1:A]⇒ (arc)→[type2:B] No definition

[type1:A]⇒ (arc)→[type:B] incomplete

No definition

[type1:A]⇒ (arc)→[type:other− value] [type1:A]⇒ (arc)→[type2:B] nonsense

[type:A]⇒ (arc)→[type2:B] No/Yes No definition ···

[type1:A]⇒ (arc)→[type:other− value] ···

For each unknown concept node in the application conceptual graphs, asking the customers to furnish the defintion until all of the introduced concept nodes are defined concept nodes or terminal concept nodes in the canonical graphs. 5.2.5

Joining conceptual graphs

Now, we get several separate conceptual graphs. By joining these graphs, we can get a connected conceptual graph. This graph can be divided into three layouts. The first level is in fact a hierarchy of the organisation units. The root of the hierarchy is current business company. The second level is a set of conceptual graphs. Each of them manily describes the activity model of an organisation unit. The third level is the information model. All of the atomic activity operates on the conceptual nodes of the information model. It is noticed that the schemas of the actomic activities may need to be adapted because of the outstanding changes in the information model. (this topic is beyond the scope of this paper. We will study it in another paper) 5.2.6

Checking the completeness

We say a requirement conceptual graph is complete if all of the non-defined nodes in the graph is terminal concept nodes. A terminal concept node is the node of a data element.

6

Conclusions

Our work contributes to existing work in requirements elicitation by proposing a knowledge-based framework for automatically acquiring the customers’ requirements in BIS. This approach relies on the ontologies, which captures the general knowledge and the domain knowledge, to generate an application requirement conceptual graph. The conceptual graph represents the application requirements in a three-layout form: the enterprise organisation decomposition, the organisational functional decomposition and the information structures. The requirements graph can be directly used to automatically design and implement the target BIS. The proposed framework shows how requirements can be represented in the knowledge base in a reusable form i.e. canonical graphs. A canonical graph provides a segment of the requirements. The application requirements can be obtained by instantiating and inheriting the canonical graphs. Requirements reuse can be achieved. 11

Our work also provides the customers a restricted natural language to describe their business information. With this language, the users don’t need to learn the terminology of software development. In other words, they can develop their requirements by themselves. We believe that the proposed approach is general enough to be applicable across a wide variety of domains for BIS developments. In fact, this approach does not make any assumptions regarding the nature of the target BIS to be specified. One limitation of this approach is that it is based on the promise that the general business ontology and domain knowledge can be represented and managed. We did not address the issue of knowledge acquirement or domain analysis. In many problem domains, not only is it difficult to locate experts, but it is also difficult to extract their knowledge. Of course, many techniques on knowledge acquirement and domain analysis can be helpful to address this problem. This work will be extended in several ways in future research. First, increment development of the conceptual graphs would be helpful to facilitate the users to evolve the application requirements. Secondly, the further researches of the formal ontologies are also interesting. That is very useful for understanding the BIS domain and facilitating the high-level requirements reuse in BIS domain.

References [1] A.Finkelstein, J.Kramer, B.Nuseibeh, L.Finkelstein, and M.Goedicke. Viewpoints: a framework for integrating multiple perspectives in system development. International Journal of Software Engineering and Knowledge Engineering, 2(1):31–57, 1992. [2] B.Nuseibeh, J.Kramer, and A.Finkelstein. A framework for expressing the relationships between multiple views in requirements specification. IEEE Transactions on Software Engineering, 20(10):760–773, 1994. [3] Grady Booch. Object-Oriented Analysis and Design. Redwood City, California: Benjamin/Cummings, 1994. [4] Kyo C.Kang, Sholom G.Cohen, James A.Hess, William E.Novak, and A.Spencer Peterson. Feature-oriented domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21, Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1990. [5] Don D.Roberts. The Existential Graphs of Charles S.Peirce. Mouton, The Hague, 1973. [6] D.T.Ross. Applications and extensions of SADT. IEEE Computer, 18(4):25–35, 1985. [7] D.T.Ross and J.Kenneth E.Schoman. Structured analysis for requirements definition. IEEE Transactions on Software Engineering, 3(1):6–15, 1977. [8] H.B. Woolf ed. Webster’s new collegiate dictionary. MA: G. & C. Merriam Company, 1981. [9] J.Rumbaugh et al. Object-Oriented Modelling and Design. Englewood Cliffs, NJ: Prentice Hall, 1991. [10] G.A.Miller. WordNet: A lexical database for english. Communications of ACM, pages 39–41, 1995. [11] J.F.Sowa. Conceptual Structure: Information Processing in Mind and Machine. Addison-Wesley Publisher, Reading, Mass, USA, 1984. [12] J.C.S.P. Leite and P.A.Freeman. Requirements validation through viewpoint resolution. IEEE Transactions on Software Engineering, 17(12):1253–1269, 1991. [13] Alan M.Davis. Software Requirements: Object, Functions and States. Prentice-Hall, 1993. [14] M.Smith. Software Prototyping. New York: McGraw Hill, 1991. [15] Hans Nissen, Manfred Jeusfeld, Matthias Jarke, Georg Zemanek, and Harald Huber. Managing multiple requirements perspectives with metamodels. IEEE Software, 12(6):37–48, 1996.

12

[16] P.Chen. The entity-relationship model - towards a unified view of data. ACM Transactions on Database Systems, 1(1):9–36, 1976. [17] R.Lu and Z.Jin. An multi-agent and pseudo-natural language approach for intelligent information service. In Proceedings of the International Conference on the Software Engineering and the Knowledge Engineering (SEKE’97), Madrid Spain, 1997. [18] R.Lu, Z.Jin, and R.Wan. Requirement specification in pseudo-natural language in PROMIS. In Proceedings of COMPSAC’95, USA, 1995. [19] Harry S.Delugach. Specifying multiple-viewed software requirements with conceptual graphs. Journal of Systems and Software, 19:207–224, 1992. [20] Harry S.Delugach. Conceptual integration in multiple viewed requirement development. Technical Report TR-UAH-CS-1997-03, Computer Science Department, University of Alabama in Huntsville, 1997. [21] Mike Uschold and Michael Gruninger. ONTOLOGIES: Principles, methods and applications. Technical Report AIAI-TR-191, Artificial Intelligence Application Institute, University of Edinburgh, February 1996. [22] Axel van Lamsweerde, R.Darimont, and P.Massonet. Goal-directed elaboration of requirements for a meeting scheduler: Problems and lessons learned. In Proceedings of RE’95, 2nd International Symposium on Requirements Engineering, York, 1995. IEEE. [23] W.Bischofberger and G.Pomberger eds. Prototype-Oriented Software Development. Berlin, Germany, Springer Verlag, 1992. [24] W.R.Cyre. Capture, integration, and analysis of digital system requirement with conceptual graphs. IEEE Transactions on Knowledge and Data Engineering, 9(1):8–23, 1997. [25] Z.Jin P.Sebillot and F.Danna. A knowledge-based approach for analyzing and understanding the students’ sentences. In Proceedings of the Natural Language Processing Pacific Rim Symposium 1997 (NLPRS’97), Thailand, 1997. [26] Z.Jin P.Sebillot and F.Danna. A natural language interface in COMPOUNDS. Chinese Journal of Advanced Software Research, 1998.

13

the customers

?

recognizing concepts

Knowledge Base

Business

-

?

instantiating

creating

concept objects

concept objects

?

?

inheriting attributes and relationship

defining attributes and relationship

?

Ontology

?

Requirements Object Repository

Domain

Model

-

?

Joining object graphs

?

Checking consistence and completeness

?

Evolving behavior scheme

?

Producing specification

?

the documents Figure 1: Architecture of Requirement Elicitation

14

EXTER− ORG

SUPPLIER

ORGANISATION

RESOURCE

CUSTOMER

ACTIVITY Figure 2: Logical Structure of Business

?P@PPPP     ? @ PPPP   @@  ? PPPP   ?   PP  @  ? resource

people

products

materials

finance

Figure 3: Resources Taxonomy

consumed consume raw material



allocate

-

6

idle

6 release

produce

?



sell

use

?

occupied

Figure 4: State Diagram of Resources

15

-

products