Enterprise Architect for Business Analysts


As a software architect and developer I’ve used Enterprise Architect (EA) from Sparx Systems (www.sparxsystems.com) for a number of years. In that time I’ve spent considerable time and energy trying to get our business analysts to do the same. While I’ve had some success I must admit it’s been an uphill battle. I suspect this is partly because EA is often seen as a technical person’s tool. And that’s not altogether surprising.

  • Enterprise Architect – the name itself is completely misleading. EA is not only for people with the title ‘Enterprise Architect’. It’s for the entire project team, from BA’s to Testers and even for Clients.
  • User Interface – for developers the user interface of EA is extremely familiar and intuitive. It looks like a lot of the tools they use already. For non-technical users more familiar with tools like Microsoft Office it is somewhat more intimidating.

So, if you’re a Business Analyst looking for a tool that can help you do your job more effectively then read on.

A lot of the BA’s I come across have a standard set of tools they use to document the results of their analysis.

  • Word Processor – perhaps the most frequently used tool, word processors are used to document everything from Vision Documents to End User Requirements. They are the primary mechanism for sharing information between the members of a project team.
  • Diagramming Tool – tools like Microsoft Visio are used to draw UML diagrams, screen mockups and a variety of custom diagrams. Diagrams are typically copy-and-pasted into relevant Word documents.
  • Spreadsheet – spreadsheets are often used to list requirements and issues. They are typically seen as ‘live’ documents that gets frequently updated and distributed across teams.

Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system.

  • Information is Hard to Find – documents are often numerous and stored on various file systems or contained within emails as attachments. You’re never sure whether you’re looking at the latest version or whether someone is working on a local version of a file somewhere. It’s difficult if not impossible to search across all sources for the information you are looking for.
  • Lack of Traceability – it should be possible to examine the relationships between the artifacts that are created as part of an analysis. For example, to trace from a system requirement all the way back to the business goal that drives it. This is particularly difficult to achieve when requirements are stored in spreadsheets and use cases and business goals are contained in separate documents.
  • Maintenance Overhead – documents are often composed of artifacts from other sources. For example, diagrams are created in a separate tool and copied into a document. If the source diagram is updated then this change is not always reflected in the master document. Similarly, requirements identified in functional specification documents are often transcribed into other formats such as spreadsheets. All of this makes keeping documents up to date difficult and error prone.
  • Lack of Consistency – because the tools allow a variety of styles to be applied to documents and diagrams it is easy for BA’s, even from the same team, to produce vastly different document formats. Some will use formal UML others will use pretty pictures and other won’t use diagrams at all. This is equally true for architects too and one of the primary reasons I like to see architectural diagrams drawn in EA is that it enforces a level of consistency that is lost once people crank open Visio and start getting ‘creative’.

This article will examine the ways in which Enterprise Architect can address some of these issues and become the single tool of choice for Business Analysts.

1. Enterprise Architect

If you’ve never heard of Enterprise Architect then check out their excellent website and you’ll get a good idea of what it’s all about. EA is software modeling tool for the entire project team, Business Analysts, Developers, Architects, Testers, Project Managers and even Clients.

Essentially EA provides the ability to describe things (i.e. use cases, requirements, screen shots…) and the relationships between them.

Once users define these things (known as elements in UML speak), EA provides an extensive range of features to manage, search, display and document them.

2. UML Diagrams

With EA users can construct any of the 13 diagrams defined within the UML 2.1 specifications. Business Analysts will most frequently use the following diagrams.

2.1 Activity Diagrams

As expected, EA supports standard activity diagrams (Figure 1) and partitioned activity diagrams (Figure 2).

Standard Activity Diagram

Figure 1: Standard Activity Diagram


Partitioned Activity Diagram

Figure 2: Partitioned Activity Diagram

2.2 Use Case Diagrams

Use case diagrams (see Figure 3) are defined by adding Actors and the Use Cases they act upon. It can also show the relationships between use cases. Details about use case and actor elements can be authored as with any other type of element by double-clicking it to view the element properties (see Figure 4).

Use Case Diagram

Figure 3: Use Case Diagram


Figure 4: The properties dialog of a use case allows you to enter all the details including summary, scenarios and any elicited requirements.


2.3 Sequence Diagrams

Although typically used by more technical users, sequence diagrams can be useful for BA’s to describe high level interactions between elements. Figure 6 gives an example of how a user logs in to a system without getting in to too many technical implementation details. It would provide a great starting point for a developer to implement a full solution.

High level Sequence Diagram

Figure 5: High level Sequence Diagram

3. Custom Diagrams

In addition to the standard UML diagrams EA supports a number of other custom diagrams. The most useful of these for a BA include,

3.1 Mind Maps

Introduced in EA 7.0, Mind Maps are a great way to brainstorm ideas during the early stages of a development project. Although not part of the UML specification the topic shapes and the relationships between them are treated in the same way as any other element in EA.

A Mind Map I created for a recent presentation on Enterprise Architect

Figure 6: A Mind Map I created for a recent presentation on Enterprise Architect


3.2 Screenshots

Screenshots are useful way for BA’s to describe how a system should present itself to users.

Figure 7: Content and functionality exposed on the Login screen.

Like any other element user interface elements (screens and controls) can be associated with use cases or requirements. Again this helps those implementing requirements to quickly determine all relevant information.

4. Requirements Management

Requirements can be recorded from the properties window of individual elements (for example on the see tab of Figure 5), or externalized and treated as elements in their own right. Simple properties for externalized requirements are defined using the requirement’s properties window (Figure 8).

Figure 8: Requirement properties

Once entered into EA it’s possible to create diagrams like Figure 9. This is invaluable for someone charged with implementing a particular use case. Try doing this when some emails you a use case document and link to a requirements spreadsheet!

Enterprise Architect makes it easy to create diagrams that show all the requirements relating to another element.

Figure 9: EA makes it easy to create diagrams that show all the requirements relating to another element.

Other cool requirement management features include,

  • CSV Export/Import - requirements (or any element for that matter) can be exported or imported to CSV format. Useful to see and update requirement statuses in bulk.
  • Hierarchical Requirements - requirements can be modeled (as is seen in the diagram above) in a hierarchical way, for example, one requirement can be broken down into finer detailed requirements. This is particularly useful for systems with large numbers of requirements.
  • Color code requirements based on status - good way to visualize progress. In Figure 10 approved requirements are colored green and proposed requirements are yellow.

5. Traceability

We’ve already seen a number of ways in which you can trace relationships between elements. The Relationship Matrix is another. It enables you to visualize specific types of relationships between any elements in the system. This is particularly useful in identifying critical requirements that are associated with multiple use cases.

The Relationship Matrix provides a visual representation of the relationships between elements.

Figure 10: The Relationship Matrix provides a visual representation of the relationships between elements.

6. Documentation

Within EA the creation of documents is seen as a by-product of analysis and design rather than the goal. This is a huge difference with alternative approaches where formatting and constructing documents can be a time consuming process. Further, the ability to share information contained in multiple documents is another challenge. For someone to access the latest information they have to rely on you, the author, putting a copy of the document where it can be accessed. For external parties this can sometimes only be achieved via email. What's more you never really know you have the latest copy of a document at any point in time.
EA solves these problems by enabling you to automatically generate documentation in a variety of formats.

  • RTF Documents - at the push of a button (well almost) you can document selected parts of your model in RTF format. You can use in-built templates or customize them for your own needs. A number of techniques exist to incorporate these RFT documents into master Microsoft Word documents to provide even more control over the look and feel.
  • HTML – ideal for sharing your model if team members are spread across remote locations. Simply publish selected parts of your model as HTML and get the Techie Crew to copy it up to a public web server somewhere.
  • EA Itself – of course if you are working with a team of people who each have EA installed on their computers and can access a central database then you could decide this is all the documentation you need.

7. Conclusion

So now you know – Enterprise Architect is not only for Enterprise Architects but for you Business Analysts too. And if you weren’t already convinced to give it a try you’ll be pleased to know it’s a fraction of the price of other similar products starting at around US$200/user. If you’d like to try before you buy then you can download a fully featured 30 day trial version for free. Just check out the website, www.sparxsystems.com.

Author: Andrew Tokeley, Development Manager, Intergen Ltd

Andrew has been involved in the IT industry since 1996, starting out in his own company writing Microsoft Access applications and since gaining hands-on experience of a wide range of Microsoft technologies. He's still passionate about development but over the last few years his focus has centered on a more holistic view of the entire process of realizing a client's vision in software. He loves the industry and is passionate about improving the way we, as a development community, design and build solutions.  You can read Andrew's blog at: http://andrewtokeley.net

Like this article:
  68 members liked this article


Sandeep posted on Wednesday, May 7, 2008 12:17 PM
Hi Andrew,

This is a great article. I am a BA who has worked with EA on prior projects and I absolutely fell in love with it. Not only does it have so many of the tools I need to help document my analysis, but I also love how I am able to develop traceability between my analysis and the actual development that is done. Even more importantly, it is extremely cheap, when you look at some other tools which just adds to its appeal. I agree, that if a development team is looking for a tool that can help them document, and provide end to end traceability throughout the life cycle EA is the way to go.
posted on Wednesday, May 7, 2008 3:36 PM
Thanks for a great read and supporting visuals.

I used EA a while back on a web application project. At that time it was a bit too clunky for me. I felt my setup (multiple apps for multiple needs) allowed me and my team to stay nimble and focused. However, after many years spent trying to keep source diagrams in sync with presentations, code-bases and documentation I think I'm ready to revisit unified suites like EA.

It was worth the read -- at least it reignited my interest in unified tools for IS Analysis. Tracing relationships is a neat feature, throwing in mind maps - now that's way cool! I hope it's not overly heavy though...

Thanks for presenting this tool in a manner deviod of "sales-man lingo". I found it useful.
Ernest posted on Wednesday, May 7, 2008 5:32 PM
Indeed, thanks for this great article inlcluding the figures.

I think you should also mention the BPMN add-in! Great feature for the BA's practicing process engineering too.
John posted on Thursday, May 8, 2008 11:34 AM
Well written article but wish it was from a BA.

I've written out UCs in word using tabling to seperate out BRs, Conditioins, Change History, and a description of all of the fields that are being acted on in the UC. I'm having a hard time finding a way to convert it over to this tool. The examples in EA are high level UC w/o any field information. One example EA diagram deals with a mail system and there are NO descriptions of the fields in the UCs for sending a message. Where does this get described and how do I utilize my existing analytical style in this new tool?

I'm use to seperating out my diagraming from my textual analysis and have not confirmed to UML standards to much in BA work. Normally I haven't diagramed out all the excpetioins but described them after requirements were written in UC and business scenario analysis. So the piece that makes EA great for conforming to one method I believe prevents relevent important requirements or context from being communicted to the developer. Have you found ways to over come this issue?
AndrewT posted on Thursday, May 8, 2008 4:31 PM
Hey, I wish it was written by a BA too!

In answer to your question about modeling field level requirements there are a number of approaches you could take. I will try and do a post on this soon as it's a good question.

- Rather than adding field level descriptions to your Use Case you could model the UI directly (and relate this back to a UC if necessary). For each UI element (textbox, dropdown...) add constraints or properties to describe field legth, type...

- Associate a Requirement element to the Use Case called "Field Level Requirements". Add tagged values for each field describing the field constraints.

- Create individual Requirements for each field definition (perhaps too time consuming but possible). Associate these to the UC.

- Attach a file to a use case (from the properties window, select the File tab). Include the field level details here.

DBrowning posted on Saturday, June 14, 2008 11:13 AM
Very interesting article. The only thing I would add would be a comparison with other commercially available tools. I'm a newbie in the field and would like to hear your opininos of other tools, since we all know we won't be able to choose our own tools in every situation.
AndrewT posted on Sunday, June 15, 2008 3:49 PM
@DBrowning - unfortunately I haven't used any of the main competitor products. But I can tell you that EA ($US355 per developer) is significantly cheaper than similar products like Rational Rose Technical Developer (US$21,000) - pretty compelling.
Only registered users may post comments.


Upcoming Live Webinars


Copyright 2006-2024 by Modern Analyst Media LLC