systems engineering - · pdf filemaintenance concept definition . ... rolling stock operator ....

Sup

erse

ded

by T

MU

AM

060

06 S

T v2

.0, 0

8/11

/201

7

Systems Engineering

T MU AM 06006 ST

Standard

Version 1.0

Issued Date: 03 March 2015

Effective Date: 03 September 2015

Important Warning This document is one of a set of standards developed solely and specifically for use on public transport assets which are vested in or owned, managed, controlled, commissioned or funded by the NSW Government, a NSW Government agency or a Transport Agency (as defined in the Asset Standards Authority Charter). It is not suitable for any other purpose. You must not use or adapt it or rely upon it in any way unless you are authorised in writing to do so by a relevant NSW Government agency. If this document forms part of a contract with, or is a condition of approval by a NSW Government agency, use of the document is subject to the terms of the contract or approval. This document may not be current. Current standards are available for download from the Asset Standards Authority website at www.asa.transport.nsw.gov.au. © State of NSW through Transport for NSW

T MU AM 06006 ST Systems Engineering

Version 1.0 Effective Date: 03 September 2015

Sup

erse

ded

by T

MU

AM

060

06 S

T v2

.0, 0

8/11

/201

7

Standard governance

Owner: Manager, Systems Engineering Process, Asset Standards Authority

Authoriser: Principal Manager, Network and Asset Strategy, Asset Standards Authority

Approver: Director, Asset Standards Authority on behalf of ASA Configuration Control Board

Document history

Version Summary of change

1.0 First issue

For queries regarding this document, please email the ASA at [email protected] or visit www.asa.transport.nsw.gov.au

© State of NSW through Transport for NSW



Preface The Asset Standards Authority (ASA) is an independent unit within Transport for NSW (TfNSW)

and is the network design and standards authority for defined NSW transport assets.

The ASA is responsible for developing engineering governance frameworks to support industry

delivery in the assurance of design, safety, integrity, construction, and commissioning of

transport assets for the whole asset life cycle. In order to achieve this, the ASA effectively

discharges obligations as the authority for various technical, process, and planning matters

across the asset life cycle.

The ASA collaborates with industry using stakeholder engagement activities to assist in

achieving its mission. These activities help align the ASA to broader government expectations of

making it clearer, simpler, and more attractive to do business within the NSW transport industry,

allowing the supply chain to deliver safe, efficient, and competent transport services.

The ASA develops, maintains, controls, and publishes a suite of standards and other

documentation for transport assets of TfNSW. Further, the ASA ensures that these standards

are performance based to create opportunities for innovation and improve access to a broader

competitive supply chain.

This standard establishes mandatory requirements for systems engineering (SE) management

for the planning, acquisition and delivery of assets owned by TfNSW across the asset life cycle.

This standard defines responsibilities for TfNSW and its engineering supply chain in carrying out

SE on multimodal, multidisciplinary engineering projects.

This standard and SE practice in general, is placed in a broader context of asset management,

and therefore SE is a methodology that supports the TfNSW asset management framework.

This standard has been approved by the ASA Configuration Control Board and is the first issue.

© State of NSW through Transport for NSW of 23 S

uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



Table of contents 1. Introduction ............................................................................................................................................ 5

2. Purpose ................................................................................................................................................... 6 2.1. Scope ..................................................................................................................................................................... 6 2.2. Application ............................................................................................................................................................. 6 3. Reference documents ........................................................................................................................... 7

4. Terms and definitions ........................................................................................................................... 8

5. TfNSW system life cycle ..................................................................................................................... 10 5.1. System life cycle model ...................................................................................................................................... 10 5.2. Plan stage ............................................................................................................................................................ 13 5.3. Acquire stage....................................................................................................................................................... 14 5.4. Operate and maintain stage ............................................................................................................................... 15 5.5. Dispose stage ...................................................................................................................................................... 15 6. System description .............................................................................................................................. 16 6.1. Stakeholder viewpoints ...................................................................................................................................... 16 6.2. Operational concept ............................................................................................................................................ 16 6.3. Maintenance concept .......................................................................................................................................... 17 7. Systems engineering management ................................................................................................... 17 7.1. System engineering organisation ...................................................................................................................... 18 7.2. Requirements management ............................................................................................................................... 18 7.3. System architecture management ..................................................................................................................... 19 7.4. System interface management........................................................................................................................... 20 7.5. Systems integration management ..................................................................................................................... 20 7.6. Reliability, availability, maintainability and safety management .................................................................... 21 7.7. Verification and validation .................................................................................................................................. 21 7.8. Electromagnetic compatibility management .................................................................................................... 21 7.9. Human factors integration .................................................................................................................................. 21 8. Shared information and records ........................................................................................................ 22

9. System engineering management plan ............................................................................................. 22 9.1. System engineering management plan content ............................................................................................... 23 9.2. System engineering management plan context ............................................................................................... 23


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



1. Introduction A system is a combination of hardware, software, people, processes and support arrangements,

brought together in a way that satisfies a customer need in the form of a product or service. A

system can also include data, facilities, materials, and naturally occurring entities such as terrain

and waterways.

Systems engineering is an interdisciplinary approach and a means to enable the realization of

successful but complex transport systems.

While introducing a new or altered system into the transport network, it is imperative to analyse,

synthesise, verify and validate the system over its full life cycle.

A system includes the functions and performance expectations of the system and its support

requirements. To manage this effectively and efficiently, ensuring that customer needs and

strategic intents are fulfilled at all times, requires each organisation to establish a framework for

systems engineering, including configuration management.

The systems engineering approach is fundamental to bringing high performing fit-for-purpose

and cost-effective systems into being. Using a multidisciplinary approach, systems engineering

determines the following outputs at the early stages of the system life cycle:

• functional, performance, non-functional and interface requirements and constraints

• appropriate management process requirements

• production or construction requirements and constraints

• sustainable operational and maintenance support requirements

• system disposal requirements

Systems engineering not only transforms a need into a definitive system configuration for use by

its users, but also ensures the system's compatibility and interfaces with related physical and

functional requirements. 'Needs' are seen as defining the problem domain, while a 'definitive

system configuration' is viewed as the solution domain.

Systems engineering can be applied equally in the problem domain through the normal systems

engineering processes as well as the solution domain.

The systems engineering approach considers life cycle outcomes measured by performance,

reliability, availability, maintainability, and safety and cost-effectiveness.

This standard is informed by and expands on the systems engineering requirements identified in

T MU MD 00009 ST AEO Authorisation Requirements.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



2. Purpose The purpose of this standard is to provide a structured set of requirements to establish a

systems engineering framework and to manage systems engineering activities within transport

projects ranging from simple to complex, across the system and asset life cycle.

2.1. Scope This standard covers requirements for planning and execution of systems engineering activities

associated with acquisition and development of new or altered transport systems.

2.2. Application This standard is to be applied at a number of levels including transport network, transport mode,

line/route and specific project.

This standard applies to all entities within the NSW transport cluster as defined in the ASA

charter. It also applies to Authorised Engineering Organisations (AEOs) in its supply chain

involved in the planning, acquiring, operating, maintenance and disposal of new or altered

systems.

Application of this standard will support compliance with the following:

• CP14005 Transport Asset Management Policy

• T MU AM 01001 ST Life Cycle Costing Standard

• 50-ST-162 Asset Life Cycle Safety Management Standard

This standard contributes to overall compliance with TfNSW obligations under legislation such

as the Rail Safety National Law (NSW).

The concepts and principles described within this standard are to be scaled and tailored to suit

the level of novelty, complexity, scale and risk associated with each project.

Note: The application of all elements of this standard should be carefully considered to

ensure the appropriate level of rigour, and to ensure that value for money and safety

are achieved for the full system life cycle including capital expenditure (CapEx) and

operational expenditure (OpEx).


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



3. Reference documents The following documents are cited in the text. For dated reference, only the cited edition applies.

For undated references, the latest edition of the reference document applies.

Australian standards

AS/NZS ISO/IEC 15288 Systems and software engineering – System life cycle processes

AS ISO 55001 Asset Management – Management Systems: Requirements

Transport for NSW standards

T MU MD 00009 ST AEO Authorisation Requirements

T MU AM 01001 ST Life Cycle Costing Standard

T MU AM 02001 ST Asset Information Management

T MU AM 06004 ST Requirements Schema

T MU AM 06007 GU Guide to Requirements Definition and Analysis

T MU HF 00001 GU AEO Guide to Human Factors Integration

TS 20001: 2013 System Safety Standard for New or Altered Assets

50-ST-162/3.0 Asset Life Cycle Safety Management Standard (available on request from

[email protected])

Legislation

Rail Safety National Law (NSW)

Other references

Asset Standards Authority Charter

CP14005 Transport Asset Management Policy (available on request from

[email protected])

INCOSE Systems Engineering Handbook


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017

mailto:[email protected]



4. Terms and definitions The following terms and definitions apply in this document:

ABS asset breakdown structure

AEO Authorised Engineering Organisation

ASA Asset Standards Authority

BRS business requirements specification

CapEx capital expenditure

CED Customer Experience division of TfNSW

CMAAC configuration management and asset assurance committee of TfNSW

COTS commercial off the shelf

EMC electromagnetic compatibility

EMI electromagnetic interference

FRD Freight and Regional Development division of TfNSW

HFI human factors integration

ICD interface control document

INCOSE International Council on Systems Engineering

IRS interface requirements specification

JOS judgment of significance. An assessment of the technical risk introduced by the

implementation of the design considers both the probability and consequence of partial

performance or failure of a design.

MCD maintenance concept definition

NWRL North West Rail Link

OpEx operational expenditure

O&M operator maintainer

OCD operations concept definition

OEM original equipment manufacturer

P50 estimate a cost estimate based on a 50% probability that the cost will not be exceeded

P90 estimate a cost estimate based on a 90% probability that the cost will not be exceeded

PPD Planning and Programs division of TfNSW


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



project the organisation responsible for planning and delivering new or altered transport

systems. The project includes wider portfolio and program organisations.

RAMS reliability, availability, maintainability, and safety

RIM rail infrastructure manager

RMS roads and maritime services

RSO rolling stock operator

SBS system breakdown structure

SE systems engineering

SID safety in design

SEMP systems engineering management plan

SRS system requirements specification

TfNSW Transport for New South Wales

TSD Transport Services division of TfNSW

V&V verification and validation

validation confirmation, through the provision of objective evidence, that the requirements for a

specific intended use or application have been fulfilled

verification confirmation, through the provision of objective evidence, that specified

requirements have been fulfilled


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



5. TfNSW system life cycle TfNSW considers systems engineering as one of a collection of methodologies that support total

asset management over the asset life cycle. The TfNSW asset or system life cycle adopts the

AS ISO 55001 Asset Management – Management Systems: Requirements approach and

comprises four main stages:

• plan

• acquire

• operate and maintain

• dispose

AS/NZS ISO/IEC 15288 Systems and Software Engineering – System life cycle processes, and

the INCOSE Systems Engineering Handbook that supports it, define the system life cycle

stages. Section 5.2 through to Section 5.5 outline how the INCOSE system life cycle stages are

interpreted and mapped to the TfNSW life cycle activities.

The ASA has adopted AS/NZS ISO/IEC 15288 and the supporting INCOSE system life cycle

model and approach, and is aiming to standardise the systems engineering approach by

applying a tailored INCOSE approach to the TfNSW model.

This life cycle model is also consistent with the life cycle activities and responsibilities defined in

the 50-ST-162 Asset Lifecycle Safety Management Standard.

5.1. System life cycle model TfNSW's system life cycle and engineering management definitions are based on the systems

engineering 'V' model described in the INCOSE Systems Engineering Handbook and

AS/NZS ISO/IEC 15288.

The V model aligns to the TfNSW asset life cycle stages and its configuration management and

asset assurance committee (CMAAC) gateways and investment gateways. Figure 1 shows the

relationship between the asset life cycle stages and CMAAC gateways.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017

http://intranet.transport.nsw.gov.au/guides/asset_management_standard_50-ST-162.pdf



Figure 1 - TfNSW asset life cycle stages and configuration gateways

Figure 2 illustrates the TfNSW system life cycle model, showing the relationship between the

CMAAC gateways and the stages of the asset life cycle.

The system V life cycle model maps system definition against all life cycle stages. System

definition increases in granularity from the system, through subsystem, to unit level.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



CMAAC Gates

Gate 1Reqmnts complete

Gate 3 For

Construction

Gate 0Initiation (Need)

AcceptNeed Concept Specify Procure Design Build Integrate Operate and Maintain Dispose

Concept Development Production Utilisation and Support Retirement

Verification (System)

Verification (System Interfaces)

Material Procurement, Fabrication / ManufacturingConstruction / Installation

Unit Level Inspection

& Test

Unit Level Design,

Final Design

OCD/MCD, Service Design

Define Need, early Con Ops,

draft T/T

Subsystem Integration

& Test

System Integration

& Test

Disposal planning & executionSystem Validation

Verification (Subsystem Level)

Verification (Unit Level)

System Validation & Acceptance

Subsystem Design

Sys Design, Physical

Architecture

Ref Design, SRS, Funct Architecture

Operate & Maintain(Replace, Refurbish,

Renew, Upgrade)

Plan Acquire Operate/Maintain

Gate 2 Initial

Design

System Definition

Gate 4 Ready to

Test

Gate 6 Asset

Review

Syst

em In

tegr

atio

n/Re

alis

atio

n

Gate 5 Accept Assets

Dispose

Feasibility, Business

Case, BRS

Exploratory

Evolve

System ReqtsValidation

System DesignVerification

Subsystem DesignVerification

Unit DesignVerification

Build Verification

Figure 2 - TfNSW system V life cycle model with configuration gates © State of NSW through Transport for NSW of 23 Sup

erse

ded

by T

MU

AM

060

06 S

T v2

.0, 0

8/11

/201

7



5.2. Plan stage The ‘plan’ stage involves the identification of a need or demand, the translation of that need into

system specification and consists of the following sub-stages:

• need and concept

• specify and procure

5.2.1. Need and concept The ‘need and concept’ sub-stages correspond to the concept stage in AS/NZS ISO/IEC 15288

and INCOSE Systems Engineering Handbook.

Key responsible parties include the following organisations:

• Customer Experience (CED)

• Transport Services (TSD)

• Freight and Regional Development (FRD)

• Planning and Programs (PPD)

• AEOs contracted to provide technical advice in this life cycle stage

Additionally, specialised large build-operate-maintain project organisations such as North West

Rail Link (NWRL) and Light Rail also hold this responsibility. Transport agencies, operators and

maintainers providing services under contract to TfNSW may in some cases also hold this

responsibility, and if not they should be consulted as key stakeholders in this stage.

Safety responsibilities of all parties at this stage shall be in accordance with the TfNSW safety

management system (SMS) and TS 20001 System Safety Standard for New or Altered Assets.

In the case of rail-specific systems, the rail infrastructure manager (RIM) and rolling stock

operator (RSO) are responsible parties involved in this stage as part of due diligence

accountability under the Rail Safety National Law (NSW).

In some cases, the need for a new or altered asset or system may be initiated by the operator-

maintainer as a capital project during the need and concept stages.

Key activities and deliverables include transport demand and needs analyses, transport

performance modelling, transport service design, draft operations concept definition and

maintenance concept definition, concept design, draft business case, P50 cost estimate, and

business requirements specification (BRS).


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



5.2.2. Specify and procure The ‘specify and procure’ sub-stage corresponds to the concept stage in

AS/NZS ISO/IEC 15288 and INCOSE systems engineering handbook.


• PPD

• the project development function of TPD

• transport agencies or operators and maintainers providing services under contract to

TfNSW

• AEOs contracted to provide technical advice to these parties in this life cycle stage

There are situations where the organisation responsible for delivering these stages may not be

PPD and TPD, and therefore this applies to any delivery entity working in these stages.

Key activities and deliverables include detailed transport modelling, final operations concept

definition and maintenance concept definition, preferred option selection, systems requirement

specification, reference design, P90 cost estimate, tender documentation, and the final business

case.

At this stage, high-level system assurance requirements are established, including conducting a

preliminary hazard analysis (PHA) of the reference design to establish a system hazard log,

early consideration of human factors integration (HFI) and setting of reliability, availability and

maintainability, and other key system performance targets.

A preliminary safety in design (SiD) workshop of the concept design should also be carried out

to support feasibility and procurement.

5.3. Acquire stage The ‘acquire’ stage corresponds to the development and production stages in

AS/NZS ISO/IEC 15288 and INCOSE Systems Engineering Handbook.


• the project delivery function of TPD; or

• any other asset delivery organisation that is established by TfNSW, including acquisition

projects managed by rail transport agencies or operators and maintainers

• AEOs contracted to provide design, supply, manufacturing or fabrication, site installation,

integration, testing and commissioning services to TfNSW in this life cycle stage

While most major TfNSW capital works are carried out under TPD control, there may be

exceptions where a rail infrastructure manager or rolling stock operator performs capital works

that require a systems engineering life cycle approach. While a significant proportion of capital


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



works undertaken by a RIM or RSO are projects that involve refurbishment, like-for-like

replacement or minor performance enhancements, there remains an element of major capital

works.

Key sub-stages in this stage of the system life cycle include:

• design; including preliminary and detailed design up to ‘approved for construction’ status

• build; including manufacturing, fabrication and procurement of OEM and COTS products

• integrate; including factory and site integration of systems, and testing and commissioning

• accept; including operational readiness and validation

Key activities and deliverables include development of detailed designs, bills of materials and

product specifications, procuring systems, fabricating products, site installation and integration,

system testing, commissioning and operational readiness demonstration for hand back to the

asset owner or handover to the contracted operator and maintainer of that asset.

Additional deliverables include integration and interface documentation as well as test plans that

support system integration and testing, as discussed in Section 7.4.

Accepting parties include the CMAAC or delegated CCBs from within the transport cluster, and

the accredited RIM or RSO with responsibility for operating or maintaining the asset.

5.4. Operate and maintain stage The ‘operate and maintain’ stage corresponds to the utilisation stage in AS/NZS ISO/IEC 15288

and INCOSE Systems Engineering Handbook.


• transport operators and maintainers (O&M) providing services under contract to TfNSW

• AEOs sub-contracted to provide asset maintenance services in this life cycle stage

Key activities and deliverables include asset acceptance from the asset acquisition and delivery

organisation at the end of the acquire stage, scheduled asset condition assessments, preparing

asset maintenance plans, and carrying out asset maintenance and logistic support activities

against these plans.

5.5. Dispose stage The ‘dispose’ stage corresponds to the retirement stage in AS/NZS ISO/IEC 15288 and

INCOSE Systems Engineering Handbook.

Key stakeholders involved include TfNSW, transport O&Ms and other asset operation and

maintenance organisations, which could be AEOs, who make performance-based decisions on

when an asset is to be retired from service.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



Disposal of life expired assets generally occurs during introduction of new assets on brown field

sites as a result of major refurbishment, end of life capital renewals, changes in asset utilisation,

or performance capability upgrades.

Key activities and deliverables include asset condition assessments to support any decisions to

retire systems that have reached the end of their design life, or changes in asset utilisation.

6. System description A project shall describe the new or altered system-of-interest, including its high level functions,

environment and its functional and physical boundaries and interfaces.

6.1. Stakeholder viewpoints The system description shall describe the system from key user and stakeholder perspectives.

Any project to introduce new or altered systems with significant levels of novelty, complexity and

risk, and therefore requiring a systems approach, will have numerous stakeholders.

It is important to ensure early involvement of the O&M.

Another key stakeholder for projects involving the introduction of new or altered systems judged

to have a significant change is the office of the national rail safety regulator (ONRSR).

6.2. Operational concept A project shall ensure that a preliminary operational concept definition (OCD) for the new or

altered system is prepared early in the system life cycle, before CM gate 1 and to inform and be

part of the final business case and business requirements specification.

The OCD should be reviewed and refined as the system definition progresses beyond the BRS

and should be finalised when the system solution has been sufficiently defined.

The operational concept definition shall describe how the system will be used and operated

over its operational lifetime.

The operational concept definition shall support the business case and associated whole of life

funding, which includes how much it will cost to operate over its operational lifetime, as defined

in T MU AM 01001 ST.

Note: the operational concept definition should be applied at the appropriate level of

novelty and complexity.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



6.3. Maintenance concept A project shall ensure that a maintenance concept definition (MCD) for the new or altered

system is prepared early in the system life cycle, before CM gate 1 and to inform and be part of

the final business case and business requirements specification.

The maintenance concept definition shall describe how the system will be maintained over its

lifetime.

The maintenance concept definition shall support the business case and associated funding,

which includes how much it will cost to maintain and support over its operational lifetime.

Maintenance concepts defined in the maintenance concept definition shall align with, and

support, operational concepts defined in the operational concept definition.

7. Systems engineering management Systems engineering is a methodology for planning, specifying and delivering complex systems

and it supports the TfNSW asset management framework. Systems engineering management

requirements for planning and acquiring new or altered systems include defining and

demonstrating management structures for the following:

• organisational structure and responsibilities for systems engineering

• requirements management

• system architecture

• system interfaces

• systems integration

• reliability, availability, maintainability and safety

• verification and validation

• electromagnetic compatibility

The party responsible for meeting each requirement may change over the life cycle.

A project shall deploy a ‘whole of life’ systems engineering approach to the planning and

acquisition of the new or altered system.

The level of systems engineering shall be scaled and tailored according to an assessment of the

novelty, scale, complexity and risk associated with introducing the new or altered system.

This scaling and tailoring should ensure that the level of systems engineering is commensurate

with the system complexity and novelty.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



7.1. System engineering organisation A project shall define its organisational management structures for systems engineering.

7.1.1. Organisation structure A project shall define its systems engineering roles and responsibilities.

7.1.2. Responsibilities Levels of responsibility and engagement of systems engineering organisational roles shall be

mapped to systems engineering management processes and activities across the system life

cycle and communicated to staff.

This is typically achieved by establishing a responsibility, accountability, consulting, informing

(RACI) matrix, with SE management processes on one axis and SE roles on the other axis.

7.2. Requirements management A project shall implement a defined process, responsibilities, structure, tools and deliverables

for management of requirements across the system life cycle.

The need or goals for new or altered service capability shall be identified.

A baseline business requirements specification (BRS) shall be produced for investment gate 2

in consultation with relevant authorised stakeholders.

Requirements planning lies on a continuum that can range from concept through to design, and

who performs the planning will depend on the planning horizon for a particular system.

Stakeholder input for the BRS is typically obtained from TSD, CED, FRD and the O&M.

While PPD will often produce the BRS, other entities such as TPD or an O&M may also be

responsible for identifying needs, goals, business requirements and system requirements, and

developing business cases.

The scope of this standard therefore applies to any entity (division or agency) producing these

deliverables on behalf of TfNSW as the asset owner.

The entity responsible for producing the BRS shall submit the BRS to the TfNSW configuration

management and asset assurance committee (CMAAC) for acceptance and endorsement.

A system requirements specification (SRS) shall be produced for CMAAC gate 2 approval, in

consultation with relevant authorised stakeholders.

As appropriate for the project, system requirements shall be allocated from the SRS into

subsystem requirements (SSRs), to synthesise and develop detailed sub-system designs.

Compliance with the above requirement is subject to scaling and tailoring to the level of novelty

of the new or altered system. Where type approved equipment is to be deployed in a standard © State of NSW through Transport for NSW of 23 S

uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



configuration in compliance with existing engineering standards, then the need for developing

an SSRS may not be appropriate or required.

Business requirement specifications shall identify and trace back to informing documents and

source documents. For example policies, strategies and long term transport plans.

Further guidance on the management of requirements, including definition and analysis, can be

obtained from T MU AM 06007 GU Guide to Requirements Definition and Analysis.

An appropriate requirements management tool shall be used to manage the categorisation,

allocation, changes, traceability, verification and validation of business, system and subsystem

requirements.

Selection of the type of requirements management tool shall be based on complexity, scale and

TfNSW contractual requirements.

The requirements management tool shall be able to exchange requirements information using a

common interchange format with TfNSW requirements databases and associated schema.

The structure of requirements in a tool is defined in T MU AM 06004 ST Requirements Schema.

7.3. System architecture management A project shall implement management arrangements that define the synthesis and

development of system level requirements into a system architecture (functional, physical and

geographic).

7.3.1. Functional architecture A project shall describe the functions for the new or altered system and how these relate to

operational concept activities, operational capabilities and high-level TfNSW goals.

7.3.2. Physical solution architecture A project shall describe the physical system breakdown structure (SBS) of the proposed new or

altered system, and describe how the physical solution will be configured.

In some cases, the use of the term asset breakdown structure (ABS) is used in projects to

mean SBS. This is described in more detail in the asset classification structure framework in

T MU AM 02001 ST Asset Information Management, Appendix A.

An SBS or ABS is essential for all project types and engineering disciplines in order to indentify

assets, associated asset data and configuration information to pass from designer to builder to

tester to operator and maintainer.

Physical system block diagrams shall be used to describe the configuration and integration of

the physical assets and systems in relation to each other and to their environment.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



The physical solution architecture should also determine whether functions are implemented in

hardware, software or human users.

7.3.3. Geographic deployment architecture A geographic architecture shall be used to describe where the physical assets will be deployed

on the TfNSW transport network.

7.3.4. System context and interfaces The new or altered system shall be described in terms of its context to existing systems, and to

its operational environment.

7.4. System interface management A project shall implement management arrangements based on a well-defined process,

responsibilities, structure, tools and deliverables associated with system interfaces.

A project shall ensure that all system interface requirements under its control are identified,

captured and managed.

System interface reviews and checks shall be conducted at appropriate stages of the system

design and implementation.

A project shall identify and manage system interface risks and their causes, consequences and

controls that may have adverse health, safety or environment impacts on users.

Control and specification of system interfaces shall be via interface control documents (ICDs)

and interface requirements specifications (IRS).

The ICD establishes high level interface definition and management responsibilities, whereas

the IRS defines the detail on functional, physical, operational and performance criteria for the

interface.

7.5. Systems integration management A project shall implement management arrangements to plan and carry out the safe, controlled

integration of all elements of the new or altered system of interest.

On high-complexity projects, where it is not possible to commission into operation the entire

new or altered system in one stage, a project shall develop and follow a multi-staged systems

migration and integration approach.

A project shall identify, plan, schedule and control interim configuration states and migration

from one configuration state to the next, up to commissioning of the fully integrated system.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



7.6. Reliability, availability, maintainability and safety management A project shall implement management arrangements that define the reliability, availability,

maintainability and safety (RAMS) process, responsibilities, structure, tools and deliverables.

A project shall consider RAMS performance and how it relates to operational performance for

novel systems early in the system life cycle, starting with development of the operational

concept definition and maintenance concept definition.

A project shall consider human reliability factors as part of the overall reliability of the system.

A project shall use RAMS modeling to appropriately support option selection and development

and preliminary system design, to ensure that the new or altered system will meet the stated

operational capability and provide value for money over the designed system lifetime.

A project shall consider sustainable operation and maintenance of the new or altered system

over the full system life cycle.

7.7. Verification and validation A project shall implement management arrangements based on a well defined verification and

validation (V&V) process, responsibilities, structure, tools and deliverables.

A project shall plan V&V activities early in the system life cycle, starting with tracing goals and

operational capabilities to the development of the business requirements specification, then to a

system requirements specification and finally a sub-system requirements specification.

A project shall establish and maintain a method of recording all V&V activities and results, and

trace these to originating requirements.

7.8. Electromagnetic compatibility management A project shall implement management arrangements for assuring electromagnetic compatibility

(EMC) during the specification, design, integration or testing of electrical and electronic systems

involving electromagnetic interference (EMI) threats or victims.

7.9. Human factors integration A project shall implement management arrangements for assuring human factors integration

(HFI) during the specification, design, integration or testing of the new or altered system.

HFI guidance is provided in T MU HF 00001 GU AEO Guide to Human Factors Integration.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



8. Shared information and records Systems engineering related shared information resources shall be mapped to system life cycle

processes, and identify which information resource is owned or used by which process owners.

Shared information resources are any databases, registers, logs or other repositories of system

specification and development information that may be shared between SE process owners.

Records shall be kept of implementation of SE processes, including traceability to competence

of staff managing and using those processes.

9. System engineering management plan Where an assurance argument based on a judgment of significance (JOS) identifies the need

for a systems engineering management plan (SEMP), this shall be produced.

Where the need for an SEMP cannot be justified, the appropriate scale of systems engineering

activities shall be identified in the engineering management plan or project management plan.

The SEMP shall ensure that all system engineering management objectives are achieved. The

SEMP shall be prepared during the concept phase.

The SEMP shall define the SE deliverables to be completed prior to each gateway.

In addition to the TfNSW gateways identified in Figure 1 and Figure 2, a system delivery project

may have additional gateways to enhance assurance, including intermediate review gates for

system definition, preliminary design and final design.

The SEMP may differ from one project to another, depending on the complexity of the system.

The SEMP should generally address three key aspects:

• Technical project planning and control: describes project tasks to be planned and

developed to ensure that project objectives are met. Tasks include statement of work, work

breakdown structure, organisation, task schedules and cost, technical performance

measurement, project design reviews, supplier interfaces and risk management.

• System engineering process: describes the systems engineering process as it applies to

system requirements, including operational and maintenance concept, functional analysis

and allocation, system synthesis and trade off studies, system design, test and evaluation.

• Engineering speciality integration: describes major system-level requirements in speciality

areas, including reliability, maintainability, human factors, supportability or logistic support,

EMC, producibility and quality assurance.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017



9.1. System engineering management plan content Where a SEMP is required, it shall include the following sections as a minimum:

• objective or need

• document context and document relationship tree diagram

• system requirements structure

• system scope and boundary description

• system interfaces

• system life cycle and stage gates description

• systems engineering technical processes

• systems engineering organisation, roles and responsibilities

• systems engineering shared information matrix

9.2. System engineering management plan context The SEMP shall support the following 'parent' plans:

• asset management plan that is scaled to network, line, discipline or asset type, depending

on the scope of the system to be delivered

• project management plan, where the level of systems engineering activity is judged to be

significant

The SEMP shall refer to and align with project peer plans.

The SEMP shall be supported by systems engineering sub-plans, appropriate to the level of

scope, novelty, complexity and risk of the proposed new or altered system.

On low complexity projects, if some systems engineering activities are to be reduced or

excluded altogether, then the project shall produce a coherent assurance argument to justify

this decision.


uper

sede

d by

T M

U A

M 0

6006

ST

v2.0

, 08/

11/2

017

systems engineering - · pdf filemaintenance concept definition . ... rolling stock operator ....

Documents