A Process for Requirement Traceability in Agent Oriented Development

1
A Process for Requirement Traceability in Agent
Oriented Development

• Rosa Pinto
• Carla Silva
• Jaelson Castro

2
Outline

• Motivation
• Tropos framework
• Requirements traceability Meta-model
• The Requirements Traceability Process
• Case Study
• Related Work
• Conclusions

3
Motivation

• In Complex systems there are quite complex web
  of relationships.
• Methodologies supporting requirement
  traceability can develop higher quality software
  with fewer costs

• Requirements Traceability
• Requirements traceability refers to the ability
  to describe and follow the life of a requirement,
  in both a forwards and backwards direction
  (i.e., from its origins, through its development
  and specification, to its subsequent deployment
  and use, and through all periods of on-going
  refinement and iteration in any of these
  phases.).
  
  Pinheiro 2003
• Agent Oriented Development Software

4
Our Proposal

• Agent Oriented Software Development

5
Tropos Framework
Ontology
Actors, social dependencies, goals, resources,...
Application area
(Requirements-driven) Software development
Agent-Oriented Programming
Detailed design
Early requirements
Architectural design
Late requirements

• Tropos, in Greek, means manner (as in manner of
  doing things)
• Depender -? dependum -? dependee

6
SD Diagram for Medi_at_ System

• Depender -? dependum -? dependee

Organizational Map
7
SR Diagram for Medi_at_ System
Rationale Map
8
Requirements Traceability Reference Model

• Requirement Management sub-model Toranzo 2002 e
  2005

9
Requirements Traceability Reference Model

• Design sub-model Toranzo 2002 e 2005

10
Requirements Traceability Reference Model

• Rational Model Toranzo 2002 e 2005

11
Requirements Traceability Process

• Stages of process
• 1. Information Gathering (IG) used to
• identify the information to be traced ltIG1, IG2,
  IG3 e IG4gt
• 2. Information Structuring (ST) used to
• achieve the proper structuring of the
  information identified before ltST1 e ST2gt, and
• defined the set of valid values for association
  instances ltST3gt
• 3. Definition of the Traceability Matrixes (TM)
  used to
• guide the construction of the appropriate
  traceability matrixesltTM1 e TM2gt

12
Requirements Traceability Process

• 1. Information Gathering (IG)
• IG1. Requirement Management sub-model classes
  from SD diagram of the actor representing
  the system
• Rules

1. Actor which has some dependency
relationship with Systems actor
? STAKEHOLDER class
13
SD Diagrama for Medi_at_ System
Organizational Map
STAKEHOLDERS
14
Requirements Traceability Process

• 1. Information Gathering (IG)
• IG1. Requirement Management sub-model classes
  from SD diagram of the actor representing
  the system
• Rules

1. Actor which has some dependency
relationship with Systems actor
? STAKEHOLDER class
2. Systems actor is dependee of
softgoal, resource or task the
dependum ? REQUIREMENT class
15
SD Diagrama for Medi_at_ System
Organizational Map
STAKEHOLDERS
REQUIREMENTS
16
Requirements Traceability Process

• 1. Information Gathering (IG)
• IG1. Requirement Management sub-model classes
  from SD diagram of the actor representing
  the system
• Rules

1. Actor which has some dependency
relationship with Systems actor
? STAKEHOLDER class
2. Systems actor is dependee of
softgoal, resource or task the
dependum ? REQUIREMENT class
3. Systems actor is dependee of goal
Organizations actor ?
ORGANIZATIONAL OBJECTIVES class
17
SD Diagrama for Medi_at_ System
Organizational Map
STAKEHOLDERS
REQUIREMENTS
ORGANIZATIONAL OBJECTIVE
18
Requirements Traceability Process

• 1. Information Gathering (IG)
• IG1. Requirement Management sub-model classes
  from SD diagram of the actor representing
  the system
• Rules

1. Actor which has some dependency
relationship with Systems actor
? STAKEHOLDER class
2. Systems actor is dependee of
softgoal, resource or task the
dependum ? REQUIREMENT class
3. Systems actor is dependee of goal
Organizations actor ?
ORGANIZATIONAL OBJECTIVES class
4. Systems actor is dependee of goal
isnt the Organizations actor ?
SYSTEM OBJECTIVES class
19
SD Diagrama for Medi_at_ System
Organizational Map
STAKEHOLDERS
REQUIREMENTS
ORGANIZATIONAL OBJECTIVE
SYSTEM OBJECTIVE
20
Requirements Traceability Process

• 1. Information Gathering (IG)
• IG1. Requirement Management sub-model classes
  from SD diagram of the actor representing
  the system
• Rules

1. Actor which has some dependency
relationship with Systems actor
? STAKEHOLDER class
2. Systems actor is dependee of
softgoal, resource or task the
dependum ? REQUIREMENT class
3. Systems actor is dependee of goal
Organizations actor ?
ORGANIZATIONAL OBJECTIVES class
4. Systems actor is dependee of goal
isnt the Organizations actor ?
SYSTEM OBJECTIVES class
5. Systems actor is depender of goal,
softgoal, resource or task the
dependum ? EXTERNAL class
21
SD Diagrama for Medi_at_ System
Organizational Map
STAKEHOLDERS
REQUIREMENTS
ORGANIZATIONAL OBJECTIVE
SYSTEM OBJECTIVE
EXTERNAL
22
Requirements Traceability Process

• 1. Information Gathering (IG)
• IG2. Requirement Management sub-model classes
  from SR diagram of the actor representing
  the system
• Rules

1. Goal ? SYSTEM OBJECTIVES
class
2. Task ? REQUIREMENT class
3. Softgoal ? REQUIREMENT class
4. Resource ? REQUIREMENT class
23
Requirements Traceability Process

• 1. Information Gathering (IG)
• IG3. Rational model classes from the process
  for selecting the proper architectural style
• Rules

1. SUBJECT class ? issue on which a
decision must be taken
2. POSITION class ? alternative
solutions for the SUBJECT
3. ARGUMENT class ? some criteria used
for choosing the proper solution
4. ASSUMPTION class ? facts that must be
taken into account for choosing
the
proper solution
5. CONSTRAINT class ? limitations/restric
tions that must be taken into
account
for deciding the proper solution
6. DOCUMENT class ? some information
used as reference for choosing the
proper
solution
24
Requirements Traceability Process

• 1. Information Gathering (IG)
• IG4. Design Sub-model classes from the
  architectural design model
• Rules

1. Each architectural component ?
SUBSYSTEM class
25
Requirements Traceability Process

• 2. Information Structuring (ST)
• ST1. to remove classes unnecessary, and to
  delete instances with the same meaning

ST2. for each pair of associated classes in the
reference model, the association should be
instantiated
ST3. for each instance created in the ST2,
define the set of values assigned to it.
26
Requirements Traceability Process

• 3. Definition of the Traceability Matrixes (TM)

• Guideline TM1
• For each pair of instantiated classes which are
  associated in a reference model, we can create a
  traceability matrix.
• Guideline TM2
• For each created matrix, we have to analyze the
  system artifacts which are related to the matrix
  and fill the association which has been
  instantiated in a previous stage of the process.

• Applying TM1 and TM2
• create a traceability matrix to the instances of
  the ltltresourcegtgt association between REQUIREMENTS
  called
• Realized_by,
• Decomposition_req,
• Support_by and
• Contradict_by (Table 2, 3, 4, and 5).

27
Case Study
1. Estimating the impact of a change
The customer may wish to be informed of items
which might be related to the ones he has ordered
.
28
Case Study
IG2 Rule2 Task ? REQUIREMENT
29
Case Study

• Mapping of the components that participated in
  the means-ends relationship and task
  decomposition
• the tasks and softgoals elements in the
  Decomposition_req matrix
• the goals elements in the Decomposition_obj
  matrix

30
Case Study
IG2 Rule2 Task ? REQUIREMENT Goal ? SYSTEM
OBJECTIVES
31
Case Study

• Mapping of the components
• the goals elements in the Decomposition_obj
  matrix

32
Related Work

• Ramesh introduces the reference model to trace
  requirements. Ramesh 2001
• Our work includes new concepts and relationships
  types
• Gotel divided the traditional requirement into
  pre-requirement and pos-requirement traceability.
  Gotel 1996
• Our proposal explicitly addresses external and
  organizational aspects

33
Related Work

• Cysneiro presents an approach that can be used
  to generate traceability relations between
  organizational models specified in i and
  software systems models represented in UML.
  Cysneiro 2003
• Our work considers a reference model which
  supports building traceability matrixes for agent
  based systems.
• Haumer extends the type of pre-requirements
  traceability defined by Gotel. Haumer 2000
• Our proposal, beyond consider a requirements
  elicitation and validation phase, it encloses
  other phases of software development lifecycle,
  such as early requirements and architectural
  design phases.

34
Conclusions

• We outline a process that can be used to extend
  Tropos to address requirements traceability.
• We intend to develop a complete and usable
  requirement traceability process for Tropos
  aiming to ensure the quality improvement of both
  the methodology and the software developed with
  it.
• Our requirement traceability process is still
  evolving and further guidelines for instantiating
  all the classes of the three reference models
  (Requirement Management and Design sub-models and
  Rational model) for each phase of Tropos may be
  required.