As a software architect and developer I’ve used Enterprise Architect (EA) from Sparx Systems 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.
__________________________
Suzuki Radiator
