Controlled requirement
Owner specification, applicable O-PAS requirement, project standard, approved clarification or contractual commitment.
Home › O-PAS Requirements Traceability and Verification Matrix
Requirements · Traceability · Verification · FAT · SAT · Lifecycle Evidence
O-PAS requirements traceability and verification matrix Connect every requirement to an accountable design and accepted evidence
A practical guide for owner, EPC and system-integration teams building a controlled requirements traceability and verification matrix for an O-PAS multi-vendor project.
The short answer
An O-PAS traceability matrix should show what each requirement means for the project, who owns it, where it is implemented and what evidence closes it.
Trace owner and applicable O-PAS requirements through architecture roles, exact products and versions, IEC 61131 applications, interfaces, configuration and lifecycle functions. Assign a verification method, environment, procedure, expected result, witness and acceptance authority. Keep product conformance evidence, system interoperability evidence and project acceptance evidence distinct while linking all three to the requirements they support.
01 · Traceability basis
Start with controlled requirements, not a test spreadsheet
The matrix should begin when requirements are interpreted and allocated, then mature with the architecture. Waiting until FAT turns traceability into retrospective paperwork.
Project interpretation
Record what the requirement means for this architecture rather than relying on ambiguous source language.
Design owner
Assign architecture role, product, application, interface, service or procedure.
Accountable party
Name who designs, supplies, configures, verifies, corrects and accepts.
Closure method
Inspection, analysis, product evidence, demonstration, test, FAT, SAT or operating evidence.
Accepted record
Link the executed result, defect disposition, deviation and approval.
Traceability stop condition: the project has hundreds of test steps but cannot show which contractual requirements those tests close or which requirements still have no verification method.
02 · Requirement sources
Preserve source and interpretation separately
| Source | Matrix treatment |
|---|---|
| Owner specification | Retain source identifier and exact contractual revision. |
| O-PAS requirements | Record applicable edition/profile basis and project applicability. |
| Clarifications | Link approved responses that modify or interpret the bid basis. |
| Supplier commitments | Capture awarded technical commitments, evidence and accepted alternatives. |
| Design decisions | Derive controlled project requirements where architecture choices create necessary behavior or evidence. |
| Change control | Maintain supersession and impact history when requirements change. |
Use the O-PAS Profiles and Project Requirements Guide to establish the applicability basis.
03 · Matrix fields
Capture enough structure to manage closure
| Field | Purpose |
|---|---|
| Requirement ID / source | Trace to the authoritative requirement and revision. |
| Requirement text / interpretation | Preserve source meaning and approved project interpretation. |
| Applicability | Applicable, not applicable with rationale, conditional or superseded. |
| Architecture allocation | Component role, product, IEC 61131 application, interface, service or lifecycle process. |
| Responsible party | Owner, EPC, integrator, supplier or other accountable role. |
| Verification method | Inspection, analysis, product evidence, demonstration or test. |
| Verification stage | Design review, integration environment, FAT, SAT, commissioning or operation. |
| Procedure / expected result | Controlled method and objective acceptance criterion. |
| Evidence record | Executed result, report, certificate/register evidence, logs or approved record. |
| Defect / deviation | Open issue, correction, exception and acceptance disposition. |
| Status / authority | Open, ready, passed, failed, accepted deviation or closed, with named authority. |
04 · Requirement allocation
Allocate requirements to the system element that must satisfy them
Component requirement
Exact product/version capability and applicable evidence.
IEC 61131 behavior
Control logic, sequence, alarm, interlock, runtime and deployment requirements.
Boundary behavior
Information, commands, state, quality, security, failure and restoration.
Integrated behavior
Interoperability, performance, resilience, recovery and system-management functions.
Installed environment
Field equipment, retained systems, facility services and operating conditions.
Owner capability
Source, configuration, monitoring, backup, support, replacement and change governance.
Use the O-PAS Architecture and Component Roles Guide to keep allocation independent of supplier packaging.
05 · Responsibility
Every requirement needs a delivery owner and an acceptance authority
The party supplying evidence is not necessarily the party accountable for integrated closure.
| Role | Traceability responsibility |
|---|---|
| Owner/operator | Owns contractual requirement intent, applicability decisions, deviations and final acceptance authority. |
| EPC/project team | Maintains contractual traceability, schedule integration, supplier deliverables and project closure. |
| System integrator | Allocates integrated technical requirements and coordinates cross-supplier verification and correction. |
| Component supplier | Provides accurate product evidence and verifies assigned product requirements. |
| Test authority | Controls procedures, witnesses, results, defects and evidence quality. |
Use the O-PAS Responsibility Matrix to make allocation contractual.
06 · Verification methods
Select the method that proves the requirement
| Method | Use |
|---|---|
| Inspection | Identity, installation, configuration, documentation or visible implementation. |
| Analysis | Capacity, architecture, cybersecurity, performance or other requirement supported by controlled engineering analysis. |
| Product evidence | Applicable product conformance or supplier evidence for the exact offered product/version and stated scope. |
| Demonstration | Observable workflow or lifecycle capability where measured test data is not the primary criterion. |
| Test | Defined inputs, conditions and expected results demonstrating functional, interface, failure, recovery or performance behavior. |
07 · Evidence layers
Keep product conformance, system interoperability and project acceptance distinct
Conformance evidence
Supports applicable requirements within the evaluated product scope. Record exact identity, scope and limitations.
Interoperability evidence
Shows selected products, applications, interfaces and services working together under project configurations and scenarios.
Acceptance evidence
Shows the delivered system satisfies contractual functional, site, lifecycle and operating requirements.
Evidence rule: never close a project interoperability requirement solely because each component has applicable product evidence.
08 · Verification stage
Close each requirement at the earliest valid stage
| Stage | Typical closure |
|---|---|
| Design review | Architecture, allocation, calculations, product selection and documented configuration decisions. |
| Integration environment | First-of-kind interfaces, IEC 61131 deployment, system services, failure behavior and correction. |
| FAT | Integrated functional, interoperability, cybersecurity, failure, recovery and lifecycle scenarios available before shipment. |
| SAT | Installed architecture, real field/retained-system interfaces and facility services. |
| Commissioning | Process-connected operation, cutover, startup and site-specific operating behavior. |
| Operational demonstration | Requirements that require sustained operation, support workflow or lifecycle evidence unavailable earlier. |
Use the O-PAS Project Schedule and Integration Milestone Planning Guide to connect evidence maturity to project gates.
09 · Evidence closure
A passed test is not closed traceability until the evidence is controlled
Confirm requirement and revision
Verify that the executed evidence addresses the current controlled requirement.
Confirm baseline
Record exact products, versions, configuration, applications and environment represented.
Execute the approved method
Use controlled procedure, expected result, data and witness requirements.
Record actual result
Preserve objective evidence rather than only pass/fail status.
Disposition defects and deviations
Link correction, retest, accepted exception or residual risk.
Accept and close
Named authority confirms the evidence satisfies the requirement.
10 · Change impact
Use traceability to select regression after change
When a product, interface, IEC 61131 application, configuration or requirement changes, use matrix relationships to identify directly affected requirements and credible downstream dependencies.
Find allocated requirements
Identify every requirement assigned to the changed configuration item.
Trace indirect effects
Follow interfaces, applications, shared services and operating consequences.
Assess retained validity
Determine which prior evidence remains valid and which must be repeated.
Select tests
Build proportionate regression from affected requirements and failure paths.
Close the new baseline
Update evidence and acceptance status before operational release.
Preserve supersession
Keep prior requirement/evidence relationships traceable for lifecycle decisions.
Use the O-PAS Configuration Management, Change Control and Regression Testing Guide for lifecycle impact assessment.
11 · Lifecycle traceability
Keep the matrix useful after project handover
The accepted matrix should become part of the owner baseline so later patches, component replacements, application changes, recovery tests and technology refreshes can reuse project evidence instead of reconstructing it.
| Lifecycle event | Traceability use |
|---|---|
| Patch/update | Identify requirements and regression affected by software or firmware change. |
| Component replacement | Compare replacement against role, interface, application and lifecycle requirements. |
| Application release | Trace changed IEC 61131 functions to required functional and regression evidence. |
| Recovery exercise | Confirm recovery requirements still have current procedures and demonstrated evidence. |
| Retirement | Identify requirements, dependencies and records affected when a function is removed. |
12 · Matrix governance
Control the matrix as a project record
Named custodian
Own structure, identifiers, revisions, status rules and controlled exports.
Regular reconciliation
Review unallocated requirements, missing methods, failed evidence and overdue closure at project gates.
Owner baseline
Transfer the accepted matrix with linked evidence, open exceptions and lifecycle ownership.
13 · Connected guidance
Connect requirements to the complete evidence chain
Requirements
Profiles and Requirements
Establish applicability and project requirement layers.
ResponsibilityResponsibility Matrix
Assign delivery and acceptance ownership.
InterfacesBoundary Management
Trace interface requirements to providers and consumers.
FATFAT and Interoperability
Execute integrated verification and evidence.
SiteCommissioning and SAT
Close site-dependent requirements.
LifecycleSystem Management
Preserve accepted evidence through operation and change.
Frequently asked questions
O-PAS requirements traceability questions
What should an O-PAS requirements traceability matrix contain?
At minimum: requirement source and revision, project interpretation, applicability, architecture allocation, responsible party, verification method and stage, procedure or expected result, evidence record, defect/deviation status and acceptance authority.
Should product conformance evidence close project interoperability requirements?
No. Product conformance evidence supports requirements within its evaluated product scope. System interoperability and project acceptance require project-specific integrated evidence.
When should the traceability matrix be created?
During requirements interpretation and architecture development, before formal testing. It should mature with design, procurement, integration, FAT, SAT and commissioning rather than being assembled retrospectively.
How should IEC 61131 application requirements be traced?
Allocate functional, sequence, alarm, interlock, runtime, deployment, portability and recovery requirements to controlled application assets and link them to the appropriate integration, FAT, SAT or regression evidence.
Can the matrix be used after handover?
Yes. The accepted matrix can support impact assessment and regression for patches, component replacement, IEC 61131 application releases, recovery exercises and retirement.
How does CSI support O-PAS requirements traceability?
CSI helps owners and EPCs structure requirements, establish applicability, allocate architecture and supplier responsibility, define verification methods, connect FAT/SAT evidence and establish a lifecycle-ready accepted matrix.
Before FAT becomes a disconnected collection of test steps
Build one evidence chain from requirement to acceptance
CSI can help owner and EPC teams structure requirements, allocate responsibility, define verification methods and build a traceability matrix that remains useful through FAT, SAT and lifecycle change.
O-PAS™ and Open Process Automation™ are trademarks of The Open Group. CSI is an independent commercial licensee of the O-PAS Standard. This guide is a project and lifecycle planning aid and does not imply endorsement by The Open Group. The applicable contract, owner requirements, current O-PAS Standard, approved project procedures and current certification records govern the project.