Reasoning with Optional and Preferred
Requirements
Neil A. Ernst1, John Mylopoulos1, Alex Borgida2 and Ivan J. Jureta3
1 Department of Computer Science
University of Toronto
fnernst,jmg@cs.toronto.edu
2 Department of Computer Science
Rutgers University
borgida@cs.rutgers.edu
3 FNRS & Information Management
University of Namur
ijureta@fundp.ac.be
Abstract. Of particular concern in requirements engineering is the se-
lection of requirements to implement in the next release of a system. To
that end, there has been recent work on multi-objective optimization and
user-driven prioritization to support the analysis of requirements trade-
os. Such work has focused on simple, linear models of requirements;
in this paper, we work with large models of interacting requirements.
We present techniques for selecting sets of solutions to a requirements
problem consisting of compulsory and secondary goals, with preferences
among them. To nd solutions, we use a modied version of the frame-
work from Sebastiani et al. [24] to label our requirements goal models.
For our framework to apply on a problem, no numeric valuations are
necessary, as the language is qualitative. We conclude by introducing a
local search technique for navigating the exponential solution space. The
algorithm is scalable and approximates the results of a naive algorithm.
1 Introduction
Requirements modeling languages have been part of the very core of Require-
ments Engineering (RE) research since the days of SADT [22], with KAOS [5],
i* [28], and others. Every requirements modeling language is grounded in an on-
tology of requirements. Such an ontology consists of a set of primitive concepts in
terms of which requirements can be elicited, modelled, and analyzed. Tradition-
ally, requirements were viewed as functions the system-to-be ought to support.
This view is re
ected in SADT and other structured analysis techniques of the
1970s and 1980s. Recently, an intentional perspective on requirements, Goal-
Oriented Requirements Engineering (GORE), has gained ground. Requirements
are now viewed as stakeholder goals representing the intended purposes for the
system-to-be. This deceptively small shift in the underlying ontology for require-
ments has had tremendous impact on RE research and is beginning to be felt in
RE practice [14].

The objective of this paper is to propose an extension to the goal-oriented
modelling and analysis framework in order to scalably accommodate priorities
in the form of secondary goals (\nice-to-have" requirements) and preferences
(\requirement A is preferred over requirement B"). The extension is much needed
to align RE theory with RE practice, where optionality and prioritization have
been routinely used to manage requirements [23].
This paper makes the following contributions:
{ An extension of the qualitative goal modeling framework of Sebastiani et
al. [24], supporting stakeholder preferences and secondary requirements.
{ Macro operators for managing the scale of the possible problem and solution
spaces.
{ Algorithms to generate and compare all possible solutions.
{ A local search algorithm to eciently nd solutions in a complex require-
ments model.
{ A case study showing these concepts working on a problem at reasonable
scale.
In this paper we make reference to the requirements problem. Our objective
is to (eciently) nd solutions to a given requirements problem. According to
[12], a solution to the requirements problem is a combination of tasks and do-
main assumptions. This combination must ensure that the execution of the tasks
under the domain assumptions satises all compulsory goals, and zero or more
secondary goals. This paper looks at how this might be done, and in particular,
done eciently.
We start by introducing the requirements modeling language that serves to
dene a requirements problem for a system of interest. The language is built on
top of a sound and complete formal logic. We begin by sorting its propositions
and well-formed formulas (ws), and then adding extra-logical constructs used
to indicate two things. One, which ws are preferred over others; two, for which
ws is satisfaction secondary to the satisfaction of compulsory ws. Preference
and optionality are extra-logical in the sense that they serve in algorithms but are
not dened within the logic. We then study the implications of adding preference
and optionality when searching for solutions to the requirements problems. We
dene what we mean by `secondary' goals below.
1.1 Case study: Enterprise strategy for portals
Figures 1 and 2 present a subset of the case study we use throughout the paper.
We show how the model and the reasoning techniques can be used to model a real
life setting concerning enterprise web portal development (ESP). We base our
scenario on the documentation that the provincial Ministry of Government Ser-
vices of Ontario (Canada) (MGS) provides, specically on the description of the
content management requirements. This is a series of reports from a 2003 project
to re-work the provincial government's enterprise-wide citizen access portals, as
part of an e-Government initiative. The content management requirements detail

Maintainability
Support
platform
requirements
Component-
Based
Development
support a
layered
arch
User Profile
Information
Support
profile
access
UTF-8
Multi-
browser
Support
minimally
support IE 5
Netscape 4.7+
Authentication
X.509
Support
Content
Authoring
Web
Accessibil
ity
Conform to
W3C
Accessibility
Guidelines
Centralized
templates
Create
new
templates
Support
extras
Thesaurus
Support
Security
Usability
Portability
Accessibility
+
-
+
+
+
--
--
--
AND
AND
OR
OR
OR
AND
OR
OR
OR
OR
AND
AND
AND
AND
AND
AND
AND
Support
government-wide
portal technology
Fig. 1. A partial QGM model of the case study (1.1).
the specic technical aspects such a portal would have to meet4. Our extended
model contains 231 goals and several hundred relationships. This is the same
size as real-world problems modeled with KAOS [15, p. 248].
2 pQGM: Extending qualitative goal models with
preferences and optionality
Goal modeling is a widely accepted methodology for modeling requirements (cf.
[14]). We leverage the qualitative goal modeling framework, which we call `QGM',
as dened in Sebastiani et al. [24]. That paper denes an axiomatization of goal
models that transforms the goal labeling problem into a boolean satisability
(SAT) problem (leveraging the power of o-the-shelf SAT solvers). The goal la-
beling problem, as stated in that paper, is \to know if there is a label assignment
for leaf nodes of a goal graph that satises/denies all root goals [24, p. 21]". This
approach can be used, among others, to nd what top-level goals can be achieved
by some set of leaf goals/tasks ("forward"), or conversely, given some top-level
goals which are mandated to be True, what combination of tasks will achieve
them ("backward"). The framework is however fully general, so that one can
4 available at http://www.mgs.gov.on.ca/en/IAndIT/158445.html

give an initial specication that indicates any set of goals as being mandated or
denied, and solutions are consistent labelings of all the nodes in the r-net. Input
goals serve as parameters for a given evaluation scenario. Thus a solution to the
requirements problem amounts to answering the question: given the input goals,
can we satisfy the compulsory goals?
We brie
y recapitulate the denitions introduced in [8, 24]. We work with
sets of goal nodes Gi, and relations Ri  }GG.
Relations have sorts Decomposition: fand, org, which are (n + 1)-ary rela-
tions; and Contributions f+s,++s,+d,++d,-s,--s,-d,--d,++,+,--,-g, which are
binary. A goal graph is a pair hG;Ri where G is a set of goal nodes and R is a
set of goal relations, subject to the following restrictions:
{ each goal has at most one incoming boolean relation;
{ every loop contains at least one non-boolean relation arc.
Truth predicates are introduced, representing the degree of evidence for the sat-
isfaction of a goal: PS(G); FS(G); PD(G); FD(G), denoting (F)ull or (P)artial
evidence of (S)atisfaction or (D)enial for G. A total order on satisfaction (resp.
denial) is introduced as FS(G)  PS(G)  > (no evidence). This permits
an axiomatization of this graphical model into propositional logic, such that
the statement \A contributes some positive evidence to the satisfaction of B",
represented A
+s
7! B becomes the axiom PS(a)! PS(b). The complete axiom-
atization from which this section is derived is available in [24]. In QGM, there
are no soft goals as separate sorts, but goals with no decompositions and incom-
ing contributions can be considered `soft', in the traditional GORE sense of the
term (cf. [4]).
Extra-logical extensions. To manage preferences and secondary elements, we
add extra-logical elements to QGM. These elements do not aect the evaluation
of admissible solutions (i.e., whether there is a satisfying assignment), thus our
use of the term \extra-logical". We call our extension prioritized Qualitative
Goal Models (pQGM). Models in this language form requirements nets (r-nets).
pQGM r-nets allow us to capture stakeholder attitudes on elements in the model.
Attitudes (i.e., emotions, feelings, and moods) are captured via optionality and
preference relationships.
Optionality is an attribute of any concept indicating its secondary or com-
pulsory status. Being secondary means that, although a solution does not have
to satisfy this goal in order to be acceptable, solutions that do satisfy it are
more desirable than those which do not, all else being equal. Being compulsory
means that the element in question must be fully satised in any solution (in the
QGM formalization, the element in question must be fully satised (FS) and
not partially denied (:PD)). We consider non-functional requirements (NFRs)
like Usability to be ideal candidates for being considered secondary goals: if not
achieved, the system still functions, but achievement is desirable if possible.
Alternatives arise when there is more than one possible solution of the prob-
lem (i.e., more than one possible satisfying assignment). In goal models with de-
composition, this typically occurs when there is an OR-decomposition. We treat
each branch of the OR-decomposition as a separate alternative solution to the

requirements problem. Note that for very small numbers of OR-decompositions
we generate exponentially many alternatives.
Preferences are binary relationships dened between individual elements in
an r-net. A preference relationship compares concepts in terms of desirability.
A preference from a goal to another goal in a pQGM r-net indicates that the
former is strictly preferred to the latter. Preferences are used to select between
alternatives.
We illustrate the role of these language elements in the sections which follow.
3 Finding requirements solutions
The purpose of creating a pQGM model is to use it to nd solutions to the
requirements problem it denes. We now dene a procedure to identify these
solutions. Brie
y, we identify admissible models (`possible solutions'); satisfy as
many secondary requirements as we can; identify alternatives; then lter the set
of alternatives using user-expressed preferences. We give both a naive and a local
search algorithm for this process.
What are the questions that pQGM can answer? We want to know whether,
for the compulsory goals we dened { typically the top-level goals as these are
most general { there is some set of input nodes which can satisfy them. Fur-
thermore, we want these sets of inputs to be strictly preferred to other possible
sets, and include as many options as possible. We show some answers to these
questions in Section 4, below. With respect to the pQGM model shown in Fig. 2,
a dominant solution (stippled nodes) consists of the goals Support government-
wide portal technology, Support Content Authoring, Web Accessibility, Conform
to W3C Accessibility Guidelines, Support platform requirements, Authentication,
X.509, User Prole Information, Support prole access, UTF-8, Accessibility,
Security, Portability. Goals such as Minimally support IE5 are alternatives that
are dominated, and therefore not included (in this case, because they break the
Usability option). Deriving this is the focus of the remainder of the paper.
3.1 Identifying admissible models
Our rst step is to nd satisfying label assignments to the model elements. We
rely on the solution to the backwards propagation problem of [24]. We take an
attitude-free r-net R (attitude-free meaning one without secondary elements,
edges leading to/from them, and without considering preferences), and label
the model. The labeling procedure encodes the user's desired output values
(outval), the model conguration (graph) and the backwards search axiomati-
zation backward (cf. [24, p.8]). The output of this is a satisfying truth assignment
 or None, if there is no assignment. If there was a satisfying assignment, we say
our attitude-free model R is admissible, as our compulsory nodes were satised,
and we call the resulting labeled goal model Rm.

Maintainability
Support
platform
requirements
Component-
Based
Development
support a
layered
arch
User Profile
Information
Support
profile
access
support
UTF-8
Multi-
browser
Support
minimally
support IE 5
Netscape 4.7+
Authentication
support
X.509
Support
Content
Authoring
Web
Accessibil
ity
Conform to
W3C
Accessibility
Guidelines
Centralized
templates
Create
new
templates
Support
extras
Thesaurus
Support
Security
Usability
Portability
Accessibility
+
-
+
+
+
--
p
p
p
--
--
AND
AND
OR
OR
OR
AND
OR
OR
OR
OR
AND
AND
AND
AND
AND
AND
AND
Support
government-wide
portal technology
C
C
Fig. 2. An example pQGM r-net. Options have dashed outlines and compulsory el-
ements are labeled `C'. Preferences are represented with `p' arcs on double-headed
arrows. R consists of the elements outlined in solid borders and S the stippled ele-
ments (a possible solution).
3.2 Satisfying secondary requirements
We now turn to consideration of the secondary goals of our initial r-net R. In our
diagrams, a node is marked secondary by having dashed outlines. (This could
of course be formalized by using a meta-predicate O.) Although a solution does
not have to satisfy such a goal in order to be admissible, solutions that do satisfy
it are more desirable than ones that do not, all else being equal. For example,
in Fig. 2, we would prefer to satisfy all the dashed nodes (Conform to W3C
accessibility guidelines, etc.). However, the use of secondary goals allows us to
accept solutions which only satisfy some of these nodes.
Consider the example in Fig. 2. In this example we have NFR Usability and
some concepts which can satisfy the goal. The model indicates that the top-level
NFRs are secondary; by specication, our algorithm should nd the maximal sets
of secondary elements that can be added to the compulsory ones while preserving
admissibility. It is important to note that in our framework secondary elements
can interact. This means that adding a secondary goal to Rm could render a) the

Input: A solution Rm and a set of secondary goals, O
Output: All maximal admissible option sets that can be added to Rm
Om ; foreach input 2 }(O) do
// in a traversal of sets in non-increasing size
value admissible(input [Rm) if value == T then
Om inputRemove subsets of input
end
end
return Om
Algorithm 1: NaiveSelect
new model inadmissible b) previously admissible secondary goals inadmissible.
This re
ects the notion that introducing a secondary goal has consequences.
Option identication. We describe our nave implementation in Algorithm
1. We are given an admissible R-net, Rm, e.g., a set of compulsory goals, along
with a map, T , from elements of Rm to the set of label assignments for Rm. We
are given a set, O, the set of secondary elements, with O [ Rm = R. In our
example, O is equal to the set of goals culminating in Usability.
For each subset input of O (i.e., element of }(O)), with the exception of the
empty set, add it to Rm, the admissible solution. We then use the SAT solver to
nd a satisfying assignment, checking for admissibility. If we nd an admissible
solution (an option set O such that O[Rm is admissible), we can add this to our
set of acceptable solutions, Sa. Now, because of the order in which we traverse
subsets, this solution is a maximal set, and the proper subsets of O contain
fewer secondary goals. We therefore remove these sets from the collection being
traversed.
The running time of this naive approach is clearly inpractical since in the
worst-case, we must check all 2n subsets of the set }(O), where n is the number
of secondary elements. (The worst-case could arise if all secondary goals inval-
idate all other secondary goals.) This is on top of the complexity of each SAT
test! Furthermore, the result set might be quite large. We therefore show some
mechanisms for improving this.
Pruning the set of secondary goals. We introduce two further ways to
reduce the number of option sets the naive algorithm nds. We use one approach
to prune the initial sets of secondary goals, and another to reduce the admissible
option set presented to the user.
Our rst approach is to dene simple operations over secondary goals. We
dene operators on }(O) that act as constraints. Each element (a set) in }(O)
has two variables, cardinality and membership. We allow constraints on op-
tion set cardinality (boolean inequalities), and option set membership (inclu-
sion or exclusion). An equivalent expression in SQL might be REMOVE FROM
secondary WHERE secondary.Size < x and REMOVE FROM secondary WHERE
x IN secondary.

Input: solution Rm, set of options O, time limit tlim, tabu expiration expire
Output: A locally optimal set of optionsets Ot
while time < tlim and candidate 62 tabu list do
Ot = Ot + TabuMove(;, O, Ot, tabu, time)if time % expire  1 then
tabu ;
end
end
foreach o0; o00 2 Ot do
if o0  o00 then
Ot - o
end
end
Algorithm 2: TabuSearch
Our second approach is to make use of pQGM's preference relations to
remove option sets which are dominated by other sets. In our example, with
P =f(Authentication, Component-based development), (Security,Usability)g, if
we found admissible solutions S1 containing fSecurity, Authenticationg, and S2
containing f(Component-based development)g, we would discard S2 in the case
where both are admissible. This makes use of the Dominate function we dene
in Section 3.4.
Section 4 shows the success of these techniques in reducing model evaluation
times.
Local search. The naive approach must search through each member of the
set of possible options, an exponential worst-case running time. This is clearly
infeasible for is to dene a local search algorithm to nd, in a bounded amount
of time, a local optimal solution. We implemented Tabu search [9] (Algorithms
2 and 3).
The algorithm iteratively searches for improvements to the cardinality of an
admissible optionset. We start with a randomly chosen option, and add (random)
remaining options singly, checking for admissibility. If we reach a point where no
admissible options are found, we preserve the best result and randomly restart.
A tabu list prevents the searcher from re-tracing steps to the same point it just
found. A tabu tenure details for how many moves that point will be considered
tabu. One commonly lists the last few moves as tabu. An iteration limit ensures
the algorithm terminates. IsAdmissible represents a call to the SAT solver with
the given optionset merged with the existing admissible solution, R. Although it
is not necessarily the case that there are single options which are admissible, in
practice this is common. If this isn't the case, our algorithm performs a random
search, beginning with 1-sets of options.

Input: candidate, remainder, solution, tabu, time
Output: solution
step = 0 while step < radius do
tmp = candidateselected = Random.Choice(remainder)tmp = tmp +
selected step = step + 1 if selected 62 tabu list and tmp 62 solution then
break
end
end
if length(candidate) == initial then
solution = solution + candidate return solution // base case
end
remainder = remainder - selected candidate = candidate + selected if time >
tlim then
return solution
end
time = time + 1 if IsAdmissible(candidate) then
solution = solution + TabuMove(candidate, remainder)
end
else
candidate = candidate - selected tabu list = tabu list + selected remainder
= remainder + selected solution = solution + TabuMove(candidate,
remainder)
end
return solution
Algorithm 3: TabuMove
3.3 Identify solution alternatives
For comparison purposes, our example model with 231 non-secondary nodes and
236 relations is translated into a SAT expression consisting of 1762 CNF clauses.
This is well within the limits of SAT solvers.
The input into our penultimate phase consists of the admissible, labeled r-net
Rm, along with a set, possibly empty, of option sets that can be joined to that
r-net, O. The number of current solutions, then, is the size of O+1.
The goal of this phase is to identify alternatives that are created at disjunc-
tions in the model. We do this by converting each admissible solution s 2 S :
Rm[ O 2 O to a boolean formula (a traversal of the AND-OR graph), and then
converting this formula to conjunctive normal form. This is the accepted format
for satisability checking (SAT). We pass this representation of the r-net as the
SAT formula  to a SAT solver, store, then negate the resulting satisability
model  and add it as a conjunct to . We repeat this process until the result
is no longer satisable (enumerating all satisfying assignments). This produces
a set of possible alternative solutions, e.g. i; i+1; ::; n. We convert this to a
set of sets of concepts that are solutions, Sa.

3.4 Solution selection
Our nal step is to prune the sets of solution r-nets, Sa, using stakeholder valua-
tions over individual elements { expressed as preferences and (possibly) costs. We
do not prune before nding secondary goals since we might discard a dominated
set in favour of one that is ultimately inadmissible. Similarly, we do not risk
the possibility of discarding an optionset that is nonetheless strictly preferred to
another set, since by denition, if set O0 is admissible and yet not selected, there
was a set O  O0 that contains the same elements (and therefore preferences)
and was admissible.
Selection using preferences. We will use in the text the notation p > q if
the r-net indicates that node p is preferred to node q, and let  be the transitive
re
exive closure of >.
We use this to dene the function Dominate(M,N), mapping S x S to
booleans as follows:
Dominate(M;N) = True () 8n 2 N:9m 2M : m  n
Intuitively, every element of a dominated set is equal to a value in the dom-
inant one, or is (transitively) less preferred. Note that the dominates relation
is a partial order, and we can therefore once again choose maximal elements
according to it.
Selection using cost. Although not shown in the case study, our framework
provides for solution selection using a simple cost operator, where such numbers
are available. Clearly there are many such dimensions to consider. For a given
cost function, we dene a min cost(value, increment) function which ranks the
proposed solutions using the cost of the solution as a total ordering. The mean-
ing of value is as an upper cost threshold (`return all solutions below value'),
and increment as a relaxation step in the case where no solutions fall under the
threshold. Note that we are ranking admissible solutions, and not just require-
ments.
4 Evaluation
We now present experimental results of our technique on our large goal model
presented in Section 1.1. Our ESP model contains 231 non-secondary nodes and
236 relations.
We demonstrate the utility and scalability of our technique by presenting
evaluation results for this model in various congurations of options, using dif-
ferent pre-processing steps to reduce the problem scale (Table 1). The rst row
of results re
ects the raw time it takes to evaluate this particular model with
no options (using the SAT solver). The third column shows that adding the set
cardinality heuristic (a call to Naive with a maximal set size of 8 and minimal

size of 5), results in some improvement in running times. For example, with 15
options, the running time is approximately 30% shorter (while returning the
same options, in this case). Similarly, while we note the exponential increase in
evaluation time for our naive algorithm, TabuSearch clearly follows a linear
trend. However, the tradeo is that TabuSearch misses some of the solutions,
although in our tests, assuming an average-case model conguration, it found
half of the maximal sets of options.
Table 1. Comparing nave vs. heuristic option selection. The fth column represents
the number of calls to the SAT solver; the last column indicates how many solutions the
local search found: max, the number of maximal sets, sub the remaining non-optimal
sets. We used a time step limit of 400.
Options Naive Naive(8,5) TabuSearch # calls solns
0 0.062 s { { { {
4 0.99 - 0.08s 2800 all
6 3.97 { 0.11 2800 1 max, 1 sub
9 31.8 23.6s 0.14 2942 1 max, 2 sub
12 4m23s 3m6s 0.16 3050 1 max, 2 sub
15 33m 21m 0.18 3165 1 max, 2 sub
20 - - 0.19 3430 1 max, 2 sub
Quality of solutions. While the naive approach returns all solutions (the
Pareto-front of non-dominated solutions) the Tabu search heuristic will only re-
turn an approximation of this frontier. TabuSearch returned, in the case with
15 options, one maximal set (of two), and 2 subsets. This in turn aected the
number of alternatives that were found. Using the naive approach with 15 op-
tions, we identied 7 dominant solutions and 8 other alternatives (unrelated via
preferences). Using TabuSearch, with the smaller option sets, we only return
4 dominant solutions and 6 other alternatives. These are individual solutions;
we permit combinations, so the total number is much higher (the powerset).
However, we feel the greatly reduced running time will allow for more model
exploration than the naive approach.
5 Related work
We focus our comparison on the process of deriving a high-level solution from
an initial model.
Tropos [3] uses the syntax of i* to generate early requirements models that
are then the source for eventual derivation of a multi-agent system design. The
`early requirements' phase generates goal models using the notions of decompo-
sition, means-ends and contribution links. These three notions bear no semantic
distinction in the eventual reasoning procedure: they all propagate truth values.
Partial satisfaction (denial) of stakeholder goals is modeled with the qualitative

`positive contribution' (denial) links, allowing goals to be partially satised (de-
nied). While this is used to model preference, it is not clear what to make of
a partially satised goal (with respect to preference). Although formalized (in
[24] and others), the reasoning still relies on stakeholder intervention to evaluate
how `well' a solution satises the qualities (e.g., is it preferable that security is
partially satised while usability is partially denied?). From [3, p. 226]: \These
[non-deterministic decision points] are the points where the designers of the soft-
ware system will use their creative [sic] in designing the system-to-be."
KAOS [5] uses a graphical syntax backed by temporal logic. KAOS has a
strong methodological bent, focusing on the transition from acquisition to spec-
ication. It is goal-oriented, and describes top-down decomposition into opera-
tionalized requirements which are assigned to actors in the system-to-be. Alter-
native designs can be evaluated using OR decompositions as in Tropos. In [18],
a quantitative, probabilistic framework is introduced to assign partial satisfac-
tion levels to goals in KAOS, which allows tradeos to be analyzed, provided
the quantication is accurate. The notion of gauge variables is hinted at in [16],
which seem to be measures attached to goal achievement. Obstacle analysis [17]
provides a mechanism to identify risks to normal system design.
In [20], we dened constraints over temporal characteristics of admissible
behavior using AND/OR goal trees and prior work on variability. This paper
gives a clearer denition of what requirements solutions should look like, in
particular with reference to NFRs. This work also proposes a more expressive
language for dening secondary requirements. However, that work had a much
more expressive preference language.
Variability models [19] allow one to dene, e.g., product lines or congu-
rations, so in a sense they provide multiple solutions. However, these models
explicitly specify when and how the alternatives come into eect. One cannot
have multiple solutions for one scenario.
Work in the AI area of planning overlaps with this as well. Hierarchical
task networks (HTNs), for example, describe at the high-level general tasks to
accomplish, decomposing these into, eventually, specic actions executable in the
world. What is interesting for our purposes is work on nding preferred plans [25],
where it is important to nd an optimal set of tasks in the HTN according to
an expressive preference language. Plans (or `solutions', in our terminology) are
metricized to re
ect how well they achieve the set of preferences.
There are several techniques that can be used to generate pairwise preferences
over lists of requirements, surveyed in [13, 10]. These included iterative pairwise
comparisons, economic valuations, and planning games. Here, all requirements
are assumed to be achievable and there are no interactions between them. This
is a very simple model of requirements. For example, what if one requirement is
blocked if another is implemented? Or if there is a trade-o analysis required?
The QGM implementation in [24] describes a variant using a minweight SAT
solver; weights are assigned using qualitative labels. It searches for a solution
that minimizes the number/cost of input goals (in essence, the tasks a solution
must accomplish). Our approach doesn't consider weights, relying on the user's

judgement to evaluate the optimal solution they prefer. As mentioned, it is simple
to add cost as a factor in our solution nding, but we don't assume that this is
available.
Finally, researchers have pointed out that assuming stakeholders understand
the cost of a given requirement is dangerous [18]. Arguably it is equally dangerous
to assume prioritization is possible; our approach assumes that such preferences
will have to be iteratively provided, as stakeholders are presented with various
solutions (or no solutions).
Finally, value-based SE [26] emphasizes the reality that not all desirable
software features (requirements, functions, qualities, etc.) can be implemented.
Design is seen as a series of tradeos, and understanding these tradeos is impor-
tant. This is also a focus of search-based SE, which focuses on combinatorial
optimization, using evolutionary and local search algorithms to eciently nd
solutions, e.g [2, 7]. DDP [6] supports quantitative reasoning and design se-
lection over non-hierarchical requirements models, and the latest iteration uses
search-based heuristics to nd system designs [11]. The principal dierence is in
the nature of the underlying model. Our framework uses goal models to provide
for latent interactions between requirements that are satised.
An alternative to formalized requirements models are workshop techniques
(e.g., [21]). Here requirements problems and solutions can be explored and eval-
uated without the use of formal reasoning, which can be dicult to construct
and display to end users. The motivation for formalization is that it is more
amenable to rapid prototyping and semi-autonomous execution, particularly in
the context of evolving systems. Workshops are expensive and dicult to orga-
nize. A good formal methodology will ensure end users don't use the model, but
merely get the results, in this case the set of optimal solutions.
6 Conclusions and Future work
With pQGM, we have introduced an extension to a well-known formal goal
reasoning procedure. Our extension allowed us to compare solutions to the re-
quirements problem using preferences and secondary goals. We described some
techniques for generating solution alternatives and comparing them, and showed
that our techniques can scale with the addition of simple constraints. We view
the modeling of requirements problems in pQGM as iterative: identify a core set
of compulsory elements and verify admissibility; identify secondary elements;
generate solutions; rene the model to narrow the solution space (using prefer-
ences or costs).
We hope to extend this work to accommodate incremental revisions of the
set of solutions as new information becomes available in the model. Finally, we
would like to highlight the enduring problem of propagation of con
icting values.
Although separate in QGM, many goals are only partially satised and often
also partially denied. We have been working on a paraconsistent requirements
framework that addresses this issue.

Most modeling languages are focused on nding single solutions to the prob-
lem. They use priorities and evaluation to nd that solution. We have dened
some ways to select from many solutions. The model assessment procedure de-
ned a) ways to narrow the search space and b) ways to select between solutions
once found. In other modeling languages, such as KAOS [5] or Tropos [3], the
aim of the methodology is to generate a single solution which best solves the
problem.
Why do we want to model multiple solutions? First, we think it is unrealistic
to expect to nd a single solution. Many practitioners, particularly from the lean
and agile paradigm, prefer to wait until the `last responsible moment' before
making decisions [27]. This is also seen in techniques such as Quality Function
Deployment[1]. Secondly, in a changing system, we should not presume to know
what single solution will always apply. Finally, this method allows the user {
with appropriate tool and language support { to dene the conditions under
which a solution is acceptable.
References
1. Akao, Y.: The Customer Driven Approach to Quality Planning and Deployment.
Asian Productivity Organization, Tokyo (1994)
2. Battiti, R., Brunato, M., Mascia, F.: Reactive Search and Intelligent Optimization,
Operations research/Computer Science Interfaces, vol. 45. Springer Verlag (2008)
3. Bresciani, P., Giorgini, P., Giunchiglia, F., Mylopoulos, J., Perini, A.: TROPOS:
An Agent-Oriented Software Development Methodology. Autonomous Agents and
Multi-Agent Systems 8, 203{236 (May 2004)
4. Chung, L., Mylopoulos, J., Nixon, B.A.: Representing and Using Nonfunctional
Requirements: A Process-Oriented Approach. ToSE 18, 483{497 (1992)
5. Dardenne, A., van Lamsweerde, A., Fickas, S.: Goal-directed requirements acqui-
sition. Science of Computer Programming 20(1-2), 3{50 (April 1993)
6. Feather, M.S., Cornford, S.: Quantitative risk-based requirements reasoning. Re-
quirements Engineering 8, 248{265 (November 2003)
7. Finkelstein, A., Harman, M., Mansouri, S., Ren, J., Zhang, Y.: A search based
approach to fairness analysis in requirement assignments to aid negotiation, medi-
ation and decision making. Requirements Engineering 14(4), 231{245 (December
2009)
8. Giorgini, P., Mylopoulos, J., Nicchiarelli, E., Sebastiani, R.: Formal Reasoning
Techniques for Goal Models. Journal on Data Semantics 2800, 1 { 20 (2003)
9. Glover, F.: Future paths for integer programming and links to articial intelligence.
Computers and Operations Research 13(5) (1986)
10. Herrmann, A., Daneva, M.: Requirements Prioritization Based on Benet and
Cost Prediction : An Agenda for Future Research. In: RE. pp. 125{134. Barcelona
(September 2008)
11. Jalali, O., Menzies, T., Feather, M.S.: Optimizing requirements decisions with keys.
In: PROMISE. pp. 79{86. IEEE, Leipzig, Germany (2008)
12. Jureta, I.J., Mylopoulos, J., Faulkner, S.: Revisiting the Core Ontology and Prob-
lem in Requirements Engineering. In: RE. pp. 71|-80. Barcelona (September 2008)
13. Karlsson, L., Host, M., Regnell, B.: Evaluating the practical use of dierent mea-
surement scales in requirements prioritisation. In: International symposium on em-
pirical software engineering. pp. 326{335. Rio de Janeiro, Brasil (2006)

14. van Lamsweerde, A.: Goal-Oriented Requirements Engineering: A Guided Tour.
In: RE. pp. 249{263. Toronto (2001)
15. van Lamsweerde, A.: Requirements engineering: from craft to discipline. In: FSE.
pp. 238{249. Atlanta, Georgia (November 2008)
16. van Lamsweerde, A.: Reasoning About Alternative Requirements Options., Lecture
Notes in Computer Science, vol. 5600, pp. 380{397. Springer (2009)
17. van Lamsweerde, A., Letier, E.: Handling obstacles in goal-oriented requirements
engineering. ieeese 26, 978{1005 (2000)
18. Letier, E., van Lamsweerde, A.: Reasoning about partial goal satisfaction for re-
quirements and design engineering. In: FSE. pp. 53|-62. ACM Press, Newport
Beach, CA (2004)
19. Liaskos, S., Lapouchnian, A., Yu, Y., Yu, E.S., Mylopoulos, J.: On Goal-based
Variability Acquisition and Analysis. In: RE. Minneapolis, Minnesota (September
2006)
20. Liaskos, S., McIlraith, S.A., Mylopoulos, J.: Towards Augmenting Requirements
Models with Preferences. In: ASE. pp. 565|-569. Auckland, NZ (2009)
21. Maiden, N., Robertson, S.: Integrating Creativity into Requirements Processes:
Experiences with an Air Trac Management System. In: RE. Paris, France (2005)
22. Ross, D.: Structured Analysis (SA): A Language for Communicating Ideas. ToSE
3(1), 16{34 (1977)
23. Schwanninger, C., Groher, I., Elsner, C., Lehofer, M.: Variability Modelling
throughout the Product Line Lifecycle. In: International Conference on Model
Driven Engineering Languages and Systems. Lecture Notes in Computer Science,
vol. 5795. Denver, Colorado (October 2009)
24. Sebastiani, R., Giorgini, P., Mylopoulos, J.: Simple and Minimum-Cost Satisabil-
ity for Goal Models. In: CAISE. pp. 20{35. Riga, Latvia (June 2004)
25. Sohrabi, S., Baier, J.A., McIlraith, S.A.: HTN Planning with Preferences. In: IJCAI
(2009)
26. Stefan Bi, Barry Boehm, H.E. (ed.): Value-based software engineering. Springer-
Verlag, Berlin, 1 edn. (2006)
27. Thimbleby, H.: Delaying commitment. IEEE Software 5(3), 78{86 (1988)
28. Yu, E.S.: Towards modelling and reasoning support for early-phase requirements
engineering. In: RE. pp. 226{235. Annapolis, Maryland (1997)