System Element Status

​

Overview

The System Element Status enumeration implements a formal change control workflow for system architecture elements. It supports eight distinct states that guide elements from initial conception through approval, obsolescence, or rejection. This enumeration is critical for ensuring only approved architectural components are baselined and traced to downstream design requirements and FMEA analysis.

​

Status Lifecycle Diagram

​

Property Reference

​

Enumeration Values

​

Draft

Purpose: Initial status for newly created system elements under development. Usage: Assign Draft status when:

• System element is first created and architecture is not yet finalized
• Element decomposition and interface definitions are still being refined
• Element should not be baselined or used for downstream traceability

Workflow Transition:

• Automatically assigned when creating a new System Element work item
• Transitions forward to: In Progress
• Transitions backward from: In Review, Pending Approval, Approved, Rejected

Notes: Draft elements are excluded from formal traceability reports and do not trigger approval notifications. Use Draft for exploratory architecture work before formal design review gates.

---

​

In Progress

Purpose: Status indicating active development work on system element specifications. Usage: Assign In Progress status when:

• System element definition is actively being worked on by architecture team
• Specifications, interface requirements, and decomposition are being refined
• Element is not yet ready for peer review
• Element appears in work-in-progress (WIP) dashboard KPIs

Workflow Transition:

• Transitions forward to: In Review
• Transitions backward to: Draft
• Transitions forward from: Draft

Notes: In Progress elements may appear in dashboard “Active Work” sections and trigger assignee notifications. This state supports tracking active architectural development effort.

---

​

In Review

Purpose: Status indicating the system element is undergoing peer or technical review. Usage: Assign In Review status when:

• System element has completed initial specification and is ready for review
• Technical review process is initiated (e.g., architecture review board assessment)
• Element requires peer approval from architecture team members
• Element should appear in “Pending Review” dashboard sections

Workflow Transition:

• Transitions forward to: Pending Approval
• Transitions backward to: In Progress, Draft
• Forward requires assignee to be set (enforced by workflow engine)

Review Gates: In Review is a quality gate—elements cannot proceed without documented review feedback. Review may result in:

• Approval pathway: In Review → Pending Approval → Approved
• Rework pathway: In Review → [reopen] → Draft or In Progress

Notes: In Review elements trigger notifications to assigned reviewers and appear in role dashboards with pending action indicators.

---

​

Pending Approval

Purpose: Status indicating the system element has passed review and awaits formal approval. Usage: Assign Pending Approval status when:

• System element has completed peer/technical review without major issues
• Element is ready for formal sign-off from architecture lead or safety manager
• Formal approval gate is being executed (approval signatures being collected)
• Approver list is being determined for formal voting

Workflow Transition:

• Transitions forward to: Approved
• Transitions backward to: In Review, In Progress, Draft
• Forward requires resolution field to be set (documents reason for closure)
• Automatically invokes AddDefaultApprovals() function to assign project_approver role members

Approval Mechanics: Pending Approval uses Polarion’s signature-based approval:

• Approval Condition: At least one approver must approve AND no approvers can disapprove
• Auto-assigned Approvers: Members with project_approver role for the System Element work item type
• Voting: Approvers vote individually; the system tallies votes and locks when condition is met
• Signature Widget: Approval votes appear in Polarion’s signature widget on the work item form

Notes: Elements in Pending Approval typically appear in “Awaiting Approval” KPI cards and trigger daily reminders to approvers. This is the final gate before baseline.

---

​

Approved ✅

Purpose: Status indicating the system element has received formal approval and is baselined. Usage: Assign Approved status when:

• System element has received all required approvals (signatures collected)
• Formal baseline is established for the architectural component
• Element is ready for downstream design decomposition and traceability
• Element is locked for modification without change control (optional, per project policy)

Workflow Transition:

• Cannot transition backward without formal change control reopen (usually via change request)
• Automatically locks signatures to create audit trail
• May trigger update to project baseline documents or configuration management system

Downstream Impact:

• Approved elements can be used as source for traceability links in PowerSheet views
• Approved elements appear in formal traceability reports and coverage analysis
• Approved elements are protected from accidental modification (form may become read-only)
• Downstream Design Requirements and FMEA analysis can reference approved elements

Notes: The Approved state represents the boundary between architecture design and detailed design. Once approved, system elements form the stable architecture baseline upon which the V-model verification and validation is built.

---

​

Rejected ❌

Purpose: Status indicating the system element was rejected during review or approval. Usage: Assign Rejected status when:

• System element fails peer review or technical assessment
• Element does not meet architectural requirements or quality standards
• Element requires significant rework before re-submission
• Element is permanently not suitable for the design (architectural decision changes)

Workflow Transition:

• Transitions backward to: Draft (must reset to Draft before re-submission)
• Requires resolution field to be set (documents reason for rejection)
• Clears all approval signatures when transitioning to reopen

Rework Process:

• Author reviews rejection reason (from resolution field) and closes element
• Element returns to Draft status and is reopened for modification
• Author addresses feedback and re-submits to In Progress
• Element re-enters review cycle starting from In Review

Notes: Rejected elements appear in “Rework Required” dashboard sections and trigger notifications to element authors. Rejection provides formal documentation of why an architectural component was not approved, creating audit trail for compliance.

---

​

Obsolete

Purpose: Status for system elements that are no longer valid due to architectural changes or scope reduction. Usage: Mark as Obsolete when:

• System element is superseded by a different architectural approach
• Architectural scope is reduced and element is no longer needed
• System hierarchy is reorganized and element is consolidated into parent
• Legacy architecture elements are archived during design evolution
• Baseline snapshot requires retention but element is no longer in active use

Workflow Transition:

• Typically final state; transitions backward to Draft if element needs to be revived
• Requires resolution field to be set (documents reason for obsolescence)
• Does not automatically clear approvals (retains baseline audit trail)

Filtering Behavior:

• Obsolete elements are typically filtered out of active PowerSheet views and dashboard displays
• Obsolete elements are excluded from traceability reports and coverage analysis (per filter configuration)
• Obsolete elements are retained in historical baseline documents for audit trail and baseline comparison
• Obsolete elements may still appear in “Baseline Evolution” or “Architecture History” reports

Notes: Obsolescence is distinct from rejection—an element may be technically sound but no longer needed due to architectural changes. Marking elements as Obsolete rather than deleting them preserves the design history and enables comparison across baseline versions.

---

​

Color Coding and Visual Indicators

System Element Status uses a standard color scheme that appears consistently across Polarion forms, PowerSheet views, and dashboard widgets:

​

Workflow State Transitions

System Element Status follows a formal workflow managed by the system element workflow engine. Below are the allowed transitions:

​

Forward Progression (Normal Workflow)

• Draft → In Progress: Manual transition when active work begins
• In Progress → In Review: Manual transition when ready for review
• In Review → Pending Approval: Manual transition after review completion
• Pending Approval → Approved: Automatic when approval condition is met (all signatures collected)

​

Backward Transitions (Rework, Reopening)

• Reopen to Draft: Clears all approvals and resolution; invalidates signatures
• Backward Transition: Triggered by workflow reopen action; cascades to linked items per MarkWorkflowSignaturesAsObsolete() function

​

End-of-Life States

• Reject: Failed review/approval; requires resolution field; triggers rework
• Obsolete: Architectural decision change; retains baseline history; excludes from active views

​

Assignee Requirements

The system element workflow enforces assignee requirements for state transitions: Bulk Assignment: Use PowerSheet bulk-edit feature to assign multiple system elements before transitioning them forward in workflow.

​

Integration with RTM Model

System Element Status impacts traceability and configuration management:

​

Related Enumerations and Work Items

Related Enumerations:

• Design Requirement Subtype — Classifies design requirements that decompose from system elements
• Action Priority (H/M/L) — Prioritizes rework when system elements are rejected

Related Work Item Types:

• System Element — Uses this enumeration as primary status field
• Design Requirement — Decomposes from Approved system elements
• Function — Allocated to system elements in architecture hierarchy

Related Concepts:

• System Element Hierarchy — Architecture decomposition using system elements
• V-Model Methodology — System element approval is baseline gate before design phase

​

Best Practices

• Use Draft for Exploration: Create system elements in Draft status during early architecture workshops to capture options without formal commitment.
• Transition to In Progress Before Assignment: Mark elements In Progress once assignment is clear and active work begins; this signals the architecture team that work is underway.
• Document Rejection Reasons: When rejecting elements, use the Resolution field to document specific feedback (e.g., “Interface definition incomplete”, “Performance requirements not met”). This guides authors in rework.
• Baseline Approved Elements: Treat the transition to Approved as a formal baseline event. Consider locking approved elements from modification or requiring change requests for downstream edits.
• Archive, Don’t Delete: Mark redundant elements as Obsolete rather than deleting them. This preserves design history for baseline comparison and regulatory audit trails required by ISO 26262.
• Monitor Pending Approvals: Use the “Pending Approval” dashboard KPI to track elements awaiting sign-off. High pending counts may indicate approval bottlenecks.
• Cascade Rework: When reopening an Approved element due to design changes, verify that linked downstream items (Design Requirements, FMEA) are also reopened or updated. Use the dependency traversal feature to automate this.