GRL (Goal-oriented Requirement Language) is a language for supporting goal-oriented
modeling and reasoning of requirements, especially for dealing with non-functional
requirements. It provides constructs for expressing various types of concepts
that appear during the requirement process. There are three main categories
of concepts: intentional elements, links, and actors. The intentional elements
in GRL are goal, task, softgoal, and resource. They are intentional because
they are used for models that allow answering questions such as why particular
behaviors, informational and structural aspects were chosen to be included
in the system requirement, what alternatives were considered, what criteria
were used to deliberate among alternative options, and what the reasons
were for choosing one alternative over the other.
This kind of modeling is different from the detailed specification of what
is to be done. Here the modeler is primarily concerned with exposing "why"
certain choices for behavior and/or structure were made or constraints
introduced. The modeler is not yet interested in the "operational" details
of processes or system requirements (or component interactions). Omitting
these kind of details during early phases of analysis (and design) allows
taking a higher-level (sometimes called a strategic stance) towards modeling
the current or the future software system and its embedding environment.
Modeling and answering "why" questions leads us to consider the opportunities
stakeholders seek out and/or vulnerabilities they try to avoid within their
environment by utilizing capabilities of the software system and/or other
stakeholders, by trying to rely upon and/or assign capabilities and by
introducing constraint how those capabilities ought to be performed.
GRL supports
the reasoning about scenarios by establishing correspondences between intentional
GRL elements and non-intentional elements in scenario models of URN-FR.
Modeling both goals and scenarios is complementary and may aid in identifying
further goals and additional scenarios (and scenario steps) important to
stakeholders, thus contributing to the completeness and accuracy of requirements.
University of Toronto, CANADA