Modification de La traçabilité

The following article deals with the traceability management with Enterprise Architect (EA). The main point of the traceability for a project, which is designed with EA, is to make sure the requirements of the project are in line with the models that you are building.

For instance, when you complete your design, the traceability between your component model (part of design phase) and the requirement model will allow you to make sure the component model is covering all the requirements.
==Input==
Goal of traceability in a project which follows a V-Cycle:
* •	Ensure the requirements traceability from specification to validation
Input for a traceability between the requirements and the use cases:
* •	Requirement Model 
* •	Use case Model 
* •	Tracability diagram 
<<pic1>>
As traceability can be compared with a gap analysis between 2 models, the traceability will begin once you have the models completed.

Example for the TPS module, you have:
The requirement
 	The use cases
 
Now, to build the traceability model, you have to link every use case to a requirement in using the EA relationship called “realization”. Once this is done for all the use case you should have the following:
 
Note: in this example the following color code was used for the requirements:
•	Yellow: Proposed 
•	Orange: Mandatory 
•	Grey: Implemented 
You have now complete 90% of the work. But keep in mind that the 10% of the work have to be completed and are in fact the most important part.
Build the traceability matrix

If you now go in EA to: « View -> Relationship Matrix »
Select the source (Use Case) and the target (Requirement) with the « Link type » = Realization, you will obtain the following:
 
NB: « Option » section allows you to extract in csv format the matrix.
Excel/csv extract:
 

You are now able to compare the requirement and the use case. You can so be able to identify orphan requirement and/or orphan use case.
Traceability utility:
1.	Allow you to be sure that there is no missing requirement that was not addressed in your specification.
2.	Allow you to know if some use case is not link to any requirement and so could be not needed.
3.	Allow you to provide a report for your manager/client as a “proof of quality”. “As shown with this traceability matrix, no requirement is missing in our solution.”
Conclusion

The above show a way to track the consistency of your specification. The same method can be used with the design, the integration and the validation phase of your project.
If we want to go deeper into Traceability, we will be able to build a traceability matrix between the use case model and the test model. If you already have traceability between the requirement and the use case, it will be simpler and quicker to do traceability between the use case and the test model. A list of requirement can be big and not easy to handle, whereas a list of use case is smaller. So you will same time in using the use case rather than the requirement.