![]() ![]() If the source diagram is updated then this change is not always reflected in the master document. For example, diagrams are created in a separate tool and copied into a document. Maintenance Overhead – documents are often composed of artifacts from other sources.This is particularly difficult to achieve when requirements are stored in spreadsheets and use cases and business goals are contained in separate documents. For example, to trace from a system requirement all the way back to the business goal that drives it. Lack of Traceability – it should be possible to examine the relationships between the artifacts that are created as part of an analysis.It’s difficult if not impossible to search across all sources for the information you are looking for. 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. Information is Hard to Find – documents are often numerous and stored on various file systems or contained within emails as attachments.Individually these tools are great but collectively they fall short in forming a cohesive picture of the requirements and constraints of a system. They are typically seen as ‘live’ documents that gets frequently updated and distributed across teams. Spreadsheet – spreadsheets are often used to list requirements and issues.Diagrams are typically copy-and-pasted into relevant Word documents. Diagramming Tool – tools like Microsoft Visio are used to draw UML diagrams, screen mockups and a variety of custom diagrams.They are the primary mechanism for sharing information between the members of a project team. Word Processor – perhaps the most frequently used tool, word processors are used to document everything from Vision Documents to End User Requirements.So, if you’re a Business Analyst looking for a tool that can help you do your job more effectively then read on.Ī lot of the BA’s I come across have a standard set of tools they use to document the results of their analysis. For non-technical users more familiar with tools like Microsoft Office it is somewhat more intimidating. It looks like a lot of the tools they use already. User Interface – for developers the user interface of EA is extremely familiar and intuitive.It’s for the entire project team, from BA’s to Testers and even for Clients. EA is not only for people with the title ‘Enterprise Architect’. Enterprise Architect – the name itself is completely misleading.I suspect this is partly because EA is often seen as a technical person’s tool. ![]() While I’ve had some success I must admit it’s been an uphill battle. In that time I’ve spent considerable time and energy trying to get our business analysts to do the same. As a software architect and developer I’ve used Enterprise Architect (EA) from Sparx Systems ( ) for a number of years. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |