The weak point of Polarion ALM software is about reporting and time for extraction of the data included in the database to communicate with the regulatory authority. Polarion did not understand that its user just wanted the reports to be submitted in a better way.

So about the improvement needed for the entire Polarion software, I spoke several times about the difficulties of the company working with a fixed standard with a document that is 500 pages, and you get this with a PDF. Also, each line of the standard will be connected to risk analysis. So the improvement I proposed is to transfer the PDF document and pages inside the database directly to be able to use each pair with the database tools. So what I saw is that Aligned Elements proposed this but never maintained this correctly, so it was useless since data was changing very often. The database standard will be very useful for doing the safety report and everything. In fact, with what is coming for the regular database, they need to add on the database format. So this is a change that happened now. So, how to integrate these changes inside the software is new. The EDR software will be software that includes thousands of standard insights in a database and maintains them correctly.

My customers were complaining about the quality of the report. The quality of reporting needs to improve.

At the moment, I haven't looked in-depth into what needs improvement in the product. Based on my understanding, the tool's integration capabilities with multiple tools is an area of concern that Polarion needs to focus on more. Polarion ALM's features should be communicated easily with other tools as well. My company developed and built up some areas in Polarion ALM, because of which we are able to communicate its features with the other tools we use, but in general, everywhere, it is quite difficult to do it, mainly on the side of Azure DevOps. If you just look at Azure DevOps, it is completely on CI/CD pipeline, and the development process for certain things happens in such a tool when revolving around areas, like Sprint, Scrum, and Kanban, that fall under agile methodologies and not there in ALM, making it an area Polarion needs to build. Otherwise, Polarion ALM should be able to integrate with multiple tools and make the overall functioning feel much better.

The solution's editing capabilities need improvement.

I would like the traceability and the generation of trace matrices beefed up. Felix ALM had a very flexible and powerful trace matrix capability, that Polarion ALM doesn't have. Currently, we have a person that writes scripting to do trace matrices across requirements tests, and different versions. 

The solution has a real problem when we have two or more people working on the same document with different WIs. in Polarion ALM, we have no way of knowing if someone else is using the same document until we try to exit because a notification pops up indicating someone else is working on the document. If we exit, we potentially will override their work and will have to go into the history to reconsolidate the document." The solution only indicates that someone else is also accessing the document once we have completed our work and it does not provide any information about who it is which makes things even more complicated when trying to consolidate the document.

It is an effective solution to improve development processes with a single, unified platform requirements, coding, testing, and release. Nevertheless, the user interface is not yet optimized. Import functions could be improved also to make the upload of structured requirement documents easier and to import those into the database. It works yet requires effort during customization. Future versions should support better workflows and task management.

We use PTC Windchill, and Polarion ALM doesn't have native integration, so we had to purchase the connector to integrate it with Polarion ALM. We still haven't implemented it.

The planning and task management aspects of the solution were not that easy.

It is a bit complex to set up.

One of Polarion's shortcomings would be planning. It can handle plans, but the planning feature is very basic. There are third-party solutions that could be easily incorporated or built into the license. They have plugins they developed only after many customers complained about Polarion's integration with third-party repositories. Some of the repositories aren't working all the time. So it works when you set it up, but it stops working after a while, and there is nothing you can do except reset the whole server and try it again. So it's not a convenient way to deal with those issues because the solution should be up 99.9% of the time.

Another issue is Polarion's integration with external tools, including repositories for source code, mechanical design, electrical designs, etc. There should be out-of-the-box integration with different tools like Jira or things of that nature. Some of this functionality exists, but it's not so easy to set up. Polarion ALM needs more integration with external repositories, especially for source code. Most of these tools don't recommend using Polarion ALM as a repository, so you have to use Search Party or a different tool for that. And integration is not straightforward or not easy to do. 

The solution can be improved by making it more user-friendly, and a server-based application rather than client based. I find it difficult to update the test cases in the test run and would like a more simplistic process. As an example, If I create version one of the test case. And in a test run, I add that version one of the test cases in the test run and I go to that test case and update it to version two, I can update that fine, but in the test run, it is not automatically updated to version two.

The tool needs to improve its planning. It also needs to add more integrations. 

As Polarion ALM is a development-oriented tool, easy support or easy access is provided by default, but if I want to use detailed features, I need to write the script, particularly the VM script, and this is its area for improvement. I want Polarion ALM to have a graphical user interface that doesn't need scripting.

In the next release of the tool, I'd like for it to not require scripting and programming because needing to run script language is time-consuming.

The solution needs to improve its user experience and graphics.

This is an area that has already been corrected, but the Navigation areas of the document and being able to have subdocuments was an area that needed improvement.

Technical support needs some improvement.

The pricing could be reduced. If the pricing would come down and it was more affordable then we wouldn't have to switch.

The ease-of-use could be improved a little, but at the same time, it's a complex tool so that has to be expected; such a complex tool cannot be completely straightforward. 

The license model is okay for large companies but would be quite expensive for smaller enterprises.

Also, the beginner's tutorials are quite outdated — working on versions from 2010 or 2012. More up-to-date tutorials with different use cases would be a nice adjustment.

It's always possible to improve such tools by adding more features and improving automatization. For example, we never tried the connection to build service. I believe it's possible to do that, to automatically link it to the software build process. We only used it more or less manually. It's possible that, that feature could be improved because I believe there was a reason why we didn't do it, but I can't explain in more detail as I was not really involved in the process.

In general, I would like to see improvements on the information and materials.

The interface for this solution needs to be made more user-friendly to provide a better user experience.

If we have too many work items in one LiveDoc then usage can be limited because the loading times are very slow.

In the next release of this solution, I would like to see the limitations removed.

There should be a better facility for importing, such as from an IBM Rational Doors document.

The configuration would be much simpler if it had limited functions for synchronizing with JIRA, for example.

The most important thing for them to improve should be platform-independent features. They should also provide extensive pipelines and release pipelines that we can define and we can work on. 

Another area of improvement is integration with external tools and external platforms like Linux, Mac, and other stuff. Most of the teams are basically moving towards faster development. Everything should be flexible. All the tasks you can see in AWS and Azure, you would just need to drag and drop and release into the pipeline.

Right now, if you can evaluate the tools, then I think that as for the cost differences and for the usability, and other things concerned, so I will rate AWS at the first, Azure second, and then Atlassian tools and then Siemens would be fourth or fifth. 

The solution is not easy to use.

The configuration aspect of the solution is not easy. A person needs a lot of programming knowledge in order to successfully handle the job.

The cost of the product is quite high. They should work to bring it down a bit so it's not on the higher end of the market.

Test management could be improved because there's only a manual process available for now.