RTDC

A Structured Engineering Method for Complex ICT Programmes

Complex ICT systems succeed when architecture, equipment, software, networks, installation, integration, testing and operations are engineered together. Nine stages turn that principle into a method.

The nine stages

Select a stage to see its activities and technical considerations.

  1. Requirement interpretation
  2. Discovery and assessment
  3. Architecture
  4. Detailed design
  5. Validation
  6. Implementation planning
  7. Testing
  8. Commissioning
  9. Operational transition

Engineered together, not assembled

The contribution of a systems integrator is not limited to supplying components. Each stage below is planned in relation to the stages that follow.

  • Design decisions consider deployment constraints.
  • Technology selection considers interoperability and supportability.
  • Installation planning considers testing and acceptance.
  • Commissioning planning considers operational transition.
  • Operational data informs performance improvement and future modernisation.

The method is how we deliver:

  • Translating functional requirements into technical architecture
  • Designing for actual field and operating conditions
  • Selecting compatible technologies
  • Managing interdependencies
  • Coordinating multiple workstreams
  • Establishing measurable acceptance criteria
  • Creating operational visibility
  • Managing system performance after commissioning
  • Planning upgrades and obsolescence over the system lifecycle

Requirements are traced to tests

Acceptance criteria are defined at the first stage and verified at the last. Each design level has a matching level of verification, so nothing is accepted that was not first specified.

Design items and the tests that verify themA V-shaped traceability diagram. On the left, descending: requirements with acceptance criteria, architecture, and detailed design. At the bottom: implementation. On the right, ascending: component and configuration testing, system testing, and commissioning. Each design level is verified by the test level opposite it.DefinedVerifiedRequirementsacceptance criteria defined (stage 1)Commissioning and handovercriteria demonstrated (stages 8 and 9)verified byArchitectureavailability, recovery, monitoring models (stage 3)System testingintegration, security, performance, failover, recovery (stage 7)verified byDetailed designrules, policies, schedules, thresholds (stage 4)Component and configuration testingeach design item checked (stage 7)verified byImplementationinstall, configure, integrate (stages 6 and 7)Acceptance criteria are written once, at requirement stage, and the same criteria are used to accept the system.
Defined and verified. Left to right pairs show which test level verifies which design level. The same criteria written at requirement stage are used to accept the system.

Stage by stage

Stage 1: Requirement interpretation

The first stage converts functional, contractual and operational requirements into technical requirements.

Carries forward. Acceptance criteria written here are the same criteria used in testing (Stage 7) and commissioning (Stage 8).

Activities may include:

  • Requirement decomposition
  • Clarification of assumptions
  • Identification of dependencies
  • Definition of workloads
  • Definition of availability requirements
  • Definition of integration points
  • Definition of security needs
  • Definition of acceptance criteria
  • Identification of exclusions

Stage 2: Discovery and assessment

Establishes what already exists and what it depends on, so design starts from the actual environment rather than its documentation.

Carries forward. Dependency maps and site surveys constrain architecture, sequencing and downtime planning.

Fibre installation trailer and truck at an outdoor site, with a buried-fibre warning marker in the foreground

Discovery may include:

  • Existing infrastructure inventory
  • Application inventory
  • Network assessment
  • Site surveys
  • Capacity assessment
  • Configuration review
  • Dependency mapping
  • Security review
  • Operations review
  • Documentation review

Stage 3: Architecture

Defines the structure of the system and the models by which it will be kept available, recovered, observed and managed.

Carries forward. The monitoring and management models are set at architecture stage so that operations are designed in, not added after commissioning.

Architecture should define:

  • System layers
  • Major components
  • Data flows
  • Network zones
  • Security boundaries
  • Integration interfaces
  • Availability model
  • Recovery model
  • Monitoring model
  • Management model

Stage 4: Detailed design

Turns the architecture into the specific parameters, schedules and rules from which equipment is procured and configured.

Carries forward. Each design artefact — cable schedule, rule set, backup policy, threshold — becomes something that can be checked during testing.

Detailed design may include:

  • Equipment sizing
  • Port mapping
  • Addressing
  • Routing
  • Segmentation
  • Rack layouts
  • Cable schedules
  • Firewall rules
  • User roles
  • Storage allocation
  • Backup policies
  • Monitoring thresholds
  • Interface specifications

Stage 5: Validation

Checks the design against the requirements before procurement and installation commit cost and time to it.

Carries forward. Testability is a design criterion: a requirement that cannot be tested cannot be accepted.

Design validation should check:

  • Requirement coverage
  • Sizing
  • Compatibility
  • Redundancy
  • Scalability
  • Security
  • Operability
  • Maintainability
  • Testability
  • Supportability

Stage 6: Implementation planning

Sequences the work so that site readiness, logistics, access and downtime are resolved before equipment arrives.

Carries forward. Acceptance points and rollback steps are fixed in the plan, ahead of installation.

Technician on a ladder against a pole, working on overhead communications cable

Implementation planning should define:

  • Work packages
  • Sequence
  • Dependencies
  • Site readiness
  • Logistics
  • Access
  • Downtime
  • Resources
  • Tools
  • Acceptance points
  • Rollback

Stage 7: Testing

Demonstrates, against predefined criteria, that the system performs, fails over and recovers as designed.

Carries forward. Test evidence forms part of the commissioning record and the baseline for later operations.

Network switch with a bundle of blue patch cables plugged into its front ports

Testing should include:

  • Component testing
  • Configuration testing
  • Integration testing
  • Security testing
  • Performance testing
  • Failover testing
  • Recovery testing
  • User validation
  • Field testing
  • Operational-readiness testing

Stage 8: Commissioning

Confirms that installation, configuration, integration and testing are complete, and that the people who will use and support the system are ready.

Carries forward. Open issues are tracked to closure; handover is a documented event, not an assumption.

Wall-mounted facility monitoring and alarm panels seen through a window in a data-centre monitoring room

Commissioning should confirm:

  • Installation completion
  • Configuration completion
  • Integration completion
  • Test closure
  • Documentation availability
  • User readiness
  • Operations readiness
  • Support readiness
  • Issue tracking
  • Formal handover

Stage 9: Operational transition

Moves the system into steady-state operation with the knowledge, records and processes needed to run and maintain it.

Carries forward. Operational data then feeds back into capacity planning, performance improvement and modernisation.

Operational transition should include:

  • Knowledge transfer
  • Runbooks
  • Monitoring setup
  • Escalation matrix
  • Asset register
  • Spares register
  • Warranty records
  • Preventive-maintenance schedule
  • Incident process
  • Change process
Project DeliveryHow the stages are executed across sites and stakeholdersManaged OperationsWhat happens after operational transitionCapabilitiesThe nine technical capability areasAcceptance test planTechnical note: building an acceptance test plan

Discuss an ICT Requirement

Describe the requirement, the locations involved and where the project stands. We will respond with the technical questions that need answering first.

Discuss an ICT Requirement