Detecting Inconsistencies in Requirements Engineering

Transcription

1 Swinburne University of Technology Faculty of Information and Communication Technologies HIT4000 Honours Project A Thesis on Detecting Inconsistencies in Requirements Engineering Tuong Huan Nguyen

2 Abstract Requirements Engineering (RE) is the first phase in the software development life cycle, concerning about the requirements of stakeholders on the software system being developed. RE involves a process of eliciting, elaborating, structuring, specifying, analyzing and managing of what problems the software solution is required to solve, why such problems need to be solved and who should be involved in the responsibility of solving the problems. RE is considered one of the most critical processes in the software development as requirements are the source of all other activities including designing, implementation or testing. Therefore, ensuring the correctness and completion of software projects requirements is the goal of RE. However meeting that goal is a challenge for requirements engineers as different stakeholders are likely to have different perspectives, which yield to inconsistencies or conflicts among their requirements. Inconsistency is considered a serious problem in RE because it results in an impossibly implemented system (system addressing conflicting features) and so the project cannot be successful. Therefore, identifying potential inconsistencies (so that they can be resolved) is a very important step in RE. Due to the limitations of related works in this field, which are either insufficient or requiring deep expertise in Logics, our research aims to develop a model that supports the process of Requirements Engineering in which requirements can be elaborated, managed and analyzed for the identification of inconsistencies and other related issues (redundancies and overlaps). In addition, the model also provides a user-friendly method for completing those tasks. The contributions of this thesis are as follows. It builds a Requirements Engineering Process model based on the Goal-oriented Requirements Engineering approach for capturing goals and requirements through a bi-directed goal refinement process. On the one hand, goals are refined into sub-goals based on the HOW question, which is HOW is this goal achieved?. On the other hand, the existence of goals can be verified with the bottom-up direction by asking the WHY question, which is WHY does this goal exist?. This top-down and bottom-up process ensures the correctness of requirements elaboration process. In addition, the thesis proposes the use of Manchester OWL Syntax, accompanied with pre-defined patterns, for formalizing requirements in a user-friendly way. The use of Manchester OWL Syntax does not

3 require users to have special expertise, making it easy for communicating requirements among participants in the project, who are from different backgrounds, including programmers, requirements engineers, testers or business domain experts. The identification process of inconsistencies, redundancies and overlaps can be achieved by relying on Pellet reasoner for the analysis and reasoning services on formalized requirements. REInDetector, a prototype tool has also been developed for illustrating the research idea, verifying and demonstrating the results of the work. ii

4 Acknowledgement I would like to sincerely thank my supervisor, Dr. Bao Vo, for his vision, guidance, patience and discussions during my Honours year. Without his great support, this work would not have been possible. iii

5 Declaration This thesis contains no material which has been submitted for the award of any other degree or diploma. To the best of my knowledge, this thesis contains no material previously published or written by other people except where due reference is made. iv

6 Table of Contents 1. INTROD UCTION REQUIREMENTS ENGINEERING THE RESEARCH QUESTIONS THE APPROACH T AKEN RESEARCH ACCOMPLISHMENTS RESEARCH LIMITATIONS THESIS STRUCTURE SUMMARY BAC KGROUND GOAL ORIENTED REQUIREMENTS ENGINEERING DESCRIPTION LOGICS Sem antics Examples THE MANCHESTER OWL SYNTAX Manchester Syntax s semantics Examples INCONSISTEN CIES, REDUNDANCIES AND OVERLAPS PELLET REASONER RELATED WORKS SUMMARY A MOTIVATING SCENARIO THE BUSINESS OBJECTIVES SYSTEM REQUIREMENTS Functional Requirements Non functional Requirements REQUIREMENTS ANALYSIS Inconsistencies Redundancies Overlaps ISSUES WITH THE CURRENT APPROACH SUMMAR Y REQUIREMENTS ENGINEERING PROCESS MODEL MODEL O VERVIEW REQUIREMENTS SPECIFICATION LANGUAGE GOAL REFINEMENT PROCESS AND Link OR Link Optional Link GOAL ANNOTATIONS APPLICATIONS OF THE MODEL Refinement Graph Goal Formalization SUMMA RY ANALYSIS AND REASONING SERVICES O WL FILES INCONSISTENCY DETECTION REDUNDANCY DETECTION v

7 5.4 OVERLAP DE TECTION REQUIREMENTS QUERY PROBLEM DETECTION RESULTS SU MMARY REQ UIREMENTS FORMALIZATION PATTERNS WHY ARE PATTERNS N EEDED? FORMALIZATION RULES FORMALIZATION PRE DEFINED PATTERNS Property Patterns Expression Patterns SUMMAR Y IMPLEMENTATION OF PROTOTYPE D ESIGN PACKAGE G UI PA CKAGE RE P ACKAGE REASONER THE ROLES OF REINDETECTOR SUMMARY CON CLUSION ACCOMPLISHMENTS LIMITATIONS AND FUTURE WORKS SUMMARY APPENDIX 1 COMPLETE GOAL REFINEMENT GRAPH APPENDIX 2 OWL FILE EXAMPLE REFERENCES vi

8 List of Figures Figure 1.1 Thesis Structure... 5 Figure 2.1 Semantics of concept constructors in SROIQ for an interpretation I with domain I [18] Figure 2.2 Examples of SROIQ Figure 2.3 Semantics of Manchester Syntax Figure 2.4 Examples for the use of Manchester OWL Syntax Figure 4.1 An example of AND Links Figure 4.2 An example of OR Links Figure 4.3 An example of Optional Links Figure 4.4 Example of goal annotations Figure 4.5 Refinement Graph Figure 4.6 Formalization of Supporting Photo Upload goal Figure 4.7 Formalization of Photo Size goal Figure 4.8 Formalization of Photo Format List goal Figure 4.9 Formalization of Photo Format Conversion goal Figure 4.10 Formalization of Supporting Batch Mode Upload goal Figure 5.1 Photo class s definition in an OWL file Figure 5.2 Algorithm for inconsistency detection Figure 5.3 Algorithm for detecting redundancies Figure 5.4 Algorithm for detecting overlaps Figure 5.5 Inconsistency Case Figure 5.6 Redundancy Case Figure 5.7 Overlap Case Figure 6.1 Basic Expression Pattern Figure 6.2 Referencing Expression Pattern Figure 6.3 Purposes and/or Instrument Expression Pattern Figure 7.1 ReInDetector Architecture vii

9 Figure 7.2 Structure of GUI package Figure 7.3 Structure of RE package Figure 7.4 Structure of Reasoner package viii

10 Chapter 1 Introduction 1. Introduction 1.1 Requirements Engineering Requirements Engineering (RE) is the first step in any software system development project, concerning about the requirements of stakeholders on the software system. RE involves a process of eliciting, elaborating, structuring, specifying, analyzing and managing of what problems the software solution is required to solve, why such problems need to be solved and who should be involved in the responsibility of solving the problems. RE is considered one of the most critical processes in the software development life cycle as requirements are the source of all other activities including designing, implementation or testing. A software project won t be successful if the goals of developing the software system are not met; the requirements of stakeholders are not fulfilled. Therefore, ensuring the correctness and completion of software projects requirements is the goal of RE. 1.2 The Research Questions One of the challenges for requirements engineers in the RE process is the inconsistencies or conflicts between requirements. Two or more requirements are considered inconsistent if they can t be satisfied by the system being developed in any way without scarifying at least one of them. Inconsistency is considered a serious problem in RE because it requires removing or modifying requirements to ensure that a consistent and realistic requirement set is produced at the end of the process. In addition, either removing or modifying a requirement should always be done with cautions as adjusting stakeholders expectations would directly affect the success of the project. Therefore, identifying potential inconsistencies is a very important step in RE. From the results of the detection, requirements engineers would be able to decide the actions to take to ensure the requirements accuracy and completion. A number of works has been done in detecting requirement inconsistencies in RE. In KAOS system [4], requirements are represented in linear temporal logics (LTL) and inconsistencies are identified based on the LTL reasoning service provided by the system. Although rigorous, this approach is too formal and requires requirements engineers to have an expertise in LTL. In addition, KAOS lacks of the supports for semantics in requirements, which are about the relationships between different concepts in the requirements domain. In Requirements Engineering, the relationships between 1

11 Chapter 1 Introduction concepts are really important in order for any analysis and reasoning to be performed on requirements. Therefore, in our opinion, this is a major issue in KAOS and needs to be addressed in our research. In Win-Win system [10], inconsistencies are detected based on a pre-defined knowledge base of potential conflicting attributes. This approach, although can produce fast and precise results in some situations, are not complete and sound because the correctness of the identification process heavily depends on the sufficiency of the knowledge base. Therefore, the need for a userfriendly, complete and sound method of inconsistency identification which is suitable for practitioners like business domain experts, business analysts or software testers become an important research problem. In addition, in many cases, the inconsistencies come from different goals and perspectives of different stakeholders. For instance, in a library system, one of the requirements from users (borrowers) is that a borrower of a book can keep it as long as he/she needs it. However, from the perspective of a librarian, the loan of a book can only be extended if there is no other people requests it. The inconsistency here comes from the difference of perspectives regarding the same factor. Before the inconsistencies can be resolved, it is a need that requirements engineers are able to trace for the source they come from. Furthermore, apart of ensuring a consistent requirement set to be produced, it is also important for guaranteeing the completeness of the requirement set and also avoiding unnecessary (or unrelated) requirements. Thus, in this research we also aim to produce a userfriendly model for supporting requirements engineers in elaborating, managing and analyzing requirements for inconsistencies and related issues (redundancies and overlaps). The model also provides links between requirements and incorporates the value (perspectives) that they are derived from. Research Questions: From the discussed problems, the following research questions are to be addressed in this thesis: 1) How to support requirements engineers in elaborating requirements sufficiently while avoiding irrelevant requirements and also support the traceability of inconsistencies sources. 2) How to provide semantics in requirements. 2

12 Chapter 1 Introduction 3) How to provide user-friendly approach for representing and detecting inconsistencies among requirements. 1.3 The Approach Taken Our approach of solving the problems is to use Goal-Oriented Requirements Engineering (GORE) [6][7] model for supporting the RE process. In GORE, the term requirement could be used interchangeable with goal because they both refer to what the software system needs to fulfill to meet the stakeholders needs. In the model, requirements are defined through the refinement process. A specific goal is refined by asking the HOW question, which is How can this goal be achieved?. By this way, the added requirements are always the ones which directly contribute to the realization of the refined goal. Therefore, the chance of irrelevant requirements would be eliminated. The model is extended to embed values to each goal for providing the traceability of inconsistencies sources. For the second problem, we use Description Logics (DL) [18] for the representation of requirements. DL is a family of languages that are decidable subsets of First-Order logic commonly used as the formal bases of object/class style ontology languages, which makes it fit nicely into the second research problem of providing semantics into requirements. In facts, by using DL, we can define concepts, individuals and the relationships between them (through roles) and therefore the semantic issue can be addressed. Specifically, we use Manchester OWL Syntax [32], which is less logician like and easy to read and write syntax, to promote the user-friendliness (Manchester OWL Syntax can be used to represent everything which is written in Description Logics). To support the process of translating requirements from informal natural language representation to Manchester OWL Syntax, we developed a set of requirement formalization patterns for Manchester Syntax based on the investigation of over 500 requirements in real world software projects [30]. In addition to inconsistencies, we also provide methods for the identification of redundancies and overlaps among requirements. The identification of overlaps would help raising attentions for requirements engineers about potential sources of inconsistencies while the finding about redundancies helps them remove unnecessary elements from the requirement set. The detection of inconsistencies, redundancies and overlaps are conducted by extending the Pellet reasoner [14]. 3

13 Chapter 1 Introduction The RE model will be discussed in chapter 4. The use of Pellet reasoner for providing analysis and reasoning services will be described in chapter 5 and requirements formalization pattern will be presented in chapter Research Accomplishments At the end of the project, the author of this thesis has completed the development of the RE model which is based on Goal-oriented Requirements Engineering model to support requirements engineers with the RE process. The model allows the refinement process, supports the relationships between requirements and also embeds value to each defined requirement. In addition, a requirement pattern library has been developed for supporting the representation of requirements in Manchester Syntax. Through the use of the syntax, semantics can be added to requirements through an ontology of concepts, which is created and maintained in the model. The Pellet reasoner has also been extended to allow the detection of inconsistencies, redundancies and overlaps. A software prototype ReInDetector has been architected and implemented to demonstrate the feasibility of the chosen approach. 1.5 Research limitations The research work in this thesis is equivalent to one semester, twelve weeks, full load in the Faculty of ICT, Swinburne University of Technology. Due to this time constraint, the work of the thesis has the following limitations: Complex requirements can t be represented and supported because of the limited expressive power of Description Logics. The requirement pattern library therefore doesn t cover all possible requirements. The process of identifying overlaps is complete by not sound due to the Open World Assumptions in Pellet reasoner. 4

14 Chapter 1 Introduction 1.6 Thesis Structure Figure 1.1 depicts the structure of the thesis. Readers should follow the arrows to navigate between chapters. Figure 1.1 Thesis Structure 5

15 Chapter 1 Introduction Chapter 2 presents the backgrounds of this research work. We will introduce the approach of Goal-oriented Requirements Engineering and its advantages over the traditional approach of Requirements Engineering. We will also discuss about Description Logics, Manchester OWL Syntax which is used for requirements formalization in our work. The formal definitions of inconsistencies, redundancies, overlaps and the introduction of Pellet reasoned will also be covered in this chapter. Chapter 3 provides a motivating example, which is about a Social Networking System project. The scenario will be used in most of the examples provided in this thesis. Chapter 4 discusses about the Requirements Engineering Process model that we propose. The details of the model, accompanied with examples will be presented. Chapter 5 describes the algorithms for the analysis and reasoning services in our work, including the identification of inconsistencies, redundancies and overlaps. Chapter 6 introduces our pre-defined requirements formalization patterns in Manchester OWL Syntax. Chapter 7 discusses about the design and implementation of REInDetector JAVA prototype. Chapter 8 concludes the work presented in this thesis, discusses about the accomplishments as well as points out future works. The appendices provide some additional important data which will be mentioned in the thesis body. 1.7 Summary In this chapter, we have described the context of the work, the goals and research questions which are the main focus in this research. We have also discussed about the approach taken, the accomplishments and limitations of the work. The structure and brief overview of each chapter and appendices have been also provided. 6

16 Chapter 2 Background 2. Background In this chapter, we present the general background of our work. The first section provides a brief introduction to Goal-oriented Requirements Engineering. The second section is about Description Logics. We will also discuss about the OWL language and Manchester OWL Syntax in the third section. In the next section, we will provide the formal definitions of inconsistency, redundancy and overlap. That will be followed by a description of the pellet reasoner for Description Logics, which is the core of all reasoning services in our research. The chapter will end with a review of other related works. 2.1 Goal oriented Requirements Engineering One of the oldest definitions of Requirements Engineering is that requirements definition is a careful assessment of the need that a system is to fulfill. It must say why a system is needed, based on current or foreseen conditions, which may be internal operations or external market. It must say what system features will serve and satisfy this context. And it must say how the system is to be constructed [6]. Therefore, requirements engineering must address the reasons why a software system is needed, the functionalities it must have to achieve its purpose and the constraints on how the software must be designed and implemented [7]. Lamsweerde [9] describes the following intertwined activities that are covered by requirements engineering: Domain analysis: the environment for the system-to-be is studied. The relevant stakeholders are identified and interviewed. Problems with the current system are discovered and opportunities for improvement are investigated. Objectives for the target system are identified. Elicitation: alternative models for the target system are analyzed to meet the identified objectives. Requirements and assumptions on components of such models are identified. Scenarios could be involved to help in the elicitation process. Negotiation and agreement: alternative requirements and assumptions are evaluated; risks are analyzed by the stakeholders; the best alternatives are selected. 7

17 Chapter 2 Background Specification: requirements and assumptions are formulated precisely. Specification analysis: the specifications are checked for problems such as incompleteness, inconsistency, etc. and for feasibility. Documentation: various decisions made during the requirements engineering process are documented together with the underlying rationale and assumptions. Evolution: requirements are modified to accommodate corrections, environmental changes, or new objectives. The major disadvantage of the traditional Requirements engineering approaches is the inadequacy of them in dealing with complex software systems [12][39][24]. These approaches treat requirements as consisting of only processes and data and do not capture the rationale behind them, thus making it difficult to understand requirements with respect to some high-level concerns in the problem domain. In addition, most techniques focus on modeling and specification of the software alone and therefore, lack of support for reasoning about the composite system comprised of the system-tobe and its environment [24]. Goal-oriented Requirements Engineering (GORE) approach was developed in an attempt to overcome these problems. GORE is concerned with the use of goals for eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and modifying requirements [7]. The idea of Goal-oriented RE is derived from the recognition that goals are the root from that all requirements of the project would be defined. In fact, the current system under consideration is typically analyzed in its organizational, operational and technical settings. As soon as problems are pointed out and opportunities are identified, high-level goals are identified and refined to address such problems and meet the opportunities; requirements are then elaborated to meet those goals. Requirements are then refined into more specific requirements to meet the higher-level requirements. Other requirements would then be generated by repeating this process. GORE addresses the issues of lacking of requirements rationale by providing both top-down and bottom-up links between requirements so that from a specific requirement, it is possible to point out the underlining reason of it (through the links to higher-level requirements) and also how it is realized by the system being developed (through the links to lower-level requirements). 8

18 Chapter 2 Background The main benefits of GORE can be listed as follows: Goals provide a precise criterion for sufficient completeness of a requirements specification; the specification is complete with respect to a set of goals if all the goals can be proved to be achieved from the specification and the properties known about the domain considered [25]. Goals help avoiding irrelevant requirements. To this end, goals provide a precise criterion for requirements pertinence; a requirement is pertinent with respect to a set of goals in the domain considered if its specification is used in the proof of one goal at least [25]. GORE also helps explaining requirements to stakeholders. Goals provide the rationale for requirements, in a way similar to design goals in design processes [21] [22]. A requirement appears because of some underlying goal which provides a base for it [13] [3] [20]. More explicitly, a goal refinement tree provides traceability links from high-level strategic objectives to low-level technical requirements. In particular, for business application systems, goals may be used to relate the software-to-be to organizational and business contexts [15]. Goal refinement provides a natural mechanism for structuring complex requirements documents for increased readability. Requirements engineers are faced with many alternatives to be considered during the requirements elaboration process. Van Lamsweede [7] has pointed out that alternative goal refinements provide the right level of abstraction at which decision makers can be involved for validating choices being made or suggesting other alternatives overlooked so far. Alternative goal refinements also allow alternative system proposals to be explored [9]. GORE has been extensively used in the areas of Requirements Engineering research. Some to name a few are Non-Functional Requirements Framework (NFR) [23][27], i*/tropos [16], KAOS [4][8][35] and GBRAM [2][1]. 2.2 Description Logics As our formalization of requirements is based on Description Logics (DL), in this section, we present the SROIQ Description Logic, which is the most expressive 9

19 Chapter 2 Background language in the family of DLs. We start the section with the semantics of SROIQ, we then provide some examples to demonstrate the use of the language Semantics In DL, the domain of interest is modeled by individuals, concepts and roles. Individuals are the instances that belong to particular concepts while roles consist of both unary and binary relations between concepts or individuals. In this section, we use C and D to denote concept expressions. A concept inclusion axiom is an expression of the form (which means C is a inclusive concept of D). A SROIQ TBox is a set of general concept inclusion axioms. An ABox is a finite set of concept expressions of the form (which means a is an instance of C) and role assertions in the form R(a, b) (which means a and b are related in the relationship defined by R). The SROIQ knowledge base is the union of the TBox and ABox. An interpretation I consists of a set Δ called interpretation domain and an interpretation function. mapping. The interpretation function assign to each atomic concept A a subset of Δ, each role R a subset of Δ xδ and each individual a an element of Δ. The Figure 2.1 illustrates the syntax for expressing concepts in SROIQ. Figure 2.1 Semantics of concept constructors in SROIQ for an interpretation I with domain I [18] Examples In this sub-section, we present some examples to illustrate the use of SROIQ as a formal expression language. The examples, which are adapted from [19], are described in Figure 2.2: 10

20 Chapter 2 Background SROIQ constructors Example Meaning Conjunction ( ) Man Person Male A man is a person with the sex of Male. Disjunction ( ) Parent Father Mother A parent can be either a father or a mother. Negation ( ) Woman Person Man A woman is a person but not a man. Inclusion ( ) Woman Person A Woman is a Person (in other words, the Woman concept is inclusive in the Person concept) Nominal ({}) {Charles} This represents an individual named Charles. Universal restriction ( ) MotherWithoutDaughter Mother haschild. Woman A mother without any daughter is a mother whose all children are not women. Existence restriction ( ) Mother Woman haschild.person A mother is a woman who has at least one child (as a person). Qualified number restriction ( and ) MotherWithManyChildrens Mother 3 haschild A mother with many children is a mother who has at least 3 children. Figure 2.2 Examples of SROIQ 2.3 The Manchester OWL Syntax Web Ontology Language (OWL) is a language that is intended to be used when the information contained in documents needs to be processed by applications, as opposed to situations where the content only needs to be presented to humans. OWL can be used to explicitly represent the meaning of terms in vocabularies and the relationships between those terms. This representation of terms and their 11

21 Chapter 2 Background interrelationships is called ontology. OWL can be used to write almost all the expressions which can be written using Description Logics. OWL 2.0, the newest version of OWL, is built based on SROIQ and thus, allow all expressions supported in this version of description logic. Web ontologies can be represented in different syntaxes provided by OWL 2.0. There are some different between OWL and DL with respect to terminologies. In OWL 2.0, class is used to refer to concept in DL while property and object are used to denote role and individual respectively. In our research, we choose the Manchester Syntax [32], which is the user-friendliest OWL syntax, to formulate requirements. Manchester OWL Syntax is developed by Manchester University for the purposes of presentation and editing. It is intended to serve a wide range of users, who do not have background in Description Logics, to take advantage of the expressive power provided by the logics. Manchester Syntax doesn t require any logical symbols and even very few brackets and thus, much more verbose than any other OWL syntaxes (including RDF/XML syntax, OWL abstract syntax and so on ). Manchester Syntax uses English keywords to provide the same semantics. In the remainder of this section, we briefly introduce about the semantics and also provide some examples for illustrating the use of Manchester Syntax Manchester Syntax s semantics The syntax for class constructors is described in Figure 2.3 OWL Constructors SROIQ syntax Manchester Syntax intersectionof C D C AND D unionof C D C OR D complementof C NOT C oneof a b {a b} somevaluesfrom RC R SOME C allvaluesfrom RC R ONLY C mincardinality NR R MIN N cardinality N R R EXACTLY N maxcardinality NR R MAX N hasvalue R a R VALUE a Figure 2.3 Semantics of Manchester Syntax 12

22 Chapter 2 Background In Manchester Syntax, it is encouraged to minimize the use of brackets. Therefore, some precedence rules are enforced. The following list shows the operator precedence, operators are shown from highest precedence to lowest precedence: SOME, ALL, ONLYSOME, VALUE, MIN, MAX, EXACTLY, THAT NOT AND OR In the above list, the keywords THAT and ONLYSOME are the ones not shown in Figure 2.3. THAT is a special keyword which is used to avoid confusion and also make the statement more natural in cases many AND and OR are required. The following example illustrates this situation (adapted from [32]). Suppose that we need to write a class expression to describe a set of people who have at least one child that has only one son. The expression is as follow: Person AND haschild SOME (Person AND haschild ONLY Man AND haschild EXACTLY 1) Can be r ewritten use THAT as: Person THAT haschild SOME (Person THAT haschild ONLY Man AND haschild EXACTLY 1), which is closer to natural languages. In addition, ONLYSOME is used to simplify the syntax in cases the universal restriction is used together with the existence restriction on the same property and filter the same set of classes. An example below illustrates this situation: Suppose that we need to define a class to describe a set of people who only have sons and no daughter. The expression for the class is as follows: Person AND haschild ONLY Man AND haschild SOME Man This can be rewritten using ONLYSOME as: Person AND haschild ONLYSOME Man 13

23 Chapter 2 Background Using ONLYSOME does help simplify and shorten the statement Examples In this sub-section we provide some more examples for the use of Manchester Syntax. We again present the ones which are shown in Figure 2.2 to illustrate the comparisons between the Manchester Syntax and SROIQ syntax. SROIQ Syntax Person Male Father Mother Person Man {Charles} Mother haschild. Woman Woman haschild.person Manchester Syntax Person AND Male Father OR Mother Person AND NOT Man {Charles} Mother AND haschild ONLY NOT Woman Woman and haschild SOME Person Mother 3 haschild Mother and haschild MIN 3 Figure 2.4 Examples for the use of Manchester OWL Syntax 2.4 Inconsistencies, redundancies and overlaps Inconsistency, redundancy and overlap issues have been mentioned in some of the previous parts in this thesis. In this section, we explain them with more details in a formal way. Definition 1: Inconsistency refers to the situation in which there are two or more assertions that cannot concurrently exist without scarifying (either removing or modifying) at least one of them. Inconsistency can be formally defined with the condition: where,,, are assertions in a Knowledge Base. In Description Logics SROIQ, inconsistency can be explained as a situation in which a concept or an object cannot exist. Accordingly, in OWL languages, inconsistency is the situation when there is a class that is unsatisfiable (there is surely no individual of that class) or when an individual, which is already defined in the knowledge base, cannot exist. 14

24 Chapter 2 Background An example of inconsistency in the form of Description Logics SROIQ is illustrated in the following example. Example 1: Suppose that there are 4 assertions :, :, : and :. These 4 assertions form an inconsistency because the concept cannot exist. From the definition of inconsistency, we define the minimal set of inconsistent assertions (we will refer to it as minimal set of inconsistency for simplicity) as follows Definition 2: A minimal set of inconsistency is a set in which the assertions are inconsistent and the inconsistency can be solved by removing any one of the assertions. The concept of minimal set of inconsistency can be formally defined as follows: Given a set of inconsistent assertions,,,. It is a minimal set of inconsisten cy if and only if the following conditions hold: For any i: (, from 1 to ) Definition 3: Redundancy is defined as the situation in which there is an assertion that is not necessary to be explicitly stated because it can be inferred from other existing assertions in the knowledge base. In Description Logics SROIQ and OWL language, redundancy can be explained as a situation in which an inclusion assertion between two concepts (classes in OWL language) or between an object (individual in OWL language) and a concept is redundant. An example of redundancy in the form of Description Logics SROIQ is illustrated in the following example. Example 2: Suppose that there are 4 assertions :, :, : and :. We can find that the assertion is redundant because it can be inferred from, and. 15

25 Chapter 2 Background Definition 4: Overlap is defined as a situation in which there are two or more assertions refer to some common or inter-related phenomena. Overlap and inconsistency are considered two level of interference between specifications; the first is the pre-requisite for the second [39]. In Description Logics SROIQ and OWL language, an overlap can be explained as a situation in which there are at least two assertions that constraint the same concepts (classes in OWL language) or objects (individuals in OWL language). An example of overlap in the form of Description Logics SROIQ is illustrated in the following example. Example 3: Two assertions : and : form an overlaps because they specify interfered constraints on the concept. The overlap could lead to an inconsistency if the concepts and are disjointed. In Requirements Engineering, the above definitions also apply. Examples of inconsistencies, redundancies and overlaps in the context of Requirements Engineering will be given in the next chapter. 2.5 Pellet Reasoner Pellet [14] is the first sound and complete OWL-DL reasoner with extensive support for reasoning with individuals (including nominal support and conjunctive query), user-defined data types, and debugging support for ontologies. Pellet currently supports almost all of the syntaxes available for OWL and is acceptable to very good performance [14]. In our research, Pellet is extended to provide reasoning services for supporting the identification of inconsistencies, redundancies and overlaps among requirements. 2.6 Related Works Much research has been done on the topic of detecting inconsistencies in Requirements Engineering. In this section, we choose to review the two most popular and also most influencing approach in the field: KAOS and Win-Win Project. KAOS framework [36] is developed based on the Goal-oriented Requirements Engineering approach. The framework provides methods for allowing engineers to 16

26 Chapter 2 Background formalize goal operators (achieve, maintain, avoid) using linear temporal logic (LTL) and many important goal concepts using conceptual graphs (CG). In the goal refinement process, the LTL representations formalize inquiries about when goals are satisfied whereas the CGs formalize inquires about why and how goals are satisfied. In KAOS, the goal refinement process ends at the goals that can be assigned to an individual agent, which can be a human being or an automated component of the system. This kind of goals is considered as requirements which are under the responsibilities of agents [26]. The problem with this framework is that, the semiformal natural language representation of goals in KAOS results in several ambiguities during the refinement process [x46]. In addition, it requires users to have an expertise in linear temporal logic which is also too complex to be used effectively in RE process and for communication between requirements engineers and stakeholders. In the Win-Win project [10][11], Boehm focused on the negotiation approach of solving requirements conflicts based on a knowledge base of potential conflicts. The meaning of Win-Win is that at the end of the negotiation, the satisfaction of every stakeholder will be improved with the outcome. Win-Win system allows stakeholders to negotiate the requirements of their systems and is primarily based on four artifact types: Win Conditions, Issues, Options, and Agreements. Win Conditions capture the stakeholders goals and concerns with respect to a new system. If a Win Condition is non-controversial, it is covered by an Agreement. Otherwise, an issue artifact is created to record the resulting conflict among Win Conditions. Options allow stakeholders to suggest alternative solutions, which address issues. The drawback of this approach is that, Win-Win needs all potential conflicts to be registered in a knowledge base (KB) that must be kept up-to-date. Maintaining such a KB is not a trivial task as it becomes more and more error-prone and tedious when the number of quality attributes and relationships amongst them increase. Furthermore, registered conflicting relationships must be checked periodically because conflicts may change as time goes by. Last but not least, in Win-Win it is not easy to track the rationale behind requirements and also tracing for the source of conflicts is not a trivial task. In this research, we attempted to solve the discussed problems in both frameworks. We used Goal-oriented Requirements Engineering approach for the goals and requirements elaboration process. The modeling of goals would also be supported by 17

27 Chapter 2 Background using goal graphs and more importantly, Manchester OWL Syntax is used for the formulation of goals to overcome the complexity with Linear Temporal Logics. 2.7 Summary In this chapter, we have presented the background to the thesis. Firstly, Requirements Engineering s concepts are discussed, followed by the disadvantages of the traditional Requirements Engineering approaches, which lead to the introduction of Goaloriented Requirements Engineering model. We also discussed about the SROIQ Description Logics, with the examples of its usage. We then presented the Manchester OWL Syntax and discussed its advantages over SROIQ DL syntax with respect to presentation and simplicity. Thirdly, we provided the formal definitions of inconsistency, redundancy and overlap, accompanied with examples. The Pellet reasoner for OWL-DL was also introduced in this chapter. In the last section, we reviewed the most popular related works, KAOS and Win-Win, discussed the drawbacks of the frameworks and pointed out our approach of solving the problems. 18

28 Chapter 3 A Motivating Scenario 3. A motivating Scenario This chapter presents a motivating scenario for our work as a basic for illustrations. The scenario is about a Social Networking System project, made up based on the investigations on various popular Social Networking Packages in the industry. They include Microsoft SharePoint [34], Elgg [17] and Mahara [31]. We start the chapter with the brief introduction about the project objectives, we then provide the requirement specifications of the project in the form of the requirement specification template proposed in [37]. We will also provide an analysis on the inconsistent, redundant and overlapped issues of the requirements. The chapter ends with the discussions on the limitations of the current approach and points out the limitations and disadvantages of the traditional approach of specifying and documenting requirements as well as the need for a formal mechanism for dealing with such problems. 3.1 The Business Objectives MIT is a diversified management consulting company that assists governments and large organizations to investigate issues and opportunities in a wide range of fields. It has 10 offices located in 4 Asia-Pacific region countries including China, Indonesia, Thailand and Vietnam, with between 30 and 50 consultants in each one. Due to the nature of work, the consultants too often work as individuals. They tend to be out working on client sites, and often do not really get to know other consultants working in the same MGBI office very well, let alone those working in other cities or countries. Not knowing each other very well, they don t draw on each other s expertise in informal casual interaction. Regarding this problem, the CIO of the company thinks close informal interaction is a feature of an effective team, and can often be an important contributor to success. He wants the consultants to know each other better, to be able to informally draw on each other s expertise, to share more about themselves with each other, and through this to become a more effective team. He thinks that some forms of social networking application could greatly help with this and so, a project is launched with the main objective of connecting staff for social activities and based on that, expertise sharing 19

29 Chapter 3 A Motivating Scenario and work collaboration would be established. In addition, the project should also concern with the cost, usability and security. The objectives of the project can be summarized as follows: To encourage social connections and work collaborations among staff with a cheap, usable and secure system. 3.2 System Requirements The requirements of the system is documented as follows, according to the proposed documentation template proposed in [37]. For simplicity, we only present the requirements and omit other parts, including background, assumptions, project scope which have little relevance to the purpose of illustrating requirements in this chapter. In addition, only selected parts of the system requirements are included due to space limitation Functional Requirements a. Personal Webpages The system being developed needs to allow users with the capacity of creating their own customizable homepages. Users are able to upload and view photos, videos, update statuses and compose notes on their homepages. Users are able to search and add or remove friends. Users are able to make posts on their friends homepage, photos, videos and notes. The system needs to support settings for languages, visibilities and system notifications. Users able to upload profile pictures for their homepage. Profile pictures must not exceed 6Mb in size. b. Group pages Group creation is allowed in the system. Group visibility settings are allowed. Group can be public or private, which means a group can only be seen and accessed by it members. File (including multimedia and documents) sharing is supported between members of a group. 20

30 Chapter 3 A Motivating Scenario The shared files visibility settings are allowed c. Event creation Users are able to create events in the system Users are able to invite (send invitations to) their friends to created events. Users are allowed to edit/modify details of the events they create. d. Multimedia and documents The system needs to support different types of multimedia, including photos, videos, audio and documents in popular file formats. Photos o The maximum size allowed for photos is 4Mb. o The supported formats are.jpg,.pgn,.jpeg and.gif. o Image format conversion is supported in cases when the uploaded image is not in one of the valid formats. o Album creation is supported. o Batch uploading is supported. Videos o Videos must not exceed 100Mb in size and 10 min in length. o Formats include:.wma,.3gp,.avi and.mpeg. o Only single upload is allowed. Audios o Audio files must not exceed 10Mb in size. o Audio files must be in one of the following formats:.mp3,.m4p and.wav o Only single upload is allowed. Documents o Documents must be in the following formats:.doc,.docx,.pdf,.ppt and.pptx o Documents must not exceed 10Mb in size. o Only single upload is allowed. e. Communications Communications is allowed between users. Languages 21

31 Chapter 3 A Motivating Scenario o The system needs to support all (and only) languages used in the organization s branches (including Indonesian, Thai, Vietnamese and Chinese). o If multiple languages are supported, the system also allows language translation capacity Private communication o The system needs to support asynchronous messaging between users (sending private messages) o Instant messaging between users is supported if the cost is not considerable. Group communications o Asynchronous messaging (broadcasting messages to multiple users) is allowed. o The system needs to support group videoconferences OR voice conference OR group instant chatting. f. Expertise sharing The system needs to support discussion boards for places for users to create and discuss on their interest topics Personal blogs OR wiki need to be supported by the system Non functional Requirements a. Cheap system Support English only Minimize operating cost o System shouldn t send the same information to a single users via both and SMS. Minimize development cost b. Usable system System should support an easy signup process o Users can signup with Facebook, Twitter OR Google account o Users can also have the option of creating local accounts with the system. System needs to support language conversion. System should support simple messaging interfaces 22

32 Chapter 3 A Motivating Scenario System needs to allow an easy password recovery process c. Secure system Users privacy must be protected An account must be locked after a specified number of continuous failed login attempts. o After three continuous failed login attempts, the account would be locked by the system o Once an account is locked, the system sends an account lock notification to the account s owner. o Once an account is locked, the system would also send a SMS message to the account s owner to notify him/her about the situation. 3.3 Requirements Analysis An analysis has been done on this set of requirements for the inconsistent, redundant and overlap problems, which are detailed as follows: Inconsistencies English is not supported according to the communications requirements specified in 1.e. However, English is claimed as the only language support by the system according to the cheap system non-functional requirement. In secure system non-functional requirements, it is specified that once an account is locked due to exceeding number of failed login attempts, the account lock notification would be sent to the account s owner via both SMS message and . However, as part of the cheap system requirement, that should be avoid because sending the same information to a users twice is considered a waste Redundancies The requirement system needs to support language conversion in the usable system non-functional requirement is redundant (not necessary to be explicitly stated) because it can be inferred from other two requirements in the communication functional requirements: system needs to support all (and only) languages used in all organization s branches and if multiple languages are supported, language conversion would be also supported in the system. 23

33 Chapter 3 A Motivating Scenario The requirement profile pictures must not exceed 6Mb in size in the homepage functional requirement is redundant because it can be inferred from the requirement photo must not exceed 4Mb in size in the multimedia and documents functional requirements and the fact that profile pictures are also photos Overlaps The requirements regarding profile pictures and photos mentioned above are also considered overlapped requirements as they specify constrains on the same set of objects. 3.4 Issues with the current approach The approach demonstrated in the previous section successfully serves the purpose of specifying and documenting requirements. However, there are some issues with the approach with respect to requirements rationale and analysis. Firstly, it is not feasible for tracking the rationale behind requirements as they are specified and grouped based on functionalities and similarities other than underlining goals. Consequently, the requirement document may not reveal sufficiently the goals and objectives of the system being developed. This could lead to serious problems during the Requirements Engineering process as the project goals and objectives could be lost or ignored during the communications among requirements engineers, system developers and stakeholders. Secondly, as requirements underlining rationales are unclear to requirements engineers, it is likely that the insufficiency of requirements couldn t be detected, which results in incomplete functionalities of the system. Similarly, irrelevant requirements may not be identified during the RE process. In addition, the natural language representation of requirements is ambiguous and easily lead to misunderstanding. Furthermore, the relationships between concepts are not defined. For instance, it is not clear about the relationships between photos and profile pictures, are all profile pictures are photos, or some types of profiles pictures are photos and others are not. This sometimes creates ambiguity and makes it hard for requirements engineers to understand, analyze and reason about requirements. 24

34 Chapter 3 A Motivating Scenario Lastly, the current approach is not able to provide mechanism for identifying problems (inconsistencies, redundancies and overlaps) automatically. The problems could only be detected manually by requirements engineers. However, that doesn t guarantee the efficiency, effectiveness and sufficiency of the process. The above discussion has shown the limitations of the traditional approach of RE. In our research, the use of Goal-oriented Requirements Engineering helps overcoming the problems with the lack of requirements rationales. In addition, the Manchester OWL Syntax and Pellet are the solution to the automation of inconsistencies, redundancies and overlaps identification process. 3.5 Summary In this chapter, we have presented a motivating scenario for our research. We have covered the business objectives of the Social Networking System project, followed by parts of its functional and non-functional requirements. We also discussed about the analysis of the requirements together with the limitations of the traditional approach of RE and pointed out the solutions to those limitations. This scenario will be used throughout thesis to demonstrate our work. 25

35 Chapter 4 Requirements Engineering Process Model 4. Requirements Engineering Process Model In this chapter, we present the Requirements Engineering Process model which is based on the Goal-oriented Requirements Engineering approach. The model supports the process of elaborating, managing, analyzing goals, refining from high-level goals to lower-level goals. In this chapter, we firstly provide an overview of the model. We then present the language used for formalizing requirements, accompanied with examples. We will also describe the goal refinement links and annotations, which are the main two elements of the goal model. In the last section of the chapter, we illustrate the use of the model with the application into the scenario discussed in chapter Model Overview The Requirements Engineering Process model in our work is adapted from the one used in KAOS. In our model, the focus is on the refinements, formalization and analysis of goals. Therefore, in comparison to KAOS, it does not support the definition of agents and responsibility assignments. The model is derived from the central roles played by goals during the requirements Engineering process. It supports the capturing of and showing how system s functional and non-functional requirements contribute to each other through different types of refinement links. In addition, the model allows the identification of requirements problems, including inconsistencies, redundancies and overlaps, which are early forms of RE analysis. In the model, goals and requirements are used interchangeably as they both refer to stakeholders expectations on the system being developed. Formal specifications are provided to low-level goals for further analysis and reasoning (for inconsistencies, redundancies and overlaps detection). High-level goals are generally not formalized for two reasons. Firstly, formalizations of high-level goals often do not convey a lot of meanings as they are usually too abstract and general. Secondly, high-level goals are difficult and unnecessary to be analyzed, also due to their abstraction and generalization. Graphically, the goal model is represented by an AND/OR graph called a goal graph. In the goal graph, each individual goal is represented as a node, which is annotated 26

36 Chapter 4 Requirements Engineering Process Model according to the goal s feature, and is connected to other goals on the same graph via various types of edge. Each edge represents a refinement link. A refinement link not only indicates how a goal is decomposed into other sub-goals, which means how a goal is realized in the system, but also reveals the parent goal where it comes from, which shows the rationale behind the goal. 4.2 Requirements Specification Language In this section, we explain the use of Manchester OWL Syntax in formalizing goals (or requirements) in the model. Closely based on Manchester OWL Syntax, the requirement specification language in our work has the following advantages. Firstly, it is user-friendly and allows practitioners to use it without special expertise. Secondly, it is close to natural language; therefore, it can be easily understood by humans. In addition, it can also be understood and processed by the Pellet reasoner, which is used to provide reasoning and analysis services in the model. The semantics and syntax of the specification language are the same as of Manchester Syntax except for the fact that it borrows the OWL language constructor SubClassOf, which is named specifier in this language, to achieve more expressive power in requirement representation. A requirement is usually represented one or more sentences, each consists of two expressions connected with each other by the specifier. The expression on the righthand side generally denotes the expectation, or constraints on the concepts or individuals represented in the expression on the left-hand side of the specifier. The following examples illustrate the use of this language. Example 4.1: The requirement The system needs to support English only is formalized as: System SubClassOf supportlanguage VALUE English. Example 4.2: The requirement Photos must not exceed 4Mb in size is formalized as: Photo SubClassOf hassizeinmb MAX 4. 27

37 Chapter 4 Requirements Engineering Process Model Example 4.3: the requirement Once an account is locked, the system would send an account locked notification message to the user s is formalized as: User AND hasaccount SOME LockedAccount SubClassOf User AND received SOME locknotificationmessage. 4.3 Goal Refinement Process The goal refinement process is conducted in both top-down and bottom-up directions. One the one hand, requirements engineers start with high-level goals. They need to answer the HOW questions (i.e. How is his goal satisfied?) to refine the goal into subgoals. The sub-goals would be the conditions for satisfying the higher-level goal. On the other hand, requirements engineers need to verify the correctness and appropriateness of the refinements by asking themselves the WHY questions (i.e. Why does this goal exist?). This sort of questions help them verifying if the existence of the goal is necessary to be stated (does it really help satisfying the higher-level goal?) or if there is any more goals needed. This bi-directed approach ensures the completion and also avoids redundancy in the goal refinement process. In our model, the refinement process is assisted by the used of a goal graph, which is also referred to as a refinement graph. The goal graph visualizes how high-level goals are refined into lower-level goals, or in other words, how low-level goals contribute to the realization of higher-level goals. For a particular goal, it can be refined into multiple sub-goals via different types of refinement links. These links include AND-links, OR-links and Optional-links. Each of these link types is described as follows AND Link In the model, AND-Links are used in cases of minimal refinement, which means the goal can only be satisfied if and only if all of the sub-goals linked to it via AND-Links are satisfied. In other words, if there is any of the sub-goals is unsatisfied, the goal will never be fulfilled. 28

38 Chapter 4 Requirements Engineering Process Model An example of AND-Link is illustrated in Figure 4.1: Figure 4.1 An example of AND-Links In this example, the goal Support Photo Upload is refined into 4 sub-goals, all with AND-Links. That means the satisfaction of that goal can only be achieved if all the 4 sub-goals are fulfilled OR Link OR-Links are used in cases of alternative refinement, which means the goal being refined can be satisfied by fulfilling any of the sub-goals involved in the OR-Links. Conversely, satisfying any of the sub-goals would fulfill the goal. In the model, whenever OR-Links is needed, it is a must to create a virtual goal for linking the goal with its alternative refinements. The virtual goal is connected to the goal via OR-Link and to the sub-goals via AND-Links. 29

39 Chapter 4 Requirements Engineering Process Model Figure 4.2 illustrates an example of OR-Link Figure 4.2 An example of OR-Links In this example, OR-Links is used to allow the specification of three alternatives of supporting group communication (any one of the three options plus the goal Support asynchronous group messaging will sufficiently satisfy the goal Support group communication ). The yellow circle denote a virtual goal, which is created only for the purpose of linking alternative options to the top goal via OR-Links Optional Link In the model, Optional-Links are used in cases of optional refinement, which means the sub-goals involved in Optional-Links are nice-to-have. They do contribute to the realization of the goal being refined. However, without such sub-goals, the goal can still be satisfied. In the goal graph, Optional-Links can be used to connect functional goals or non-functional goals to any other goals. However it can t be used to connect virtual goals to any other goals. 30

40 Chapter 4 Requirements Engineering Process Model Figure 4.3 present an example of the use of Optional-Link: Figure 4.3 An example of Optional-Links This example shows a case of refining the goal Support private communications. According to the refinement, that goal can be achieved by supporting asynchronous private messaging between users in the system. However, it would be nicer to allow instant messaging services. This feature is considered nice-to-have and so its existence does not affect the satisfaction of the goal. 4.4 Goal Annotations In the model, each goal is annotated by a number of features that characterize the goal individually. In this section, we describe the elements of annotation for each individual goal. The list of elements is as follows: Name: The name element must uniquely identify the goal in the goal model. Each name contains 2 parts, separated by a _. The first part of the name denotes the goal type and its order compare to other goals (i.e. F12 denotes the 12 th functional goal defined in the model while N10 denotes the 10 th nonfunctional goal). The second part is the short (but meaningful) form of its description; briefly define what the goal is about. For instance, F12_SysSupEnglishOnly is the name of a requirement specifying that the system needs to support English only. Exceptions are for the case of virtual 31

41 Chapter 4 Requirements Engineering Process Model goals, which are only used in situations when alternative refinements are needed. In this case, the first part contains a V followed by an order number and the second part is the number part of its parent goal s name (i.e. V2_F12). The order number is automatically generated in the system which supports the model (will be described in chapter 7). Value: each goal is associated to one or more values. A value represents the perspective, or the top most objective, which derives the goal. For instance, the requirement The system needs to support English only has the value of cheap, which means the purpose for the fact that the system only supports English is to save development costs. GoalType: each goal has a type, which is functional or non-functional or virtual (which is used in case an OR refinement link is used). Refines: This element is associated with the higher-level goal that this goal refines. In order words, this element refers to the parent goal of this goal. Unless this is the top most goal, which doesn t refine any goal, this element indicates one and only one goal. RefinementType: This element indicates the type of the refinement link from this goal s parent to itself (this is empty if this goal is the top most one). According to the previous section, the refinement type can be AND, OR or Optional. RefinedTo: This element indicates the list of goals which are generated as the results of the refinement on this goal (which are considered children goals). InformalDef: This element defines what the goal is about in natural language. For instance, The system needs to support English only. FormalDef: This element defines the goal in a formal specification language. In this case, it is in the form of the language described in section 4.2 above. For instance, the formal definition of the goal F12_SystemSupEnglishOnly is: System SubClassOf supportlanguage VALUE English. 32

42 Chapter 4 Requirements Engineering Process Model Figure 4.4 below illustrates an example of how a goal annotations. Name Value GoalType Refines Refinement Link RefinedTo InformalDef FormalDef F9_SysSupPrivateComm Collaboration, Social Activity Functional F8_SysSupComm AND F10_SysSupAsynMessaging, F11_SysSupInstantMessaging, F12_SysSupVoiceCall System needs to support private communication System SubClassOf supportcommunication SOME PrivateCommunication Figure 4.4 Example of goal annotations The described goal specifies that the system needs to support private communications between users. It comes from the refinement of the higher-level goal, which requires the system to allow ways of communications (Refines). The goal is derived from the objective of encouraging social activities as well as work collaborations among users (Value). It is refined into 3 other sub-goals, which are F10_SysSupAsynMessaging, F11_SysSupInstantMessaging and F12_SysSupVoiceCall. 4.5 Applications of the Model In this section, we present an example of the application of the proposed Requirements Engineering Process model into a real world project. We continue with the scenario described in chapter 3. However, the requirements would be specified in a different way. We apply the model by starting with the top most objective (top goal) and refining the top goal into different sub-goals. The refinement would then be continued at those sub-goals and so on. In the first part of this section, we present parts of the refinement graph generated for the scenario (the complete refinement graph can be found in appendix 1). In the second part, we will also provide some example for the formalization of goals generated from the refinement graph. 33

43 Chapter 4 Requirements Engineering Process Model Refinement Graph 34

44 Chapter 4 Requirements Engineering Process Model 35

45 Chapter 4 Requirements Engineering Process Model 36

46 Chapter 4 Requirements Engineering Process Model 37

47 Chapter 4 Requirements Engineering Process Model Figure 4.5 Refinement Graph 38

48 Chapter 4 Requirements Engineering Process Model Goal Formalization In this section, we present some example for the formalization of goals in the refinement graph. We choose to show the formalization of the goals involved in the refinement of Support Photo Upload. Name Value GoalType Refines Refinement Link RefinedTo InformalDef FormalDef F43_SysSupPhotoUpload Collaboration, Social Activity Functional F41_SysSupFileUpload AND F44_PhotoMax4Mb, F45_PhotoFormatList, F46_PhotoFormatConversion, F47_PhotoBatchUpload System needs to allow photo uploaded System SubClassOf supportfeature SOME Upload AND hasobject SOME Photo Figure 4.6 Formalization of Supporting Photo Upload goal Name Value GoalType Refines Refinement Link F44_PhotoMax4Mb Collaboration, Social Activity Functional F43_SysSupPhotoUpload AND RefinedTo InformalDef Photos must not exceed 4Mb in size FormalDef Photo SubClassOf hassizeinmb MAX 4 Figure 4.7 Formalization of Photo Size goal 39

49 Chapter 4 Requirements Engineering Process Model Name Value GoalType Refines F45_PhotoFormatList Collaboration, Social Activity Functional F43_SysSupPhotoUpload Refinement Link AND RefinedTo InformalDef FormalDef Photos must be in the following formats in order to be uploaded:.jpg,.pgn,.jpeg and.gif Photo SubClassOf hasformat ONLY {JPG, PNG, JPEG, GIF} Figure 4.8 Formalization of Photo Format List goal Name Value GoalType Refines Refinement Link F46_PhotoFormatConversion Collaboration, Social Activity Functional F43_SysSupPhotoUpload AND RefinedTo InformalDef FormalDef System needs to support photo format conversion for photos that are not in valid formats System SubClassOf supportconversion SOME PhotoFormat Figure 4.9 Formalization of Photo Format Conversion goal 40

50 Chapter 4 Requirements Engineering Process Model Name Value GoalType Refines F47_PhotoBatchUpload Collaboration, Social Activity Functional F43_SysSupPhotoUpload Refinement Link AND RefinedTo InformalDef FormalDef Photos can be uploaded in batch mode System SubClassOf supportuploadmode SOME BatchMode AND hasobject SOME Photo Figure 4.10 Formalization of Supporting Batch Mode Upload goal 4.6 Summary In this chapter, we have presented out proposed Requirements Engineering Process Model, which is largely based on the Goal oriented Requirements Engineering approach. We have discussed on the language used for formalizing requirements, refinement links and goal annotations. We have also provided an example for the application of the model into a scenario which has been described in chapter 3. 41

51 Chapter 5 Analysis and Reasoning Services 5. Analysis and Reasoning Services As mentioned earlier in previous chapter, the proposed Requirements Engineering Process model support the analysis and reasoning services for identifying inconsistencies, redundancies and overlaps among selected requirements. In this chapter, we describe the services in details. We firstly discuss about the OWL files and the reasons why we need them in our model. We then present the mechanism for detecting inconsistencies, redundancies and overlaps (we will use requirement problems as a general term for these in this chapter). The chapter ends with the description on ontology generation. 5.1 OWL Files The analysis and reasoning services in our work are largely based on the pellet reasoner, which requires OWL language inputs for operation. In OWL language, an ontology is referred to as a collection of the definitions of a number of classes, roles, individuals and their relationships. As discussed earlier, in the proposed model we use Manchester OWL Syntax, a user-friendly syntax of OWL language for formalizing requirements. Each requirement s representation is made up from classes, individuals and roles. Therefore, in order for analysis and reasoning can be performed on the defined requirements, an ontology is needed to hold the definition and relationships of the classes, roles and individuals used in those requirements formalization. In the current version of the proposed model, we need a separate OWL file to perform the identification of requirement problems for two reasons. Firstly, it is required as an input to Pellet reasoner. Secondly, requirements formalization, although represented in Manchester OWL Syntax, only contains the relevant facts which are necessary to describe the requirements sufficiently. The formal representations of requirements may not provide the definitions of and relationships among classes, roles and individuals. For instance, the representation of the requirement Photo must not exceed 4 Mb in size is Photo SubClassOf hassizeinmb MAX 4 does not define what the Photo class is, what individual it contains, what classes it is disjointed from, or what the hassizeinmb role is and what classes it can be used with and so on. In other words, the requirement s representation is created based on the assumptions that the relevant classes, roles and individuals have been (or will be) defined some where in the system, separately. 42

52 Chapter 5 Analysis and Reasoning Services Ideally, the OWL file should be created automatically from the formalization of requirements. However, due to time limitation, this automation process has not been completed in our work. We instead create the OWL file concurrently with the formalization of requirements with the help of Protégé OWL editor. Figure 5.1 illustrates an example of how Photo class is defined in an OWL file (with Manchester Syntax). The complete example of an OWL file can be found in the appendix 2. Class: < 3.owl#Photo> SubClassOf: Annotations: rdfs:isdefinedby "F23_PhotoMax3Mb" < 3.owl#hasSizeInMb> max 3 rdfs:literal, < 3.owl#hasFormat> value < 3.owl#JPG>, < 3.owl#hasFormat> only ({< 493.owl#JPG>, < 3.owl#PNG>}) Figure 5.1 Photo class s definition in an OWL file 43

53 Chapter 5 Analysis and Reasoning Services 5.2 Inconsistency Detection The created OWL file is input into the Pellet reasoner, promoting the analysis and reasoning services in the model. In this section, we present the mechanism for identifying inconsistencies among requirements. Inconsistencies are detected based on their definition, which is either the situation when a class is found unsatisfiable or an individual that cannot exist. Every inconsistency detected is accompanied with the explanation of the problem. The inconsistency detection is part of Pellet reasoner s features, which guarantees the minimum set of inconsistency to be detected always. The algorithm is presented in Figure 5.2. function CHECK-INCONSISTENCIES (ontology) returns problem-explanation pairs problemexpl an empty set of problem-explanation pairs if!pellet.isconsistent then GET-EXPLANATIONS(Pellet.getInconsistencyExplanations, end if problemexpl) unsatisfiableclasses loop do Pellet.getEquivalentClasses(NOTHING) if!hasnext?(unsatisfiableclasses) then exit class NEXT(unsatisfiableClass) GET-EXPLANATIONS( Pellet.getUnsatisfiableExplanations(class), problemexpl) return problemexpl 44

54 Chapter 5 Analysis and Reasoning Services function GET-EXPLANATIONS (explanations, problemexpl) loop do if!hasnext?(explanations) then return explanationaxiom NEXT(explanations) problemexpl.add(get-requirements(explanationaxiom), explanationaxiom) end loop Figure 5.2 Algorithm for inconsistency detection In Figure 5.2, functions with Pellet. prefix are the ones supported by Pellet reasoner. 5.3 Redundancy Detection Another service supported by the proposed model is redundancy detection. Basically, the identification of redundancies is performed by checking if an inclusive relationship is redundant. In other words, the redundancy checker would detect the cases when a set of axioms (which define relationships) which, in collaboration, infers an inclusive relationship which is defined by another axiom in the ontology. The redundancy detection is not directly supported by Pellet. We provide the identification service for this type of problem by taking advantage of the subsumption reasoning built-in function of Pellet. The algorithm for detecting redundancies is illustrated in Figure

55 Chapter 5 Analysis and Reasoning Services function CHECK-REDUNDANCIES (ontology) returns problemexplanation pairs problemexpl an empty set of problem-explanation pairs allclasses Pellet.getClasses /*get all classes in the ontology for processing */ loop do if!hasnext?(allclasses) then exit class NEXT(allClasses) superclasses GET-PRE-REASONING- SUPERCLASSES(class) loop do if!hasnext?(superclasses) then exit asuperclass NEXT(superClasses) allsuperclasses GET-ALL-SUPER- CLASSES(aSuperClass) loop do if!hasnext?(allsuperclasses) then exit anothersuperclass NEXT(allSuperClasses) then if superclasses.contains(anothersuperclass) GET-REDUNDANCY- EXPLANATIONS(Pellet.getSubClassExplanation(class, superclass), Pellet.getSubClassExplanation(class, anothersuperclass), Pellet.getSubClassExplanation(superClass, anothersuperclass), problemexpl) end loop end loop end loop return problemexpl Figure 5.3 Algorithm for detecting redundancies 46

56 Chapter 5 Analysis and Reasoning Services 5.4 Overlap Detection In the proposed model, the overlap detection process is complete, but not sound. Which means all overlaps in a provided ontology could be identified but not all results found are overlaps. In the model, overlaps are identified based on the analysis on the subsumption relationships between classes. Basically, two or more requirements are detected as an overlap if they are represented by two or more axioms which defines the subsumption relationships on intersected classes (classes having individuals in common or classes in which a class is a sub-class of another). Specifically speaking, if there are at least two class, denoted as A and B, which have something in common (the common is explicitly defined in the ontology), any requirements which are represented by subsumption relationships between A, B and other classes (in which A and B are subclasses of those classes), i.e. A SubClassOf C and B SubClassOf D, would be considered overlapped. This process is not sound because the requirements that are detected as overlaps are not actually overlaps. In the example above, assuming that C and D are not relevant with each other, then there shouldn t be any overlap detected. Ideally the model should be able to detect this irrelevance. However that turns out to be not possible because in Pellet only Open World Assumptions are supported, which means if there is no axiom specifying the irrelevance between C and D, then they are considered relevant. Therefore, the results of the identification process may contain nonoverlapped requirement set. Figure 5.4 illustrates the algorithm for detecting overlaps in the proposed model. 47

57 Chapter 5 Analysis and Reasoning Services function CHECK-OVERLAPS (ontology) returns problemexplanation pairs problemexpl an empty set of problem-explanation pairs checkedpairs an empty set to hold pairs of classes which are checked for redundancies allclasses Pellet.getClasses /*get all classes in the ontology for processing */ loop do if!hasnext?(allclasses) then exit class NEXT(allClasses) loop do if!hasnext?(allclasses) then exit anotherclass NEXT(allClasses) if isintersected?(class, anotherclass) then then if HasOverlappedReqs?(class anotherclass) GET-OVERLAP-EXPLANATIONS(class, anotherclass, problemexpl) end loop end loop return problemexpl Figure 5.4 Algorithm for detecting overlaps 5.5 Requirements Query When a set of requirements is detected with problems, which can be inconsistency, redundancy or overlap, it is sometimes necessary for requirements engineers to take a closer look to get more insights into the requirements, understand the problems and probably try to resolve them (inconsistencies are the main concerns in these cases because redundancies could be easily resolved and overlaps are only low-level warnings and do not need to be resolved). In addition, requirements engineers may only be interested in a partial set of requirements rather than the requirements for the 48

58 Chapter 5 Analysis and Reasoning Services entire system, i.e. they only need to study the requirements relevant to the communication features in a Social Networking System. To address these needs, the proposed model allows requirements engineers to query particular sets of requirements and for the specific types of problems they are interested in. In order to achieve this, a new ontology (rather than the ontology for the entire requirement set) would be created based on the selected requirements. The detection of specific problems of interest (inconsistency, redundancy or overlap) would be conducted on this ontology to produce the query results. 5.6 Problem Detection Results In this section, we demonstrate the results obtained by applying the model in identifying requirements problems in the scenario described in chapter 3. The results are generated by the REInDetector prototype tool. Figure 5.5 shows the case of detected inconsistency. In this case, two requirements, F10_SupAllBrLang which specifies that the system only supports all branch languages and F15_SysSupEngOn stating that the system only supports English are inconsistent because they refer to the conflicting issues. Figure 5.6 shows the case of redundancy. In this case, we have three involved requirements. F10_SupAllBrLang specifying the system supports all and only branch languages including Vietnamese, Thai and Indonesian, F11_SupLangTrans stating the system needs to support language translation and F12_IfMulLangThenTrans specifying that if the system supports multiple languages, it needs to support language translation. The tool has detected that the requirement F11_SupLangTrans is redundant because it doesn t need to be stated as it can be inferred by other two requirements. Figure 5.7 illustrates a case of overlap. In this case, there are two overlapping requirements which are F13_PhotoMax4, F15_ProPicMax5 because they specify constrains on intersecting concepts (photos and profile pictures). 49

59 Chapter 5 Analysis and Reasoning Services Figure 5.5 Inconsistency Case 50

60 Chapter 5 Analysis and Reasoning Services Figure 5.6 Redundancy Case 51

61 Chapter 5 Analysis and Reasoning Services Figure 5.7 Overlap Case 52

62 Chapter 5 Analysis and Reasoning Services 5.7 Summary In this chapter, we have presented the analysis and reasoning services provided by our proposed model in details. We have described the process of detecting inconsistencies, redundancies and overlaps in the model, based on the integration with Pellet reasoner. The process of overlap identification is complete but not sound because of the Open World Assumption in Pellet and OWL language. We also have discussed about the requirement query service, which allows requirements engineers to query partial set of requirements for problems types of interest. Finally, we have illustrated the results of applying the proposed model into the Social Networking System scenario described in chapter 3. 53

63 Chapter 6 Requirements Formalization Patterns 6. Requirements Formalization Patterns As discussed in previous chapters, in our work requirements need to be formalized using Manchester OWL Syntax (MOS) to promote automated requirement problems verification process (for identifying inconsistencies, redundancies and overlaps). Just as natural language, sometimes there is more than one way to specify a single requirement in MOS. The way in which a requirement is formalized could affect the outcomes of the verification process. Therefore, it is a need for a systematic way of specifying requirements in place to assist requirements engineers in requirements formalization to guarantee the correctness of the outcomes. In this chapter, we will present some important pre-defined requirement formalization patterns in our work. We firstly will discuss about the reasons why patterns are needed. We then present the patterns in the next section. 6.1 Why are patterns needed? In order to identify inconsistencies, redundancies and overlaps in our proposed model, requirements are formalized with Manchester OWL Syntax, and then processed by Pellet reasoner to produce outcomes. In addition, as other languages, including natural languages or logics, Manchester OWL Syntax allows different ways for specifying a single requirement. Furthermore, as described in chapter 5, the identification process is largely based on the definitions and uses of classes and class relationships in a defined ontology. Therefore, if a requirement is specified in a different way, different classes may be generated and so different ontologies may be created for the same set of requirements. This leads to the problem that the outcomes are different on the same set of requirements because the ontologies are different. We will take the case of redundancy in regards to photos and profile pictures sizes as an example. The requirement Photos must not exceed 4Mb in size is formalized as before, which is Photo SubClassOf hassizeinmb MAX 4 while the requirement Profile pictures must not exceed 5Mb in size is now specified with the meaning of The system must not have profile pictures which is over 5Mb in size as System SubClassOf hasprofilepicture ONLY ProfilePicture AND hassizeinmb MAX 5. The two meanings are equivalent, they lead to different results however because now there are no super class are defined for the Photo class and thus no redundancy (and only 54

64 Chapter 6 Requirements Formalization Patterns overlap!) are identified in this case according to the algorithms described in chapter 5. Note that, this problem does not come from the algorithms because it is not possible to develop algorithms to work on ontologies but ignore the classes and class relationships, which define those ontologies. It is because of the use of Manchester OWL Syntax an OWL syntax and the ways requirements are defined. Therefore, solving this problem would involve developing a systematic method for formalizing requirements in the model, which ensures the consistency of ontologies generated on a single set of requirements. The systematic method to formalize requirements is discussed in the next sections, in which we describe some formalization rules and then present the patterns. 6.2 Formalization Rules In this sub-section, we present the rules which govern the requirements formalization process. Rule 1: The System class must always be used for all requirements related to the system being developed. For instance, the requirement saying The system must support event creation is represented as System SubClassOf support EventCreation. The System keyword is used always, no TheSystem or ASystem. That guarantees the consistency among requirements specifications. Rule 2: When formalization a requirement, the class and subsumption relationship must be created (if the class hasn t been existing) based on the object of main concerns. For example, the requirement In the system, all photos must not exceed 4Mb in size is represented as Photo SubClassOf hassizeinmb MAX 4. The focus is on the Photo class, not the system even it is mentioned in the requirement because photos are the main concerns in this case. Rule 3: If there is more than one object of concern, the object which is the source of the situation is chosen for creating class and relationships. 55

65 Chapter 6 Requirements Formalization Patterns For instance, the requirement specifying after three failed login attempts, the account is locked. This can be interpreted in either after an three failed login attempts are recorded on an account, it will be locked or after a user made three failed login attempts, his account will be locked. The first interpretation is formalized as Account AND hasfailedlogins VALUE 3 SubClassOf LockedAccount. The second interpretation is represented as User AND hasfailedlogins VALUE 3 SubClassOf User AND has Account SOME LockedAccount. Both two expressions are reasonable, the second one is chosen however. That is because user is the source of the situation, not account, because the user is the object making login attempts. 6.3 Formalization pre defined Patterns OWL language-related specification patterns have been extensively studied in the literature. However most of the works are done on the patterns in web service verification process [28][29][30][40][41] (which is understandable as OWL language is for specifying web ontologies). Breaux et al. [38] have also developed requirement formalization patterns in Description Logics as part of the semantic parameterization process they proposed. Although a systematic formalization strategy has been developed, the patterns are still relatively simple and do not cover the cases when requirements contain relationships between different states or circumstances (i.e. If Then ). In this work, the patterns in [38] were extended to achieve better expressiveness and adapted to the Manchester OWL Syntax. The patterns are presented as follows Property Patterns The dictionary of property is very important to the specification of requirements. It is a need to ensure that one single relationship (or attribute) must have the same property in different requirements (i.e. the hassizeinmb property is chosen for defining the size of an object in Megabytes then it must also be used whenever a constraint on the same kind of attribute, size, needs to be specified). The dictionary can be created and maintained by user. It however must in the same formats as described bellows. 56

66 Chapter 6 Requirements Formalization Patterns The functionality support requirements (i.e. System needs to support Group creation, or System support event creation) are always in the format of System SubClassOf support + Feature where Feature is defined by users to denote the feature being supported by the system (it can be a class or an expression with class/property/individual combination). The attribute declaration requirements (i.e. Photos must not exceed 4Mb in size) is specified using property of the format: has + Attribute with Attribute is defined by users to denote the attribute of the object. Other properties are up to users to define Expression Patterns All requirements are specified in the format of Expression1 + SubClassOf + Expression2 (as shown in many examples before). An expression here can be a single class or a combination of classes and properties and/or individuals. This format solves the problem with Breaux patterns [38] as it allows the specification of If Then requirements. In such cases, the If statement is represented with Expression1 while Then statement is defined in Expression2. The patterns for each expression are defined as follows. The patterns and examples are adapted from [38]. Basic Expression Pattern This is the simplest expression pattern, which consists of a class and a single property connecting the class to another class, individual or value. The pattern and example are illustrated in Figure 6.1. Pattern ClassExp SubClassOf property + ConnectingWord + Class/individual/value (ConnectingWord is one of: SOME, ONLY, ONLYSOME, VALUE, MAX, MIN) Example 57

67 Chapter 6 Requirements Formalization Patterns Natural Expression 1. System needs to support English only. 2. Photos must not exceed 4Mb in size. Formal Expression 1. System SubClassOf support VALUE English 2. Photo SubClassOf hassizeinmb MAX 4 Figure 6.1 Basic Expression Pattern Expressions with References to Others This type of expressions is the most frequently used pattern in requirements formalization. It involves the reference to other expressions. The expressions of this type is recognized by studying the structure of the requirement being formalized. If the requirement requires a condition applied on a concept to specify another concept, then the requirement is of this type. The pattern is illustrated in Figure 6.2, accompanied with examples. Pattern ClassExp SubClassOf property + ConnectingWord + expression (expression can be in any pattern described in this section) Example Natural Expression Formal Expression 1. After a user have 3 failed login 1. User AND hasfailedlogins VALUE 3 attempts, his account will be locked. SubClassOf User AND hasaccount 2. Once a user s account is locked, his will receive a lock notification from the system. 3. Provider restricts sharing information with third parties. SOME LockedAccount 2. User AND hasaccount SOME LockedAccount SubClassOf User AND receive SOME LockNotification 3. Provider SubClassOf restrict SOME (Sharing AND (hascontent SOME Information) AND hastarget SOME 58

68 Chapter 6 Requirements Formalization Patterns ThirdParty) Figure 6.2 Referencing Expression Pattern Expressions with Purposes AND/OR instruments In some cases, in requirement specifies a constraint on an object (or multiple objects) and also include the purposes of that constraint (This rarely happens in Goal-oriented Requirements Engineering because the purposes are already specified in higher-level goals but this type of requirements exists sometimes, in case clearly stating the purposes would help minimize ambiguity, raise attentions from users or for other special reasons). In addition, an expression may contain the instrument, which is about the method for accomplishing actions specified in a requirement (purpose and instrument are referred to as the WHY and the HOW of the requirement). Figure 6.3 presents this pattern in case when both purpose and instrument are needed. One of them can be omit if not needed. Pattern ClassExp SubClassOf property + ConnectingWord + expression + AND + haspurpose + ConnectingWord + expression + AND + hasinstrument + ConnectingWord + expression (expression can be in any pattern described in this section) Example Natural Expression Formal Expression 1. The provider discloses information to 1. Provider SubClassOf disclose SOME market service to individuals. Information AND haspurpose SOME (Purpose AND (hasaction SOME Market) AND (hastarget SOME 2. The employee protects documents by encrypting them. Individual)) 2. Employee SubClassOf protect (SOME Document) AND hasinstrument SOME 59

69 Chapter 6 Requirements Formalization Patterns (Instrument AND hasaction SOME Encryption AND hastarget SOME Document) Figure 6.3 Purposes and/or Instrument Expression Pattern 6.4 Summary In this chapter, we have discussed about the need of requirements formalization patterns in the proposed model. We also have presented a set of rules, followed by different patterns for the formalization processimplementation of Prototype In this chapter, we will present the design and implementation of the REInDetector JAVA prototype tool. We start with the overview of the architecture behind the tool. We then discuss on each of its main components. 60

70 Chapter 7 Implementation of Prototype 7. Implementation of Prototype 7.1 Design The general architecture of REInDetector is illustrated in Figure 7.1. The program is built in integration with Pellet reasoner to provide analysis, reasoning and query services as described in chapter 6. In this implementation, Pellet can be seen as a black box and the interactions between Pellet and the main program are performed through an interface, which is built in the package Reasoner showed in the figure. In order words, the Reasoner is responsible as a bridge between the main program and Pellet. In addition, Reasoner package is the one which responses to all analysis and reasoning requests in the program. The Main Program is concerned about defining and editing requirements based on the Goal-oriented Requirements Engineering approach. It provides all the interfaces for users to interact with the tool, sends query requests to and receives results from the Reasoner and provides feedbacks to users. Figure 7.1 ReInDetector Architecture 7.2 Package GUI Figure 7.2 depicts the implementation of package GUI, which is responsible for providing interfaces for users to interact with the tool. 61

71 Chapter 7 Implementation of Prototype Figure 7.2 Structure of GUI package In Figure 7.2, the MainUI class is in charge of managing all GUI components in the program. The main GUI component is REGraph which supports the functions of drawing, presenting and managing requirements graphically. This class is developed with the help of JUNG Java library, which provides graph visualization features. The REGraphUtils utility class provides customization features to ReGraph to adapt with the context of Requirements Engineering. In addition, QueryPanel provides an interface for users to make selections on the requirements they want to make queries and the problem types they are interested in discover. The InfoPanel class provides 62

72 Chapter 7 Implementation of Prototype an area to display goal information (whenever it is requested from users) and detected problems explanations. The GoalCreationDialog and OntologyLoadingDialog are for entering inputs to create goals and choosing an OWL file to load an ontology respectively. 7.3 Package RE Figure 7.3 illustrates the structure of the RE package, which is responsible for managing requirements in the program. The REController class keeps track of all requirements (or goals) created and added by users. In addition, this package is where different goal types and links types used in refinement graphs are programmatically defined. In this implementation, we separate the definitions of Virtual Goal class ( VirtualGoal ) and real goal class ( Goal ) as they are very different. Goal refers to functional ( FunctionalGoal ) or non-functional goals ( NonFunctionalGoal ), which are requested as requirements or criteria of a system while virtual goals are created only for the purpose of visualization (in refinement graphs). Both of these goal types do have something in common and they are designed to inherit the same AbstractGoal abstract class. In regards to refinement links in refinement graphs, we implement three classes ANDLink, ORLink and OptionalLink to represent And- Links, Or-Links and Optional-links programmatically. 63

73 Chapter 7 Implementation of Prototype Figure 7.3 Structure of RE package 64

74 Chapter 7 Implementation of Prototype 7.4 Package Reasoner As mentioned earlier, the Reasoner package acts as a bridge between the main program and Pellet reasoner. The main class in this package is Reasoner, which can be considered as a Pellet s customized reasoner with additional features (provide inconsistency, redundancy, overlap checking and query service among requirements). These features are implemented with the InconsistencyChecker, RedundancyChecker and OverlapChecker. In addition, in order to allow queries t be performed, the OntologyGenerator class is implemented with the responsibility of generating new ontologies based on requirement selections (problem types would be detected on these new ontologies). Furthermore, the explanations of detected requirements problems are generated with the help of ProblemExplanator class, which is supported by the ExplanationUtility class, which interacts with the explanation built-in functions of Pellet, defines problem types and specifies the outputs of explanations. Last but not least, the full analysis and reasoning features of the program are strongly supported by ReasonerUtility class, which directly interacts with Pellet to process requests and receives responds. Figure 7.4 Structure of Reasoner package 65

75 Chapter 7 Implementation of Prototype 7.5 The roles of REInDetector The implementation of REInDetector has helped realizing the research idea. It provides a tool for requirements engineers to perform the process of eliciting, elaborating, structuring, analyzing and managing requirements. The tool supports the automated creation and maintenance of the ontology of concepts in the domain of requirements. Users are allowed to specify requirements in Manchester OWL Syntax, which will then be used by the tool to perform reasoning and detecting inconsistencies, redundancies and overlaps. 7.6 Summary In this chapter, we have discussed about the architecture and implementation of the REInDetector prototype tool. We have explained the general design of the system and also described in details the responsibilities and structure of each package in the programs. We have also discussed the role of this prototype tool in our research. 66

76 Chapter 8 Conclusion 8. Conclusion In this chapter, we will conclude our work with the summary of the goals and accomplishments of the research. We will also discuss about the limitations of the outcomes and point out future works. 8.1 Accomplishments One of the main goals of this thesis was developing a Requirements Engineering model which allows goals and requirements to be elaborated, managed and analyzed effectively and efficiently. The model also needs to support requirements engineers with the process of identifying requirement problems, including inconsistencies, redundancies and overlaps, which promotes further actions for resolutions. Another important goal was to provide requirements engineers with a user-friendly and systematic way of using the model in which no special expertise is required. The research described in this thesis has been conducted towards achieving the above goals. The accomplishments of this work are presented as follows: Requirements Engineering Process Model A Requirements Engineering Process model has been developed based on the Goaloriented Requirements Engineering (GORE) approach to address the issues and problems encountered in traditional Requirements Engineering approach. With the application of GORE, goals are elaborated through a process called goal-refinement. Goal refinement is a bi-directed process. One the one hand, goals are defined from higher-level goals by asking HOW questions (i.e. HOW this goal is achieved?). On the other hand, the appropriateness of a goal is verified by asking WHY questions (i.e. Why does this goal exist?). This sort of questions help requirements engineers verifying if the existence of the goal is necessary to be stated (does it really help satisfying the higher-level goal) or if there is any more goals needed. This bi-directed approach ensures the completion and also avoids redundancy in the goal refinement process. Manchester OWL Syntax and Requirement Specification Patterns In order to allow the automation of the process of identifying inconsistencies, redundancies and overlaps, requirements need to be formalized in a language that is 67

77 Chapter 8 Conclusion understandable by machine. In addition, the language needs to be user-friendly and requires no or less expertise to use it. From these criteria, Manchester OWL Syntax has been selected as the requirement specification language in our work. Manchester OWL Syntax is a sub-set of the Web Ontology Language (OWL) which is less logical and does not require the use of symbols, which make it easy to write and communicate. In addition, our main contribution in this part is the development of a set of pattern for this specification language. The patterns can be applied to a number of different scenarios in software development projects to assist requirements engineers with a quicker and systematic way to formalize requirements. Analysis and Reasoning Services The analysis and reasoning on requirements are performed with the help of Pellet reasoner. We have developed a custom reasoner based on Pellet to provide the identification of inconsistencies, redundancies and overlaps among requirements. In addition, the model also allows queries to be performed on any selected requirement set. REInDetector We have developed REInDetector, a JAVA prototype tool for verifying and demonstrating the ideas, features and functionalities of the model. 8.2 Limitations and Future Works The limitations, accompanied with the intended improvements, are discussed as follows: Limited Expressive Power One of the limitations in our work comes from the limited expressive power of the Manchester OWL Syntax (or Description Logics, as they are equivalent with respect to expressive power and things which can be represented in Description Logics can be expressed in Manchester OWL Syntax and vice versa). Manchester OWL Syntax is an OWL language which is designed for just sufficiently describing Web Service Ontologies, which usually contains only simple relationships and loose constraints. Therefore, difficulties would arise if the language is used for representing 68

78 Chapter 8 Conclusion complicated requirements (i.e. requirements with temporal relationships or requirements involves many objects and concepts). This is a tricky problem as the expressive power of languages, in general, would decrease according to their simplicities and so, usually complicated languages would solve the problem of lacking of expressive power but at the cost of complexity that users encounter (i.e. Linear Temporal Logics used in KAOS). To solve this problem, it is intended to extend the Manchester OWL Syntax with keywords which are able to specify temporal relationships. In addition, new keywords for defining universal and existential quantifier should also be part of the language. Other extensions of the language are surely required and would need to be done with comprehensive investigation on different real world projects requirements. Overlap Detection Process is not sound Overlaps are considered as the situations in which there are two or more requirements refer to the common or inter-related phenomenon. Specifically in Manchester OWL Language, overlaps are defined as the cases when two or more subsumption relationships are defined on two or more classes which have something in common ( something means that either the classes have subsumption relationships one is sub-class of another or there are individuals which are defined as the common instances of those classes) and those two relationships must refer to the same phenomenon. An example of overlaps is that: Photo SubClassOf hassizeinmb MAX 2 and ProfilePicture SubClassOf hassizeinmb MAX 4 overlap with each other because they refer to the same matter (size in Megabytes) on the intersecting classes (ProfiePicture is a sub-class of Photo). As another example, these two requirements are not overlapping, Photo SubClassOf hassizeinmb MAX 2 and ProfilePicture SubClassOf hasformat ONLY {PNG, JPG} because although ProfilePicture and Photo are intersecting classes, the two subsumption relationship refer to irrelevant factors. However, this irrelevance can t be detected with Pellet unless it is explicitly defined in the ontology. This problem comes from the Open World Assumptions used in Pellet. Therefore, the second example would be identified as an overlap in our system, which makes the detection process not sound even though it is complete because all possible overlap cases would be detected in this approach. 69

79 Chapter 8 Conclusion This problem can be solved by extending Pellet with Close World Assumption support. This extension is considered as our future work on Pellet, together with other extensions to adapt to the extended version of Manchester OWL Syntax discussed in the last section. 8.3 Summary This chapter concludes the body of the thesis. In this chapter, we have discuss about our goals and accomplishments in the research work, including the development of the Requirements Engineering Process model, the use of Manchester OWL Syntax to promote user-friendliness, the identification process of inconsistencies, redundancies and overlaps and the implementation of REInDetector, a prototype tool for verifying and demonstrating the ideas of this research. We have also identified some areas that require further attentions to improve the outcomes of this research. 70

80 Appendix 1 Complete Goal Refinement Graph Appendix 1 Complete Goal Refinement Graph This appendix presents the complete goal refinement graph in the small scenario used in this thesis. It is built for the purpose of demonstrating the use of the Requirements Engineering Process model and not targeted for specifying the entire set of requirements for the system. Therefore, the word complete here means the completion of the refinement graph in the scope of the scenario (see chapter 3 for the description of the scenario). The refinement graph for the entire system could take up to hundreds of pages and surely is not feasible to be included in this thesis. 71

81 Appendix 1 Complete Goal Refinement Graph 72

82 Appendix 1 Complete Goal Refinement Graph 73

83 Appendix 1 Complete Goal Refinement Graph 74

84 Appendix 1 Complete Goal Refinement Graph 75

85 Appendix 1 Complete Goal Refinement Graph 76

86 Appendix 1 Complete Goal Refinement Graph 77

87 Appendix 1 Complete Goal Refinement Graph 78

88 Appendix 1 Complete Goal Refinement Graph 79