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).
Figure 1: Standard 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).
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.
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.
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!
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.
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