Velocize integrates with the IBM engineering environment your organization already operates. Requirements and accepted configurations can remain under IBM authority while related planning, architecture decisions, delivery, supplier participation and acceptance work continue in Velocize. The objective is a connected operating process that preserves your engineering investment.
The process works in both directions. IBM source information gives Velocize work its engineering context; authorized feedback, findings, change requests and evidence references return through the selected integration profile. A team can begin a delivery step in Velocize, continue selected work in the IBM environment and follow the returned outcome without losing the source requirement or its configuration.
What moves in each direction?
Keep the IBM environment and continue the selected process in both directions. Each action follows the target product's permissions and configured integration scope.
On narrow screens, scroll the table horizontally.
| Direction | Content | Authority and process |
|---|---|---|
| IBM → Velocize | Requirement, revision and configuration | Source authority stays in IBM; related work continues in Velocize. |
| Velocize → IBM | Authorized work or change request | The target workflow receives the permitted action and retains its approval rules. |
| Velocize → IBM | Finding, review and evidence reference | Mapped feedback gives the source owner the delivery result to review. |
| IBM → Velocize | Accepted revision and returned outcome | Impact review continues against the relevant configuration. |
What does process integration mean for an IBM ELM program?
An engineering program contains requirements, configurations, work, verification and people with different decision rights. Integration needs to carry the meaning of each handover: which requirement revision authorizes the work, who can change it, which evidence applies and who accepts the result. Velocize connects these responsibilities across the systems used by your teams.
DOORS Next can remain the authoritative requirements environment. Existing IBM work or test environments can retain their assigned responsibilities, while Velocize coordinates the selected lifecycle around them. Teams gain a shared view of dependencies and readiness without needing to relocate every specialist activity.
The integration scope identifies the actual IBM products, versions, project areas, configurations and supported operations. DOORS Next and classic DOORS have distinct interfaces; work-management, test and model tools have their own records. A round trip is configured against that environment rather than assuming all IBM products expose identical behavior.
How does an IBM requirement become actionable in Velocize?
The source identity, requirement revision, module or project context and selected configuration accompany the relationship into Velocize. A team can relate that requirement to architecture, delivery items, risks, supplier work and the evidence needed for acceptance. The IBM source remains identifiable throughout that work.
A baseline establishes the agreed reference for a delivery scope. A later stream change can trigger impact review without rewriting the meaning of the earlier accepted configuration. Teams can explain whether a result applies to the baseline used for release or to a newer requirement that still needs engineering review.
Product, engineering and quality roles then continue the process in Velocize. They plan the response, assign responsibilities and inspect outstanding obligations. Native Velocize records can develop around the IBM source while retaining the distinction between an external requirement and an internally accepted decision.
How can a process continue from Velocize into IBM?
An authorized delivery or review decision in Velocize can initiate an outbound action against the mapped IBM record or create the permitted follow-up record. The integration profile defines the target application, object type, writable fields and allowed transition. Source references connect the action to its originating requirement and responsible person.
For example, a review can identify a requirement ambiguity and send the agreed clarification or change-request information to the responsible IBM workflow. If implementation work is managed in an IBM work environment, the authorized handover can carry the mapped work context there. Returned progress remains related to the Velocize activity that initiated it.
An action originating in Velocize remains subject to the target system's permissions and process rules. Source-owned requirements and approvals retain their owners. A proposal can continue through the IBM review workflow until the appropriate authority accepts it; integration does not grant the sender unrestricted editing rights.
What feedback travels from Velocize back to IBM?
Feedback can carry implementation progress, an engineering finding, a requested clarification, review outcome or evidence reference, according to the mapped operations. This gives the source-side owner a way to see the consequence of the requirement in the delivery process and to act on it in the environment they govern.
A failed verification can generate a linked finding and an authorized correction request. An accepted review can publish the permitted result or traceability reference. Where the integration transmits a reference rather than an evidence file, the reviewer follows that reference under the applicable access rules; the destination is not assumed to contain a full copy of every artifact.
Completion, verification and approval remain separate states. Feedback that work is finished does not by itself approve a requirement change or customer release. The destination owner reviews the applicable result, and the resulting status or revision can return to Velocize. The process therefore supports another engineering step in either environment.
How do OSLC and ReqIF support this operating model?
OSLC-oriented integration connects lifecycle resources and their relationships through the services made available by the source environment. The selected domain, configuration context, authorization and permitted operations determine how a record can be queried, linked or updated. The integration profile documents the operations used in your program.
ReqIF provides a bounded requirements exchange, useful when a defined package must cross an organizational or network boundary. Identifiers, attributes, relationships and revisions are reviewed during import and return exchange. Workflow execution, approval history and all external links do not automatically travel with a requirements package; these need explicit treatment in the agreed scope.
Choose the route by the process you need to continue. Online linked work and periodic package exchange have different operating rhythms. Both retain source ownership, reviewable reconciliation and the authority needed before imported or returned information changes the governed working state.
What happens when requirements change in parallel?
The same requirement can participate in several delivery configurations. A change must be evaluated against the configuration that the team is implementing and verifying. Requirement identity alone is insufficient to explain which version the result supports; the configuration and revision references stay with the lifecycle connection.
Field ownership and mapping versions govern synchronization. If a Velocize proposal conflicts with a changed IBM source, the conflict is retained for reconciliation. Approval-sensitive changes require human review. An accepted baseline stays a reference; proposed changes follow the authorized working configuration and source process.
Connector monitoring exposes permission failures, interrupted exchange and records awaiting reconciliation. Operators can recover a bounded scope and review the result. Teams retain the last known source context and can identify where fresh confirmation is still needed before making an acceptance decision.
A round-trip example from requirement to correction
Take an illustrative program with a DOORS Next requirement in an accepted configuration. Velocize links that source to a design decision, a delivery work package and verification obligations. The engineering owner uses Velocize to plan the work and initiate the configured handover to the selected implementation environment.
Progress returns, followed by a verification result that exposes an ambiguity in the requirement. The team records the finding in Velocize with the affected revision and evidence. An authorized feedback action sends the mapped clarification or change request to the IBM-side owner. That owner evaluates it through the source workflow.
When the IBM change is accepted, the revised source returns to the linked Velocize scope. Impact review identifies the design, work and verification that need attention. Correction and new evidence proceed, and the responsible release owner makes the final acceptance decision. Each handover retains its source, reviewer and result. This is an explanatory scenario, not a customer case study.
Who governs suppliers, AI and cross-system access?
Requirements owners govern the source; engineering owners govern design consequences; delivery and quality owners manage work and proof. Administrators authorize the integration account and allowed operations. IBM project and team permissions continue to apply to source-side changes.
Suppliers can contribute through scoped online collaboration or offline exchange in Velocize while the IBM requirement remains traceable. Returned progress and evidence enter internal review before customer acceptance. AI assists within an assigned role, permitted sources and approved model route; it does not acquire the source owner's approval authority.
Choose deployment and data paths with the same care as access. Review where source content, extracted material and AI context are processed, how support can access the environment and how failed exchanges are recovered. The security checklist gives IT and assurance a shared review structure.
What should a technical evaluation demonstrate?
Use one accepted requirement, one changed revision, one restricted item and one unresolved finding. Agree source ownership, configuration context, supported inbound/outbound actions and acceptance criteria. Show a process step started in Velocize, its authorized continuation in the IBM environment and the returned result.
Include a failed or conflicting update. The team should be able to explain why the action was held, who resolves it and how the accepted outcome becomes visible on both sides. Inspect links from requirement to work and evidence, then follow a finding back to the source requirement and configuration.
Document the IBM products and versions, mapped objects, write permissions, online or package route, reconciliation owner, support and training. Select the Velocize package and deployment for the additional lifecycle scope. The outcome is an accepted integrated workflow with clear responsibilities, while IBM remains part of the operating environment.