t-mu-am-06004-stREquirements Schema

Technical Note – TN 027: 20182018
For queries regarding this document

standards@transport.nsw.gov.au
www.transport.nsw.gov.au

Issue date: 09 August 2018
Effective date: 09 August 2018
Subject: Amendments to T MU AM 06004 ST

Requirements Schema, v2.0
This technical note is issued by the Asset Standards Authority (ASA) as an update to
T MU AM 06004 ST Requirements Schema, version 2.0.
The update includes amendments to the following to address some anomalies identified in the
methods of verification and validation:
• Table 4 Verification activity information
• Table 6 Validation activity information
• Section A.4 Example verification activities
This technical note will be incorporated in version 3.0 of T MU AM 06004 ST.
In accordance with T MU AM 06006 ST Systems Engineering the only difference between

verification and validation activities is that verification is performed against system requirements,
whereas validation is performed against business requirements.
If the validation activity information includes a ‘Test type’ attribute, then the verification activity
information shall also include a ‘Test type’ attribute.
There should be no difference between the ‘Method’ attributes in the verification and validation
activity information in Table 4 and Table 6.
To this effect, Table 4, Table 6 and the example in Section A.4 have been updated.
© State of NSW through Transport for NSW 2018 Page 1 of 5

Replace Table 4 Verification activity information in its entirety with the following:
Table 4 Verification activity information
Field name Description Values Type Occurs

Identifier Verification text string one
identifier unique for
the project.
Description Verification item text. text string one
Method Verification method. • review string one
It is used to ensure • analysis
requirements are
covered by the • modelling
proper type of • simulation
verification items. • demonstration
• inspection
• test
• NA
Remarks Additional text string zero or more
explanation of the
verification
method.
Status Status to assess • draft string one
verification item • review
maturity and support
its life cycle. • agreed
• cancelled
• NA
Success criteria Verification item text string one
success criteria.
Verification Verification item text string one
outcome outcome.
Test type If verification method • FAT string one
is a test, then this • IFAT
specifies the test type.
• SAT
• SIT
• NA
Result Verification item actual • passed string one
result. • failed
• blocked
• pending
• NA
Executed by Person names text string one or more
executing the
verification item.
Executed on The verification item text date one
execution date.
Execution The verification item text string zero or more
comments execution comments.

Replace Table 6 Validation activity information in its entirety with the following:
Table 6 – Validation activity information

Identifier Validation identifier text string one
unique for the
project.
Description Validation item text. text string one
Method Validation method. • review string one
It is used to ensure
• analysis
requirements are
covered by the • modelling
proper type of • simulation
validation items.
• demonstration
• inspection
• test
• NA
explanation of
validation method.

validation item • review
maturity and support
its life cycle. • agreed
• cancelled
• NA
Success criteria Validation item text string one
success criteria.
Validation Validation item text string one
outcome outcome.
Test type If validation method • FAT string one
is a test, then
• IFAT
specifies the test
type. • SAT
• SIT
• NA
Result Validation item actual • passed string one
result • failed
• blocked
• pending
• NA
executing the
validation item.
Executed on The validation item text date one
execution date.
Execution The validation item text string zero or more
comments execution comments.

Replace the contents in Section A.4 Example verification activities in its entirety with the following:
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 Result Executed by Executed on Execution comments Verifies links
type
ABC_VER_001 For 3 hours run trains at intervals of test Test carried out agreed Trains at intervals of Train intervals: SAT passed D Person 01/06/2014 The train interval was ABC_SR_001
8 minutes from A station to D without passengers. 8 ± 2 minutes at A station, B A station: 8 minutes not always 8 minutes
station, stopping at B station and C station, C station, and D station for trains.
station for 2 minutes. At each station B station: 8 minutes
measure the arrival time of each C station: 9 minutes
train.
D station: 9 minutes
ABC_VER_002 For 3 hours run trains at intervals of test Test carried out agreed Trains at intervals of Train intervals: SAT passed D Person 01/06/2014 The train interval was ABC_SR_002
13 minutes from A station to D without passengers. 13 ± 2 minutes at A station, B A station: 14 minutes not always 13 minutes
station, stopping at B station and C station, C station, and D station for trains.
station for 2 minutes. At each station B station: 13 minutes
measure the arrival time of each C station: 13 minutes
train.
D station: 14 minutes
ABC_VER_003 For 3 hours run trains at intervals of test Test carried out agreed Travel times of 90 ± 30 seconds Travel intervals: SAT passed D Person 01/06/2014 The travel time was ABC_SR_003
8 minutes from A station to D without passengers. between adjacent stations. A to B station : 80 seconds not always 90
station, stopping at B station and C seconds.
station for 1 minute. At each station B to C station: 100 seconds C to
measure the arrival time and D station: 120 seconds
ABC_VER_004 Verify the materials used for the review Test carried out on agreed Trains can travel at speeds from 0 Speeds up to 120 km/h SAT passed D Person 01/06/2014 Design document XXX ABC_SSR_00 1
rails support a train travelling at test track. km/h to 100 km/h. chapter Y.Z: Usage of
100 km/h.
ballast less track
supporting speeds up to
SSS km/h.
ABC_VER_005 Accelerate the train from 0 km/h to test Test carried out on agreed The train travels at speeds from Speeds up to 100 km/h SAT passed D Person 01/06/2014 ABC_SSR_00 1
100 km/h. Allow the train to travel at test track. 0 km/h to 100 km/h
100 km/h for 5 minutes.
ABC_VER_006 Accelerate the train from 0 km/h to test Test carried out on agreed SAT passed D Person 01/06/2014
The train accelerates from 0 Accelerates from 0 km/h to 100 ABC_SSR_00 2
100 km/h as rapidly as possible. test track.
km/h to 100 km/h within km/h in 20 seconds
30 seconds.
ABC_VER_007 Decelerate the train from test Test carried out on agreed The train decelerates from 100 Decelerate from 100 km/h to 0 SAT passed D Person 01/06/2014 ABC_SSR_00 3
100 km/h to 0 km/h as rapidly as test track. km/h to 0 km/h within km/h in 25 seconds.
possible. 30 seconds.

Authorisation:
Technical content Checked and Interdisciplinary Authorised for
prepared by approved by coordination release
checked by
Signature
Date
Name Richard Fullalove Gary Thong Jagath Peiris Jagath Peiris
Position Manager Systems A/Director Network Director Director
Engineering Process and Asset Strategy Network Standards Network Standards
and Services and Services

T MU AM 06004 ST
Standard
Requirements Schema
Version 2.0
Issued date: 14 April 2016
Important Warning
This document is one of a set of standards developed solely and specifically for use on Transport Assets (as defined in the Asset
Standards Authority Charter). It is not suitable for any other purpose.
You must not use or adapt it or rely upon it in any way unless you are authorised in writing to do so by a relevant NSW Government
agency. If this document forms part of a contract with, or is a condition of approval by a NSW Government agency, use of the document
is subject to the terms of the contract or approval.
This document is uncontrolled when printed or downloaded. Users should exercise their own skill and care in the use of the document.
This document may not be current. Current standards may be accessed from the Asset Standards Authority website at
www.asa.transport.nsw.gov.au.
© State of NSW through Transport for NSW

T MU AM 06004 ST
Requirements Schema
Version 2.0
Standard governance
Owner: Manager Systems Engineering Process, Asset Standards Authority
Authoriser: Principal Manager Network and Asset Strategy, Asset Standards Authority
Approver: Executive Director, Asset Standards Authority on behalf of the ASA Configuration Control
Board
Document history
Version Summary of Changes
1.0 First issue
2.0 Second issue
Added clarification that all of the schema fields are mandatory. Added requirements for
satisfies links, verifies links and validates links.
For queries regarding this document,

please email the ASA at
standards@transport.nsw.gov.au
or visit www.asa.transport.nsw.gov.au
© State of NSW through Transport for NSW

T MU AM 06004 ST
Requirements Schema
Version 2.0
Preface
The Asset Standards Authority (ASA) is an independent unit within Transport for NSW (TfNSW)
and is the network design and standards authority for defined NSW transport assets.
The ASA is responsible for developing engineering governance frameworks to support industry
delivery in the assurance of design, safety, integrity, construction, and commissioning of
transport assets for the whole asset life cycle. In order to achieve this, the ASA effectively
discharges obligations as the authority for various technical, process, and planning matters
across the asset life cycle.
The ASA collaborates with industry using stakeholder engagement activities to assist in
achieving its mission. These activities help align the ASA to broader government expectations
of making it clearer, simpler, and more attractive to do business within the NSW transport
industry, allowing the supply chain to deliver safe, efficient, and competent transport services.
The ASA develops, maintains, controls, and publishes a suite of standards and other
documentation for transport assets of TfNSW. Further, the ASA ensures that these standards
are performance-based to create opportunities for innovation and improve access to a broader
competitive supply chain.
This document aims to provide a standard schema for requirements, to help the exchange of
consistent information across TfNSW divisions and the Authorised Engineering Organisations
(AEOs) 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 a second issue.
© State of NSW through Transport for NSW Page 3 of 22

T MU AM 06004 ST
Requirements Schema
Version 2.0
Table of contents
1. Introduction .............................................................................................................................................. 5
2. Purpose .................................................................................................................................................... 5
2.1. Scope ..................................................................................................................................................... 5
2.2. Application ............................................................................................................................................. 5
3. Reference documents ............................................................................................................................. 5
4. Terms and definitions ............................................................................................................................. 6
5. TfNSW requirements schema................................................................................................................. 7
6. Structuring requirements information................................................................................................... 8
6.1. Requirement element-level information ................................................................................................. 8
6.2. Requirement management information ................................................................................................. 9
7. Structuring verification information .................................................................................................... 11
7.1. Verification element-level information .................................................................................................. 11
7.2. Verification activity information ............................................................................................................ 12
8. Structuring validation information....................................................................................................... 13
8.1. Validation element–level information ................................................................................................... 13
8.2. Validation activity information .............................................................................................................. 14
9. Providing link information .................................................................................................................... 15
10. Providing traceability across the engineering life cycle ................................................................... 16
Appendix A Example schema implementation .................................................................................... 18
A.1. Example business requirements ......................................................................................................... 18
A.2. Example system requirements ............................................................................................................ 19
A.3. Example subsystem requirements ...................................................................................................... 20
A.4. Example verification activities .............................................................................................................. 21
A.5. Example validation activities ................................................................................................................ 22

T MU AM 06004 ST
Requirements Schema
Version 2.0
1. Introduction
Different divisions of Transport for NSW (TfNSW), transport agencies, and the TfNSW supply
chain have used ad hoc 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 passed between different organisations.
2. Purpose
This document provides a standard schema for requirements data definition and management
for exchange of requirements. 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 capital projects.
This document is not for use on maintenance projects.
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 Guide to Requirements Definition and Analysis 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 Authorised Engineering
Organisations (AEOs) that define and manage requirements for planning and acquiring TfNSW
new or altered assets.
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

T MU AM 06004 ST
Requirements Schema
Version 2.0
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
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
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
BR business requirement
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
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
IFAT integrated factory acceptance test
INCOSE International Council on Systems Engineering

T MU AM 06004 ST
Requirements Schema
Version 2.0
modelling (as defined in ISO 24765) representing a real world process, device, or concept
NA not available, not applicable
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
simulation (as defined in ISO 24765) a model that behaves or operates like a given system
when provided a set of controlled inputs
site acceptance test acceptance test carried out at the destination site
SAT site acceptance test
SIT system integration testing
SR system requirement
SSR subsystem requirement
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
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 help the
free exchange of requirements information between multiple parties using different requirement
management tools.
The schema identifies the information types 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

T MU AM 06004 ST
Requirements Schema
Version 2.0
(INCOSE) Systems Engineering Handbook specifies the 'V' model. Figure 1 in Section 10
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 schema provides a standard for the following activities:
• structuring of requirements
• structuring of verification and validation 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 solution is verified and validated
Appendix A contains a worked example of the schema.
6. Structuring requirements information

The 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 administrative information
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 for each requirement element. Each of
the fields in this table is mandatory and shall be completed with the relevant information
available.

T MU AM 06004 ST
Requirements Schema
Version 2.0
Table 1 - Requirement element-level information
Field name Description Type Occurs

Type Type of the element. Element type is used to string one
differentiate between business requirements,
system requirements and subsystem
requirements.
Name Name of the element. string one
Sources Sources of the element. string one or
more
Owner Owner of the element. string one
Release date The date that the version was released. date one
Version The version number of the element. number one
Element status The status of the element – draft or approved. string one
6.2. Requirement management information

Table 2 shows the mandatory set of information that shall be recorded for each requirement.
Each of the fields in this table is mandatory and shall be completed with the relevant information
available. However for fields where “Occurs” has a possible value of zero, it is permissible for
the field to be empty.
Organisations may include additional information to meet their specific requirements

management needs.
Table 2 - Requirement management information

Identifier Requirement identifier unique for text string one
the project.
Description Requirement item text. text string one
Allocation Stakeholders involved in text string zero or
requirement decomposition. List of more
elements needing requirements to
satisfy a given parent requirement.
Business requirements allocate to
system requirements. System
requirements allocated to
subsystems requirements.

T MU AM 06004 ST
Requirements Schema
Version 2.0

Compliance Whether the designed solution • compliant string one
status meets the requirements. The status • noncompliant
may change as the solution is
developed. • partially
compliant
A partially compliant status
indicates that only some of the • to be
necessary compliance activities determined
have been completed. The
Remarks field is used to indicate
the reason for the partially
compliant status.
Criticality Requirement criticality for the • essential string one
solution. • desirable
• optional
• NA
Proposed Verification method used to verify • review string one
verification that the solution will meet the • analysis
method requirements.
• modelling
The proposed verification method is
not applicable (NA) for business • simulation
requirements. • test
• NA
Limit of scope The limit of the scope covered by text string one or
the requirement. This can be more
geographical locations or scope of
works.
Owner Requirement owner. The sponsor text string one
of the requirement.
Proposed Validation method used to validate • demonstration string one
validation that the built solution will meet the • test
method requirements.
• inspection
The proposed validation method is
NA for system requirements and • NA
subsystem requirements.
Validation test If the validation method is a test, it • FAT string one
type indicates which kind of test is • IFAT
expected.
• SAT
The validation test type is NA for
business requirements. • SIT
• NA
Rationale Explains why the requirement is text string zero or
needed from a solution point of one
view. This field needs to be
completed only if there is no
satisfaction out link to a source
requirement. (otherwise, the
requirement has to be part of the
solution because of the satisfied
requirements)

T MU AM 06004 ST
Requirements Schema
Version 2.0

Remarks Any remark, comment, notes or text string zero or
explanations for the requirement. more
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.
Requirement The project phase or milestone for • concept string one
delivery phase requirement delivery. • specify
• procurement
• design
• build
• integrate
• accept
• operate
• maintain
• evolve
• dispose
Requirement Status to assess requirement • draft string one
approval maturity and support the • review
status requirement life cycle.
• agreed
• cancelled
• NA
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 needed for each verification element containing a
collection of verification activities. Each of the fields in this table is mandatory and shall be
completed with the relevant information available.
Table 3 - Verification element-level information

Type Type of the element. string one
Element type is used
to differentiate the
verification element
from other elements.

T MU AM 06004 ST
Requirements Schema
Version 2.0

Owner Owner of the string one
element.
Release date The date that the date one
version was released.
Version The version number number one
of the element.
Element status The status of the string one
element – draft or
approved.
7.2. Verification activity information

Table 4 contains the mandatory information needed for each verification activity. Each of the
fields in this table is mandatory and shall be completed with the relevant information available.
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 text string one
identifier unique
for the project.
Description Verification item text string one
text.
Method Verification • review string one
method. It is • analysis
used to ensure
requirements are • modelling
covered by the • simulation
proper type of • test
verification
items. • NA

explanation of
the verification
method.
verification item • review
maturity and
support its life • agreed
cycle. • cancelled
• NA
Success criteria Verification item text string one
success criteria.
Verification Verification item text string one
outcome outcome.

T MU AM 06004 ST
Requirements Schema
Version 2.0

Result Verification item • passed string one
actual result. • failed
• blocked
• pending
• NA
executing the
verification item.
Executed on The verification text date one
item execution
date.
Execution The verification text string zero or more
comments item execution
comments.
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 needed for each validation element containing a
collection of validation activities. Each of the fields in this table is mandatory and shall be
completed with the relevant information available.
Table 5 - Validation element-level information

Type Type of the element. string one
Element type is used
to differentiate the
validation element
from other elements.
Owner Owner of the string one
element.
Release date The date that the date one
version was released.
Version The version number number one
of the element.
Element status The status of the string one
element – draft or
approved.

T MU AM 06004 ST
Requirements Schema
Version 2.0
8.2. Validation activity information

Table 6 contains the minimum mandatory element information needed for each validation
activity. Each of the fields in this table is mandatory and shall be completed with the relevant
information available. 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 text string one
identifier unique
for the project.
Description Validation item text string one
text.
Method Validation • demonstration string one
method. It is • test
used to ensure
requirements • inspection
are covered by • NA
the proper type
of validation
items.
explanation of
validation
method.
validation item • review
maturity and
support its life • agreed
cycle. • cancelled
• NA
Success criteria Validation item text string one
success criteria.
Validation Validation item text string one
outcome outcome.
Test type If validation • FAT string one
method is a test, • IFAT
then specifies
the test type. • SAT
• SIT
• NA
Result Validation item • passed string one
actual result • failed
• blocked
• pending
• NA

T MU AM 06004 ST
Requirements Schema
Version 2.0

executing the
validation item.
Executed on The validation text date one
item execution
date.
Execution The validation text string zero or more
comments item execution
comments.
9. Providing link information

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, and their respective
verification and validation activities.
Each business requirement shall have one or more satisfies links from system requirements.
Each system requirement shall have one or more satisfies links from subsystem requirements, if
there are subsystems.
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 is satisfied by the system requirement
ABC_SR_001; the system shall operate with service intervals of 8 ± 2 minutes.
Table 7 shows the permitted terms and descriptions for links.
Table 7 - Link information
Link name Description Source element Target element

Satisfies Requirement decomposition. specific identified specific
Source element needs to be requirement identified
the lower level and target requirement
element the upper level (e.g.:
from system requirements to
business requirements)
Verifies Requirement verification verification requirement
Validates Requirement validation validation requirement

T MU AM 06004 ST
Requirements Schema
Version 2.0
10. Providing traceability across the engineering life

cycle
Linking verification and validation items to requirements ensures that the solution fulfils the
requirements.
Using the requirements schema for all stages of a project allows for ongoing verification through
the stages and validation at system acceptance. Figure 1 illustrates how the verification and
validation of requirements link across the engineering life cycle through decomposition and
solution definition to solution integration and composition.

T MU AM 06004 ST
Requirements Schema
Version 2.0
Requirements
Repository
Business System
Concept Validation
Requirements validates Acceptance
Feasibility
Validation
satisfies
System System
System Design Verification Integration and
D Requirements verifies
ec
Verification on
s
om ti
ie
satis si
rif
po fies
po
ve
si
tio
n
Subsystem om
C
an Requirements d
d an
so Subsystem n
lu Subsystem io
tio Integration and at
n Design egr
de Procurement, Verification Int
fin n
iti
on
Fabrication, tio
lu
Construction, So
Installation
Time
Figure 1 - Relationship between requirements and verification and validation

T MU AM 06004 ST
Requirements Schema
Version 2.0
Appendix A Example schema implementation

The following is an example implementation of the requirements schema for a fictitious rail project 'ABC'.
The example contains requirement elements of:
• business requirements
• system requirements
• subsystem requirements
The verification and validation elements provide criteria for assuring the requirements are achieved.
The links for connecting these elements are marked as 'satisfies' 'verifies' or 'validates'. 'Satisfies links' show the system requirements that satisfy the business requirements and subsystem requirements that satisfy the system requirements.
'Verifies links' show the verification activities that verify system requirements and subsystem requirements. The 'Validates links' include the validation activities that validate the business requirements.
A.1. Example business requirements

Type Business requirements
Name ABC project business requirements
Owner Rail network planning
Sources Customer survey ABC
Business case ABC
Version 1.0
Identifier Description Allocation Compliance Criticality Proposed Limit of Owner Proposed Validation test Rationale Remarks Requirement Requirement
status verification scope validation type delivery approval
method method phase status
ABC_BR_001 The passenger waiting system compliant essential NA A station Planning Manager test SAT Based on This is for the accept agreed
time shall be maximum B station customer survey initial
10 minutes at stations ABC. operation of
C station
in peak periods. the system.
D station
ABC_BR_002 The passenger waiting system compliant essential NA A station Planning Manager test SAT Based on This is for the accept agreed
time shall be maximum B station customer survey initial
15 minutes at stations ABC. operation of
C station
in off peak periods. the system.
D station
ABC_BR_003 The passenger journey system compliant essential NA A station Planning Manager test SAT Based on This is for the accept agreed
time shall be maximum B station business case initial
2 minutes between ABC. operation of
C station
adjacent stations. the system.
D station

T MU AM 06004 ST
Requirements Schema
Version 2.0
A.2. Example system requirements

Type System requirements
Name ABC project system requirements
Owner Systems engineering
Sources Business requirements
Version 1.0
Identifier Description Allocation Compliance Criticality Proposed Limit of scope Owner Proposed Validation Rationale Remarks Requirement Requirement Satisfies
status verification validation test type delivery approval links
ABC_SR_001 The system shall train subsystem compliant essential test A station Systems NA NA This is for the accept agreed ABC_BR_001
operate with service B station Manager initial
intervals of operation of
C station
8 ± 2 minutes in peak the system.
periods. D station
ABC_SR_002 The system shall train subsystem compliant essential test A station Systems NA NA This is for the accept agreed ABC_BR_002
operate with service B station Manager initial
intervals of operation of
C station
13 ± 2 minutes in off the system.
peak periods. D station
ABC_SR_003 The system shall train subsystem compliant essential test A station Systems NA NA accept agreed ABC_BR_003
operate with travel B station Manager
times of
C station
90 ± 30 seconds
between adjacent D station
stations.

T MU AM 06004 ST
Requirements Schema
Version 2.0
A.3. Example subsystem requirements

Type Subsystem requirements
Name ABC project train subsystem requirements
Owner Rolling stock
Sources System requirements
Version 1.0
Identifier Description Allocation Compliance Criticality Proposed Limit of scope Owner Proposed Validation Rationale Remarks Requirement Requirement Satisfies
status verification validation test type delivery approval links
ABC_SSR_001 The train shall compliant essential review train Rolling NA NA Analysis XYZ accept agreed ABC_SR_001
travel at speeds Stock shows that ABC_SR_002
from 0 km/h to Manager this speed is
ABC_SR_003
100 km/h. required.
accelerate from Stock shows that ABC_SR_002
0 km/h to Manager this
ABC_SR_003
100 km/h within acceleration
30 seconds. is required.
decelerate from Stock shows that ABC_SR_002
100 km/h to Manager this
ABC_SR_003
0 km/h within deceleration
30 seconds. is required.

T MU AM 06004 ST
Requirements Schema
Version 2.0
A.4. Example verification activities

Type Verification
Name ABC project verification
Version 1.0
Identifier Description Method Remarks Status Success criteria Verification outcome Result Executed by Executed on Execution comments Verifies links
ABC_VER_001 For 3 hours run trains at test Test carried agreed Trains at intervals of Train intervals: passed D Person 01/06/2014 The train interval was ABC_SR_001
intervals of 8 minutes from A out without 8 ± 2 minutes at A station, B A station: 8 minutes not always 8 minutes
station to D station, stopping at passengers. station, C station, and D for trains.
B station: 8 minutes
B station and C station for 2 station
minutes. At each station C station: 9 minutes
measure the arrival time of D station: 9 minutes
each train.
ABC_VER_002 For 3 hours run trains at test Test carried agreed Trains at intervals of Train intervals: passed D Person 01/06/2014 The train interval was ABC_SR_002
intervals of 13 minutes from A out without 13 ± 2 minutes at A station, A station: 14 minutes not always 13 minutes
station to D station, stopping at passengers. B station, C station, and D for trains.
B station and C station for 2 station
minutes. At each station C station: 13 minutes
measure the arrival time of D station: 14 minutes
each train.
ABC_VER_003 For 3 hours run trains at test Test carried agreed Travel times of 90 ± 30 Travel intervals: passed D Person 01/06/2014 The travel time was ABC_SR_003
intervals of 8 minutes from A out without seconds between adjacent A to B station : 80 seconds not always 90
station to D station, stopping at passengers. stations. seconds.
B to C station: 100 seconds
B station and C station for 1
minute. At each station C to D station: 120 seconds
measure the arrival time and
departure time of each train.
ABC_VER_004 Verify the materials used for review Test carried agreed Trains can travel at speeds Speeds up to 120 km/h passed D Person 01/06/2014 Design document XXX ABC_SSR_00
the rails support a train out on test from 0 km/h to 100 km/h. chapter Y.Z: Usage of 1
travelling at 100 km/h. track. ballast less track
supporting speeds up
to SSS km/h.
ABC_VER_005 Accelerate the train from 0 test Test carried agreed The train travels at speeds Speeds up to 100 km/h passed D Person 01/06/2014 ABC_SSR_00
km/h to 100 km/h. Allow the out on test from 0 km/h to 100 km/h 1
train to travel at 100 km/h for 5 track.
minutes.
ABC_VER_006 Accelerate the train from 0 test Test carried agreed The train accelerates from Accelerates from 0 km/h to passed D Person 01/06/2014 ABC_SSR_00
km/h to 100 km/h as rapidly as out on test 0 km/h to 100 km/h within 100 km/h in 20 seconds 2
possible. track. 30 seconds.
ABC_VER_007 Decelerate the train from test Test carried agreed The train decelerates from Decelerate from 100 km/h passed D Person 01/06/2014 ABC_SSR_00
100 km/h to 0 km/h as rapidly out on test 100 km/h to 0 km/h within to 0 km/h in 25 seconds. 3
as possible. track. 30 seconds.

T MU AM 06004 ST
Requirements Schema
Version 2.0
A.5. Example validation activities

Type Validation
Name ABC project validation
Version 1.0
Identifier Description Method Remarks Status Success criteria Validation outcome Test type Result Executed by Executed on Execution comments Validates links
ABC_VAL_001 For 3 hours run trains at test Test carried agreed Maximum Maximum waiting times: SAT passed E. Person 10/06/2014 D station had the ABC_BR_001
intervals of 8 minutes from out with passenger waiting A station: 8 minutes longest waiting time. ABC_BR_002
A station D station, passengers. time is 10
stopping at B station, C minutes.
station and D station. C station: 9 minutes
Unload and load 200 D station: 10 minutes
passengers at each
station. At each station
measure the waiting time
for passengers.
ABC_VAL_002 For 3 hours run trains at test Test carried agreed The passenger Maximum journey times: SAT passed E. Person 10/06/2014 ABC_BR_003
intervals of 8 minutes from out with journey time is A station to B station: 2 minutes
A station D station, passengers. maximum 2
B station to C station: 2 minutes
stopping at B station, C minutes between
station and D station. adjacent stations. C station to D station: 2 minutes
Unload and load 200
passengers at each
station. At each station
measure the arrival time
and departure time of
each train.

t-mu-am-06004-stREquirements Schema

Uploaded by

Copyright:

Available Formats

You might also like

t-mu-am-06004-stREquirements Schema

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

t-mu-am-06004-stREquirements Schema

Uploaded by

Copyright:

Available Formats

Technical Note – TN 027: 20182018

For queries regarding this document

Technical Note – TN 027: 2018

Effective date: 09 August 2018

Subject: Amendments to T MU AM 06004 ST

• Table 4 Verification activity information

• Table 6 Validation activity information

• Section A.4 Example verification activities

This technical note will be incorporated in version 3.0 of T MU AM 06004 ST.

In accordance with T MU AM 06006 ST Systems Engineering the only difference between

© State of NSW through Transport for NSW 2018 Page 1 of 5

Table 4 Verification activity information

Field name Description Values Type Occurs

© State of NSW through Transport for NSW 2018 Page 2 of 5

Table 6 – Validation activity information

Field name Description Values Type Occurs

Status Status to assess • draft string one

© State of NSW through Transport for NSW 2018 Page 3 of 5

© State of NSW through Transport for NSW 2018 Page 4 of 5

© State of NSW through Transport for NSW 2018 Page 5 of 5

© State of NSW through Transport for NSW

For queries regarding this document,

© State of NSW through Transport for NSW

This document is a second issue.

© State of NSW through Transport for NSW Page 3 of 22

© State of NSW through Transport for NSW Page 4 of 22

This document does not cover commercial contractual arrangements.

ISO 9000 Quality management systems — Fundamentals and vocabulary

© State of NSW through Transport for NSW Page 5 of 22

ISO 24765 Systems and software engineering — Vocabulary

INCOSE Systems Engineering Handbook

Transport for NSW standards

T MU AM 06007 GU Guide to Requirements Definition and Analysis

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

4. Terms and definitions

acceptance test (as defined in ISO 24765)

AEO Authorised Engineering Organisation

ASA Asset Standards Authority

FAT factory acceptance test

IFAT integrated factory acceptance test

INCOSE International Council on Systems Engineering

© State of NSW through Transport for NSW Page 6 of 22

NA not available, not applicable

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

SAT site acceptance test

SIT system integration testing

SSR subsystem requirement

TfNSW Transport for New South Wales

5. TfNSW requirements schema

© State of NSW through Transport for NSW Page 7 of 22

The schema provides a standard for the following activities:

• structuring of verification and validation evidence

• linking requirements to provide traceability through tracking the requirement decomposition

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

Appendix A contains a worked example of the schema.

6. Structuring requirements information

6.1. Requirement element-level information

© State of NSW through Transport for NSW Page 8 of 22

Table 1 - Requirement element-level information