Techne: Towards a New Generation of Requirements Modeling Languages with Goals, Preferences, and Inconsistency Handling
2010 18th IEEE International Requirements Engineering Conference (2010)
- ISSN: 1090705X
- ISBN: 9781424480227
- DOI: 10.1109/RE.2010.24
Available from
Neil Ernst's profile on Mendeley.
or
Abstract
Techne is an abstract requirements modeling language that lays formal foundations for new modeling languages applicable during early phases of the requirements engineering process. During these phases, the requirements problem for the system-to-be is being structured, its candidate solutions described and compared in terms of how desirable they are to stakeholders. We motivate the need for Techne, introduce it through examples, and sketch its formalization.
Author-supplied keywords
Page 1
Techne: Towards a New Generation of Requirements Modeling Languages with Goals, Preferences, and Inconsistency Handling
Techne: Towards a New Generation of Requirements Modeling Languages
with Goals, Preferences, and Inconsistency Handling
Ivan J. Jureta
FNRS & Louvain School of Management
University of Namur
ivan.jureta@fundp.ac.be
Alex Borgida
Department of Computer Science
Rutgers University
borgida@cs.rutgers.edu
Neil A. Ernst, John Mylopoulos
Department of Computer Science
University of Toronto
jm,nernst@cs.toronto.edu
Abstract—Techne is an abstract requirements modeling lan-
guage that lays formal foundations for new modeling languages
applicable during early phases of the requirements engineering
process. During these phases, the requirements problem for
the system-to-be is being structured, its candidate solutions
described and compared in terms of how desirable they are
to stakeholders. We motivate the need for Techne, introduce it
through examples, and sketch its formalization.
Keywords-Requirements models, goal-oriented requirements
engineering, requirements modeling languages
I. INTRODUCTION
Three intertwined questions remain among the central
ones in Requirements Engineering (RE) for at least three
decades now (e.g., [1]): (1) What information should be
elicited from the stakeholders of the system-to-be? (2) What
models should be used to represent the elicited information?
(3) What kinds of reasoning should be performed over these
models? Seminal answers took the form of requirements
modeling languages (RMLs), which typically included (1) an
ontology of requirements stating the information to elicit,
relevantly describing optative properties and behaviors of the
system-to-be and its operational environment, (2) modeling
primitives for the concepts and relations of the ontology,
the instances of which together form models to record the
elicited information, and (3) often automated methods that
could be applied to the models in order to answer questions
of methodological interest, such as if a model is consistent,
or if the properties and behaviors it attributes to the system
would allow the latter to satisfy its designated purpose. RMLs
such as SADT [2], RML [3], ERAE [4] KAOS [5] and i* [6]
often served as the starting point for further research on
various issues of interest in RE, shaping thereby the field.
The answers that an RML gives to the three key questions
reflect its respective fundamental assumptions about the very
problem that RE aims to resolve within the broader process
of systems engineering, of how the problem can and should
be resolved, and of when it is resolved. SADT illustrates the
views of the 1970s and 1980s, that requirements ought to
be described graphically as functions that the system-to-be
should deliver once it is operational within its environment.
As the importance of automated systems to the work and
coordination of people increased, and interest shifted from
software and hardware alone to sociotechnical systems, it was
recognized that RE must account for the variously (im)precise
and (in)consistent expectations of the stakeholders, including
its future users, owners, and so on. To do so, RE had to move
away from its historical origins in formal specification meth-
ods, towards knowledge representation. An understanding
of the functions of the system-to-be could only be sought
after beliefs, desires, and intentions of stakeholders had
been grasped to a feasible extent. The concept of system
or stakeholder goal (to represent desires) became central,
as KAOS made clear. i* went one step further with its
focus for how various intentional agents/stakeholders are
interdependent on each other and the system-to-be for the
realization of their individual and joint goals.
The move from functions to goals reflects the change of
the core ontology of RE and with it of the definition of
the requirements problem. New RMLs were consequently
designed, in which the modeling primitives and reasoning
methods follow and benefit from the fundamental changes.
However, as argued in [7], the core ontology for re-
quirements and the requirements problem [8] — which are
implicit in state-of-the-art RMLs such as KAOS and i* — is
limited in several respects that are critical for the successful
performance of RE for contemporary systems. It is not clear
how candidate solutions to the requirements problem can be
compared, e.g., what criteria (should) serve for comparison,
and how these criteria are represented in requirements
models. The CORE ontology for requirements [7] emphasized
these issues, by recognizing that in addition to goals and
tasks, different stakeholders have different preferences over
requirements, that they are interested in choosing among
candidate solutions, that potentially many candidate solutions
exist (as in the case of service-/agent-oriented systems, where
different services/agents may compete in offering the same
functions), and that requirements are not fixed, but change
with new information from the stakeholders or the operational
environment. This has created the need for new RMLs to be
designed so as to respond to these issues.
The main objective of this paper is to introduce Techne,
an abstract RML designed as the core on which to build new
with Goals, Preferences, and Inconsistency Handling
Ivan J. Jureta
FNRS & Louvain School of Management
University of Namur
ivan.jureta@fundp.ac.be
Alex Borgida
Department of Computer Science
Rutgers University
borgida@cs.rutgers.edu
Neil A. Ernst, John Mylopoulos
Department of Computer Science
University of Toronto
jm,nernst@cs.toronto.edu
Abstract—Techne is an abstract requirements modeling lan-
guage that lays formal foundations for new modeling languages
applicable during early phases of the requirements engineering
process. During these phases, the requirements problem for
the system-to-be is being structured, its candidate solutions
described and compared in terms of how desirable they are
to stakeholders. We motivate the need for Techne, introduce it
through examples, and sketch its formalization.
Keywords-Requirements models, goal-oriented requirements
engineering, requirements modeling languages
I. INTRODUCTION
Three intertwined questions remain among the central
ones in Requirements Engineering (RE) for at least three
decades now (e.g., [1]): (1) What information should be
elicited from the stakeholders of the system-to-be? (2) What
models should be used to represent the elicited information?
(3) What kinds of reasoning should be performed over these
models? Seminal answers took the form of requirements
modeling languages (RMLs), which typically included (1) an
ontology of requirements stating the information to elicit,
relevantly describing optative properties and behaviors of the
system-to-be and its operational environment, (2) modeling
primitives for the concepts and relations of the ontology,
the instances of which together form models to record the
elicited information, and (3) often automated methods that
could be applied to the models in order to answer questions
of methodological interest, such as if a model is consistent,
or if the properties and behaviors it attributes to the system
would allow the latter to satisfy its designated purpose. RMLs
such as SADT [2], RML [3], ERAE [4] KAOS [5] and i* [6]
often served as the starting point for further research on
various issues of interest in RE, shaping thereby the field.
The answers that an RML gives to the three key questions
reflect its respective fundamental assumptions about the very
problem that RE aims to resolve within the broader process
of systems engineering, of how the problem can and should
be resolved, and of when it is resolved. SADT illustrates the
views of the 1970s and 1980s, that requirements ought to
be described graphically as functions that the system-to-be
should deliver once it is operational within its environment.
As the importance of automated systems to the work and
coordination of people increased, and interest shifted from
software and hardware alone to sociotechnical systems, it was
recognized that RE must account for the variously (im)precise
and (in)consistent expectations of the stakeholders, including
its future users, owners, and so on. To do so, RE had to move
away from its historical origins in formal specification meth-
ods, towards knowledge representation. An understanding
of the functions of the system-to-be could only be sought
after beliefs, desires, and intentions of stakeholders had
been grasped to a feasible extent. The concept of system
or stakeholder goal (to represent desires) became central,
as KAOS made clear. i* went one step further with its
focus for how various intentional agents/stakeholders are
interdependent on each other and the system-to-be for the
realization of their individual and joint goals.
The move from functions to goals reflects the change of
the core ontology of RE and with it of the definition of
the requirements problem. New RMLs were consequently
designed, in which the modeling primitives and reasoning
methods follow and benefit from the fundamental changes.
However, as argued in [7], the core ontology for re-
quirements and the requirements problem [8] — which are
implicit in state-of-the-art RMLs such as KAOS and i* — is
limited in several respects that are critical for the successful
performance of RE for contemporary systems. It is not clear
how candidate solutions to the requirements problem can be
compared, e.g., what criteria (should) serve for comparison,
and how these criteria are represented in requirements
models. The CORE ontology for requirements [7] emphasized
these issues, by recognizing that in addition to goals and
tasks, different stakeholders have different preferences over
requirements, that they are interested in choosing among
candidate solutions, that potentially many candidate solutions
exist (as in the case of service-/agent-oriented systems, where
different services/agents may compete in offering the same
functions), and that requirements are not fixed, but change
with new information from the stakeholders or the operational
environment. This has created the need for new RMLs to be
designed so as to respond to these issues.
The main objective of this paper is to introduce Techne,
an abstract RML designed as the core on which to build new
Sign up today - FREE
Mendeley saves you time finding and organizing research. Learn more
- All your research in one place
- Add and import papers easily
- Access it anywhere, anytime
Start using Mendeley in seconds!
Readership Statistics
21 Readers on Mendeley
by Discipline
by Academic Status
57% Ph.D. Student
19% Student (Master)
5% Student (Bachelor)
by Country
10% Canada
10% United States
10% France


