A Veteran’s View on Making EA Documents Actually Readable

Like most EA users, we started with the built-in document generator. RTF templates, fragments, master documents… all the usual moving parts. On paper it looked powerful. In practice, it was the same old story: we spent more time fixing templates than improving the actual model. A tiny formatting change meant climbing back into the template designer; assembling the right combination of packages and searches felt like threading a needle in a sandstorm; and training new staff was a slog. Eventually, people just gave up and pasted content back into Word. Honestly, I couldn’t blame them.

So we started looking at alternatives—again—and came across eaDocX on the Sparx extensions page. I wasn’t holding my breath. But the idea of seeing the finished document inside EA, not just firing out a report and hoping it was usable, was interesting. We downloaded the trial, ran a Quick Document, and—much to my surprise—got something clean and readable in seconds. It even used our normal Word template, so the document looked like something humans might have written. That was the moment my team stopped sighing at “yet another add-in.”

For me, the real value is readability. eaDocX leans on standard Word features—styles, cover pages, headers, footers, proper TOCs—all things my team already knows. The reports now look like the ones our business analysts used to build by hand, back before they ran out of time to do that. We can even take another department’s corporate template, add EA content, and keep all the original branding intact.

One feature I didn’t expect to care about but now use constantly is suppressing empty sections. While we’re building the model, we keep the “(none)” placeholders because they tell us what’s missing; once the document is ready to go, we remove them. It gives the final result that “hand-built” look that EA’s native generator never managed.

Stakeholders have also noticed how easy the documents are to navigate. Because eaDocX produces real Word documents, all the cross-references, page numbers and heading links behave the way people expect. When someone clicks “Requirement R-123,” they actually end up at R-123. That alone has cut down on half the questions I used to get in review meetings.

The relationship matrix has also been a standout. We can produce proper Word tables showing requirements vs test cases, or capabilities vs applications, straight from the model. We used to maintain those spreadsheets manually in Excel, and they were never quite up to date. Now they’re always accurate and in the correct style, which keeps our auditors happy—and that’s no small achievement.

As we’ve grown more comfortable with eaDocX, we’ve started tailoring documents for different audiences. Senior stakeholders get a shorter, model-light version; technical reviewers get the full detail. Yes, we could have done this with EA’s native RTF tools, but eaDocX makes it much less painful.

To be frank, once we compared EA’s native output with an eaDocX version for the same project, the decision was obvious. eaDocX documents take less time, match our house style, and—importantly—people actually read them. We still use the native generator for quick throwaway reports, but anything going outside the team is eaDocX by default.