Agent Oriented Requirements Engineering

By
Sugandh Wafai
0771137
Introduction: requirements engineering started with the study of what the
system should do, i.e. late phase requirements analysis, which focuses on
the specification of requirements. Their completeness, consistency,
automated verification, etc. However, it has become known that the early
phase of requirements analysis focuses on why the system must be
developed, how the desired system will meet its goals, what alternatives can
be proposed, what the relationships between various actors or stakeholders
are, and how the interests of actors can be achieved.

In agent oriented RE frameworks, crucial RE concerns such as functionality,

quality, and process will be organized around agents so that they will be
addressed in a way which is appropriate for open, distributed, and constantly
evolving environments.

Agent concepts have been introduced in RE primarily as modeling

constructs to characterize active element in the environment, usually
including the target systems. These active elements may be human or
machine, and may contain hardware and/or software.

What are Agents?

Agents may be human, hardware or software. An agent is a specialized kind
of object. Like other objects, it has states and other properties associated
with other objects. However it is also a processor for some actions, and
therefore controls state transitions. Unlike other kinds of objects (which
include entities, relationships, and events) agents have choice over their
behavior. Each agent has capabilities which is the list of actions that the
agent has capabilities which is the list of actions that the agent can perform.
The designer starts with goals for the overall composite system, then refine
them until they are reduced to constraints that can be assigned to agents.
Agents can have wishes that are goals, and which may conflict with each
other. Agents have further attributes to represent load, reliability, cost, and
motivation. These are used by designer in deciding what constraints can be
assigned to what agents.

Characteristics of Agents: a software agent is a software program that

is capable of autonomous (or at least semi-autonomous) actions in pursuit of
a specific goal. The autonomy characteristic of a software agent
distinguishes it from general software programs. Autonomy in agents
implies that the software agent has the ability to perform its tasks without
direct control, or at least with minimum supervision, in which case it will be
a semi autonomous software agent.

Software agents can be grouped, according to specific characteristics into

different types or classes of software agents. As software agents are
commonly classifies according to a set of characteristics, different classes of
software agents often overlap, implying that a software agent might belong
to more than one class at a time (d’Inverno & Luck 2001)

According to Wooldridge (2001) intelligence implies the inclusion of at least

three distinct properties, namely reactivity, proactiveness, and social ability.
Reactivity refers to the agent’s ability to perceive its environment and in a
timely manner to changes that occur in order to achieve its design goals.
Proactiveness is the agent’s ability to take the initiative in its environment in
order to achieve its design goals. Social ability alludes to the collaborative
nature of the agent.

Types of Agents: agents can generally be classified in two types.

A stationary agent can be seen as a piece of autonomous (or semi
autonomous) software that permanently resides on a particular host. Such an
agent performs tasks on its host machine such as accepting mobile agents,
allocating resources, performing specific computing tasks, enforcing security
policies and so forth.

A mobile agent is a software agent that has the ability to transport itself from
one host to another in a network. The ability to travel allows a mobile agent
to move itself to a host that contains an object with which the agent wants to
interact, and then to take advantage of the computing resources of the
object’s host in order to interact with that object. Full autonomy,
migratability and collaborativeness are the most important characteristics
that should be embedded in each mobile agent. When a mobile agent
possesses these three intelligence requirements, it is often regerred to as a
robot (Krupansky, 2003)

A Look at Agent Oriented Requirements Engineering

Framework:
Here we take a look at the RE frameworks that support the concept of
agents.

Composite Systems Design and KAOS: a composite system is

one that is made up of a number of components (or agents) that interact with
each other to produce some overall behavior. An important premise of the
CSD approach is that in designing an automated system, one should treat the
system and its environment as a (larger) system whose overall properties are
the one we aim to achieve. The specification of the automated system should
be derived systematically from the desired behavior of the overall system.
Typically one starts with global system goals, which are decomposed until
they can be assigned to individual agents. During the design process, goals
are replaced by ‘responsibilities’ and assigned to subsets of agents.
Ultimately, responsibilities are subdivided so that individual pieces are
assigned to individual agents.

KAOS is a framework for goal-directed requirements acquisition. As in CSD

a composite system viewpoint is adopted. Agents may be human, hardware
or software. An agent is a specialized kind of object. Like other objects, it
has states and other properties associated with objects. However, it is also a
processor for some actions and therefore controls state transitions. Unlike
other kinds of objects (which include entities, relationships, and events)
agents have choice over their behavior. Each agent has capabilities, which is
a list of actions that the agent can perform.

The designer starts with goals for the overall composite system, then refines
them until they are reduced to constraints that can be assigned to agents.

Albert II: the Albert language supports the modeling of functional

requirements in terms of a collection of goals interacting in order to provide
services necessary for an organization. Each agent is characterized by
actions that change or maintain its own state of knowledge about the
external world and/or states of other agents. Such actions are performed by
agents in order to discharge contractual obligations expressed in terms of
internal and cooperative constraints.

Functional requirements in Albert are expressed in terms of a set of formal

statements. These statements are grouped around agents in order to define
the set of admissible behavior the agents may experience.
Agents in Albert are not intentional and do not have goals. The language
focuses on specification, and is not concerned with the examination of
alternatives for meeting goals.

The F3 Framework: the F3 framework (From Fuzzy to Formal) is a

framework which aims to cover a wide range of requirements engineering
activities. An important part of framework is the “Enterprise Model”. This
model has five sub models: Objective Model, Concept Model, Activities and
Usage Model, the Actors Model, and Information System Requirements
Model. These models are essentially ERA models with entities,
relationships, and attributes suitable for each of these sub-areas. There are
also links across the sub-models of the overall model. The approach is
objective-driven, with an emphasis on understanding the business objectives
behind system requirements.

The i* Framework: is a framework for modeling and redesigning

intentional relationships among strategic actors. It was developed as a
framework to support the early phase of requirements engineering. The
strategic actor is the central concept. Actors have intentional properties such
as goals, beliefs, abilities, and commitments. They are strategic in that they
are concerned about opportunities and vulnerabilities.

The focus of the framework is in analyzing strategic implications from the

viewpoint of each actor, and to support the exploration and identification of
alternative operational processes (solution) which will better meet the
strategic interests of the actors. To support this level of modeling and
reasoning a process is modeled in terms of intentional relationships among
actors, rather than input/output relationships. Actors depend on each other
for goals to be achieved, tasks to be performed, and resources to be
furnished. This is called the Strategic Dependency Model.

The Strategic Rationale model provides a way for systematically asking why
a process is structures the way it currently is, thus revealing the goals behind
them.

The framework is not concerned with the detailed specification of processes

and activities, leaving these to a separate part of requirements engineering
called the “late-phase.”
References
• http://www.cse.yorku.ca/~lesperan/papers/AOIS01.pdf

• http://journal.info.unlp.edu.ar/Journal/journal14/papers/JCST-Aug05-
P4.pdf

• www.cs.toronto.edu/pub/eric/REFSQ97.ps.gz