t mu am 06004 st requirements schema
TRANSCRIPT
© 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
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 3 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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 4 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 5 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 6 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 7 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 8 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 9 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 10 of 36
• 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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 11 of 36
Field name Description Type Occurs DE field name
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 12 of 36
Field name Description Values Type Occurs DE field name
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
Refer to DE Project Data Schema
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
Refer to DE Project Data Schema
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 13 of 36
Field name Description Values Type Occurs DE field name
Discipline code (DE)
Engineering or other related discipline responsible for requirement satisfaction, e.g. Civil. Typically NA to BRs and most SRs
Refer to DE Project Data Schema
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
Refer to DE Project Data Schema
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
Refer to DE Project Data Schema
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
Refer to DE Project Data Schema
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 14 of 36
Field name Description Values Type Occurs DE field name
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
• Text String One or more
DE Project Work package code
T MU AM 06004 ST
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 15 of 36
Field name Description Values Type Occurs DE field name
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 verification method
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
Validation test type
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 16 of 36
Field name Description Values Type Occurs DE field name
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 17 of 36
Field name Description Values Type Occurs DE field name
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.
• Text String One or more
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
Field name Description Type Occurs DE field name
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 18 of 36
Field name Description Type Occurs DE field name
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
Field name Description Values Type Occurs DE field name
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.
• Text String Zero or more
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 19 of 36
Field name Description Values Type Occurs DE field name
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
• Text String One or more5
Contracted Organisation Code
Executed on The verification item execution date
• Text Date One6 Executed on
Execution comments
The verification item execution comments
• Text String Zero or more
Execution comments
Verifies links The verification link identifier to the requirement that is under verification
• Text String One or more
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
Field name Description Type Occurs DE field name
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 20 of 36
Field name Description Type Occurs DE field name
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
Field name Description Values Type Occurs DE field name
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
• Text String Zero or more
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 21 of 36
Field name Description Values Type Occurs DE field name
Success criteria
Validation activity item success criteria
• Text String One or more
Success criteria
Validation outcome
Validation activity item outcome
• Text String One or more7
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.
• Text String Zero or more
Execution comments
Validates links
The validation activity link identifier to a requirement
• Text String One or more
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 22 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 23 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 24 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 25 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 26 of 36
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
Validation test type
Rationale Remarks Requirement delivery phase
Requirement approval status
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.
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_003 Reqt Technical BR The passenger journey time shall be maximum 2 minutes between adjacent stations.
TfNSW/Transport Planning
System Compliant Essential Simulation A station B station C station D station
Planning Manager
Test UAT Based on business case ABC.
This is for the initial operation of the system.
Accept Agreed
T MU AM 06004 ST
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 27 of 36
A.2. Example system requirements (non-DE) Type System requirements (SR)
Name ABC project system requirements
Owner Systems engineering
Sources Business requirements
Release date 01/05/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
Validation test type
Rationale Remarks Requirement delivery phase
Requirement approval status
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.
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_002
ABC_SR_003 Reqt Technical SR The system shall operate with travel times of 90 ± 30 seconds between adjacent stations.
Service planning meeting minutes
Train subsystem
Compliant Essential Test A station B station C station D station
Systems Manager
NA NA Accept Agreed ABC_BR_003
T MU AM 06004 ST
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 28 of 36
A.3. Example subsystem requirements (non-DE) Type Subsystem requirements (SSR)
Name ABC project train subsystem requirements
Owner Rolling stock
Release date 10/05/2014
Sources System requirements
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
Validation test type
Rationale Remarks Requirement delivery phase
Requirement approval status
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.
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 acceleration is required.
Accept Agreed ABC_SR_001 ABC_SR_002 ABC_SR_003
ABC_SSR_003
Reqt Technical SSR The train shall decelerate from 100 km/h to 0 km/h within 30 seconds.
Train perform model & analysis
Braking subsystem
Compliant Essential Review Train Rolling Stock Manager
NA NA Needed to meet the service journey time & T/T
Analysis XYZ shows that this deceleration is required.
Accept Agreed ABC_SR_001 ABC_SR_002 ABC_SR_003
T MU AM 06004 ST
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 29 of 36
A.4. Example verification activities (non-DE) Type Verification
Name ABC project verification
Owner Systems assurance
Release date 20/05/2014
Version 1.0
Element status approved
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.
Test Test carried out without passengers.
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
SIT Passed Data Logger files
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.
Test Test carried out without passengers.
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.
Test Test carried out on test track.
Agreed The train travels at speeds from 0 km/h to 100 km/h
Speeds up to 100 km/h
SIT Passed Data Logger files
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.
Test Test carried out on test track.
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
SIT Passed Data Logger files
D Person 01/06/2014 ABC_SSR_002
ABC_VER_007 Decelerate the train from 100 km/h to 0 km/h as rapidly as possible.
Test Test carried out on test track.
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.
SIT Passed Data Logger files
D Person 01/06/2014 ABC_SSR_003
T MU AM 06004 ST
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 30 of 36
A.5. Example validation activities (non-DE) Type Validation
Name ABC project validation
Owner Systems assurance
Release date 01/06/2014
Version 1.0
Element status approved
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 31 of 36
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 32 of 36
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
Release date 01/04/2014
Version 1.0
Element status approved
Identifier Object type
Reqt type
Reqt level
Description Source Allocation Uniclass 2015 asset location code (DE)
Uniclass 2015 asset location title (DE)
Asset location code (DE)
Discipline code (DE)
Sub-discipline code (DE)
Uniclass 2015 asset code (DE)
Uniclass 2015 asset title (DE)
Compliance status
Criticality Proposed verification method
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.
GWHEK2M-JAJV-NWW-AR-ANA-00001
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)
Proposed validation method
Validation test type
Rationale Remarks Requirement delivery phase
Requirement approval status
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 33 of 36
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
Owner code AEO123 (DE)
Sources Business requirements
Release date 01/05/2014
Version 1.0
Element status approved
Identifier Object type
Reqt type
Reqt level
Description Source Allocation Uniclass 2015 asset location code (DE)
Uniclass 2015 asset location title (DE)
Asset location code (DE)
Discipline code (DE)
Sub-discipline code (DE)
Uniclass 2015 asset code (DE)
Uniclass 2015 asset title (DE)
Compliance status
Criticality
DEF_SR_001 Reqt Technical SR Step-free access shall be provided at all heavy rail stations.
GWHEK2M-JAJV-NWW-AR-ANA-00002
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.
GWHEK2M-JAJV-NWW-AR-ANA-00002
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.
GWHEK2M-JAJV-NWW-AR-ANA-00002
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.
GWHEK2M-JAJV-NWW-AR-ANA-00002
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.
GWHEK2M-JAJV-NWW-AR-ANA-00002
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.
GWHEK2M-JAJV-NWW-AR-ANA-00002
Toilet subsystem
SL_35_80_68 Public toilets MAS AR AT Ss_40_15_75 Sanitary appliance systems
Compliant Essential
Table columns continued below.
Proposed verification method
Limit of scope
Owner Work package (DE)
Proposed validation method
Validation test type
Rationale Remarks Requirement delivery phase
Requirement approval status
Satisfies links
Test HRS AEO123 WG01 NA NA Compliance with DSAPT Accept Agreed DEF_BR_001
Test HRS AEO123 WG01 NA NA Compliance with DSAPT Accept Agreed DEF_BR_001
Test HRS AEO123 WG02 NA NA Compliance with DSAPT Accept Agreed DEF_BR_001
Test NWW AEO123 WG02 NA NA Compliance with DSAPT Accept Agreed DEF_BR_001
Test NWW AEO123 WG01 NA NA Compliance with DSAPT Accept Agreed DEF_BR_002
Test NWW AEO123 WG02 NA NA Compliance with DSAPT Accept Agreed DEF_BR_002
T MU AM 06004 ST
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 34 of 36
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
Owner code AEO123 (DE)
Release date 10/05/2014
Sources System requirements
Version 1.0
Element status approved
Identifier Object type
Reqt type
Reqt level
Description Source Allocation Uniclass 2015 asset location code (DE)
Uniclass 2015 asset location title (DE)
Asset location code (DE)
Discipline code (DE)
Sub-discipline code (DE)
Uniclass 2015 asset code (DE)
Uniclass 2015 asset title (DE)
Compliance status
Criticality
DEF_SSR_001 Reqt Technical SSR Accessible routes shall be created and identified.
GWHEK2M-JAJV-NWW-AR-ANA-00003
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.
GWHEK2M-JAJV-NWW-AR-ANA-00003
Stations & Buildings
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.
GWHEK2M-JAJV-NWW-AR-ANA-00003
Stations & Buildings
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.
GWHEK2M-JAJV-NWW-AR-ANA-00004
Stations & Buildings
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.
GWHEK2M-JAJV-NWW-AR-ANA-00004
Stations & Buildings
SL_35_80_68 Public toilets WLS AR AT Pr_40_20_76_06 Baby changing units
Compliant Essential
Table columns continued below.
Proposed verification method
Limit of scope
Owner Work package (DE)
Proposed validation method
Validation test type
Rationale Remarks Requirement delivery phase
Requirement approval status
Satisfies Links
review WLS AEO123 WG01.01 Inspection SAT Comply with DSAPT Accept Agreed DEF_SR_001
review WLS AEO123 WG01.01 Inspection SAT Comply with DSAPT Accept Agreed DEF_SR_001
review WLS AEO123 WG01.02 Inspection SAT Comply with DSAPT Accept Agreed DEF_SR_002
review WLS AEO123 WG01.03 Inspection SAT Comply with DSAPT Accept Agreed DEF_SR_005
review WLS AEO123 WG01.03 Inspection SAT Comply with DSAPT Accept Agreed DEF_SR_005
T MU AM 06004 ST
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 35 of 36
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)
Owner Systems assurance
Owner code AEO123 (DE)
Release date 20/05/2014
Version 1.0
Element status approved
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.
Inspection Agreed Continuous step-free access route, clearly signposted. Gradients do not exceed ##.
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
Requirements Schema Version 3.0
Effective date: 13 August 2021
© State of NSW through Transport for NSW 2021 Page 36 of 36
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)
Owner Systems assurance
Owner code AEO123 (DE)
Release date 01/06/2014
Version 1.0
Element status approved
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.
Inspection Agreed Continuous step-free access route, clearly signposted. Gradients do not exceed ##.
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