search

openETCS / toolchain

WP7: Top Level Project for the toolchain
27 stars 30 forks source link

Adapt the Traceability architecture document to the needs of WP3 and WP4 #471

Closed cecilebraun closed 9 years ago

cecilebraun commented 9 years ago

Tasks to be done by Faiez to complete this issue:

@openETCS/toolchain Here is proposition for the traceability architecture: https://github.com/openETCS/toolchain/blob/master/T7.3/TraceabilityArchitecture/oetc_WP7_traceability.pdf

Please read it and comment it in this issue. We will discuss it 08.01.2015

MarcPantel commented 9 years ago

Dear Cecile,

I will have a look and provide feedback.

Best regards, Marc

Marc Pantel Maître de Conférences en Informatique Assistant Professor in Computer Science IRIT - Institut de Recherche en Informatique de Toulouse - CNRS N7 - INPT - Université de Toulouse - France - Europe http://maps.google.com/maps?q=Rue+Charles+Camichel,+31000+Toulouse,+France&z=16 phone +(33) 534 32 2185 fax +(33) 534 32 2157 cell +(33) 676 221 687

raphaelfaudou commented 9 years ago

Dear all,

Just joining the project on WP7 traceability, in support of ENSEEIHT partner.

I have read the last revision of traceability architecture document and I get some remarks/questions with current figure about traceability process.

  1. For me all traceability link types (satisfies, realizes, refines and defines) concern relations between engineering artefacts. I do not understand "satisfy" relations between artefact and activities. Can anyone explain?
  2. Other confusion concerns what does "System model" means: is it system specification (requirements) model? In case it is specification model, I'm not comfortable with "realize" relation between functional model and system model. Generally we get high level system functions that are "services" provided by system and that refine system requirements. Then those functions are broken down into functions of lower complexity and we get functional architecture. Finally when physical architecture is identified, there are new functions (technical) that appear in order to support functional flows carried by physical interfaces. Those functions are derived from physical architecture. For me "realization" is rather a term used for physical components (physical architecture) that realize functions (and associated functional requirements) in addition to other non functional requirements.

Perhaps it is just semantics: need some alignment because my background comes from avionics and INCOSE and words are different.

  1. Where is physical architecture? If we mention functional architecture, we need to show how functions will be allocated to system physical elements. Did I miss something?

If anyone can give me some pointers to other documents that help understanding those terms and this picture, I would appreciate a lot.

raphaelfaudou commented 9 years ago

Dear all, I have completed traceability architecture document in two directions:

  1. added background for reviewers in the beginning of document to introduce requirement engineering levels, models scopes, priorities, expectations for traceability (that I could capture) and first tool chain requirements.
  2. completed suggested traceability architecture solutions with two other solutions more integrated.

I took the time to do a lot of diagrams in order to help understanding and provide concise illustration.

I would appreciate feedback on described context (I might be wrong in some interpretation and I'm quite new to the project) and on suggested second and third solutions.

Thanks

jastram commented 9 years ago

I believe that this can be closed with the release of the traceability document. Please reopen, if anyone disagrees.