B4.4 Guidelines & Template Proposal

Please Fill in the file properties and NOT in the Document:

Field: Title in the “file properties”: Project Title

Field: Keyword in the “file properties”: Project Number

Field: Subject in the “file properties”: Working Document Number

This text will not be printed – “it is hidden text”

Versioning and contribution history (according program template)

Project B4 Dynamic Requirement Definition

B4.1 Dynamic Requirement Definition Principles

Report Version: 2.1

Report Preparation Date: 23rd of July, 2004

Classification: PrivatePublicRestricted

Status : Version circulated to ATHENA – status under validation

Authors: EADS CCR

B4 internal history

A B4 internal process was followed as initially the deliverable process was not available.

A document associated to the deliverable provides inputs and comments tracking about the deliverable.

Table of contents

Versioning and contribution history (according program template)

1.Summary

2.Introduction

2.1Content of the deliverable......

2.2Important consideration for the reader......

2.3Table of Acronyms......

3.Definitions of the concepts

3.1Introduction......

3.2Definitions......

4.Requirements : multi-viewpoint analysis

4.1Executive summary

4.2Requirements engineering

4.2.1Requirement Determination

4.2.1.1Requirement elicitation

4.2.1.2Requirement Analysis

4.2.1.3Requirement Negotiation

4.2.1.4Requirement Validation

4.2.2Requirement modelling

4.2.3Requirement management

4.2.4Requirements and projects

5.General statements about Interoperability of Heterogeneous Enterprise Networks and their Applications

5.1Executive summary......

5.2Motivation of the section......

5.3The approach......

5.4General statement about patterns......

5.4.1Management of patterns

5.4.2Architectural pattern

5.4.3Representation patterns

6.ATHENA Program objectives and context

6.1Executive summary......

6.2ATHENA objectives......

6.3ATHENA program structure and organsiation......

6.3.1B4

7.Dynamic requirements principles

7.1Executive summary......

7.2Principles list......

7.2.1Short list

7.2.2The principles

7.3Analysis and impacts on ATHENA Program......

7.3.1Cross project general considerations

7.3.2Links and impact between this document and B4 activities

8.References

8.1Documents......

8.2Organizations......

9.Annex 1

9.1Requirements Management Technology Overview......

9.1.1The Need for Requirements Management

9.1.2Evolution of Automated Requirements Management Tools

9.1.3Characteristics of Requirements Management Tools

9.1.4Traceability as part of Requirements Management

Table of figures

Figure 1 : The two worlds of an enterprise Application

Figure 2 : projection on conceptual axis

Figure 3 : EIS Inside enterprise

Figure 4 : Inter Enterprise common references model

Figure 5: what a networked enterprise could be

Figure 6: Interoperability supported by all the layers of an application

Figure 7: Product centric view of the scenario

Figure 8 : Eliciting common user requirements

1.Summary

The “Dynamic Requirements Principle” deliverable is a reference document for the ATHENA B4 (Dynamic Requirement) project.

It provides a set of definitions that must be shared by the ATHENA partners in the context of ATHENA dynamic requirements project.

It provides precise definitionsabout requirement process from a requirement engineering point of view, but also from project management point of view. Requirements gathering, elicitation, modelling and management are described, as different associated methodologies and tools coming from different business activities as software engineering, system engineering or requirement engineering, that constitute basis for further activities of B4 if adapted to the program specificity.

It provides a set of core statements concerning Interoperability of Heterogeneous Enterprise Networks and their Applications that are important for definition of 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. This is particularly important to identify target groups for AIF and different results of the different projects. All these actors and stakeholders are potential sources of requirements. The set of core statements are formalized as “Interoperability templates”, and aims to be reused and enrich all along the project as communication and dissemination tools.

It provides description of elements from ATHENA Program objectives and context, that are to take into consideration for definition of general requirements principles, in particular links with ATHENA program management, IDEAS roadmap, AIF framework and targeted Interoperability Centre.

Finally, twentyDynamic requirements principles are defined on the basis of analysis provided by 3 previous sections, pointing out importance to define an appropriate requirement process and associated Dynamic Requirement Definition System, i.e. adapted to :

• interoperability of enterprise applications purpose, in an always changing business and technological context
• current trends for software product market (commercial of the shelve with wide market but important customisation, growing change rhythm implying agility of solutions, etc), and structure of actors and stakeholders (software providers, applications owners and maintainers, application integrators… )
• ATHENA program and projects structure, infrastructures (ACP, AIF), objectives and needs
• future targeted interoperability centre

These principles are the basis to build an efficient evolutionary or spiral requirement process, with associated system, and the way to improve it from what will be learnt all along the project .

2.Introduction

2.1Content of the deliverable

The aim of this document is to be a reference document for the B4 project, but also for the whole ATHENA program concerning the principle of dynamic requirements definition, both to structure the results but also the work to be done by the ATHENA members.

It is based on a B4 partners activity in a first stage, and on the validation of the other B activities and A projects partners in a second phase, especially to be compliant with ATHENA Interoperability Framework (AIF) coming from the A4 Projects. The complete process to elaborate this document involved support and contribution of the ATHENA coordination team (for coordination and decision support from a management point of view) and technological council (for technological and scientific validation).

The first section (Chapter 3) provides a set of definitions that must be shared by the ATHENA partners in the context of ATHENA dynamic requirements project. As used all along this document, it was made the first section of the document, but it should have been a part of the “Dynamic requirements principles” section as well.

The second section (Chapter 4) provides precise definitionsabout requirement process from a requirement engineering point of view, but also from project management point of view. It provides the description of what are requirements gathering, elicitation, modelling and management, and description of different methodologies and tools for different business activities.

The third section (Chapter 5) provides a set of core statements concerning Interoperability of Heterogeneous Enterprise Networks and their Applications that are important for definition of 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. This is particularly important to identify target groups for AIF and different results of the different projects. All these actors and stakeholders are potential sources of requirements.

The fourth section (Chapter 6) provides description of elements from ATHENA Program objectives and context, that are to take into consideration for definition of general requirements principles, in particular links with program management, IDEAS roadmap, AIF framework and targeted Interoperability Centre.

The fifth section (Chapter 7) defines the Dynamic requirements principles, based on the previous sections.

2.2Important consideration for the reader

It is important to consider that different sections of this document are a snapshot at a given time (M6) of the result of on-going activities :

• Definition, usage, evaluation and evolution of the glossary,
• Definition, usage and evaluation and evolution of the interoperability patterns,
• Definition, usage, evaluation and evolution of principles.

This deliverable provides these three features first version, mainly targeting clarification of B4 project context and future activities.

It is also important to point that these first version are frozen, and will be the reference for the next period (duration to be manage in order to be manageable).

This features may evolved all along the ATHENA duration. It means that some of the sections will be deprecated, based on feedback concerning their usage within or outside ATHENA. The new version of these sections will be made available on future ATHENA B4 deliverables.

At M6, when delivered , these features will be submitted to evaluation, with as main criteria of evaluation:

• usability,
• integration/coherency with AIF,
• and adequacy with ATHENA objectives.

Usability concerns ATHENA partners who have to achieve objective of each research project and activity separately and collectively, and who will use this features as an input for their activity. It will also concern, in a further phase, future targeted members of ATHENA interoperability centre.

Integration/coherency with AIF concerns the technical and scientific aspects of ATHENA projects. During AIF definition, it may occur that some principles may have to be refined or adapted, for usability purpose ( based on return on experience from the program activities). AIF will also probably evolved, and coherency with dynamic requirements principle will also require some adaptation and evolution of the principles.

Adequacy with ATHENA objectives was insured by basing the work on the objectives defined in the DoW. Nevertheless, the objectives may evolved all along the lifecycle of the ATHENA program, and have an impact on adequacy of some of the defined principles.

As a consequence, it means that the first version of this features (principles, glossary, templates) is probably not perfect, but sufficient in order to start efficiently the project on common basis. These first versions are also constrained by available resources, timeframe (necessity to start the next activities of the project). Future versions will be produced by B4 based on the return on experience of the usage, and made available on future deliverables of the B4 project.

2.3Table of Acronyms

3.Definitions of the concepts

3.1Introduction

This section provides a set of definitions that must be shared by the ATHENA partners in the context of ATHENA dynamic requirements definition It means that some other definition of the same terms may be provided in other contexts, including ATHENA contexts (for example a given A project or even a B4 specific deliverable context – for example an EADS business scenario may provide a glossary that is specific to this scenario). It must be considered that value of such a glossary is linked to the usage of the glossary, and especially to the “contract” that associate a community to this usage. It implied to precisely identify the community of users and stakeholders that are concerned in “ATHENA Dynamic Requirement Process” and to involve them in definition, refinement, acceptation and usage of this glossary through ATHENA program infrastructure and processes. Such principle was consequently applied to defined and refined this glossary all along the elaboration of this document, and that allowed, starting from general definition, to reach ATHENA purpose/context adapted definition.

These definition are useless without description of usage context (ATHENA program and projects), including involved actors, stakeholders, concerned processes and finally objectives of the ATHENA programs.

3.2Definitions

ACTIVITY (context=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 (context=ATHENA.B4): The system in which the ESAI (Enterprise Software Application Interoperability) will be analysed and defined [GRAISOFT]

BUSINESS PROCESS (context=ATHENA.B4, origine=[ISO 15704, 1999]) : “A partially ordered set of enterprise activities that can be executed to realise a given objective of an enterprise or a part of an enterprise to achieve some desired end-result.”

BUSINESS SCENARIO (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 scenario have no idea about what the solutions for interoperability are. Scenario may include results of some investigation or evaluation of solutions that were unsuccessful and related requirements concerning interoperability coming from the enterprise.

BUSINESS SCENARIO (context=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 reorganization.

BUSINESS SCENARIO PROCESSES (context= 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 (context=ATHENA.B4) : project of ATHENA focussing on the process dealing with interoperability requirements gathering, elicitation , analysis and management in the ATHENA B4 project context; as interoperability is a quality of a set of application systems at a given time, and as these systems and their context are evolving all along the time, it implies to consider an evolutionary process ensuring agility of interoperation when dealing with always accelerating change rhythm, being at business goals, business process, applications, software product or ICT technology levels. As the ATHENA provided solutions aim to address need of the widest community, the process includes in the analysis part extraction of interoperability issues targeting maximum reusability of these solutions for the largest community.

E-BUSINESS (context=ATHENA.B4, origin=[A European Initiative in Electronic Commerce, COM(97) 157 final, 16 April 1997]): “Doing business electronically in support of organizational goals” "Such as content management, supply chain integration, value chain integration, information standardization for electronic marketplaces." [IDEAS]

END USER (context=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.