Note (9 May 2008): This post has been written up and expanded upon as an article on Modern Analyst. Check it out.

I recently presented a Twilight at Intergen on Enterprise Architect 7.0. The audience was primarily non-technical people which was encouraging because, in my experience EA is often seen as a technical person's tool. In a bid to dispel this myth I thought I'd do a series of posts on how EA can be used to help those non-techie types. I won't be regurgitating EA's help guides or tutorials but what I will do is provide someone who wants a quick overview of features and benefits with some ideas to take away and decide whether EA is for them.

In this post I'll be looking at the EA goodness aimed at Business Analysts.

At its core the role of a BA is to articulate the needs of a client in such a way that others can turn those needs into working software. EA can help in a number of ways.

UML Diagrams

Since most people think of EA as primarily a UML tool it won't come as any surprise that you have the ability to create any UML diagram you like. Of the 13 diagrams that are covered by UML 2.0, these are the ones BA's will most likely be using.

 

image

Use Case Diagrams

 

  image

Activity Diagrams

  image

Partition Diagram (special form of Activity Diagram)

image

You can even use your own images

 

At this point you might be thinking, heck I can do all this with Microsoft Visio and a Word Template, why would I want to use EA? Well...

  • Find-ability - what typically happens is that multiple documents are created to describe business processes and the use cases that formalise them. For large systems it can become increasingly difficult to find the information you're after. As someone who is being asked to realise the use cases as working software it is paramount that all information can be found in a central place.
  • Managing change - the issue of finding specific information is made even more difficult when you consider multiple versions of the same document. Using EA as a central repository you know you're looking at the latest version.
  • Traceability - relying on people to track changes in their documents can be a challenge. This is especially difficult when multiple people are working on the same documents. EA's new Auditing functionality allows you to track changes to individual properties of use cases and any other element you model.
  • Maintainability - you get to focus on maintaining you model (use cases, actors, relationship etc) rather than worrying about creating and formatting documentation.

It becomes even more compelling when you look further at requirements management.

 

Requirements Management

The road to realising use cases in software is often bridged by specific system requirements. These are typically derived directly from use cases or independently from other business drivers (for example, non-functional requirements like performance, security, scalability...).

If I was tasked with implementing a particular use case it is very simple to construct a diagram like the one below to show me all the related requirements.

image

In fact, with the EA example project, this diagram was created by the following simple steps.

  • Create new (custom) diagram
  • Set the diagram properties to show Element notes
  • Drag on the use case of interest
  • Right-click the use case and select Add -> Related Elements...
  • Select to include only Requirements

And that's it. I can clearly see all the requirements that are related to the use case and make sure that the work I do caters for them all. Try doing that with a stack of Word documents :-) 

Other cool requirement management features include,

  • CSV Export/Import - requirements (or any element for that matter) can be exported/imported to CSV format. Useful to see and update requirement status' in bulk.
  • Hierarchical Requirements - requirements can be modelled (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.
  • Colour code requirements based on status - good way to visualise progress.

Documentation

Within EA the creation of documents is seen as a by-product of analysis and design rather than the goal. Depending on your individual requirements for documenting, you may not need to do anything more than push a button!  

One of the challenges of a document based approach (i.e. using Word/Visio) is that it makes sharing information more difficult. 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 allows you to expose your model far and wide in a number of ways.

  • Dynamic documentation generation that allows anyone (with access to the EA repository and a copy of EA) to create up to date documentation. RTF documentation can be produced at the push of a button and is fully customisable to achieve your own branding and styling.
  • HTML - for example, you could publish your model over the Internet for external parties to see
  • XMI import/export - you can even export your model and send it to another party to import into their own copy of EA.

Built in templates exist to be able to automatically generate lots of standard types of documents.

  • Use Case Template
  • Use Case Scenario Template
  • Requirements Template

Next post I'll take a closer look at what support there is for testers.