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

[cecilebraun]

Tasks to be done by Faiez to complete this issue:

• At least rudimentary complete all open sections in this document (marked as TODO)
• Talk to WP3 and WP4 representatives, find out what they are doing TODAY and what they want to do in the near Future and incorporate it in this document.
• Organize a review of this document, involving WP3, WP4 and WP7

---

@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]

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]

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]

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