Elsevier

Information Systems

Volume 43, July 2014, Pages 100-116
Information Systems

Agile requirements engineering via paraconsistent reasoning

https://doi.org/10.1016/j.is.2013.05.008Get rights and content

Highlights

  • Motivates importance of managing software variability via paraconsistent reasoning.

  • Introduces RE-KOMBINE for solving inconsistent requirements problems.

  • Creates language T1 for expressing inconsistent requirements problems.

  • Specifies and implements operators for querying requirements problems.

  • Evaluates the RE-KOMBINE framework with a retrospective industrial case study.

Abstract

Innovative companies need an agile approach towards product and service requirements, to rapidly respond to and exploit changing conditions. The agile approach to requirements must nonetheless be systematic, especially with respect to accommodating legal and non-functional requirements. This paper examines how to support lightweight, agile requirements processes which can still be systematically modeled, analyzed and changed. We propose a framework, RE-KOMBINE, which is based on a propositional language for requirements modeling called Techne. We define operations on Techne models which tolerate the presence of inconsistencies. This paraconsistent reasoning is vital for supporting delayed commitment to particular design solutions. We evaluate these operations with an industry case study using two well-known formal analysis tools. Our evaluations show that the proposed framework scales to industry-sized requirements model, while still retaining (via propositional logic) the informality that is so useful during early requirements analysis.

Introduction

It is increasingly uncommon for software systems to be fully specified before implementation begins. This is because uncertainty about the right requirements is inescapable. Furthermore, it is highly desirable to avoid premature commitment by being able to change/revise requirements throughout the development lifecycle. Being flexible in this fashion is a source of competitive advantage for a business; for example, by delivering the correct product before competitors. The notion that one should engage in what has been called “big design up front” as part of the design activity is no longer defensible [2], since inevitably early plans must be abandoned, or at best revised. A variety of studies and experience reports (most recently [3]) have shown that requirements changes are very expensive to accommodate and constitute the most frequent cause of project failures.

There is a shift, instead, to methods of software development which avoid premature commitment to decisions. The central tenet of these methods, including most Agile methodologies, is that requirements are discussed iteratively. These requirements are often manifested as very brief user stories, which serve as conversation starters with business representatives. A major concern with such lightweight requirements “engineering” is that non-functional requirements, such as security, are often neglected since system functionality is the focus [4].

While this lightweight approach to Requirements Engineering (RE) has become popular in many segments of industry, the IEEE standard for software requirements [5] uses words like “correct” and “unambiguous” to describe its recommended practice for RE. Thus, many previous approaches to the problem of system specification have methodological constraints insisting that conflicts and obstacles be resolved before solutions are identified. It is rarely, if ever, possible to achieve these criteria. We argue that the above shift demands a much more flexible approach to requirements modeling and analysis.

In this paper we introduce a framework, RE-KOMBINE, which supports this shift to flexibility. The framework represents possibly contradictory requirements as assertions about the current state of the requirements model, allowing us to reason paraconsistently about requirements problems. In paraconsistent reasoning local inconsistencies are not propagated globally, “polluting” all inferences, as in standard logic. This paraconsistent reasoning accommodates flexible, agile decision-making. The chief advantage of our approach is that it permits derivation of useful knowledge about problems of interest in the moment, while postponing decisions about currently inconsistent states of the problem until a decision must be made.

Example 1

To illustrate the usefulness of deferring conflict resolution, consider the requirements fragment in Fig. 1. The figure represents part of the business requirements (“use mobile terminals”) together with the imposed requirements from an applicable security standard (PCI-DSS, which we discuss fully in Section 4.1). The red, X-headed relation between requirements twep and d4.1.1 represents a conflict. In this case, the conflict is between the business-motivated use of the Wireless Encryption Protocol (WEP) and the security problems with WEP. Domain assumptions (in square boxes) are taken to be asserted truths (in contrast to goals, which are desired, or tasks, which are proposed parts of implementations). Existing approaches to requirements analysis either (i) insist that the conflict be resolved before proceeding with further reasoning (e.g., KAOS [6]) or (ii) represent the conflict as trade-offs for higher-level goals (e.g., [7]).

Assuming that we have an existing WEP solution in place, it also must satisfy the PCI-DSS. The conflict in this model emerges as a logical inconsistency. Because our framework is paraconsistent, its reasoning can isolate and work around the conflict for the time being, by informing the requirements engineer of conclusions that can be satisfied regardless. This is useful if, for example, the need for compliance is not immediate, and time and money can be better spent elsewhere. We also flag the conflict for the requirements engineer, who later has the choice of proceeding with one of the conflicting choices, or insisting that the model be revised (e.g., remove our WEP equipment). In the example, the final system might instead make use of Bluetooth for wireless transmission. 

In practice, then, the approach for a requirements engineer is as follows (italicized text indicates steps not addressed in this paper).

  • 1.

    Elicit requirements from stakeholders.

  • 2.

    Create requirements model using RE-KOMBINE, written in the T1 language. The model will include goals, domain assumptions, existing and possible tasks, and the structure of the problem space.

  • 3.

    Query RE-KOMBINE for possible solutions, if any, to this model.

    • (a)

      If RE-KOMBINE indicates that a solution exists, understand whether this is a controversial or uncontroversial solution (i.e., whether paraconsistent reasoning was necessary). If needed, choose one of the options in the conflict through further interaction with the stakeholders. If it is necessary to remove the conflict after choosing one option, then remove one or all other options in the conflict, which will remove the conflict. The decision to do so is indicated by assessment of the cost of revision, using, e.g., real options theory [8].

    • (b)

      If no solutions exists, repeat elicitation.

  • 4.

    Implement specification indicated by answer to queries on RE-KOMBINE.

  • 5.

    Update the requirements model when and where the existing problem changes, e.g., if new requirements are discovered or new domain assumptions constrain the solutions.

Here is an example showing how this might work.

Example 2

Lucene1 is a popular text retrieval library. One recent feature, tracked as LUCENE-1458,2 is the addition of a flexible indexing approach to storing text. The requirements might be represented as shown in Fig. 2.

Note the conflict between the implemented text-storage approach tutf8, supporting gbytes, and the need for tutf16 for Unicode support guni, which says that if we want both flexible indexing (gflex) and need internationalization support (gi18n) we have an inconsistent model. At this point we would like to signal the requirements engineer of this inconsistency, leaving it to him/her to resolve the problem. This might mean changing the design, dropping support for internationalization, or deferring the decision until the development of the rest of the feature was completed (e.g., satisfying gpost). 

What actually happened in this scenario was that the need for internationalization (a non-functional requirement) was never explicitly connected to the change in storage format for the new feature, and only a few days prior to release was the conflict understood. This example shows the inter-twining of the two motivations for our work: (1) the importance of requirements, because the portability/internationalization non-functional requirement did not seem to be an important factor in the ad hoc requirements approach of Lucene's developers; (2) the usefulness of delayed commitment in resolving fundamental contradictions in design approaches, such as the Unicode issue. For Lucene, in particular, the ability to develop experimentally is important, and we would not want to insist on Unicode support until the rest of the feature's design was properly understood.

In [9], we introduced the notion of a Requirements Engineering Knowledge Base/Theory rekb for maintaining a requirements model. In this paper, we build on the notion of an rekb to focus on the case where problems are changing and possibly inconsistent (i.e., contain contradictory assertions). We adopt a design science research methodology (as explained in [10]), focusing on the problem investigation and solution validation aspects, and leaving evaluation of the solution to future work. Our research questions are

  • RQ1

    What formal mechanisms are necessary to support reasoning with inconsistent requirements models?

  • RQ2

    Is there a scalable algorithm for automating analyses of such models?

To answer these questions, this paper makes the following contributions:

  • motivates the problem by identifying the importance of accommodating variability by supporting paraconsistency in software development, and modifying the way in which the requirements are queried;

  • proposes a framework, RE-KOMBINE, for finding solution specifications to possibly inconsistent, goal-oriented requirements problems, including:

    • language T1, in Section 3.1;

    • consequence relation over T1 formulas

      ;

    • formally specifying operators querying/modifying rekb using T1 and

      , in Section 3.3;

    • implementing these operators on top of existing technologies;

  • explicitly introduces paraconsistent reasoning into a prototype tool (Section 3.4);

  • evaluates the framework and its scalability with a retrospective industrial case study (Section 4).

This paper is an updated and expanded version of an earlier conference paper [1]. The most important extensions over [1] are: (1) a detailed discussion of paraconsistent consequence (

) to explain several semantic choices; (2) a formal introduction of the Techne language T1 used in the earlier paper; (3) a formal definition of the candidate solution concept; (4) a greatly expanded set of paraconsistent operators to include those creating rekb and those finding conflicts.

Notation: We use the following conventions in our paper, indexed or primed as necessary.

  • Capital Roman letters (A, B, C, …) represent typed sets.

  • Capital Greek letters (Π, Δ, Θ) represent arbitrary sets of formulas.

  • Small Greek letters (ϕ, ψ, δ, ) represent arbitrary formulas.

  • Small Roman letters represent specific atoms (e.g., a1, a2, b3).

  • reads False.

Section snippets

Inconsistency and Conflict

The ability to represent conflicts between requirements is an essential part of any requirements modeling language. In formal logic, a theory T is said to be inconsistent if one can derive False/, from T. Classical logic trivializes in the sense that anything can be derived from an inconsistent T (ex falso quodlibet). This makes inconsistent rekb based purely on classical logic useless for solving requirements problems

There are several ways to interpret the presence of a conflict relation

RE-KOMBINE

We now define a framework, RE-KOMBINE, for managing the inconsistency in requirements problems. We do so by viewing the requirements as a Requirements Engineering Theory (rekb)—a set of requirements formulas, which is manipulated by several operators, including ones allowing us to check what can be deduced from it by logical inference. We will use a paraconsistent inference relation

. We discussed in Section 2.2 a number of candidates for
which we have considered, and now proceed with it as a

Evaluating rekb

Recall that our research questions were:

  • RQ1

    What formal mechanisms are necessary to support reasoning with inconsistent requirements models?

  • RQ2

    Is there a scalable algorithm for automating analyses of such models?

We begin with a description of our case study of variability and evolution in requirements found in the Data Security Standard (henceforth PCI-DSS) [34], an industry standard which regulates security of credit card transactions. This is a retrospective case study, based on a real standard

Related work

We described the work of Giorgini et al. [39] and Sebastiani et al. [7] in Section 2.2.3. Their qualitative approach can simulate some of the capability of RE-KOMBINE. A major difference in philosophy is the omission, in RE-KOMBINE, of qualitative, partial satisfaction/denial relations. RE-KOMBINE deliberately omits this notion of partial satisfaction, because in practice, this bipartite approach leads to frequent occurrences of conflicting information about a given requirement. In a dynamic

Future work

There are several open questions on the topic of reasoning from requirements knowledge bases. Paraconsistent reasoning simply means that conclusions drawn from a requirements knowledge base are based on a set of inference rules that satisfy the paraconsistency property: whenever is inferred, it is not the case that all formulas are also consequences of the knowledge base, unlike classical logic.

A key open question for paraconsistency for requirements knowledge bases is: What are the

Conclusion

In many situations, establishing the entirety of a software development project's requirements up-front is unrealistic and even undesirable. Instead, we propose a systematic approach to agile requirements evolution where it is easy to change requirements and automatically evaluate the consequences of these changes (answering RQ1). We further show that this reconciliation makes it possible to delay decisions about conflicting requirements until more information becomes available. Our proposal is

References (40)

  • D. Zowghi et al.

    On the interplay between consistency, completeness, and correctness in requirements evolution

    Information and Software Technology

    (2003)
  • B. Nuseibeh et al.

    Making inconsistency respectable in software development

    Journal of Systems and Software

    (2001)
  • A. Dardenne et al.

    Goal-directed requirements acquisition

    Science of Computer Programming

    (1993)
  • J. de Kleer

    An assumption-based TMS

    Artificial Intelligence

    (1986)
  • N.A. Ernst, A. Borgida, J. Mylopoulos, I. Jureta, Agile requirements evolution via paraconsistent reasoning, in:...
  • M. Jarke, P. Loucopoulos, K. Lyytinen, J. Mylopoulos, W.N. Robinson, The brave new world of design requirements: four...
  • S. Mcgee, D. Greer, Software requirements change taxonomy: evaluation by case study, in: International Conference on...
  • B. Ramesh et al.

    Agile requirements engineering practices and challengesan empirical study

    Information Systems Journal

    (2010)
  • IEEE Software Engineering Standards Committee, IEEE Recommended Practice for Software Requirements Specifications,...
  • A. van Lamsweerde et al.

    Managing conflicts in goal-driven requirements engineering

    Transactions on Software Engineering

    (1998)
  • R. Sebastiani, P. Giorgini, J. Mylopoulos, Simple and minimum-cost satisfiability for goal models, in: International...
  • K. Sullivan, P. Chalasani, S. Jha, Software design as an investment activity: a real options perspective, in: Real...
  • N.A. Ernst, A. Borgida, I. Jureta, Finding incremental solutions for evolving requirements, in: International...
  • R. Wieringa et al.

    Requirements engineering paper classification and evaluation criteriaa proposal and a discussion

    Requirements Engineering Journal

    (2006)
  • W.N. Robinson et al.

    Requirements interaction management

    ACM Computing Surveys

    (2003)
  • S.M. Easterbrook, B. Nuseibeh, Managing inconsistencies in an evolving specification, in: International Conference on...
  • H. Thimbleby

    Delaying commitment

    IEEE Software

    (1988)
  • P. Zave et al.

    Four dark corners of requirements engineering

    ACM Transactions on Software Engineering and Methodology

    (1997)
  • N. Rescher et al.

    On inference from inconsistent premisses

    Theory and Decision

    (1970)
  • R. Fagin, J. Ullman, M. Vardi, On the semantics of updates in databases (preliminary report), in: International...
  • Cited by (24)

    • An agile approach for managing requirements change to improve learning and adaptability

      2019, Journal of Industrial Information Integration
      Citation Excerpt :

      Moreover, by providing only a few simple notations, anyone can quickly learn and use. RE-KOMBINE [20] also supports notation for domain assumption, but cannot distinguish requirements as hypotheses that require validation. The modeling result is in the form of a goal and task tree for the target system and doesn't expose customers directly.

    • A systematic review of requirements change management

      2018, Information and Software Technology
      Citation Excerpt :

      One technique used in requirement modelling in agile methods is goal-sketching, which provides goal graphs that are easy to understand [83]. This activity is also iterative and the goals are refined during each iteration [82]. This helps in RCM by creating unambiguous requirements that have a clear purpose, reducing the need for change during subsequent iterations.

    • Disciplined or Agile?: Two Approaches for Handling Requirement Change Management

      2021, Research Anthology on Agile Software, Software Development, and Testing
    View all citing articles on Scopus

    This is an expanded and updated version of an earlier conference paper [1].

    View full text