EA allows you to capture all kinds of information about your project, but it's real power comes from relating different kinds of information together.
So it's great that EA can store Use Cases and Components, but when you start to relate them together, to say which components are involved in implementing which Use Cases, you are making real progress in understanding your project.
Putting this knowledge about the relationships between 'things' into readable documents has always been a problem. The only solution is often diagrams, which are fine when the number of relationships is small, for example, in a Class diagram.
But as you use EA more, you may find that more and more of your understanding of the project is expressed in relationships: not just classes related to other classes, but classes to use cases, use cases to requirements, requirements to stakeholders.....
eaDocX allows you to make these relationships fully visible to readers of your documents, in a powerful and flexible way.
This is best illustrated using an example.
We've created two types of EA Element: Stakeholders, which are Actors of stereotype <<stakeholder>>, and Requirements. We've also linked them, to show which stakeholder owns which requirements, and even one who is "demanding" requirements (we've attached a note to that relationship, to show there is more information on the relationship).
If we now decide to print a quick table summary of which requirements are owned (or demanded) by each stakeholder, we might want to print:
|
To do this, when specifying how to print <stakeholder>Actors, add a Relationship attribute, telling eaDocX to follow 'Dependency' links, and print the name attribute of what's at the other end of the relationship, that is, the Requirement name.
We might want to print more information about the requirements, for example, to have a table of them after each stakeholder, like this:
1 - Stakeholders 1.1 Fred Fred is the..... 1.1.1 Requirements
1.2 Bill Bill is responsible... 1.2.1 Requirements
1.3 Jane Jane is the.... 1.3.1 Requirements
|
In this case, we have a whole table of requirements after each stakeholder. See Relationship tables for more details.
Just occasionally, we might want to print all about a related element in whatever style it is formatted: table or inline. See Relationship Elements.