Extended Enterprise Modeling Language (EEML) is modelling language, which combines structural modeling, business process modeling, goal modeling with goal hierarchies, and resource modeling. It is used in practice to bridge the type of goal modeling used in common requirements engineering to other modeling approaches. The process logic in EEML is mainly expressed through nested structures of tasks and decision points. The sequencing of tasks is expressed by the flow relation between decision points. Each task has an input port and the output port being decision points for modeling process logic.
EEML is intended to be a simple language, which makes it easy to update models. In addition to capturing the various tasks(can consist of several sub-tasks) and their interdependencies, models show which roles perform each task, and the tools, services and information they apply.
Extended Enterprise Modeling Language (EEML) is end 1990s developed in the EU project EXTERNAL as extension of the Action Port Model (APM) by S. Carlsen (1998). The EXTERNAL project  aimed to facilitate inter-organisational cooperation in knowledge intensive industries. It is the hypotheses of the project that interactive process models form a suitable framework for tools and methodologies for dynamically networked organisations. In the project EEML (Extended Enterprise Modelling Language) was first constructed as a common metamodel, designed to enable syntactic and semantic interoperability.
It has been further developed in the EU projects Unified Enterprise Modelling Language (EUML) from 2002 to 2003 and the ongoing ATHENA project. The objectives of UEML Working group has been to define, to validate and to disseminate a set of core language constructs to support a Unified Language for Enterprise Modelling, named UEML, to serve as a basis for interoperability within a smart organisation or a network of enterprises.
The EEML-language is divided into 4 sub-languages, with well-defined links across these languages:
Process modeling supports the modeling of process logic which is mainly expressed through nested structures of tasks and decision points. The sequencing of the tasks is expressed by the flow relation between decision points. Each task has minimum an input port and an output port being decision points for modeling process logic, Resource roles are used to connect resources of various kinds (persons, organizations, information, material objects, software tools and manual tools) to the tasks. In addition, data modeling (using UML class diagrams), goal modeling and competency modeling (skill requirements and skills possessed) can be integrated with the process models.
EEML has four layers of interest
Goal Modelling is one of the four EEML modeling domains age. A goal expresses the wanted (or unwanted) state of affairs (either current or future) in a certain context. Example of the goal model is depicted below. It shows goals and relationships between them. It is possible to model advanced goal-relationships in EEML by using goal connectors. A goal connector is used when one need to link several goals.
Goal modeling Tabel.gif
In goal modeling to fulfil Goal1, one must achieve to other goals: both Goal2 and Goal3 (goal-connector with “and” as the logical relation going out). If Goal2 and Goal3 are two different ways of achieving Goal1, then it should be “xor” logical relationship. It can be an opposite situation when both Goal2 and Goal3 need to be fulfilled and to achieve them one must fulfil Goal1. In this case Goal2 and Goal3 are linked to goal connector and this goal connector has a link to Goal1 with ”and”-logical relationship.
The table indicate different types of connecting relationships in EEML goal modeling. Goal model can also be interlinked with a process model.
Within requirements engineering (RE), the notion of goal has increasingly been used. Goals generally describe objectives which a system should achieve through cooperation of actors in the intended software and in the environment . Goals are central in some RE frameworks, and can play a supporting role in others. Goal-oriented techniques may particularly be useful in early-phase RE. Early-phase requirements consider e.g. how the intended system meets organizational goals, why the system is needed and how the stakeholders’ interests may be addressed. 
Goal-oriented Requirements Language (GRL) is a language that is designed to support goal-oriented modeling and reasoning about requirements, especially the non-functional requirements  It allows to express conflict between goals and helps to make decisions that resolve conflicts. There are three main categories of concepts in GRL: intentional elements, intentional relationships and actors . They are called for intentional because they are used in models that primarily concerned with answering "why" question of requirements (for ex. why certain choices for behavior or structure were made, what alternatives exist and what is the reason for choosing of certain alternative.)