Polarion ALM Lead​/Developer- Remote

Evaluation Area
What It Actually Means
1. Hands-on Polarion configuration and implementation

The candidate should have helped design, configure, deploy, or enhance Polarion
, rather than only using it to enter requirements or update task status. Configuration includes creating Work Item types, fields, workflows, roles, permissions, templates, link rules, notifications, and project structures. Implementation means understanding business processes, translating them into Polarion, conducting testing, deploying the solution, training users, and supporting production rollout.

The candidate should understand how customer, regulatory, system, hardware, software, calibration, and test requirements are structured and linked. They should be able to establish traceability from the original need through implementation, testing, defect resolution, and release.

The candidate should have migrated requirements, defects, tests, attachments, comments, users, relationships, and history from legacy systems into Polarion. Migration should involve data assessment, mapping, cleansing, trial loads, validation, reconciliation, cutover, and post-production support.

The candidate should know how Polarion is used for test-case creation, test planning, execution, defect management, formal reviews, electronic approvals, audit trails, and release evidence. They should understand the connection between requirements and verification not not defect tracking.

The candidate should understand how Polarion exchanges information with PLM, source-control, Dev Ops, modeling, testing, and collaboration tools. This may involve REST APIs, SOAP services, OSLC, ReqIF, webhooks, middleware, or file-based integrations.

The candidate should understand product-engineering processes and be able to work with systems, embedded-software, hardware, calibration, testing, quality, PLM, and program teams. They should also have experience taking a solution from workshops through deployment and adoption.