+ All Categories
Home > Documents > Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis,...

Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis,...

Date post: 08-Oct-2020
Category:
Upload: others
View: 0 times
Download: 0 times
Share this document with a friend
96
Programme Integrating and Strengthening the European Research Strategic Objective Networked Businesses and Governments Integrated Project / Programme Title Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application Acronym ATHENA Project No 507849 ATHENA – Project Name Dynamic Requirements Definition ATHENA - Project No B4 Deliverable DB4.1 Dynamic Requirements Definition Principles Work package – B4.1 Leading Partner: EADS Security Classification: PP September, 2004 Version 1.0
Transcript
Page 1: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

Programme

Integrating and Strengthening the European Research Strategic Objective

Networked Businesses and Governments Integrated Project / Programme Title

Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application

Acronym

ATHENA Project No

507849 ATHENA – Project Name

Dynamic Requirements Definition ATHENA - Project No

B4

Deliverable DB4.1

Dynamic Requirements Definition Principles

Work package – B4.1 Leading Partner: EADS

Security Classification: PP

September, 2004

Version 1.0

Page 2: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL

Versioning and contribution history

Version Description Comments 0.10 Starting point to elaborate the initial draft, provided by EADS CCR to

INTRACOM and IPK (040906_ATHENA_D.B4.1_V0)

0.11 Initial Draft after Rot discussions. Use of ATHENA template, first editing and comments by Maria Anastasiou

0.12 Compilation of contribution from: o Maria Anastasiou (INTRACOM)

(040908_ATHENA_DB41_V01.doc) o Thomas Knothe (IPK)

(040906_ATHENA_D.B4.1_V0_IPK_input for elicitation) o Sobah Abbas Petersen (COMPUTAS)

(athena_b41_ch4_reqneg.doc) with following notes • Requirements Management can be considered as

part of Introduction. • Requirements Analysis can be elaborated in chapter

3. • The main focus of this is on chapter 4. • All this can be expanded once the general idea and

framework has been accepted.

A simple cut and paste compilation, without any changes from EADS except:

o Indication of the contributor input come from within the text when overlapping

o correction of the template of 0.1

o completion of versioning and contribution history

o Renumbering of figures

o Systematic usage of signet for the principles. Short description is written only once

o Inclusion of correction provided by Jorg during Rot.

0.13 Integration of contribution of Ippolito Massimo Terminology updated by Nicolas FIGAY according Jorg comments

0.14 Integration of IPK contribution V2 (3.2) and Graisoft contribution (3.1) Correspond to 040915_ATHENA_DB41_V10c.doc

0.15 Integration of Computas contribution, V1 for 3.3 and V2 for 3.4, with some presentation changes by NFI Integration of Maria first draft of overview Plus comment and proposal for change by Nicolas. Integration of some complementary lines from Thomas for the section of Ippolito

0.16 Restructuring of the document by NFI, that will be reflected by MAN in 1.0f. 1.0f will be distributed tomorrow morning as baseline for next iteration on Friday, before to send next version to the reviewers

0.17 Update of summary and introduction, some English improvement, editing work use of styles (body text for main text, Liste PC01 for first level bullet points, Liste PC02 for second level bullet points, Listen NR PC01 for numbered items at first level) by Maria Anastasiou.

0.18 Integration of updated schemas, updated links with principle by Thomas, new section concerning generic requirement gathering, introduction chapter for the principles, architectural patterns withdrawn, minor correction within the appendixes.

0.19 Integration of Thomas contribution (cross referencing), sobah’s corrections and terminology review by Nicolas, with some extra correctio – final integration.

0.20 Version submitted to internal and external reviewers 0.21 Version taking into account comments and corrections from internal

and external reviewers

1.0 Version taking into account comment of PCC delegates

Page 3: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL

Table of contents

1 Summary................................................................................................................................... 1 2 Introduction ............................................................................................................................... 2 2.1 Objectives................................................................................................................................................ 2 2.2 Method of Work ....................................................................................................................................... 3 2.3 Structure of the Document....................................................................................................................... 3 3 Requirements Handling in ATHENA – Methodology and Guidelines ....................................... 4 3.1 Introduction.............................................................................................................................................. 4 3.2 Elaborate Specific Requirements Coming from Scenarios ...................................................................... 7 3.2.1 Principles for Requirements Determination .......................................................................................... 7 3.2.2 Objectives ....................................................................................................................................... 8 3.2.3 Scope and Approach ............................................................................................................................ 8 3.2.4 Result ....................................................................................................................................... 9 3.2.5 Process Step Description ................................................................................................................... 10 3.2.6 Use of Enterprise Modelling................................................................................................................ 12 3.3 Elaborate Generic Requirements .......................................................................................................... 14 3.4 Scenario Specific Requirements and Generic Requirements ................................................................ 15 3.4.1 Requirements Classification ............................................................................................................... 16 3.4.2 Generalization Process....................................................................................................................... 18 3.5 Requirements Negotiation ..................................................................................................................... 22 3.5.1 Negotiating Parties ............................................................................................................................. 23 3.5.2 General Negotiation Process.............................................................................................................. 24 3.5.3 Negotiation Parameters ...................................................................................................................... 25 3.5.4 Negotiation Techniques ...................................................................................................................... 25 3.5.5 Support Required for Requirements Negotiation ................................................................................ 26 3.6 Validate Requirements and Prepare Solutions Acceptance Criteria ...................................................... 26 3.6.1 Introduction ..................................................................................................................................... 26 3.6.2 Requirements Validation Process....................................................................................................... 27 3.6.3 Validation Checklist ............................................................................................................................ 29 3.6.4 Relations to Piloting activities ............................................................................................................. 29 4 Dynamic Requirements Principles .......................................................................................... 30 4.1 Overview................................................................................................................................................ 30 4.2 Principles List ........................................................................................................................................ 31 4.3 Principles Description ............................................................................................................................ 32 5 Dynamic Requirements Definition (DRD) Terminology .......................................................... 40 5.1 Introduction............................................................................................................................................ 40 5.2 Structure ................................................................................................................................................ 40 5.3 Definitions.............................................................................................................................................. 40 6 References.............................................................................................................................. 50 6.1 Documents ............................................................................................................................................ 50 6.2 Organisations ........................................................................................................................................ 50 7 Acronyms ................................................................................................................................ 52 Appendix A. Requirements: multi-viewpoint analysis........................................................................ 54 Appendix B. Requirements Management Technology Overview...................................................... 75 Appendix C. Patterns for interoperability of Heterogeneous Enterprise Networks and their

Applications....................................................................................................................... 77

Page 4: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL

Figures Figure 1 ATHENA Dynamic Requirements Process............................................................................... 4 Figure 2 ATHENA projects and ATHENA Dynamic Requirements Process .......................................... 5 Figure 3 ATHENA Dynamic Requirements process and Requirements Engineering ............................ 6 Figure 4: Requirements Elicitation - Scope............................................................................................. 8 Figure 5 Requirements description template .......................................................................................... 9 Figure 6 Elaborate ATHENA Requirements.......................................................................................... 10 Figure 7 Process Model that illustrates the Interoperability Issue......................................................... 12 Figure 8 Properties of Today not Interoperable Systems along the Process View............................... 13 Figure 9 Object Part of Structure – Information Technologies (IT) Architecture................................... 13 Figure 10: Specific to Generic Requirements ....................................................................................... 15 Figure 11: IDEAS Interoperability Framework....................................................................................... 17 Figure 12: Requirements Generalization Process ................................................................................ 19 Figure 13: Requirements Negotiation in ATHENA................................................................................ 23 Figure 14: Negotiating Parties............................................................................................................... 24 Figure 15: General Negotiation Process ............................................................................................... 24 Figure 16 Requirements Validation Process......................................................................................... 27 Figure 17 Application Protocol 233 requirement model in EXPRESS G .............................................. 64 Figure 18 Relationships Between Program and Project ....................................................................... 65 Figure 19 Usual Project Life Cycle........................................................................................................ 66 Figure 20 Usual product life cycle ......................................................................................................... 66 Figure 21 Phases of Project Life Cycle ................................................................................................. 67 Figure 22 Complex Project and Life Cycle............................................................................................ 67 Figure 23 The Waterfall Model .............................................................................................................. 67 Figure 24 The Incremental Model ......................................................................................................... 68 Figure 25 The Evolutionary Model ........................................................................................................ 69 Figure 26 The Spiral Model ................................................................................................................... 71 Figure 27 Matrix of Project Life Cycle Choice according Constraints ................................................... 72 Figure 28 The two Worlds of an Enterprise Application........................................................................ 81 Figure 29 Projection on Conceptual Axis .............................................................................................. 82 Figure 30 Enterprise Information System Inside enterprise.................................................................. 83 Figure 31 Inter Enterprise Common Reference Models ....................................................................... 84 Figure 32 What a Networked Enterprise could be ................................................................................ 85 Figure 33 Interoperability Supported at all the Layers of an Application .............................................. 85 Figure 35 Cross-organisation BP .......................................................................................................... 87 Figure 36 Process Description an IDEF0-like Way............................................................................... 87 Figure 37 Interoperability for a Process Centric Approach ................................................................... 88 Figure 38 Software Product Against Applicative System...................................................................... 89 Figure 39 AIF supporting both Applicative Systems and Software Product ......................................... 90 Figure 40 Software Product - Applicative Systems Relationships ........................................................ 90 Figure 41 Software Products - Applicative Systems Relationships in a B2B context ........................... 91

Page 5: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 1 / 92

1 Summary

Activity of B4 project, “Dynamic Requirements Definition (DRD)”, aims to continuously collect and synthesise industrial user requirements, and provide them to research and development through iterative input and feedback loops. The objective is to ensure that ATHENA will get results which are truly relevant and meaningful for a maximum set of practical applications in industry.

To achieve this, the B4 activity will provide a methodology for dynamic requirements gathering, elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements Definition System (DRDS) in order to support all ATHENA projects, and apply it to the business scenarios that will be produced.

In this context, the deliverable DB4.1, “Dynamic Requirements Definition Principles”, aims to provide the foundation of the methodology to be used for requirements handling and the associated principles that guide its definition and application within the ATHENA programme and, in the future, within the European Interoperability Centre (EIC).

It aims to be used by B4 partners, other requirements providers (B3, Action Line (Action Line A projects), by solution providers (Action Line A) and finally by the industrial users that will validate the solutions (project B5), when applying the proposed Dynamic Requirements Definition methodology.

To fulfil these objectives, DB4.1 provides: • A methodology: based on current practices for requirements engineering, the methodology

describes a process adapted to the purpose of ATHENA, i.e. interoperability of enterprise applications and software, the different activities to perform (gathering requirements, elicit requirements…) and tools to perform these activities (e.g. classification, categorisation, negotiation tools…).

• Guidelines: how to apply the methodology in the ATHENA and EIC context. For example which projects and stakeholders profiles will be implied to perform such or such activity, role and usage of ATHENA key objectives for negotiation of requirements to be addressed…

• A set of 21 principles to be adhered to by ATHENA/EIC members: for example “Generic solutions from Action Line (AL) A projects must address generic interoperability issues”(principle 11, c.f. section 4 Dynamic Requirements Principles).

• A set of definitions: a terminology associated with the methodology, the principle and the B4 project. For example, definition of “Generic Solution”: “Within the ATHENA Dynamic Requirements Process and Methodology, solutions generated by Action Line (AL) A projects, that are specific scenarios independent. From the generic solutions, specific and generic Information Technologies (IT) solutions will be developed respectively within Piloting activities and as exploitation of the results to provide product on the market.”

• A body of reference information on requirements management: for example external references (e.g. INCOSE) or appendixes provided with the document (“Requirements: multi-viewpoint analysis”, “Requirements Management Technology Overview”, “Patterns for interoperability of Heterogeneous Enterprise Networks and their Applications”).

Bearing in mind this future target, methodology and principles provided in DB4.1 are anticipated to be updated during the ATHENA program in order to reflect the experience gained through the practical use of the methodology inside ATHENA and the consensus built around the principles, as well as to consider handling requirements coming from additional user communities and organisations outside ATHENA consortium.

The provided methodology will be instrumented through the Dynamic Requirements Definition System (DRDS) and instantiated by the targeted projects throughout the project, in order to allow the ATHENA program to provide to the EIC effective tools and approach to address needs of the communities concerning Interoperability of Enterprise Applications and software within a Networked Organisation.

Page 6: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 2 / 92

2 Introduction

2.1 Objectives Activity performed within the B4 project, “Dynamic Requirements Definition”, aims to continuously

collect and synthesise industrial user requirements, and provide them for research and development through iterative input and feedback loops. The objective is to ensure that ATHENA will get results which are truly relevant and meaningful for a maximum set of practical application in industry.

To achieve this, B4 project will provide the following results: • A Method for

o Defining ATHENA interoperability requirements to be addressed from industrial users (c.f. specific requirements) or from others sources (c.f. generic requirements)

o Prioritising the interoperability issues to be address by ATHENA from analysis and negotiation activities taking into account the interest of the different stakeholders and the key objectives of the program

o Insuring traceability from the requirements to the generic and specific solutions, developed, identified or validated (pilots) by ATHENA.

The method will be applied in the context of ATHENA programme in order to provide a coherent and common way for the different projects to perform their activities concurrently, following spiral or evolutionary project life cycles, and to integrate as soon as possible evolution of the context in terms of solutions or needs coming from the market. This is the reason why we are talking about dynamic requirements process. • A System that supports the definition, storage, retrieval, sharing, validation, analysis, negotiation

and traceability of the requirements and associated solutions, within ATHENA programme and between the different stakeholders and actors concerned.

• A set of scenarios that capture industry specific requirements. Scenarios are identified by the users and provide experience and requirements of the larger community to guide research activities in Action Line A.

• Analysis of the scenarios that will extract interoperability requirements, identify commonalities and differentiation factors between the various scenarios.

• A mapping approach to support requirements mapping with interoperability issues and the identification of existing technical solution or the need for new or improved ones to address the derived interoperability requirements.

In this context, the objective of this report is to form the foundation of the methodology to be used for requirements handling in ATHENA and the associated principles that guide this methodology definition and application within ATHENA and, in the future, the European Interoperability Centre (EIC).

As already mentioned, initially, the methodology and system developed will be applied and implemented in the context of the ATHENA programme in order to provide a coherent and common way for defining user requirements for interoperability features and service definition and thus support Action Line (AL) A research projects. However, it is envisaged that B4 together with all Action Line (AL) B activities, will be migrated into the European Interoperability Centre (EIC). To this end, D.B4.1 is anticipated to be a living document that will be further updated to reflect the experience gained through the practical use of the methodology inside ATHENA and the consensus built around the principles, as well as to consider handling requirements coming from additional user communities and organisations outside ATHENA consortium.

Page 7: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 3 / 92

2.2 Method of Work This document was developed in the context of Work Package B4.1 Initialisation, and it is the

result of several discussions, workshops and interactions between partners involved in activity B4 in collaboration with representatives from Action Line A and other action line B activities to ensure common understanding and agreement. The results of these exchanges have been formalized by the mean of Patterns for interoperability of Heterogeneous Enterprise Networks and their Applications (Appendix C) and by the development of B4 specific and shared terminology.

The work performed is the amalgam of the knowledge and expertise of ATHENA Enterprise Modelling and Ontology experts and Industrial Users’ experience. It also exploits the experience gained in previous projects (IDEAS Thematic Network and Unified Enterprise Modelling Language (UEML) Thematic Network) and takes under consideration the state of the art in Requirements Engineering, (Appendices A, B), the patterns for interoperability and B4 terminology.

Both the Terminology and the Patterns for interoperability of Heterogeneous Enterprise Networks and their Applications are tools aimed to be shared within the ATHENA programme, and to evolve according to the reaction and feedback from other projects in ATHENA through Task B4.1.3 activities (Technical coordination of the ATHENA Integrated Project).

2.3 Structure of the Document The document is structured into three main parts. The first part of the document (Chapter 3) presents the methodology that the ATHENA

programme is using for handling requirements. First, it provides an overview of the main phases of the methodology and then proceeds to describe, in more detail, the activities that will be performed within the context of activity B4: • Elaboration of specific requirements coming from scenarios aimed at assigning in an efficient way

industrial needs and requirements according to interoperability issues specific for various sectors and process types to common requirements classes.

• Association of scenario specific requirements with generic requirements coming from other sources such literature, Action Line (AL) A research projects, etc.

• Negotiation to reach an agreement between the developers and stakeholders and among the stakeholders to reach an agreement that is mutually acceptable for all parties involved.

• Requirements validation to examine the set of the collected requirements against quality criteria (such as validity, consistency, completeness, realism, etc.) and support the development of acceptance test plan within the piloting activities.

The second part of the document (Chapter 4) presents the Dynamic Requirements Principles that were established to guide the elaboration of Dynamic Requirements methodology and the development of the Dynamic Requirements Definition system.

The third part of the document (Chapter 5) presents a set of definitions and references that is / should be shared by ATHENA partners within the context of Dynamic Requirements Definition.

The document provides also three appendices: • Appendix A briefly refers to the state of the art analysis and practice in Requirements

Engineering, linked to interoperability issues on the one hand, and on project and program life cycle types on the other. The presented state of the art was considered during the elaboration of the requirements handling methodology.

• Appendix B provides a brief overview of requirements management technology. • Appendix C presents general patterns of Heterogeneous Enterprise Networks and their

Applications that are important for the definition of requirements. These patterns were used to facilitate the discussions during the elaboration of the Dynamic Requirements Definition (DRD) methodology, the establishment of several Dynamic Requirements Definition principles and the interaction within the ATHENA Programme.

Page 8: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 4 / 92

3 Requirements Handling in ATHENA – Methodology and Guidelines

3.1 Introduction Within ATHENA Programme, several projects are dealing with the subject of “Requirements”.

Considering this, it was proposed in the meeting of B4 Activity that was held in Lisbon (15 March 2004) to create a Process to describe the link between the various activities to elaborate the Requirements: This process is called the ATHENA Dynamic Requirements process.

We will recall that “a Requirement” is a process by which the “customer” needs are understood and documented by the “supplier of solutions”.

The requirements express “what” is to be built and NOT “how” it will be built. Usually the “document requirements” serves:

• as a contract between the “customer” and the “supplier” or “developer in Information Technologies (IT) industry”,

• as a source of test plans, • to specify project goals, plan development, cycles and increments.

The ATHENA Dynamic Requirements Process is described in Figure 1 ATHENA Dynamic Requirements Process.

P2 Select Generic

Requirements

P1 Select Specific

Requirements

P6Develop

Generic ITProducts

P7 Develop Specific IT Products

P3 Elaborate ATHENA

requirements

P4 Search for Generic

Solutions

P5 Develop Generic

Solutions

Scenarios

External world

Generic Requirements

Information

Generic Requirements

Specific Requirements

ATHENA Requirements

List of potential genericsolution Generic

Solutions

Market

Validation Scenarios,

Demonstration

Figure 1 ATHENA Dynamic Requirements Process

We determine two origins for the requirements. The first one is the set of scenarios proposed by the industrial users in the ATHENA Programme. Initially four families of scenarios are planned in the following applicative area: • Supply Chain Management • Collaborative Product Development • e-Procurement • Portfolio Management

From these scenarios, an initial set of requirements must be determined: we call these requirements

Page 9: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 5 / 92

Specific Requirements. On the other hand, a lot of requirements have already been proposed by the literature, other

projects, in particular the Unified Enterprise Modelling Language (UEML) Project (IST – 2001 - 34229) and IDEAS Thematic Network (IST-2001-37368). We call these requirements Generic Requirements.

In both cases, the objective of the first activities (P1 and P2) is to determine which requirements belong to the ATHENA Programme domain. So from P1 and P2 we get the Specific and Generic Requirements for ATHENA. The third activity (P3) is to analyse and select this set of ATHENA Requirements in order to: • Determine the requirements according to interoperability issues, • Collect the needed information about requirements including a classification according to

industrial needs (inside and outside ATHENA), priority in terms of market,etc. • Provide consistent requirements definition.

The rest of the phases in Figure 1 is outside the scope of the B4 Activity, but they are very important in order to have the complete process:

P4: Based of the selected Athena Requirements, the list of Potential Generic solutions will be determined

P5: After an agreement inside the project, the adapted Generic Solutions will be produced P6: Generic Information Technologies (IT) Products1 will be proposed by the Information

Technologies (IT) suppliers P7: Specific Information Technologies (IT) products will be proposed to the ATHENA Industrial

Users in order to answer to the initial requirements deduced from the scenarios. Some specifics validation scenarios, in accordance of realised Test plans, will be outputs of P7 (c.f. 3.5.4).

Indication concerning the projects that will supply the results is given in Figure 2 ATHENA projects and ATHENA Dynamic Requirements Process.

P2 Select Generic

Requirements

P1 Select Specific

Requirements

P6 Develop Generic ITProducts

P7 Develop Specific IT Products

Requirements

P3 Elaborate ATHENA

requirements

P4 Search forGeneric

Solutions

P5 Develop Generic

Solutions

Scenarios

External world

Generic Requirements

Information

Generic Requirements

Specific Requirements

ATHENA Requirements

List of potential genericsolution Generic

Solutions

Market

AL A & B3

B4

AL A

B5

Spiral (<=Traceability)Validation Scenarios,

Demonstration

Figure 2 ATHENA projects and ATHENA Dynamic Requirements Process

1 In the context of ATHENA Dynamic Requirements Process, a product is considered as a concrete implementation of a given solution, in particular the tools that can be produced by solution providers.

Page 10: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 6 / 92

ATHENA Dynamic Requirements Process is the requirements engineering process that is applied for the ATHENA project as this process takes into account the various projects that compose ATHENA and the fact that requirements come from various sources, as both generic and specific requirements. This section of the document considers Dynamic Requirements Process in the light of the classical requirements engineering approach to illustrate how ATHENA Dynamic Requirements Process addresses the same issues that are addressed in classical requirements engineering.

The classical requirements engineering process consists of the following sub-processes: • Requirements determination and gathering. • Requirements elicitation, analysis and modelling. • Requirements negotiation. • Requirements validation.

Figure 3 shows the ATHENA Dynamic Requirements Process and how it corresponds to the classical requirements engineering process.

P2 Select Generic

Requirements

P1 Select Specific

Requirements

P6 Develop Generic ITProducts

P7 Develop Specific IT Products

Requirements

P3 Elaborate ATHENA

requirement

P4 Search for Generic

Solutions

P5 develop Generic

Solutions

Scenarios

External world Market

Validation Scenarios,

Demonstration

GATHERGATHER

GATHERGATHER

ELICITANALYSE

MODEL

ELICITANALYSE

MODEL

NEGOTIATENEGOTIATE VALIDATEVALIDATE

NEGOTIATE &VALIDATENEGOTIATE &VALIDATE

Figure 3 ATHENA Dynamic Requirements process and Requirements Engineering

Requirements Determination and Gathering Requirements are gathered from Action Line (AL) A and Action Line (AL) B projects and these

requirements will be considered in the context of the ATHENA project. Action Line (AL) A and B3 will provide a set of generic requirements while Action Line (AL) B will provide a set of specific requirements. These requirements can be modelled for the purpose of managing them and viewing information related to them in a structured manner.

Requirements Elicitation, Analysis and Modelling The requirements elicitation sub-process provides an initial set of requirements for ATHENA which

can then be generalised and analysed according to the objectives of the project and interoperability issues. The requirements can then be categorised according a specific classification and modelled for the purpose of managing the requirements and the information related to them.

Page 11: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 7 / 92

Requirements Negotiation Requirements negotiation takes place between the developers and stakeholders and among the

stakeholders to select a set of requirements that is mutually acceptable for all parties. For example, to agree upon the requirements that will be fulfilled by a particular solution.

The requirements negotiation may occurs at different places (c.f. Figure 13: Requirements Negotiation in ATHENA), within different sub-processes of the Dynamic Requirements Definition Process, e.g. P5 and P7. It is due to the fact that in P5, the negotiation will be about developing generic solution addressing given ATHENA requirements, and about prioritisation of this development. In P7, the negotiation will be about developing a pilot or not, that will take into account some other constraints, as the available resources in P5 for the pilot development. The negotiating parties and stakeholders are not the same in P5 and P7. Requirements Negotiation is detailed in 3.5 Requirements Negotiation.

Requirements validation Requirements validation is conducted to examine the set of requirements to find out potential

problems with these requirements.

3.2 Elaborate Specific Requirements Coming from Scenarios

3.2.1 Principles for Requirements Determination The following principles are the base for the first step in the ATHENA requirements gathering and

analysis procedure2.

Principle No. Definition Principle 2 There is a need for a Reference Model for ATHENA requirements. The

Reference Model must reflect the complexity of the socio-economic structure of the stakeholders and the actors for interoperability purposes.

Principle 4 Requirements can’t come directly from the Action Line (AL) B activities to each Action Line (AL) A project without elicitation, prioritisation and analysis that will allow a coherent distribution between the different projects.

Principle 6 There is a need for the Dynamic Requirements Definition to support the categorization of requirements according to research activities and type of applications.

Principle 8 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must establish links between industrial scenarios, research and pilots.

Principle 10 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must support traceability between specific needs from B4, structured generic business needs and interoperability issues.

Principle 11 Generic solutions from Action Line (AL) A projects must address generic interoperability issues.

Principle 12 Dynamic Requirements Definition System and Process will support definition of innovative instrumented methodologies that address specific needs.

Principle 13 All ATHENA projects are “end-users” of the Dynamic Requirements Definition System (DRDS).

Principle 19 Business scenarios analysis and interoperability issue identification should imply usage of interoperability patterns.

2 The following table just provides links with section 4, by providing principle short description and principle number. To see detailed descriptions of the principles, c.f. section 4

Page 12: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 8 / 92

3.2.2 Objectives The following objectives are relevant for this step:

• To assign industrial needs and requirements according to interoperability issues specific for various sectors and process types to common requirements classes in an efficient way.

• To collect the needed information about the requirements including reasons and the business background of the requirements as much as possible

• To provide consistent requirements definition – avoid overlapping • To tackle requirements that are in the scope of interoperability of enterprises and applications

3.2.3 Scope and Approach In the Figure 4, the scope of the “Specific Requirements Elicitation” is described. This starts by

having an initial scenario that addresses one or more interoperability issues coming from the actual or near future enterprise operations. The description can be specific from the sector (e.g. automotive), process (e.g. purchasing), organisational (e.g. establishment of virtual organisations) or Information Technologies (IT)-systems (Enterprise Resource Planning or ERP – Enterprise Modelling Tool relationship). So it is also possible to address only one interoperability issue without a holistic scenario.

Elaboration of specific

requirements

Initial Scenario Definition

Specific Technical

Requirements

Specific Business

Requirement

Interoperability Issue

OutputInput

Figure 4: Requirements Elicitation - Scope

The outputs are specific technical or business requirements. Business requirements address the need of an interoperability solution that fits a business objective - e.g. “Need for a system that supports the organisational interaction between manufacturing engineering and product development in the ramp up phase before start of production (SOP)”. A specific technical requirement addresses the functionality or the quality of a solution – e.g. “It should be possible to generate from a software code a part of an enterprise model automatically”.

In order to prepare and facilitate Requirements gathering, elicitation, analysis, validation and negotiation, Requirements from both categories can be defined with various types of: • Levels of abstraction: The dynamic requirements determination should be able to involve

different roles in an enterprise (not only end-user or business managers). For that reason different kinds of abstraction levels should be possible (E.g. “Enterprise modelling should be less cost consuming” or “It should be possible to allow interoperability between time discrete execution systems like A and event controlled systems like B for exchanging bill of material data”).

• Process or sector specifics: The requirements should address sectors and non sector-specific issues (e.g. “The solution should be able to connect Action Request System Remedy with the Information Technologies (IT) systems shop floor control system in order to provide a holistic overview on order management” or “The solution should be able to combine MS Office products seamless with workflow management systems”).

• Domain specifics: Requirements can have influence on several solution domains like workflow systems, execution environments, backend systems or enterprise modelling.

• Personal specifics: All stakeholder interests on enterprise and application interoperability should be addressed, so their needs and objectives have to be taken into account.

Page 13: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 9 / 92

• Organisational specifics: The needs and requirements often depend on the industrial organisational structures. The elicitation environment has to taken into account e.g. virtual organisations or matrix structures.

• Information Technologies (IT):systems specifics, proprietary or open, they have different background. So the Dynamic Requirements Definition System (DRDS) will allow system specific requirements (e.g. “to connect to Microsoft internet information server”) or vendor independent systems requirements.

For explanation of the scenarios and for a better understanding of the requirements issues, models (enterprise models) are recommended. These models can contain the following information on instance and class levels: • Process descriptions • Information flows • Decision flows • Organisational structure and role descriptions • Systems descriptions • Product structure and variant descriptions • Business architectures

All model elements can be related to each other. For modelling the content, several modelling languages and tools as described in the DA1.1.1 “First Version of State of the Art in EM technology to support enterprise interoperability” can be used.

The enterprise models should be owned and preferably maintained by the scenario providers.

3.2.4 Result In the Figure 5, a partially completed template for describing each single specific requirement is

shown. It was derived from the results of the IDEAS and the Unified Enterprise Modelling Language (UEML) projects.

ID Name

25Specific work environments for different

project phasesApproach Topic

Background Is-Situation

Information exchange and cooperation in development projects is weakly supported and mainly addressed by administrative project systems (e.g. MS project, task planning systems).

Desired Situation (Requirement Description)

Demand to define project specific work environments supporting all three main phases (Selection and Analysis, Screening and Operational Feedback).

Problem SpaceExisting ResearchExisting Technology

Existing Standards

Gap Analysis Research Gap

Technology Gap

Standard Gap

Priority

Time Horizon

Relevance to Scenario E Procurement

Supply Chain Scenario

Collaborative Product Design x

Portfolio Management

other

Comments/NotesModel Name:

Model Element

Stakeholder INTRACOM, IPK Berlin

REQUIREMENT TABLE

Requirement

Model Link

Identification code

RequirementName

Scenario : could be one or more… Observations

Company Name

Importance

The Requirement should be developed for ..

Distance from the s.o.a. and the objective

State of the art of the

requirement

Objective to reach

Other information concerning the

requirement

Model to Scenario

Figure 5 Requirements description template

Page 14: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 10 / 92

The following properties at minimum are required for further analysis: • ID • Name • “Is” or “desired” situation • Model Link if possible

The requirements have to be related as much as possible to the given scenario descriptions and relevant enterprise models.

3.2.5 Process Step Description In the following Figure 6 the tasks for this process step is indicated. The next subchapters will

describe in detail these tasks.

Requirements description

Assign requirements to categories

Requirements refinement

Link the requirements to others

Figure 6 Elaborate ATHENA Requirements

3.2.5.1 Initial description of the requirements

The template (Figure 5) will be used for analysis of each requirement coming from the scenario in order to identify the minimum requested properties of the description. Additional information for describing a set of requirements can be obtained by the following activities: • Questionnaire to the requirements stakeholder. • Interviews with involved end-users or business specialists. • Interviews with one or more peers that represent the end-users. • Document analysis of existing information about the interoperability issues. • Derive from the scenario an enterprise model, if not existing. Modelling should be done by a

common team with people that provides solutions and the scenario provider The scenario provider has to choose the appropriate methodology by consultation with the cross

Action Line (AL) teams. This analysis method can be executed during all other steps. As an example, the following functional requirement from the aeronautic scenario will be used.

“The systems will allow to integrate legacy systems, with few resources, or to provide distant services to the sub-contractor to support his/her collaboration (e.g. Product Data

Management functionalities and access to the product and industrial project data)” In order to harmonise the description, the spelling of the description has to be rephrased “The

systems should allow to…”. If possible, the link between requirements and given models should be provided, with as many details and information as possible.

In Table 1, the result of the first description is shown. So, only four elements are defined.

Page 15: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 11 / 92

ID Name

10 Easy integration of legacy systems

Approach Topic

Background Is-Situation

Desired Situation (Requirement Description)

The systems should allow to integrate legacy systems, with few resources, or to provide distant services to the sub-contractor to support his collaboration (e.g. PDM functionalities and access to the product and industrial project data)

Priority Highly desirable

Relevance to Scenario E Procurement

Supply Chain x

Collaborative Product Design x

Portfolio Management

otherModel Name:

Model Element

Stakeholder EADS CCR

REQUIREMENT TABLERequirement

Model Link

Table 1 First Fulfilled Template from the Aeronautic Scenario

3.2.5.2 Assignment to categories

The requirement can now be assigned to requirements classes or properties. This is necessary to allow requirements comparing and identification of already existing similar requirements. On the other hand the classification can be used for collecting additional information about business issues behind the requirement. Depending on the already existing scenario description this task has to be executed in collaboration with the requirements stakeholder. The following properties and classification issues are relevant:

Categories • Abstraction level (to be defined) • Interoperability issue and goal • Requirements origin (functional, non functional)

Properties • Sectors (e.g. automotive industry, service industry public sector) • Domain (e.g. enterprise modelling, model driven architecture, ) • Actors (e.g. Business Manager, Knowledge Worker) • Urgency (e.g. must, highly desirable) • Time frame to solve the problem (e.g. already solved, in 10 Years) • Organisational Scope (e.g. networked enterprises, intra-enterprise collaboration)

3.2.5.3 Requirements refinement

By using the Dynamic Requirements Definition System (DRDS), similar requirements will be identified automatically during requirements definition. Also simple search algorithms should be used for finding related requirements. The selected requirements similar to a new one can now be analysed in order to secure consistency. So the following activities can be done: • Reject the new or the existing requirement in case of full overlapping. • Refine the new requirement in order to erase overlapping – the effect could be that already

existing requirements will be refined in order to ensure consistency. On the other hand new classes can be defined. Both the refinement of existing requirements and the change of requirements structure should be done by the administrator only.

• Split the new requirement in order to allow integration into the requirements classification.

Page 16: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 12 / 92

3.2.5.4 Link the requirements to others

The last step for specific requirements definition is the link to other requirements in order to support further analysis and negotiation. The linking can be executed • By having a common substructure, like the one defined for common interoperability issues – no

additional activity is necessary. • By having a common set of properties –no additional activity is necessary. • By addressing a specific interoperability issue of one scenario – here the issue can be used as

common relation.

3.2.6 Use of Enterprise Modelling Enterprise models can be used for the explanation of the interoperability issues addressed by the

scenario. The following explanations are based on a small IEM model that addresses today not integrated legacy systems as mentioned in the requirements example in subchapter 3.2.5.1 Initial description of the requirements for enquiry processing in a company. So in the process view, media breaks along organisational processes can be illustrated (see Figure 7).

Conflict because of media break

Figure 7 Process Model that illustrates the Interoperability Issue

The process model also indicates the relevant roles in the enterprises that are involved in the process execution. Information breaks can also be analysed in detail by showing the properties of the systems that are not interoperable at present (Figure 8).

Page 17: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 13 / 92

Properties of the Systems

Missmatch

Figure 8 Properties of Today not Interoperable Systems along the Process View

In order to analyse the enterprise objects several views and diagrams can be used. The views should be integrated to each other in order to ensure consistent relations. As example, see Figure 9, the Information Technologies (IT) Architecture of the company is sketched as part-of-structure. Here all disconnected systems can be identified in order to follow a holistic approach to integrate different Information Technologies (IT) Systems. Especially for business analysts the relation between all views of the enterprise model should be possible. For that also tables and textual descriptions generated from a model will be helpful.

Disconnected Systems

Figure 9 Object Part of Structure – Information Technologies (IT) Architecture

The models should be used during all the other phases described in Elaborate Specific Requirements Coming from Scenarios, Elaborate Generic Requirements and Validate Requirements and Prepare Solutions Acceptance Criteria. Here business consequences of solutions that fit to the

Page 18: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 14 / 92

requirements can be identified and calculated. E.g. process the time reduction by reducing the information gaps or in this case by reducing the calculation activity through automatic calculations as well as cost reductions or by simulating new business organisation.

3.3 Elaborate Generic Requirements For issues of enterprise and application interoperability there will be generic requirements

collected from various sources: • Literature according to enterprise and application interoperability • B3 project Business Interoperability Research • Action Line A projects will define generic requirements according to their targeted achievements • IDEAS Project – requirements related to enterprise modelling, architecture and platform, and

ontologies • Unified Enterprise Modelling Language (UEML) Project – requirements related to enterprise

modelling collected from several viewpoints like Tool vendors, European projects, industrial users, standardisation.

The relevant principles for gathering the generic requirements are explained in the following list.3

Principle

Number Short description

Principle 2 There is a need for a Reference Model for ATHENA requirements. The Reference Model must reflect the complexity of the socio-economic structure of the stakeholders and the actors for interoperability purposes.

Principle 4 Requirements can’t come directly from the Action Line (AL) B activities to each Action Line (AL) A project without elicitation, prioritisation and analysis that will allow a coherent distribution between the different projects.

Principle 6 There is a need for the Dynamic Requirements Definition to support the categorization of requirements according to research activities and type of applications.

Principle 10 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must support traceability between specific needs from B4, structured generic business needs and interoperability issues.

Principle 11 Generic solutions from Action Line (AL) A projects must address generic interoperability issues.

Principle 13 All ATHENA projects are “end-users” of the Dynamic Requirements Definition System (DRDS).

Principle 14 There is a need for Action Line (AL) A technical requirements to be addressed by ATHENA

Principle 17 All the ATHENA projects are stakeholders and actors of the Dynamic Requirements Definition process

The generic requirements will be defined by using the template explained in Figure 5 but without indicating the relevant scenario. In order to ensure consistency the process steps for definition described in Figure 6 have be taken into account. With the exception of “level of abstraction” for categorisation and the property “sector” all aspects of the requirements definition can be used for broader explanation can be used.

3 The following table just provides links with section 4, by providing principle short description and principle number. To see detailed descriptions of the principles, c.f. section 4

Page 19: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 15 / 92

3.4 Scenario Specific Requirements and Generic Requirements Requirements in ATHENA are received from the Action Line (AL) A projects as generic

requirements and from Action Line (AL) B projects as specific requirements. The specific requirements come from industrial scenarios and will be specific to a particular industrial area or area of application. In ATHENA, there is a need to generalise these specific requirements, see Figure 10. This section discusses how the specific requirements may be generalised for the purposes of ATHENA.

Generalize specific requirements

Specific Business & Technical

Requirements from Action Line B

To Generic Business & Technical

Requirements for Action Line A

Figure 10: Specific to Generic Requirements

Specific requirements can be considered as requirements that represent situated knowledge. The meanings of specific requirements depend on the source of the requirements and the environment that it originates from such as the scenario, methodology, platform or a situation. Generic requirements, on the other hand, are not sensitive to any particular scenario, methodology, platform or situation. In order for the solution providers to provide a generic solution, there is a need to generalise specific requirements.

To generalise specific requirements for the purpose of ATHENA, the requirements must be considered in the light of the objectives of ATHENA, interoperability issues, business and technology drivers and the pilot applications that have been identified in ATHENA.

Page 20: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 16 / 92

The relevant principles for gathering the generic requirements are explained in the following list4.

Principle Number

Short description

Principle 4 Requirements can’t come directly from the Action Line (AL) B activities to each Action Line (AL) A project without elicitation, prioritisation and analysis that will allow a coherent distribution between the different projects.

Principle 5 There is a need to consider usage of the ATHENA interoperability Framework when analysing and classifying requirements in the Dynamic Requirements Definition methodology.

Principle 6 There is a need for the Dynamic Requirements Definition to support the categorization of requirements according to research activities and type of applications.

Principle 8 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must establish links between industrial scenarios, research and pilots.

Principle 11 Generic solutions from Action Line (AL) A projects must address generic interoperability issues.

Principle 12 Dynamic Requirements Definition System and Process will support definition of innovative instrumented methodologies that address specific needs.

Principle 18 To-be scenarios are to be elaborated by multidisciplinary teams, including end-users, technology providers and researchers

Principle 19 Business scenarios analysis and interoperability issue identification should imply usage of interoperability patterns.

3.4.1 Requirements Classification Requirements classification has been defined as “the process of grouping related requirements

into class hierarchies”, (See Terminology). The main purpose of creating groups of requirements is to categorize requirements based on well-defined classifications, such as areas of expertise. It also facilitates better viewing of requirements that may be relevant to the context of a particular solution, stakeholders’ interests and the different levels of abstraction of the enterprise.

There are different kinds of classification structures that can be applied to requirements to support different interest purposes and interests. This section proposes to utilize the research that has been done in the IDEAS project, i.e. the IDEAS Interoperability Framework, (INTEROP, 2004), and the ATHENA Interoperability Framework, [B3200402], to identify the different requirement classes.

4 The following table just provides links with section 4, by providing principle short description and principle number. To see detailed descriptions of the principles, c.f. section 4

Page 21: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 17 / 92

3.4.1.1 IDEAS Interoperability Framework

The IDEAS Interoperability Framework, see Figure 11. This framework can be interpreted as considering different aspects and abstraction levels of an enterprise as follows: 1. Business level 2. Knowledge level 3. Systems level

Framework 1st Framework 2nd ONTOLOGY QUALITY ATTRIBUTES

Semantics Security Scalability Evolution Decisional model

Business model

Business

Business process Organisation roles

Skills Competencies

QUALITY ATTRIBUTES

ENTERPRISE MODEL

Knowledge

Knowledge Assets

Performance Availability Portability

Solution Management

Work-place Interaction

Application logic

Application

Process Logic Product data Process data Knowledge data

Data

Commerce data

ARCHITECTUE Communication

Figure 11: IDEAS Interoperability Framework

Business Level: This is the level of an enterprise that is concerned with its business processes, business drivers and in making strategic decisions about an enterprise. To support this level of the enterprise, there is a need for a requirements classification structure that will help to identify requirements that pertain to the following classes: • Business Goals. • A specific industrial sector. • A specific application area. • A specific type or model of organization. • The specific product or service area. • A specific business process. • Stakeholders.

The IDEAS Interoperability Framework addresses the abstraction levels of a single enterprise. The ATHENA Interoperability Framework, [B3200402], addresses networks of enterprises (for various collaborative processes). Thus, it is also important to consider requirements that address a network of enterprises.

Page 22: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 18 / 92

Knowledge Level: This is the level of an enterprise that is concerned with its knowledge and intellectual assets. It concerns the people of an enterprise, the skills and competencies of the enterprise as well its knowledge assets. The knowledge assets of an enterprise consists of the methodologies and models that an enterprise uses and the meta-data that is used by an enterprise in performing their work. The requirements classification structures must help an enterprise to be able to do the following: • Identify the impact of a requirement on its knowledge assets and increase the value of its

knowledge assets. • Perform efficient resource allocation.

System Level: This is the level of an enterprise that is concerned with its Information Technologies (IT) infrastructure and capabilities. It is concerned with its Information Technologies (IT) architecture(s) at the data, application and communication levels. At this level, the requirements will be considered in terms of its impact on the Information Technologies (IT) architecture. One was of looking at this (in particular in software engineering) is to consider requirements in terms of: • Functional requirements – requirements that address a particular functionality of the product or

service. This could be in terms of system, user, interface, database, communication, security, etc. • Non-functional requirements – requirements that address other aspects of a system or service

such as performance. The system level will also consider the end-users of the system as well as the stakeholders of the

requirement.

3.4.2 Generalization Process The process of generalizing specific requirements can be considered as follows, see Figure 12:

• Receive specific requirements. • Analyse them in the context of ATHENA.

o Relevance to ATHENA objectives. o Relevance to interoperability issues. o Relevance to the ATHENA drivers. o Relevance to the ATHENA pilots.

• Categorise requirements. • Review relationships among the requirements and identify new ones. • Model requirements.

Page 23: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 19 / 92

ReceiveSpecific

requirements

CategorizeAnalyze them inthe context

of ATHENA

Review/identify

relationships

Relevance to interoper-

ability issues

Relevance toobjectives

Relevance to the

drivers

Relevanceto thepilots

ModelRequirements

Figure 12: Requirements Generalization Process

Receive Specific Requirements Specific requirements are received from Action Line (AL) B. These requirements may be specific

business requirements or specific technical requirements, see Elaborate Specific Requirements Coming from Scenarios. For the analysis of the requirements, it is important to understand the requirement and its context. Thus, it is important to have as much information about the requirement as possible. Some information that will be helpful is listed below: • The source of the information – the particular end-user or developer that provided the information. • The priority assigned by the source to the requirement, i.e. an indication of how important it is for

the source to have this requirement met in order for the him/her to progress with the work. • The scenario the requirement originated from, e.g. project. • The application the requirement originated from. • The relationship with the requirement and other requirements. • The classification assigned by the source to the requirement.

Analyse Requirements in the Context of ATHENA Specific requirements are analysed to identify the requirements for ATHENA by reviewing them in

the light of the ATHENA project, by considering the following: • Objectives of the ATHENA project: does the requirement meet the business, technological and

scientific objectives of the ATHENA project? • Interoperability Issues: is the requirement relevant to issues concerning interoperability? • Business and technology drivers: is the requirement aligned with the business and technology

drivers that have been identified by the ATHENA project? • Pilot applications: is the requirement relevant to any of the pilot applications or industrial

application areas identified in the ATHENA project? This process must provide a set of generic requirements that have relevance to the ATHENA

project and are stated in a manner that can be used in the project. Based on the above analysis, the following information about the generic requirements may be determined: • Stakeholders. • Priority. • Risks. • Application area.

Page 24: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 20 / 92

• Technology Area/drivers. • Business implications.

Categorize Section 3.2 Elaborate Specific Requirements Coming from Scenarios proposes that categorization

of requirements is also a sub-process of the elaborating specific requirements from Action Line (AL) B. Similarly, generic requirements must also be categorised according to one or more appropriate classifications, see Principles for Requirements Determination for a discussion on classification of requirements.

The specific requirements that are received may already be categorised. This process must review the category(ies) the specific requirement is assigned and determine the new category(ies).

Review Relationships among the Requirements and Identify New Ones Section 3.2 proposes the linking of specific requirements to other specific requirements. Similarly,

relationships among generic requirements should also be identified and established. First, relationships that have been identified among the specific requirements should be reviewed to determine if they are still applicable in the generic requirements. Second, there may be relationships that have not been identified in the specific requirements and these must be identified and established.

The types of relationships that may exist among generic requirements are: • Similarity – one requirement is similar to another, i.e. some properties of the requirements are

similar and may require similar effort in fulfilling the requirements. • Dependency – one requirement may need to be met before another requirement can be met. • Conflict – one requirement is in conflict with another or violates another, see also Negotiation

Techniques • Contains/overlaps - one requirement is a part of another, see also Negotiation Techniques. • Affects – one requirement affects another requirement in some way. e.g. the particular choices

made in meeting one requirement may have consequences on another requirement.

Model Requirements Ideas from Enterprise Modelling can be applied to describe the requirements and the various

information that are relevant to the requirements, i.e. 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, e.g. business drivers and 5stakeholders, and then modelled.

The purpose of modelling requirements is to describe the requirements in a structured manner and to view them according to a desired way. Some of the benefits or advantages of modelling requirements include: • Reuse – the ability to reuse the requirements for different solutions. • Links to everything – the model shows how the requirements are related to the rest of the

enterprise and how it may affect an enterprise. • Conflict resolution – the model will assist in the detection of conflicts, duplicated information and

various other information inconsistencies that may be otherwise difficult to detect, see also Negotiation Techniques.

• Link to architecture – the model can also provide a link from specific systems architecture to the requirements that led to the architecture.

• Recognise patterns - the model can help identify patterns of architecture or interoperability patterns (see Principle 19 and Appendix B).

• Support for the negotiation and validation – then model can support the processes of requirements negotiation and validation by providing access to the information pertaining to any requirement and a structured overview of requirements.

5 Generic requirements address a broader perspective than specific requirements and are not specific to any particular scenario or an individual. Thus, the term “stakeholders” is used instead of the term “source” of the requirement

Page 25: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 21 / 92

• Different views based on classification – the model can be used to obtain different views of the requirements, e.g. a view of requirements belonging to a particular industrial area or a scenario.

The beneficiaries of requirements modelling include the stakeholders of requirements, the developers or solution providers that try to meet the requirements, European Interoperability Centre (EIC) and researchers in the area of requirements management and interoperability.

Modelling facilitates the structuring, viewing and management of large quantities of information. For requirements modelling, 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, e.g. business level, knowledge level, architectural or platform

level, • Risk and for which group of stakeholders. • Indication of resource requirements to fulfil requirement. • The scope of the requirement, e.g. details of functionalities that will be provided.

Appendixes A.2.3 Requirements modelling and B3 Characteristics of Requirement Management Tools provide more details on requirements modelling. In particular it clarifies differences between usual requirements that are textual, and requirement models that are more a functional model created from the requirements, and dedicated to automation of some task in Requirement Engineering (e.g. Traceability).

Page 26: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 22 / 92

3.5 Requirements Negotiation Requirements negotiation can be defined as “the activity in which the stakeholders meet to

discuss and resolve problems related to the requirements”, (ref: terminology, appendix A). The relevant principles for gathering requirements negotiation are explained in the following list6.

Principle Number

Short description

Principle 1 There is a need for a B4 specific terminology that can be shared among ATHENA partners.

Principle 5 There is a need to consider usage of the ATHENA interoperability Framework when analysing and classifying requirements in the Dynamic Requirements Definition methodology.

Principle 7 Requirements prioritising must be done during the elaboration of to-be scenarios performed by cross-Action Line (AL) teams.

Principle 9 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process will be improved all along the life cycle of the ATHENA Program.

Principle 10 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must support traceability between specific needs from B4, structured generic business needs and interoperability issues.

Principle 11 Generic solutions from Action Line (AL) A projects must address generic interoperability issues.

Principle 12 Dynamic Requirements Definition System and Process will support definition of innovative instrumented methodologies that address specific needs.

Principle 13 All ATHENA projects are “end-users” of the Dynamic Requirements Definition System (DRDS).

Principle 15 There is a need for B4 to provide adapted requirements process for paradigms addressed by ATHENA.

Principle 17 All the ATHENA projects are stakeholders and actors of the Dynamic Requirements Definition process

Principle 18 To-be scenarios are to be elaborated by multidisciplinary teams, including end-users, technology providers and researchers

In ATHENA, requirements will be gathered from the scenarios. These requirements will be analysed and categorised into different classifications. After that, some of the requirements will be selected for the development of Generic Solutions, Generic Information Technologies (IT) products for various market areas and Specific Information Technologies (IT) products for different industrial scenarios. In ATHENA, there will be a need to conduct requirement negotiations in several stages of the requirements handling process, as shown in Figure 13.

6 The following table just provides links with section 4, by providing principle short description and principle number. To see detailed descriptions of the principles, c.f. section 4

Page 27: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 23 / 92

P2 Select Generic

Requirements

P1 Select Specific

Requirements

P6 Develop Generic ITProducts

P7 Develop Specific IT Products

Requirements

P3 Elaborate ATHENA

requirement

P4 Search for Generic

Solutions

P5 Develop Generic

Solutions

Scenarios

External world Market

Validation Scenarios,

Demonstration

NEGOTIATION

NEGOTIATION

NEGOTIATION

Figure 13: Requirements Negotiation in ATHENA

Requirements Negotiation is likely to take place in the following stages of the requirements handling process: 1. Selection of requirements for the Dynamic Requirements Definition System (DRDS):

Requirements are gathered from the external world (Action Line A) and the use-case scenarios (Action Line B) in ATHENA and then entered into the Dynamic Requirements Definition System (DRDS). Negotiation may take place to reach an agreement upon if a particular requirement should be entered into the Dynamic Requirements Definition System (DRDS). The negotiation takes place among the requirement providers who may be industrial partners or researchers.

2. Selection of Requirements for a Generic Solution: After the requirements have been analysed and categorised, negotiation takes place to reach an agreement upon the requirements that will be met by a particular generic solution that is designed. The negotiation takes place between the developers of the solution or the solution providers and the stakeholders (the issue of the participants of any negotiation will be addressed in more detail in Section3.5.1 Negotiating Parties)

3. Selection of Requirements for a Generic Information Technologies (IT) Product for the market: Once a generic solution is agreed upon, further negotiation may take place to agree upon the requirements to adapt the generic solution for a generic Information Technologies (IT) product for a specific market area. This is likely to place in the Action Line (AL) A projects in ATHENA. In this case, negotiation takes place between the developers of the generic Information Technologies (IT) product and the stakeholders of the product.

4. Selection of Requirements for a Specific Information Technologies (IT) Product for industry: Once a generic solution is agreed upon, further negotiation may take place to agree upon the requirements to adapt the generic solution for a specific Information Technologies (IT) product for a specific industry, in the B5 work package in ATHENA. In this case, negotiation takes place between the developers of the specific Information Technologies (IT) product and the stakeholders of the product.

3.5.1 Negotiating Parties Negotiation usually takes place between two or more parties to reach an agreement and each of

these parties have a desire to influence the outcome of the negotiation and are usually affected in someway by the outcome. This section aims to clarify some of the terminology used to describe negotiating parties, (ref: Principle 1).

In ATHENA, the requirements are provided by the industrial partners and researchers. In this case, the industrial partners may be the end-users of a system or someone representing them, such as a project manager. However, if the requirements that are gathered in ATHENA are used by the members of the European Interoperability Centre (EIC) for the development of various solutions, the impact of such a solution may spread to a wider audience than the ATHENA partners. Thus, is it likely

Page 28: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 24 / 92

that parties other than the ATHENA partners may have a desire to influence the requirements negotiation process. These parties can be collectively referred to as the stakeholders.

Negotiation of requirements takes place between the solution provider or the developer of a system and stakeholders and among the stakeholders to reach an agreement that is mutually acceptable for all parties. The party that will process the requirement and act upon it is referred to as the Developer. In some cases, the services of a Facilitator or a Requirements Broker may be used.

Developers

Stakeholder 1

Stakeholder n

Figure 14: Negotiating Parties

3.5.2 General Negotiation Process The general process of requirements negotiation is illustrated in Figure 15 General Negotiation

Process. This process can be described as follows: 1. Requirements are received from the source, e.g. an industrial partner. 2. These requirements are analysed by the developer to categorise them and assign priorities before

they are presented to the stakeholders for negotiation. 3. The stakeholders and the developer negotiate to agree upon the requirement and its fulfilment.

Different techniques may be used for negotiation (c.f. Negotiation Techniques, Section 3.5.4) 4. The developer may either accept or reject a requirement depending on the outcome of the

negotiation.

Stakeholder Developer

Requirement from source

Propose requirement after analysis

Negotiation

Accept

Reject

Figure 15: General Negotiation Process

Page 29: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 25 / 92

An important aspect in supporting the negotiation process is that the Dynamic Requirements Definition System (DRDS) must be able to define and support a well-defined and repeatable negotiation process that is transparent to the stakeholders. It must also be easy for the stakeholders to participate in this process. (related to the Principles 9, 12, 15 and 21).

3.5.3 Negotiation Parameters The stakeholders must be able to base the negotiation on several parameters and must have

access to information related to the requirements. The stakeholder must also have knowledge of the negotiation that takes place between other stakeholders and the developer, e.g. the current priority rating or the no. of votes assigned to a requirement. Some general parameters that can be negotiated upon include: • Scope of the requirement: there must be a clear agreement between the stakeholder and the

developer on what the requirement would deliver in terms of the specific functionality, performance, etc. This could be as elaborate as the details of the solution and its architecture or just a list of functionalities.

• The time of delivery. • The risk a stakeholder or the developer is taking. • The mutual commitment, (e.g. resource, financial), made by both parties to fulfil the requirement.

Most negotiations end up in a mutual agreement where neither party will meet a 100% of their expectations. There are often tradeoffs. Thus, both parties must be clear about the tradeoffs for each requirement and this information must be made available via the Dynamic Requirements Definition System (DRDS).

Some specific parameters that influence the negotiation of requirements in ATHENA may be: • Objectives of the ATHENA project: the agreement that is reached must be aligned with the

objectives and the approach that is followed in ATHENA. • Interoperability Issues: the agreement that is reached must address the relevant interoperability

issues. • Business and technology drivers that have been identified by ATHENA. • The suitability for a particular pilot application.

3.5.4 Negotiation Techniques There are a number of negotiation techniques that have been applied in automated systems in

various domains, e.g. Auctions in Electronic Commerce. The choice of the negotiation technique or protocol depends on the domain of application. Some of the common negotiation techniques that have been applied in the domain of requirements engineering are: • Prioritising, [BO200101] and [CO200403] • Voting, [CO200403] • Weighting, similar to prioritising.

Prioritising The stakeholders assign their priorities to the requirements. The priorities can be graded as high,

medium, low or even more specific and granular.

Voting Each stakeholder has a vote for supporting the implementation of the functionality that is required

and the requirements that have the most votes are selected for implementation.

Weighting The stakeholders can assign weights to requirements. This draws ideas from Multi-attribute utility

Theory [KE197601].This technique is more applicable in situations where the requirements are described using a number of parameters such as the time it will take to implement the requirement and the cost to implement it. So, the user can assign weights to each of these parameters and a utility function can be applied to calculate the weight for each requirement.

Voting and Prioritising appear to be the simpler while sufficient for ATHENA purpose, to implement and should be supported by Dynamic Requirements Definition System (DRDS). It must also

Page 30: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 26 / 92

be possible to perform several iterations of voting or prioritising.

3.5.5 Support Required for Requirements Negotiation The “Elaborate ATHENA Requirements” sub-process, that includes Requirements Analysis

activity, must produce results that will support Requirements Negotiation when searching for (P4) and developing (P5) generic solutions, or when developing generic IT products (P6) or prototypes of specific IT products (P5). It must present the gathered requirements in a structured manner that will make it easier for the stakeholders to base their negotiations.

The support required for Requirements Negotiation can be summarised as follows: • Must support stakeholder heterogeneity and diversity. • Must be able to define and support a repeatable negotiation process. • Must support more than one negotiation process, e.g. prioritising and voting. • The negotiation process must be transparent to the stakeholders. • It must also be easy for the stakeholders to participate in the negotiation process. • Must provide information related to the requirement, e.g. the business goal that is related to the

requirement, the application area, etc. • Must support negotiation parameter, e.g. the scope of the requirement, the time, costs, etc. • Must show explicitly the risks and tradeoffs for each requirement. • The outcome of the negotiation must produce clear agreements on the requirements that can be

used in the validation process.

3.6 Validate Requirements and Prepare Solutions Acceptance Criteria

3.6.1 Introduction The goal of requirements validation is to examine the set of requirements that have been collected

and to find out potential problems with these requirements. Indeed, after the requirements set has been produced, each requirement should be formally validated. The Dynamic Requirements Definition System (DRDS) should provide a means for stakeholders to precisely get into the requirements and assist in recognizing omissions.

ATHENA B4 requirements validation process will ensure that the described requirements are related with the issues expressed by the end-users and other ATHENA stakeholders. Requirements validation should involve an Action Line (AL) A actor but and an Action Line (AL) B end-user to determine the validity (i.e. how well it fits) of each requirement. In fact, a multi-disciplinary team made by partners with different backgrounds should review the set of requirements. This should include a system end-user or end-user representative, one or more domain experts, one or more engineers who will be responsible for system design and implementation and one or more requirements engineers. This should be applied both in formal requirements inspections and less structured review process.

In the ATHENA context, requirements validation also implies that subsequently piloting is planned and executed by a team of experienced application specialists, who are independent and distinct from the development team, based on the validated requirements.

The relevant principles for requirements validation are explained in the following list7.

7 The following table just provides links with section 4, by providing principle short description and principle number. To see detailed descriptions of the principles, c.f. section 4

Page 31: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 27 / 92

Principle Number

Short description

Principle 2 There is a need for a Reference Model for ATHENA requirements. The Reference Model must reflect the complexity of the socio-economic structure of the stakeholders and the actors for interoperability purposes.

Principle 8 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must establish links between industrial scenarios, research and pilots.

Principle 10 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must support traceability between specific needs from B4, structured generic business needs and interoperability issues.

Principle 20 There is a need for the continuous evolution of Dynamic Requirements Definition System (DRDS) and improvement of the Dynamic Requirements process throughout the whole life cycle of the ATHENA program

3.6.2 Requirements Validation Process The requirements validation process can be considered like a Quality Gateway that ensures a

rigorous specification by testing each requirement for completeness, correctness, measurability, absence of ambiguity and several other qualities before each requirement can be added to the specification. In order to validate each requirement, different activities are needed, for example reading, reviewing, and inspection. Requirements validation is a process that involves different stakeholders reading and thinking about a lengthy set of requirements. Meetings may have to be arranged in order to discovering and fixing requirements problems and without doubt avoid a lot of expensive rework of the system design and implementation. These problems must be solved before the set of requirements is approved. A reasonable validation process for evolving from definition to specification will be implemented for validity, consistency, completeness, and realism:

Validity Consistency Com Realism

Figure 16 Requirements Validation Process

3.6.2.1 Validity

Does the requirement reflects an actual need and is clearly expressed? Based on the scenario and the preliminary system architecture, the requirements definition team

will publish a correlation table between Needs/Issues and preliminary requirements. The rational of this table is to verify if each requirement reflect an actual need.

The requirements definition team will also verify if each requirement has been clearly expressed or may have lost information that has been collected during requirements elicitation.

3.6.2.2 Consistency

Does requirement conflict with one another? The requirements definition team will review the set of requirements, coming from the previous

phase, for consistency and uniformity. In this phase the Action Line (AL) A projects will work closely with the requirements definition team to resolve ambiguities, discrepancies, in order to validate the requirements. Furthermore, the requirements definition team will review the requirements set to carry out a quick standards check to ensure that the document and the set of collected requirements are consistent with a previous defined standard.

Page 32: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 28 / 92

3.6.2.3 Completeness

Are requirements missing? Based on the previous validity phase the requirements definition team will analyse the correlation

table between Needs/Issues and preliminary requirements in order to verify if each Needs/Issues reflect an actual requirement. On the other hand inconsistencies according to overlapping of requirements definition or not consistent relations between business and technical requirements can appear during this analysis. These kind of inconsistencies will be fixed as described in the phase “How to elaborate Specific Requirements coming from Scenarios”

3.6.2.4 Realism

Can requirement possibly be met? The requirements definition team will analyse the requirements for realism. They will verify if a

measurement to quantify the requirements has been defined, in order to determine if an implementation meets the requirement and how. Using some kind of fit criteria, it is possible to recognize the fact that you cannot design a solution to the requirement unless you have a way of knowing if the solution meets the requirement. Fit criteria, like those described in the following table, will quantify the behaviour, the performance, or some other quality of the requirement. • Property • Measure: it is necessary to suggest a way to measure the metric. Measurements will be taken

from the state of the art and/or preceding experiences. • Target: value or judgement that describe it (example: bad, quite good, good).

ID Property Measure Performance01 Speed Processed transactions / sec. 02 Response time 03 Screen refresh time 04 Size K bytes 05 Ease of use Training time 06 Number of help frames 07 Reliability Mean time to failure 08 Probability of unavailability 09 Failure rate 10 Robustness time to restart after failure 11 Probability of data corruption

after failure

12 Portability % of target dependent statements

Number of target systems Moreover, the requirements definition team will analyse the requirements for future

implementation. Unrealistic requirements are those requirements that don’t appear to be implementable with the planned project results. In this case stakeholders will decide if the requirements should be deleted or modified to make it more realistic.

Page 33: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 29 / 92

3.6.3 Validation Checklist Based on the previous general issues a validation checklist will be defined which help and focus

the requirements definition team on critical attributes and give hints about what they should looking for throughout the validation process. Moreover checklists help in the introduction of people who are new to this validation process:

Checklist

item Description

Validity Does the requirement reflect an actual need? Is the requirement clearly expressed? Is the requirement consistent with the business goals

defined for the ATHENA project? Consistency Does the requirement describe a single requirement? Does the requirement conflict with one another? Could the requirement be broken down into several different

requirements Completeness Are requirement missing?

Realism Can requirement possibly be met?

Is the requirement realistic given the technology that will be used to implement the system?

Is the requirement testable, that is, is stated in such a way that test engineers can derive a test which can show if the system meets that requirement?

3.6.4 Relations to Piloting activities The requirements validation process is also crucial in developing acceptance test plan system test

plan. The acceptance measure will be defined in relation with the measurement of the requirement in

order to enable the tester to determine, without use subjective judgements, if the delivered solution meets, or fits, the requirement. The acceptance measure is a quantification of the requirement, for example, the first question to ask is “Does the requirement have a correctly defined acceptance measure?” The next test for the acceptance measure is whether it can be used as input the acceptance test. The acceptance measure is not the test, but should indicate what kind of tests need to be done to ensure that the delivered solution complies with the original requirements.

Page 34: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 30 / 92

4 Dynamic Requirements Principles

4.1 Overview Objective The objective of deliverable DB4.1 is to form the foundation of the methodology to be used for

requirements handling. This section provides the associated principles that guided its definition and will guide its application within ATHENA programme (in particular B4 project) and, in the future, within the European Interoperability Centre (EIC).

How principles were elaborated The principles were elaborated from different discussion arising during B4 workshops, exchanges

between the different partners, and analysis of the interoperability patterns, ATHENA Description of Work (DoW) and state of the practice concerning requirements engineering in relationship with interoperability.

They were submitted to all the ATHENA stakeholders in order to obtain agreement. The list provided here is a first version, that will be updated according experience gained through

applying the ATHENA methodology. The principles and their status will consequently be managed all along the ATHENA program.

Process associated with principles Principles were already used in order to define the Dynamic Requirements Definition

methodology. It will be the role of B4 to ensure that:

• The principles are agreed and applies • The principles are updated and improved after one cycle from requirements gathering to pilots)

It will be done through: • Cross action line teams activities with support of A4 project • Enforcing some rules and principles within the DRD System • Systematic review of deliverables and activities linked to the Dynamic Requirements Definition

process. The precise process will be defined after agreement from all ATHENA stakeholders.

Structure A short list of the 20 principles is first provided for quick discovery, in a first sub-section, and with

references of the steps of the Dynamic Requirements Definition process and methodology for which the principle was/will be relevant.

Principle Number

Short description

Principle number

Short description of the principle used to identify it. It is necessary to refer to the full description of the principle to be able to use it.

Steps of Dynamic Requirements Definition process/methodology for which the principle is relevant.

Then the principles are described with more details and justification, in the second sub-section. Principle

Number Short description of the principle used to identify it. It is necessary to

refer to the full description of the principle to be able to use it. Long Description of the principle, including explanation and references to the appendixes Already existing or potential application of the principle

Page 35: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 31 / 92

4.2 Principles List Principle Number Short description

Principle 1 There is a need for a B4 specific terminology that can be shared among ATHENA partners.

Relevant for all process steps

Principle 2 There is a need for a Reference Model for ATHENA requirements. The Reference Model must reflect the complexity of the socio-economic structure of the stakeholders and the actors for interoperability purposes.

3.2.1, 3.3, 3.5.1, 3.6

Principle 3 There is a need to consider requirements for collaborative agile infrastructures for effective interoperability of enterprise applications.

Relevant for all process steps

Principle 4 Requirements can’t come directly from the Action Line (AL) B activities to each Action Line (AL) A project without elicitation, prioritisation and analysis that will allow a coherent distribution between the different projects.

3.2.1, 3.3, 3.4

Principle 5 There is a need to consider usage of the ATHENA interoperability Framework when analysing and classifying requirements in the Dynamic Requirements Definition methodology.

3.4, 3.5

Principle 6 There is a need for the Dynamic Requirements Definition to support the categorization of requirements according to research activities and type of applications.

3.2.1, 3.3, 3.4

Principle 7 Requirements prioritising must be done during the elaboration of to-be scenarios performed by cross-Action Line (AL) teams.

Principle 18, 3.4, 3.5

Principle 8 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must establish links between industrial scenarios, research and pilots.

3.2.1, 3.4, 3.6.1

Principle 9 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process will be improved all along the life cycle of the ATHENA Program.

Relevant for all process steps, A.1

Principle 10 Dynamic Requirements Definition System (DRDS) and Requirements Definition Process must support traceability between specific needs from B4, structured generic business needs and interoperability issues.

3.2.1, 3.3, 3.4, 3.6.1

Principle 11 Generic solutions from Action Line (AL) A projects must address generic interoperability issues.

3.2.1, 3.3, 3.4, 3.5

Principle 12 Dynamic Requirements Definition System and Process will support definition of innovative instrumented methodologies that address specific needs.

3.2.1, 3.4,3.5

Principle 13 All ATHENA projects are “end-users” of the Dynamic Requirements Definition System (DRDS).

3.2.1, 3.3, 3.6

Principle 14 There is a need for Action Line (AL) A technical requirements to be addressed by ATHENA

3.3

Principle 15 There is a need for B4 to provide adapted requirements process for paradigms addressed by ATHENA.

Relevant for all process steps

Principle 16 There is a need for Life Cycle of collaboration activity for requirements process implementation will be evolutionary or spiral.

Relevant for all process steps, A.1

Principle 17 All the ATHENA projects are stakeholders and actors of the Dynamic Requirements Definition process

3.3, 3.6

Principle 18 To-be scenarios are to be elaborated by multidisciplinary teams, including end-users, technology providers and researchers

Principle 7, 3.4, 3.6

Principle 19 Business scenarios analysis and interoperability issue identification should imply usage of interoperability patterns.

3.2.1, 3.4

Page 36: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 32 / 92

Principle Number Short description

Principle 20 There is a need for the continuous evolution of Dynamic Requirements Definition System (DRDS) and improvement of the Dynamic Requirements process throughout the whole life cycle of the ATHENA program

A.1, 3.5.1

Principle 21 The requirements handling process(es) supported by Dynamic Requirements Definition System (DRDS) must be clear (to the user of Dynamic Requirements Definition System) and repeatable.

3.5.2-General Negotiation Process

4.3 Principles Description Principle 1 There is a need for a B4 specific terminology that can be shared among

ATHENA partners.

An analysis of the requirements defines the requirement phases for different kind of engineering: software, system, business process, knowledge, etc. Numerous similarities as well as dissimilarities exist. To define a set of definitions for B4 project and ATHENA starting from a standard in one of these domains of engineering is not obvious, as it will go against culture and current practices of some of the ATHENA partners specialised in some domains. But it can also go against culture and current practices of the future members of European Interoperability Centre (EIC). Consequently it is important that ATHENA B4 project proposes its own set of definitions and reference models for requirements that are shared, understood and adequate for each profile member of the ATHENA community.

A consequence is that, according to the analysis of the state of the art on requirements engineering, it is not appropriate to reuse “as it is” a set of standardised definitions coming from a standard for ATHENA purpose: most of the standards are focusing on only one discipline involved in ATHENA, or are driven by only one paradigm that is not necessarily adopted by all the actors and stakeholders of ATHENA.

Application: Definition of a shared terminology, provided in this document. Principle 2 There is a need for a Reference Model for ATHENA requirements. The

Reference Model must reflect the complexity of the socio-economic structure of the stakeholders and the actors for interoperability purposes.

It is also important to point that, for most of the concerned domains, requirements are about one system or solution that is to be designed, produced and operated. No requirements methodology is targeting interoperability of independent systems that are not necessarily known in advance, that have different life cycles and project/ownership/control/usage boundaries. Socio-economic structure of stakeholders and actors is consequently more complex than for a single system. This structure needs to be reflected when structuring, modelling, analysing and managing the requirements. The reference model for ATHENA requirements has to reflect complexity of socio-economic structure of stakeholders and actors for interoperability issues analysis and solving purposes.

Page 37: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 33 / 92

Principle 3 There is a need to consider requirements for collaborative agile

infrastructures for effective interoperability of enterprise applications.

The structure of the ATHENA program reflects what is happening in the real world when addressing interoperability issues: the universe of the problem (industry) and the universe of the solution (solution providers) are separated, as more and more “component off the shelves“ or ready to use “software products” are proposed to the enterprises, that want to avoid to develop “in-house” solutions. There is a meeting point during evaluation of existing solutions when running a project to develop an application. The industrial project does not drive the software product development that is based on marketing studies. The available software products don’t drive the requirements phase as needs are usually solution independent. The idea is then to organise a “meeting” or “collaboration” space between solution providers and industry, providing a framework that will be used to map continuously changing and evolving needs with continuously evolving technical solutions, infrastructures, standard, etc. The idea is to be able to quickly provide collaboration agile infrastructures, despite the always changing context, when dealing with requirements for effective interoperability of enterprise applications.

Principle 4 Requirements can’t come directly from the Action Line (AL) B activities to

each Action Line (AL) A project without elicitation, prioritisation and analysis that will allow a coherent distribution between the different projects.

The usual project approaches are not appropriate for the program: first, ATHENA is a mix of projects, program and ongoing activities, with their own project life cycle type, and their particular way to elicit and validate requirements. Second, B4 aims to provide an approach that will allow addressing a maximum number of scenarios coming from as many possible industrial sectors with a limited set of resources (B4 objectives in ATHENA program). Finally, each Action Line (AL) A project has to provide part of the solution that must be integrated into those coming from the other Action Line (AL) A projects, by means of the ATHENA Interoperability Framework. Consequently requirements can’t come directly from the Action Line (AL) B activities to each Action Line (AL) A project without elicitation, prioritisation and analysis that will allow a coherent distribution between the different projects.

This principle is reflected in the Dynamic Requirements Definition methodology and on the way the different classical phases of a requirements process are applied and distributed between the ATHENA projects (c.f. Figure 3 ATHENA Dynamic Requirements process and Requirements Engineering).

Principle 5 There is a need to consider usage of the ATHENA interoperability

Framework when analysing and classifying requirements in the Dynamic Requirements Definition methodology.

Requirements will be analysed, structured and categorised through AIF, taking into consideration interest of the different stakeholders to prioritise research and development activities. There is consequently a need to consider usage of the ATHENA interoperability Framework when analysing and classifying requirements in the Dynamic Requirements Definition methodology.

Page 38: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 34 / 92

Principle 6 There is a need for the Dynamic Requirements Definition to support the

categorization of requirements according to research activities and type of applications.

Requirements dispatching will be done through the profiles, that are aimed to provide a partition of the collaboration space per type of applications (CPD, eProcurement, Portfolio Management, SCM) with clear definitions of the boundary of problems Action Line (AL) A projects aim to solve. During this dispatching, the requirements will be categorized taking into account interest of the different stakeholders of the projects, with some times negotiation and even arbitration when incompatible interest, by the means of referring the Key objectives of ATHENA. Such decision-making can be difficult and complex. There is consequently a need for Dynamic Requirements Definition to support the categorisation of requirements according to research activities and type of applications.

Principle 7 Requirements prioritising must be done during the elaboration of to-be

scenarios performed by cross-Action Line (AL) teams. (linked to Principle 18).

The negotiation phase of the requirements process and the elaboration of to-be scenario will imply A4 support, as it will be done by cross action teams mixing people coming from and representing the different ATHENA projects and the program. At least one team per profile will have to be constituted. They will work together on the elaboration of (ATHENA.B4.) to-be scenarios, under the responsibility of B4, and supported by A4 in order to obtain a good representation of each project and to guaranty solutions taking advantage of each represented discipline (software engineering, enterprise modelling, knowledge modelling, ontology). Even if requirements are industry driven, the negotiation will have to take as constraints:

the innovative nature of the project, as we are in the context of a research program (it is why ATHENA program representatives are to be involved)

the driving paradigm of ATHENA, that is interoperability of enterprise applications and software based on approach federating enterprise modelling, knowledge modelling, Information and Communication Technologies (ICT) and ontology (it is why A4 representatives are to be involved)

the interest of solution providers, as developed solutions will have to allow development of a viable economic activity, to ensure impact on the European Community (it is why representatives of different solution providers profile are to be involved)

It is why cross Action Line (AL) teams have to include the different kind of actors and stakeholders Principle 8 Dynamic Requirements Definition System (DRDS) and Requirements

Definition Process must establish links between industrial scenarios, research and pilots.

One of the main motivations is to be able to establish clear link between industrial scenarios and validation of Action Line (AL) A projects proposed innovation as effective solution for industry through B5 pilots.

Principle 9 Dynamic Requirements Definition System (DRDS) and Requirements

Definition Process will be improved all along the life cycle of the ATHENA Program.

As B4 target to provide a robust and efficient Dynamic Requirements Definition process within ATHENA and for future targeted European Interoperability Centre (EIC), an objective of B4 is to improve the ATHENA B4 requirements process and Dynamic Requirements Definition System (DRDS) through analysis of collaboration process. Dynamic Requirements Definition System (DRDS) will have to support this analysis by collecting and structuring relevant information for this analysis.

Page 39: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 35 / 92

Principle 10 Dynamic Requirements Definition System (DRDS) and Requirements

Definition Process must support traceability between specific needs from B4, structured generic business needs and interoperability issues.

B4 specific objective is to provide the path from specific needs coming from specific business scenario, to structured generic business needs and finally to generic interoperability issues. DRD system and process have to support elaboration and traceability of relationships between these different categories of requirements.

Principle 11 Generic solutions from Action Line (AL) A projects must address generic

interoperability issues.

The specific solution provided by Action Line (AL) A projects should address the generic interoperability issues.

The interoperability issues will result of requirements gathering, elicitation and analysis from an interoperability and business point of view. They are the consolidated set of requirements shared by the industrial users, and organised to be addressed by Action Line (AL) A project through the AIF.

Principle 12 Dynamic Requirements Definition System and Process will support

definition of innovative instrumented methodologies that address specific needs.

Specific business needs that can’t be made generic are most of the time linked to the problem of customisation. The solutions addressing these needs should be in the area of innovative instrumented methodologies to support business cooperation and interoperability of enterprise application.

In order to have an impact on European industrial community, customisation is a key issue, that can’t only be address by software applications. Dynamic Requirements Definition System and Process will have to take this aspect into consideration.

Principle 13 All ATHENA projects are “end-users” of the Dynamic Requirements

Definition System (DRDS).

As interoperability issues will be manage within the Dynamic Requirements Definition System (DRDS), Action Line (AL) A project and the program will have to access to the information in the Dynamic Requirements Definition System (DRDS) coming from B4 activity. It will also be necessary to establish links between B4 requirements, ATHENA objectives, Action Line (AL) A solutions. Consequently all projects will be end-users of the Dynamic Requirements Definition System (DRDS).

In particular: • Dynamic Requirements Definition System (DRDS) and Requirements process will be a key

components in ATHENA program, and will have to be integrated to the AIF and to the ACP. Consequently A4 and C1 will be users and stakeholders concerning elaboration of requirements process and Dynamic Requirements Definition System (DRDS) specifications.

• Dynamic Requirements Definition System (DRDS) and Dynamic Requirements Definition (DRD) process will support B5 requirements process. To drive pilots defined from cross Action Line (AL) teams collaboration, an another partition will be used, per industrial sector (aeronautic, automotive, furniture, telecom), with clear definition of the results these pilots will have to demonstrate, and with as constraints resources available from the ATHENA program. B4 project will support requirements process for the pilots, as B5 will use Dynamic Requirements Definition System (DRDS).

Page 40: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 36 / 92

Principle 14 There is a need for Action Line (AL) A technical requirements to be

addressed by ATHENA Each project can generate its own set of requirements. For example, Action Line (AL) A

projects will have to manage technological requirements for innovative solutions that can be seen as requirements to solve current technology drawbacks for interoperability purposes. As industrial users are not specialists of these technologies, technical requirements for innovation in these domains (enterprise modelling, ontology, Information and Communication Technologies (ICT), knowledge management) can only come from experts on these fields and be generated by Action Line (AL) A projects. Project B4, through design of Dynamic Requirements Definition System (DRDS), will have to address Action Line (AL) A needs for the technical requirements (process, requirements).

Note: these technical requirements are a subset of the generic requirements as defined in the Dynamic Requirements Definition methodology

Principle 15 There is a need for B4 to provide adapted requirements process for

paradigms addressed by ATHENA. Project B4 will have to produce adapted requirements process to address “Unified

Paradigm Interoperability Infrastructure”, “Networked Enterprises Operations Support”, “Integrated Paradigm Interoperability Infrastructure” or “Flexible Enterprise support infrastructure and Process Customisation Support Environment”, even if not addressed by initial projects.

Principle 16 There is a need for Life Cycle of collaboration activity for requirements

process implementation will be evolutionary or spiral.

Through application of the previous principle, B4 activities can be summarise by the following schema.

BusinessDomain

BusinessProcesses

Application scenario

Aeronautic

Automotive

Telecom

Furnitures

CPD

eProcurment

Portfolio Mgt

SCM

ANALYSISExtracting needs (and issues) concerning interoperability

Formalising it from ATHENA point of view, maintaining the links

Generic Need & Issues

Specific Needs & Issues

•Enterprise process•Busines Domain•One given Enterprise

The following schema can represent the link with Action Line (AL) A.

Page 41: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 37 / 92

Generic Need & Issues

Specific Needs & Issues

•Enterprise process•Busines Domain•One given Enterprise

PROFILES(applicationsBased)

A1

A2

A3

A4

A5

A6

IntelligentCollaborationInfrastructure

PILOTS B5

Based on the analysis of the previous principles and reinforced by previous sections of the document, the organisation of the ATHENA program cycles should be organised a concurrent way with well established synchronisation points, with pertinent rhythm and horizon. Life cycle of collaboration activity for requirements process implementation will be evolutionary or spiral.

Time axis

Space of the problem Space of the Solution

Synchronisation pointTO BE SCENARIO

Synchronisation pointNEW TO BE SCENARIOEvaluation of pilots

NEG

OC

IATI

ON

PILO

TS

NEG

OC

IAT I

ON

PIL O

TS

NE

GO

CIA

TIO

NP

ILO

TS

NE

GO

CI A

TIO

NP

ILO

TS

Principle 17 All the ATHENA projects are stakeholders and actors of the Dynamic

Requirements Definition process All the projects will have to be considered as stakeholders and actors of the DR process.

Consequently, use cases will have to be elaborated for each of them when designing the Dynamic Requirements Definition System. The role of the “ATHENA projects” actors is also to be formalised on the Dynamic Requirements Definition process.

Page 42: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 38 / 92

Principle 18 To-be scenarios are to be elaborated by multidisciplinary teams, including

end-users, technology providers and researchers (linked to Principle 7).

The to-be scenarios are to be elaborated by multidisciplinary teams, including end-users, technology providers and researchers, in order not only to satisfy end-users and industry needs, but also to target innovative solutions that are feasible by the technology providers in the scope of the project.

The to-be scenario will be elaborated by cross Action Line (AL) teams under the responsibility of B4 project, and supported by A4 for coordination of Action Line (AL) A projects.

Generic and specific interoperability

issues from specific scenarios Specific interch

angeable Solutions

For generic

problem

StartingScenarios

To-beScenarios

PilotScenarios

NEG

OC

IATI

ON

PIL

OTS

PilotResults

Innovativetechnologies

Principle 19 Business scenarios analysis and interoperability issue identification should imply usage of interoperability patterns.

In order to formalise and in a second phase to analyse business scenarios and extract interoperability issues according industrial user point of view, interoperability patterns will be defined, shared with ATHENA community.

The objective is to formalise generic interoperability issues with identified best practices to address them, issued from the ATHENA community.

Page 43: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 39 / 92

Principle 20 There is a need for the continuous evolution of Dynamic Requirements

Definition System (DRDS) and improvement of the Dynamic Requirements process throughout the whole life cycle of the ATHENA program.

As Dynamic Requirements Definition System (DRDS) design and development is targeted during the first year, as elaboration of the DR process, it will not be possible to use for the different activities of the program that are starting at the same time. Consequently, an evolutionary approach will have to be adopted. Initiation will be done using “starting business scenarios” that will not be analysed before to be exploited by A4 and Action Line (AL) A projects. It is exactly the same thing with the to-be scenarios.

Consequently requirements collection and formalisation in the Dynamic Requirements Definition System (DRDS) will have to be collected first by means other than the Dynamic Requirements Definition systems, and to be entered into the Dynamic Requirements Definition System (DRDS) as soon as a validated Dynamic Requirements Definition System (DRDS) is be available.

Application of methodology proposed by B4 will imply some retrofits during the first iteration, and validated during the next iterations. It will be possible, comparing the different iterations, to compare gains of usage of more formalised scenarios based on B4 methodology, to analyse results, and to improve DR process and system. Proposed change will be an on going activity (Dynamic Requirements Definition System maintenance)

Principle 21 The requirements handling process(es) supported by Dynamic

Requirements Definition System (DRDS) must be clear (to the user of Dynamic Requirements Definition System) and repeatable.

An important aspect in supporting the negotiation process is that the Dynamic Requirements Definition System (DRDS) must be able to define and support a well-defined and repeatable negotiation process that is transparent to the stakeholders. It must also be easy for the stakeholders to participate in this process.

Page 44: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 40 / 92

5 Dynamic Requirements Definition (DRD) Terminology

5.1 Introduction This section provides a set of definitions that must be shared by the ATHENA partners in the

context of the ATHENA dynamic requirements definition. The same terms may be defined differently in other contexts. Its elaboration was motivated by the Principle 1. It is aimed to share the terminology with all the ATHENA program and to improve it all along the life cycle of ATHENA program.

5.2 Structure Each term presentation is defined in a table structure as following.

TERM ATHENA.B4 context (optional) Definition 1 Definition 2… CONTEXT 2 (optional) Definition… and so on

The first definition is the one chosen in B4 context, when defined. If other definitions of interest in other contexts (other ATHENA projects, standards…), some lines

are added that allow to precise the context Within the definition, the origin can be provided It is then signalled between brackets: [origin].

5.3 Definitions ACTIVITY ATHENA.B4 An atomic part of a workflow, e.g. a logical step or description of a piece of work that

contributes toward the accomplishment of a process. An activity may be a manual activity and/or an automated activity. "Play a significant role in enterprise integration and consequently in interoperability, since enterprise integration is necessary to develop interoperability of enterprise application" [IDEAS]

BUSINESS

CASE ATHENA.B4

The system in which the ESAI (Enterprise Software Application Interoperability) will be analysed and defined

BUSINESS

PROCESS ATHENA.B4

“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.” [ISO 15704, 1999]

Page 45: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 41 / 92

BUSINESS

SCENARIO ATHENA.B4

A 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 in the scope of ATHENA project. In B4, the scenarios have no idea about what the solutions for interoperability are. Scenarios may include results of some investigation or evaluation of solutions that were unsuccessful and related requirements concerning interoperability coming from the enterprise.

Enterprise modelling A 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 reorganisation.

BUSINESS

SCENARIO PROCESSES

Enterprise modelling

A scenario process is the 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

DYNAMIC

REQUIREMENTS DEFINITION

ATHENA.B4

Dynamic Requirements Definition (DRD) is a methodology and associated process addressing requirements gathering, elicitation, modelling, analysis, validation, negotiation and tracking all along the life cycle of the ATHENA program, in order to provide a coherent and common way for the different ATHENA projects to perform their activities concurrently, following spiral or evolutionary project life cycles, and to integrate as soon as possible evolution of the context in term of solutions or needs coming from the market. This is the reason why we are talking about Dynamic Requirements.

E-

BUSINESS ATHENA.B4

“Doing business electronically in support of organisational goals” "Such as content management, supply chain integration, value chain integration, information standardization for electronic marketplaces." [IDEAS] [A European Initiative in Electronic Commerce, COM(97) 157 final, 16 April 1997]

Page 46: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 42 / 92

END-USER Software engineering The final or ultimate user of a computer system. The end-user is the individual who uses the

product after it has been fully developed and marketed. The term is useful because it distinguishes two classes of users, users who require a bug-free and finished product (end-users), and users who may use the same product for development purposes. The term end-user usually implies an individual with a relatively low level of computer expertise.

In information technology, the term end-user is used to distinguish the person for whom a hardware or software product is designed from the developers, installers, and services of the product. The term end-user thus distinguishes the user for which the product is designed from other users who are making the product possible for the end-user. The term is used mostly with mainframe computer products and seldom with personal consumer products. Often, the term user would be sufficient.

Someone who has some kind of direct interface with the system. ENTERPRISE ATHENA.B4 It is an economic entity/organisation, linked to obligation to exist as one juridical and viable

economic entity. It implies for this organisation to deal with security, intellectual property, law, economic... aspects. Activities between the enterprise are done through contracts. [IDEAS]

One or more organisations sharing a definite mission, goals, and objectives to offer an output such as a product or service - NOTE This term includes related concepts such as extended enterprise or virtual enterprise. [ISO 15704, 1999]

FUNCTIONAL

REQUIREMENT ATHENA.B4

A functional requirement specifies what the system must be able to do, the functions it should perform. Functional requirements are associated with specific functions, tasks or behaviours the system must support. This term is used at both the user requirements analysis and software requirements specifications phases in the software life cycle. [VOLERE] [Software Engineering]

Functional requirements capture the intended behaviour of the system. This behaviour may be expressed as services, tasks or functions the system is required to perform.

Functional requirements are the fundamental subject matter of the system and are measured by concrete means like data values, decision making logic and algorithms.

Functional Requirement is an action that the system must be able to take, something that the product must do.

GENERIC

REQUIREMENT ATHENA.B4

Within the ATHENA Dynamic Requirements Process and Methodology, all the requirements that are not coming from Business scenarios, but those coming from Action Line (AL) A projects or B3 projects. They can come from the literature, from the experience of ATHENA partners in Action Line (AL) A, from documents provided by stakeholders identify in B3,etc.

GENERIC

INFORMATION TECHNOLOGIES (IT) PRODUCT

ATHENA.B4

Within the ATHENA Dynamic Requirements Process and Methodology, product that will be developed to satisfy market’s needs, as exploitation of generic solution developed within the ATHENA program.

Page 47: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 43 / 92

GENERIC

SOLUTION ATHENA.B4

Within the ATHENA Dynamic Requirements Process and Methodology, solutions generated by Action Line (AL) A projects, that are specific scenarios independent. From the generic solutions, specific and generic Information Technologies (IT) solutions will be developed respectively within Piloting activities and as exploitation of the results to provide product on the market.

INTEROPERABILITY

ISSUE ATHENA.B4

Problems concerning interoperability extracted elicited from analysis of business scenarios, analysed and modelled through the B4 process. The idea is to reuse already existing issues for several scenario when it is the same needs, and to extend the list when a new need occurs. Interoperability issues are classified according specificity criteria.

INTER

OPERATION CONSTRAINTS

ATHENA.B4

Identify how the targeted interoperation must fit into the world. For example the inter operation might have to be based on usage of some existing network protocol, technical platform (CORBA) or business protocol, or it might have to fit within a defined budget or be ready by a defined date.

INTER

OPERATION DRIVERS

ATHENA.B4

are the business- related forces. For example the purpose of the interoperation is a interoperation driver, as are all of the stakeholders - each for different reasons

INTER

OPERATION ISSUES

ATHENA.B4

define the conditions under which the interoperation will be done. We include these in the requirements specification to present a coherent picture of all the factors that contribute to the success or failure of the inter operation.

MAPPING ATHENA.B4 issues/requirements mapping. It is the way that the B4 interoperability issues will be

connected to the requirements manage by B4 according the Profiles. METHODOLOGY ATHENA.B4 A set of instructions (provided through text, computer programs, tools, etc.) that is a step-by-step

aid to the user[ISO 15704, 1999])

Page 48: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 44 / 92

NON-

FUNCTIONAL REQUIREMENT

ATHENA.B4

A non-functional requirement specifies an aspect of the system other than its capacity to do things. Examples of non-functional requirements include those relating to performance, accessibility, usability, etc

Non-functional requirements are the behavioral properties that the specified functions must have, such as performance, usability, etc. Non-functional requirements can be assigned a specific measurement.

A property that the eventual system must have PILOT ATHENA.B4 The implementation of use case solutions in a real context of industrial users. Pilots are

employed to test in a limited context the goodness of a use case solution before its extension on the whole enterprise reality [ATHENA.B5]

PROCESS-

CENTRIC SCENARIOS

ATHENA.B4

Its core function is the implementation of business processes by means of inter-related activities (manual, Information and Communication Technologies (ICT) interactive, Information and Communication Technologies (ICT) automatic). Data exchange sharing as well as resources (business-knowledge) employment are the key points. Semantic interoperability of processes and applications is often needed as well as data-resources reconciliation.

PROCESSES

OF REFERENCE ATHENA.B4

These are generic processes of reference supported by a community, as for example those standardised by Department of Defence (DoD), Change Management Institute (CMII), a software product provider (generic processes pre-cabled within the product), processes associated to a methodology… It can also be processes of reference within a virtual or networked enterprise.

PRODUCT-

CENTRIC SCENARIO

ATHENA.B4

Its core function is the accessibility by different classes of users to repositories of data, models, metadata, meta-models. Depending on the final purpose of such an access we can have sharing/exchanging of data-models, Information Technologies (IT) automatic - Information Technologies (IT) mediated - manual access, workplace generation. Access could be either an activity inside a business process, or a task inside a project, or an extemporary ad-hoc initiative. Semantic reconciliation of data and models is often needed.

SCENARIO ATHENA.B4 Use case instance showing system user sequences, a specific running of the use case. The

scenario is a set of detailed activities. SPECIFIC

INFORMATION TECHNOLOGIES (IT) PRODUCT

ATHENA.B4

Specific Information Technologies (IT) product are those implementing generic solution provided by ATHENA in order to respond to business scenarios provided in B4.

Page 49: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 45 / 92

SPECIFIC

REQUIREMENT ATHENA.B4

Within the ATHENA Dynamic Requirements Process and Methodology, specific requirements are requirements coming from the Industrial scenarios, and that is consequently specific to a given industrial stakeholders.

REQUIREMENT ATHENA.B4 A statement of what the system or part of the system should do. It is a statement of a customer

wish without specifying how that wish will be implemented. Requirements can be grouped into 'essential', 'useful' and 'desirable'. A requirement relates to multiple viewpoints and a viewpoint can be decomposed into multiple requirements. Several scenarios implement a requirement.

Dynamic

Requirements Definition (DRD) REQUIREMENTS

ATHENA.B4

Statements of what the Dynamic Requirements Definition System (DRDS) should do. It is a statement of users and stakeholders wish without specifying how that will be implemented.

DYNAMIC

REQUIREMENTS DEFINITION PROCESS (DRDP)

ATHENA.B4

Stands for Dynamic Requirements Definition Process; it is a requirements process adapted to the purpose and the organisation of ATHENA program. It targets interoperability between systems, and implies the various stakeholders and actors concerned by the program, within ATHENA or outside ATHENA.

DYNAMIC

REQUIREMENTS DEFINITION SYSTEM (DRDS)

ATHENA.B4

Stands for Dynamic Requirements Definition System; it is an application system that will be specified under the responsibility of ATHENA B4 project, and that aims to support the Dynamic Requirements Definition Process within ATHENA program and the future targeted Interoperability Centre.

REQUIREMENTS

ANALYSIS ATHENA.B4

The phase in Requirements Determination 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.

Page 50: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 46 / 92

REQUIREMENT

CLASS ATHENA.B4

For multi-dimensional approach, a hierarchy of requirements sharing common characteristics. A class has many requirements while a given requirement may be a member of several classes. Typical examples of classes are System, User Interface, Database, Communication and Security.

REQUIREMENTS

CLASSIFICATION ATHENA.B4

The process of grouping related requirements into class hierarchies. One of the reasons for creating requirements classes is the ability to group common requirements based on well-defined expertise areas. The 'leaves' in a given class represent system requirements and these are found from the corresponding Viewpoint hierarchies. Intermediate nodes represent placeholders.

REQUIREMENTS

CONFLICT ATHENA.B4

Two requirements R1 and R2 are in conflict if the realisation of R1 implies difficulty in realising R2 and vice versa. This is a problem that must be resolved by suggesting compromises and workarounds in co-operation with stakeholders.

REQUIREMENTS

DETERMINATION ATHENA.B4

The phase in the software life cycle consisting of the sub-phases Elicitation, Analysis and Negotiation, Validation. A Commercial Requirements Specification (CRC) is transformed into a requirements document. Note: Code name=RD

REQUIREMENTS

ELICITATION ATHENA.B4

The phase of Requirements Determination in which an initial set of requirements for a system are discovered. This set is 'unoptimised' in the sense that it may contain duplicate requirements, ambiguities, omissions and inconsistencies.

REQUIREMENTS

HARMONISATION ATHENA.B4

The activities in which the requirements from the Requirements Analysis phase are integrated with Datasim's domain model(s). In this way different subsystems can be independently developed. Furthermore, we achieve loose coupling between subsystems and tight coupling within each subsystem, an issue that has been prevalent since the 1970's (for example, in the work of David Parnas).

REQUIREMENTS

TYPES ATHENA.B4

Functional requirements, non functional requirement, interoperation constraints, interoperation drivers, interoperation issues

REQUIREMENTS

NEGOTIATION ATHENA.B4

The activity in which stakeholders meet to discuss and resolve problems related to the requirements in the Requirements Analysis phase.

Page 51: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 47 / 92

REQUIREMENTS

OVERLAP ATHENA.B4

Two requirements R1 and R2 are overlap if they contain sub-requirements that are common to both of them. In other words, they both contain common functionality.

REQUIREMENTS

PRIORITISATION ATHENA.B4

The process of giving each requirement a priority. We thus distinguish between high-priority, medium-priority and low-priority requirements, thus making the tasks of analysts and project leaders easier to schedule and execute. Furthermore, each requirement should be given a risk value. Hint: watch out for high-risk, high-priority requirements. See also Risk Management.

REQUIREMENTS

SCOPING ATHENA.B4

The process of eliminating unnecessary requirements as soon as possible in the Requirements Analysis phase.

REQUIREMENT

SOURCE ATHENA.B4

The stakeholder who wished the requirement in the first place. REQUIREMENTS

TRACEABILITY ATHENA.B4

The ability to trace the path of a requirement from initial Source through Elicitation, Analysis and Negotiation.

REQUIREMENTS

VALIDATION ATHENA.B4

The phase in which the requirements document is reviewed and formally validated. Concerns are omissions, conflicts and ambiguities and ensuring that the document follows quality standards.

REQUIREMENTS

VERIFICATION ATHENA.B4

Negotiation with stakeholders in order to determine if a requirement is accurate and correct. This step occurs in the Requirements Elicitation phase.

RISK

MANAGEMENT ATHENA.B4

Each requirement in the Analysis phase is examined and an estimate is made of the risk associated with it (for example, high, medium and low). Explicit risk assessment is a good way to identify requirements that will cause downstream development problems. Requirements that have both high risk and high priority deserve special attention.

SCENARIO Software engineering Is a description of a user interaction with a system or alternatively can be defined as an Use

Case instance. The scenario is a set of detailed activities. A generic name for an interaction session between actors and the system.

Page 52: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 48 / 92

STAKEHOLDER ATHENA.B4 A stakeholder is a person or an organisation who gains or loses something (could be

functionality, revenue, status, compliance with rules…) link to the usage of a system and can affect the development, deployment or usage of the system.

Any entity that directly or indirectly benefits from the introduction of the system. This group includes potential stakeholders. The types of stakeholder are: human/nonhuman, past/current/future, and direct/indirect

SCOPING ATHENA.B4 The first phase in Requirements Analysis. Requirements that are outside the scope of the

system are eliminated. This corresponds to an initial partitioning step and it is closely related to the Operating Environment phase.

SYSTEM

ARCHITECTURE ATHENA.B4

This is the architectural model for the system. This is similar to the way the system is partitioned into sub-domains (domain categories). The advantage of creating a system architecture is that many requirements can be associated with specific subsystems. Furthermore, in some cases the system architecture may be a requirement itself. Examples of system architecture are layers, client-server, blackboard, repository and pipeline.

SYSTEM

BOUNDARY ATHENA.B4

The dividing line between those requirements that are inside and outside the system. Actors fall outside the system boundary and hence are not modelled.

SYSTEM

FEASIBILITY STUDY

ATHENA.B4

The activity during Requirements Elicitation that is executed in order to determine if the system should be constructed. Attention should be paid to current technology, the organisation and recommendations on whether the system should be constructed.

SYSTEM

MODELLING ATHENA.B4

the process of decomposing a system into several loosely coupled subsystems. A number of abstract models can be created, such as Duffy's domain models, classification models, composition models stimulus-response and process models. Some of these activities that are executed in order to create these models border on Object Oriented Analysis (OOA).

TEST

CASE ATHENA.B4

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 ATHENA.B4

Is the step-by-step process needed in order to verify that the product meets all the interoperability requirements established.

Page 53: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 49 / 92

TEST

SCENARIO ATHENA.B4

Is a scenario identifying test environment. A test scenario can be defined as a Test Case instance.

TO-BE

SCENARIO ATHENA.B4

scenarios built from initial scenario implying subset of targeted solutions coming from Action Line (AL) A projects. It will be produced by multi-project teams, and it will aim to describe the ideal situation, considering that the targeted solutions will be available.

Software engineering Envisaged ideal situation in which Interoperability problems don’t exist.

TRACEABILITY ATHENA.B4 The term traceability is used to denote a relationship between a requirement and any other

element of the system engineering process such as a design component or specification document. Traceability has become a key driver for defining and developing government sponsored software. Traceability provides a relation between requirements, design and final implementation of a system. Traceability supports maintenance and provides the ability to discover the history of every system feature.

USE CASE ATHENA.B4? 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. A use case 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.

USER ATHENA.B4 Any person, organisation, or functional unit that uses the services of an information

processing system. In a conceptual schema language, any person or any thing that may issue or receive commands and messages to or from the information system. [Open Group, 2000]

VALIDATION ATHENA.B4 Confirmation by examination and provision of objective evidence that specifications conform

to user needs and intended uses, and that the particular requirements implemented can be fulfilled. The primary focus of validation is customer satisfaction.

Software engineering

Validation, for software, is the process of evaluating software to ensure compliance with specified requirements [ISO 9000-3: 1991,3.7]

Page 54: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 50 / 92

6 References

6.1 Documents [CU200312]: "Requirements Engineering: The state of the practice", Colin J. Neill and Phillip A.

Laplante, Penn State University, IEEE Software Nov/Dec 2003, N°6 Vol 20 [WI200404]: “Practical Requirements Engineering Solutions”, Roel Wieringa, Christophe Ebert,

IEEE Software March/April 2004,N° 2 Vol 21, p16 [NFI200310_1]: FP5 IDEAS Project D4.1: “The action plan for future research activity in the

scientfic focus area including priorities and schedules” [NFI200310_2]: FP5 IDEAS Project D4.2: “Project Management plan for large projects and

networks” [KO200306]: “Enterprise Inter- and Intra-Organizational Integration – building International

Concensus”, edited by Kurt Kosanke, Roland Jochem, Jams G. Nell and Angel Ortiz Bas, Kluwer Academic publishers,IFIP 108, ISBN 1-4020-7277-5

[GS200302]: “Guidelines for Successful Acquisition and Management of Software-Intensive Systems: Weapon Systems Command and Control Systems Management Information Systems”, DEPARTMENT OF THE AIR FORCE, Software Technology Support Center, Condensed Version, February 2003

[KE1976O1] Keeney, R. and Raiffa, H. (1976). Decisions with Multiple Objectives: Preferences and Value Tradeoffs. John Wiley and Sons.

[MU199601] H. J. Mueller, (1996). “Negotiation Principles”, (G.M.P O’Hare and N.R. Jennings eds.), Foundations of Distributed Artificial Intelligence, John Wiley & Sons, pp.211-230.

[IN200401] INTEROP (2004), available from www.interop-noe.org.

[B3200402] ATHENA B3 (2004), D. B3.1, ATHENA Interoperability Framework, in progress.

[BO200101] Boehm, B., Grunbacher, P. and Briggs, R. O., (2001). “Developing Groupware for Requirements Negotiation: Lessons Learned”, IEEE Software, May/June 2001, pp. 46-55. (Available from http://www4.in.tum.de/lehre/seminare/hs/SS04/requirements/winwin2.pdf)

[CO200403] Computas AS, (2004). METIS 3.6 Requirements Gathering Process, March 2004. (Internal Document).

6.2 Organisations This section provides descriptions of some organisations that are referred in this document. INCOSE: The International Council on Systems Engineering is a not-for-profit membership

organisation founded in 1990. INCOSE is an international authoritative body promoting the application of an interdisciplinary approach and means to enable the realization of successful systems (c.f. http://www.incose.org/).

ISO TC 184 SC 4: stands for International Standard Organisation Technical Committee 184 Sub-Committee 4. TC 184 deals with Industrial automation systems and integration, while SC4 addresses more specifically Industrial data. The mission of SC4 is to develop and promulgate standards for the representation of scientific, technical and industrial data, to develop methods for assessing conformance to these standards, and to provide technical support to other organizations seeking to deploy such standards in industry. It includes ISO 10303 part 233 (Application Protocol 233 or AP 233) that deals with system engineering (c.f. http://www.tc184-sc4.org/).

OMG: the Object Management Group (OMG) is an open membership, not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications (c.f. http://www.omg.org/).Their flagship specification is the multi-platform Model Driven Architecture (MDA), recently underway but already well known in the industry. It is based on the modelling specifications that are Meta Object Facilities (MOF), the Unified Modelling Language (UML), the XML Metadata Interchange Format (XMI), and Common Warehouse Metamodel (CWM). OMG's own middleware platform is Common Object Request Broker Architecture (CORBA), which includes the Interface Definition Language (IDL), and protocol IIOP (Internet Inter Orb Protocol). The Object Management Architecture (OMA) defines standard services that will carry over into Model Driven Architecture (MDA) work shortly. Object Management Group (OMG) Task Forces standardize Domain Facilities in industries such as healthcare, manufacturing, telecommunications, and others. Several

Page 55: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 51 / 92

specifications, connected to requirement engineering, are mentioned in this documents as Unified Modelling Language (UML) (use cases in the Unified Process) or Systems Modelling Language (SysML- c.f. http://www.sysml.org/)

VOLERE: Volere is the umbrella that covers the collection of requirements resources, templates, process, consulting and training. Since its inception, Volere has been used by thousands of organisations around the world (c.f. http://www.volere.co.uk/)

Page 56: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 52 / 92

7 Acronyms

Acronym Definition AL Action Line (within ATHENA Program) AP Application Protocol API Application Programming Interface B2B Business to Business B2C Business to Customer CMII Change Management Institute COM Common Object Model CORBA Common Object Request Broker Architecture (Object Management Group) CRC Commercial Requirements Specification CRF Centro Ricerche FIAT CWM Common Warehouse Metamodel (c.f. http://www.omg.org/ ) DoD Department of Defence DoDAF American Department of Defence Architecture Framework DoW Description of Work DRD Dynamic Requirements Definition DRDS Dynamic Requirements Definition System EAI Enterprise Application Integration EIC European Interoperability Centre EIS Enterprise Information System ERP Enterprise Resource Planning EUP Enterprise Unified Process (http://www.enterpriseunifiedprocess.info/) GUI Graphical User Interface ICT Information and Communication Technologies IDEAS Interoperability Development for Enterprise Application and Software IEM Integrated Enterprise Model INCOSE International Council on Systems Engineering (c.f http://www.incose.org/ ) ISO International Standard Organisation (c.f. http://www.iso.org/ ) IST Information Society Technologies (c.f. http://www.cordis.lu/ist/ ) IT Information Technologies MDA Model Driven Architecture (c.f. http://www.omg.org/ ) OMA Object Management Architecture (c.f. http://www.omg.org/ ) OMG Object Management Group (c.f. http://www.omg.org/ ) OOA Object Oriented Analysis PDM Product Data Management RM ODP Reference Model for Open Distributed Processing (c.f

http://www.dstc.edu.au/Research/Projects/ODP/standards.html ) RMI Remote Method Invocation (Java) SMEs Small and Medium Enterprises SOAP Simple Object Access Protocol (XML protocol) (c.f. http://www.w3c.org/ ) SOP Start Of Production STEP Standard for the Exchange of Product Model Data (ISO 10303) (c.f.

Page 57: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 53 / 92

Acronym Definition http://www.tc184-sc4.org/SC4_Open/SC4_Work_Products_Documents/STEP_(10303)/ )

TC Technical Committee TOGAF The Open Group Architecture Framework (c.f. http://www.opengroup.org/ ) TXT TXT e-solutions company SysML Systems Modelling Language (c.f. http://www.sysml.org/) UEML Unified Enterprise Modelling Language (c.f. http://www.ueml.org/ ) UML Unified Modelling Language (c.f. http://www.omg.org ) VBA Virtual Business Architecture W3C World Web Wide Consortium (c.f. http://www.w3.org/ ) WfMC Workflow Management Coalition XML eXtensible Mark-up Language XMI XML Metadata Interchange Format

Page 58: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 54 / 92

Appendix A. Requirements: multi-viewpoint analysis

A.1 Introduction During the last decade, requirements engineering has evolved into multidisciplinary fields,

including software engineering, systems engineering, product management or psychology. Requirements engineering is the branch of systems engineering concerned with the desired properties and constraints of systems, the goals to be achieved in the systems environment, and assumptions about the environment.

Requirements engineering varies greatly depending on the domain involved, and interfaces with software engineering, system engineering and enterprise modelling

But in all cases, requirements engineering maps needs to solutions, providing ways to gather, elicit, model and manage (phases of the requirements process) them, with associated heterogeneous set of concepts that are more or less formalized.

This annex describes these different phases and associated tools and approaches that exist in this field, with ATHENA as a background, objectives and organisation. Some candidate technologies that can be used as starting points for B4 are identified and analysed (Application Protocol (AP) 233, Volere template…). In all cases, some adaptation is required, because no requirements process addresses interoperability of systems an adequate way.

This annex also describes the context of a requirements process, i.e. different kind of projects, with very different life cycle models: V cycle, evolutionary, spiral… It appears that in the ATHENA context: • evolutionary or spiral life cycles are the more appropriate • different projects are involved implying improvement of the requirements process, both at solution

provider and requester side • boundaries of these projects have a significant impact on interoperability issue.

The conclusions coming from this multi-viewpoint analysis are reflected in the dynamic requirements principles, being applied to the ATHENA environment, in particular Principle 9, Principle 16 and Principle 20.

A.2 Requirements Engineering During the last decade, requirements engineering has evolved into a multidisciplinary fields,

including software engineering, systems engineering, product management or psychology. Requirements engineering is the branch of systems engineering concerned with the desired properties and constraints of systems, the goals to be achieved in the systems environment, and assumptions about the environment.

It deals with these aspects of systems engineering from the problem analysis stage to the system implementation and maintenance stages.

Requirements engineering varies greatly depending on the domain involved, ranging from public-administration, technical, enterprise…software to workflow systems, groupware, embedded systems and control software.

Requirements engineering interfaces with software engineering in that it specifies the desired function, quality, attributes and other properties of the software that is to be built or assembled.

It interfaces with system engineering and enterprise modelling in that it analyses the software problem that exist in the socio-technical system in which the software is to play a role, or the way the socio-technical system may evolved taking advantage of qualities and capacities the software products and Information Technologies (IT) provide.

As a problem analysis discipline, Requirements Engineering borrows from product management and psychology; it deals with goals to be achieved, the stakeholders who have these goals, and the problem to be solved within given business constraints.

In other words, Requirements engineering maps needs to solutions. Consequently large set of methodologies and approaches (Enterprise modelling, Software

engineering methodology) deals with requirements and propose different ways to gather, elicit, model and manage them, with associated heterogeneous set of concepts that are more or less formalized.

Page 59: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 55 / 92

A.2.1 Requirements management phases The phases/sub processes usually defined for requirements definition process are gathering,

elicitation, modelling and management. The way to organise and coordinate these phases/sub-processes together is project context

dependant. It can be strongly or weakly formalised by the project team. It can also be imposed by the client or

the project owner. It is the case for example of: • Military projects that impose structured and predefined approaches in call for tenders, before to

select a proposal and to launch a project. • Aeronautic projects, when an integrator selects partners and sub-contractors and have the

responsibility to of the respect of market constraint for the final delivered product (for example ATA rules, Aircraft certification rules, etc).

Techniques and methods for needs/requirements gathering and elicitation can also be very different. It appears from state of the practices in software engineering [CU200312] that very numerous techniques exist both for elicitation and modelling., that are part or not of different methodologies for software engineering (e.g. Unified Process, MERISE, Extreme Programming - Enterprise Unified Process or EUP), system engineering, knowledge engineering, etc. Within the scope of each technic and methodology, concepts are defined dealing with needs, requirements, actors, stakeholders, etc. The definitions are not the same and are strongly linked to the processes that are proposed to use the techniques or to apply a methodology.

All these contexts can lead to an explicit and constraint formalisation of the requirements process that does not fit exactly with elicitation, gathering, modelling and management phases.

This description of requirements process in 4 phases is nevertheless the one that will be used here, as it corresponds to precise activities to undertake within ATHENA and because it help to check, from management point of view, that some actions to plan are not forgotten nor under or over evaluated.

Finally, as this formalisation is usually used to classify tools and techniques for requirements engineering, it will help for the selection of existing tools to use for definition or implementation of the Dynamic Requirements Definition System (DRDS).

Next part consequently describes requirements determination phases (elicitation, analysis, negotiation and validation). It is followed by description of requirements modelling and management.

A.2.2 Requirements Determination The phase in a project life cycle consisting of the sub-phases Elicitation, Analysis and Negotiation,

Validation. A Commercial Requirements Specification (CRC) is transformed into a requirements document.

A.2.2.1 Requirements Elicitation Requirements elicitation is the phase of Requirements Determination in which an initial set of

requirements for a system is discovered. This set is 'unoptimised' in the sense that it may contain duplicate requirements, ambiguities, omissions and inconsistencies.

It includes a verification phase that consists in negotiation with stakeholders in order to determine if a requirement is accurate and correct.

It also include a system feasibility study i.e. the activity during Requirements Elicitation that is executed in order to determine if the system should be constructed. Attention should be paid to current technology, the organisation and recommendations on whether the system should be constructed.

Numerous techniques exist for elicitation as: • Ethnography • Soft Systems Methodology • Protocol analysis • Throwaway prototype • Scenarios & use cases • Formal modelling • Semi formal modelling

Page 60: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 56 / 92

• Informal modelling • Designer as apprentice • Cooperative requirements capture • Quality Function Deployment • Data Mining

Some are “Group consensus” type as User-Centred design, joint Application Design, interviews or focus groups.

A.2.2.2 Requirements Analysis The phase in Requirements Determination 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.

It includes the process of eliminating unnecessary requirements, that are outside the scope of the system, as soon as possible in the Requirements Analysis phase. It is called requirements scoping. It corresponds to an initial partitioning step and it is closely related to the Operating Environment phase.

It also includes the prioritisation of requirements, i.e. the process of giving each requirement a priority. We thus distinguish between High-priority, medium-priority and low-priority requirements are distinguished, thus making the tasks of analysts and project leaders easier to schedule and execute. Furthermore, each requirement should be given a risk value. Hint: watch out for high-risk, high-priority requirements. Each requirement in the Analysis phase is examined and an estimate is made of the risk associated with it (for example, high, medium and low). Explicit risk assessment is a good way to identify requirements that will cause downstream development problems. Requirements that have both high risk and high priority deserve special attention.

For a complex system, a system architecture can be used, i.e. an architectural model for the system. This is similar to the way the system is partitioned into sub-domains (domain categories). The advantage of creating a system architecture is that many requirements can be associated with specific subsystems. Furthermore, in some cases the system architecture may be a requirement itself. Examples of system architecture are layers, client-server, blackboard, repository and pipeline.

To structure the requirement and support analysis (but also negotiation, validation and management), several techniques exist: • Object-oriented analysis • Structural Analysis Design technique • Structural Requirements Definition • Structure Systems Analysis & Design Methodology • Structured Entity Relationship Model • Jackson System Development

Such a list is to be extended when taking into consideration Enterprise modelling, System engineering or Knowledge engineering.

It is important to take into consideration that, according state of the practice, requirements modelling for software engineering used most of the time: • Informal approach (51%) • Semi-formalized approaches (27%). It is usually Unified Modelling Language (UML) use case

diagrams and textual documents with a template for functional requirements, textual documents for non-functional requirements.

• Formal (only 7%) • There is no response from 15% of the group concerned by the survey.

It is important, because it shows that formal modelling of needs and requirements is not so used nor so accessible to end-users. Unified Modelling Language (UML) is almost not used (it means very few diagrams and construct) for approach like Extreme Programming (Requirements phase). It is one important challenge for Enterprise Modelling to provide language that are more useable and understandable to help to elicit and structure the requirements of different involved actors and stakeholders.

Page 61: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 57 / 92

A.2.2.3 Requirements Negotiation This is an activity in which stakeholders meet to discuss and resolve problems related to the

requirements in the Requirements Analysis phase. It usually requires having a clear vision of the project objectives and of project members’ common

and antagonist interests. Piloting a project by objectives (set of common objectives at the program level, agreed by all the project partners), is a way to structure the space of negotiation.

Such an activity is strongly linked to the nature of the project. For complex projects implying several stakeholders and actors with different interest, it is important to understand the project sociology.

Some approaches are defined as modelling of stakeholders, promoted by some consultant in Project sociology modelling (c.f. http://www.volere.co.uk or http://www.scenarioplus.org.uk ). In these approaches, a clear distinction is done between stakeholders, operator of a system. It allows to clarify the notion of “end-user”, that is more dedicated to software engineering to name people who will operate the system and use it for a business purpose (i.e. linked with the main activity of the enterprise). For example, the end-user of a workflow system is the actor of the business process instance receiving notification for action. But what about the workflow system administrator, the person who will install and deploy it within the enterprise,… Who is really an “end-user” then? It is important to point that requirements coming from each kind of user are not of the same nature an do not reflect some kind of interest nor preoccupation. For each system it is required to categorise “end-users”, both the way they are operating with the system, interest they have in the system, power they have on the decision of the enterprise according the concerned system.

Finally a stakeholder is not necessarily an “end-user”, but have a great impact on requirements and negotiation of these requirements. “End-user” is more used in the context of software engineering, to distinguish developers from people who will use the software.

A.2.2.4 Requirements Validation The phase in which the requirements document is reviewed and formally validated. Concerns are

omissions, conflicts and ambiguities and ensuring that the document follows quality standards. They then can be input for development phase.

A.2.3 Requirements modelling Specification of the desired function of the targeted section can be done using modelling

techniques that led to: • Representation models (for understanding), • Formal explicit models (that can be used for analysis and operationalisation) • Or even simulation models.

Using formal modelling for functional requirements allow validating the functional model at the earlier phase of the project. It is used for complex industrial products, as for example aerospace products requirement embedded software. It is less used for software engineering, if even used. It should imply advance testing capability, but it seems to be very difficult to provide efficient tests definition that will allow to certify behaviour of an application system. Some examples that illustrate this difficulty are certification of STEP interface (very difficult to obtain at an IS level) or CORBA vertical interfaces (that are almost inexistent with Object Management Group specification).

From the state of the practice, it seems that there is not an ideal modelling technique or language. The importance is to use the more adequate and efficient modelling technique for each phase of requirements process and for a given purpose and planned usage.

According the concerned domain (software engineering, enterprise modelling, system engineering, etc), the techniques and modelling languages used are different.

In software engineering one of the more used language is Unified Modelling Language (UML). UML is not really stable (short cycle of evolution compare to life cycle of enterprise application: about 2 or 3 years against 10 to 30 years) or mature (UML is not yet at the level of other specialised languages nor necessarily adapted for modelling for example enterprises or systems of systems) for the time being, especially with UML 2.0 being produced.

In enterprise modelling, Unified Enterprise Modelling Language (UEML) is being developed. But some interesting constructs for modelling can come from several methodologies as CIMOSA or GRAI. As an example, GRAI propose some constructs concerning decision making that are particularly

Page 62: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 58 / 92

adapted for the ATHENA purpose. In system engineering, different languages exist that are not necessarily easy to use (as Petri

Nets). A standard for interchange is under development in the manufacturing area (ISO STEP Application Protocol 233 or AP233) for system engineering. It should allow exchanging systems model between different tools and language (including Unified Modelling Language or UML). One unit of functionality of Application Protocol (AP) 233 deals with requirements engineering.

In requirements engineering, Application Protocol (AP) 233 can be used as an interchange format for requirements, as strongly connected to INCOSE activities.

It is not obvious that such languages will be adapted if they are not aiming quick and easy understanding of interviewed people for need gathering. Several of them can nevertheless be used for different purpose. To be able to keep these different models in coherency should nevertheless be very important.

Some models for cooperating requirements engineering with scenarios were also developed by CREWS Esprit Long term research project 21.903. The CREWS project aimed to develop, evaluate, and demonstrate the applicability of, methods and tools for cooperative scenario-based requirements elicitation and validation. A reference model was developed Objectives of CREW project is the following: “as information technology is becoming an integral aspect of organisations, more stakeholders with less formal training must be involved in requirements elicitation, validation, and usage over long periods of time in a traceable manner. Effective and efficient team interaction become even more critical because systems must be continuously adapted to changing business practice and needs. Different kinds of scenarios (recorded current practice, animated specifications, use cases, illustrative examples) have been suggested to help this task but must be better understood, effectively supported, and interrelated with traditional requirements engineering methods which in themselves do not offer adequate solutions for these problems. The CREWS project will develop four related methods and tools for cooperative scenario-based requirements elicitation and validation. Multiple stakeholders will be supported in eliciting and negotiating requirements under different perspectives from real world scenes captured in multimedia. Local natural language understanding will allow stakeholders to augment graphical requirements representations with short natural language statements. Validation will be facilitated by cooperative requirements animation, and by systematic comparison of the specification with usage test scenarios interactively generated using domain knowledge.

A.2.4 Requirements management This part is a synthesis of different methods and tools that allow managing the

requirements, with a special focus on some ATHENA needs. It aims to provide an overview of such a tools in order to provide inputs that should be part of the background for definition of Dynamic Requirements Principle. It can be a starting point for requirements collection and classification, on the Dynamic Requirements Definition System (DRDS) itself.

For complex project or products, with complex set of actors/stakeholders, it is necessary to manage and structure the requirements an efficient way. The needs are to be formalized a coherent and comprehensive way. It is also necessary: • to make requirements and their status available all along a project for all of the actors of the

project that need to access or to produce these requirements. • to check if what is expected is what is produced (quality foundation) • to manage change management all along the life cycle of the project • to be able to identify interaction and dependencies between the requirements in order to measure

impacts of changes • …

Numerous tools are available to support requirements engineering. A group of well-known is provide in [WI200404], at http://www.incose.org/tools/tooltax.html or at www.volere.co.uk/tools.html . Some of them can be candidate to be used within the ATHENA project. Nevertheless, before to review them, a precise collection and analysis of ATHENA needs concerning requirements management is necessary.

As a starting point, it is considered that we have to target openness, used software product independency, adaptation to complex system of systems, adaptation to ATHENA program and projects organisation.

List of function of a Requirements Engineering system, from INCOSE: the link to INCOSE

Page 63: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 59 / 92

organisation WEB site provides a table of different available tools with the response from their vendors concerning some given requirements concerning awaited function or quality of such a product. The list can be use as a starting point to have an idea of function usually found in a Requirements management system. Such function will probably have to found as list of function proposed by the Dynamic Requirements Definition System (DRDS). They are also reflecting some generic use cases and processes link to requirements process.

1.Capturing Requirements/Identification 1.1. Input document enrichment / analysis 1.1.1. Input document change / comparison analysis 1.2. Automatic parsing of requirements 1.3. Interactive/semi-automatic requirement identification 1.4. Manual requirement identification 1.5. Batch mode operation 1.5.1. Batch-mode document/source-link update 1.6. Requirements classification 2. Capturing system element structure 2.1. Graphically capture systems structure 2.2. Textual capture of systems structure 3. Requirements flowdown 3.1. Requirements derivation (req. to req, req. to analysis/text) 3.2. Allocation of performance requirements to system elements (weight, risk, cost, etc.) 3.3. Bi-directional requirement linking to system elements 3.4. Capture of allocation rationale, accountability, test/validation, criticality, issues, etc. -- if so,

how and what mechanism does it use. 4. Traceability analysis 4.1. Identify inconsistencies (orphans,...if so, what kind of...) 4.2. Visibility into existing links from source to implementation--i.e. follow the links. 4.3. Verification of requirement (was it done, how was done) 4.4. Requirement performance verification from system elements (roll up of actuals) 5. Configuration Management 5.1. History of requirement changes, who, what, when, where, why, how. 5.2. Baseline/Version control 5.3. Access control (modification, viewing, etc.) 6. Documents and other output media 6.1. Standard specification output (if so, what kind) 6.2. Quality and consistency checking (spell, data dictionary, ) 6.3. Presentation output 6.4. Custom output features & markings (definable tables, security marking) 6.5. WYSIWYG previewing of finished output 6.6. Status reporting 6.6.1. Technical Performance Measurement status accounting 6.6.2. Requirement progress/status reporting 6.6.3. Other ad hoc queries and searches 6.7. Support and display special character sets. 7. Groupware 7.1. Support of concurrent review, markup, and comment 7.2. Multi-level assignment/access control 8. Interfaces to other tools 8.1. Inter-tool communications

Page 64: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 60 / 92

8.1.1. Interfaces to other tools? 8.1.2. External Applications Program Interface available 8.1.3. Support Open database system (standard query access) 8.1.4. Import of existing data from various standard file formats? 8.2. Intra-tool communications 8.2.1. Exchange of information between same-tool different installations 8.2.2. Consistency/comparison checking between same-tool datasets 9. System Environment 9.1. Single user/multiple concurrent users 9.2. Multiple Platforms/Operating Systems? 9.3. Commercial vs. unique database 9.4. Resource requirements 9.4.1. Memory requirements 9.4.2. CPU requirements 9.4.3. Disk space requirements 10. User Interfaces 10.1 Doing one thing while you are looking at another 10.2 Simultaneous update of open views 10.3 Interactive graphical input/control of data 10.4 Which window standard do you follow? 10.5 Executable via scripts (recordable) or macros 10.6 Web browser Interface? 10.7 Edit Undo Function Support 11. Standards--which one do you comply with? 12. Support and maintenance 12.1. Warranty 12.2. Network license policy 12.3. Maintenance and upgrade policy 12.4 On-line help 12.5 Internet access/World Wide Web home page location 12.6 Phone support 12.7 Support User's Group 13. Training 13.1 Tool specific training classes. 13.2 Training available at customer's location. 13.3 Recommended training time 13.4 Software installation with only basic training. 14. What other requirements management features do you as a tool supplier think are important

(modelling, etc.)? List of key features for a Requirements Engineering System: In [WI200404], list of tools are

provided in a table providing some key features and the tools it integrate with, ranked from the most relevant for the respective purpose. The Entry-level cost (level of magnitude from low to high) is also provided.

The key-features list includes: • Application Programming Interface (API) available • Change management • Database-centric • Database-like view

Page 65: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 61 / 92

• Entry level • Entry-level requirement management • Impact analysis • Information modelling • Large project • Large systems • Life cycle oriented • Modelling • Multi-users distributed project • OO analysis and entity relationship method for database design • Requirements centric • Requirements classification • Team-centric • Test support • Text processing • Traceability • WEB Browser forms • eXtensible Mark-up Language (XML) support

If these lists reflect usual function and key features of Requirements Management systems, it does not provide anything concerning requirements information models that are used. It is also difficult to have an idea about capacity of tools to deal with complex socio-economic features.

To have a visible and easily accessible requirements models, two interesting inputs were identified, respectively Application Protocol (AP) 233 for information model and VOLERE Template for socio-economic analysis.

VOLERE Template: the template is provided with complete set of definition and explanation that make it easy to use. This template seems appropriate to ATHENA purpose (multi-actor/stakeholders/clients), even if it needs to be adapted to ATHENA program: ATHENA will provide several deliverables, each of them concerning different set of actors/stakeholders/clients. Different systems will be produced, and interoperability will be a quality of interaction between these subsystems and existing enterprise applications. In such a context, it will be important to be clear about the targeted subsystem and/or deliverable. It will also be important to be very clear about who the client is and who the consumer/users/operators are.

VOLERE provides within the template a classification of requirements (some being functional, some others non-functional). One important point is that there is no point about interoperability (only about interfaces). As for the other methodologies for several domains (software, knowledge, system… engineering), it reflects the fact that the approaches are ONE system centric, and are not based on production of systems of systems. Nevertheless, the VOLERE template is very useable, and should be a good basis when completed in order to comply to ATHENA specificities.

Page 66: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 62 / 92

Here follow an extraction of the VOLERE template that can be used as a starting point for classification of requirements in B4, and for each ATHENA project.

PROJECT DRIVERS 1. The Purpose of the Product 2. Client, Customer and other Stakeholders 3. Users of the Product PROJECT CONSTRAINTS 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions FUNCTIONAL REQUIREMENTS 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements NON-FUNCTIONAL REQUIREMENTS 10. Look and Feel Requirements 11. Usability Requirements 12. Performance Requirements 13. Operational Requirements 14. Maintainability and Portability Requirements 15. Security Requirements 16. Cultural and Political Requirements 17. Legal Requirements PROJECT ISSUES 18. Open Issues 19. Off-the-Shelf Solutions 20. New Problems 21. Tasks 22. Cutover 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions

Possible application with ATHENA projects Should be link to ATHENA objectives and resources, include “partner” applications. Should be link to AIF The product here should be the deliverable of the project 19 address the fact that already solutions may exist (interchangeable or not) 20 what are the new problems the provided solutions cause in ATHENA environment? 21 help to build the planning 22a linked with dealing with legacy data

To be useable, such a template is to be adapted to deliverables that are not software

components. ATHENA internal and “external” actors and stakeholders are to be considered. Sometimes, ATHENA deliverables does not target directly “external users”, e.g. a new software development methodology for new family of agile and interoperable products will target software providers, not directly end-users of the enterprise application that will benefit of the software developed by software providers. Finally it should be adapted when a project address interoperation between two existing systems.

Page 67: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 63 / 92

Despite all these adaptation, VOLERE illustrate an approach that is very pragmatic, paper document based, that does not require any software product to launch elicitation of needs and requirements. From such a template, it should be very easy, if used in ATHENA, to populate the future Dynamic Requirements Definition System (DRDS) database when ready after collection of requirements.

STEP ISO 10303 part 233: in the system engineering and manufacturing area, a standard is being developed (ISO 10303 part 233), that allows to formalize requirements for system engineering, an can be use for interchange of requirements between several tools. EuroSTEP provides a prototype demonstrating Application Protocol (AP) 233, , illustrating in particular how it is possible to import/export DOORS requirements. Work of experts who defined this application protocol is strongly link with the INCOSE activities, and consequently awareness of different tools and approach when developing this application protocol is insured. Its development is also strongly connected to Systems Modelling Language (SysML), a profile for system engineering developed by Object Management Group (OMG), and DoDAF (American Department of Defence Architecture Framework)

This standard should be very useful to provide information schema that support: • Completeness and improvement the informational model of Dynamic Requirements Definition

System (DRDS) in the area of requirements • Standardised definitions (one ontology on requirements linked to system of systems, that is on

line with the ATHENA problematic) • Openness of Dynamic Requirements Definition System (DRDS) of ATHENA and is solution

independence, by expressing the concepts of the PDESR information model using the Application Protocol (AP) 233 application protocol could do it.

• traceability of requirements, configuration management, links with functional decomposition of services and architecture components of ATHENA solutions and AIF

A graphical representation is provided by the standard using the Express-G formalism that is available on the following page.

Having a quick look at the application protocol, we can briefly extract some concepts that are available in Application Protocol (AP) 233: • An abstract requirement_definition, that is context independent, may be a

textual_requirement_definition, a structured_requirement definition, or a model_defined_requirement_definition.

• A requirement_instance is a context dependant representation of a requirement (associated to a function of the system or a physical instance of the system).

• A hierarchy may be defined between requirements, with association (requirement_composition_relationsip) between a requirement_definition and a requirement_occurrence (place_holder of the requirement).

• Classification of requirements is done using requirement_class, requirement_class_relationship, and requirement_requirement_class_relationship.

• Persons and organisations are linked to requirement using requirement_allocation_relationship. • It is also possible to attached approval to requirements. • Finally change management and configuration management capabilities are integrated in

Application Protocol (AP) 233, that can be applied to requirements.

Page 68: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 64 / 92

Figure 17 Application Protocol 233 requirement model in EXPRESS G

Page 69: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 65 / 92

Without aiming to be exhaustive, this quick overview shows that the information model provided in Application Protocol (AP) 233 is very complete and is able to provide numerous features and ideas of interest for the PDESR information model and for the associated processes.

One recommendation should be to start from such an application protocol, and to create classifications of requirements, adapted to ATHENA different viewpoints, using Application Protocol (AP) 233 constructs.

Each viewpoint should be adapted to precise actors, ATHENA program and ATHENA Requirements processes phases that are to be defined in B4.

Finally, if adopting a system approach, several other constructs of Application Protocol (AP) 233 should be of interest to link the requirements to the systems that will be produced, delivered or studied by ATHENA projects.

A.2.5 Requirements and projects A project is a set of activities necessary to deliver at a given time, a response to a need of a client

i.e. a solution. This solution is to be observable and unique (i.e. not a series). This makes the path to realize it

also unique. In other words, the path to realize it is an instance of process and not a process. It is not repeatable and always project specific.

Similar description are provided in [DO200302]: “A project is a group of activities undertaken to meet one or more specific objectives. These

objectives could include solving a problem, building or upgrading a system or product, launching a product or service, implementing a strategic plan, changing a process, or one of many other unique efforts. Projects can differ in size from small and simple to large and complex. However, to accomplish specific objectives, projects are temporary and have specific starting and completion dates. Ongoing operations such as operating a maintenance facility or publishing a magazine are not projects. Performing a specific aircraft avionics upgrade or printing a monthly issue of a magazine are projects. Limited, specific performance times and objectives are how projects differ from programs. Programs are generally much larger efforts than projects, with longer duration. Relative to projects, they are ongoing rather than temporary efforts. While this chapter focuses primarily on project management, most of what is presented will also apply to programs. Programs are made up of multiple projects and in many cases can be treated as longer, more complex projects. Projects are often divided into smaller components or activities, usually based on technical and functional disciplines such as engineering, manufacturing, testing, and procurement...”

The relationships between programs, projects, and activities are shown in following figure:

Figure 18 Relationships Between Program and Project

Important differences exist between projects concerning who play the roles of the different actors of the project: project activities responsible (project manager), the project object/deliverable owner(s), the project object/deliverable user(s), the project resource provider(s) and the pilot of the project. Multiple combinations exist, that can be very complex, as for example an FP6 Integrated Project. It is source of multiple levels of mixed requirements and constraints, both on deliverables and on project activities. The way to structure the requirements and to organize the requirements process is link to the project actors structure.

Requirements Engineering is more and more used during for all kind of projects. Way to use it and associated tools depend on the objectives, concerned organisations and types of deliverable (e.g. knowledge/reports, software product, industrial product, knowledge…) of the project.

Page 70: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 66 / 92

What will be delivered by the project (report, knowledge, prototype, software product…) also structures the requirements and drives the requirements process. It is always driven by very simple set of question about the deliverable: what is it, who will use it, why, when, how, where. The “who” will allow identifying the “end-users”. The “why” will allow finding several stakeholders. “When”, “how” and “where” will allow to categorise end-users, stakeholders and requirements all along the life cycle of the deliverable.

Considering different models of project life cycle, similar sequences usually appear, as for example the following one:

Why the deliverable (needs, opportunity) What is the deliverable (design, functional requirement) How will be produce the deliverable (production planning) Realisation of the deliverable (production) Delivery and acceptation

According [DO200302], usual project life cycle can be described by the following picture:

Figure 19 Usual Project Life Cycle

The usual product life cycle can be described by the following picture:

Figure 20 Usual product life cycle

Each execution phase of the project life cycle, for software, will include an adapted software development life cycle: Requirement, Design, Development, Test, and Implementation.

Page 71: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 67 / 92

Figure 21 Phases of Project Life Cycle

For a complex project, each phase of software development becomes a project by itself.

Figure 22 Complex Project and Life Cycle

A procurement phase before execution may be added when execution is subcontracted. Many life cycle models or life cycle exist, most of them being the variation of 3 classical models:

waterfall, incremental and spiral models, that are described and analysed as following in [DO200302]. The choice of the project life cycle is also link to the requirements (stable or not) and of the users need (clear or unclear).

The waterfall model, also known as the linear sequential model, is shown in Figure 23 with its major phases, milestones, and products. It is a highly structured development process. It is the “traditional” approach to software development and was derived from defence and aerospace project life cycles. It is considered superior to the previously used “code and fix” methods of software development, which lacked formal analysis and design.

Figure 23 The Waterfall Model

The waterfall model is documentation-intensive, with earlier phases documenting what must be done and subsequent phases adding greater detail and defining how it should be done. The output from one phase serves as the input to the next phase, with the project flowing from one step to the next in a waterfall fashion. Phases are assumed to be sequential, with only localized feedback during the transition between phases. This is accomplished by using reviews as gates. Comprehensive reviews validate the work of one phase, and require the resolution of any problems before development is allowed to proceed to the next phase. An important consideration for the Waterfall model is that fixes or modifications are often put off until the maintenance phase. This can be very

Page 72: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 68 / 92

costly, as the cost to correct a problem gets higher with each successive phase. Advantages:

• system is well documented, • phases correspond with project management phases, • cost and schedule estimates may be lower and more accurate, • details can be addressed with more engineering effort if software is large or complex.

Disadvantages: • all risks must be dealt with in a single software development effort • because the model is sequential, there is only local feedback at the transition between phases • a working product is not available until late in the project, • progress and success are not observable until the later stages. • If a mistake or deficiency exists in the documentation of earlier phases, it may not be discovered

until the product is delivered • Corrections must often wait for the maintenance phase.

Application: the Waterfall model can be successfully used when requirements are well understood in the beginning and are not expected to change or evolve over the life of the project. Project risks should be relatively low.

The incremental model is essentially a series of waterfall cycles. One variant is shown following figure. The requirements are known at the beginning of the project and are divided into groups for incremental development. A core set of functions is identified in the first cycle and is built and deployed as the first release.

Figure 24 The Incremental Model

The software development cycle is repeated, with each release adding more functionality until all requirements are met. Each development cycle acts as the maintenance phase for the previous software release. While new requirements that are discovered during the development of a given cycle can be implemented in subsequent cycles, this model assumes that most requirements are known up front. The effort is planned and executed to satisfy the initial list of requirements. A modification to the incremental model allows development cycles to overlap. That is, a subsequent cycle may begin before the previous cycle is complete.

Advantages: • Provides some feedback, allowing later development cycles to learn from previous cycles. • Requirements are relatively stable and may be better understood with each increment. • Allows some requirements modification and may allow the addition of new requirements. • It is more responsive to user needs than the waterfall model. • A usable product is available with the first release, and each cycle results in greater functionality. • The project can be stopped any time after the first cycle and leave a working product. • Risk is spread out over multiple cycles. • This method can usually be performed with fewer people than the waterfall model. • Return on investment is visible earlier in the project. • Project management may be easier for smaller, incremental projects. [7] • Testing may be easier on smaller portions of the system.

Disadvantages: • The majority of requirements must be known in the beginning.

Page 73: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 69 / 92

• Formal reviews may be more difficult to implement on incremental releases than on a complete system.

• Because development is spread out over multiple iterations, interfaces between modules must be well defined in the beginning.

• Cost and schedule overruns may result in an unfinished system. • Operations are impacted as each new release is deployed. • Users are required to learn how to use a new system with each deployment.

Application: the incremental model is good for projects where requirements are known at the beginning, but which need functionality early in the project or which can benefit from the feedback of earlier cycles. Because each cycle produces a working system, it may also be advantageous for projects whose continued funding is not assured and may be cut at any time. It is best used on low to medium-risk programs. If the risks are too high to build a successful system using a single waterfall cycle, spreading the development out over multiple cycles may lower the risks to a more manageable level.

The evolutionary model, like the incremental model, develops a product in multiple cycles. Unlike the incremental model, which simply adds more functionality with each cycle, this model produces a more refined prototype system with each iteration. The process, shown in following figure, begins in the centre with initial requirements and plans, and progresses through multiple cycles of planning, risk analysis, engineering, and customer evaluation. Each cycle produces a prototype that the customer evaluates, followed by a refinement of requirements. Specification, development, and testing activities are carried out concurrently (in the engineering quadrant) with rapid feedback. Since requirements continue to change, documentation is minimal, although essential information must still be included for understanding the system and for future support. Implementation compromises are often made in order to get the prototype working – permanent fixes can be made with the next prototype. Operational capability is achieved early, but users must be willing to learn how to use each new prototype.

Figure 25 The Evolutionary Model

General system requirements must be known prior to development. This is particularly helpful where evolving technology is being introduced into the project. The evolutionary model relies heavily on user feedback after each implementation to refine requirements for the next evolutionary step.

Advantages: • Project can begin without fully defining or understanding requirements. • Final requirements are improved and more in line with real user needs. • Risks are spread over multiple software builds and controlled better. • Operational capability is achieved earlier in the program. • Newer technology can be incorporated into the system as it becomes available during later

prototypes. • Documentation emphasizes the final product instead of the evolution of the product. • This method combines a formal specification with an operational prototype.

Disadvantages

Page 74: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 70 / 92

• Because there are more activities and changes, there is usually an increase in both cost and schedule over the waterfall method.

• Management activities are increased. • Instead of a single switch over to a new system, there is an ongoing impact to current operations. • Configuration management activities are increased. • Greater coordination of resources is required. • Users sometimes mistake a prototype for the final system. • Prototypes change between cycles, adding a learning curve for developers and users. • Risks may be increased in the following areas:

o Requirements – Temptation to defer requirements definition. o Management – Programs are more difficult to control. Better government/contractor cooperation

needed. o Approval – Vulnerable to delays in funding approval, which can increase schedule and costs. o Architectural – Initial architecture must accommodate later changes. o Short term benefits – Risk of becoming driven by operational needs rather than program goals. o Risk avoidance – Tendency to defer riskier features until later. o Exploitation by suppliers – Government bargaining power may be reduced because initial

contract may not complete the entire task, and subsequent contracts are not likely to be competed.

o Patchwork quilt effects – If changes are poorly controlled, the product quality can be compromised.

Application: the evolutionary model can be employed on most types of acquisitions. However, it is usually employed on medium to high-risk systems. The evolutionary model should be considered for systems where requirements are not all known or not yet refined, but are expected to evolve. It is more applicable to new systems than upgrading existing software. The developing and using organizations must be flexible and willing to work with evolving prototypes. Programs well suited to employ the evolutionary model have some or all of the following characteristics. • Software intensive systems. • Have a large number of diverse users. • Have rapidly changing software technology. • Developing an unprecedented system. • Humans are an integral part of the system. • Limited capability is needed quickly.

The spiral model was developed with the goal of reducing risk in the software life cycle. It combines elements of the waterfall, evolutionary, and incremental models, and depending on how it is implemented can strongly resemble any combination of the others. The model’s spiral nature can be seen in following figure, one of several variants. The project starts at the centre and progresses through multiple cycles, each working through the software development activities associated with the four quadrants: 1. Determine objectives, alternatives, and constraints. 2. Evaluate alternatives. Identify and resolve risks. 3. Develop the next-level product. 4. Plan the next phase.

Risk management is a key element of the Spiral model and each round of the spiral identifies problems with the highest risk and develops solutions for that set of problems. The process may even resemble a waterfall with additional risk management techniques. Each cycle ends in a review in which stakeholders agree on plans for the next cycle. While a prototype may be produced for IOC, software is usually not developed for release until the last cycle.

Page 75: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 71 / 92

Figure 26 The Spiral Model

The Spiral model has been used extensively in the commercial world because of its performance in a market-driven environment. It significantly reduces technical risk and more easily incorporates new technology and innovations. At the same time, it tends to increase cost and schedule risks. In the past the Spiral model has been difficult to implement in the Department of Defence (DoD) environment. This is because contracts with predefined deliverables and schedules do not easily accommodate repeating phases, requirement tradeoffs, and changing deliverables. However, use of the Spiral model, where applicable, has become somewhat popular in the Defense and Aerospace industries.

Advantages • It provides better risk management than other models. • Requirements are better defined. • System is more responsive to user needs.

Disadvantages • The spiral model is more complex and harder to manage. • This method usually increases development costs and schedule.

Application: the spiral method should be considered for projects where risks are high, requirements must be refined, and user needs are very important.

The following matrix provides way to make a selection.

Page 76: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 72 / 92

Figure 27 Matrix of Project Life Cycle Choice according Constraints

Looking at this matrix, project life cycle choice is needs/requirements dependant. The requirement process will also be different according the kind of project life cycle. Finally, to achieve interoperability within an enterprise is more an ongoing effort than a project, as it never finishes. This effort can be done by the mean of several projects dealing with some aspects of the enterprise information system infrastructure or with some of its components, where interoperability aspects are addressed. For example, when developing a new application, some non functional requirements can be defined concerning interoperability aspect. Dealing with enterprise information integration, through for example deployment of an Enterprise Application Integration (EAI) system, interoperability aspects will always be addressed, through the choice of required connectors. Some ongoing efforts like enterprise information system urbanisation are also addressing interoperability, though definition of well defined interfaces and urbanism rules concerning collaboration between the different parts of the information system of the enterprise.

Way to collect requirements and type of project is also linked to the concerned companies organisation, culture and practices in the area of requirements engineering. Culture and practices are also connected to the domain of activities of the concerned companies, and to the used tools.

For example, a company developing software may use the Unified Rational Process that propose a requirements phase, with identification of several artefacts to produce at different phases of the project life cycle and way to formalize it (e.g. Use case diagram to formalize it). A company developing complex industrial product will use in conjunction different requirements management tools (e.g. DOORS), Functional modelling tools (e.g. StP) that will allow to provide a functional model of the deliverable, Product Data Management systems (e.g. Windchill that allows for example to link function of the product to technical solutions and to measure), configuration management tools (from a quality point of view - will allow to check that there is not over quality, i.e. who produce all what is required and only what is required)

Page 77: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 73 / 92

Drivers of the project have also a significant impact on requirements phase. For example, when owner of the deliverable drives the project (we consequently consider here the development of an application), defines and imposes the methodology used for requirements phase, we are in a case where the project aims to respond precisely to specific needs of the owner. The application orients the development of technical solutions.

When solution provider drives the project (case of Commercial of the shelves software product), he defines the methodology for requirements phase of the product. The project aims to provide a solution that can be applied and used by the widest market, and consequently to provide a generic solution (e.g. Enterprise Resource Planning systems or ERP systems, Product Data Management systems or PDM systems,…). The market orients the development of technical solutions.

When a commercial of the shelve solution is selected for an application within a company, two different projects exist and are to be considered. The first one concerns the software product development. The second concerns application development within the enterprise (or set of organisation). In the second project, the technical solution requires a lot of adaptations that can be done through usage rules (methods), parameterisation of the software product, or by specific developments that extend and complete the software product to respond to the need of the enterprise and to provide final wished application. Let’s call it “Customisation of the solution”. The second project respond to the same logic than any project, i.e. a requirements phase do exist. The deliverable of this project is the deployed and operational application within the enterprise.

Finally, such an application is deployed within the enterprise, and has usually to be integrated in the legacy enterprise information system. As a project should have an identifiable result in a finite duration, with finite resources, this aspect is often putted of the scope of application projects. Interconnecting two applications is a project itself, which is undertaken latter, when the two operational systems are deployed and used. It led to, what is called today, islandisation of enterprise information system: several isolated applications, with heterogeneous formalisation of needs, technologies, objectives, etc. Successive interconnections during several decades led to complex and inextricable information system, the Gartner Group called the “Spaghetti model”: let’s change a component of the system; you just can’t measure the impacts. It appears that the major part of the budget of Information Departments is used for the maintenance of such a complex system. As a consequence more and more enterprise projects address integration of enterprise information system, that are other kind of projects to consider, that are linked to interoperability issue. The market of integration is becoming more and more important. In one hand, technological platforms as J2EE, .Net, CORBA, eBusiness Web services, Enterprise Integration Application Systems that provide tools for technical integration. In the other hand, tools for business integration connected to Business Process Reengineering, enterprise modelling, and knowledge management. The integration of the enterprise information systems is enterprise internal, and “Enterprise Information System Urbanisation” projects or program are launched within the enterprises (it is the case for example at Renault, EADS…). Business to Business (B2B) and Business to Customer (B2C) projects or programs are also launched to connect the enterprise to the outside, that are often based on other set of technologies and approaches, are these projects are more based on collaboration between different organisations, with a more complex socio-technical environment.

Infrastructures and architecture that integrate applications and the infrastructures are also subjects for different projects, and are more and more requiring consensus and holistic approach, being internal to the enterprise or external.

In such context, numerous projects produce and consume multiple requirements, and use several requirements systems and processes. These systems and processes are most of the time disconnected, due to the fact that these projects are most of the time not coordinated and decoupled. This is one of the brakes for interoperability.

These projects themselves become part of the continuously growing set of actors and stakeholders of interoperability. In such a context, it is more and more difficult to collect, analyse, negotiate and manage the requirements, due to the complexity of the stakeholders and projects portfolio structure. It is why some categorisation of requirements is needed, in order to master this complexity when taking into consideration multiple dimensions of the problem.

A challenge, when dealing with interoperability, is also to find the more adapted requirements models and processes to obtain sufficient level of integration and interoperability of the enterprise systems, with reasonable cost and well-identified benefits, for all the concerned stakeholders and

Page 78: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 74 / 92

projects. For real efficiency, such a model should be shared by enterprises, solution providers and researchers, but also by all the actors of the different running projects. Requirements categorisation has to take into consideration multiple projects aspect.

Approaches addressing interoperability issues at enterprise level have to cope with islandisation phenomena that is strongly connected to the scoping that each project have to establish, as resources and duration are limited, and as deliverables of a project have to be identifiable and measurable.

It is important to point out that, taking into account the multi-project aspect of the interoperability problem, interoperability can’t be a deliverable of a research project, nor of a project delivering a product (as a software product).

It is also important to consider that interoperability is always achieved in the context of an operational activity, and on between specific applications in a specific context. It is not something achieved between two software products, but between two (or more) instances of two deployed customisation of one (or more) software product, in a given operational context. It is consequently not possible to deliver interoperability of two application systems for a project dealing with software product engineering, as such a project does not deal with deployment and customisation of a specific enterprise application. Software product engineering and software engineering may nevertheless contribute, for example by providing new type of software products architecture and methodologies allowing ensuring by default agility, openness and coherency of the different viewpoints (according RM-the Reference Model for Open Distributed Processing or RM ODP) of customised solutions, with connectors to the main technical (e.g. CORBA or Common Object Request Broker Architecture, Workflow Management Coalition or WfMC, Common Object Model or COM, Remote Method Invocation or RMI, Simple Object Access Protocol or Simple Object Access Protocol or SOAP/ Web Services….) and business oriented (e.g. ISO STEP, OAGIS, Vertical CORBA interfaces) infrastructures, taking advantage of enterprise modelling and ontology.

A significant effort is also to be done by the industrial enterprise: • To improve their methodological approach to specify characteristic of an application and

of interoperation between application, both at business infrastructure level (e.g. urbanism strategy) than at the engineering level (e.g. by providing constraint during requirements process concerning to be used business/discipline/organisation ontology’s);

• For Information Technologies (IT) departments, Enterprise Information System (EIS) administrators and end-users maintaining operational interoperability of enterprise systems in use, supporting cooperation projects.

In conclusion, “requirements” and “project” concepts are strongly interlinked. If requirements are linking needs to solutions, and are consequently connected to needs and solutions, there are also linked to the projects that are dealing with them (gathering, elicitation, analysis, negotiation). It is important to clearly identify the requirements and the deliverables that are in the boundary of the projects, and those that are outside, in order to have a well-focused project. The fact that a requirement is in the boundary of the project does not mean that the source is within the project. But it is up to the project to make selection of the requirements that they will endorse. The source (project, project member, stakeholder identified by the project) of requirements is to be traced, as the reason why a requirement is or not endorse by the project.

The process of negotiation of the requirements (and prioritisation) is to be clearly stated, according structure and nature of the different projects, and tracked.

Page 79: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 75 / 92

Appendix B. Requirements Management Technology Overview

The following is an excerpt from a report dated 24-June-1994, titled: Analysis of Automated Requirements Management Capabilities developed in support of Advanced System Engineering Automation (ASEA) CSC-2.7 Requirements/Design Manager (Contract No. F30602-93-C-0123) Prepared for Rome Laboratory, Air Force Materiel Command C3CB 525 Brooks Rd. Griffiss AFB, NY 13441 by Software Productivity Solutions, Inc. 122 4th Ave. Indalantic, FL 32903.

B.1 The Need for Requirements Management The development of large, complex systems presents many challenges to system engineers.

Foremost among these are the ability to ensure that final system satisfies the needs of the users and provide for easy maintenance and enhancement of these systems during their deployed lifetime These systems often change and evolve throughout their life cycle, make it difficult to tract the implemented system against original and evolving user requirements.

Requirements establish an understanding of the user's needs, and also provide the final yardstick against which implementation success is measured. Requirements management consists of information capture, information storage, and management, and information dissemination. Information management is at the heart of the requirements management problem and includes organization, traceability, analysis and visualization. Key to the success of any requirements management process is requirements traceability. Requirements traceability is a technique used to provide relationships between requirements, design and implementation of a system in order to manage the effect of change and ensure the success of the delivered systems. A recent survey of INCOSE members identified improved support for requirements traceability as the most critical need to be addressed by automated systems engineers tools. For requirement traceability to be effective, it is necessary to associate requirements with information stored in a variety of system engineering tools.

B.2 Evolution of Automated Requirements Management Tools As recently as two decades ago, system engineers used tools such as pencil and paper to keep

track of the requirements and system design of many complex systems. These elementary tools were relied upon to design and develop complex communication, transportation, space, military and medical systems. Although these tools were the best available at the time, managing the hundreds of complex requirements and design decisions during system engineering consumed much of the systems engineer's time, leaving little opportunity to explore alternatives or perform analyses. During the 1980's, system engineers used word processors, spreadsheets, databases and graphics packages as their tools for designing and developing complex systems. These tools provide a vast improvement over their predecessors, but still paced limitations on system engineers. Until very recently, it was not possible to transfer data from one tool to another, or from on system engineering environment to another. The tools did no support the ability to view requirements information at any level abstraction. Most were design to support a signal user, and were no readily transitioned to support the large, teamed system development environment common in many organizations.

Today, several specialized automated system-engineering tools are available. These tools have been made possible by improvements in computer technology including grater storage capacity and faster processing speeds. With these improvements, computer technology is now able to support the complex processes necessary for automation of system engineering. Along with the technology improvements, system engineering as a discipline has matured and become a definable process. Among the emerging automated tools are specialized requirements management tools. These tools concentrate on capturing requirements, managing, and producing requirement specifications. However, even these specialized tools have limitations. It is still difficult to relate the information stored within one tool to information stored in another. Many of the tools have automated an existing, document driven system engineering process, rather than improving the process to support alternative abstraction and visualization mechanisms.

Page 80: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 76 / 92

B.3 Characteristics of Requirements Management Tools The automated tools available today focus primarily on the information management aspect of

requirements management of requirements management, namely traceability and organization (with a few emerging exceptions). The tools vary in their level of support for these activities. Most of the tools provide a text-oriented view of requirements management (such as DOORS, RTM, Document Director and others). A few of the tools take a model-oriented view of requirements management (these include CORE and RDD-100). Another emerging approach is to capture the design (rather than documents describing the design or models describing the functions) from all of its different perspectives and flow down requirements through the various implementation alternatives (making documentation a by-product of the design capture--SLATE is an example of this approach).

The term traceability is used to denote a relationship between a requirement and any other element of the system engineering process such as a design component or specification document. Many of the tools support traceability links between requirements and design elements, allocation of requirements to design elements and traceability between specification documents.

Organizational capabilities of the tools include grouping of functional requirements and assignment of keywords and attributes to requirements and links to facilitate searching for sets of requirements.

Other characteristics available in requirements management tools include generation of customized reports and interfaces with other system engineering and software engineering tools. Many of the tools also provide a graphical, multi-windowed user interface.

B.4 Traceability as part of Requirements Management There are many definitions of traceability. Traceability has become a key driver for defining and

developing government sponsored software. Traceability provides a relation between requirements, design and final implementation of a system. Traceability supports maintenance and provides the ability to discover the history of every system feature.

There are many relationships that exist between requirements, design; components and other products and processes of system engineering process. Managing these relationships is critical to providing a comprehensive requirements management capability supporting the system engineering life cycle. Traceability is the term commonly used to refer to the collective set of requirements based relationships.

If traceability (i.e. the complete set of requirements relationships) has been consistently used throughout system development, it may be used to answer the following questions: • What is the impact of changing a requirement? • Where is a requirement implemented? • Are all requirements allocated? • What mission need is addressed by a requirement? • Why is this requirement here? • Is this requirement necessary? • What design decisions affect the implementation of a requirement? • Why is the design implemented this way and what were the other alternatives? • Is the implementation compliant with the requirements? • What acceptance test will be used to verify a requirement? • Is this design element necessary? • How do I interpret this requirement? • Are we done?

Page 81: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 77 / 92

Appendix C. Patterns for interoperability of Heterogeneous Enterprise Networks and their Applications

C.1 Introduction Interoperability of enterprise application and software in a networked organisation is a complex

topic, for which gathering, elicitation, analysis and management of requirements are difficult. All along the discussions between the ATHENA partners, a way to express generically

interoperability issues emerged. The idea of this section is to reflect and to structure this way through development and management of shared Representation (or communication) patterns, as tools for a better communication between the different actors and stakeholders of the ATHENA program.

Interoperability “Representation” patterns are “Bipolarity of an application”, “Projection on conceptual axis”, “References for organisation internal cooperation”, “References for cooperation between organisations”, “Networked organisations”, “Interoperability supported at all layers of the applications”, “Product centric/Process centric views”, “Software product against applicative system project viewpoint”, “Software product / applicative system integrative view” and “Enterprise information system us single application”

They formalize important aspects of interoperability problems, taking into account different viewpoints.

They were used to support discussion during principle elaboration and discussion, within B4 and with the other ATHENA projects.

C.2 Motivation of the approach This section provides general patterns for Interoperability of Heterogeneous Enterprise Networks

and their Applications that are useful when defining and discussing the requirements, especially to identify and distinguish the different actors and stakeholders of interoperability, and to identify and classify the different users and stakeholders of advanced ATHENA interoperability technologies.

Aim of this section is, starting from the ATHENA driving vision: “plug and do business”, to analyse what kind of requirements it implies between different concerned actors and stakeholders, outside of the ATHENA, that will be the targets of ATHENA program and the future users of ATHENA results coming from the different projects. Some of them are represented within ATHENA, for example industrial users from automotive, aerospace, furniture or telecom by respectively Centro Ricerche FIAT (CRF), EADS CCR, AIDIMA or INTRACOM. Some will be invited to contribute through the future European Interoperability Centre (EIC).

One motivation is to go through the fact that most of the time the different categories of actors and stakeholders are not identified with a sufficient level of details, making it difficult to make a socio-economic analysis of the interoperability needs and solutions. Such an analysis is required if ATHENA want to have an impact, by providing technical and scientific solution that will be adopt by the enterprises. But what is more important for B4: • it is required to help analysis and decision phases of the requirement processes. • it is needed to explain to external actors (as the European Commission, future European

Interoperability Centre members, European industry, etc) how ATHENA works, what are the problems addressed, what are the provided solutions, and to whom. As requirement is the link between solution and problems, this section is fully appropriate in Dynamic Requirements Principle.

From business point of view, it is also important, when classifying the different types of problems and solutions, to take into account different kinds of enterprises: • the Small and Medium Enterprises (SMEs) that are a particularly important target for ATHENA, • the huge enterprises wanting to be able to work quickly with numerous Small and Medium

Enterprises (SMEs) on a well defined, open and agile infrastructure, allowing to reduce the cost of integration when establishing the cooperation.

• Solutions and services providers.

Page 82: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 78 / 92

C.3 The approach Let’s consider it like “Communication” or “Representation” patterns, that will may be become, after

finding solutions, basis for real “Interoperability of Enterprise applications and software” patterns. The approach chosen to reach the aims of this section is to provide some representation patterns

for interoperability of enterprise application and software. Combined, these patterns aim to ensure that ATHENA cover all the spectrum of problem. One

future potential usage is to be used and completed within A4 project, by solution patterns. Finally, they are a way to provide industrial viewpoints on general problem concerning

interoperability, and to discuss (patterns language) some pertinent directions to create synergy between ontology, Enterprise modelling, Knowledge engineering and Information and Communication Technologies (ICT) domains, that can be applied at enterprise level and in order to fulfil identified high level objectives of the industrial enterprises.

For example, interoperability of enterprise application is not directly a target for AIRBUS, it is just a mean to support aeronautic objectives and organisations that are being deployed to reach them: concurrent engineering based on virtual product to reduce time to market, virtual organisation to find the best partners to provide the better product at the lowest price, etc. To deploy a solution or to use an approach provided by ATHENA will be of interest only if it is possible to measure necessary investments and impact on current organisations, and to have an idea on benefits that it will bring to these companies.

This way to proceed was used by the FP5 IDEAS roadmap project, and more precisely in [NFI200310_1] and a practical use was done in [NFI200310_2]. This approach is consolidated by usage of several ideas extracted from presentations found in [KO200306], that were made during IFIP Technical Committee (TC)5/WG5.12 International Conference on Enterprise Integration and Modelling Technology (ICEIMT’02) in April 2002,at Valencia, Spain. Finally a strong usage is made from [BUS1996], reusing definitions patterns and systems of patterns, and referring some patterns that are of direct interest in the context of ATHENA B4 in particular and of ATHENA in general.

C.4 Using patterns

What patterns are When experts work on a particular problem, it is unusual for them to tackle it by inventing new

solutions that are completely distinct from some that already exist. A similar problem already solved is often recall, and the essence of its solution is reused to solve the new problem. This kind of ‘expert behaviour’, the thinking in problem-solution pairs, is common to many different domains. The pattern approach is to regroup such pairs into family problems and solution with each family exhibiting a pattern in both the problem and the solution.

Historically, Christopher Alexander wrote a number of books in the 1970’s, concerning civil engineering and architecture. Software community, on the basis of his work, adopted the idea of patterns. Patterns were popularised by the book “Design patterns: elements of reusable Object-Oriented Software” by Eric Gamma, Richard Helm, Ralph Jonhson, and John Vlissides.

The patterns in this book were not created by the authors, but collected and documented. A pattern is about communicating problem and solution, and enables to document a known

recurrent problem. It is a tangible manifestation of an organization’s tribal memory. It provides a common solution to a common problem and so on, within the culture of one specific organization or within one domain, naming and then specifying a pattern represents the codification of a common solution, drawn from proven, prior experiences.

Having a good language of patterns at your disposal is disposal is like having an extended team of experts sitting at your side: by applying one of their patterns, you in effect take the benefit of their hard-won knowledge”.

For software engineering, a pattern addresses a recurring design problem that arises in specific design situations, and presents a solution to it [BUS1996].

Page 83: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 79 / 92

“Representation patterns” for ATHENA When dealing with interoperability of enterprise application in a networked organisation, a similar

approach can be used, especially because we are considering complex systems of systems, and because even the way expression of needs and problems are not so obvious to be shared by different communities with different backgrounds and viewpoints (enterprise, software engineers, given domain experts, etc).

As the encountered problems concerning interoperability are sometimes similar between different industries, the idea is to use ‘representation” patterns, i.e. general and shared way to represent problems, that will shared as patterns of reference to refer to the problem space of ATHENA. They will provide a common vocabulary and understanding for interoperability problems. This notion is defined in IDEAS as following:

“The models presented here are not precisely patterns but simplified representations allowing identifying a simple and understandable way problems, needs, actors and stakeholders in relation with interoperability of enterprise applications and software.

They were useful during the exchange between the specialists of the different implied domains during the IDEAS project, and the fact to collect and to document them is very helpful to achieve clear understanding for an heterogeneous community that was not initially involved on IDEAS discussion.”

These ‘presentation’ patterns will be refined. They may evolve in order to become more standard patterns for interoperability, if such an approach is adopted by A4.

Structure of patterns A pattern is usually described using three part schema containing:

• The context: a situation giving rise to a problem, that can be general or specific • The problem: the recurring problem arising in that context, that begins with a general problem

specification, concerning its very essence and what is the concrete issue we must solve. This is completed by a set of forces, i.e. any aspect of the problem that should be considered solving it, including requirements the solution must fulfil, constraints that we must consider, desirable properties of the solution.

• The solution: a proven resolution of the problem. ATHENA B4 will

• reuse the IDEAS presentation patterns concept, • adapt it to the ATHENA context, • extend the set of provided patterns, • provide them as an input to links general problems to general solution families provided by

ATHENA, and more precisely by Action Line A. Potential contribution of presentation patterns to B4 objectives The objective of B4 is to extract, from given business cases provided by an industrial partners, the

maximum set of business patterns that are context independent and to restrict to the minimum the number of patterns that are context specific, in order to have a set of solutions that can be applied to the maximum number of business cases.

The idea is also to provide methodological approach to address context specific interoperability problems; taking into consideration that interoperability of enterprise applications is always specific.

If B4 will not deal directly with problems of domains involved to solve the interoperability issues (ontology, KM, EM, Information and Communication Technologies or ICT,…), they will have to reflect technological and business constraints from each specific business context, that will have to be taken into consideration for elaboration of new and innovative solutions.

Some of the issues to solve will be more at scientific and technological level (by expert of domains), and will be directly issued and managed within the solution space (Action Line -A projects, for example interchange of enterprise models independently of the tools used to build it, synergy between the domains, etc.). Usual architectural patterns used by software and Information System architecture, may both be reused through adaptation to enterprise system and collaborative systems (organisations), and in order to analyse problems with current architectures of products.

Page 84: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 80 / 92

C.4.1 Management of patterns In order to be easily reused, there are named and numbered, and a status associated to the

definition and adoption process is defined. A versioning mechanism is also proposed. The following table provides the list of patterns with number and name.

Number

(Type+indice)

Version Status Pattern name

RP1 1.0 A Bipolarity of an application RP2 1.0 A Projection on conceptual axis RP3 1.0 A References for organisation internal cooperation RP4 1.0 A References for cooperation between organisations RP5 1.0 A Networked organisations RP6 1.0 A Interoperability supported at all layers of the applicationsRP7 1.0 A Product centric/Process centric views RP8 1.0 A Software product against applicative system project

viewpoint RP9 1.0 A Software product / applicative system integrative view

RP10 1.0 A Enterprise information system us single application (impact on typology of projects and interoperability issues and requirements process)

Status: A(dopted), P(roposed), U(nder construction), D(eprecated)

• Adopted means that partners of B4 and ATHENA considers that the pattern is relevant and used as a reference as communication tool.

• Proposed means that the pattern is proposed, and is waiting for the adoption. • Under construction means that the pattern is not finished and not ready to be proposed for

adoption • Deprecated means that the pattern is no used: or it was decided that the pattern at status P will

never be Adopted, or it was adopted, and after a certain time, it appears that it is not useful and it will no more be used

Type: R(epresentation) P(attern) • Representation patterns are B4 specific and represent general families of problems (generic

interoperability issues)

Page 85: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 81 / 92

C.4.2 Representation patterns This part reuses (RP1 to RP6) and completes IDEAS representation patterns, from discussion and

exchanges within B4, and between B4 and other ATHENA projects.

C.4.2.1 Pattern 1: bipolarity of an application

Figure 28 The two Worlds of an Enterprise Application

An application can be considered as part of two different systems. The real world where it is used and the Information Technologies (IT) environment.

This model is adequate addressing interoperability of enterprise applications and software because it highlights that two different viewpoints can be considered concerning an application: • the organisation that do consider the application like a resource and like an actor (application

performs some task for the enterprise, that can be done by persons) • the Information Technologies (IT) department that support the process the application participates

in. Here the enterprise models are those describing processes of the organisation (like quality

procedures, reporting,…) and are not necessarily used in an application. They even can not be formalised.

Interoperability is to be addressed at the organisation level first and then to be supported by Information Technologies (IT) Department. Interoperability quality of hardware/software products, as existing infrastructure and communication protocols, will at their turn support Information Technologies (IT) departments and organizations.

The concerned actors are organization, Information Technologies (IT) department, business process actors that are interacting with the application.

Page 86: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 82 / 92

C.4.2.2 Pattern 2: Projection on conceptual axis

Figure 29 Projection on Conceptual Axis

This pattern illustrates how various engineering activities linked to Enterprise Application development are connected and that for each, at different conceptual levels, the tools used (modelling language, models of reference) have some equivalence.

It can be extended to other linked engineering activities or paradigm (like knowledge management, urbanism of enterprise information systems- city planning applied to information systems…).

This model is appropriate addressing interoperability of enterprise applications and software because it allows identifying and classifying different elements of the information systems that contribute: • to creation and operational usage of an application in one hand, • to cooperation or integration of application in the other hand.

By using notions of horizon and period, it highlights that it is important to take into account time factor for the evolution of the different components of the enterprise applications, as enterprise applications infrastructures, when we want to address interoperability and maintain it in an operational state.

It also highlights potential roles of many different actors, as roles of ontology or enterprise modelling that can help to pilot Enterprise Application Systems evolution in the context of the enterprise.

Page 87: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 83 / 92

C.4.2.3 Pattern 3: References for organisation internal cooperation

Figure 30 Enterprise Information System Inside enterprise

This pattern aims to illustrate differences between the user level, where user have a definite role in the organisation, the application level connected to the processes of the enterprise , and the information level were databases contains information of reference, but also all the enterprise meta models of reference.

The situation is similar within all the organisations. To allow cooperation and then interoperability, a prerequisite is that the organisation do have roles of reference, process of reference and information and meta models of reference in order to allow a real interoperability between enterprise application (as define in the glossary – definition proposed by EADS CCR).

Page 88: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 84 / 92

C.4.2.4 Pattern 4: References for cooperation between organisations

Figure 31 Inter Enterprise Common Reference Models

This model illustrates and formalise that in order to cooperate efficiently, two enterprise need to share some models of reference. As for computing system, it can be manage point to point, and consequently imply a lot of work.

The reference models can also be shared by a group of organisation, but leaded by only one that is the “master”. It is the case for example for Integrators in industry (automotive, aeronautic).

When equal power of different organisations, we can imagine than a network, where the model of reference are manage collectively. We have then a kind of standard for the group.

In order to save time and resources, usage of standards (e.g. ISO STEP for product modelling, Unified Enterprise Modelling Language (UEML) for enterprise modelling, The Open Group Architecture Framework (TOGAF) for knowledge management, etc) is pertinent.

C.4.2.5 Pattern 5: Networked organisations The idea of a networked organization is to consider that each organisation is equivalent, and to

develop an infrastructure to allow a quicker integration of new members, and to manage common services for interoperability (at business and Information Technologies level) in order to enhance the network capacities.

It responds to the problem of resource and skill scarcity. What could be a networked enterprise? The following picture provides an example about how we

can imagine it. Numerous new kind of services and activities can be imagine for networked organisation. It implies emerging actors (technological and economical) and new roles in the integration process. In all case, interoperability of enterprise application and software is a prerequisite, as security and performance.

Page 89: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 85 / 92

Figure 32 What a Networked Enterprise could be

Emergence of networked enterprises is one of the trends that contribute to IDEAS vision. It’s important to point that such a network can be applied to different kind of organisations, inside

or outside enterprises.

C.4.2.6 Pattern 6: Interoperability supported at all layers of the applications The aim of this pattern is to illustrate the links between interoperability and the different layers of

enterprise applications, as the role of ontology.

Figure 33 Interoperability Supported at all the Layers of an Application

The communication between two organisations (could be enterprises) applications required to address all the layers of the application: Information and Communication Technologies (ICT) systems (required interoperability of software and hardware components), knowledge and business layers (required interoperability at organisation and discipline level, that is addressed by enterprise modelling). Between layers and organisations, it is absolutely required to use shared semantics to ensure interoperability. Role of Ontology domain is to help to provide such shared semantics, with associated methodologies, tools and services.

Issued from IDEAS, this pattern is also one of the foundations of ATHENA. It implements the layer architecture pattern (AP1) and can consequently take advantage of the

study of this pattern: context, advantages, and drawbacks.

Page 90: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 86 / 92

It is not fully adapted to needs of enterprises for networked organisation or virtual enterprise encompassing many companies (two many mapping to do, especially difficult if software product implement reflection architectural pattern or blackboard architectural pattern. Such partners are those used for agile solutions addressing generic needs.

C.4.2.7 Pattern 7: Product centric/Process centric views The representation of scenarios should reflect the ATHENA Framework: Business-Knowledge-

Information and Communication Technologies (ICT) Systems-Semantics Moreover, the same scenario could be viewed from two different perspectives:

• Product-centric: the core function is the accessibility by different classes of users to repositories of data, models, metadata, meta-models. Depending on the final purpose of such an access we can have sharing/exchanging of data-models, Information Technologies (IT) automatic - Information Technologies (IT) mediated - manual access, workplace generation. Access could be either an activity inside a business process, or a task inside a project, or an extemporary ad-hoc initiative. Semantic reconciliation of data and models is often needed.

• Process-centric: the core function is the implementation of business processes by means of inter-related activities (manual, Information and Communication Technologies (ICT) interactive, Information and Communication Technologies (ICT) automatic). Data exchange-sharing as well as resources (business-knowledge) employment are the key points. Semantic interoperability of processes and applications is often needed as well as data-resources reconciliation.

A Product-centric view of the Scenarios is based upon Data and Models (business-knowledge-applications-data) related to Extended Product life cycle and upon how to make models executable, accessible, condivisible, usable by Working Teams and Knowledge Workers.

The Interoperability problem is mostly (not uniquely) related to: • Content: heterogeneity, dynamics, multi-disciplinarity, multi-dimensionality, multi-language,

semantic discrepancies, privacy, confidentiality, security. • Users: different positions and roles, different competencies and cultural background, Graphical

User Interface (GUI) customisation, user profiling and preferences • Usage: sharing & access, co-operative work (co-design, co-development), knowledge exchange,

navigation & browsing, search & retrieval, monitor & control, change & consistency maintenance The core Pilots for such an approach should be collaborative Product Development and Product

Portfolio Mgmt.

USERSUSERS USAGEUSAGE CONTENTCONTENT

ICT Systems Data & Models

PSM

PIM

UML

MDA

STEP

Knowledge Data & Models

AKM

ONT

SKILLS

OBS

BusinessData & Models

UEML

Decision

BPMI

Knowledge Access & Sharing

Workspace Generation

Project Management

Co-operative Design & Develop

Top Management

Middle Management

Knowledge Workers

Figure 34 Product Centric View of the Scenario

A Process-centric view of the Scenarios is based upon Business Processes integrated with Enterprise Applications and Software and upon how to make them open, inter-connected, synchronized, integrated with those running at the suppliers', customers' and partners' premises.

Page 91: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 87 / 92

The Interoperability problem for them is mostly (not uniquely) related to: • Applications: Enterprise Application Integration (EAI) by software components, heterogeneity in

architectures (web-grid-agent-p2p), hardware platforms, operating systems, deployment languages. Transient services, dynamic on-the-fly assignment-composition

• Data: meta-frameworks for product, process, e-commerce data exchange and semantic reconciliation of concepts

• Resources: a wide variety of resources involved, from physical to human to Information and Communication Technologies (ICT) to knowledge. Need to support collaboration among them

The core Pilots for such an approach should be Supply Chain Management; e-Procurement.

Business

Knowledge

ICT Systems

Sem

antic

s

Enterprise A

Business

Knowledge

ICT Systems

Sem

antic

s

Enterprise A

Business

Knowledge

ICT Systems

Semantics

Enterprise B

Business

Knowledge

ICT Systems

Semantics

Enterprise B

Cross-Organisation BPCross-Organisation BP Figure 35 Cross-organisation BP

More than focussing on product data, such approach are more focussing on activity that is represented the following way (IDEF like):

Inputs Outputs

Business

Knowledge

ServiceInputs Outputs

Business

Knowledge

Service

Figure 36 Process Description an IDEF0-like Way

Family of applications that can be addressed are: • Teamwork TW (HR, assignment, scheduling) • Collaborative TW (TW + Collaboration Primitives in Actuation) • Office work OW (HR positions, individuals in OR) • Collaborative OW (OW + Collaboration Primitives in Actuation) • Manufacturing (primary/secondary Resources, assign, sched, OPS)

Page 92: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 88 / 92

• Automatic (Information and Communication Technologies (ICT) Application, assign-schedule runtime)

• Interactive TW (1 HR + Information and Communication Technologies (ICT) Application, HR assignment-scheduling)

• Interactive OW (1 ROLE + Information and Communication Technologies (ICT) Application, no assign-sched)

For a process centric approach, every Output of Activity x which enters (I or K or B) an Activity y represents a potential Interoperability problem, either intra- or inter-enterprise. It could be at Business/Knowledge/Sharing level.

Inputs Outputs

Business

Knowledge

ServiceInputs Outputs

Business

Knowledge

ServiceInputs Outputs

Business

Knowledge

ServiceInputs Outputs

Business

Knowledge

Service

Figure 37 Interoperability for a Process Centric Approach

Referring ISO 14258: • an Integrated Interoperability solution imposes the same K-B-S framework at semantic level. If

supported by both Enterprises then I/op is solved. If not, Enterprise should be re-organised to support it.

• A Unified Interoperability solution foresees the presence of a meta-framework and of proper mapping tools. They should be inserted in the Business Process in order to implement it.

• A Federated Interoperability solution will solve Interoperability problems on-the-fly at runtime, thanks to intelligent agents, negotiation and self-adapting architectures.

Suggestions for pilots from A4 for pilots: • Select a significant subset of the whole processes • Try to represent it in product-centric (content, usage, users -> use diagrams) and in process-

centric (activity, flows, business-knowledge resources) mode • Put the red lightning when I/op problems could arise • Content-Content, Content-Usage, Users-Usage, .... • Service-Service, Business-Business, Knowledge-Knowledge • Describe the I/op scenarios in AS-IS and TO-BE terms

AS-IS: current problems and recovery actions TO-BE: envisaged ideal situation and identification of the Interoperability modality suggested Note:It must be pointed out that these definitions are not exactly those of B4, as B4 considered

that there are different phases of negotiation and validation before to launch a pilot. But it is very closed. I/op modality suggested are those coming from A projects, and linked to innovative ideas of solutions that Action Line (AL) A project expect to develop and that will be used for the pilots. Danger of “Ideal” scenario is that we have not idea for now about idea of solutions that will be developed by Action Line (AL) A projects. We have also no idea about feasibility or what is already existing. Finally the ideal scenarios provided by each industrial partners have to be reviewed in order to know if it is within the scope of ATHENA (relation to ATHENA objectives), addressed by Action Line (AL) A projects (cross project team per profile is targeted in order to ensure that), with a clear idea of the feasibility (resources available or not) in the scope of B5, with in particular internal call if some are missing and required new partners.

Page 93: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 89 / 92

C.4.2.8 Pattern 8: software product against applicative system project viewpoint The aim of this pattern is to differentiate viewpoints of B4 in one hand, the space of problems, and

the viewpoints of technology and solutions providers in the other hand, the space of the solutions. More than making the distinction between people than express the problem and those who are

solving it, the idea is to put the focus on the distinction between different kind of projects when the project owner is the “industrial enterprise”, or when the project owner is a software product vendor.

In the first situation, the deliverable of the project will be an application, and the requirements are elicited, analysed and formalized by the industrial enterprise. Then a solution (functional) is design, and before to start the development phase, a decision must be taken concerning to run a new development or to use an already existing product of the market. It can be done by internal analysis or through a call for tender. One a software product selected, it is then necessary to launch a customisation and deployment phase that can be done directly by the “industrial” enterprise or by a service provider (that can also be the software vendor or distributor, or a third party). In this case, a project is launch as for deliverable an application, and the requirements are concerning the application. Some requirements are reused to make the selection and evaluation of existing product, but these requirements are not directly used by the software product designers and developers. The development of the application is driven by a given “industrial” enterprise for a given very precise and unique context.

In the second situation, an Information and Communication Technologies (ICT) company is willing to develop a new product, and according identification of a market and after elaboration of a business plan, is launching a project to develop a new software product. In this case, the owner of the project is the marketing department, not the future buyers of the software product. The development of the software product is leaded by market opportunity.

Business Space of problems

Operational applications

Space of solutions

Software products

Methodologies

Research

Call for tender

Customisation Market study

Specific Solution For generic problem

Project owner= the enterprise

Deliverable = application

Project owner= the provider

Deliverable = software product

Figure 38 Software Product Against Applicative System

The fact to buy Commercial product Of the Shelves, if it lead to potential saving for the buyer, is also the origin of some interoperability problems. Software product providers aims to address the wider market, and consequently to propose a (specific) solution that address generic problems, in order to be able to sell the same product to other companies with similar needs. To reach this objective, the delivered software are most often design using reflection architectural pattern, that allow to customise the application without coding. It also provides agile application, as changes of the environment of the applications and of functional expectation may be done just by changing the customisation. One drawback, when the solution is too much generic, is that the two applicative systems based on the same product are most of the time very different, and when establishing collaboration, it becomes difficult and complex to make the two applications easily interoperate.

As in such a process there is two projects with different owners, and different set of requirements and different set of (sometimes contradictory) interests, wanting to address interoperability of application should imply both projects (and stakeholders families – software vendor and buyers) to use a common infrastructure for interoperability, addressing all the interoperability issues from requirements phase to operation phase, to be able to obtain, at the end, effective interoperations between systems at the lower cost, despite the changes.

It is what Industrial partners are expecting from ATHENA and the future European Interoperability

Page 94: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 90 / 92

Centre (EIC).

Business Space of problems

Operational applications

Space of solutions

Software products

Methodologies

Research

Call for te

nder

Customisa

tion Market study

Specific Solution

For generic problem

Project owner= the enterprise

Deliverable = application

Project owner= the provider

Deliverable = software product

EIC

Interoperability?

Figure 39 AIF supporting both Applicative Systems and Software Product

C.4.2.9 Pattern 9: software product / applicative system integrative view The aims of this pattern are:

1. To identify different items concerned by interoperability issues, their relationship (composition and time dependencies)

2. To point out disconnection of life cycles of each of these items 3. To be a tool helping for identification of the different actors and stakeholders of interoperability, all

along the life cycle of the different items

Development environment

SoftwareProduct

SoftwareComponentsSoftware

ComponentsSoftwareComponentsSoftware

ComponentsSoftwareComponents

SoftwareComponentsSoftware

ComponentsSoftwareComponentsSoftware

ComponentsSoftwareComponents

Applications

Business ProcessBusiness Process

Is actor of

Is used to implement(development/customisation)

Integrates

Network (hardware)Network (software)

Network (B2B) => WEB servicesEnterprise operational network

Operational environment

Support Processes

Figure 40 Software Product - Applicative Systems Relationships

Page 95: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 91 / 92

When collaboration between two or more enterprises (or organisation), we retrieve the same thing two times or even three times if a cooperative infrastructure that is outside the two companies (networked enterprise).

Applications

Business Process

Is actor of

Network (hardware)Network (software)Network (business) => WEB services…Enterprise operational network

Operational environment

ENTERPRISE B

Support ProcessesApplications

Business Process

Is actor of

Network (hardware)Network (software)Network (business) => WEB services…Enterprise operational network

Operational environment

ENTERPRISE A

Support Processes

Network (software)Network (business) => WEB services…Enterprise operational network

Cooperation Process

Cooperation InfrastructureCooperation services

Figure 41 Software Products - Applicative Systems Relationships in a B2B context

C.4.2.10 Pattern 10: Enterprise information system us single application The aim of this pattern is to formalise difference of viewpoint when considering enterprise

information system or a single application, and impact on project typology and interoperability issues and requirements process.

Within an enterprise or organisation, most of the time several enterprise applications exist, for different purpose (disciplines), activities, group of end-users. They are most of the time owned by subpart of the enterprise/organisation, used or operated by an another subpart of the enterprise/organisation, administrated from a business point of view by an another subpart of the enterprise/organisation, and supported from Information and Communication Technologies (ICT) point of view by an another subpart of the enterprise/organisation (usually Information Technologies (IT) department, that provides different kind of services). For huge organisations, the number of such application is very high.

To respond to cooperation/interchange always changing needs, various interfaces based on numerous approach (file interchange, batch, middleware, transactional monitors, etc) were developed in order to connect heterogeneous applications using. It led to what the Gartner group call the “spagetthi model”. It is more and more difficult to make any change one application as it is near impossible to measure the impact on other applications and to measure the risk on operational and critical processes.

As a current trend is to enhance collaboration within the enterprise (integrated enterprise) and between enterprises (virtual enterprise, extended enterprise, networked enterprise), it is more and more important to rationalise the Enterprise Information System, in order Enterprise Information System supporting efficiently new needs for communication and collaboration.

One another issue is to reduce budget of maintenance of the Enterprise Information System, knowing that about 80% percent of the budget of Information Technologies (IT) department is about maintaining the legacy, and not to create new applications to cover the new needs.

In such a context, different viewpoint exist when dealing with interoperability within an enterprise: 1. Viewpoint of one single new application, with dedicated project 2. Viewpoint of interconnection between two existing applications, with dedicated projects 3. Viewpoint of the whole enterprise information system, with different type of dedicated projects:

Page 96: Deliverable DB4.1 Dynamic Requirements Definition ... provided t… · elicitation, analysis, negotiation, modelling, management and traceability, instrument it in the Dynamic Requirements

IP- Project ATHENA IP- Project - No 507849 ATHENA - Project Dynamic Requirements Definition ATHENA - Project Number B4

Document Deliverable DB4.1 Date 29.09.04

040927_ATHENA_DB41_V1.doc CONFIDENTIAL Page 92 / 92

• Enterprise Application Integration (EAI) projects: they are launched most of the time by Information Technologies (IT) department in order to reduce the cost of the maintenance and evolution of legacy enterprise information system

• Urbanism projects: they are launched at the enterprise level, taking into account all the stakeholders of the enterprise, in order to pilot the evolution of the information system from enterprise objectives and business processes, and by putting in place an “urbanism team” that:

o Elaborate and maintain cartography of objectives, business process, information system (functional, applicative, technical) in order to pilot evolution of the whole enterprise information system

o Elaborate “urbanism rules” that each application have to follow in order each new application being integrated in the whole strategy for the enterprise information system. It provides before the launching of the project of application development, the interface between the boundary of the application and its environment, and also some constraint in order to have an harmonised set of applications within the enterprise

When addressing collaboration between several enterprises, similar set of viewpoints exist, knowing that in this case two organisations are implied, and that we are then in the area of Business to Business (B2B) or Business to Cutomer (B2C) (can be extended to other kind of organisations). Viewpoint of one single new application, with dedicated project with as owner the two concerned

organisations, and elaboration of distributed a distributed application from scratch. Viewpoint of interconnection between two existing applications (legacy systems), with dedicated

projects to establish collaboration between these applications. Viewpoint of the whole enterprise information system, with different type of dedicated projects: • Business to Business (B2B) projects: they are driven most of the time by Information

Technologies (IT) department in order to support effective and secure cooperation with the outside. When own by Information Technologies (IT) department, they provide infrastructures to support and integration with the Enterprise information system (back office).

• When launched and driven by a function of the enterprise, they have most of the time other names: Supply Chain Management, Product Life Cycle Management, Collaborative distributed development

• Network of enterprise: some industrial sectors are currently developing infrastructures for cooperation with establishment of common infrastructures and rules for cooperation. Roughly (reality is not so simple and the proposed classification can be discussed and discussed), they can be industry driven and owned (automotive network VBA), Information Technologies (IT) service providers driven (World Web Wide Consortium or W3C) or mixed consortium driven Object Management Group (OMG).

All those kind of projects, that are in the space of the problem, have to deal with interoperability issues. The actors and stakeholders are very different within the enterprise, according the fact a project deal with one application, two applications, the whole enterprise information system, and according the fact that one or several enterprises are involved (ownership, decisional, integration aspects).

Note: starting business scenarios from B4 can encompass any of these projects, as all of them have impact on interoperability issues: • Source of requirements on the infrastructure when the project is running • Constraint of the legacy (application, infrastructure, urbanism rules and constraints) when the project is

finished From EADS point of view, AIF and B5 have to reflect this diversity of approaches within the

enterprise. A special focus is to be putted on Small and Medium Enterprises (SMEs) that have not

necessarily the resources to launch all this kind of projects.


Recommended