PDE 1 Introduction to Dynamic Requirements Definition Learn

PDE 1 – Introduction to Dynamic Requirements Definition Learn about the definition of dynamic requirements by understanding the current business problems. © 2005 -2006 The ATHENA Consortium.

Course description • The course presents the methodology to deal with the Dynamic Requirements Definition (DRD) in current business environments. • The course will show the methodology allows the users to extract the specific requirements from: – Description of the business scenario; – Presentation of the interoperability issues. • The course also explains the concepts that have been developed in ATHENA regarding the requirements definition and handling. © 2005 -2006 The ATHENA Consortium. 2

Course objective • The participants will learn: – – About the DRD Methodology; How to extract requirements; How to describe interoperability problems; How to propose a business scenario. © 2005 -2006 The ATHENA Consortium. 3

Introduction to Dynamic Requirement Definition (DRD) <Presenter> <Company>, <Country> <E-mail> © 2005 -2006 The ATHENA Consortium.

Outline • • • Interoperability Issues Dynamic Requirement Definition Methodology Describing Business Scenarios Conclusive remarks References © 2005 -2006 The ATHENA Consortium. 5

What is ATHENA? © 2005 -2006 The ATHENA Consortium. 6

R&D for applications • • © 2005 -2006 The ATHENA Consortium. Enterprise modelling: How to deal with business information; Cross Business Process: How to deal with business information exchange between different actors; Ontology; ATHENA Interoperability Framework: Integration of ATHENA Tools and definition of a common Framework Service-Oriented Architectures; Model-Driven Architectures; Business Documents & Protocols: Definition of standardized Business documents; SMEs in practice: Definition of an standardized use case specific for SMEs; 7

R&D for business • • • © 2005 -2006 The ATHENA Consortium. Community creation: Deals with policy issues as well as setting EIC; Knowledge Sharing: Deals with the knowledge transfer through Newsletters, papers publication, conferences management (I-ESA) and marketing activities; Biz Interoperability Research: Deals with the interoperability among enterprises at an enterprise level; DRD: Deals with the scenario definition and establishment of requirements; Piloting activities: Deals with the testing of the ATHENA developed tools and their improvement; Training: Deals with the Knowledge transfer through Training courses; 8

Interoperability Issues © 2005 -2006 The ATHENA Consortium. 9

Definition Interoperability Issue (def. ) is “a problem concerning interoperability extracted and elicited from analysis of business scenarios, analyzed and modeled” – ATHENA Consortium They relate to data-sharing view and workplace-sharing © 2005 -2006 The ATHENA Consortium. 10

Other useful definitions (1) • MAPPING: – Issues/requirements mapping; – The way that the interoperability issues will be connected to the requirements. • METHODOLOGY (ISO 15704, 1999): – A set of instructions (provided through text, computer programs, tools, etc. ) that is a step-by-step aid to the user. • PILOT: – The implementation of use case solutions in a real context of industrial users; – Employed to test in a limited context the goodness of a use case solution before its extension on the whole enterprise reality. • SCENARIO: – Use case instance showing system user sequences, a specific running of the use case; – Is a description of a user interaction with a system or alternatively can be defined as an Use Case instance; – Set of detailed activities. © 2005 -2006 The ATHENA Consortium. 11

Interoperability Issues classification • The interoperability issues should be classified • Levels of the Interoperability Framework: – Business level interoperability issues; – Knowledge level interoperability issues; – ICT level interoperability issues. © 2005 -2006 The ATHENA Consortium. 12

Dynamic Requirement Definition © 2005 -2006 The ATHENA Consortium. 13

Other useful definitions (2) • DYNAMIC REQUIREMENTS – Process dealing with interoperability requirements gathering, elicitation, analysis and management; – Implies to consider an evolutionary process ensuring agility of interoperation when dealing with always accelerating change rhythm. • REQUIREMENT – A statement of a customer wish without specifying how that wish will be implemented. – Can be grouped into 'essential', 'useful' and 'desirable'. – Relates to multiple viewpoints and a viewpoint can be decomposed into multiple requirements. – Role-views: • Information/Data, Roles, Tasks, Views – Role-oriented views of requirements aspects: • How to handle • How to interpret and extract meaning and impact • How to meet/solve/fulfil © 2005 -2006 The ATHENA Consortium. 14

Other useful definitions (3) • FUNCTIONAL REQUIREMENT: – Specifies what the system must be able to do. – Associated with specific functions, tasks or behaviour the system must support. – Used at both the user requirements analysis and software requirements specifications phases in the software life cycle; – Capture the intended behaviour of the system; – Fundamental subject matter of the system and are measured by concrete means like data values, decision making logic and algorithms; – Action that the system must be able to take, something that the product must do. • NON-FUNCTIONAL REQUIREMENT: – Aspect of the system other than its capacity to do things; – Behavioural property that the specified functions must have, such as performance, usability, etc. – Can be assigned a specific measurement; – A property that the eventual system must have © 2005 -2006 The ATHENA Consortium. 15

Other useful definitions (4) • REQUIREMENT ANALYSIS: – Phase in which the initial set of requirements from the Elicitation phase are analysed for conflicts, overlaps, omissions and inconsistencies. – Stakeholders negotiate to agree on a set of consistent system requirements. • REQUIREMENT CLASSIFICATION: – Process of grouping related requirements into class hierarchies. – To group common requirements based on well-defined expertise areas. • REQUIREMENT ELICITATION: – Phase in which an initial set of requirements for a system are discovered. • REQUIREMENTS HARMONISATION: – Activity in which the requirements from the Requirements Analysis phase are integrated and harmonized. • REQUIREMENT VALIDATION: – Phase in which the requirements document is reviewed and formally validated. © 2005 -2006 The ATHENA Consortium. 16

Phases to extract requirements • Requirement determination – – Elicitation Analysis Negotiation Validation • Requirement modelling • Requirement management © 2005 -2006 The ATHENA Consortium. 17

Requirements Analysis (1) • Aims: – Identifying commonalities, differences and dependencies between specific requirements; – Abstracting them from the specific characteristic of their origin; – Elaborating ATHENA requirements. © 2005 -2006 The ATHENA Consortium. 18

Requirements Analysis (2) • Requirements can be classified as: – Specific requirements, which are the requirements coming from the business scenario to be analyzed; – Generic requirements, which are requirements not sensitive to any particular scenario, methodology, platform or situation. • Particularly, ATHENA Requirements: – Are interoperability requirements – Derived from generic and specific requirements considering them: • • Objectives of ATHENA; Interoperability Issues; Business and Technology drivers; Pilot applications © 2005 -2006 The ATHENA Consortium. 19

Requirements Analysis (3): Method of Work • Usage of a common classification schema: – To facilitate the requirements analysis; – To support viewing the requirements from various viewpoints. • Classify the requirements: – Usage of a DRD System, i. e. a complex database • ATHENA Requirements: © 2005 -2006 The ATHENA Consortium. 20

Methodology for extracting requirements © 2005 -2006 The ATHENA Consortium. 21

Introduction • Write down common views for: – Planning – Forecasting – Replenishment • Procedure to extract requirements – Procedure developed under the ATHENA Programme – The aims of the procedure are: • Be integrated and coherent with the methodology shown, and eventually to complete and refine it; • Support and experiment a model based approach to the overall process; • Be aligned with Users’ expectations expressed through the AS-IS business scenarios and the TO-BE scenarios; © 2005 -2006 The ATHENA Consortium. 22

A (step-wise) Procedure for Extracting Requirements Step 0 Prerequisite s • • • Step 1 Busin ess Case Step 2 Interop erability Use Case & Scenario Step 3 a Extract Specific Reqs from Scenarios Step 3 b Generic Requirement Consolidation Step 4 Require ment Generaliz ation Ste p 5 Ste p 6 I mpl em ent V alid ate Step 0 – Prerequisites: Decide on the essentials to follow the procedure; Step 1 – Business Case (formalization of the): Describe/formalize the business case using a modelling approach. Step 2 – Interoperability Use Case & Scenario: Focus on interoperability issues and provide scenario, e. g. hypothesis of solution to the non-interoperability situation. Step 3 a – Extract Specific Requirements from Scenarios: Analyse the business case, by confronting current situation (As-Is) and foreseen scenario, and drive out the requirements for making it happen Step 3 b – Consolidate Generic Requirements: Consolidation of the set of generic requirements that are to be confronted with specific requirements at generalization step. Even that this step is supposed not to be part of the procedure, it is included here for the sake of completeness. Step 4 – Specific Requirements Generalization: Generalize specific requirements in view of Athena and Generic Requirements; Consolidate and Compare across usecases; Categorize Requirements. © 2005 -2006 The ATHENA Consortium. 23

Step 0 – Prerequisites Step 0 Prerequisite s Step 1 Busin ess Case Step 2 Interop erability Use Case & Scenario Step 3 a Extract Specific Reqs from Scenarios Step 3 b Generic Requirement Consolidation Step 4 Require ment Generaliz ation Ste p 5 Ste p 6 I mpl em ent V alid ate • Static views and models • Ensure that a set of basics are agreed upon, in order to avoid misunderstanding, miscommunication and consequently prevent pitfalls: – Agree on an Enterprise Analysis/Modelling approach; – Commit to use a common Scenario Template; – Agree on a common vocabulary and documents of reference set to work with; – Define the condition of application © 2005 -2006 The ATHENA Consortium. 24

Step 1 – Business Case Step 1 Step 0 Prerequisite s Busin ess Case Step 2 Interop erability Use Case & Scenario Step 3 a Extract Specific Reqs from Scenarios Step 3 b Generic Requirement Consolidation Step 4 Require ment Generaliz ation Ste p 5 Ste p 6 I mpl em ent V alid ate • Objective & Goals: – Focus at this stage is to have full understanding of the business case. • Recommendations: – Describe the business case using modelling techniques; – Start from already existing descriptions; – User and Modelling Expert close interaction • Outputs: – User and Modelling Expert close interaction; – Possible improvement for business case (optional); – Proposed improvements for scenario templates (optional); © 2005 -2006 The ATHENA Consortium. 25

Step 2 – Interoperability Use Case & Scenario Step 1 Step 0 Prerequisite s Busin ess Case Step 2 Interop erability Use Case & Scenario Step 3 a Extract Specific Reqs from Scenarios Step 3 b Generic Requirement Consolidation Step 4 Require ment Generaliz ation Ste p 5 Ste p 6 I mpl em ent V alid ate • Objective & Goals: – Focus on the problems (interoperability issues) by identifying the situation (instances of use cases) where interoperability is needed. • Recommendations: – Formalize use-cases using modelling techniques; – Try to explain why there is non-interoperability (optional); • Outputs: – Use Cases; – (To-Be) Scenario description; – Proposed improvements for scenario templates (optional); © 2005 -2006 The ATHENA Consortium. 26

Step 3 a – Specific Requirement Extraction (1) Step 1 Step 0 Prerequisite s Busin ess Case Step 2 Interop erability Use Case & Scenario Step 3 a Extract Specific Reqs from Scenarios Step 3 b Generic Requirement Consolidation Step 4 Require ment Generaliz ation Ste p 5 Ste p 6 I mpl em ent V alid ate • Objective & Goals: – The goal is to analyse the business case, by confronting current situation (As-Is) and foreseen scenario, and drive out the requirements for making it happen. Requirements considered here are specific requirements as they relate to a specific business case (e. g. the one being worked upon). • Recommendations: – Identify the "points to improve"; – The TO-BE solution is designed following the same steps; – Compare AS-IS and TO-BE to deduce specific requirements; • Outputs: – Set of Specific Requirements; © 2005 -2006 The ATHENA Consortium. 27

Step 3 a – Specific Requirement Extraction (2) • Guidelines for Requirement Extraction: – In the TO-BE Scenarios, there will be new services that do not exist in AS-IS scenarios, like: • Order tracking; • Smooth direct program to program interaction (e. g. automatic purchase requirement calculation for several tier suppliers); • Work procedures (e. g. joint parallel access to same drawings during co-design by OEM-Suppliers). – These new services have to be created – they are the requirements; – Set of Specific Requirements, needed to be fulfilled to reach interoperability without obstacles: • • Program interaction (per domain); New software modules; Collaboration Services; Protocol Standards; Ontologies / terms / glossaries; Process descriptions (SCOR); Trust building; Community building © 2005 -2006 The ATHENA Consortium. 28

Step 3 b – Generic Requirement Consolidation Step 1 Step 0 Prerequisite s Busin ess Case Step 2 Interop erability Use Case & Scenario Step 3 a Extract Specific Reqs from Scenarios Step 3 b Generic Requirement Consolidation Step 4 Require ment Generaliz ation Ste p 5 Ste p 6 I mpl em ent V alid ate • Recommendations: – Drive generic requirements from experience: know-how, past projects, etc…; – Drive generic requirements from bibliographic sources; – Drive generic requirements from software and application providers and business analyzers; • Outputs: – Set of Generic Requirements; © 2005 -2006 The ATHENA Consortium. 29

Step 4 – Requirement Generalization Step 0 Prerequisite s Step 1 Step 2 Receive specific requirement s Require ment Generaliz ation Step 3 b Generic Requirement Consolidation Analyse them in the context of Project Relevance to objectives © 2005 -2006 The ATHENA Consortium. Step 3 a Extract Specific Reqs from Scenarios Interop erability Use Case & Scenario Busin ess Case Step 4 Rel evanc e to the driver s Classi fy Review / Identify relationshi ps Relevance to Interop. Issues Ste p 5 Ste p 6 I mpl em ent V alid ate Model Requirem ents Relevance to the pilots 30

Step 4 – Requirement Generalization: Analyse Requirements in the Context of the project • Specific requirements are analysed to identify the requirements for the purpose; • By reviewing them in the light of the project, by considering the following: – – Objectives of the project; Interoperability Issues; Business and technology drivers; Pilot applications; • This process must provide a set of generic requirements; • The following information about the generic requirements may be determined: – Stakeholders; Priority; Risks; Application area; Technology Area/drivers; Business implications © 2005 -2006 The ATHENA Consortium. 31

Step 4 – Generic Generalization: Classify Requirements and Review Relationships • Classify Requirements: – Process of assigning requirements to one or more classes that are defined in the requirements classification structure; – Sub-process of elaborating specific requirements; – Generic requirements must also be classified according to one or more appropriate classes; • Review Relationships among the requirements and identify new ones: – Link specific requirements to other specific requirements; – Relationships among generic requirements should also be identified and established; – Relationships identified among the specific requirements should be reviewed to determine if they are still applicable in the generic; – There may be relationships not identified in the specific requirements and must be identified and established – The types of relationships that may exist among generic requirements are: • • • Similarity; Dependency; Conflict; Contains/overlaps; Affects © 2005 -2006 The ATHENA Consortium. 32

Step 4 – Generic Generalization: Model Requirements (1) • Use of guidelines from Enterprise Modelling; • To obtain a quick overview of the context of any requirement or a group of requirements; • The various information that have been gathered and determined to describe the requirements are structured into various concepts within an enterprise • Why? – To describe the requirements in a structured manner and to view them according to a desired way • Benefits: – – – – Reuse; Links to everything; Conflict resolution; Link to architecture; Recognise patterns; Support for the negotiation and validation; Different views; © 2005 -2006 The ATHENA Consortium. 33

Step 4 – Generic Generalization: Model Requirements (2) • Beneficiaries: – – Stakeholders of requirements; Developers or solution providers; European Interoperability Centre (EIC); Researchers in the area of requirements management and interoperability; • Facilitates the structuring, viewing and management of large quantities of information; • The following information about the requirements should be identified and represented in the model: – – – – Application area; Stakeholders Technology driver Business driver/goals Level of impact on the enterprise Risk and for which group of stakeholders Indication of resource requirements to fulfil requirement The scope of the requirement © 2005 -2006 The ATHENA Consortium. 34

Describing Business Scenarios © 2005 -2006 The ATHENA Consortium. 35

Other useful definitions (5) • BUSINESS SCENARIO – Scenario describing a concrete case of collaboration within a given enterprise, including encountered problems to make it effective, that is relevant to extract interoperability issues. – May include results of some investigation or evaluation of solutions which were unsuccessful and related requirements coming from the enterprise. – Chain of business transactions that share a common dependency on either time or an event: • Event-driven scenarios are those that are based on a particular event, such as the receipt of a sales order; • Time-based scenarios are those that are based not on a particular event but on the passage of time. Such processes include month-end closing, standard cost revaluation, check run, and possibly data reorganization. © 2005 -2006 The ATHENA Consortium. 36

Other useful definitions (6) • BUSINESS CASE – System in which the ESAI (Enterprise Software Application Interoperability) will be analysed and defined. • BUSINESS PROCESS – It is defined by ISO 15704 in 1999 as “A partially ordered set of enterprise activities that can be executed to realise a given objective of an enterprise or a part of an enterprise to achieve some desired end-result. ” • BUSINESS SCENARIO PROCESSES – Representation of a complete set of chronologically and logically interrelated processes that cover a given business task. – A process definition generally consists of many activities that are connected for the purpose of defining a process flow or state transition network. © 2005 -2006 The ATHENA Consortium. 37

Other useful definitions (7) • TEST CASE: – A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. • TEST PROCEDURE: – Step-by-step process needed in order to verify that the product meets all the interoperability requirements established. • TEST SCENARIO: – Scenario identifying test environment. A test scenario can be defined as a Test Case instance. • TO-BE SCENARIO: – Scenarios built from initial scenario implying a subset of targeted solutions; – Describe the ideal situation, considering that the targeted solutions will be available; – Envisaged ideal situation in which Interoperability problems don’t exist. © 2005 -2006 The ATHENA Consortium. 38

Other useful definitions (8) • USE CASE: – It is a functional requirement for a Business Case. – It is a collection of possible sequences of interactions between the system under discussion and its Users (or Actors in Business Processes), relating to a particular goal. – Defines a goal-oriented set of interactions between external users and the system under consideration or development. – Use cases allow capturing functional requirements for a Business case. • VALIDATION: – Confirmation by examination and provision of objective evidence that: • specifications conform to user needs and intended uses, • the particular requirements implemented can be fulfilled. – The primary focus of validation is customer satisfaction. – Validation (for software) is the process of evaluating software to ensure compliance with specified requirements [ISO 9000 -3: 1991, 3. 7] © 2005 -2006 The ATHENA Consortium. 39

Describing a Scenario (1) • Description of the situation in two moments: – Current situation: AS-IS scenario – Desired situation: TO-BE scenario • Should include the description of: – – The business context; Involved processes and actors; Information exchanged; Systems used. • Improvements caused by the application of Generic Solutions • Roles participating in the scenario and their relationships and business objectives. • A high-level description of the Requirements: – Functional Requirements; – Non-Functional Requirements. © 2005 -2006 The ATHENA Consortium. 40

Describing a Scenario (2) • Description of the Interoperability Issues: – – Conceived as high-level Interoperability Needs; Derived by the scenario analysis; Identify the Interoperability Gaps of the AS-IS Scenario; Identify the Technological Problems needed to be addressed. • Description of the Business benefits and expectations: – A forecasted Business Benefits and Expectations by applying the solutions and implementing the TO-BE. • Description of the Glossary: – Explanation of the terms and acronyms used. © 2005 -2006 The ATHENA Consortium. 41

Example 1 of a Business Scenario: e. Procurement in Furniture sector (I) • Introduction: – Introduction to the furniture sector both in economical aspects and in business aspects; – Introduction to the use of the e. Procurement activities in the furniture industry; – Statement of the objectives of the furniture industry with the use of e. Procurement activities. • Scenario description: – Full description of the processes involved in the e. Procurement; – AS-IS situation: description of the current processes involved of the industry’s way of doing business, with current actors, business units, problems; – TO-BE situation: description of the desired situation to be achieved by using ATHENA tools. – Make use of data-flow graphs; – Description of partners involved in the processes with their roles, relationships, business objectives and requirements. © 2005 -2006 The ATHENA Consortium. 42

Example 1 of a Business Scenario: e. Procurement in Furniture sector (II – AS-IS) RETAILER R 1. Request for Quotation R 2. Quotation R 3. Order Delivery Interior Decoration Project R 4. Order Confirmation Customer communication Looks for furniture Delivery M 1. Request for Quotation M 2. Quotation Invoice R 5. Delivery Note R 6. Packing List M 3. Order M 4. Order Confirmation R 7. Invoice MANUFACTURER Delivery M 5. Delivery Note PROVIDER M 6. Invoice © 2005 -2006 The ATHENA Consortium. 43

Example 1 of a Business Scenario: e. Procurement in Furniture sector (III – Use Case) ßAS IS TO BE © 2005 -2006 The ATHENA Consortium. 44

Example 1 of a Business Scenario: e. Procurement in Furniture sector (IV) • Interoperability issues – Statement of the issues which will define the scenario; – By the analysis of the requirements placed; – Classify them according to the levels of the Interoperability framework. • Business benefits and expectations – Description of the Business benefits; – According to the ATHENA Subprojects: • • • Enterprise modelling; CBP; Ontology; Service-Oriented Architectures; Model-Driven Architectures. Relationships with ATHENA key objectives – Description of the relationship of the scenario according to the ATHENA Key Objectives; – Use of the Classification of: • Business objectives; • Strategic objectives; • Scientific and technical objectives. • Glossary / Acronyms © 2005 -2006 The ATHENA Consortium. 45

Example 1 of a Business Scenario: e. Procurement in Furniture sector (V) Major reduction in false/incorrect orders Better integration between internal systems Dramatic shortening of time from order to delivery PERMASA Business Objectives Ability to search new providers and apply Permasa criteria to rate those providers © 2005 -2006 The ATHENA Consortium. Dramatic reduction in surplus stock in warehouse 46

Example 2 of a Business Scenario: Product Development in Aerospace sector (I) Principle of the collaboration space for Networked Collaborative Product Development (NCPD) © 2005 -2006 The ATHENA Consortium. 47

Example 2 of a Business Scenario: Product Development in Aerospace sector (II) NCPD Organization and Infrastructure Pilot scenario NCPD organization Governance of the network Set up, Design, Development , Enactment and support of the NCPD infrastructure based on Standards ATHENA results Design of NCPDI © 2005 -2006 The ATHENA Consortium. Development and enactment of NCPDI Governance of NCPDO 48

Example 2 of a Business Scenario: Product Development in Aerospace sector (III) Usage of ATHENA results for NCPD Pilot aims: – provide requirements on interoperability – test – evaluation of impact Usage of the AIF (A 4) © 2005 -2006 The ATHENA Consortium. Usage of CBP (A 2, A 5) Usage of Model Driven Approach (A 6, A 3) 49

Example 2 of a Business Scenario: Product Development in Aerospace sector (IV) Dynamic Requirement Definition for NCPD Distinction between – – generic requirements (expected functions) Generic solutions (generic capabilities) Specific requirements (business context specific needs) Specific solutions (specific technical environment constraints plus concrete implementations - or software product) It was facilitated by structuring existing standards of the industrial sector that already support such distinction STEP AP © 2005 -2006 The ATHENA Consortium. STEP technological framework binding with ICT technologies 50

Conclusive remarks © 2005 -2006 The ATHENA Consortium. 51

Conclusive remarks (1) • The description of the requirements should facilitate and possible their analysis; • A good scenario description enables the extraction of the requirements; • Classifying and modelling the requirements aids in interpreting and managing them; • It is necessary to compare the requirements extracted against: – – Project Objectives, Interoperability Issues, Business and Technology drivers, and Pilot applications. © 2005 -2006 The ATHENA Consortium. 52

Conclusive remarks (2) • The procedure to extract requirements follow a sequence of steps, and in each one we study: – – – Prerequisites; Business case; Interoperability Use case & scenario Specific requirements extraction; Generic requirements consolidation; Requirements generalization. • The description of the scenario should include: – – – Current and desired situation; Business context, processes, actors, information exchanged, … Improvements caused; Roles, relationships and business objectives; Business benefits and expectations; Interoperability Issues © 2005 -2006 The ATHENA Consortium. 53

References © 2005 -2006 The ATHENA Consortium. 54

References [ATHENA] ATHENA, "ATHENA Public Web Site", ATHENA Integrated Project (IST-507849). http: //www. athena-ip. org/ [ATHENA] ATHENA, “D. B 4. 1 Dynamic Requirement Definition Principles", ATHENA Consortium [ATHENA] ATHENA, “D. B 4. 3 Scenarios Mapped with Interoperability Issues", ATHENA Consortium [DATASIM] Data. Sim Software http: //www. people. cornell. edu/pages/mcs 5/Pages/Data. Sim. Page. htm © 2005 -2006 The ATHENA Consortium. 55

This course has been developed under the funding of the EC with the support of the EC ATHENA-IP Project. Disclaimer and Copyright Notice: Permission is granted without fee for personal or educational (non-profit) use, previous notification is needed. For notification purposes, please, address to the ATHENA Training Programme Chair at rg@uninova. pt. In other cases please, contact at the same e-mail address for use conditions. Some of the figures presented in this course are freely inspired by others reported in referenced works/sources. For such figures copyright and all rights therein are maintained by the original authors or by other copyright holders. It is understood that all persons copying these figures will adhere to the terms and constraints invoked by each copyright holder. © 2005 -2006 The ATHENA Consortium. 56