Towards an Agent-driven Software Architecture Aligned with User

Stories

Yves Wautelet

, Samedi Heng

, Manuel Kolp

and Christelle Scharff

Faculty of Economics and Business, KULeuven, Brussels, Belgium

Louvain School of Management, Universit

e Catholique de Louvain, Louvain-La-Neuve, Belgium

Seidenberg School of Computer Science and Information Systems, Pace University, New York, U.S.A.

Keywords:

Agent Architecture, Agile Development, User Story, Agile Architecture, Multi-agent System.

Abstract:

Agile principles have taken an increasing importance in the last decades. Software Architecture (SA) deﬁnition

is perceived as a non-agile practice as it is executed in a top-down manner, reminding waterfall development,

and sometimes imposes heavy documentation. This paper proposes to systematically build an agent-oriented

SA from a set of User Stories (US), the core artifact to document requirements in agile methodologies. Pre-

vious research has allowed to deﬁne a uniﬁed US meta-model for the generation of templates relating WHO,

WHAT and WHY elements. This meta-model’s elements deﬁne a syntax issued from practitioners templates

associated with semantics from Goal Oriented Requirements Engineering frameworks, more precisely i*. With

a set of US following the templates of this previous model, the link between the US and SA concepts is sys-

tematically studied and a transformation process is proposed. The SA can decline agent behaviors aligned

with requirements and organizational behaviors. Moreover, requirements (thus US) are subject to evolution

through agile iterations; the SA can evolve with these changes in a semi-automatic manner. We thus argue that

the Agent-SA produced with our transformation process contributes to the overall project agility.

1 INTRODUCTION

(Abrahamsson et al., 2010) highlights the core oppo-

sition between Software Architecture (SA) deﬁnition

within a software project – seen as a top-down prac-

tice implying heavy documentation – and agile devel-

opment. The Agile Manifesto emphasizes four values

in agile development: (i) Individuals and interactions

over processes and tools; (ii) Working software over

comprehensive documentation; (iii) Customer collab-

oration over contract negotiation; and (iv) Respond-

ing to change over following a plan. Agile principles

seem thus opposed to SA design unless the SA can

evolve together and parallel to the requirements. Such

an evolution would be eased if the SA would follow

agile-style requirements deﬁnition. In agile method-

ologies, requirements are expressed using User Sto-

ries (US). US are written in natural language by the

customer and they describe user functionalities at an

abstract level.

In this work, we consequently suggest to system-

atically derive part of the SA from the set of US of a

project in the form of a multi-agent architecture better

aligned with agile principles. At the end, we want to

dispose of a SA deﬁnition that is not heavy but can

be partly automated and changed with the evolution

of the US models, only if they are properly struc-

tured following the model deﬁned in (Wautelet et al.,

2014). This model’s elements deﬁne a syntax issued

from practitioners templates associated with seman-

tics from Goal Oriented Requirements Engineering

(GORE) frameworks, more precisely i* (Yu et al.,

2011). The implementation of the agent-architecture

is outside the scope of this paper, but an implementa-

tion model in line with the SA can be found in (Kiv

et al., 2012).

2 STRUCTURING USER STORY

CONCEPTS

This section exposes the “building blocks” used

within this research.

2.1 Macro-level: Ways to Organize User

Stories

We ﬁrst distinguish a US macro-level dealing with the

Wautelet, Y., Heng, S., Kolp, M. and Scharff, C.

Towards an Agent-driven Software Architecture Aligned with User Stories.

DOI: 10.5220/0005706103370345

In Proceedings of the 8th International Conference on Agents and Artiﬁcial Intelligence (ICAART 2016) - Volume 2, pages 337-345

ISBN: 978-989-758-172-4

337

grouping of US into depending (i.e. relating) sets. We

thus consider here the US as potential building blocks

serving for SA composition/decomposition. Figure 1

presents our meta-model of the US concepts.

AcceptanceTest

Feature

Theme

Epic

User_Story

priority : Integer

amountOfPoints : Integer

status : ENUM{0_US,IP_US,C_US}

conversation : Text

1..n

Fulfills

1..n1..n

Requires

groups

1..n

0..1

1..n

0..1

is refined in

0..n0..n

Figure 1: US as Macro-Level Structures: Meta-Model.

The User Story class represents the US as a

whole. US are written by the customer or product

owner at the earliest stages of the project and put in

the product backlog with a (implementation) priority

and an amountOfPoints which refers to the number of

User Story Points (USP)

(Cohn, 2004; Lefﬁngwell,

2010). As a result, these elements have been added

as attributes to the User Story class. Additional at-

tributes required for process management are also in-

cluded within the User Story class.

The concept of US is by essence granular in the

sense that some US need to be reﬁned into other ones

since they are too abstract to be estimated, imple-

mented and tested in their initial forms. These US

are called Epics (Cohn, 2004). Epics are US with a

high level of abstraction meaning that they must be

reﬁned/decomposed into smaller US to fully describe

the requirement they refer to. These US are repre-

sented by the class Epic that inherits from the US

class. As we will see later on, Epic US contain coarse-

grained process elements that cannot be transformed

at once in the SA (see Section 4.2).

Other concepts evoked in the meta-model of Fig-

ure 1 are non-relevant for the present research and will

not be discussed.

2.2 Micro-level: Decomposing a User

Story in Descriptive Concepts

Within Figure 2, the meta-model of the previous sec-

tion is enriched with the constituting elements of the

US. We refer to this US view as the micro-level.

Rather than using the US as a whole within the

requirements analysis process, we suggest, in our re-

search design, to decompose the US on the basis of

The amount of USP represents the estimated effort re-

quired to implement the US.

their WHO, WHAT and, when available, WHY dimen-

sions. To ensure uniformity, these elements are all

characterized as Descriptive Concepts (D C). When

decomposed into a set of D C, the dependency be-

tween D C is intended to be further studied (see Sec-

tion 2.3). Each element of a US template relating to

one of the 3 dimensions is then an instance of the D C

class. For the template of a US: As a <role>, I need

a <task> so that <goal>, we have 3 instances of

the D C class: one for role, one for task and one for

goal. The dimension attribute thus compulsorily takes

one of the values WHO (for role), WHAT (for task) or

WHY (for goal) and the syntax attribute takes the syn-

tax of the concept name (role, task, goal, ...). The

semantic attribute relates to the deﬁnition of the D C.

The list of all the possible D C is given in the form

of a meta-model allowing to deﬁne US templates in

Section 2.3.

Finally, since different D C can be linked together,

we introduce the Link class that represents the possi-

ble types of links between two D C. Typically such

links can be (at least partially) found in a logical way

through agents’ behavior at the level of the SA (see

Section 6).

2.3 Uniﬁed-model of User Stories’

Descriptive Concepts

(Wautelet et al., 2014) proposes to build a uniﬁed

model for designing US templates. The interested

reader will refer to the latter reference for research

and process related details. Figure 3 represents the

meta-model of US templates. A US template can be

designed from taking an element of the WHO, WHAT

and possibly WHY dimensions. The link between the

classes conceptually represents the link from one di-

mension to the other. Speciﬁcally, the unidirectional

association from the Role to one of the Capability,

Task or Goal classes implies that the target class in-

stantiates an element of the WHAT dimension (al-

ways tagged as wants/wants to/needs/can/would like

in the model). Then, the unidirectional association

from one of these classes instantiating the WHAT di-

mension to one of the classes instantiating the WHY

dimension (always tagged as so that into the model)

implies that the target class eventually (since 0 is the

minimal cardinality) instantiates an element of the

WHY dimension. A US template supported by our

model is for instance: As a <role>, I would like

<task> so that <hard-goal>.

Each concept is associated with a particular syn-

tax (identical to the name of the class in Figure 3) and

a semantic. The syntax and semantics of the model

are summarized here. As a result of the research

ICAART 2016 - 8th International Conference on Agents and Artiﬁcial Intelligence

338

Link

type : String

sibling : Descriptive_Concept

AcceptanceTest

Feature

Theme

Epic

Descriptive_Concept

dimension : ENUM{WHO,WHAT,WHY}

syntax : String

semantic : String

0..n

User_Story

priority : Integer

amountOfPoints : Integer

status : ENUM{0_US,IP_US,C_US}

conversation : Text

1..n

Fulfills

1..n1..n

Requires

groups

1..n

0..1

1..n

0..1

is refined in

2..31..n 2..31..n

includes

0..n0..n

Figure 2: US as Macro and Micro-Level Structures: Meta-Model.

Soft_Goal

dimension : Enum{WHAT,WHY}

name : String

Hard_Goal

dimension : Enum{WHAT,WHY}

name : String

0..n

so that

Capability

name : String

dimension : String = WHAT

Role

name : String

dimension : String = WHO

0..n

1..n

0..n

1..n

wants/wants to/needs/can/would like

Task

name : String

dimension : Enum{WHAT,WHY}

0..n1..n 0..n1..n

wants/wants to/needs/can/would like

0..n

so that

0..n

so that

0..n

Goal

0..n

so that

0..n

1..n

0..n

1..n

wants/wants to/needs/can/would like

0..n

so that

Figure 3: Uniﬁed Model for User Story Descriptive Concepts.

conducted in (Wautelet et al., 2014), all these cou-

ples syntax/semantic are issued of (Yu et al., 2011).

Speciﬁcally:

• A Role is an abstract characterization of the be-

havior of a social actor within some specialized

context or domain of endeavor;

• A Task speciﬁes a particular way of attaining a

goal;

• A Capability represents the ability of an actor to

deﬁne, choose, and execute a plan for the fulﬁll-

ment of a goal, given certain world conditions and

in the presence of a speciﬁc event;

• A Hard-goal is a condition or state of affairs in the

world that the stakeholders would like to achieve;

• A Soft-goal is a condition or state of affairs in the

world that the actor would like to achieve. But

unlike a hard-goal, there are no clear-cut crite-

ria for whether the condition is achieved, and it

is up to the developer to judge whether a particu-

lar state of affairs in fact achieves sufﬁciently the

stated soft-goal.

More explanations for distinguishing Hard-goal,

Task and Capability elements will be discussed in

Section 4.

3 A STRUCTURE FOR DEFINING

THE SOFTWARE

ARCHITECTURE

This section exposes the main building blocks of the

abstract agent-architecture that will be used to map

US concepts in order to automatically align part of

the SA with the collected requirements. Examples of

each of the elements are provided in the illustrative

example of Section 6.

3.1 Agent Structure

Figure 4 proposes a generic template for the Agent

concept. The deﬁnition of an Agent is composed of

ﬁve parts: Attributes, Events, Plans, Beliefs and Meth-

ods.

We typically refer in this work to BDI agent im-

plementation platforms such as JADE, JACK Intelli-

gent Agents or the Jadex BDI Agent System (Pokahr

et al., 2005; Pokahr et al., 2013; Pokahr et al., 2014).

The agent class allows to specify:

• the declaration of agent attributes;

• the events (both internal and external) that the

agent (i) handles, (ii) can post internally (to be

Towards an Agent-driven Software Architecture Aligned with User Stories

339

handled by other plans), or (iii) can send exter-

nally to other agents;

• the plans that the agent can execute;

• the beliefs the agent can use and refer to. The be-

liefs of an agent can be of type private, protected,

or public. A private access is restricted to the

agent to which the belief belongs. Protected ac-

cess is shared with other agents of the same class,

while public access is unrestricted;

• the declaration of agent methods (e.g., the con-

structor of an agent).

Agent

Attribute

Event

Plan

Belief

Method

<plan>

private belief

post

send <event>

<event>

protected belief

public belief

Figure 4: Agent template.

3.2 Event Structure

Events describe stimuli, emitted by agents or auto-

matically generated, in response to which other or the

same agents must take action.

Events are the origin of all activity within an

agent-oriented system. In the absence of events an

agent stays idle. Whenever an event occurs, an agent

initiates a task to handle it. This task can be thought

of as a thread of activity within the agent. The task

causes the agent to choose between the plans it has

available, executing a plan or a set of plans until it

succeeds or fails.

There are different event types, each with different

uses. Events can be described along three dimensions:

• External or internal event: external events are sent

to other agents while internal events are posted by

an agent to itself;

• Normal or BDI event: an agent has a number of al-

ternative plans to respond to a BDI event and only

one plan in response to a normal event. Whenever

an event occurs, the agent initiates a plan to handle

it. If the plan execution fails and if the event is a

normal event, then the event is said to have failed.

If the event is a BDI event, a set of plans can be

selected for execution and these are attempted in

turn. If all selected plans fail, the event is also said

to have failed;

Belief

Attribute

key

value

FieldType FieldNam

Figure 5: Belief template.

• Automatic or nonautomatic event: an automatic

event is automatically created when certain belief

states arise.

3.3 Belief Structure

A Belief describes a piece of knowledge that an agent

has about itself and its environment.

Figure 5 shows a template of a belief. Every be-

lief that an agent currently has is represented as tu-

ples. It has key and value ﬁelds. The key FieldType

Fieldname declaration describes the key attributes,

while the value FieldType FieldName declaration

describes the data attributes of each belief. A belief

may have zero or more key or value ﬁeld declarations.

3.4 Plan Structure

A plan describes a sequence of actions that an agent

can take when an event occurs.

Plan

Event

Used Belief

Method

<event>

handle

post

send

read

modify

main() {}

Figure 6: Plan template.

Plans are structured in three parts as shown in Fig-

ure 6: the Event part, the Belief part, and the Method

part. The Event part declares events that the plan han-

dles (i.e., events that trigger the execution of the plan)

and events that the plan produces. The latter can be

either posted (i.e., sent by an agent only to itself) or

sent (i.e., sent to other agents). The Belief part de-

clares beliefs that the plan reads and those it modiﬁes.

The Method part describes the plan itself, that is, the

actions performed when the plan is executed. In the

following, we study in more detail each part of the

plan template.

3.4.1 Events in Plans

handle <event>

Whenever an agent detects that an event arises, it tries

to ﬁnd a plan to handle the event.

ICAART 2016 - 8th International Conference on Agents and Artiﬁcial Intelligence

340

The event the agent can handle is identiﬁed by its

plans’ handle <event> declarations. When an in-

stance of a given event arises, the agent may execute

one of the plans that can handle this event.

The handle <event> declaration is mandatory.

Whenever an instance of this event occurs, the agent

will consider this plan as a candidate response. With-

out a handle <event> declaration, a plan would

never be executed by an agent.

post <event>

The post <event> statement declares that the

plan is able to post this event when executed. This

may be in one of the methods declared in the Method

part. Only events that the agent posts internally are

declared after the post statement.

send <event>

The send <event> declaration is similar to the

post <event> declaration, except that it identiﬁes

events that the plan can send to other agents. A plan

is able to send an event through one of the methods

declared in the Method part.

3.4.2 Used Beliefs in Plans

read <belief>

The read <belief> declaration indicates that the

<belief> is to be read (and only read) within the

plan.

modify <belief>

The modify <belief> statement indicates that

the <belief> may be read and modiﬁed within the

plan.

3.4.3 Methods in Plans

All the plan’s methods are declared in the method

part. Two of these methods are worth to be pointed

out: context() and main().

An agent may further discriminate plans that han-

dle an event by determining whether a plan is rele-

vant. The context() method allows the agent to de-

termine which plan to execute when a given event oc-

curs. To be relevant, the plan must declare that it is

capable of handling the event that has arisen (via the

handle <event> declaration) and that it is relevant

to the event instance (via the context() method).

context() is a boolean method. If this method

returns true, the plan is relevant to the event. If not,

the plan is not relevant to the event.

The main() method is executed whenever a plan

is executed. The main() method is just like the

main() method in Java – it represents the starting

point in a plan’s execution.

4 BRIDGING A SET OF US TO A

MULTI-AGENT SOFTWARE

ARCHITECTURE

The aim of this Section is, starting from the De-

scriptive Concepts deﬁned into the model presented

in Section 2.3, to study the transformation possibili-

ties to the element constituting the agent SA.

4.1 Role

A Role within a US is transformed in an intentional

Agent in the SA. This way, an organizational role

(which is most often a software user) is literally

mapped to an intelligent acting entity at run-time into

the system.

4.2 Hard-goal

The Hard-goal is the most abstract element since it is

a condition or state of affairs that must be attained but

there is no deﬁned way to attain it or more precisely

several ways could be followed in practice contrarily

to the task that represents an operational way to attain

a Hard-goal. An example of a Hard-goal could, for

example, be to Graduate for a diploma in Business In-

formation Management; it can be the Hard-goal of a

student but there are several ways to attain this Hard-

goal .

Being highly abstract, Hard-goals are not right

away transformed into a functional aspect in the soft-

ware architecture. US containing Hard-goals can be

(but not necessarily) Epic US. Their satisfaction is

rather supported by one or several Task(s) and/or Ca-

pabilities that will themselves be transformed into the

agent architecture (see Section 4.3).

4.3 Task & Capability

The Task and the Capability represent more concrete

and operational elements but these two need to be dis-

tinguished. The Capability could in fact be modeled

as a Task but the Capability has more properties than

the former since it is expressed as a direct intention

from a role. In order to avoid ambiguities in interpre-

tation, we use of the Capability element only for an

atomic Task (i.e., a task that is not reﬁned into other

Towards an Agent-driven Software Architecture Aligned with User Stories

341

Elements

Plan

Belief

Structural Diagram

Communication

Diagram

Multi

-Agent System Design

Event

Soft_Goal

Dynamic Diagram

Role Capability

Hard_Goal

Task

realizes executes

Agent

Figure 7: The Forward Engineering Process.

elements but is located at the lowest level of hierar-

chy). A Task could then be Take the Business Intel-

ligence Methods class and a Capability would be Fill

in the Exam.

The Task representing a whole process composi-

tion will be transformed as a Plan, while Capability,

by nature atomic, will be transformed in an Event.

4.4 Soft-goals

Soft-goals are not transformed at operational level but

other Hard-goals and Tasks contribute positively or

negatively to their satisfaction. These latter Hard-

goals and Tasks are themselves transformed into the

agent architecture as evoked above.

5 SOFTWARE

TRANSFORMATION PROCESS

Figure 7 graphically illustrates the transformation

process deﬁned in the previous section. With respect

to the SA:

• A Role element is transformed into an Agent;

• A Task element is transformed into a Plan;

• A Capability element is transformed into an

Event.

Let us also note that Domain Entities (DE) ma-

nipulated by the Agents to fulﬁll the elements evoked

above will form the Beliefs in the SA. DE are not ex-

pressed as such in US but rather physical or logical

resources manipulated by Roles in the realization of

US. This means they are derived from a careful read-

ing of the US.

On the bottom right side of Figure 7, we can also

note three types of diagrams – the Structural Diagram

(SD), the Communication Diagram (CD) and the Dy-

namic Diagram (DD) – representing complementary

views of the agents properties and behavior at system

level. Due to a lack of space and with the willingness

to focus on the transformation process only, we will,

in the context of this paper, focus on the SD only.

6 ILLUSTRATIVE EXAMPLE

This section exposes the illustrative example on

which we apply the SA transformation process. Note

that this illustrative example is taken from a bigger

case but that, due to a lack of space, the set of US

chosen and their transformation into the SA is lim-

ited.

6.1 User Stories

Our proposal will be illustrated using a running ex-

ample about carpooling. Carpooling deals with shar-

ing car journeys so that more than one person trav-

els within a car. In this context, it becomes increas-

ingly important to save gas, reduce trafﬁc, save driv-

ing time and control pollution. ClubCar is a multi-

channel application available as an Android applica-

tion, SMS service and IVR system. Users of Club-

Car are riders and/or drivers that can register by SMS,

voice or through an Android app. Roughly speaking,

the software allows drivers to propose rides and sub-

mit their details with dates, times, sources and des-

tinations while riders can search for available rides

(Shergill and Scharff, 2012).

As shown in Table 1, we have taken a sample of

the US of the ClubCar application to illustrate the re-

search developed in this paper. The ﬁrst column de-

picts the Dimension of US D C, the second column

describes the element itself and the last column gives

the type of the D C

Note that, when there were several possibilities, an

ad-hoc choice has been made since envisaging the multi-

ple modeling solutions at the level of the uniﬁed template

model is not the focus of the present research.

ICAART 2016 - 8th International Conference on Agents and Artiﬁcial Intelligence

342

Table 1: US sample issued of the ClubCar development.

# Dimen-

sion

Element D C Type

1 WHO As a DRIVER Role

WHAT I want to propose

rides to Riders

Hard-goal

2 WHO As a DRIVER Role

WHAT I want to propose

a ride from A to B

with the price loca-

tion and time of de-

parture, and number

of seats available

Task

3 WHO As a DRIVER Role

WHAT I want to log in to the

platform

Capability

WHY so that I can register

to the service

Task

4 WHO As a DRIVER Role

WHAT I want to select the

ride characteristics

Capability

5 WHO As a DRIVER Role

WHAT I want to conﬁrm the

proposal

Capability

6 WHO As a RIDER Role

WHAT I want to order a ride Capability

6.2 Agent Architecture

US1 contains a Hard-goal element in the WHAT di-

mension and constitutes an Epic US so that it is not

forwarded as such to the SA but is satisﬁed through

the realization of the Task element in US2. Never-

theless we can “manually” identify the presence of a

DE which is the Ride that will be transformed into a

Belief (see hereunder).

As illustrated in Figure 8, the ProposeRideFro-

mAtoB Plan is forwarded from the Task element de-

picted in US2. It is used by the Driver Agent to pro-

pose a ride to the Rider Agent

. The Plan is executed

when the CharacteristicsSelected Event (con-

taining the information about the characteristics of the

Ride offered by the Driver) occurs. The latter Event

is forwarded from US4. The ProposeRideFromA-

toB Plan also creates a Ride Belief, i.e. the Driver

belief storing the proposed Ride that can then be pro-

posed to a Rider Agent. Later, the Rider Agent can

subscribe for the proposed Ride.

DriverProposalConﬁrmation is an Event trans-

formed from US5 that is posted automatically when-

ever the value of the status ﬁeld (of the Ride Belief)

Due to a lack of space the Rider Agent has not been

represented in Figure 8.

is set to submitted. It will then invoke a plan to inform

the Rider that the Ride is available.

The RiderOrder Event (not illustrated in Figure

8) belonging to the Rider Agent is sent when the

Rider Agent subscribed to a Ride offered by the

Driver Agent. This Event is transformed from the

Capability element in US6.

As evoked in the previous section, other agent be-

havior is outside the scope of the this paper that fo-

cuses on systematic forward engineering of US to a

SA, therefore the full SD as well as CD and DD are

not represented here.

<<Plan>> ProposeRideFromAtoB

Event

handle

CharacteristicsSelected

post

RideCharacteristicsRecorded

send

DriverProposalConfirmation

Used Beleif

modify

Ride

Method

main()

{

// save ride proposition to

// Driver’s belief

// post and send events upon

// the Ride availability and

// characteristics

}

<<Agent>> Driver

Attribute

String Name

Event

InformRideDone

……..

Plan

ProposeRideFromAtoB

……..

Beleif

private beleif

Ride

……..

public belief

RideCharacteristics

Method

// Constructor

public Driver (Dname)

// load data to the beliefs

// of the driver

public void loadBK_Driver()

…………..

<<Event>> DriverProposalConfirmation

Attribute

Scope: <<Internal>>

Type : <<Normal>>

// String rCode

// String DriverID

Creating Method

// createEvnt (String rRCode,

// String DriverID)

Created Automatically

create when

driver.confirm(Ride)

use beleif

Ride

<<Beleif>> Ride

Attribute

key

// String rCode

// String DriverID

value

// Enum Status

Figure 8: Structural Diagram – ClubCar Example.

7 RELATED WORK

Agile development and SA have been identiﬁed as the

fourth position among the top ten research questions

that should be addressed by the community (Freuden-

berg and Sharp, 2010). The actual researches on this

area are focused on quantity of SA rather than quality

(Babar et al., 2013). SA is seen as a human activ-

ity based on designers experience meaning that most

architectures are ad-hoc and only some follow a de-

ﬁned pattern (Booch, 2008). Many practitioners have

argued that model-driven engineering as well as user-

center design are beneﬁcial for constructing a SA in

the agile environment (Babar et al., 2013). We point

to the development of a SA not following patterns but

aligned on the structure of requirements.

Towards an Agent-driven Software Architecture Aligned with User Stories

343

To the best of our knowledge, there is no work

on mapping the US to agent SA. In most existing re-

search, US are generated and decomposed from the

SA elements. (Lefﬁngwell, 2010) proposes the scaled

agile framework that emphasizes on the importance of

building the SA to support development. They how-

ever do not furnish any mechanism for building and

and tracing the SA. (Perez et al., 2014) propose a sim-

ilar framework that bridges US to SA elements; US

are nevertheless considered as ﬁne-grained elements

only.

We can also focus on the use of US in agent meth-

ods. In Agile PASSI (Chella et al., 2006), US are used

as requirement artifact for communication but its their

only usage. US, speciﬁcally in MaSE (DeLoach et al.,

2002), is one source of requirements for capturing

the goal of the agent (Wood and DeLoach, 2001) but

without formal transformation. (Gaur and Soni, 2012)

use fuzzy theory to provide a systematic and method-

ical approach to explore various dependencies such as

goal, task, resource or soft-goal from US. Again the

technique is limited at analysis stage with no transfor-

mation. In contrast, (Tenso and Taveter, 2013) adopt

agent-oriented modeling in agile development. They

provide a method for decomposing a goal into sub-

goals and link them to US elements. (Carrera et al.,

2014) use US as testing mechanism for agent-oriented

software development. Only one US template is used

and aligned to JBehave (http://jbehave.org).

8 CONCLUSION

The quest for agility has, in the recent years, been

conducted in several domains and, behind the buzz

word, companies are looking for a high-level of align-

ment between user requirements and software as well

as rapid respond to change. This paper has proposed

to map US – THE requirements models of agile soft-

ware development methods like SCRUM and XP –

with an agent-based SA in order to implement a soft-

ware system made of Agents mapping organizational

behavior at run-time. The transformation process can

be partially automated for rapid response to change

and to avoid a heavy documentation process.

Future work includes a full validation on the

ideas on a broader case study. A plug-in support-

ing the automatic transformation of US elements into

the proposed SA is under development within the

DesCARTES Architect CASE Tool.

REFERENCES

Abrahamsson, P., Babar, M. A., and Kruchten, P. (2010).

Agility and architecture: Can they coexist? IEEE

Software, 27(2):16–22.

Babar, M. A., Brown, A. W., and Mistrik, I. (2013). Agile

Software Architecture: Aligning Agile Processes and

Software Architectures. Morgan Kaufmann Publ.

Booch, G. (2008). Architectural organizational patterns.

Software, IEEE, 25(3):18–19.

Carrera,

A., Iglesias, C. A., and Garijo, M. (2014).

Beast methodology: An agile testing methodology for

multi-agent systems based on behaviour driven devel-

opment. Info. Syst. Frontiers, 16(2):169–182.

Chella, A., Cossentino, M., Sabatucci, L., and Seidita, V.

(2006). Agile passi: An agile process for designing

agents. International Journal of Computer Systems

Science & Engineering, 21(2):133–144.

Cohn, M. (2004). User Stories Applied: For Agile Software

Development. Addison Wesley.

DeLoach, S. A., Matson, E. T., and Li, Y. (2002). Apply-

ing agent oriented software engineering to cooperative

robotics. In FLAIRS Conference, pages 391–396.

Freudenberg, S. and Sharp, H. (2010). The top 10 burning

research questions from practitioners. IEEE Software,

27(5):8–9.

Gaur, V. and Soni, A. (2012). A novel approach to explore

inter agent dependencies from user requirements. Pro-

cedia Technology, 1:412–419.

Kiv, S., Wautelet, Y., and Kolp, M. (2012). Agent-driven

integration architecture for component-based software

dvpt. Trans. Comp. Collect. Intell., 8:121–147.

Lefﬁngwell, D. (2010). Agile software requirements: lean

requirements practices for teams, programs, and the

enterprise. Addison-Wesley Professional.

Perez, J., Diaz, J., Garbajosa, J., and Yage, A. (2014).

Bridging user stories and software architecture: A tai-

lored scrum for agile architecting. In Agile Software

Architecture, pages 215–241.

Pokahr, A., Braubach, L., Haubeck, C., and Ladiges, J.

(2014). Programming BDI agents with pure java. In

uller, J. P., Weyrich, M., and Bazzan, A. L. C.,

editors, Multiagent System Technologies - 12th Ger-

man Conference, MATES 2014, Stuttgart, Germany,

September 23-25, 2014. Proceedings, volume 8732 of

LNCS, pages 216–233. Springer.

Pokahr, A., Braubach, L., and Jander, K. (2013). The jadex

project: Programming model. In Ganzha, M. and

Jain, L. C., editors, MAS and Applications - Volume

1: Practice and Experience, volume 45 of Intelligent

Systems Reference Library, pages 21–53. Springer.

Pokahr, A., Braubach, L., and Lamersdorf, W. (2005).

Jadex: A BDI reasoning engine. In Bordini, R. H.,

Dastani, M., Dix, J., and Fallah-Seghrouchni, A. E.,

editors, Multi-Agent Programming: Languages, Plat-

forms and Applications, volume 15 of MAS, Artiﬁcial

Societies, and Simulated Organizations, pages 149–

174. Springer.

Shergill, M. P. K. and Scharff, C. (2012). Developing multi-

channel mobile solutions for a global audience: The

ICAART 2016 - 8th International Conference on Agents and Artiﬁcial Intelligence

344

case of a smarter energy solution. SARNOFF’12, New

Jersey.

Tenso, T. and Taveter, K. (2013). Requirements engineering

with agent-oriented models. In ENASE, pages 254–

259.

Wautelet, Y., Heng, S., Kolp, M., and Mirbel, I. (2014).

Unifying and extending user story models. In CAiSE

2014, Thessaloniki, Greece, June, 2014. Proceedings,

volume 8484 of LNCS, pages 211–225. Springer.

Wood, M. F. and DeLoach, S. A. (2001). An overview of

the multiagent systems engineering methodology. In

Agent-Oriented Soft. Eng., pages 207–221. Springer.

Yu, E., Giorgini, P., Maiden, N., and Mylopoulos, J. (2011).

Social Modeling for Requirements Engineering. MIT

Press.

Towards an Agent-driven Software Architecture Aligned with User Stories

345