The Software and Systems Engineering Experts
US: +1 (610) 247-9595 / EU: +48 666 74 71 74
Home · Solutions · Telecommunications
Solutions · Telecommunications
Telecom products with release‑ready requirements traceability
3GPP and TL 9000 evidence from one connected IBM Engineering Lifecycle Management toolchain, set up by consultants who work with telecommunications engineering teams.
Telecommunications
The telecommunications sector
Networks are now defined in software
The sector covers network equipment vendors, operators and the software companies behind them: radio and core network suppliers, OSS and BSS vendors, and device makers. Products follow 3GPP releases, ship to many operators and stay in networks for years.
More of what a network does runs as software on general-purpose hardware and in the cloud. Every feature has to match the standard it implements, the operator's own requirements and security rules, release after release.
ShiftCloud-native networks
Network functions move from dedicated hardware to containers and cloud platforms, with continuous delivery instead of large yearly releases.
ShiftOpen and multi-vendor RAN
Open interfaces bring more vendors into one network, and more interface requirements to agree and test.
ShiftSecurity under regulation
NIS2 and the EU Cyber Resilience Act make security of network software and devices a legal duty.
ShiftFaster 3GPP cycles
Each 3GPP release adds features and change requests that operators expect in products quickly.
Engineering challenges
What this means for software and systems engineering
Standards compliance per release
Each feature must state which 3GPP specification and version it implements, and which options are supported.
Operator requirements
Operators send long requirement lists in tenders and acceptance, and expect a compliance statement for every line.
Many products, many versions
The same platform ships in many configurations and releases to different operators, each needing its own baseline.
Continuous delivery
Pipelines deliver in short cycles. Requirements and tests have to keep up without slowing the pipeline down.
Quality measured for TL 9000
TL 9000 asks for measured quality across the life cycle, from requirements to problem reports from the field.
Security in the pipeline
Security requirements, scans and tests run in the delivery pipeline, with results linked to the release.
What operators and auditors expect
Where telecom teams lose time before operator acceptance
When a new 3GPP release or change request arrives, engineers search specifications and spreadsheets to find which features it affects.
Each operator sends its own requirement list. Teams answer it in a spreadsheet copied from the last tender and checked by hand.
GitLab pipelines run tests on every merge, but the results are not linked to requirements or to the release.
RiskA product claims compliance with a specification version it no longer matches.
With Smarter Process3GPP clauses are linked to feature requirements, so a new change request shows which features, code and tests to recheck.
RiskStatements contradict the product, and acceptance finds gaps the tender promised to close.
With Smarter ProcessOperator requirements link to feature requirements, and compliance statements come from the same data, compared with the previous answer.
RiskAt acceptance or a TL 9000 audit, nobody can show which requirements a release verified.
With Smarter ProcessPipeline results flow into IBM Engineering Test Management, linked to requirements and to the release baseline.
Compliance map
3GPP, TL 9000 and NIS2, mapped to the toolchain
Pick a standard to see what it asks for, and where it lives in your toolchain once we have set it up.
3GPP · Technical specifications per release
IBM Engineering Requirements Management DOORS Next
What it asks forFeatures implemented to a stated specification, version and release, with supported options declared
How we cover itSpecification clauses as linked requirements with release and version attributes; trace to features and tests
IBM Engineering Requirements Management DOORS Next3GPP · Change requests between releases
IBM Engineering Requirements Management DOORS NextIBM Engineering Lifecycle Management Global Configuration Management
What it asks forChanges from new releases and change requests assessed for their impact on products
How we cover itNew release imported and compared; suspect links mark affected features, code and tests
IBM Engineering Requirements Management DOORS Next
IBM Engineering Lifecycle Management Global Configuration Management3GPP · Conformance and interoperability testing
IBM Engineering Test ManagementHCL DevOps Test
What it asks forEvidence that implemented features pass conformance and interoperability tests
How we cover itTest plans and results linked to specification clauses, with a coverage view per release
IBM Engineering Test Management
HCL DevOps TestTL 9000 · Requirements and design control
IBM Engineering Requirements Management DOORS NextIBM Engineering Workflow Management
What it asks forCustomer and product requirements reviewed, traced to design and verified before release
How we cover itRequirement reviews, trace views and release baselines; problem reports linked to what they change
IBM Engineering Requirements Management DOORS Next
IBM Engineering Workflow ManagementTL 9000 · Measurements
IBM Engineering Workflow ManagementIBM Engineering Lifecycle Optimization – Publishing
What it asks forMeasured product quality, including problem reports and how fast fixes are delivered
How we cover itProblem reports and fixes as work items with dates and links, reported per release
IBM Engineering Workflow Management
IBM Engineering Lifecycle Optimization – PublishingNIS2 · Article 21 risk management measures
IBM Engineering Requirements Management DOORS NextIBM Engineering Workflow Management
What it asks forRisk management, supply chain security, secure development and vulnerability handling, documented and reviewed
How we cover itMeasures as requirements linked to controls, owners and evidence; review workflow per period
IBM Engineering Requirements Management DOORS NextIBM Engineering Workflow ManagementEU CRA · Annex I essential requirements
IBM Engineering Requirements Management DOORS NextGitLab
What it asks forSecurity requirements from a risk assessment, secure by default, and vulnerability handling for the support period
How we cover itEssential requirements linked to product requirements, pipeline security tests and release baselines
IBM Engineering Requirements Management DOORS Next
GitLabETSI EN 303 645 · Clause 5 provisions
IBM Engineering Requirements Management DOORS NextIBM Engineering Test Management
What it asks forSecurity provisions for consumer devices, such as no universal default passwords, secure updates and vulnerability disclosure
How we cover itProvisions as a checklist module linked to device requirements and test results, with status per release
IBM Engineering Requirements Management DOORS NextIBM Engineering Test ManagementBook a 30-min compliance gap review
Compliance is achieved by your organization and confirmed by your operators, auditors or certification body. Tools hold the evidence; we set them up so the evidence is complete and easy to show.
Capabilities
What your team can do on day one
Baselines for every release
Freeze a configuration for each product release or operator delivery and compare it with the next one, item by item. Operators and auditors see exactly what changed and why.
- IBM Engineering Lifecycle Management Global Configuration Management
3GPP traceability that stays current
Specification clauses link to features and tests, so a new release or change request shows its impact the day it arrives.
- IBM Engineering Requirements Management DOORS Next
Operator compliance statements
Operator requirement lists come in through Requirements Interchange Format (ReqIF) or import and go back answered, compared with the previous round.
- IBM Engineering Requirements Management DOORS Next
Requirements in the CI/CD pipeline
Merge requests and pipeline results in GitLab link to requirements and work items, without slowing delivery.
- GitLab
- IBM Engineering Workflow Management
Test results linked to releases
Automated and manual tests report into one place, with coverage per requirement and per release.
- IBM Engineering Test Management
- HCL DevOps Test
Security from requirement to scan
Security requirements link to HCL AppScan findings and security tests in the pipeline, ready for NIS2 and Cyber Resilience Act audits.
- GitLab
- IBM Engineering Requirements Management DOORS Next
See every product we implement and support
IBM Engineering Lifecycle Management, HCL and GitLab: licences, set-up, training and support from one team.
All products →
Network test labCustomer references
Engineering teams in telecommunications software
We work with engineering teams at Amdocs, a provider of software and services to communications operators, on requirements and test management in IBM Engineering Lifecycle Management.
3GPPclauses traced to tests
Operatorscompliance statements from live data
CI/CDpipeline results linked to requirements
FAQ
Questions telecommunications teams ask us
Do we need to validate the toolchain for TL 9000 or ISO 9001 audits?
Not as formal tool qualification, as in safety standards. TL 9000 auditors look for controlled processes and records you can trust. We document how each tool is configured, which workflows and permissions protect requirement and test records, and how baselines are created. That configuration description, with access control and an audit trail of changes, is usually what auditors ask to see, and it stays valid across tool updates when it is kept with the project.
Operators send requirement lists in their own spreadsheets. How do we answer without retyping?
Each operator list is imported into its own module with the operator's IDs kept, or exchanged through ReqIF where the operator supports it. Compliance status and comments are attributes linked to your feature requirements, so answers are reused across tenders and stay consistent with the product. The answered list goes back in the operator's format, and the next round is compared with the previous one, so you see what changed.
We ship one platform in many releases and operator configurations. How do we avoid copying requirements?
With streams and baselines in IBM Engineering Lifecycle Management Global Configuration Management. The platform is one stream. Each release and operator configuration reuses it and holds only its own differences, and every delivery gets a baseline. You compare releases item by item, bring fixes across where they apply, and answer an operator's question about a delivered release from the exact configuration it runs.
Our requirements are in IBM Engineering Requirements Management DOORS (9.x), with DXL scripts. How do we move?
Product by product, not all at once. Products in maintenance often stay on IBM Engineering Requirements Management DOORS (9.x) while new releases start in IBM Engineering Requirements Management DOORS Next. When a product moves, modules, attributes and links move with their original IDs, and delivered baselines are kept, so answers given to operators stay reproducible. DXL scripts are inventoried first. Most become configuration, views or link rules, and the rest become supported extensions.
Our developers work in Atlassian Jira and GitLab. Do they have to change tools?
No. Requirements stay in IBM Engineering Requirements Management DOORS Next, and Atlassian Jira issues and GitLab merge requests link to them through OSLC connectors or a synchronization we configure. Pipeline test results are published to IBM Engineering Test Management against the release, so coverage per requirement is current after every run. We agree with your teams which links are mandatory, for example a requirement link on every feature merge request, and check them in the pipeline.
How do NIS2 and the EU Cyber Resilience Act affect our requirements and pipeline?
Both turn security into documented, auditable work. We set up security requirements as their own artifact type, linked to the threats they answer and the features they constrain. HCL AppScan and other scanners run in the GitLab pipeline, and findings become work items linked to the affected release. NIS2 measures and Cyber Resilience Act essential requirements are kept as checklists with links to evidence, so audits draw on the same data as delivery.
New · SmarterWidgets 2.0
Ready-made widgets for IBM DOORS Next
Add them to the ELM Mini Dashboard and hand repetitive requirements work over to them. Each one previews its changes first.
Browse all widgets- Content qualityClean text and glossary linksStyle Cleaner, Link Checker and more
- Links and traceabilityFix, move and inspect linksLink Remover, Module To Base Links and more
- Module structureBuild and repair module hierarchyModule Fill, Module Explorer 2.0 and more
- Configuration and governanceBaselines, data models and auditsBaseline Archiver, Compare Data Models and more
- Reporting and publishingCharts, maps and publishingPublishing URLs, Module Insights and more
- See all widgetsScreenshots and details for every widget
Watch and learn
Our Videos
Demos, tutorials and customer stories on requirements, traceability and test.
Talk to our consultants
Leave your details and we will get back to you, usually within one business day.
