t mu am 06004 st requirements schema

© State of NSW through Transport for NSW 2021

Requirements Schema

T MU AM 06004 ST Standard

Version 3.0

Issue date: 13 August 2021

Effective date: 13 August 2021

T MU AM 06004 ST Requirements Schema

Version 3.0 Effective date: 13 August 2021

© State of NSW through Transport for NSW 2021

Disclaimer This document has been prepared by Transport for NSW (TfNSW) specifically for its own use

and is also available for use by NSW public transport agencies for transport assets.

Any third parties considering use of this document should obtain their own independent

professional advice about the appropriateness of using this document and the accuracy of its

contents. TfNSW disclaims all responsibility and liability arising whether directly or indirectly out

of or in connection with the contents or use of this document.

TfNSW makes no warranty or representation in relation to the accuracy, currency or adequacy

of this document or that the document is fit for purpose.

The inclusion of any third party material in this document, does not represent an endorsement

by TfNSW of any third party product or service.

For queries regarding this document, please email Transport for NSW Asset Management Branch at [email protected] or visit www.transport.nsw.gov.au

T MU AM 06004 ST

Requirements Schema Version 3.0


© State of NSW through Transport for NSW 2021 of 36

Standard governance

Owner: Senior Manager Systems Engineering, Asset Management Branch

Authoriser: Director Asset Management Partnering and Services, Asset Management Branch

Approver: Executive Director, Asset Management Branch on behalf of the AMB Configuration Control Board

Document history

Version Summary of changes

1.0 First issue, 04 December 2014.

2.0 Second issue, 14 April 2016. Added clarification that all of the schema fields are mandatory. Added requirements for satisfies links, verifies links and validates links.

3.0 Third issue Incorporated the agreed contents of appended technical note TN 027:2018 Incorporated additional metadata fields to reflect Digital Engineering outputs on projects Incorporated changes/additions to other metadata fields due to stakeholder feedback

T MU AM 06004 ST




Preface The Asset Management Branch (AMB), formerly known as Asset Standards Authority (ASA) is a

key strategic branch of Transport for NSW (TfNSW). As the network design and standards

authority for NSW Transport Assets, as specified in the ASA Charter, the ASA identifies,

selects, develops, publishes, maintains and controls a suite of requirements documents on

behalf of TfNSW, the asset owner.

The ASA deploys TfNSW requirements for asset and safety assurance by creating and

managing TfNSW's governance models, documents and processes. To achieve this, the ASA

focuses on four primary tasks:

• publishing and managing TfNSW's process and requirements documents including TfNSW

plans, standards, manuals and guides

• deploying TfNSW's Authorised Engineering Organisation (AEO) framework

• continuously improving TfNSW’s Asset Management Framework

• collaborating with the Transport cluster and industry through open engagement

The AEO framework authorises engineering organisations to supply and provide asset related

products and services to TfNSW. It works to assure the safety, quality and fitness for purpose of

those products and services over the asset's whole-of-life. AEOs are expected to demonstrate

how they have applied the requirements of ASA documents, including TfNSW plans, standards

and guides, when delivering assets and related services for TfNSW.

Compliance with ASA requirements by itself is not sufficient to ensure satisfactory outcomes for

NSW Transport Assets. The ASA expects that professional judgement be used by competent

personnel when using ASA requirements to produce those outcomes.

About this document

This document aims to provide a standard schema for requirements, to help the exchange of

consistent information across TfNSW divisions and suppliers that are involved in the planning

and acquisition of TfNSW new or altered assets.

This document has been developed in consultation with key stakeholders within TfNSW.

This document is the third issue.

T MU AM 06004 ST




Table of contents 1. Introduction .............................................................................................................................................. 6

2. Purpose .................................................................................................................................................... 6 2.1. Scope ..................................................................................................................................................... 6 2.2. Application ............................................................................................................................................. 6

3. Reference documents ............................................................................................................................. 7

4. Terms and definitions ............................................................................................................................. 7

5. TfNSW requirements schema ................................................................................................................. 9

6. Structuring requirements information................................................................................................. 10 6.1. Requirement element-level information ............................................................................................... 10 6.2. Requirement management information ............................................................................................... 11

7. Structuring verification information .................................................................................................... 17 7.1. Verification element-level information .................................................................................................. 17 7.2. Verification activity information ............................................................................................................ 18

8. Structuring validation information....................................................................................................... 19 8.1. Validation element–level information ................................................................................................... 19 8.2. Validation activity information .............................................................................................................. 20

9. Linking and traceability ........................................................................................................................ 21

Appendix A Example schema implementation (non-DE enabled projects) ...................................... 25 A.1. Example business requirements (non-DE) .......................................................................................... 26 A.2. Example system requirements (non-DE) ............................................................................................. 27 A.3. Example subsystem requirements (non-DE) ....................................................................................... 28 A.4. Example verification activities (non-DE) .............................................................................................. 29 A.5. Example validation activities (non-DE) ................................................................................................ 30

Appendix B Example schema implementation (DE-enabled project) ............................................... 31 B.1. Example business requirements (DE-enabled project) ....................................................................... 32 B.2. Example system requirements (DE-enabled project) .......................................................................... 33 B.3. Example subsystem requirements (DE-enabled project) .................................................................... 34 B.4. Example verification activities (DE-enabled project) ........................................................................... 35 B.5. Example validation activities (DE-enabled project) ............................................................................. 36

T MU AM 06004 ST




1. Introduction Different divisions of Transport for New South Wales (TfNSW), transport agencies, and the

TfNSW supply chain have previously used ad hoc bespoke requirement structures or schemas

on projects. Using different schemas has created difficulties in exchanging common and

consistent requirements information between entities.

A common requirements schema avoids the need to transcribe and restructure requirements

information (metadata) passed between different organisations.

2. Purpose This document provides a standard schema for requirements data definition and management

for exchange of requirements between organisations on TfNSW projects. It elaborates on the

guidance provided in T MU AM 06007 GU Guide to Requirements Definition and Analysis.

2.1. Scope The document defines a common minimum requirements schema for use on major transport

capital projects with medium to high levels of novelty, complexity or risk, with additional optional

requirements included for projects utilising Digital Engineering (DE) methodologies (shaded in

grey in the tables).

This document is not for use on maintenance projects except where they are major refresh or

upgrade projects that occur as part of the maintenance program, where new or altered

requirements and assets are realised.

This document does not specify or cover the use of requirements management tools.

This document does not cover the specialised requirements schema for software testing. Refer

to T MU TE 81003 ST Test Processes and Documentation for Programmable Electronic

Systems and Software for this specialised requirement.

This document does not cover the broader topic of requirements definition and analysis. Refer

to T MU AM 06007 GU for guidance.

This document does not cover commercial contractual arrangements.

2.2. Application This standard is to be used by TfNSW divisions, agencies and the suppliers that define and

manage requirements for planning and acquiring TfNSW new or altered assets.

T MU AM 06004 ST




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

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

International standards

ISO 9000 Quality management systems — Fundamentals and vocabulary

ISO 15288 Systems and software engineering — System life cycle processes

ISO 24765 Systems and software engineering — Vocabulary

ISO 29148 Systems and software engineering — Life cycle processes — Requirements

Engineering

INCOSE Systems Engineering Handbook

Transport for NSW standards

DMS-ST-207 Digital Engineering Standard – Part 2 – Requirements

T MU AM 06007 GU Guide to Requirements Definition and Analysis

T MU TE 81003 ST Test Processes and Documentation for Programmable Electronic Systems

and Software

T MU AM 06006 ST Systems Engineering

T MU AM 06006 GU Systems Engineering

T MU AM 06010 GU Business Requirements Specification

T MU AM 06016 GU Guide to Verification and Validation

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

Acceptance test (as defined in ISO 24765)

1. Testing conducted to determine whether a system satisfies its acceptance criteria and to

enable the customer to determine whether to accept the system.

2. Formal testing conducted to enable a user, customer, or other authorized entity to determine

whether to accept a system or component.

AEO Authorised Engineering Organisation

Analysis (as defined in ISO 24765) the process of studying a system by partitioning the system

into parts (functions, components, or objects) and determining how the parts relate to each

other

ASA Asset Standards Authority

T MU AM 06004 ST




BR business requirement

BRS a type of specification document that contains business requirements

DE digital engineering

Demonstration (as defined in ISO 24765) a dynamic analysis technique that relies on

observation of system or component behaviour during execution, without need for post-

execution analysis, to detect errors, violations of development standards, and other problems

Factory acceptance test acceptance test carried out at the vendor premises

FAT factory acceptance test

IFAT integrated factory acceptance test

INCOSE International Council on Systems Engineering

Inspection (as defined in ISO 24765) a static analysis technique that relies on visual

examination of development products to detect errors, violations of development standards, and

other problems

Modelling (as defined in ISO 24765) representing a real world process, device, or concept

NA not available, not applicable

Owner (of a requirement) is the entity responsible for meeting the requirement

Requirement (as defined in ISO 29148) statement which translates or expresses a need and its

associated constraints and conditions

Review a method to provide assurance by a competent person that an engineering output

complies with relevant standards and specific requirements is safe and fit for purpose

SAT site acceptance test

Simulation (as defined in ISO 24765) a model that behaves or operates like a given system

when provided a set of controlled inputs

SIT system integration testing

Site acceptance test acceptance test carried out at the destination site

SR system requirement

SRS a type of specification document that contains system requirements

SSR subsystem requirement

SSRS a type of specification document that contains subsystem requirements

Technical requirement a requirement associated with a physical asset, not a process or

general contract requirement

T MU AM 06004 ST




Test (as defined in ISO 24765) an activity in which a system or component is executed under

specified conditions, the results are observed or recorded, and an evaluation is made of some

aspect of the system or component

TfNSW Transport for New South Wales

UAT user acceptance test

Uniclass 2015 a unified classification system for all sectors of the UK construction industry

Validation (as defined in ISO 9000) confirmation, through the provision of objective evidence,

that the requirements for a specific intended use or application have been fulfilled

Verification (as defined in ISO 9000) confirmation, through the provision of objective evidence,

that specified requirements have been fulfilled

5. TfNSW requirements schema The TfNSW requirements schema comprises a standard structure for requirements to enable

the free exchange of requirements information between multiple parties using different

requirements management tools.

The schema identifies the information types (metadata) needed for each requirement, and

provides a standard configuration for requirements management.

The schema identifies the information that is needed for each requirement and standard field

names that can be used by diverse requirements management tools.

The schema describes a data model for the organisation of requirements, and provides a

framework for requirements management.

ISO 15288 Systems and software engineering — System life cycle processes specifies the life

cycle model management process and the International Council on Systems Engineering

(INCOSE) Systems Engineering Handbook specifies the 'V' model. Figure 2 in Section 9 shows

how the schema integrates with the engineering life cycle 'V' model.

ISO 15288 and ISO 29148 Systems and software engineering — Life cycle processes —

Requirements Engineering specify the technical processes of stakeholder requirements

definition, requirements analysis and architectural design. The schema allows for the

management of requirements throughout these technical processes during requirements

decomposition, allocation and solution development.

ISO 15288 and ISO 29148 specify the technical processes of verification and validation and

ISO 15288 specifies the technical processes of integration and transition. The schema provides

a mechanism for tracing integration and composition of a solution throughout these technical

processes.

The requirements schema provides a standard framework for the following activities:

• structuring of requirements

T MU AM 06004 ST




• structuring of verification and validation activity evidence

• linking requirements to provide traceability through tracking the requirement decomposition

from system level to subsystem level, and finally to the detailed solution design

• providing traceability through linking verification and validation items to requirements to

ensure that the solution is verified and validated

Appendix A contains a worked example of the requirements schema.

Organisations may include additional information fields to meet their specific requirements,

verification and validation management needs.

6. Structuring requirements information The requirements schema consists of a number of elements.

The requirements element of the schema is used to store and manage requirements. It can be

used for business requirements, system requirements or subsystem requirements. The

requirements element format is the same for each type of requirement.

6.1. Requirement element-level information Requirement element-level information provides identifying and management metadata

regarding a particular requirement element containing a collection of requirements.

Each requirement element shall be recorded with its own identifying and administrative

information. Table 1 shows the mandatory information fields (with the exception of the optional

additional DE information in grey shade) for each requirement element.

Table 1 - Requirement element-level information

Field name Description Type Occurs DE field name

Project (DE) Title of the project String One Project name

Type Type of the requirement element. Element type is used to differentiate between business requirements, system requirements and subsystem requirements

String One Type

Name Name of the requirement element String One Document title

Document number (DE)

Project allocated document number of the element

String One Document number

Sources Source(s) of the requirement element String One or more

Source document number

Owner Owner of the requirement element. The entity responsible for meeting the requirement

String One Contracted organisation name

T MU AM 06004 ST





Owner code (DE)

Owner / service provider code of the requirement element.

String One Contracted organisation code

Release date

The date that the version was released

Date One Date released

Version The version number of the requirement element

Number One Document version number

Element status

The status of the requirement element – draft or approved

String One State code

6.2. Requirement management information Table 2 shows the mandatory set of information fields (with the exception of optional additional

DE information in grey) that shall be recorded for each requirement. However, for fields where

“Occurs” has a possible value of zero, it is permissible for the field to be empty.

Table 2 - Requirement management information

Field name Description Values Type Occurs DE field name

Identifier Requirement identifier unique for the project. Recommend that the requirement identifier is automatically generated by a tool.

text (preferably automatic tool-generated string)

String One Identifier

Object type Describes the object type in the schema

• Requirement: a need within the scope of work that needs to be delivered

• Heading: a descriptive title or subject division used to structure a set of requirements or other objects

• Context: a pretext or setting, to be read with the subsequent requirement(s) for full understanding

• Information: an articulation of facts outside of the scope of work (in the domain or delivered by another scope of work)

• Scope: a physical or functional limitation of applicability or extent of relevance or boundary of scope of work

• Term: a phrase, definition or acronym used to describe something within the scope of work

String One Object type

T MU AM 06004 ST





Requirement type

Type of requirement • Technical requirement: a property of the operational product (that exists within the finished product)

• Process requirement: an action or step taken to deliver the product (that does not exist within the finished product)

String Zero or one

Requirement type

Requirement level

Level of requirement (within the requirement hierarchy)

• Business requirement • System requirement • Subsystem requirement

String One Requirement level

Description Requirement item description text.

Text String One Description

Source Source of the requirement.

String String One or more

Document number

Allocation Anticipated apportionment of requirement at decomposition (to be substantiated with traceability). Business requirements are allocated to system requirements. System requirements are allocated to subsystems requirements.

Text String Zero1 or more

Allocation

Uniclass 2015 asset location code (DE)

Required to the level of information specified in DE Standard (DMS-ST-207). Code identifying the location type. Typically NA to BRs and most SRs

Refer to DE Project Data Schema

String One or more

Uniclass 2015 asset location code

Uniclass 2015 asset location title (DE)

Required to the level of information specified in DE Standard (DMS-ST-207). Title identifying the location type. Typically NA to BRs and most SRs


String One or more

Uniclass 2015 asset location title

Asset location code (DE)

Code identifying the location instance. Typically NA to BRs and most SRs


String One or more

Asset location code

1 The “occurs” value is zero for Subsystem Requirements, as they cannot be further allocated.

T MU AM 06004 ST





Discipline code (DE)

Engineering or other related discipline responsible for requirement satisfaction, e.g. Civil. Typically NA to BRs and most SRs


String One or more

Discipline code

Sub-discipline code (DE)

Required where an appropriate sub-discipline is available e.g. Drainage. The sub-discipline responsible for requirement satisfaction. Typically NA to BRs and most SRs


String One or more

Sub-discipline code

Uniclass 2015 asset code (DE)

Required for technical requirements. Required to level of information specified in DE Standard (DMS-ST-207). Code identifying the asset type. Typically NA to BRs and most SRs


String One or more

Uniclass 2015 asset code

Uniclass 2015 asset title (DE)

Required for technical requirements. Required to level of information specified in DE Standard (DMS-ST-207). Title identifying the asset type. Typically NA to BRs and most SRs


String One or more

Uniclass 2015 asset title

Compliance status

Whether the designed solution meets the requirements. The status may change as the solution is developed. A partially compliant status indicates that only some of the necessary compliance activities have been completed. The Remarks field is used to indicate the reason for the partially compliant status.

• Compliant • Compliant with concession • Non-compliant • Partially compliant (or

Compliant at Interface) • Not applicable • Pending (or ‘to be

determined’ or ‘no information’)

String One Compliance status

T MU AM 06004 ST





Criticality Requirement criticality for the solution, or vital to safety/mission. Essential means it is mandatory (shall), desirable means it is highly recommended (should), and optional means the deliverer can choose to implement the requirement or not. A child requirement cannot be at a higher criticality than the parent requirement

• Essential • Desirable • Optional

String One Criticality

Limit of scope

The limit of the scope covered by the requirement. This can be geographical extent of locations or the scope of works. Certain requirements such as for control & communications systems, may have multiple limits of scope due to the distributed nature of their functions.

• Text String One or more

Limit of scope

Owner Requirement owner, or the sponsor of the requirement. There may be projects with some co-owned requirements, but a single accountable owner should be identified and agreed where practicable

• Text String One Project contract code

Work package (DE)

Required for system requirements (SR) and subsystem requirements (SSR). Refers to the Work Package that includes the activity where a requirement will be satisfied. NA to BRs. There may be multiple Work packages associated with a requirement


DE Project Work package code

T MU AM 06004 ST





Proposed verification method

Verification method used to verify that the solution will meet the requirements. The proposed verification method is not applicable (NA) for business requirements. Verification takes place during the requirements delivery phase as the system solution is designed and delivered

• Review • Analysis • Modelling • Simulation • Certification • Inspection • Demonstration • Test • NA (BRs only)

String One or more


Proposed validation method

Validation method used to validate that the built solution will meet the requirements. The proposed validation method is NA for system requirements and subsystem requirements.

• Review • Analysis • Modelling • Simulation • Certification • Demonstration • Test • Inspection • NA (SR and SSR only)

String One Proposed validation method

Validation test type

If the validation method is a test, it indicates which kind of test is expected.

• SIT • UAT • NA

String One or more


Rationale Provide the reason for the requirement. This field needs to be completed only if the source field does not provide the source of the requirement.

• Text String Zero or one

Rationale

Remarks Any remark, comment, notes or explanations for the requirement. Remarks could indicate the requirement type, such as a safety requirement or interface requirement. Remarks should not change the requirement meaning. If so, new requirements should be considered.

• Text String Zero or more

Remarks

T MU AM 06004 ST





Requirement delivery phase

The project phase or milestone for requirement delivery.

• Concept • Specify • Procure • Design • Manufacture • Build • Integrate • Accept • Operate • Maintain • Evolve • Dispose/renew/recycle

String One or more

Project milestone description

Requirement approval status

Status to assess the requirement maturity and to support the requirement development life cycle.

• Draft: Author has created, or elicited from Owner or stakeholder input, a new draft requirement for potential inclusion in the specification

• Candidate: Owner has been identified for the requirement, which is now a candidate for inclusion in the specification

• Agreed: Owner has agreed to sponsor the requirement to Governance for inclusion in the specification

• Approved: Governance has approved the requirement for inclusion in the specification. All requirements need to be approved prior to award

• Cancelled: The requirement has been cancelled by: • Author if Draft • Owner if Candidate • Governance if Agreed • CAP if Approved

String One Requirement approval status

T MU AM 06004 ST





Satisfies links

Also referred to as “Parent Identifier”. A requirement can satisfy higher level Parent requirements. Identifier(s) of the parent requirement for traceability; Business Requirement(s) or System Requirement(s). Field not applicable if requirement is from the highest level BRS (initial top level BRS such as a program level BRS). Project level BRS requirements developed from a program level BRS will require a parent identifier for traceability.


Satisfies links

7. Structuring verification information The verification element of the schema is used to manage verification activities associated with

the requirements, including tracing to requirements and recording evidence.

7.1. Verification element-level information Table 3 contains the mandatory information fields (with the exception of the optional additional

DE information in grey shade) needed for each verification element containing a collection of

verification activities.

Table 3 - Verification element-level information


Project (DE) Title of the project. String One Project name

Type Type of verification element. Element type used to differentiate verification element from other elements.

String One Type

Name Name of the verification element. String One Document title

Document number (DE)

Project allocated document number of the verification element.

String One Document number

Owner Owner of the verification element. String One Contracted organisation name

Owner code (DE)

Owner service provider code of the verification element.

String One Contracted organisation code

Release date The date that the version was released.

Date One Date released

T MU AM 06004 ST





Version The version number of the verification element.

Number

One Document version number

Element status

The status of the verification element – draft or approved.

String One State code

7.2. Verification activity information Table 4 contains the mandatory information fields (with the exception of the optional additional

DE information in grey shade) needed for each verification activity. However, for fields where

“Occurs” has a possible value of zero, it is permissible for the field to be empty.

Table 4 - Verification activity information


Identifier Verification activity identifier unique for the project

• Text String One Identifier

Description Verification activity item text

• Text String One Description

Method Verification method. It is used to ensure requirements are covered by the proper type of verification items.

• Review • Analysis • Modelling • Simulation • Certification • Type approval • Demonstration • Inspection • Test

String One or more

Method

Remarks (or Rationale)

Explanation of the verification method or rationale as to how and why this verification activity is needed.


Remarks

Status Status to assess verification activity item maturity and support its life cycle

• Draft • Candidate • Agreed • Approved • Cancelled

String One Status

Success criteria

Verification activity item success criteria.

• Text String One Success criteria

Verification outcome

Verification item outcome details.

• Text String One or more2

Verification outcome

2 Value of “occurs” is zero until verification method is executed

T MU AM 06004 ST





Test type If the verification method is a test, then this specifies the test type. If verification method is not a test, then Test Type is NA

• FAT

• IFAT

• SAT

• SIT

• NA

String One or more

Test type

Result Verification activity item actual result.

• Passed • Failed • Blocked • Pending

String One3 Result

Evidence Document number of the file containing the evidence. This could be a document, model, survey, test results, meeting/review notes, and so on.

• Text One4 Document Number

Executed by Person names and roles executing the verification item


Contracted Organisation Code

Executed on The verification item execution date

• Text Date One6 Executed on

Execution comments

The verification item execution comments


Execution comments

Verifies links The verification link identifier to the requirement that is under verification


Verifies links

8. Structuring validation information The validation element of the schema is used to manage validation activities associated with the

requirements, including tracing to requirements and recording evidence.

8.1. Validation element–level information Table 5 contains the mandatory information fields (with the exception of the optional additional

DE information in grey shade) needed for each validation element containing a collection of

validation activities.

Table 5 - Validation element-level information


Project (DE) Title of the project String One Project Name

3 Value of “occurs” is zero until verification method is executed 4 Value of “occurs” is zero until verification method is executed and evidence is available 5 Value of “occurs” is zero until verification method is executed 6 Value of “occurs” is zero until verification method is executed

T MU AM 06004 ST





Type Type of validation element, and is used to differentiate the validation element from other elements.

String One Type

Name Name of the validation element. String One Document Title

Document Number (DE)

Project allocated document number of the validation element.

String One Document Number

Owner Owner of the validation element. String One Contracted Organisation Name

Owner code (DE)

Owner service provider code of the validation element.

String One Contracted Organisation Code

Release date The date that the version was released.

Date One Date Released

Version The version number of the validation element.

Number One Document Version Number

Element status

The status of the validation element – draft or approved.

String One State Code

8.2. Validation activity information Table 6 contains the minimum mandatory element information fields (with the exception of the

optional additional DE information in grey shade) needed for each validation activity. However

for fields where “Occurs” has a possible value of zero, it is permissible for the field to be empty.

Table 6 - Validation activity information


Identifier Validation activity identifier unique for the project.

• Text String One Identifier

Description Validation activity item text. • Text String One Description

Method Validation method, used to ensure requirements are covered by the proper type of validation items

• Review • Analysis • Modelling • Simulation • Certification • Demonstration • Inspection • Test

String One or more

Method

Remarks Additional explanation of the validation method


Remarks

Status Status to assess validation item maturity and support its life cycle

• Draft • Candidate • Agreed • Approved • Cancelled

String One Status

T MU AM 06004 ST





Success criteria

Validation activity item success criteria


Success criteria

Validation outcome

Validation activity item outcome


Validation outcome

Test type If validation method is a test, then specifies the test type. If validation method is not a test, then Test Type is NA.

• SIT • UAT • NA

String One Test type

Result Validation activity item actual result

• Passed • Failed • Blocked • Pending

String One Result

Evidence Document number of the file / record containing the evidence. This could be a document, model, survey, test results, meeting/ review notes etc.

• Text String One8 Document Number

Executed by Person names and roles executing the validation activity item

• Text String One9 or more

Contracted Organisation Code

Executed on The validation activity item execution date.

• Text Date One Executed on

Execution comments

The validation activity item execution comments.


Execution comments

Validates links

The validation activity link identifier to a requirement


Validates links

9. Linking and traceability The links element of the schema is used to manage traceability between other elements of the

schema. The linkages are 'satisfies', 'verifies' or 'validates'.

The one way links list the relationships between specific requirements (business, system, and

subsystem) and their respective verification and validation activities.

Figure 1 illustrates these linking and traceability requirements.

7 Value of “occurs” is zero until validation method is executed 8 Value of “occurs” is zero if until validation method is executed 9 Value of “occurs” is zero if until validation method is executed

T MU AM 06004 ST




Business Requirement

Satisfies(m:m)

System requirements

Subsystem requirements

Satisfies(m:m)

Verification activities

Validationactivities

Validates(m:m)

Project Information

Verifies(m:m) Verifies

(m:m)

Figure 1 – Requirement Schema link information

Each business requirement shall have one or more satisfies links from system requirements.

For example, business requirement ABC_BR_001, the passenger waiting time shall be

maximum 10 minutes at stations in peak periods is satisfied by the system requirement

ABC_SR_001; the system shall operate with service intervals of 8 ± 2 minutes.

Each system requirement shall have one or more satisfies links from subsystem requirements, if

there are subsystems.

For example ABC_SR_001, the system shall operate with service intervals of 8 ± 2 minutes in

peak periods is satisfied by multiple subsystem requirements related to train acceleration and

top speed, electrical traction supply capacity, track rating, and the signalling system capacity.

The “many-to-many (m:m)” relationship means that one or more parent requirements are

satisfied by one or more child requirements. Generally one parent requirement is satisfied by

one or more child requirements (that is, a trunk, branch and leaf structure), but in some cases a

child requirement can satisfy more than one parent.

Each system requirement shall have one or more verifies links from verification activities.

Each subsystem requirement, if there are subsystems, shall have one or more verifies links

from verification activities.

Each business requirement shall have one or more validates links from validation activities.

For example, business requirement ABC_BR_001, the passenger waiting time shall be

maximum 10 minutes at stations in peak periods can be validated early in the system life cycle

T MU AM 06004 ST




by means of traffic modelling and analysis before design commences, and again validated at

the system acceptance and handover by means of live demonstration and “stopwatch” tests.

Table 7 shows the permitted terms and descriptions for links.

Table 7 - Link information

Link name

Description Source element Target element

Satisfies Requirement decomposition. Source element needs to be the lower level and target element the upper level (for example: from system requirements to business requirements)

Specific identified requirement (lower-level)

Specific identified requirement (higher-level)

Verifies Requirement verification Verification Requirement

Validates Requirement validation Validation Requirement

Linking verification and validation items to requirements ensures that the solution can be fully

demonstrated to fulfil the requirements.

Using the requirements schema for all stages of a project allows for progressive verification

through the stages and validation at system acceptance. Figure 2 illustrates how the verification

and validation of requirements link across the engineering life cycle through decomposition and

solution definition to solution integration, composition, and final system acceptance.

T MU AM 06004 ST




validates

verifies

satis

fies

satisfies

Time

Decomposition and solution definition

Business Requirements Validation

System Requirements Verification

Subsystem Requirements

Solutio

n Inte

gratio

n and

Com

posit

ion

verifi

es

ConceptFeasibility

System Design

SubsystemDesign

Procurement, Fabrication,

Construction, Installation

Subsystem Integration and

Verification

System Integration and

Verification

System Acceptance Validation

Requirements Repository

Figure 2 - Relationship between requirements and verification and validation

T MU AM 06004 ST




Appendix A Example schema implementation (non-DE enabled projects) Section A.1 to Section A.5 provide an example implementation of the requirements schema for a fictitious project 'ABC'.

The example contains requirement elements of:

• business requirements

• system requirements

• subsystem requirements

The verification and validation elements provide criteria for progressively assuring that the requirements are achieved.

The links for connecting these schema elements are marked as 'satisfies', 'verifies' or 'validates'.

'Satisfies links' show the system requirements that satisfy the “parent” business requirements, and the subsystem requirements that satisfy the “parent” system requirements.

'Verifies links' show verification activities that verify system requirements and subsystem requirements.

'Validates links' include validation activities that validate the business requirements.

T MU AM 06004 ST




A.1. Example business requirements (non-DE) Type Business requirements (BR)

Name ABC project business requirements

Owner Rail network planning

Sources Customer survey ABC Business case ABC

Release date 01/04/2014

Version 1.0

Element status approved

Identifier Object type

Reqt type

Reqt Level

Description Source Allocation Compliance status

Criticality Proposed verification method

Limit of scope

Owner Proposed validation method


Rationale Remarks Requirement delivery phase


ABC_BR_001 Reqt Technical BR The passenger waiting time shall be maximum 10 minutes at stations in peak periods.

TfNSW/Transport Planning

System Compliant Essential Simulation A station B station C station D station

Planning Manager

Test UAT Based on customer survey ABC.

This is for the initial operation of the system.

Accept Agreed

ABC_BR_002 Reqt Technical BR The passenger waiting time shall be maximum 15 minutes at stations in off peak periods.



Planning Manager

Test UAT Based on customer survey ABC.


Accept Agreed

ABC_BR_003 Reqt Technical BR The passenger journey time shall be maximum 2 minutes between adjacent stations.



Planning Manager

Test UAT Based on business case ABC.


Accept Agreed

T MU AM 06004 ST




A.2. Example system requirements (non-DE) Type System requirements (SR)

Name ABC project system requirements

Owner Systems engineering

Sources Business requirements


Version 1.0



Reqt type

Reqt level



Limit of scope





Satisfies Links

ABC_SR_001 Reqt Technical SR The system shall operate with service intervals of 8 ± 2 minutes in peak periods.

Service planning meeting minutes

Train subsystem

Compliant Essential Test A station B station C station D station

Systems Manager

NA NA This is for the initial operation of the system.

Accept Agreed ABC_BR_001

ABC_SR_002 Reqt Technical SR The system shall operate with service intervals of 13 ± 2 minutes in off peak periods.


Train subsystem


Systems Manager

NA NA This is for the initial operation of the system.

Accept Agreed ABC_BR_002

ABC_SR_003 Reqt Technical SR The system shall operate with travel times of 90 ± 30 seconds between adjacent stations.


Train subsystem


Systems Manager

NA NA Accept Agreed ABC_BR_003

T MU AM 06004 ST




A.3. Example subsystem requirements (non-DE) Type Subsystem requirements (SSR)

Name ABC project train subsystem requirements

Owner Rolling stock


Sources System requirements

Version 1.0



Reqt type

Reqt level



Limit of scope





Satisfies Links

ABC_SSR_001

Reqt Technical SSR The train shall travel at speeds from 0 km/h to 100 km/h.

Train perform model & analysis

Propulsion subsystem

Compliant Essential Review Train Rolling Stock Manager

NA NA Needed to meet the service journey time & T/T

Analysis XYZ shows that this speed is required

Accept Agreed ABC_SR_001 ABC_SR_002 ABC_SR_003

ABC_SSR_002

Reqt Technical SSR The train shall accelerate from 0 km/h to 100 km/h within 30 seconds.


Propulsion subsystem



Analysis XYZ shows that this acceleration is required.


ABC_SSR_003

Reqt Technical SSR The train shall decelerate from 100 km/h to 0 km/h within 30 seconds.


Braking subsystem



Analysis XYZ shows that this deceleration is required.


T MU AM 06004 ST




A.4. Example verification activities (non-DE) Type Verification

Name ABC project verification

Owner Systems assurance


Version 1.0


Identifier Description Method Remarks Status Success criteria Verification outcome Test Type

Result Evidence Executed by

Executed on Execution comments

Verifies links

ABC_VER_001 For 3 hours run trains at intervals of 8 minutes from A station to D station, stopping at B station and C station for 2 minutes. At each station measure the arrival time of each train.

Test Test carried out without passengers.

Agreed Trains at intervals of 8 ± 2 minutes at A station, B station, C station, and D station

Train intervals: A station: 8 minutes B station: 8 minutes C station: 9 minutes D station: 9 minutes

SIT Passed Data Logger files

D Person 01/06/2014 The train interval was not always 8 minutes for trains.

ABC_SR_001

ABC_VER_002 For 3 hours run trains at intervals of 13 minutes from A station to D station, stopping at B station and C station for 2 minutes. At each station measure the arrival time of each train.


Agreed Trains at intervals of 13 ± 2 minutes at A station, B station, C station, and D station

Train intervals: A station: 14 minutes B station: 13 minutes C station: 13 minutes D station: 14 minutes


D Person 01/06/2014 The train interval was not always 13 minutes for trains.

ABC_SR_002

ABC_VER_003 For 3 hours run trains at intervals of 8 minutes from A station to D station, stopping at B station and C station for 1 minute. At each station measure the arrival time and departure time of each train.


Agreed Travel times of 90 ± 30 seconds between adjacent stations.

Travel intervals: A to B station : 80 seconds B to C station: 100 seconds C to D station: 120 seconds

SIT Pending ABC_SR_003

ABC_VER_004 Verify the materials used for the rails support a train travelling at 100 km/h.

Test Test carried out on test track.

Agreed Trains can travel at speeds from 0 km/h to 100 km/h.

Speeds up to 120 km/h SIT Passed Data Logger files

D Person 01/06/2014 Design document XXX chapter Y.Z: Usage of ballast less track supporting speeds up to SSS km/h.

ABC_SSR_001

ABC_VER_005 Accelerate the train from 0 km/h to 100 km/h. Allow the train to travel at 100 km/h for 5 minutes.


Agreed The train travels at speeds from 0 km/h to 100 km/h

Speeds up to 100 km/h


D Person 01/06/2014 ABC_SSR_001

ABC_VER_006 Accelerate the train from 0 km/h to 100 km/h as rapidly as possible.


Agreed The train accelerates from 0 km/h to 100 km/h within 30 seconds.

Accelerates from 0 km/h to 100 km/h in 20 seconds



ABC_VER_007 Decelerate the train from 100 km/h to 0 km/h as rapidly as possible.


Agreed The train decelerates from 100 km/h to 0 km/h within 30 seconds.

Decelerate from 100 km/h to 0 km/h in 25 seconds.



T MU AM 06004 ST




A.5. Example validation activities (non-DE) Type Validation

Name ABC project validation



Version 1.0


Identifier Description Method Remarks Status Success criteria

Validation outcome Test type

Result Evidence Executed by

Executed on

Execution comments

Validates links

ABC_VAL_001 For 3 hours run trains at intervals of 8 minutes from A station D station, stopping at B station, C station and D station. Unload and load 200 passengers at each station. At each station measure the waiting time for passengers.

Test Test carried out with passengers.

agreed Maximum passenger waiting time is 10 minutes.

Maximum waiting times: A station: 8 minutes B station: 8 minutes C station: 9 minutes D station: 10 minutes

UAT Passed Data logs, Stopwatch records, customer satisfaction surveys

E. Person 10/06/2014 D station had the longest waiting time.

ABC_BR_001 ABC_BR_002

ABC_VAL_002 For 3 hours run trains at intervals of 8 minutes from A station D station, stopping at B station, C station and D station. Unload and load 200 passengers at each station. At each station measure the arrival time and departure time of each train.

Test Test carried out with passengers.

agreed The passenger journey time is maximum 2 minutes between adjacent stations.

Maximum journey times: A station to B station: 2 minutes B station to C station: 2 minutes C station to D station: 2 minutes

UAT Passed Data logs, Stopwatch records, customer satisfaction surveys

E. Person 10/06/2014 ABC_BR_003

T MU AM 06004 ST




Appendix B Example schema implementation (DE-enabled project) Section B.1 to Section B.5 provide an example implementation of the requirements schema for a fictitious rail project 'DEF'.

The example contains requirement elements (including additional optional fields for DE projects, shaded grey) of:

• business requirements

• system requirements

• subsystem requirements

The verification and validation elements provide criteria for assuring that the requirements are achieved (including additional optional fields for DE projects, shaded grey).

The links for connecting these elements are marked as 'satisfies', 'verifies' or 'validates'.

'Satisfies links' show the system requirements that satisfy the “parent” business requirements, and subsystem requirements that satisfy the “parent” system requirements.

'Verifies links' show verification activities that verify system requirements and subsystem requirements.

'Validates links' include validation activities that validate the business requirements.

T MU AM 06004 ST




B.1. Example business requirements (DE-enabled project) Project DEF Project (DE)

Type Business requirements

Name DEF project business requirements

Document number DEF-SPC-BRS-00001 (DE)

Owner Transport Access Program

Owner code AEO123 (DE)

Sources Customer survey DEF Business case DEF


Version 1.0



Reqt type

Reqt level

Description Source Allocation Uniclass 2015 asset location code (DE)







Compliance status


Limit of scope

DEF_BR_001 Reqt Technical BR Passenger access to public transport shall comply with current access legislation.

GWHEK2M-JAJV-NWW-AR-ANA-00001

System Co_80 Transport complexes

NWW AR AT EF_35 Stairs and ramps Compliant Essential NA

DEF_BR_002 Reqt Technical BR Transport interchanges shall provide accessible amenities.


System Co_80 Transport complexes

NWW AR AT EF_40 Signage, fittings, furnishings and equipment

Compliant Essential NA

Table columns continued below.

Owner Work package (DE)





Transport Service Planning Manager

WG01 WG02

Test UAT Based on customer survey DEF.

Accept Agreed

Transport Service Planning Manager

WG01 WG02

Test UAT Based on customer survey DEF.

Accept Agreed

T MU AM 06004 ST




B.2. Example system requirements (DE-enabled project) Project DEF Project (DE)

Type System requirements

Name DEF project system requirements

Document number DEF-SPC-SRS-0001 (DE)

Owner Systems engineering


Sources Business requirements


Version 1.0



Reqt type

Reqt level








Compliance status

Criticality

DEF_SR_001 Reqt Technical SR Step-free access shall be provided at all heavy rail stations.


Access subsystem

En_80_50_74 Railway stations HRS AR AT Ss_35 Stair and ramp systems

Compliant Essential

DEF_SR_002 Reqt Technical SR Passenger lifts shall be provided at HRS where gradients exceed maximum.


Access subsystem

En_80_50_74 Railway stations HRS ME VT Ss_80_50_60 Passenger and goods lift systems

Compliant Essential

DEF_SR_003 Reqt Technical SR Step-free access shall be provided at all ferry wharves.


Access subsystem

En_32_50_98 Wharfs MAS AR AT Ss_35 Stair and ramp systems

Compliant Essential

DEF_SR_004 Reqt Technical SR Passenger lifts shall be provided at MAS where gradients exceed maximum.


Access subsystem

En_32_50_98 Wharfs MAS ME VT Ss_80_50_60 Passenger and goods lift systems

Compliant Essential

DEF_SR_005 Reqt Technical SR Existing toilet facilities at stations shall be accessible and family friendly.


Toilet subsystem

SL_35_80_68 Public toilets HRS AR AT Ss_40_15_75 Sanitary appliance systems

Compliant Essential

DEF_SR_005 Reqt Technical SR Existing toilet facilities at wharves shall be accessible and family friendly.


Toilet subsystem

SL_35_80_68 Public toilets MAS AR AT Ss_40_15_75 Sanitary appliance systems

Compliant Essential



Limit of scope






Satisfies links

Test HRS AEO123 WG01 NA NA Compliance with DSAPT Accept Agreed DEF_BR_001



Test NWW AEO123 WG02 NA NA Compliance with DSAPT Accept Agreed DEF_BR_001



T MU AM 06004 ST




B.3. Example subsystem requirements (DE-enabled project) Project DEF Wollstonecraft TAP Project (DE)

Type Subsystem requirements

Name DEF project Wollstonecraft subsystem requirements

Document number DEF-SPC-SSRS-00001 (DE)

Owner Access



Sources System requirements

Version 1.0



Reqt type

Reqt level








Compliance status

Criticality

DEF_SSR_001 Reqt Technical SSR Accessible routes shall be created and identified.


Stations & Buildings

SL_90_10_96 Wheelchair circulation spaces

WLS AR AT Ss_40_10 Signage systems Compliant Essential

DEF_SSR_002 Reqt Technical SSR Step-free access shall be compliant with current legislation.



En_90_10_02 Access stairways and walkways

WLS AR AT Ss_35 Stair and ramp systems

Compliant Essential

DEF_SSR_003 Reqt Technical SSR Lifts shall be provided where gradient and station layout restricts accessibility.



SL_90_10_47 Lifts WLS ME VT Ss_80_50_60 Passenger and goods lift systems

Compliant Essential

DEF_SSR_004 Reqt Technical SSR Toilet facilities shall be upgraded to comply with current access legislation.



SL_35_80_68 Public toilets WLS AR AT Ss_40_15_75_02 Accessible WC package systems

Compliant Essential

DEF_SSR_005 Reqt Technical SSR Toilet facilities shall be upgraded to provide baby-change facilities.



SL_35_80_68 Public toilets WLS AR AT Pr_40_20_76_06 Baby changing units

Compliant Essential



Limit of scope






Satisfies Links

review WLS AEO123 WG01.01 Inspection SAT Comply with DSAPT Accept Agreed DEF_SR_001





T MU AM 06004 ST




B.4. Example verification activities (DE-enabled project) Project DEF Wollstonecraft Project (DE)

Type Verification

Name DEF Wollstonecraft TAP project verification

Document number DEF-RPT-VV-0001 (DE)




Version 1.0


Identifier Description Method Remarks Status Success criteria Verification outcome

Test Type

Result Evidence (DE)

Executed by

Executed on

Execution comments Verifies links

DEF_VER_001 BIM/DE model validation for compliance.

Inspection Agreed Continuous step-free access route, clearly signposted. Gradients do not exceed ##.

All objects identified in the BIM model.

NA Passed GWHEK2M-JAJV-NWW-AR-M3D-00005

D Person 01/04/2013 Model walkthrough and gradient measures extracted from BIM model.

DEF_SSR_001 DEF_SSR_002 DEF_SSR_003

DEF_VER_002 BIM/DE model validation for compliance.

Inspection Agreed Objects identified in appropriate locations, as per TfNSW requirements.

All objects identified in the BIM model.

NA Passed GWHEK2M-JAJV-NWW-AR-M3D-00005

D Person 01/04/2013 Model walkthrough. DEF_SSR_004 DEF_SSR_005

DEF_VER_003 On-site inspection and walk-through.


Continuous access confirmed. Gradients compliant.

NA Passed GWHEK2M-JAJV-NWW-AR-ITC-00006

D Person 01/06/2014 DEF_SSR_001 DEF_SSR_002 DEF_SSR_003

DEF_VER_004 On-site inspection of facilities.

Inspection Agreed Facilities and fixtures found in-situ.

Facilities and fixtures available on site.

NA Passed GWHEK2M-JAJV-NWW-AR-ITC-00006

D Person 01/06/2014 DEF_SSR_004 DEF_SSR_005

T MU AM 06004 ST




B.5. Example validation activities (DE-enabled project) Project DEF Project (DE)

Type Validation

Name DEF project validation

Document number DEF-RPT-VV-00001 (DE)




Version 1.0


Identifier Description Method Remarks Status Success criteria Validation outcome Test type

Result Evidence (DE)

Executed by

Executed on Execution comments

Validates links

DEF_VAL_001 Wollstonecraft: On-site inspection and walk-through.


Continuous access confirmed. Gradients compliant.

NA passed GWHEK2M-JAJV-NWW-AR-ITC-00006

D Person 01/06/2014 WLS only DEF_BR_001

DEF_VAL_002 Wollstonecraft: On-site inspection of facilities.

Inspection Agreed Facilities and fixtures found in-situ.

Facilities and fixtures available on site.

NA passed GWHEK2M-JAJV-NWW-AR-ITC-00006

D Person 01/06/2014 WLS only DEF_BR_002

t mu am 06004 st requirements schema

Documents