This glossary defines 60 terms in four areas: Polarion features such as work items, LiveDocs and save hooks; lifecycle and traceability concepts; validation vocabulary such as CSA and IQ/OQ/PQ; and the regulations and standards used in medical device, automotive, aerospace and oil and gas programs. Where a topic has its own page on this site, the definition links to it.
0–9
21 CFR Part 11
The US FDA regulation that sets the criteria under which electronic records and electronic signatures are treated as trustworthy, reliable and equivalent to paper records and handwritten signatures. It covers controls such as system validation, secure computer-generated audit trails, limited system access and signature manifestations. In Polarion, Part 11 support comes from the configuration of electronic signatures, workflows, permissions and revision history, which the regulated company then validates. See Part 11 validation.
21 CFR Part 820
The FDA regulation that sets quality management system requirements for medical device manufacturers. Until February 2, 2026 it was the Quality System (QS) Regulation; from that date the amended version, the Quality Management System Regulation (QMSR), applies. See QMSR.
A
Agile Release Train (ART)
In the Scaled Agile Framework (SAFe), a long-lived team of agile teams that plans, commits and delivers together on a shared cadence toward a common mission. An ART is usually aligned to a value stream and plans its work in joint PI planning events. See our webinar on SAFe and ART setup.
ALM (Application Lifecycle Management)
The practice and tooling for managing a product's requirements, design, development, testing, release and maintenance as one connected record. In regulated engineering, ALM provides the traceability between these artifacts and the evidence that auditors and assessors expect. See Why ALM? and The ALM Wheel.
ARP4754A
SAE guidelines for the development of civil aircraft and systems, published jointly with EUROCAE as ED-79A. It covers the system-level development process, including requirements capture and validation, verification, configuration management and development assurance. Revision B (ARP4754B / ED-79B) was published in December 2023. See aerospace and defense.
ASIL (Automotive Safety Integrity Level)
The risk classification defined in ISO 26262. Each hazardous event is rated for severity, exposure and controllability, which gives ASIL A (lowest) to ASIL D (highest), or QM (quality management) where no ASIL is required. The ASIL sets the rigor of the safety requirements and of the methods used to meet them.
Audit Trail
A secure, time-stamped, computer-generated record of who created, changed or deleted a record and when. Part 11 requires that audit trail entries leave previously recorded information visible. Polarion keeps a revision history for work items and documents that supports this requirement.
Automotive SPICE
A process assessment model used to evaluate the capability of system and software development processes at automotive suppliers, published by the VDA Quality Management Center. Its system engineering (SYS) and software engineering (SWE.1 to SWE.6) processes require consistency and bidirectional traceability between work products. See automotive.
B
Baseline
A named, frozen reference to the state of a project or document at a specific revision. Baselines let teams see what changed between releases, reproduce what was approved and supply evidence for reviews. In Polarion a baseline points to a repository revision, so its historical content can be opened later. Our Redline Report Widget compares baselines to produce change reports.
C
Change Request
A formal record that proposes a modification to a controlled item such as a requirement, design or document. It usually captures the reason for the change, the impact analysis, the approval decision and links to the items changed. In Polarion, change requests are typically a work item type with their own workflow and links to the affected items.
Collection
In Polarion, a named set of specific document revisions grouped for a release, review or submission. A collection fixes which version of each document belongs together, so the package can be reviewed, approved and referenced as one unit.
Computer Software Assurance (CSA)
FDA's risk-based approach to establishing confidence that software used in production or the quality system is fit for its intended use. FDA issued its final guidance, Computer Software Assurance for Production and Quality System Software, in September 2025. CSA concentrates assurance effort on features with high process risk and allows unscripted or exploratory testing where risk is lower. See our article on CSA for Polarion.
Computer System Validation (CSV)
Documented evidence that a computerized system used in a regulated process consistently does what it is intended to do. Traditional CSV relies on a validation plan, specifications, scripted IQ/OQ/PQ protocols and a summary report. Many organizations now apply the risk-based principles of CSA to scale that effort to the risk of each function.
CVSS (Common Vulnerability Scoring System)
An open framework, maintained by FIRST, for rating the severity of software vulnerabilities on a scale from 0.0 to 10.0. Versions 3.1 and 4.0 are both in current use. Medical device and automotive cybersecurity processes often record a CVSS score with each vulnerability. Our CVSS Calculator (coming soon) brings CVSS 3.1 scoring into Polarion.
D
Design Control
The quality system requirements that govern how a medical device is planned, specified, designed, reviewed, verified, validated, transferred and changed. Under the QMSR these requirements come from clause 7.3 of ISO 13485:2016; under the former QS Regulation they were set out in 21 CFR 820.30. ALM tools support design control by linking design inputs, outputs, reviews and verification evidence. See medical devices.
Design History File (DHF)
The compilation of records that describes the design history of a finished medical device, including plans, inputs, outputs, reviews, verification, validation and design changes. The term comes from the former 21 CFR 820.30; ISO 13485:2016, which the QMSR incorporates, calls the equivalent records the design and development file (clause 7.3.10). When these records are linked items in an ALM system, the file can be produced from current data.
Design Input
The physical and performance requirements of a device that serve as the basis for its design, derived from user needs and intended use. Design inputs should be complete, unambiguous, verifiable and free of conflicts with each other. Each input is later traced to the design outputs and verification activities that address it.
Design Output
The results of the design effort at each phase and at the end of design, such as specifications, drawings, software and labeling. Design outputs are verified against the design inputs and form the basis for production. Traceability from inputs to outputs is a core part of design control evidence.
Development Assurance Level (DAL)
The level of rigor assigned to airborne systems, software or hardware according to the most severe failure condition they can contribute to, from Level A (catastrophic) to Level E (no safety effect). ARP4754A assigns development assurance levels to functions and items, DO-178C calls the equivalent for software the software level, and DO-254 uses the design assurance level. Higher levels require more objectives and more independence in verification.
DevOps
A set of practices that brings development and operations together through automation, continuous integration and delivery, and fast feedback. In regulated settings, DevOps pipelines are connected to the ALM system so that builds, test results and releases stay traceable to requirements. See our Pragmatic DevOps webinar.
Digital Thread
A connected flow of data that links a product's information across its lifecycle, from requirements and design through manufacturing and service. Connecting ALM, for example Polarion, with PLM, for example Teamcenter, is a common building block of a digital thread. See scripting and integration.
DO-178C
Software Considerations in Airborne Systems and Equipment Certification, published by RTCA and, as ED-12C, by EUROCAE. It defines objectives for airborne software planning, development and verification, scaled by software level from A to E. It calls for traceability between system requirements, software requirements, source code and tests. See aerospace and defense.
DO-254
Design Assurance Guidance for Airborne Electronic Hardware, published by RTCA and, as ED-80, by EUROCAE. It applies a lifecycle and objectives-based approach to complex electronic hardware such as FPGAs and ASICs, scaled by design assurance level. Requirements-based verification and traceability are central to it.
DOORS Classic
The common name for IBM Engineering Requirements Management DOORS, a long-established requirements tool with a desktop client and its own database. Requirements are stored as objects in modules, links connect objects across modules, and DXL is used for scripting. See DOORS migration.
DOORS Next
IBM Engineering Requirements Management DOORS Next, a web-based requirements tool that is part of the IBM Engineering Lifecycle Management suite and uses OSLC for integration. It is a separate product from DOORS Classic with a different data model, so moving between them is a migration. See Polarion vs DOORS Next.
E
Electronic Signature
Under 21 CFR Part 11, a signature applied through a computer system that is intended to be the legally binding equivalent of a handwritten signature. The signed record must show the signer's printed name, the date and time, and the meaning of the signature, such as review or approval, and the signature must be linked to its record. Polarion supports electronic signatures on workflow transitions for work items and documents.
F
FRS (Functional Requirements Specification)
A document that describes what a system must do to meet the user requirements, including its functions, data, interfaces and behavior. In computer system validation, the FRS is typically verified through operational qualification (OQ) testing.
G
GraalJS
A JavaScript engine that runs on GraalVM and the Java platform and implements the ECMAScript specification. Polarion uses GraalJS for JavaScript workflow scripts and save hooks, following the removal of the Nashorn engine from newer Java versions. See workflow scripts and save hooks.
I
IEC 61511
The international functional safety standard for safety instrumented systems in the process industry sector, including oil and gas, chemicals and refining. It covers the safety lifecycle from hazard and risk assessment and SIL determination through design, operation, maintenance and modification. See oil and gas.
IEC 62304
The international standard for medical device software lifecycle processes, covering development, maintenance, risk management, configuration management and problem resolution. It assigns software a safety class based on the harm that could result from a failure, after risk controls outside the software are considered: Class A (no injury or damage to health possible), Class B (non-serious injury possible) or Class C (death or serious injury possible). The class determines which activities and documentation are required.
IMDRF AE Codes
Adverse event terminology and codes published by the International Medical Device Regulators Forum for reporting incidents involving medical devices. The codes describe device problems, investigation findings, health effects and device components in a harmonized way, and regulators use them in adverse event and vigilance reporting. See our IMDRF webinar.
Impact Analysis
The assessment of which items a proposed change affects, such as linked requirements, designs, risks, tests and documents. With traceability links in place, an ALM tool can list the affected items directly from the link structure. The result feeds the change request decision and the plan for re-verification.
IQ/OQ/PQ
Installation, Operational and Performance Qualification, the three classic stages of validation testing. IQ confirms the system is installed as specified, OQ confirms it operates according to its functional specification, and PQ confirms it performs as intended in the user's environment and processes.
ISO 13485
The international standard that specifies quality management system requirements for organizations involved in the design, production, installation and servicing of medical devices. The current edition is ISO 13485:2016, which the FDA QMSR incorporates by reference.
ISO 14971
The international standard for applying risk management to medical devices. It defines a process to identify hazards, estimate and evaluate risks, implement and verify risk controls, evaluate residual risk and monitor production and post-production information. The current edition is ISO 14971:2019.
ISO 26262
The international functional safety standard for electrical and electronic systems in series production road vehicles. It defines a safety lifecycle from concept through production, uses ASILs to scale requirements, and expects traceability from safety goals to safety requirements, design and verification. See automotive.
ISO/SAE 21434
The international standard for cybersecurity engineering of road vehicle electrical and electronic systems, published in 2021. It covers cybersecurity management, threat analysis and risk assessment (TARA), and cybersecurity activities across the vehicle lifecycle.
L
Link Role
In Polarion, the named type of a link between two work items, such as parent, relates to or verifies. A link role has a meaning in each direction and can be limited to certain work item types. Traceability reports and coverage queries are built on link roles.
LiveDoc
Polarion's structured document, shown as Documents in the Polarion interface. Each requirement, test or other element in it can be a work item with its own fields, workflow and links. Teams read and edit a LiveDoc as a document while Polarion tracks every item individually, which keeps document views and item-level traceability in sync.
LiveReport
A Polarion report page that runs its queries against repository data each time it is opened, so the content reflects the current state of the project or a selected baseline. LiveReports are built from widgets, Velocity scripts or both. See our Velocity widget tutorial.
O
OSLC (Open Services for Lifecycle Collaboration)
A set of open specifications, maintained as an OASIS Open Project, for linking data between lifecycle tools with web standards such as REST and linked data. OSLC lets an item in one tool reference an item in another without copying the data.
P
PLM (Product Lifecycle Management)
The management of product data such as parts, bills of materials, CAD models and engineering changes across a product's life. PLM and ALM overlap at requirements and change management, and connecting them supports a digital thread.
Polarion ALM
Siemens' browser-based application lifecycle management platform, which keeps requirements, tests, risks, defects and change management in one repository with LiveDocs, configurable workflows, traceability and reporting. Corbinsoft is a certified Siemens partner for Polarion sales and services. See our Polarion services.
Q
QMSR (Quality Management System Regulation)
FDA's amended 21 CFR Part 820 for medical device manufacturers, effective February 2, 2026. It incorporates ISO 13485:2016 by reference and replaces the former Quality System Regulation, aligning US device quality requirements with the international standard while keeping some FDA-specific requirements.
R
ReqIF (Requirements Interchange Format)
An XML-based OMG standard for exchanging requirements, with their attributes and relations, between tools and organizations. It is widely used between OEMs and suppliers, and it is one route for moving requirements from DOORS to Polarion.
Requirements Traceability Matrix (RTM)
A table that shows how each requirement links to related items, such as higher-level needs, design elements, risk controls and tests, and whether each link is covered. In an ALM tool the RTM is generated from live links, so gaps such as untested requirements appear as soon as they exist.
Rich Page
A Polarion report page assembled from configurable widgets such as tables, charts and work item lists, with optional custom widgets written in Velocity. Rich Pages are commonly used for project dashboards and traceability reports.
S
SAFe (Scaled Agile Framework)
A framework from Scaled Agile, Inc. for applying lean and agile practices at enterprise scale. It organizes teams into Agile Release Trains, plans work in fixed planning intervals and defines roles, events and artifacts from the team level up to the portfolio. See our Agile and SAFe webinar.
Save Hook
Custom logic that Polarion runs when an object such as a work item is saved, whichever action or user caused the save. Save hooks enforce rules that must hold at all times, such as field consistency, and can reject a save that breaks a rule. They are written as scripts or Java extensions; see our Java 21 Save Hook (coming soon).
SIL (Safety Integrity Level)
A measure of the risk reduction a safety function must provide, defined in IEC 61508 and applied to the process industry by IEC 61511. Levels run from SIL 1 (lowest) to SIL 4 (highest), and each sets target failure measures and the rigor of design and verification.
T
Teamcenter
Siemens' PLM software for managing product data, bills of materials, engineering change and configuration. Polarion and Teamcenter can be integrated so that requirements and changes connect to the parts and designs they affect. See Polarion implementation.
Traceability
The ability to follow the relationships between lifecycle items, forward from a need or requirement to design, implementation and tests, and backward from a test or defect to its origin. Standards such as IEC 62304, ISO 26262, DO-178C and Automotive SPICE call for it, and it is the basis for impact analysis and coverage reporting.
U
URS (User Requirements Specification)
A document that states what users and the business need a system to do, written from the user's point of view. In validation it is the starting point for risk assessment and is confirmed through performance qualification (PQ) or user acceptance testing.
V
V-Model
A development lifecycle model drawn as a V: specification and design levels descend on the left, and the matching integration and test levels rise on the right, each one verifying its counterpart. It is widely used in automotive, aerospace and medical device development because it makes the link between requirements and tests explicit.
Validation
Confirmation, through objective evidence, that a product or system meets the needs of its users and its intended use. Design validation shows that a finished device meets user needs; validation of quality system software shows that it is fit for its intended use. In short, validation checks that the right product was built.
Velocity
Apache Velocity, a Java-based template language. Polarion uses Velocity for custom report widgets, LiveReport scripting and notification templates. See our Velocity widget tutorial.
Verification
Confirmation, through objective evidence, that specified requirements have been fulfilled, for example that a design output meets its design input. Typical methods are test, analysis, inspection and review. In short, verification checks that the product was built right.
W
Work Item
The basic unit of information in Polarion, such as a requirement, risk, test case, defect or task. Each work item has a type, fields, a workflow status, links to other items and a full revision history, and it can live inside a LiveDoc or on its own.
Workflow
The set of statuses, and the allowed actions between them, that an item or document moves through, for example from draft to reviewed to approved. Polarion workflows are configured per work item type or document type and can require roles, signatures, conditions and functions on each transition.
Workflow Condition and Workflow Function
Built-in or scripted logic attached to a Polarion workflow action. A condition decides whether an action is available and should not change data; a function runs when the action is performed, for example to set fields or create follow-up items. See workflow scripts and save hooks.
Definitions are summaries for orientation. For compliance decisions, refer to the current text of the regulation or standard and to the guidance of the authority that applies to your product.