The Goal- and Process-Oriented Approach in Requirements Engineering

Contents

Introduction

Theoretical Background and related Work
Evolution of Requirements Engineering
The process- and goal-oriented approach

Research Method
Research Approach Overview
Preliminary Results: Keyword Search
Analytical research framework

Results
Overview of RE Approaches

Discussion
Comparison of RE Approaches
Kind of analysis/Context
Notation
Rationale
Advantages/Disadvantages of PORE and GORE

Conclusions
Contributions
Limitations
Future directions

References

Introduction

Requirements engineering (RE) is as a subfield of software engineering. It belongs to one of the most fundamental processes in software development as it significantly influences the outcome (Henderson 2006; Panayiotou et al. 2015; Ullah and Lai 2011). It is an iterative process comprising several stages like eliciting, elaborating, structuring, specifying, analyzing and managing the stakeholders’ requirements (Daneva and Wieringa 2006). Two methodologies namely process- and goal-oriented RE have been developed to standardize the RE procedure. Process-orientation focuses on the business process itself and how it can be aligned to the existing system (Hill and Wang 2004). Using goal-orientation, the analyst derives goals from requirements mostly looking on non-functional requirements (van Lamsweerde 2001). The achievement of goals is necessary to fulfill the requirement. The mentioned directions are abstract ones, since researchers developed several frameworks, that are derived from them, such as KAOS, TROPOS, i*, NFR etc. (Kavakli 2002; Van Lamsweerde 2000; van Lamsweerde 2001). These approaches can be assigned to either the process- or goal-oriented methods. So in this article, I conduct a comparison of them and create an overview, helping practitioners to pick an appropriate method for their specific contract. Having these frameworks, they support the complete RE procedure and assist to mitigate issues:

Looking at a concrete scenario, namely the implementation of an enterprise resource planning systems (ERP) implementation, RE is a vital task to fulfill the stakeholders’ demands and be successful (Panayiotou et al. 2015). Furthermore, occurring stakeholders’ conflicts during the requirements specification and inconsistencies are major issues in RE (Cailliau and van Lamsweerde 2013; Daneva and Wieringa 2006; Eveleens and Verhoef 2010; Kavakli 2002; Nguyen et al. 2014; van Lamsweerde 2001). At least two requirements are inconsistent, if they are in opposition to each other, i. e. they cannot be met by the system simultaneously (Nguyen et al. 2014). Hence modifications are necessary to solve the conflict or revoke the inconsistencies. Additionally, occurring issues during the eliciting phase lead to incomplete and inaccurate requirements strengthening this problem area. The analyst and the client work together to develop the requirements (Chakraborty et al. 2015; Chung and Nixon 1995). Each analyst has a different comprehension of the interviewees’ utterances, so that misunderstandings and misinterpretations of this kind of qualitative data lead to a vague requirements document. Distributed requirements analysis, i. e. client and vendor not sitting at the same location and therefore have to use tools such as Skype or Lync, is a complication factor as well (Mylopoulos et al. 2002; Mylopoulos et al. 1999; van Lamsweerde 2001).

Therefore, standardized frameworks provide a practical solution to avoid the mentioned problems and I can justify, that a closer look on these kind of approaches is necessary. Hence, my research question is as follows: What are the current process- and goal-oriented approaches in RE and how do they differ?

To answer this research question, and based on already conducted research, I carry out a comparative literature review.

I have structured the remainder of this paper as follows. In the first section, I will provide background information about RE and establish important terminology for understanding. In the second section, I describe my research method and its results. In the third section, I illustrate the different RE approaches. In the fourth section, I examine the found approaches looking at differences and similarities by choosing four categories as distinctive features. I wrap up the paper with a conclusion.

Theoretical Background and related Work

Evolution of Requirements Engineering

Looking back in the 90s, researchers hardly focused on RE and thus, little practical advice was available (Panayiotou et al. 2015). However, the few developed approaches address the problem of incomplete RE as mentioned in the introduction (Yu 1997). But, these traditional RE approaches turned out to be inadequate for handling complex information technology (IT) systems such as self-adaptive systems (Nguyen et al. 2014; Rumbaugh et al. 1991). These kind of approaches are somewhat rudimentary and have a narrow perspective in their approach/treatment of RE (Mylopoulos et al. 1999). Requirements engineers conduct system analysis by mixing isolated modeling techniques such as data flow, entity-relationship (ER) and state transition diagrams (van Lamsweerde 2001). Consequently, they were able to collect information that had to be understood, modeled and analyzed before the actual system development phase can start. Nevertheless, they include a couple of drawbacks apart from the shortage of integration (Mylopoulos et al. 1999). They do not capture the fundamental principle, i. e. they lack a detailed view. For example, the analysis elicits the requirement ‘security’. Now here are the questions: “What kind of security? Data security or data backup? Fingerprint, password, eye-scanner? Etc.”. Consequently, this makes it even more aggravating to set a linkage to high-level concerns in the problem area (Mylopoulos et al. 2002; Nguyen et al. 2014). Additionally, most of the methods consider the modeling and the specification process of a software as singular without taking into consideration interdependencies with the environment (Rumbaugh et al. 1991).

However, traditional methodology does not meet the demands of present day RE due to lack of standardized analyzing methods. On the one hand, systems became more complex. On the other hand, the stakeholders’ qualitative data is unstructured and brings inconsistencies as well as constraints along (Doerr et al. 2005). Due to the high influence of object-oriented programming in the last years, the perspective on RE has undergone a change. Research activities more intensively concentrate on the “how to design” question on RE in sense of improvement and alignment with business processes. Furthermore, system integration also plays a significant role in the system development research domain (Doerr et al. 2005; Giorgini et al. 2005; Mylopoulos et al. 1999). Although the dynamic environment is a complex construct, new approaches encourage to explicitly consider those aspects, since they significantly emboss the output (Mylopoulos et al. 1999).

The process- and goal-oriented approach

Examining the existing body of literature and hence to encounter the problems mentioned above, researchers developed two main approaches. These, known as process- and goal-oriented approach, consider the dynamic of the environment and provide holistic techniques to develop requirements for a proposed system (Panayiotou et al. 2015; van Lamsweerde 2001). In order to promote the understanding of both, the process- and goal-oriented approach, requirements and goals should be defined and distinguished from each other:

Usually, requirements are derived from qualitative data, for example from interviews with stakeholders. There are functional as well as non-functional requirements. Functional ones define the task a feature has to do. Non-functional ones are quality attributes which promote e.g. usability, performance, security, portability etc. (Chung and Leite 2009; Hill and Wang 2004; Mylopoulos et al. 1999). Non-functional requirements are not always complementary, they may also be contrary. For example, a credit card system has to process online transactions (the task) in an accurate, secure, fast and user-friendly way (quality attributes). Security is absolutely necessary since without a high degree of security, the user is exposed to the danger of abuse. A highly implemented secure mechanism requires more processing time, because several numbers have to be put in the graphical user interface (GUI) and thus, decelerates the whole process, also affecting the user-friendliness (Haley et al. 2008).

In general usage, goal is associated with facts that have to be achieved at a certain point in the future. From a RE perspective, goals represent organizational objectives or targets having to be fulfilled and for implementing business targets, goal modeling initializes the whole process (Ullah and Lai 2011; van Lamsweerde 2001). Furthermore, goals can be separated into hard- and soft-goals. On the one hand, hard-goals specify functional and on the other hand, soft-goals itemize non-functional requirements (van Lamsweerde 2001). Both of them help to make the requirements operationalizable (Chung and Leite 2009). Defining goals are a key task in the RE process, since they provide a couple of benefits:

1. Generally, achieving a RE completeness is a major concern. Goals represent a precise criterion for an adequate completeness of a requirement. Having a set of goals for the requirements specification, they have the capability to achieve the specification, if all goals are able to be proved (Kavakli 2002).
2. Making requirements understandable for stakeholders is another existing concern. Requirements need a rationale and this is represented by goals. Especially in the business application systems, goals are qualified to set the link between the system-to-be to business and organizational contexts (van Lamsweerde 2001).

Having clarified the two prevailing terms, I can characterize the process- and goal-oriented approach.

Process-oriented requirements engineering (PORE) helps to justify design decisions during the software decision process. According to Mylopoulos et al. (2002) “it attempts to develop formal definitions of non-functional requirements so that a software can be evaluated as to the degree to which it meets its requirements”. Since this is a quite narrow definition, I append the following statement to the definition to cover by findings: “PORE also focuses on how business processes can be streamlined with each other and to integrate new ones without violating existing ones in the organization”. PORE methodology is usually applied in the context of enterprise resource planning systems (ERP) implementation, especially to align the cross-organizational processes. On the one hand, each company has to be able to manage its own processes. On the other hand, they have to be made transparent, so that they are visible to each stakeholder of the overall enterprise (Daneva and Wieringa 2006; Nguyen et al. 2014).

In contrast to PORE, Goal-oriented requirements engineering (GORE) “is concerned with the use of goals for eliciting, elaborating, structuring, specifying, analyzing, negotiating, documenting, and modifying requirements” (Nguyen et al. 2014). The idea behind is, that a goal tree is constructed which is derived from the requirements. It is possible that they may be related to object models, since goal formulations have a linkage to specific objects such as entities, agents and relationships (Dardenne et al. 1993). As a matter of fact, the examined system is usually analyzed in its operational, technical and organizational setting (Van Lamsweerde 2000). In the case of detecting problems, high-level goals can be defined and refined into further sub-goals to address those problems (Van Lamsweerde 2001; Van Lamsweerde et al. 1998). In the next step, analysts elaborate requirements to satisfy the prior defined goals. By iterating this process, other requirements can be elicited. Summing up, GORE approaches provide both a top-down and bottom-up refinement. They quantify the requirements in order to address major issues associated with a lack of the requirements’ basis (Kavakli 2002; Kolp et al. 2001; Nguyen et al. 2014).

Research Method

Research Approach Overview

For answering my research question “What are the current process- and goal-oriented approaches in RE and how do they differ?”, I conducted a literature review based on the recommendations of Webster and Watson (2002). After that, I present an analytical framework consisting of four distinctive categories to compare process- and goal-oriented approaches. The literature review comprised three steps: (1) initial review, (2) keyword search via LITSONAR, PROQUEST and EBSCOhost, (3) Backward search.

The initial review revealed, that most of the documents deal with RE approaches containing fundamental knowledge about process- as well as goal-oriented strategies. These documents served the purpose to deliver the basis for further analysis.

For getting more detailed information about current methodologies, I made use of search engines such as LITSONAR, PROQUEST and EBSCOhost. In the beginning, I used LITSONAR, which is a meta search tool and accessed by the University of Cologne Network. I wanted to get a general overview of the existing body of literature in requirements engineering referring to process and goal-oriented approaches. At first, I selected the term “requirements engineering”. There were over 10 Million results. I extended the search string to “requirements engineering framework” also having more than 10 Million hits. Hence, the necessity of further key words, the usage of smaller tools, had their justification leading to PROQUEST and EBSCOHOST.

Finally, I conducted a backward search with focus on titles containing terms such as “process-oriented” or “goal-oriented”. Consequently, I found basic literature about predominant approaches in RE and could investigate them.

Preliminary Results: Keyword Search

Within this context, I used PROQUEST comprising 26 databases. The string “requirements engineering” delivered 92,564 hits. So, I elected an advanced search method by focusing only on “full text” and “peer-reviewed” articles, reducing output and ensuring the papers’ quality. There were 3,885 results. A further constraint, concerning the published date, lead to another compression of the results. Since requirements engineering is an up-to-date research topic as mentioned in the introduction, I filtered only articles published between 2005 and 2015, ended up in 1,744 papers. In order to get more information about process and goal-oriented approaches in requirements engineering, I added the term “framework”, i. e. “requirements engineering AND framework”. I could minimize the output to 177. Subsequently I extended the string to “requirements engineering AND framework AND software” to get 85 results being more topic-related. Finally, I appended the composite search string with terms within the research question resulting in “requirements engineering AND framework AND (process-oriented OR goal-oriented)”. I got 5 hits.

Finally, I caught out the same procedure with EBSCOhost running through 39 databases. I depicted the overall result in table 1, whereas the first value relates to PROQUEST (PR) and the second one to EBSCOhost (EB).

Abbildung in dieser Leseprobe nicht enthalten

Table 1. Literature review results.

Analytical research framework

Based on my reading, I derived certain attributes that each RE approach has in common (Giunchiglia et al. 2002; Hill and Wang 2004; Mylopoulos et al. 2002; Nguyen et al. 2014; Van Lamsweerde 2000). Firstly, a RE approach consists of a certain analysis technique. Secondly, it uses a special notation to make it standardized and applicable for each analyst. Thirdly, it follows a fundamental principle to achieve a certain goal. Fourthly, there exists not only advantages but also disadvantages, making a RE methodology more or less appropriate for a modeling scenario.

Abbildung in dieser Leseprobe nicht enthalten

Table 2. Analyzed dimensions.

[...]