deliverable b4.4 drds work package – b4 · ip- project / programme athena project - no 507849...

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 Requirement Definition ATHENA - Project No

B4

Deliverable B4.4

DRDS

Work package – B4.4 Leading Partner: Troux (Computas) / IPK

Security Classification: Populated KM base

March 2005

Version 1.0

IP- Project / Programme ATHENA Project - No 507849 ATHENA - Project Dynamic Requirement Definition Project Number B4 Document Deliverable DB4.4 Date 19.03.05

050319_ATHENA_DB44_DRDS_V10.doc CONFIDENTIAL Page ii / 29

Versioning and contribution history Version Description Author Date Comments

0.1 Initial Draft IPK 02/08/2004

0.2 First Contributions (WP Members) 03/03/2005

0.3 First Consolidation (Owner) 04/03/2005

0.4 Final Contributions (WP Members) 08/03/2005

0.5 Final Consolidation (Owner) 09/03/2005

0.6 Quality Check (Peers)

0.7 Final Editing Programme Office 21.03.2005

0.8 Final Approval PCC Not needed

1.0 Submission to EU Programme Committee

21.03.2005


050319_ATHENA_DB44_DRDS_V10.doc CONFIDENTIAL Page iii / 29

Table of contents

1 Summary.............................................................................................................................. 1

2 Introduction .......................................................................................................................... 2

3 ATHENA Requirements Engineering................................................................................... 3 3.1 Gathering Requirements .................................................................................................................... 3 3.2 Creating ATHENA Requirements....................................................................................................... 4 3.3 Classifying Requirements .................................................................................................................. 5

4 DRDS overview.................................................................................................................... 6 4.1 Web User Interface ............................................................................................................................ 6 4.2 Requirements Database .................................................................................................................... 7 4.3 Visual Model ...................................................................................................................................... 7 4.4 Requirements Reports ....................................................................................................................... 9 4.5 Extending the Requirements Model ................................................................................................... 9

5 User Guide for DRDS ........................................................................................................ 10 5.1 Finding DRDS inside ACP ............................................................................................................... 10 5.2 Viewing requirements in the Web UI ................................................................................................ 11 5.2.1 View all or one requirement......................................................................................................... 11 5.2.2 Search and filtering...................................................................................................................... 12 5.2.3 Searching and reporting by category or other ............................................................................. 12 5.3 Submitting a new requirement ......................................................................................................... 13 5.3.1 Entering basic information ........................................................................................................... 13 5.3.2 Entering additional information .................................................................................................... 13 5.3.3 Classifying the requirement ......................................................................................................... 14 5.3.4 Relating to other requirements .................................................................................................... 14 5.3.5 Submitting attachments ............................................................................................................... 14 5.4 Viewing the requirements model ...................................................................................................... 15 5.5 Using the requirements model ......................................................................................................... 15 5.6 Administrator functionality ................................................................................................................ 15 5.6.1 Specifying classifications............................................................................................................. 15 5.6.2 Triggering model import............................................................................................................... 15

6 Underlying system design and development ..................................................................... 16 6.1 Envisioning....................................................................................................................................... 16 6.1.1 Problem statement ...................................................................................................................... 16 6.1.2 Vision........................................................................................................................................... 16 6.1.3 Scope of DRDS ........................................................................................................................... 17 6.1.4 Solution concept .......................................................................................................................... 17 6.1.5 Critical success factors................................................................................................................ 18 6.1.6 Initial schedule............................................................................................................................. 18 6.2 Design and planning ........................................................................................................................ 18 6.2.1 Conceptual design....................................................................................................................... 18 6.2.2 Logical design ............................................................................................................................. 20 6.2.3 Physical design............................................................................................................................ 25 6.3 Change Management....................................................................................................................... 27 6.3.1 DRDS Change Management....................................................................................................... 27 6.3.2 Requirements Change Management........................................................................................... 28

7 Conclusion ......................................................................................................................... 29


050319_ATHENA_DB44_DRDS_V10.doc CONFIDENTIAL Page iv / 29

Figures

Figure 1. Overall ATHENA requirement engineering process.............................................................. 3 Figure 2. Requirements gathering. ....................................................................................................... 4 Figure 3. Classifications used............................................................................................................... 5 Figure 4. System architecture and processes. ..................................................................................... 6 Figure 5. Main Web User Interface....................................................................................................... 6 Figure 6. One container per requirement type...................................................................................... 7 Figure 7. Highlighting related requirements.......................................................................................... 8 Figure 8. Links from a classification. .................................................................................................... 8 Figure 9. Global requirements model. .................................................................................................. 9 Figure 10. Initial DRDS Management Process..................................................................................... 27 Figure 11. Initial Requirements Change Management Process........................................................... 28


050319_ATHENA_DB44_DRDS_V10.doc CONFIDENTIAL Page1 / 29

1 Summary

This documents aims to accompany the formal deliverable D.B4.4 Dynamic Requirements Definition System (DRDS). It describes the Dynamic Requirement Definition System (DRDS) per month 12 of the ATHENA integrated project.

This document does not contain a detailed description of the Athena Dynamic Requirements Definition Process. The interested reader should refer to deliverable D.B4.1 Dynamic Requirements Definition for a detailed description of the process, the guidelines for its execution and the principles behind.

In month 12, we have a clearly defined process for managing requirements within ATHENA, as well as a computer system called DRDS to support that process. 116 requirements have been collected and are stored in the DRDS Database (March 3rd 2005).

DRDS consists of two front-ends:

1) A custom web-based user interface

2) A visual modelling tool, Metis, from the ATHENA partner Troux (previously called Computas). Both these share and work together with a back-end requirement database, which is the third vital

component of DRDS. The web-based interfaces are ease to use without extensive training, and allow all Athena

partners to add, view and change requirements that are stored in the database. This basically covers the gather phases of the Athena requirements engineering process, as well as some aspects of classification.

The stored requirements are also available in a global requirements model where they are visualized with the state-of-the-art modelling tool Metis. This visualization supports classification, analysis, elicitation and selection of requirements, i.e. the next phases of the requirement engineering process.

Using this global requirements model, all projects and activities of ATHENA may create additional models that for example describe scenarios or solutions and how these map to the requirements.

All in all, DRDS is central archive of requirements within ATHENA, which supports state-of-the-art visualization techniques and can be linked to from any kind of visual model.



2 Introduction

Anyone designing and developing products will confirm that high-quality requirements are key to success. This is also true for research projects. A central and coordinating part of ATHENA is requirements coming from industry or use cases, which is the responsibility of the industry-oriented B-line activities of ATHENA. These requirements are converted to research issues and solved by the research-oriented A-line projects of ATHENA. To ensure that the research is heading in the right direction, and solving real industrial problems and headaches, gathering and prioritising requirements is essential for ATHENA’s success. This has been done with a web UI and a visual modelling tool.

Chapter 3 contains a summary of the ATHENA requirement engineering process. Readers that are familiar with the process may skip this chapter.

Chapter 4 gives an overview of DRDS and describes the important concepts and logic behind DRDS. All readers should read this chapter.

Chapter 5 contains a user guide for DRDS. It is meant for project partners that will use DRDS. Chapter 6 contains system design and development details of DRDS. Chapter 7 contains a summary of this deliverable.



3 ATHENA Requirements Engineering

This chapter contains a summary of the ATHENA requirement engineering process. The overall requirement handling process of ATHENA is shown in Figure 1, and tasks 1, 2 and 3

are the responsibility of the sub-project B4 called Dynamic Requirement Definition. Requirements are gathered and organized in tasks 1, 2, and 3 by the requirements handling sub-

project, and then passed on to the research projects to find and develop solutions in tasks 4 and 5. Project partners, or external software vendors may perform task 6, while task 7 is performed by the piloting sub-project to verify solutions in the scenarios in which they appeared, as well as other relevant scenarios. It is worth noting that these are concurrent tasks and this is an iterative process, not purely sequential.

ATHENApiloting

ATHENA research

ATHENA requirement

handling

1 Collect Specific

Requirements

3 ElaborateATHENA

Requirements

2 Collect Generic

Requirements

4 Search for Generic Solutions

5 Develop Generic Solutions

7 DevelopSpecific ITProducts

6 DevelopGeneric ITProducts

ExternalWorld

ATHENAScenarios

Figure 1. Overall ATHENA requirement engineering process.

3.1 Gathering Requirements Figure 2 shows the three main tasks of our requirement handling. In ATHENA, requirements

coming from the scenarios are called specific requirements since they relate to specific industrial situations. Only requirements that are related to interoperability are relevant for ATHENA, and these are selected in task one. Similarly, a set of generic requirements related to interoperability are gathered in task 2, coming from various external sources including previous research projects such as UEML.



ATHENA requirement

handling

1 Select Specific

Requirements

3 ElaborateATHENA

Requirements

2 Select Generic

Requirements

ExternalWorld

ATHENAScenarios

ATHENA requirements

Specificrequirements

Generic Requirements

Figure 2. Requirements gathering.

3.2 Creating ATHENA Requirements The specific and generic requirements are then elaborated and turned into ATHENA

requirements. This is done by analyzing requirements in terms of the ATHENA objectives, drivers and pilot projects.



3.3 Classifying Requirements To easier be able to deal with similar and related requirements, they are grouped using

classifications. A hierarchical classification schema is used. Each requirement may be related to as many classifications as are deemed relevant, and the classifications may be extended during the ATHENA project. The classification structure used at present is shown in Figure 3, and other orthogonal or overlapping classification structures are foreseen in the near future to be used by the various sub-projects. A requirement may be classified according to any element in the tree-structure, and there may be multiple trees, so it is perfectly legal to e.g. say that a requirement is classified as ‘business level’.

When creating ATHENA requirements from the specific and generic ones, it is possible to examine all specific and generic requirements that belong to a certain classification.

Figure 3. Classifications used.



4 DRDS overview

To support the requirement engineering process of the ATHENA IP, an IT system with the components shown in Figure 4 was created. Such as system had already been created and used in the UEML project, and this was taken as a starting point. The main parts of this system are: A web user interface, a requirement database and a visual model. The requirement database is shared between the web user interface and the modelling tool, meaning that users can seamlessly collaborate while using two completely different tools.

Requirementsdatabase

Registerrequirement

Web UI

Store requirement

Visual model

Visualizereqs.

Organize requirements

Requirementsreports

Generatereports

Browserequirements

Figure 4. System architecture and processes.

4.1 Web User Interface Most sporadic users of any computer system are very reluctant to install new software. Therefore,

we decided that the requirement handling system had to have a web user interface, as shown in Figure 5.

Figure 5. Main Web User Interface.

The screen is divided into 3 main parts:

1) The left-hand menu allows the user to select function, such as “getting started”, “requirements” or “manage categories”. “Requirements” can be selected for viewing, editing and submitting new generic or specific requirements into the system.



2) The upper half shows the current list of requirements in the system. This list can be filtered and sorted, for example to find existing requirements with given keywords. A requirement can be selected from this list.

3) Details of a selected requirement, which may be a specific, generic or an ATHENA requirement, are shown on the lower half. Details of the requirement include its type, status (e.g. new, solved, rejected, etc.), who is responsible, requester name and organization.

One requirement may be related to any number of other requirements. For each pair of related requirements, it is necessary to select how they are related. The available options are duplicate, impacts, leads to, part of, prerequisite for and. In a similar user interface as for relating one requirement to other requirements, a requirement can be related to any number of categories.

There are also some administrative functions available in the web user interface, for example the administration of categories. This controls what categories are available to connect the requirements to.

4.2 Requirements Database To store all the requirement information needed, a relational database is used. This database has

entities such as requirement, requirement type, status, ATHENA project, class (category), relationship, relationship type etc.

4.3 Visual Model Storing a set of requirements and related information according to a predefined database schema

is not a new idea. However, when using a visual modelling tool that can be extended with any construct necessary to deal with the requirements; we have a whole different situation. Referring back to Figure 4, remember that the web user interface and the modelling user interface in fact share the same data; the database.

Metis [5] is a visual modelling tool that has pluggable metamodels. A metamodel defines the entities (e.g. objects and relationships) that can be modelled. This means that Metis may be used to model anything, as long as there is a suitable metamodel available, and that anyone can create their own metamodel or extend existing ones to suit their purpose. This is exactly what has been done in ATHENA, and therefore Metis can be used to represent and visualize our requirements.

When visualizing something, there are numerous issues to be solved and selections to be made. We decided that each requirement is represented by an object in the model. Further, all requirements of the same type, e.g. specific, are modelled together in an object called a “container”, see Figure 6.

Figure 6. One container per requirement type.



The classes in the classification structure (Figure 3) are considered objects as well, and imported into the lower left-hand part of the model in Figure 7.

The overall model structure was defined to have four main parts: requirements, classifications, attachments and reports. For each of the classifications, links are created to the corresponding requirements objects. A small example of such a model is shown in Figure 7.

Figure 7. Highlighting related requirements.

Now, by selecting one requirement, one can see all its properties, as well as its links to other requirements and its classifications. Similarly, it is possible to start at one classification and easily see in its properties dialog all related requirements as shown in Figure 8. (There are three requirements related to the classification called portfolio management in the example below.)

Figure 8. Links from a classification.



Figure 9. Global requirements model.

A user of the modelling tool may also do searches visually to show related requirements, as shown in Figure 9. (This screenshot shows that three requirements are related to portfolio management.)

In addition, the modelling tool has numerous capabilities such as performing what-if analyses, exporting parts of the data to other formats, doing reporting, etc. which are not available from the web front-end.

4.4 Requirements Reports At the time of writing, which is in the first year of the ATHENA project, a massive amount of

reports to the outside world are not considered crucial. This is because no requirements have been fulfilled yet. However, it will very soon be important to give feedback to external stakeholders to show that their requirements have been understood and categorized properly, as well as show when the requirements are expected to be fulfilled.

4.5 Extending the Requirements Model Any ATHENA research project can extend the central requirements model and create its own

augmenting models. Since the modelling tool allows for anything to be modelled, the research projects may model entities such as their solution (in the form of standards, software, hardware, protocols, interfaces, APIs, etc.), their approach (projects, tasks, partners, architecture) or they may model scenarios to better describe the as-is situations that trigger the need to solve the requirements. All or some of these entities may then be linked back to the overall and common requirements model, showing which solution is expected to solve which requirement, when and who will do this.



5 User Guide for DRDS

This chapter explains the Dynamic Requirements Definition System of the Athena Project, called DRDS. DRDS is based on the Athena Collaboration Platform and available from within it.

Athena Collaboration Platform (ACP) is the infrastructure supporting the day-to-day work of the Athena IP. ACP was launched during the kick-off meeting of Athena in Valencia, February 2004.

DRDS has a Web front end for entering and viewing requirements and their attributes, categorization and attachments and a requirement database for storing this. This front-end is available for all users. Reflecting the requirement database content, a visual model is generated.

This model shows more clearly the dependencies between the various requirements, and inside this model, further work on the requirements is possible, extending with other aspects than those stored in the requirements database.

Regular Athena partner members are allowed to:

• Add new requirements

• View existing requirements

• Change existing requirements

• Mark existing requirement as deleted DRDS Managers are also allowed to:

• Change the categorization structures of the DRDS system

• Change the folder structure of the DRDS system Other related documents:

• The “Athena Collaboration Portal User's Guide” contains information about how to use the ACP.

• The internal Athena B4 document “WD B4 - Athena DRDS 1.0 Spec v4.doc” contains the technical details (specification and design) of DRDS.

5.1 Finding DRDS inside ACP First, go to ACP and log in. Then click on the “Athena B4” button to enter the B4 (Requirements)

portal. Go to the “Tools” area and you will see the picture below:



Finding DRDS inside the portal

In the left-hand tree, you see the DRDS menu, which when expanded looks like this:

Only administrators or DRDS managers have access to the two last services.

5.2 Viewing requirements in the Web UI

5.2.1 View all or one requirement

To view all requirements, click on the “Requirements” service in the left-hand menu. This will show a list of all requirements in the upper list view.

To view details of one requirement, click on the left-most column in the list (ID column). Details are then shown at the lower half, like this:



Viewing all requirements

5.2.2 Search and filtering

To add a filter to the list of requirements, enter some text in one of the header columns like shown below where only requirements with “add” in their description are listed.

Applying a filter to the list of requirements

5.2.3 Searching and reporting by category or other

This is currently not supported in the Web UI, only in the Metis model. No other reports are so far implemented in the Web UI.



5.3 Submitting a new requirement Any Athena partner is allowed to enter new requirements.

5.3.1 Entering basic information

To submit a new requirement, press the “New Requirement” button. This will show the screen below.

Entering basic requirement information

Enter all fields you know and understand, and press the “Submit” button to store the new

requirement.

5.3.2 Entering additional information

Press the “Additional Req. info” button to enter more information about the requirement:

Entering additional requirement information

Press the “save” button when finished.



5.3.3 Classifying the requirement

Press the “Categorization” button to select categories the requirement belong to:

Categorization of requirements


5.3.4 Relating to other requirements

Press the “Related Requirements” button to relate the requirement to other requirements:

Relating to other requirements


5.3.5 Submitting attachments

Press the “Attachments” button to add attachments: Attachments are additional files that describe the requirement, its context, background or similar.

The attachments will be stored in Team Server.



5.4 Viewing the requirements model To view the requirements model, you must follow the instructions in “getting started” in the DRDS

web pages. (This means installing Metis and the proper meta-models).

• Click on the “Requirements model” link in the left-hand menu.

• Metis is started, and the model

https://www2.mycomputas.com/team/repository/projects/project_213/req-model.kmv is loaded

• Enter your user name and password

• This will load the requirements model showing visually all requirements, categorization etc.

5.5 Using the requirements model

• Check out model, from web-pages or Metis repository browser

• Make changes using Metis client

• Check in model, from web-pages or Metis repository browser

5.6 Administrator functionality

5.6.1 Specifying classifications

Click on “Requirements classifications” to go to the administration of classifications. The user interface allows you to add, change or delete classifications. For each classification, choose which top-level classification it is a child of.

5.6.2 Triggering model import

To re-generate the Metis model with all the requirements that are stored in the database, click on the “Generate model” link and then click on the “Import XML” link to start the import.



6 Underlying system design and development

It was agreed in Lisbon in March 2004, that ATHENA need some structured way of collecting requirements quickly, and that the first version of DRDS should be based on the requirement handling system of the UEML project. In addition, an adjusted version of a template from IDEAS for scenario collection / requirement collection was to be used.

DRDS 1.0 was operational to the Mallorca meeting in the end of May 2004. Given this short time, DRDS 1.0 had to be quite similar to the UEML system. Several improvements to DRDS 1.0 were implemented in DRDS 2.0, and it was operational in end of 2004.

The rest of this chapter describes the design of DRDS (by following a simplification of the Microsoft Solution Framework development methodology).

6.1 Envisioning

6.1.1 Problem statement

We need to collect requirements from various sources, internal and external. The projects inside Athena need a system that allows them to deal with these requirements in a professional and coordinated way.

6.1.2 Vision

We want a DRDS that supports various kinds of users that have different needs and therefore need to see and work in different views of the total requirements like in the figure below:

Generic Reqs.

Specific Reqs.A-lineperspective

B-line

persp

ectiv

e

Industryexternal

perspective

In addition, we would like the A-line projects and B-line activities to be able to model related aspects and how this relates to requirements objects. For B4 and B5, modelling the scenarios, and A-line solutions to requirements. An example of this is shown in the figure below where requirements in the upper left-hand corner are linked with business processes and product structures of the scenarios:



6.1.3 Scope of DRDS

The scope of DRDS is something similar to the requirement system used in the UEML project, with some necessary additions. This system had the following functions: register requirements, categorize requirements and some simple analysis and reporting features. Refer to www.ueml.org and WP2 of the UEML project for more information.

6.1.4 Solution concept

The main aspects of the solution concept are shown in the figure below: Web UI, Requirements Database, Visual Model and Reports.

Requirementsdatabase

1. Registerrequirement

Web UI

2. Store requirement

Visual model

3. Visualizereqs.

4. Organize requirements

Requirementsreports

5. Generatereports



The main processes are:

1) Web pages for input of requirements

2) Storage in a requirements database.

3) Visualization of requirements and their relationships in a visual model (based on the requirements database)

4) Organization and refinement of the requirements inside the visual model, with updates written back to the requirements database

5) Various reports and extracts from the requirements model targeted at different audiences (both internally in Athena and externally).

6.1.5 Critical success factors

Having a system up and running that from day 1 in operation allows various project members to add their requirements and related documents. This means items 1. and 2. in the solution concept.

6.1.6 Initial schedule

DRDS version 1.0 should be operational in May 2004. An adjusted version 2.0 should be operational in end of 2004.

6.2 Design and planning

6.2.1 Conceptual design

The conceptual design is written and modeled in user terms, and describes the DRDS actors, what can be done and the overall architecture.

Actors

• Req. system admin – responsible for the requirements system.

• External user – someone not part of the Athena IP, but still contributing to requirements

• B5 Pilot partner – partner working in B5

• B4 Partner – partner working in B4

• B4 Manager – the one overall responsible for requirements

• A-line Partner – someone working on the research projects, main consuming and refining requirements.



Use cases

Here are the main operations performed by the various actors.

Overall architecture

This is a refinement of the solution concept, described in Section 6.1.4, Solution concept:

Requirements DB

DB Extraction HTML

Extract

Member or Partner adds requirements on the portal (including attaching documents)

Member or Partner reviews all requirements in HTML on portal (links to online documents)Req. responsible

organizes requirements and extracts misc. useful reports and overviews

Misc. reports

Comments (also on mailing list)

Repository



6.2.2 Logical design

The logical design is created for the IT solution team, including project managers, but excluding end-users. It is therefore not useful for all Athena partners.

Logical object model

The main class in our object model is the Requirement. It can be related to an arbitrary number of other requirements, and these are typed relationships.



Description of the classes

Class Description

Requirement Represents on requirement. Types of requirements: General vs. Specific. Research vs. industry. The state of a requirement is a state-diagram according to the requirement life cycle.

Attachment Document or URL describing the requirement

Requirement Folder

Defines a hierarchical folder structure for the requirements. Makes it more convenient to work with the requirements

Requirement Attribute

This is just a mechanism to dynamically add more attributes to all requirements.

Requirement Category

This is a hierarchical category structure. Each requirement may have associations with as many of these categories as desired

Audit This represents a list of actions performed on one requirement: Who did what when.

Initial allowed values for Related Requirement types:

• Duplicate – one requirement is completely covered by another one

• Contains (vs. “is contained in”) – one requirement describes only part of the problem of another one

• Related – one requirement is important to understand another one

• Generalizes (vs. “specializes”)

Initial set of instances of the RequirementFolder objects:

This is the hierarchical breakdown of requirements in folders seen at this point:

• Meta-models and concepts

• Methodologies

• Tools and Specification environment

• Execution environment

• Pilot applications/ usage



Initial set of instances of the RequirementCategory objects:

These are the categories that each requirement can be associated with, seen at this point:

• Technology area

Enterprise Modeling

Process modeling

Product modeling

Organization modeling

Systems modeling

Ontologies

Architecture and Platform

• AL A Goals

Goal 1

Goal 2

• Stakeholders

Administration

Industry

Service

• Scope

Extended Enterprise

Corporation

Company

Department

Project Group

Team

Individual

• Process

Change

Control/monitor

Doing business

Innovate

Manage

Manifest

Planning

• Relevant Scenario

E-procurement

Supply Chain

Portfolio management

Collaborative process design



Initial set of instances of the RequirementAttribute objects:

These are the additional attributes for each requirement foreseen at this point:

• Requester priority – Priority seen from the perspective of the one requesting this

• Requester organization – Name of company / university requesting the requirement

• Requester time frame – When requester wants / needs this solved

• Is situation – Description of the situation today (without the requirement solved)

• Desired situation – What the requirement should solve, a description so to speak

• Problem space – A selection of relevant research fields

• Existing research – What is known to the requester about related research

• Existing technology - What is known to the requester about related technology

• Existing standards - What is known to the requester about related standards

• Research gap – What research is needed to fulfill the requirement

• Technology gap – What technology is needed to fulfill the requirement

• Standards gap – What standards are needed to fulfill the requirement

• Relevance to E-procurement scenario – How this requirement is related to that scenario

• Relevance to Supply Chain scenario - -“-

• Relevance to Portfolio management scenario - -“-

• Relevance to Collaborative process design scenario - -“-

• Proposed requester solution – Proposal from requester for how to solve this

High-level user interface

For registering requirements:



For organizing the requirements, a visual model is used:

For reporting, a web page will be created, with the information from the organized model:



6.2.3 Physical design

The physical design is created by and written and modeled for the developers. It is therefore not fully detailed in this document.

Components

The system will have these components and sub-components: Problem tracker UI: The ACP form editor will be used to create the needed forms in the figure

below:

Metis will be used to create the models in the figure below:

A special meta-model for the Athena DRDS system will be created; to be able to properly represent all needed aspects.



ASP.net and the Metis COM api will be used to crete the reports in the figure below:

The final component is the Requirement DB. It will be created with the SQL Server Enterprise Manager.

User interface

The user interface has not been finalized yet.

Physical database model

This is a simple mapping from the class diagram in the logical object model. (See 0.)



Programming model

The following apply to the programming of this solution:

• The so-called meta-form facility of the ATHENA Collaboration Portal (ACP) will be used to configure the Requirements input forms.

• ASP.net will be used for the web UI, if the meta-form facility of ACP is not sufficient.

• SQL Server Enterprise Manager will be used for the Database design.

• Metis DIF (XML Data Import) and a template model will be used to generate the requirements model from the requirement database.

• Visual Studio .net and C# will be used for creating reports from the model. The Metis COM API will be used to read the needed data.

6.3 Change Management The change management is related to the entire DRDS as well for each requirement, which is

inside the DRDS. In the following subchapters the initial process will be introduced.

6.3.1 DRDS Change Management

Any B4 partner will be able to define change requests for the DRDS. They will use the DRDS category and will so be able to define these change requests during their work with the DRDS. IPK will check all change requests on working days. A team will analyze the request and will provide a proposal. IPK will here also involve other partners, which will be identified by the relation to requirements categories (like project link). Two weeks after submission of a change request a proposal for solving will be send to a decision group. In monthly conference calls the DRDS decision group decides about the DRDS changes. There are two possible categories of changes first for DRDS system change on the technologies – which is under control of the activity C4 – Troux. The second type of change has to do with changing the DRDS model which will be performed by IPK.

The changes will be monitored according to time and quality as well the results will be transferred to the DRDS requester and the decision group. Regularly the CATS leader will be informed. The initial process can be seen in Figure 10

2 weeks after

Change request

MonthlyConf Call

2 weeks after Change request

MonthlyConf Call

Figure 10. Initial DRDS Management Process



6.3.2 Requirements Change Management

Integrated requirements will be analyzed in order to check in terms of ability to understand, classification level of granularity and hierarchy. The time objective is 1 week after requirements submission. If there are changes necessary IPK will propose together with the requirements submitter the change.

IPK will send every month a change report to the major groups in ATHENA (Projects and Cross Action Line Teams). In case of major changes (classification) the report will be send on demand. The initial process is explained in Figure 11.

1 week after submission, depends on the number

of requirements

1 week after submission, depends on the number

of requirements

Figure 11. Initial Requirements Change Management Process



7 Conclusion

DRDS is operational. The system covers the needs of the ATHENA IP project, but the mechanisms to capture new requirements and refinement suggestions have been established. These additional requirements to DRDS are collected in DRDS itself, and new versions of DRDS may be made later in the project.

deliverable b4.4 drds work package – b4 · ip- project / programme athena project - no 507849...

Documents