The goal of this section is to collecte as many feature requests as possible and group them into topics that make sense as a whole. Grouping them by use case could also be a potential reusable material for the "Tips & Tricks" website section. The idea being to see the whole enterprise and thus focus on several workflows/use cases Architects develop around Archi.

Please read the guidelines before contributing.

If you want to discuss some potential edits before doing them, you can use the discussion page.

I'm basically copying here all answers I got to my posts on LinkedIn and Archi's user forum. This will obviously take some time to make all this digest. Jean-Baptiste Sarrodie (17/3/2014)

This is the default category used when collecting information from various sources

• Rationale: This will allow team to collaborate on a common models set. Models in repository are easy to be integrated, exported, imported, analyzed, reported and trustworthy.
• Use cases: Team cooperation
• Description:
• Need collaborations and Versioning.
• A repository with 'tagging' so that multi-version models and model elements can be maintained. This will allow for multiple versions of a model to be in production at any point-in-time.
• Secondly, any quantitative performance analysis of models as they are adapted will be more easily compared against performance analysis of past models, for example, if particular bottlenecks in different tagged versions are able to be compared (the Properties of the Elements can be captured n the repository at each point-in-time based on the 'tags', and these Properties could hold Response Times, Frequency of events being triggered, etc.). See this post on LinkedIn

This has to be sorted/split

• Rationale:
• Use cases:
• Description:
• Ability to change the start/end position of a relationship "line" within the concept symbol. Another small improvement to the UI would be that when I have manually changed the relationship line to be angled (e.g. two 90-degree angles), and I then move one of the concepts it connects, the angles should remain unchanged.
• If Manhattan option is selected in Connection Router, then add 'handles' to relation line in order to adjust route.
• Add Print Preview to File Menu
• Add Page Orientation selection (Landscape, Portrait)
• Customizable default size for symbols in diagrams when pulled from the palette.
• A "replace" function to go along with "search".
• Add the following standard attributes to elements, relationships, and connectors: timestamp and user initials for creation, timestamp and user initials for last update. These would be displayed on the Main section of the Properties tab. The user initials could be saved in the preferences.
• Manual addition of user-defined properties is time-consuming and error-prone. It would be helpful if, for example, a set of properties could be defined for a folder and each new element added to the folder automatically inherited them. Other option: re-usable Property templates.
• Controlled manipulations: merge and split operations, type change - so I can change the type of an object, merge two objects, make two connected objects from one... This includes promotion of objects from the Sketch views and Canvases. And why not use model objects in Sketch Views and Canvases.
• Present all relations in navigators and magic connector without regard to direction (so I stand on one object and choose either "uses" or "used by", or similar).
• Copy views between one model to another model
• Merging two elements together (to remove duplicates elements e.g.)
• Find items / relationships / models with property values
• The searchbar should search into properties keys and values
• Add left and right scroll to SHIFT-MOUSEWHEEL-DOWN and SHIFT-MOUSEWHEEL-UP respectively. This is common to Visio, Adobe and other tools.

• This section is further worked out in: Generate Deliverables (Reporting) Requirements
• Rationale:
• Use cases:
• Description:
• Been able to produce a view centric only report with details and PDF index (Olivier_Rey@LinkedIn created such report)
• Make Jasper report use SVG/Vector Graphics
• Add option to render documentation items as Markdown in JasperReport wizard
• We should model a report structurally and semantically by defining the structure of the report (chapters, sections, sub-sections, paragraphs) and the structure of the view which this report has on the model, and the relationships between syntactical elements of the reports with the filling of content coming from the nodes navigation within the model (without forgetting the necessary definition of the initial context of the report).
• Catalogs, Reports, Matrices, based on queries: All ApplicationComponents, Flow relations with X in property Y. Maybe even diagrams that have a specification for what elements to include in the form of a query: A Collaboration View including everything tagged as "ToBe"

• Rationale:
• Use cases: CMDB synchronization
• Description: Import capability with possibility to customize the import with data mapping is a key.

• Rationale:
• Use cases:
• Model analysis.
• Locate and report unused objects.
• Heatmaps
• CMDB synchronization.
• Scripts in read only mode. This would be mainly for extraction/reporting purposes, offering a similar feature as what BIZZdesign Architect include. No issues with undo/redo stack so can be seen as a potential Archi feature or plugin. If GroovyConsole doesn't integrate well with eclipse, a simple UI can be created.
• Scripts in update mode. This would be mainly for model manipulation purposes. Undo/redo stack could be an issue, so this could be (at least at the beginning) a companion tool, but not integrated into Archi itself. In this case, GroovyConsole UI is perfect so we just have to focus on EMF integration through Beans and/or EMF Builder.
• A tool for content analysis so that the result could create a color view or text view for instance : What are the application components used by this process ? what processes are impacted by a device failure ? This kind of query should be possible with any element of the base ARCHI.
• Description: After some research, it seams that groovy is a good candidate (can be used as a standalone script engine) and a cool way of doing it is through an embedded groovy console. This would allow us to work on EMF model with the help of EMF Builder and thus access all elements and properties without (to many) issues.

• Rationale:
• Use cases:
• Description:

• Rationale: Ease specialization of concepts without the need to change the meta-model.
• Use cases:
• Description:
• As of today, Archi comes with no predefined list of property name. I suggest to add one named "Stereotype". It could then be used by users to better define some concepts. The goal here is just to avoid users having to type it (and misspell it).
• Create a new option in preference to either:
  • do nothing (same as now),
  • add "<< stereotypename >>" under all figures and use concept name if no stereotype defined (this would be very close to Gerben naming suggestion to ease readability,
  • add "<< stereotypename >>" only under figures that are linked to concepts having the "Stereotype" property set.
    

• Rationale:
• Use cases:
• Description: This would then open a new tab on Archi, listing all views contained on that model. At first each view would be collapsed, but with ability to be "opened" to see a small version of the view:
  
  The pattern name would be the view name, and hovering would display the view documentation...
  With this "Pattern Library", it could then be really easy to add a whole bunch of elements and relation to a new model (without having to open a model, the view, selecting all, copying, switch to the model being edited, pasting, removing unwanted "(copy)" suffixes...).
  So basically its a kind of enhanced copy/past buffer.
  It could also be uses as a layout template. So, if you have modeled a server by hand in a certain way and it has minimally the same types of elements and relations as the one of the pattern, you could select one of the elements of what you have modelled and right click it to say “layout as pattern” further extending in a popup of all the patterns that can be used for this elements.

• Rationale:
• Use cases:
• Description:
• Use real ArchiMate figures. This would make image export more attractive.
• Filter element types through ArchiMate viewpoints. On rich models, the Visualizer output gets clutter. Been able to apply dynamic viewpoint would allow to focus on context dependent needs.
• Group elements on subgraphs based on architecture layers and use a Tree Layout Algorithm. This would allow to create a layered view.
• With all these enhancements, we could create a new concept: the "virtual view". A "virtual view" could be seen as a saved Visualizer context (selected object, rendering configuration). Of course the rendering would never be as good as a manually created view, but this could help managing big models.

• Rationale:
• Use cases:
• Description: A customizable tabular view that can display selected properties and relations between one or two types of elements. "For all Requirements, show me the content of property Name and property X", "For all Business Functions and all Actors, show me for which combinations a Assignment Relations exist". The tabular view could be editable to allow for each update of properties across many elements, or deletion of unwanted properties. The tabular view could be exportable as a rtf document.

• Rationale:
• Use cases: For example, that way a property "Plateau" could be defined with values "as-is" or "to-be". The respective viewpoint would then hide/ghost those elements that are not in the corresponding plateau.
• Description: