ChapterPDF Available

A Refinement Calculus for Requirements Engineering Based on Argumentation Theory

Authors:

Abstract and Figures

The Requirements Engineering (RE) process starts with initial requirements elicited from stakeholders – however conflicting, unattainable, incomplete and ambiguous – and iteratively refines them into a specification that is consistent, complete, valid and unambiguous. We propose a novel RE process in the form of a calculus where the process is envisioned as an iterative application of refinement operators, with each operator removing a defect from the current requirements. Our proposal is motivated by the dialectic and incremental nature of RE activities. The calculus, which we call CaRE, casts the RE problem as an iterative argument between stakeholders, who point out defects (ambiguity, incompleteness, etc.) of existing requirements, and then propose refinements to address those defects, thus leading to the construction of a refinement graph. This graph is then a conceptual model of an RE process enactment. The semantics of these models is provided by Argumentation Theory, where a requirement may be attacked for having a defect, which in turn may be eliminated by a refinement.
Content may be subject to copyright.
A Refinement Calculus for Requirements Engineering
Based on Argumentation Theory
Yehia ElRakaiby1ID , Alexander Borgida2ID
Alessio Ferrari3ID , and John Mylopoulos4ID
1Universit´
e du Luxembourg, Luxembourg yehia.elrakaiby@uni.lu
2Rutgers University, New Brunswick NJ, USA borgida@rutgers.edu
3CNR-ISTI, Pisa, Italy alessio.ferrari@isti.cnr.it
4University of Toronto and University of Trento jm@cs.toronto.edu
Abstract. The Requirements Engineering (RE) process starts with initial re-
quirements elicited from stakeholders – however conflicting, unattainable, in-
complete and ambiguous – and iteratively refines them into a specification that
is consistent, complete, valid and unambiguous. We propose a novel RE process
in the form of a calculus where the process is envisioned as an iterative appli-
cation of refinement operators, with each operator removing a defect from the
current requirements. Our proposal is motivated by the dialectic and incremental
nature of RE activities. The calculus, which we call CaRE, casts the RE problem
as an iterative argument between stakeholders, who point out defects (ambiguity,
incompleteness, etc.) of existing requirements, and then propose refinements to
address those defects, thus leading to the construction of a refinement graph. This
graph is then a conceptual model of an RE process enactment. The semantics of
these models is provided by Argumentation Theory, where a requirement may be
attacked for having a defect, which in turn may be eliminated by a refinement.
Keywords: requirements engineering, RE process, RE calculus, argumentation
theory
1 Introduction
The creation of software requirements is a very important initial stage of software de-
velopment. The original core problem in Requirements Engineering (RE) consists of
transforming the initial requirements Relicited from stakeholders — however infor-
mal, ambiguous, unattainable, etc. — through a systematic refinement process into a
specification Sthat (a) consists of functional requirements, quality constraints and do-
main assumptions, such that (b) Sis consistent, complete, and realizable, and (c) S
fulfills R. Variants of this problem form the backbone of RE research, and since the
late 1970’s it has been recognized that the resulting requirements document contains a
conceptual model of the environment and the software-to-be [1,2].
To begin with, consider two RE techniques that can be viewed as research baseline
and analogues for our work. In each case, we mention 1) the basic ontology underlying
the approach, 2) the refinement process by which the requirements are built, and 3) the
“requirements document” resulting from the enactment of this process.
2 Y.ElRakaiby et al.
SADT (1977) [1] was the first widely known requirements specification notation
and methodology. The modeling ontology of SADT consists of data and activity boxes,
connected by input/output/control arrows. The refinement methodology is structured
decomposition of non-atomic boxes into aptly named sub-boxes, which are intercon-
nected by aptly-named arrows in appropriate ways. Therefore, the final requirements
document/model consists of a number of pages, each describing the internal content of
a box; all unexpanded boxes are viewed as atomic/realizable. Ross [1] explicitly stated
that SADT can be used to describe not just software requirements but to communicate
any idea/conceptual model, and showed how to describe the process of model building
in SADT itself.
Basic Goal-Oriented RE—GORE (1993) [3,4] is one of the most influential RE
paradigms, and, in its simplest form, has an ontology consisting of goals, connected
by reduction and conflict relations. The methodology suggests refining non-realizable
goals (ones that cannot be implemented directly) using AND/OR decomposition. The
final requirements model then consists of the graph of goal and decomposition nodes,
with operationalisable goals as leafs.
The present paper, which extends and builds on initial work in [5], proposes an
approach, called CaRE, whose ontology consists of goals/requirements,defects and
refinements, the latter two of various sub-types. CaRE offers a novel calculus of oper-
ators that can be used to critique goals using various defect types, and to address such
defects using various kinds of refinements. The CaRE refinement methodology suggests
viewing the use of the operators as a dialectic argument between stakeholders, includ-
ing requirements engineers. The result of enacting this argument will be a refinement
graph, which records goals, defects and refinements, and for which we define a notion
of “acceptability”. The set of defect subtypes in CaRE is inspired by the IEEE/ISO Stan-
dards on Software Requirements Specifications [6,7]. The set of refinements addressing
them is gathered from the RE literature, which contains many proposals for dealing with
specific types of problems. These include techniques for eliminating forms of conflict,
such as inconsistencies [8] and obstacles [9]. For example, the nonAtomic defect in
CaRE marks a goal as non-operationalisable (in GORE terminology), and the reduce
operator can be used to perform AND-decomposition of the goal.
Prior RE approaches, starting with [10], viewed initial requirements Ras being
satisfied by specification Sunder domain assumptions A, if Aand Stogether logically
entailed R. This notion of fulfillment runs counter to requirements engineering practice,
where stakeholder requirements are routinely weakened because they are unnecessarily
strong (e.g., “system shall be available 7/24”), or even dropped altogether. Such refine-
ments can’t be accounted for explicitly by proposals in the literature.
The CaRE process, in contrast, results in a refinement graph with nodes correspond-
ing to requirements: some for the initial R, some for potential specifications S, and oth-
ers for intermediate refinements. Some S, consisting of leaf nodes, is said to address R
if there is an “acceptable argument” that involves refining Sfrom R. This renders the
derivation of Sfrom Ra Hegelian dialectic process of thesis-antithesis-synthesis [11],
also similar in spirit to the inquiry cycle [12], though our proposal includes more struc-
ture, technical details, and reasoning support for the RE process. Addressing a given
set of requirements by offering an acceptable argument is a weaker notion of fulfill-
A Requirements Refinement Calculus 3
ment than satisfying it, because it allows a requirement to be weakened or altogether
dropped, as long as there is an acceptable argument for this. Towards this end, we adopt
argumentation semantics from Dung [13].
The contributions of this work are:
A comprehensive refinement calculus for RE, inspired by goal-oriented RE but
which adds: (i) “defects” and “refinements” to its ontology, based on a full set
of defect types from IEEE/ISO standards; (ii) a comprehensive set of refinement
operators for defects; (iii) refinement graphs, which are conceptual models of the
RE process enactment, and can serve as explanation/rationale for the specifications
obtained.
An argumentation-based semantics of what it means for a specification to address
a set of stakeholder requirements. The systematic process for constructing CaRE
refinement graphs, inspired by its argumentation-based semantics, supports nego-
tiation and convergence towards agreement between stakeholders. In contrast with
most previous approaches, where only a requirement engineer conducts analysis,
with CaRE all stakeholders are involved.
Reasoning support that, given an initial set of requirements Rand a constructed
refinement graph, returns all specifications Sthat address R. This is implemented
as a prototype tool that is available on the web.
2 CaRE Requirements Calculus
The proposed approach consists of a calculus and a systematic process for requirements
elicitation, negotiation, and refinement. The calculus is based on a collection of defect
types and of refinements. The defect types are inspired by the IEEE/ISO standards and
represent issues that could be identified by stakeholders for one or more requirements.
Refinements, on the other hand, are the means for fixing defects. By means of an iter-
ative process of defect identification and refinement, a refinement graph is constructed
and zero or more specifications are produced.
Defect Types: Defects can be found in individual requirements (single-target defects)
or sets thereof (multi-target defects). The single target defects are
– nonAtomic: the requirement is not operationalisable. For example, hg1:“System
shall schedule a meeting upon request”imay not be atomic since there is no single
action the system-to-be or an agent in the environment can perform to address it.
– ambiguous: the requirement admits many interpretations because it is vague, im-
precise, or otherwise ambiguous. For example, hg2:“The authentication process
shall be easy”iis ambiguous since the term easy is vague.
– unattainable: the requirement is not feasible, i.e. doesn’t have a realistic solution.
For example, hg3:“The system shall be available at all times”iis unattainable be-
cause it assumes eternal availability of power and other resources.
– unjustified: the requirement does not have an explicit motivation. For example,
hg4:“The system shall run on Windows operating system”iis missing an explicit
justification why other operating systems are not considered.
4 Y.ElRakaiby et al.
– incomplete: the requirement is missing information. For example, hg5:“In case of
fault, the system shall send an error message”iis incomplete because it does not
specify a recipient for the message.
– tooStrong: the requirement is over-restictive. For example, hg6:“The website shall
use HTTPS protocol”i, may be too strong if there is no sensitive data.
– tooWeak: the requirement is too weak. For example, hg7:“The DB system shall
process 500 transactions/sec”iis too weak if the expected workload for the system-
to-be is 1,000 transactions/sec.
– rejected: the requirement is rejected. For example, in the context of an app rec-
ommending nearby restaurants to users, a requirement such as hg8:“The app shall
support chatting between user and restaurant”imay be deemed unacceptable.
The multitarget defects are:
– mConflict: the full set of requirements doesn’t admit any solutions, even though
subsets may do so. For example, the requirements hg9:“The train control system
shall stop the train if a red signal is missed”iand hg10:“The train control system
shall not apply brakes if the speed is below 30 km/h”iare conflicting, if the driver
is in charge for speeds <30km/h.
– mMissing: the set of requirements is incomplete. For example, a set of require-
ments for a social network platform is mMissing if it does not include any privacy
requirement.
– mRedundant: here a set of requirements is too strong or redundant, as in hg11:“The
system shall support authentication through fingerprint recognition”iand hg12:“The
system shall support authentication through iris recognition”i.
Refinement Operators: A refinement operator invocation, op(D, R), addresses a de-
fect Dof some existing requirements, offering alternative (presumably better) require-
ment(s) Rthat address the problem. Each operator takes a (set of) defective require-
ments, and is applicable to one or more defect types. Each defect type has at least
one refinement operator that is applicable to it, i.e., can eliminate defects of that type.
Defects of type rejected are an exception: in this case there is no possible fix, as the
rejected requirement constitutes a dead end. Although some operators behave similarly,
we have chosen to keep them, to make the calculus more readily usable. The operators
are as follows:
– weaken: introduces a weaker requirement. For example, the unattainable require-
ment g3may be weakened into hg13:“The system shall be available at all times, with
interruptions of 2 hours”i.weaken is applicable to defects of type unattainable,
and tooStrong.
– strengthen: introduces a stronger requirement. For instance, g7may be strength-
ened into hg14:“The system shall process 1,200 tps”i.strengthen is applicable to
defects of type tooWeak.
– reduce: decomposes a requirement into a set g1, ..., gnusing AND-refinement. re-
duce is applicable to defects of type nonAtomic.
– add: introduces new requirements, and is applicable to defects of type mMissing.
– clarify: is applicable to incomplete and ambiguous defects, and introduces a, pre-
sumably, improved requirement.
A Requirements Refinement Calculus 5
REQ-id: REQ-text
Single Target
Defect
Requirement
Single Refinement
Multi-target
Defect
{REQ-1, ..., REQ-m} Requirement Set
Multiple
Refinement
DType(DEF-id:[<"claim">])
RType(REF-id)
DType(DEF-id:[<"claim">])
Alternative
Refinement
RType-1(REF-id-1)
RType(REF-id)
RType-2(REF-id-2)
Fig. 1. Graphical Notation
g00: the app shall run on
Android
g01: the app shall be
delivered within
6 months
mConflict(d01: "cannot deliver
Android app in 6 months")
g23: the app shall
run on Android
g24: the app shall be
delivered within
12 months
resolve(r20)
g20: the app shall run on
iOS
g21: the app shall be
delivered within 6 months
resolve(r21)
unjustified(d00)
g10: the app shall run on
all existing tablets, which
use Android
g22: all tablets of the
factory shall be replaced
with iPads
justify(r10)
Fig. 2. Refinement Graph Example
– justify: introduces a new requirement that represents an explicit motivation for
another requirement, and is applicable to unjustified defects.
– resolve: applies to defects of type mConflict, typically moderating or dropping the
original requirements.
– drop: given a set of mRedundant requirements, produces a proper subset not in-
cluding redundant elements.
2.1 Incremental Construction of a Refinement Graph
The incremental CaRE requirements acquisition process starts with an initial set of re-
quirements. These are critiqued by stakeholders and defects in the requirements are
identified. Then, requirements – or sets of requirements – that have defects are refined
by applying the different refinement operators, producing new requirements. If the new
requirements are acceptable, i.e. have no defects, the original (defective) requirements
are accepted. Otherwise, this process is repeated until no new defects are identified.
Thus, the result of the process is a refinement graph in which all the leaf nodes are re-
quirements that have no defects. Therefore, in a sense, the acceptability of requirements
is propagated from the leaf nodes towards the higher-level nodes. Finally, specifications
of a refinement graph are determined by identifying minimal sets of leaf nodes that
make the initial requirements acceptable.
2.2 Graphical Notation and Running Example
This section presents a simple example used to illustrate our proposal, and its graphical
expression. The basic elements of the graphical notation are shown in Fig. 1, and consist
of requirements, defects (single- and multi-target), and refinements. Each instance of
these elements is associated with a unique id (REQ-id, DEF-id, REF-id in Fig. 1).
6 Y.ElRakaiby et al.
The example, which is based on a simple elicitation case, is represented by the re-
finement graph in Fig. 2. In the running example, a customer requires a new app to be
installed on the tablets of factory workers, to be used for sharing workflow information.
The customer requires that the app runs on Android (g00). Furthermore, the customer
wants the system to be delivered within six months (g01). The requirements analyst
asks why Android is required (unjustified(d00) defect), and the customer replies that
the tablets currently used by the workers are all Android tablets (g10, introduced with
the jusify refinement r10). The requirements analyst knows that their software com-
pany has a very similar app for iOS, but that porting and adaptation would require
twelve months. Hence, g00 and g01 are considered conflicting. In the refinement graph,
an mConflict defect is specified, and a textual motivation (the optional <“claim”>
in Fig. 1) is used to explain the nature of the defect: mConflict(d01:“cannot deliver
Android app in 6 months”). To comply with the deadline, the requirements analyst sug-
gests to develop the app for iOS (g20), so that its adaptation to the customer’s needs
is feasible within 6 months (g21). However, this would require replacing the tablets at
the factory with iPad tablets (g22). Alternatively, the requirements analyst suggests to
develop the app for Android (g23), but to deliver it in twelve months (g24). These two
options aim at resolving conflict d01, and are represented as alternative refinements r20
and r21. Assuming that no other defects are found, according to the approach provided
in Sect. 2.1, we have two possible specifications: {g20, g21, g22}and {g23, g24}.
2.3 Discussion of Design Choices
Firstly, we gained a claim of completeness with respect to the defect types of our cal-
culus by using the IEEE/ISO standards. However, there is no claim of minimality for
defect types since, e.g., unattainable is a form of tooStrong. However, there’s been
much research on how to recognize and deal with unattainable specifically – it is a
special case of conflicting requirements and domain assumptions.
The set of refinement operators is not minimal since, e.g., add and justify modify
the graph the same way. However, operators guide users on how to deal with defects. For
example, if ris attacked as being incomplete with respect to privacy concerns, then use
of add should introduce some privacy requirements. If, on the other hand, ris deemed
unjustified, the new requirement introduced by justify should serve as justification for
r. In short, add and justify do similar things, but for very different purposes.
CaRE might be criticized as too cumbersome for users compared to, say, GORE
approaches. This may well be the case – we need empirical studies to judge this. How-
ever, as discussed above, CaRE is the only proposal in the RE literature for solving the
requirements problem in its greater generality. And in any case, in addressing an open
problem one may want to keep in mind Albert Einstein’s dictum “Make things as simple
as possible, but not simpler”.
3 Argumentation Semantics
Dung [13] introduced a formal Argumentation Framework (DAF), whose basic notions
are arguments and attacks (conflicts between arguments), and where the key reason-
ing task is the acceptability of arguments, i.e, whether and which arguments should or
A Requirements Refinement Calculus 7
should not be accepted by an intelligent agent. Sets of collectively acceptable arguments
are called extensions.
The semantics of the CaRE calculus will be given in the form of a translation from a
refinement graph into an ASPIC+argumentation theory, a structured variant of Dung’s
DAF [13]. The translation leads to arguments that represent requirements, defects and
refinements. Informally, attacks between these arguments correspond to (i) the identifi-
cation of a defect in a requirement or set of requirements, and (ii) the application of a
refinement to address a defect. More precisely, in our formalisation, an argument dthat
represents a defect in a requirement gattacks the argument representing g; similarly,
an argument rthat represents a refinement to address a defect dattacks the argument
representing d, thus possibly restoring the acceptability of the attacked requirement.
The specifications resulting from a refinement graph are computed by considering all
possible minimal extensions where the initial requirements are acceptable.
The formalization of CaRE using ASPIC+is motivated by (i) the dialectic nature of
requirements engineering, for which argumentation theory is a natural formal choice;
(ii) the flexibility of ASPIC+, being a meta-reasoning tool for reasoning over a freely
chosen underlying logic, which enables us to easily consider more structured RE lan-
guages, e.g. [14], in the future; (iii) the non-monotonic nature of argumentation theo-
ries, which enables extending the framework to incorporate other important features,
e.g., support of conflict and dependency relations between requirements [15].
This section first introduces the formal definition of the ASPIC+structured argu-
mentation framework, and the formal representation of a refinement graph and its well-
formedness conditions. It then describes how a refinement graph is translated into an
ASPIC+argumentation theory and, thereby, into a DAF. We define how this enables de-
termining the acceptability of requirements and computing specification sets. Finally,
we conclude by describing a prototype tool implementing our calculus.
3.1 Basics of Argumentation Theory
In a DAF, arguments have an abstract representation in the form of simple propositions,
e.g., the argument “It is raining today, therefore I should stay home”can be represented
using a simple propositional symbol a. Conflicts between arguments are given in a rela-
tion Dover the set of arguments. For example, consider another argument b, “I have to
buy food, so I must go to the store”, which obviously conflicts with a. In DAF’s termi-
nology, this conflict is called an attack, and is represented in the form of a tuple (a, b)
in D. Given arguments and attacks, the acceptability of arguments can be determined,
informally, as follows [16]: an argument is IN (acceptable) if it is not attacked or if
all its attackers are OUT (not acceptable). An argument is OUT if it is attacked by an
argument that is IN. Otherwise, an argument is UNDECIDED.
Though powerful, the abstract representation of arguments in DAF makes it often
less practical for modeling real-world problems. The ASPIC+framework for structured
argumentation [17]5therefore extends DAF to enable the representation of basic argu-
ments in the form of inference rules, each having a set of premises and a conclusion. For
example, argument aabove can be represented using a (strict) inference rule, having a
5In this paper, we adapt a version of ASPIC+, by simplifying and specializing it to support
reasoning in our calculus. Our version is partially inspired by [18].
8 Y.ElRakaiby et al.
single premise “it is raining today” and a conclusion “I should stay home”. One advan-
tage of this representation is that it explicates the structure of arguments and enables
the automatic construction of complex arguments by chaining inference rules. ASPIC+
relies on DAF to determine acceptability of arguments. In particular, given an argu-
mentation theory that includes inference rules, ASPIC+identifies the different basic and
complex arguments as well as conflicts between them. Then, it constructs a DAF and
uses it to determine which arguments are accepted and which are not.
3.2 Formal Description of Refinement Graphs
A refinement graph RG is a tuple hReq,Defect,Refiwhere:
Req Idg×Text is a set of requirements. Each requirement has a unique identifier
(in Idg) and a natural language text description (in Text).
Defect Idd×DType × P(Text) × P(Idg)is a set of defects. A defect has (i)
a unique identifier (in Idd); (ii) a defect type ; (iii) some natural language explana-
tions of the defect’s nature; and (iv) the identifier(s) of a set of requirements found
to have the defect.
Ref Idr×RType ×Idd× P(Idg)is a set of refinements. A refinement has
(i) a unique identifier (in Idr); (ii) a refinement type ; (iii) a defect that it aims at
addressing, and (iv) a set of other requirements, which are meant to replace the
defective one(s).
So, for example, from Fig. 2, we have the formal requirement Req(g23, T he app shall
run on Android)6.
The set of identifiers Idg,Idr, and Iddare disjoint; henceforth, given a refinement
graph RG=hReq,Defect,Refi, the set IdRG is used to denote all identifiers of its ele-
ments, i.e., IdRG = IdgIddIdr.
A refinement graph is well-formed iff every refinement addressing a defect matches
its type, as described in Sect. 2.
In addition, to make the semantics work out more easily, we assume in this confer-
ence paper that the refinement graph is acyclic. This means that if a requirement is to
be re-used it must be given a new label.
3.3 Refinement Graph Semantics by Translation to Argumentation Theory
Each refinement graph RG has a corresponding ASPIC+argumentation theory repre-
sentation, denoted AT (RG). An argumentation theory is a tuple hL, IR, nameiwhere
Lis a logical language (in our case simple propositional symbols and their negation).
IR is a set of defeasible inference rules of the form ϕ1, ..., ϕnϕ,n0, where
ϕ1, ..., ϕn, ϕ are from L. In case n= 0,ϕis equivalent to true ϕ, and de-
feasibly asserts ϕ. The intended meaning of a defeasible rule is that if one accepts all
antecedents/premises, then one must accept the consequent/conclusion unless there is
sufficient reason to reject it. Defeasible rules with empty premises, of the form ϕ,
are called assumptions.
Finally, name is a partial function that gives names to (some) defeasible rules in-
cluding assumptions. For convenience, we will write ϕ1, ..., ϕn
d
=ϕfor a defeasible
rule ϕ1, ..., ϕnϕwhose name is d.
6Henceforth, we will use Req,Defect and Ref as predicates in Prolog: variables (in italics)
match possible values, and underscores are wildcards. In logical formulas, wildcards are
existentially quantified anonymous variables.
A Requirements Refinement Calculus 9
Table 1. Mapping of Elements of Refinement Graphs to ASPIC+Argumentation Theory.
Element Type Refinement Graph Element ASPIC+Representation
requirement (g)Req(idg,txt )idg
=txt
defect (d)Defect(idd, , , IDdefective )idd
=⇒ ¬idgifor every idgiIDdefective
refinement (r)Ref(idr, , idd,IDreplace)VidgiIDreplace Req(idgi,txt i)txti
idr
=⇒ ¬idd
Fig. 3. Example of Construction of ASPIC+Arguments
Translation of Refinement Graphs to ASPIC+.The argumentation theory AT (RG) =
hLRG,IRRG,nameRGicorresponding to a refinement graph RG = hReq,Defect,Refi
is constructed as follows7:
The set of propositions Lcontains the elements of Text used in the graph, together
with the identifiers in RG, and their negations.
The set of defeasible rules of AT (RG) is constructed on the basis of requirements,
defects, and refinements of refinement graphs as described in Table 1.
Thus, the above formalization represents requirements and defects as antecedent-
free rules, while refinements have premises which are the requirements that the refine-
ment introduces.
Note that natural language statements of defects are not currently considered in
the translation to argumentation theories. The inclusion of these elements as well as
support/conflict relations between them represent future work.
Construction of Arguments and Attacks. ASPIC+constructs arguments that take the
form of inference trees. In our case, complex arguments start from leaves that are rules
with antecedent true, and are put together into larger ones by chaining with inference
rules. Due to space limitations, we do not present the rules of the construction of argu-
ments. Interested readers are referred to [17,18].
Fig. 3 depicts the arguments constructed on the basis of the refinement graph shown
in Fig. 2. The figure shows that all the requirements in the refinement graph correspond
to arguments {G0, G1, G2, G3, G4, G5, G6, G7}in the theory, and defects correspond
to {D0, D1, D2}. Refinements take the form of defeasible rules whose premises are
7When clear from the context, we will henceforth drop the subscript RG.
10 Y.ElRakaiby et al.
(non-initial) requirements. These lead to inference trees where the premises are the
leaves of the tree, as in {R0, R1, R2}. Notice the structure of every argument: it in-
cludes a set of sub-conclusions, a (proper) conclusion, and a set of defeasible rules. For
example, the sub-conclusions of argument R1are The app shall run on Android,The
app shall be delivered in 12 months, and ¬d01; the conclusion is ¬d01; and it has a
single defeasible rule r01.
Identification of Attacks. Given two ASPIC+arguments Aand B,Aattacks Bif one of
the conclusions of Aconflicts with (the name of) one of the defeasible rules of B. Note
that two formulas φand ψconflict if they are contradictory, i.e., if φ=¬ψor ψ=¬φ.
According to the previous definition, defects attack requirements that they point to,
whereas refinements attack defects that they address. So, for example, Fig. 3 shows that
defect D0attacks requirement G0, and then the refinement R0attacks the defect D0.
Construction of DAFs. The purpose of argument construction and attack identification
in ASPIC+is to enable the construction of a DAF.
We present the construction process by example here (for details, see [17]): start-
ing from the theory above, one obtains a DAF that can be represented graphically as in
Fig. 4, where nodes represent arguments, and edges represent attacks. One can easily
Fig. 4. DAF Example
see in the graph how arguments {D0, D1, D2}, representing defects, attack arguments
{G0, G1, G2}, representing requirements. Similarly, arguments {R0, R1, R2}, denot-
ing refinements, attack arguments {D0, D1, D2}, denoting defects.
Computation of DAF Extensions The computation of the extensions of a DAF enables
the determination of the acceptability of arguments, i.e., which arguments should be
accepted and which should not. The computation of extensions is based on the following
concepts and definitions.
A set Aof arguments is conflict-free if it does not include two arguments that attack
each other.
An argument ais acceptable w.r.t. to a set of arguments Aiff whenever ais attacked
by an argument bthen bmust be attacked by some element in A.
A set of arguments Ais admissible iff Ais conflict-free and every argument aA
is acceptable w.r.t. A.
A Requirements Refinement Calculus 11
A set of arguments is complete iff if is admissible and includes every argument a
that is acceptable w.r.t. to it.
In this paper, we are interested in the computation of the so-called complete extensions.
In the previous example, the only complete extension is the set {G0, G1, G2, G3, G4,
G5, G6, G7, R0, R1, R2}. In general, if a DAF graph is acyclic then it is guaranteed to
have a single complete extension. To avoid the complexity of multiple extensions, we
assume in this conference paper that the original requirements graph is acyclic.
In general, the acceptable requirements in a refinement graph RG, denoted by
AR(AT (RG)), will be the set of requirements appearing in the conclusions of the
arguments of its complete extension.
After the identification of acceptable arguments, we determine acceptable require-
ments by checking the ones that appear as conclusions of acceptable arguments. Thus,
we determine that all the requirements are acceptable since they are the conclusions of
arguments {G0,...,G7}.
3.4 Identification of Specification Sets
The acceptability of requirements only indicates that either they are free of defects or
their defects have been addressed. To determine the minimal sets of requirements neces-
sary to make the initial requirements acceptable, we compute the minimal specification
sets. In the following, suppose we are given a specific requirements graph RG =hReq,
Defect,Refi.
The initial requirements InitR are those that are not introduced by a refinement.
Formally, InitR={txt | ¬∃RF ,id .Ref( ,,,RF )id RF Req(id ,txt )}
The specification elements SpecE are the “leaves” of refinement graphs. More pre-
cisely, these requirement elements satisfy two conditions: (i) They have no defects other
than mMissing, and hence have not been further refined; the rationale for this is that
mMissing, in contrast to nonAtomic say, is dealt with by the add operator, which only
leads to the introduction of other new necessary requirements as opposed to its replace-
ment. This means that requirements found to be mMissing can still be leaves in refine-
ment trees , if they have no other defects. (ii) And the leaves have not been introduced
by a justify refinement, because those are (higher-level) goals.
Let a minimal set of requirements be a (minimal) subset of the requirements Req
that lead to the acceptance of the initial requirements. Formally, it is one of the sets
minimal w.r.t. set inclusion of the set RR, defined as follows:
RR = {R0|RG0=hR0,Fault,Refi R0Req InitR AR(AT (RG0))}
Intuitively, the set RR is the set of all subsets of the requirements proposed during
refinements that lead to the acceptance of the initial requirements. In the running ex-
ample, the sets {G3, G4, G5},{G2, G3, G4, G5}, and {G2, G3, G4, G5, G6}represent
some of the elements of RR. The minimal requirements sets are {G2, G3, G4}and
{G2, G5, G6, G7}. Finally, the specification sets,SS, are identified by taking the inter-
section of specification elements and minimal requirements, i.e., SS = {S| ∃R.R
RR ,S = (R SpecE)}. In the running example, the sets {G3, G4}and {G5, G6, G7}
represent the only specification sets.
3.5 Tool Description
We have implemented a prototype tool of the calculus. The tool aims at helping require-
ments engineers to systematically refine, negotiate, and document the requirements re-
12 Y.ElRakaiby et al.
finement process (in the form of a refinement graph). The tool also provides reasoning
support by determining the acceptability of requirements and computing the minimal
specifications. Due to space limitations, we only present a brief description of the tool
below. The tool, as well a description of the examples in this paper and use instructions,
can be downloaded at [19] (requires Java SE Development Kit 9 to run). The tool’s
input is a textual description of a refinement graph—a GUI is left as future work. An
Argumentation Theory Generator” module then generates an ASPIC+argumentation
theory for every possible configuration of requirements. A requirements configuration
is a subset of the requirements that could lead to the acceptance of the initial require-
ments. On the basis of these argumentation theories, an “ASPIC+module” identifies the
ASPIC+arguments, attacks, and generates a Dung Argumentation Framework (DAF).
A “DAF module” then determines the acceptability of abstract arguments by comput-
ing the complete extensions of the DAF. Finally, a “Compute Minimal Specifications”
module stores all (subsets of) requirements (RR) that make the initial requirements ac-
ceptable and determines the minimal specification sets (SS) by taking the intersection
of specification elements and minimal requirements (as explained in Sec. 3.4).
4 Related Work
Since requirements engineering is dialectical by nature, argumentation frameworks have
been previously used to formalise and support RE activities, including elicitation [20],
assessment [21,22,23], and regulatory compliance [24]. Some works focus on specific
RE issues, such as security [21,22], or requirements conflicts [25,26]. The spirit of our
work is analogous to the more comprehensive frameworks of Juret et al. [27], who sup-
port the definition of goal models through argumentation, and Mirbel & Villeta [15],
who manage requirements artifacts based on argumentation-theory.
Finally, RationalGRL [28,29] captures not only traditional GORE model refine-
ment, but also arguments about design decisions (e.g., “This refinement should be OR
rather than AND”), and the rationale behind them. RationalGRL also proposes argu-
mentation patterns to point out defects in goal models. Its laudable focus is making
goal models and their evolution understandable to RE users.
The main feature distinguishing our work from all of the above is the intention:
CaRE is an integrated calculus for deriving specifications from stakeholder require-
ments. Thus the defect types used by our framework are different and comprehensive,
as are refinement operators addressing each specific defect type. Moreover, CaRE pro-
poses its own unified representation (refinement graphs), with ASPIC+/AF only being
used to give CaRE semantics rather than being an overt part of the framework.
The only work we know of that offers a refinement calculus for the requirements
problem is the Desir´
ee proposal [14], which generalizes GORE approaches with a rich
set of operators for refinement and operationalization. The main differences between
CaRE and Desir´
ee are that CaRE (a) includes defects and defect types in its ontology,
which Desiree does not, (b) casts the refinement process as a dialectic argument among
stakeholders, and (c) gives a formal semantics of what does it mean for S to satisfy R
based on Argumentation Theory.
A Requirements Refinement Calculus 13
5 Conclusion
This paper presents a novel calculus for RE through which initial stakeholder require-
ments can be refined into specifications through a dialectic process. A major advantage
of our approach over existing proposals, notably GORE ones, is that it offers a com-
prehensive framework for introducing into the discussion the full range of defects rec-
ognized in RE standards, as opposed to the particular types considered so far. It also
makes all of the stakeholders active participants in the refinement process, as opposed
to traditional approaches where typically only the requirements analyst is responsible
for refining the requirements and building models.
CaRE refinement graphs capture a more complete view of the RE process. Signif-
icantly, they provide a conceptual model of the enactment of our requirements engi-
neering process. They offer excellent support for RE documentation, traceability, and
change management since new defects or refinements can be added to the graph mono-
tonically, without needing to revise its previous elements.
The semantics of the calculus is given in terms of argumentation theory, by defining
a mapping from refinement graphs to constructs of the ASPIC+argumentation frame-
work. Through this formalisation, we define what it means for a specification to make
initial requirements acceptable. In our proposal, the notion of satisfaction, typical of
earlier approaches, is replaced by the weaker notion of acceptability. Our contributions
include a Java implementation of a prototype tool for the calculus. A forthcoming paper
will show the connection of the argumentation theoretic semantics here to abduction in
an essentially propositional logic setting.
We have carried out a detailed scenario from the railway domain illustrating the el-
ements of our calculus and how they can be used to derive specifications from require-
ments8. We still need a preliminary assessment of CaRE on an industrial case-study,
and a consolidation assessment of domain experts using CaRE. Other future work in-
cludes adding further aspects of GORE ontologies (e.g., soft-goals, agents), and global
consistency conditions on requirements graphs (e.g., can gbe marked both tooStrong
and tooWeak by the same person?).
References
1. Ross, D.T.: Structured analysis (sa): A language for communicating ideas. IEEE TSE (1),
16–34 (1977)
2. Bubenko Jr, J.A.: Validation and verification aspects of information modeling. In: Pro.
VLDB, pp. 556–566 (1977)
3. Dardenne, A., van Lamsweerde, A., Fickas, S.: Goal-directed requirements acquisition. Sci.
Comput. Program. 20(1-2), 3–50 (1993)
4. Yu, E.S.: An organization modeling framework for information system requirements engi-
neering. In: Proc. Wkshp. Information Technologies and Systems (WITS’93), p. 9 (1993)
5. Elrakaiby, Y., Ferrari, A., Mylopoulos, J.: Care: A refinement calculus for requirements en-
gineering based on argumentation semantics. In: RE’08, pp. 364–369 (2018)
6. IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 830-1998
pp. 1–40 (1998)
8This is available in a technical report providing further details on the application of CaRE [19].
14 Y.ElRakaiby et al.
7. Iso/iec/ieee international standard - systems and software engineering – life cycle processes
–requirements engineering. ISO/IEC/IEEE 29148:2011(E) (2011)
8. Hunter, A., Nuseibeh, B.: Managing inconsistent specifications: reasoning, analysis, and ac-
tion. ACM Trans. Softw. Eng. Methodol. 7(4), 335–367 (1998)
9. van Lamsweerde, A.: Handling obstacles in goal-oriented requirements engineering. IEEE
TSE 26(10), 978–1005 (2000)
10. Jackson, M., Zave, P.: Deriving specifications from requirements: an example. In: ICSE’95,
pp. 15–15. IEEE (1995)
11. Hegel, G.W.F.: Ph´
’anomenologie des Geistes (1807)
12. Potts, C., Takahashi, K., Anton, A.I.: Inquiry-based requirements analysis. IEEE software
11(2), 21–32 (1994)
13. Dung, P.M.: On the acceptability of arguments and its fundamental role in nonmonotonic
reasoning, logic programming and n-person games. AI Journal 77(2), 321–357 (1995)
14. Li, F.L., Horkoff, J., Borgida, A., Guizzardi, G., Liu, L., Mylopoulos, J.: From stakeholder
requirements to formal specifications through refinement. In: REFSQ’15, pp. 164–180.
Springer (2015)
15. Mirbel, I., Villata, S.: Enhancing Goal-based Requirements Consistency : an Argumentation-
based Approach. In: Int. Work. Comput. Log. Multi-Agent Syst., pp. 110–127 (2012)
16. Caminada, M.: On the issue of reinstatement in argumentation. In: M.F. et al (ed.) Logics in
Artificial Intelligence, pp. 111–123. Springer (2006)
17. Modgil, S., Prakken, H.: The ASPIC+ framework for structured argumentation: a tutorial.
Argument Comput. 5, 31–62 (2014)
18. Caminada, M., Amgoud, L.: On the evaluation of argumentation formalisms. Artif. Intell.
171(5-6), 286–310 (2007)
19. CaRE Tech. Report (2020). URL https://doi.org/10.5281/zenodo.3856402
20. Elrakaiby, Y., Ferrari, A., Spoletini, P., Gnesi, S., Nuseibeh, B.: Using argumentation to ex-
plain ambiguity in requirements elicitation interviews. In: RE’17, pp. 51–60. IEEE (2017)
21. Haley, C.B., Laney, R., Moffett, J.D., Nuseibeh, B.: Security requirements engineering: A
framework for representation and analysis. TSE 34(1), 133–153 (2008)
22. Franqueira, V.N.L., Tun, T.T., Yu, Y., Wieringa, R., Nuseibeh, B.: Risk and argument: A
risk-based argumentation method for practical security. In: RE 2011, pp. 239–248 (2011)
23. Jureta, I.J., Mylopoulos, J., Faulkner, S.: Analysis of multi-party agreement in requirements
validation. In: RE’09, pp. 57–66 (2009)
24. Ingolfo, S., Siena, A., Mylopoulos, J., Susi, A., Perini, A.: Arguing regulatory compliance
of software requirements. DKE 87, 279–296 (2013)
25. Bagheri, E., Ensan, F.: Consolidating Multiple Requirement Specifications Through Argu-
mentation. ACM SAC pp. 659–666 (2011)
26. Murukannaiah, P.K., Kalia, A.K., Telangy, P.R., Singh, M.P.: Resolving goal conflicts via
argumentation-based analysis of competing hypotheses. In: Proc. RE’15, pp. 156–165 (2015)
27. Jureta, I.J., Faulkner, S., Schobbens, P.Y.: Clear justification of modeling decisions for goal-
oriented requirements engineering. Requirements Engineering 13(2), 87 (2008)
28. van Zee, M., Bex, F., Ghanavati, S.: Rationalization of goal models in GRL using formal
argumentation. In: Proc. RE’15, pp. 220–225. IEEE Computer Society (2015)
29. van Zee, M., Marosin, D., Bex, F., Ghanavati, S.: RationalGRL: A framework for rationaliz-
ing goal models using argument diagrams. In: Proc. ER’16, pp. 553–560. Springer (2016)
Article
Full-text available
The Requirements Engineering (RE) process starts with initial requirements elicited from stakeholders—however conflicting, unattainable, incomplete and ambiguous—and successively refines them until a consistent, complete, valid, and unambiguous specification is reached. This is achieved by balancing stakeholders’ viewpoints and preferences to reach compromises through negotiation. Several frameworks have been developed to support this process in a structured way, such as KAOS, i*, and RationalGLR. However, none provides the means to model the dialectic negotiation inherent to the RE process, so that the derivation of specifications from requirements is fully explicit and traceable. To address this gap, we propose CaRE, a refinement calculus for requirements engineering based on argumentation theory. CaRE casts the RE refinement problem as an iterative argument between all relevant stakeholders, who point out defects (ambiguity, incompleteness, etc.) of existing requirements, and then propose suitable refinements to address them, thereby leading to the construction of a refinement graph. This graph is then a conceptual model of the RE process. The semantics of refinement graphs is provided using Argumentation Theory, enabling reasoning over the RE process and the automatic computation of software specifications. An alternate semantics is also presented based on abduction and using Horn Theory. The application of CaRE is showcased with an extensive example from the railway domain, and a prototype tool for identifying specifications in a refinement graph is presented.
Conference Paper
Full-text available
The requirements problem consists of transforming stakeholder requirements-however informal, ambiguous, conflicting , unattainable, imprecise and incomplete-into a consistent , complete and realizable specification through a systematic process. We propose a refinement calculus for requirements engineering (CaRE) for solving this problem, which takes into account the typically dialectic nature of requirements activities. The calculus casts the requirement problem as an iterative argument between stakeholders and requirements engineers, where posited requirements are attacked for being ambiguous, incomplete, etc. and refined into new requirements that address the defect pointed out by the attack. Refinements are carried out by operators provided by CaRE that refine (e.g., strengthen, weaken, decompose) existing requirements, to build a refinement graph. The semantics of the operators is provided by means of argumentation theory. Examples are given to illustrate the elements of our proposal.
Conference Paper
Full-text available
The requirements elicitation process often starts with an interview between a customer and a requirements analyst. During these interviews, ambiguities in the dialogic discourse may reveal the presence of tacit knowledge that needs to be made explicit. It is therefore important to understand the nature of ambiguities in interviews and to provide analysts with cognitive tools to identify and alleviate ambiguities. Ambiguities perceived by analysts are sometimes triggered by specific categories of terms used by the customer such as pronouns, quantifiers, and vague or under-specified terms. However, many of the ambiguities that arise in practice cannot be rooted in single terms. Rather, entire fragments of speech and their relation to the mental state of the analyst need to be considered.In this paper, we show that particular types of ambiguities can be characterised by means of argumentation theory. Argumentation is the study of how conclusions can be reached through logical reasoning. In an argumentation theory, statements are represented as arguments, and conflict relations among statements are represented as attacks. Based on a set of ambiguous fragments extracted from interviews, we define a model of the mental state of the analyst during an interview and translate it into an argumentation theory. Then, we show that many of the ambiguities can be characterized in terms of 'attacks' on arguments. The main novelty of this work is in addressing the problem of explaining fragment-level ambiguities in requirements elicitation interviews through the formal modeling of the analyst's mental model using argumentation theory. Our contribution provides a data-grounded, theoretical basis to have a more complete understanding of the ambiguity phenomenon, and lays the foundations to design intelligent computer-based agents that are able to automatically identify ambiguities.
Conference Paper
Full-text available
A stakeholder's beliefs influence his or her goals. However, a stakeholder's beliefs may not be consistent with the goals of all stakeholders of a system being constructed. Such belief-goal inconsistencies could manifest themselves as conflicting goals of the system to be. We propose Arg-ACH, a novel approach for capturing inconsistencies between stakeholders' goals and beliefs, and resolving goal conflicts. Arg-ACH employs a hybrid of (1) the analysis of competing hypotheses (ACH), a structured analytic technique, for systematically eliciting stake-holders' goals and beliefs, and (2) rational argumentation for determining belief-goal inconsistencies to resolve conflicts. Arg-ACH treats conflicting goals as hypotheses that compete with each other and the winning hypothesis as a goal of the system to be. Arg-ACH systematically captures the trail of a requirements engineer's thought process in resolving conflicts. We evaluated Arg-ACH via a study in which 20 subjects applied Arg-ACH or ACH to resolve goal conflicts in a so-ciotechnical system concerning national security. We found that Arg-ACH is superior to ACH with respect to completeness and coverage of belief search; length of belief chaining; ease of use; explicitness of the assumptions made; and repeatability of conclusions across subjects. Not surprisingly, Arg-ACH required more time than ACH: although this is justified by improvements in quality, the gap could be reduced through better tooling.
Conference Paper
Full-text available
[Context and motivation] Stakeholder requirements are notoriously informal, vague, ambiguous and often unattainable. The requirements engineering problem is to formalize these requirements and then transform them through a systematic process into a formal specification that can be handed over to designers for downstream development. [Question/problem] This paper proposes a framework for transforming informal requirements to formal ones, and then to a specification. [Principal ideas/results] The framework consists of an ontology of requirements, a formal requirements modeling language for representing both functional and non-functional requirements, as well as a rich set of refinement operators whereby requirements are incrementally transformed into a formal, practically satisfiable and measurable specification. [Contributions] Our proposal includes a systematic, tool-supported methodology for conducting this transformation. For evaluation, we have applied our framework to a public requirements dataset. The results of our evaluation suggest that our ontology and modeling language are adequate for capturing requirements, and our methodology is effective in handling requirements in practice.
Conference Paper
Goal modeling languages, such as i* and the Goal-oriented Requirements Language (GRL), capture and analyze high-level goals and their relationships with lower level goals and tasks. However, in such models, the rationalization behind these goals and tasks and the selection of alternatives are usually left implicit. To better integrate goal models and their rationalization, we develop the RationalGRL framework, in which argument diagrams can be mapped to goal models. Moreover, we integrate the result of the evaluation of arguments and their counterarguments with GRL initial satisfaction values. We develop an interface between the argument web tools OVA and TOAST and the Eclipse-based tool for GRL called jUCMNav. We demonstrate our methodology with a case study from the Schiphol Group.
Conference Paper
Requirements engineering research has for long recognized the leading role of goals as requirement artifacts during the requirements engineering specification processes. Given the large number of artifacts created during the requirements specification and the continuous evolution of these artifacts, reasoning about them remains a challenging task. Moreover, the rising complexity of the target domain under consideration during the requirements engineering process as well as the growth of geographically distributed projects explain why the number of collected requirements as well as their complexity also increase. In this context, providing support to stakeholders in achieving a common understanding of a set of goal-based requirements, in consolidating them and keeping them consistent over time is another challenging task. In this paper, we propose an approach to detect consistent sets of goal-based requirements and maintain their consistency over time. Our approach relies on argumentation theory which allows to detect the conflicts among elements called arguments. In particular, we rely on meta-argumentation, which instantiates abstract argumentation frameworks, where requirements are represented as arguments and the standard Dung-like argumentation framework is extended with additional relations between goal-based requirements.
Article
This article gives a tutorial introduction to the ASPIC + framework for structured argumentation. The philosophical and conceptual underpinnings of ASPIC + are discussed, the main definitions are illustrated with examples and several ways are discussed to instantiate the framework and to reconstruct other approaches as special cases of the framework. The ASPIC + framework is based on two ideas: the first is that conflicts between arguments are often resolved with explicit preferences, and the second is that arguments are built with two kinds of inference rules: strict, or deductive rules, whose premises guarantee their conclusion, and defeasible rules, whose premises only create a presumption in favour of their conclusion. Accordingly, arguments can in ASPIC + be attacked in three ways: on their uncertain premises, or on their defeasible inferences, or on the conclusions of their defeasible inferences. ASPIC + is not a system but a framework for specifying systems. A main objective of the study of the ASPIC + framework is to identify conditions under which instantiations of the framework satisfy logical consistency and closure properties.
Article
A software system complies with a regulation if its operation is consistent with the regulation under all circumstances. The importance of regulatory compliance for software systems has been growing, as regulations are increasingly impacting both the functional and non-functional requirements of legacy and new systems. HIPAA and SOX are recent examples of laws with broad impact on software systems, as attested by the billions of dollars spent in the US alone on compliance. In this paper we propose a framework for establishing regulatory compliance for a given set of software requirements. The framework assumes as inputs models of the requirements (expressed in i*) and the regulations (expressed in Nòmos). In addition, we adopt and integrate with i* and Nòmos a modeling technique for capturing arguments and establishing their acceptability. Given these, the framework proposes a systematic process for revising the requirements, and arguing through a discussion among stakeholders that the revisions make the requirements compliant. A pilot industrial case study involving fragments of the Italian regulation on privacy for Electronic Health Records provides preliminary evidence of the framework's adequacy and indicates directions for further improvements.