Guide To Requirements Definition and Analysis

T MU AM 06007 GU
Guide
Guide to Requirements Definition

and Analysis
Version 3.0
Issued date: 29 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 06007 GU
Guide to Requirements Definition and Analysis
Version 3.0
Standard governance
Owner: Manager Systems Engineering Process, Asset Standards Authority
Authoriser: Principal Manager Authorisation and Audit, 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 Addition of more guidance about system requirement specifications, including the new
Appendix D
3.0 Addition of new Appendix E – Requirements specification review
For queries regarding this document,

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

T MU AM 06007 GU
Version 3.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.
The ASA developed this Guide to Requirements Definition and Analysis based on the technical
processes of AS/NZS ISO/IEC 15288:2013 Systems and software engineering – System life
cycle processes. A consultative committee containing members from stakeholder groups within
Transport for NSW (TfNSW) reviewed this document and the Asset Standards Authority
Configuration Control Board approved it.
This document provides the supplier organisations with guidance through the steps involved in
identifying and capturing stakeholder requirements and developing the systems requirements
based upon the stakeholder needs.
This document is the third issue.
© State of NSW through Transport for NSW Page 3 of 47

T MU AM 06007 GU
Version 3.0
Table of contents
1. Introduction .............................................................................................................................................. 5
2. Purpose .................................................................................................................................................... 5
2.1. Scope ..................................................................................................................................................... 5
2.2. Application ............................................................................................................................................. 5
3. Reference documents ............................................................................................................................. 6
4. Terms and definitions ............................................................................................................................. 6
5. Requirements management ................................................................................................................... 8
5.1. Objectives of requirements management .............................................................................................. 9
5.2. Requirement types and attributes .......................................................................................................... 9
5.3. Requirement construction .................................................................................................................... 10
5.4. Requirements management tools ........................................................................................................ 12
5.5. Requirements change management ................................................................................................... 13
5.6. Requirements configuration management........................................................................................... 13
5.7. Establishing baselines ......................................................................................................................... 13
5.8. Types of requirements sources ........................................................................................................... 13
6. Requirements definition and analysis ................................................................................................. 14
7. Stakeholder requirements definition ................................................................................................... 15
7.1. Stakeholder requirements definition output ......................................................................................... 16
7.2. Business requirements specification ................................................................................................... 16
7.3. Defining stakeholder requirements ...................................................................................................... 17
8. Requirements analysis ......................................................................................................................... 19
8.1. Purpose of requirements analysis ....................................................................................................... 19
8.2. Requirements analysis output ............................................................................................................. 19
8.3. Requirements analysis activities ......................................................................................................... 20
Appendix A Requirements verification and traceability matrix template ......................................... 24
Appendix B Requirements repository structure ................................................................................. 27
Appendix C Requirement examples ..................................................................................................... 28
Appendix D SRS examples .................................................................................................................... 30
D.1. Example 1 – Replacement of a road level crossing ............................................................................ 30
D.2. Example 2 – Rolling stock replacement program ................................................................................ 37
Appendix E Requirements specification review ................................................................................. 46

T MU AM 06007 GU
Version 3.0
1. Introduction
An Authorised Engineering Organisation (AEO) engaged by Transport for NSW (TfNSW) to
undertake engineering activities is required to have formalised requirements definition and
analysis arrangements in place. These arrangements should be relevant to the engineering
services or products provided by the AEO to TfNSW.
T MU MD 00009 ST AEO Authorisation Requirements defines the mandatory requirements for

requirements definition and analysis.
An AEO's engineering management plan, systems engineering management plan or equivalent

documents and procedures should contain the plan, management and approval of the AEO's
engineering activities to facilitate formalised requirements definition and analysis.
Any organisation applying for an AEO status should ensure that the requirements management
documentation of an AEO meets the minimum level required for the complexity of its projects or
contracts.
2. Purpose
This Guide to Requirements Definition and Analysis describes the process and key
responsibilities that an AEO and TfNSW divisions are required to implement in managing this
process.
It also contains general guidance on requirements management tools, requirements change

control and sources of requirements.
2.1. Scope
This guide forms part of a suite of systems engineering documents and guidance notes and
further develops the guidance on requirements management as described in TS 10504 AEO
Guide to Engineering Management.
This document does not outline the evidence that an AEO should produce in order to be
authorised to perform systems engineering for TfNSW, but provides an outline of the processes
that an AEO should demonstrate.
2.2. Application
The Guide to Requirements Definition and Analysis is for use by all AEOs conducting systems
engineering activities related to engineering services undertaken for or on behalf of TfNSW.
The guidance provided in this document also applies to organisations that are currently applying
for authorisation to carry out engineering activities for TfNSW in response to a tender or are
applying to be pre-registered as an AEO for consideration when tendering for TfNSW work.

T MU AM 06007 GU
Version 3.0
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.
Australian standards
AS/NZS ISO/IEC 15288:2013 Systems and software engineering – System life cycle processes
International standards
ISO/IEC/IEEE 29148:2011 Systems and software engineering – Life cycle processes –

Requirements engineering
Transport for NSW standards
TS 10504 AEO Guide to Engineering Management
TS 10506 AEO Guide to Verification and Validation
TS 20001 System Safety Standard for New or Altered Assets
T MU AM 04003 GU Configuration Management Guide
T MU AM 06010 GU Business Requirements Specification
T MU MD 00009 ST AEO Authorisation Requirements
Other references
INCOSE Guide for Writing Requirements
SEBoK v1.0 Guide to the Systems Engineering Body of Knowledge (SEBoK) version 1.0
4. Terms and definitions

The following terms and definitions apply in this document:
accountable the obligation of an individual or an organisation to account for its activities,

accept responsibility for them, and to disclose the results in a transparent manner. The job role
that is ultimately responsible for the engineering service. Accountability cannot be delegated.
AEO Authorised Engineering Organisation; it means a legal entity (which may include a
Transport Agency as applicable) to whom the ASA has issued an ASA Authorisation
ASA Asset Standards Authority
assurance a positive declaration intended to give confidence. It provides evidence of effective

management.
authorisation the conferring of authority, by means of an official instruction and supported by

assessment and audit

T MU AM 06007 GU
Version 3.0
availability the measure of the percentage of time that an item or system is available to perform
its designated function
BRS business requirements specification; the document in which the business goals and
stakeholder requirements are documented
client a person that has a business need, and uses the project’s product, service or result
Note: The client is responsible and accountable for realising and delivering the
benefits. The client is usually the receiver of the benefits and can also be the sponsor.
compliance the state or fact of according with, or meeting, rules, standards or requirements
COTS commercial off-the-shelf
EMP engineering management plan
framework a basic structure underlying a system, concept, or text
governance the rules, processes, or laws by which a business is operated, regulated, and
controlled. The exercise of authority and control between the accountable and responsible
entities within TfNSW and the AEOs such that planned outcomes are achieved.
human systems integration (as defined in ISO 29148) an interdisciplinary technical and
management process for integrating human considerations with and across all system elements
maintainability the probability that an item will be restored to operating condition, within a given
period of time, using prescribed procedures and resources
MCD maintenance concept definition
OCD operations concept definition
OMG Object Management Group, Inc.
performance the extent or how well a function or task is conducted
RAM reliability, availability and maintainability
RAMS reliability, availability, maintainability and safety
RATM requirements analysis, allocation and traceability matrix
reliability the probability that a specified item will perform a specified function within a defined
environment, for a specified length of time
requirements interchange format (Req IF) defines an open, non-proprietary exchange format
responsible a duty or obligation to satisfactorily perform or complete a task (assigned by

someone, or created by one's own promise or circumstances) that one must fulfil, and which
has a consequent penalty for failure. Responsibility can be delegated.
review a method to provide assurance by a competent person that a defined engineering output
complies with relevant standards and specific requirements, is safe, and fit for purpose

T MU AM 06007 GU
Version 3.0
RVTM requirements verification and traceability matrix; a list of requirements, their verification
attributes, and their traces. Sometimes referred to as a requirements allocation and traceability
matrix (RATM)
SEMP systems engineering management plan
specification a document that fully describes a design element or its interfaces in terms of
requirements (functional, performance, constraints, and design characteristics) and the
qualification (validation) conditions and procedures for each requirement
SRS system requirements specification
stakeholder individual or group whose interest in the project is recognised if the project is to be
successful
Note: In particular, those who may be positively or negatively affected during the
project or on successful completion of the project
supplier a supplier of engineering services or products. Defined as an 'applicant' until such time
as it has been granted AEO status, after which it is referred to as an AEO
system requirements all of the requirements at the system level that describe the functions
which the system as a whole should fulfil to satisfy the stakeholder needs and requirements,
and is expressed in an appropriate combination of textual statements, views and non-functional
requirements; the latter expressing the levels of safety, security, reliability, and so on that will be
necessary
system requirements specification a description of what the system should do, in terms of the
system’s functions, interactions and interfaces with its operational environment. It
communicates the stakeholder requirements to the technical community who will specify and
build the system. Alternatively, referred to as the system requirements document.
TfNSW Transport for New South Wales
validation the process of ensuring that the final product conforms to defined client requirements
verification the process performed to ensure that the output of a design stage, or stages,
meets the design stage input requirements
WHS work health and safety
5. Requirements management
Technical requirements management processes are used to define the requirements for a
system to achieve the following:
• transform the requirements into an effective product
• use the product to provide the required services

T MU AM 06007 GU
Version 3.0
• sustain the provision of those services
• dispose of the product when it is retired from service
T MU MD 00009 ST AEO Authorisation Requirements states mandatory requirements for

requirements definition and analysis.
5.1. Objectives of requirements management

Requirements management is a broad heading for the definition, analysis, allocation,
verification and validation of stakeholder requirements throughout a product or service life cycle.
Requirements management delivers the following objectives across the full asset life cycle:
• provide a structured means for identifying and defining all requirements from all relevant
stakeholders
• provide a means for analysing, allocating and recording all stakeholder requirements
• provide a complete set of unambiguous requirements
• define a structure for the storage and management of the requirements
• eliminate conflicting and duplicating requirements
• provide traceability of requirements, design output and the final product or service
• provide for the structured management of changes to requirements and approval process
• provide control and ensure data integrity in the recording, storing, and changing of
requirements
• provide a foundation for system verification and validation
5.2. Requirement types and attributes

Each requirement statement is reviewed and written in such a way that they exhibit the following
attributes:
• clear and concise
• specific
• necessary
• valid
• implementation independent – the needs should be independent of the solution
• unambiguous – all readers of a statement should reach a common interpretation of the

meaning of the requirement

T MU AM 06007 GU
Version 3.0
• verifiable – the requirement is expressed in a manner that compliance with the requirement
can be verified by an acceptable method
• feasible – the requirement can be achieved by one or more developed system concepts at
a definable (or bounded) cost
• traceable – each requirement is traceable from stakeholder level down to the appropriate
system or element level with established parent-child relationships
• consistent – no contradictions or conflicts with other requirements
• atomic – the statement contains only one requirement
• complete – all requirements of a given product or service has been specified including
interfaces
Appendix C provides a list of these attributes with description and requirement examples.
Appendix E provides guidance for the review of specifications.
5.3. Requirement construction

Requirements are constructed in order to express a need and the conditions and constraints
associated with this need. For stakeholder requirements, the need is to achieve an objective of
a stakeholder or to solve a problem of a stakeholder. Stakeholders include customers,
operators, maintainers, or external parties such as local councils and utilities. In the case of a
system or subsystem requirements, the needs to be achieved are those of the system or the
subsystem in order to fulfil the needs of the parent stakeholder requirements.
Requirements should be written in simple English. Best practice states that the requirements
written in English contain a subject of the requirement, imperative, a verb and a complement.
The requirement construct is therefore defined as follows:
• subject indicates the focus, for example: 'the system' or the 'driver control console'
• imperative indicates the priority of the requirement; for example shall, should or may
• verb outlines what action is performed, for example 'brake' or 'display'
• complement provides additional information in order to make the requirement bounded,

verifiable and unambiguous
The complement syntax can be further broken down into the following:
o conditions are attributes that can be measured, verified and validated; for example,
'normal mode' is a condition
o objects are physical or logical entities referred to within the requirement; for example,
'the train' and 'train speed' are objects

T MU AM 06007 GU
Version 3.0
o values provide quantitative numerical definitions for requirements; for example,

'80 km/h' is a value
o constraints provide bounds for requirements; for example, 'visually to the train driver'
and 'within a distance' are constraints
The requirement forms a complete and clear sentence as shown in the following examples:
The passenger waiting time [subject] shall [imperative] be [verb] a maximum of

[constraint] 10 minutes [value] at stations [object] in peak service periods [condition].
The braking system [subject] shall [imperative] brake [verb] the train [object] on
application of service braking [condition] from a speed of 80 km/h [value] to a speed of
0 km/h [value] within a distance of 1500 m [constraint] when fully loaded at a gross
weight of 500 tons [condition].
The driver control console [subject] shall [imperative] display [verb] the train speed
[object] visually to the train driver [constraint] in units of km/h [constraint] during
normal mode [condition].
Imperatives indicate that the sentence is actually a requirement. To standardise on a set of

imperatives and agreed meanings for these imperatives, and be consistent, the following
imperatives should be used for requirements:
• 'shall' for mandatory requirements
• 'should' for non-mandatory or desirable requirements
• 'may' for non-mandatory suggestions
The use of words such as 'must', 'are', 'is' and 'will', should be avoided as they can convey
unclear and inconsistent meaning.
Negative imperatives such as 'shall not', 'should not' or 'may not' should be avoided where
practicable as they can convey ambiguous meaning.
The following terms should be avoided, where possible, in requirement construction as they are
unbounded and can lead to ambiguous requirements:
• undefined terms such as 'user-friendly', 'versatile', 'flexible', 'approximate', 'minimal',

'fastest', 'smallest'
• speculative terms such as 'usually', 'generally', 'often', 'normally', 'typically'
• over specification such as '100% reliability', 'safe', 'handle all failures', 'fully upgradeable',
'run on all platforms'
• non-verifiable terms such as 'work reliably', 'clearly display'
• optional terms such as 'if available', 'as required', 'with approval'

T MU AM 06007 GU
Version 3.0
Further details regarding requirement construction is provided in INCOSE Guide for Writing
Requirements.
5.4. Requirements management tools

A requirements management tool that provides a structured framework for storing requirements
and provides parent-child traceability between levels of requirements should be used.
Parent-child traceability provides the following:
• improved integrity of requirements
• tracking of requirements development, decomposition and allocation
• a means of documenting and reviewing the relationships between the levels of

requirements that capture certain aspects of the design
• easier maintenance and change implementation of the system in the future
When an agreed set of stakeholder needs is defined, a requirements verification and traceability
matrix (RVTM) should also be developed as a part of this process. This RVTM lists all the
stakeholder requirements, their verification attributes, and the traceability back to the source of
a particular requirement. The RVTM also includes the status of the requirement, that is, whether
the requirement is compliant, partially compliant or noncompliant.
A list of attributes, which feature in a requirements verification and traceability matrix, is located
in Appendix A.
5.4.1. Tools for external interface of requirements management

The preference is for the requirements to be imported and exported directly from the
requirements management tool to a standard format for interchange, such as the Object
Management Group, Inc. requirements interchange format (OMG Req IF).
5.4.2. Requirements management tool selection

The complexity of the project determines the suitability of a requirements management tool. For
low complexity projects, a requirements verification and traceability matrix in a spreadsheet
format may be appropriate. However, a dedicated requirements management tool should be
employed for projects that are more complex.
Any selected tools should be capable of transferring data to the TfNSW requirements
management tool using the OMG requirements interchange format (Req IF).

T MU AM 06007 GU
Version 3.0
5.5. Requirements change management

Requirements definition, decomposition and management continue to evolve as system
development activities are applied over the life cycle. Management of requirements changes
during the systems life cycle is a critical aspect of the process.
Changes are managed by ensuring proposed changes are subjected to an impact assessment,
a review and a stakeholder approval process applying careful requirements tracing and version
management. This stakeholder approval process includes approval by the TfNSW configuration
management and asset assurance committee (CMAAC) and permission from key stakeholders.
The project configuration management plan should identify the baselines used for the project
including associated levels of authority required for change approval.
5.6. Requirements configuration management

Requirements should be managed in accordance with the project and organisational
configuration management processes. This includes baseline control of the business
requirements specification (BRS), system requirements specification (SRS), design
documentation, and verification and validation evidence.
Details on configuration management are covered in T MU AM 04003 GU Configuration

Management Guide.
5.7. Establishing baselines

When all stakeholder requirements have been identified and captured, baselines should be
established which enable design changes to be identified and the impact of those changes on
all systems or elements to be identified and traced. Traceability to the agreed requirements
should be recorded throughout the development and production stages to assure the final
system-of-interest complies with the original stakeholder requirements and agreed changes.
This includes the production of system level requirements sets and compliance matrices against
the agreed baseline stakeholder requirements.
5.8. Types of requirements sources

When acquiring engineering products or services, TfNSW usually issues a specification that
describes the intended outcomes expected from the product or the service. This specification is
often referred to as a works or service brief. The requirements can be included in a separate
requirements specification that is included within the tender specification, or incorporated in the
tender specification itself.

T MU AM 06007 GU
Version 3.0
The types of requirements sources included in a requirements specification include the

following:
• functional requirements
• performance requirements
• interface requirements
• process requirements
• non-functional requirements
• quality requirements
• human factors requirements
• design constraints
• safety
The requirements that are agreed between TfNSW and the AEO at the time of signing the
contract become the baseline requirements for the product or service.
The requirements specification takes the form of a suite of requirements depending upon the
level of requirements definition performed by TfNSW prior to AEO engagement. The
stakeholder requirements are also known as a business requirements specification (BRS). The
system level requirements are also known as a system requirements specification (SRS).
Appendix B provides a diagram describing the relationship between the business level
requirements, system level requirements and element level requirements.
Performed at the successful completion of each life cycle stage are further baselines of
requirements. An agreed change control process is used when implementing changes to
baseline requirements.
6. Requirements definition and analysis

Requirements definition and analysis are systems engineering processes designed for
managing requirements. The purpose of requirements definition and analysis is to minimise the
risks that arise from decisions and actions throughout the project life cycle, thus enabling the
products and services to meet a project's expectations and legislated requirements.
Requirements definition and analysis forms part of the continuous requirements management
process. This incorporates the following processes throughout a project life cycle:
• eliciting requirements
• defining and analysing requirements
• tracing requirements

T MU AM 06007 GU
Version 3.0
• agreeing requirements
• documenting requirements
• controlling and communicating changes to the requirements
An initial design brief incorporating a set of desired outcomes is expanded into a full set of
manageable requirements using stakeholder requirements definition.
Requirements analysis takes the initial set of stakeholder requirements and assists in
developing them into a full set of guidelines and specifications that are required to guide the
work. The stages or output of a system is measured against these specifications to determine
whether the system is fit for purpose as intended.
7. Stakeholder requirements definition

The requirements management for multidisciplinary transport projects is performed at the
system level. This involves capturing stakeholder requirements from the user requirements,
stakeholder specifications, a works brief or service brief and applicable standards.
The following documents describe the purpose of stakeholder requirements definition:
• AS/NZS ISO/IEC 15288:2013 Systems and software engineering – System life cycle
processes
• ISO/IEC/IEEE 29148:2011 Systems and software engineering – Life cycle processes –

Requirements engineering
Figure 1 provides a high-level representation of stakeholder requirements definition.
User need /
customer Stakeholder
experience need
User Stakeholder
requirements need
Operator document
need
Maintainer
need
Figure 1 – Stakeholder requirements definition

T MU AM 06007 GU
Version 3.0
7.1. Stakeholder requirements definition output

The output of the stakeholder requirements definition process is an initial set of stakeholder
requirements for the required product or service, which should define the required capability and
any constraints including supporting information.
For each stakeholder requirement, traceability to the source of the stakeholder requirement is
identified and recorded.
The stakeholder requirements form the baseline documents that are used as the basis of design
and should be subject to configuration control.
The process flow charts for generic requirements definition are available in the Systems
Engineering Body of Knowledge (SEBoK).
Further details regarding verification and validation, including the allocation of verification
methods is provided in TS 10506 AEO Guide to Verification and Validation.
7.2. Business requirements specification

The document that contains the business goals and stakeholder requirements is referred to as
the business requirements specification (BRS) within TfNSW.
The BRS contains the following information:
• stakeholder and business requirements in the context of why the system is being
developed or changed which is also referred to as the business case
• the stakeholders, users, operators, maintainers and interfaces to the system
• the manner in which the system interacts with the intended users
• the manner in which the system is operated and maintained
• new or improved capabilities including any interfaces and constraints
• policies and rules under which the system is used
• high level strategic requirements
• key benefits and values
A completed BRS typically outlines the stakeholder requirements relating to the following
strategic areas:
• enterprise or business
• maintenance – often also documented in a maintenance concept definition
• operations – often also documented in an operations concept definition
• user needs or expected customer experience

T MU AM 06007 GU
Version 3.0
In certain situations, a BRS might exist but contain insufficient information to address all of the
stakeholder requirements including the business requirements, user requirements, maintenance
requirements and operational requirements. Where this situation arises, further work is required
to elicit and define the complete set of necessary stakeholder requirements before any attempt
is made to develop the system level requirements.
Business requirements specifications are usually prepared by the transport planning entity.
However, in some situations the transport planning entity may contract an AEO to assist with
the preparation of this document.
Further details regarding business requirements specifications is provided in

T MU AM 06010 GU Business Requirements Specification.
7.3. Defining stakeholder requirements

Defining stakeholder requirements comprises the following elements:
• eliciting requirements from stakeholders
• defining the requirements
• analysing stakeholder requirements
• on-going maintenance of stakeholder requirements
Figure 2 provides a high-level representation of the stakeholder requirements definition

processes.
Analyse and
Elicit stakeholder Define stakeholder maintain
requirements requirements stakeholder
requirements
Figure 2 – Stakeholder requirements definition process
7.3.1. Elicit stakeholder requirements

Eliciting stakeholder requirements is undertaken to ensure that the system or product that is
being acquired or developed meets the needs of all stakeholders.
Eliciting stakeholder requirements requires the AEO to identify all the individuals, groups or
organisations that have a legitimate interest in the system and then identify their requirements.
7.3.2. Define the stakeholder requirements

Identifying the needs of stakeholders is crucial for defining the objectives of the desired product
or service and the way it should be designed. Accurate and clear documentation of these
requirements reduces inefficiency in the design, and review process and ensures that the final

T MU AM 06007 GU
Version 3.0
product or service adequately fulfils the stakeholder's expectations. The following high-level
steps can assist in compiling a comprehensive requirements document:
• define the constraints on the system
• identify the required products or services
• identify the operational needs and environment
• identify the interactions between users, operators and maintainers and the system
• define any reliability, availability, maintainability, safety, security, environmental or other

stakeholder requirements that are needed
Development of a system to meet all of the stakeholder's needs is often subject to many
constraints. These constraints can include the following:
• requirements to use commercial off the shelf (COTS) or proprietary systems
• requirements to use existing facilities
• operations interfaces with other systems or organisations
• standards
• safety features
• operational environment
• regulatory and architectural constraints
Each requirement should originate from an authorised source, signed by all of the relevant
stakeholders and be attributed a finalised status. The elicited requirements should include input
from all identified stakeholders.
7.3.3. Review and maintain stakeholder requirements

Stakeholder's needs and expectations are unique. The captured stakeholder requirements
should be recorded, reviewed and maintained. The following activities are undertaken to assist
in managing stakeholder requirements:
• record the stakeholder requirements in a form suitable for management throughout the life
cycle
• establish a requirements database and store all requirements with information that can be
traced back to their source documents
• review the complete set of elicited requirements
• identify each requirement uniquely by implementing a logical coding system
This unique identifier should remain with the requirement.

T MU AM 06007 GU
Version 3.0
• identify and categorise requirements according to types to meet the project and design
constraints
• review the captured requirements with stakeholders to ensure needs have been captured
and expressed correctly
• identify the verification and validation method and acceptance criteria for the stakeholder
requirement
8. Requirements analysis
Section 8.1 through to Section 8.3 explains the requirements analysis.
8.1. Purpose of requirements analysis

Requirements analysis develops the initial set of requirements into a fully scoped set of
specifications. It takes the user requirements and develops them into system requirements.
The purpose of requirements analysis is more comprehensively described in

AS/NZS ISO/IEC 15288:2013.
Figure 3 provides a high-level representation of requirements analysis.
User Requirements System

requirements Analysis requirements
Figure 3 – Requirements analysis
8.2. Requirements analysis output

The output of the requirements analysis process is the establishment of an initial set of system
requirements for the required product or service, which fully responds to the stakeholder
requirements. This initial set of system requirements should define the following requirements
and attributes of the proposed product or service:
• required characteristics and attributes
• functional requirements
• performance requirements
For each system requirement, traceability should be identified and recorded against the
stakeholder requirement.
The verification method for each system requirement should also be defined.

T MU AM 06007 GU
Version 3.0
When these system requirements are approved, they form the baseline specifications for design
purposes, and are subject to configuration control.
When an agreed set of system requirements is established, the requirements verification and
traceability matrix (RVTM) should be established or updated.
8.2.1. System requirements document

The purpose of the system requirements specification (SRS) is to provide a description of the
functional intent of the system including any expected interactions and interfaces with its
operational environment. The SRS communicates the stakeholder requirements to the technical
community who specify and build the system.
A system requirements document performs the following functions:
• defines the high-level system requirements
• defines the functional, performance and non-functional requirements (including reliability,

availability, maintainability and safety requirements)
• identifies any constraints or assumptions
• identifies the technical specifications for the selected system-of-interest
• identifies usability for human-system interaction and interfaces
• provides background information about the overall objectives for the system and its
operating environment
• can include conceptual models designed to illustrate the system context, usage scenarios,
the internal and external interfaces with the operational environment, data, information and
workflows
SRSs are usually prepared by the transport projects entity; however, in most situations the
transport projects entity contracts an AEO to undertake the development of an SRS.
Appendix D provides examples of SRS.
8.3. Requirements analysis activities

An AEO, on engagement by TfNSW, should carry out a detailed analysis of the requirements in
order to produce a technical view of a product or service that can deliver the expected outcome.
Requirements analysis comprises defining the system requirements and then analysing and
maintaining the system requirements.

T MU AM 06007 GU
Version 3.0
Figure 4 provides a high-level representation of requirements analysis activities.
Analyse and
Define system
maintain system
requirements
requirements
Figure 4 – Requirements analysis activities
When the requirements analysis process is complete, the system requirements are submitted to
all authorised stakeholders for review and validation.
8.3.1. Define system requirements

The following activities are undertaken to develop a technical view of the required product or
service from the stakeholder needs:
• define the system boundaries
Review the stakeholder requirements, including both user's and maintainer's requirements
and the operation environment to understand the boundaries of the required product or
service.
• define the system functions
Undertake functional analysis and derive new functional requirements that are required to
achieve the project mission or service outcome. This can include safety controls identified
to mitigate risks as identified through hazard analysis workshops.
• define any implementation constraints
These can include constraints defined by the stakeholders, limitations of the solution or
compliance with standards.
• define interfaces
This should include technical and enterprise interfaces both internal and external to the
system-of-interest. Interfaces should be defined and should be categorised as one or more
of the following:
o functional system interface
o physical system interface
o information interface
• define speciality process factors; for example, health and safety, security, human factors,
reliability, availability and maintainability
These can include factors defined by the stakeholders, compliance with standards or
outputs from hazard and risk analysis activities.

T MU AM 06007 GU
Version 3.0
Further details regarding system safety, including hazard analysis is provided in TS 20001
System Safety Standard for New or Altered Assets.
8.3.2. Analyse and maintain system requirements

The following activities are undertaken in order to analyse the technical system view of the
required product or service:
• review the integrity of the system requirements
Each system requirement statement should be checked to ensure that it is unique,

complete, unambiguous, consistent with other requirements, verifiable, and able to be
implemented.
• define the verification criteria for each system requirement
Identify the evidence required to demonstrate where and how the requirements will be
verified. This occurs through executing verification and validation plans. Verification and
validation plans are also referred to as inspection and test plans.
• allocate the requirements to the relevant system or element
This includes the identification of internal and external interfaces, which requires
management to ensure that the implications of design development in one system or
element are fully incorporated in other systems or elements.
• allocate the responsibilities associated with each of the system requirements
Requirements can have more than one aspect of responsibility.
• establish and maintain system level traceability
System requirements should have parent-child traceability to the source document or direct to
the stakeholder need. This should include all derived requirements with information that traces
back to parent requirements or source documents. The established traceability includes all
identified interfaces.
Establishing and maintaining traceability is fundamental to ensure that all stakeholder

requirements are satisfied, and that each system requirement is justified. Requirements
traceability ensures that stakeholder requirements have been realised in the proposed solution
and that an impact analysis can be undertaken when requirements change.
Parent-child traceable relationships exist between stakeholder requirements through system

elements at multiple levels of derived requirements all the way down to the lowest configuration
items.

T MU AM 06007 GU
Version 3.0
A parent-child traceable relationship exists between stakeholder requirements or requirements

that have been derived from hazard analysis and failure mode analysis such as safety,
reliability, availability or maintainability requirements to any one or more of the following sets:
• architectural design
• system elements that implement a requirement
• verification entities that satisfy a requirement, along with any supporting models and
analysis
• all interfaces

T MU AM 06007 GU
Version 3.0
Appendix A Requirements verification and

traceability matrix template
Table 1 through to Table 8 provides a list of attributes under different headings and these
should feature in a typical requirements verification and traceability matrix (RVTM).
Table 1 – Attributes for 'Description' in a RVTM
Attribute Suggested type Description

Requirement ID String Unique identifier for the requirement
Requirement clause String Description of the requirement
Requirement type String • capability – requirements from the stakeholders on
the functionality of a design discipline or disciplines
or the system, that is, requirements on what the
system does or provides
• constraint – requirements defining the boundaries
for the possible solution, that is, qualities demanded
by the user
• assumptions – a statement that is ambiguous or
requires further clarification prior to it being
accepted as a requirement
• supporting – information that supports a
requirement or group of requirements; supporting
objects do not need to be verified and validated
Rationale String A description of why this requirement is required or why
this requirement is important to the stakeholders.
Table 2 – Attributes for 'Assign' in a RVTM

Allocation String Teams or elements that are partially or fully responsible
for ensuring this requirement is met.
Accountable String Person who will be accountable for ensuring this
requirement is met.
Due date Date Date by when the requirement should be implemented.
Table 3 – Attributes for 'Backward traceability' in a RVTM

Source String Original source of the requirement
Stakeholders String People who use this requirement, should be consulted
on changes.
Table 4 – Attributes for 'Forward traceability' in a RVTM

Dependencies String Child requirements that have traceability linked to this
requirement.

T MU AM 06007 GU
Version 3.0

Use case NA Link to relevant use cases that verify the requirement is
necessary.
Design elements NA Link to relevant design elements.
Test cases NA Link to test cases that verify the requirement will be met.
Table 5 – Attributes for 'Verification and validation' in a RVTM

Verification and String Examples include inspection, analysis, demonstration,
validation method test, and certification.
Verification and String Identify the documents that demonstrate where and how
validation document the requirements are verified or validated or both.
Verification and String Identify where the verification or validation evidence can
validation evidence be located.
Table 6 – Attributes for 'Requirement status' in a RVTM

Requirement status String • proposed – new or changed requirements are set at
this classification
• approved – requirements that have been approved
and baseline established by the stakeholders are
set at this classification
• completed – requirements that have been satisfied
by testing, or other means are set to this
classification
• nonconformance – requirements which cannot be
delivered by the project
• removed/on hold – statements that were previously
requirements, but have been removed from scope
or suspended are set to this classification
• N/A – items that are not requirements are set to this
classification
Date Date Date the requirement was last reviewed.
Author String The most recent editor of the requirement.
Version Integer Current version of the requirement.
Table 7 – Attributes for 'Requirement prioritisation' in a RVTM

Priority, importance Integer How important the delivery of this requirement is for the
project success.
Risk Integer Level of risk that this requirement places on the project
and company.

T MU AM 06007 GU
Version 3.0
Table 8 – Attributes for 'Miscellaneous' in a RVTM

Comments String N/A

T MU AM 06007 GU
Version 3.0
Appendix B Requirements repository structure

Figure 5 shows the relationships between the business level requirements, system level
requirements and element level requirements.
Figure 5 – Requirements repository structure diagram

T MU AM 06007 GU
Version 3.0
Appendix C Requirement examples

Table 9 provides the list of attributes that exhibit in the requirement statements.
Table 9 – Attributes exhibited in requirement statements
Attribute Description Requirement example

Clear and Requirements contain clear and The system [subject] shall provide [verb] the
concise concise language, avoiding unclear level of operational capability [condition] of 24
phrases such as "the required level of trains per hour [value].
operation capability".
Specific Requirements contain specific The system [subject] shall operate [verb] from
information, avoiding non-specific an N-1 redundant electrical supply [constraint]
phrases such as "from electricity". of 240 V ac [value], 50 Hz [value].
Necessary Requirements are essential, avoiding The card reader [subject] shall operate [verb]
unnecessary requirements such as continuously [constraint] over its operating life
“The card reader shall operate 24/7” [condition] of 25 years [value].
and “The card reader shall operate
Monday through to Sunday".
Valid Requirements are logically valid The system [subject] shall operate [verb] in one
avoiding invalid phrases such as mode at a time [constraint].
"operate in all modes all the time".
Implementation Requirements are implementation The system [subject] shall break [verb] the load
independent independent avoiding implementation circuit [object] when the load current exceeds
dependent phrases such as "use [constraint] 10 A ac [value], 50 Hz [value] for
Acme 123 circuit breakers". greater [constraint] than 200ms [value].
Unambiguous Requirements contain unambiguous The user interface [subject] shall operate [verb]
language avoiding ambiguous by keyboard [object].
phrases such as "operate solely by The user interface [subject] shall operate [verb]
mouse or keyboard". by mouse [object].
Verifiable Requirements are able to be verified The 8-car train [subject] shall weigh [verb] a
avoiding unverifiable phrases such as maximum [constraint] of 500 tonnes [value] fully
"The system shall be as light as loaded [constraint].
possible".
Feasible Requirements are implementation The base station [subject] shall operate [verb]
feasible avoiding not feasible phrases from solar energy [constraint].
such as "operate from dark energy".
Traceable Requirements are traceable to a The train [subject] shall be repairable [verb]
source requirement, standard or according to service level agreement XYZ
document avoiding not traceable [constraint].
phrases such as "be repairable in two
hours".
Consistent Requirements contain consistent The train car body [subject] shall be
information avoiding inconsistent constructed [verb] from non-magnetic materials
phrases such as "non-magnetic mild [constraint].
steel".

T MU AM 06007 GU
Version 3.0
Attribute Description Requirement example

Atomic Requirements are atomic containing The train [subject] shall accelerate [verb] from
one requirement, avoiding [constraint] 0 km/h [value] to [constraint]
non-atomic phrases such as 60 km/h [value] within [constraint].10 seconds
"accelerate from 0 km/h to 60 km/h in [value].
10 seconds and brake to 0 km/h in The train [subject] shall brake [verb] from
5 seconds". [constraint] 60 km/h [value] to [constraint]
0 km/h [value] within [constraint] 5 seconds
[value].

T MU AM 06007 GU
Version 3.0
Appendix D SRS examples

Section D.1 and Section D.2 provide examples of structuring system requirement specifications
based on ISO/IEC/IEEE 29148:2011.
D.1. Example 1 – Replacement of a road level

crossing
The following is an example of a system requirement specification for replacement of a road
level crossing.
Note that this example includes the system requirement headings only and does not
include the actual system requirements.
System purpose
To improve safety and traffic flow the existing road level crossing should be replaced by a grade
separation.
System scope
The system is the level crossing replacement. The business requirements for this project are
defined in the level crossing replacement business requirements specification. The level
crossing currently causes traffic congestion on the road, safety and security incidents.
The system will remove the existing level crossing and provide a grade separated thoroughfare
for road vehicles, cyclists and pedestrians. The system will not divert the road and the railway
lines.
System overview
System context
The system consists of the following major elements:
• railway lines
• trains operating on the railway lines
• thoroughfare
• vehicles driving through the thoroughfare
• pedestrians walking through the thoroughfare
• cyclists riding through the thoroughfare

T MU AM 06007 GU
Version 3.0
System functions
The major system capabilities, conditions and constraints are as follows:
• railway line for passenger, freight and maintenance rail vehicles
• vehicle thoroughfare for light and heavy road vehicles
• cycle thoroughfare for bicycle riders
• pedestrian thoroughfare for pedestrians
User characteristics
Users of the system have the functions and locations as provided in Table 10.
Table 10 – user functions and locations
User Function Location

Train crew Operating suburban, country and freight Trains
trains
Railway maintenance Sustaining civil, track, signals, overhead Rail corridor

personnel wiring, electrical and communications assets
Vehicle drivers Controlling cars, motorbikes, buses, trucks Thoroughfare
and articulated vehicles
Pedestrians Walking, jogging and running Thoroughfare
Cyclists Riding bicycles Thoroughfare
Road maintenance personnel Sustaining road, footpaths, lighting and Thoroughfare
signage
System requirement headings
Functional requirements
• decommissioning of existing
• grade separation
• railway lines
• railway signage
• railway lighting
• railway signalling
• control systems
• railway fencing
• traction power
• signalling power

T MU AM 06007 GU
Version 3.0
• overhead wiring
• railway safety
• roadway safety
• cycleway safety
• pathway safety
• telecommunications
• stormwater management
• water supply
• electrical supply
• fresh air supply
• fire and life safety
• exhaust fumes
• roadway
• pathway
• cycleway
• roadway signage
• thoroughfare lighting
• security monitoring
• railway fencing
Usability requirements
• train drivers
• vehicle drivers
• pedestrians
• cyclists
• maintainers
Performance requirements
• number of railway lines
• train types

T MU AM 06007 GU
Version 3.0
• number of vehicle lanes
• vehicle types
• number of footpaths
• number of bike lanes
• operational life
• fence heights
• train frequency
• train speeds
• roadway speeds
• cycleway speeds
• railway lighting levels
• thoroughfare lighting levels
• monitoring coverage
• monitoring resolution
• monitoring retention
• availability of thoroughfare
• availability of railway lines
• visual appearance
System interfaces
External interfaces
• railway lines
• signalling systems
• telecommunication systems
• buildings (includes railway, residential and commercial buildings)
• stabling yards
• train stations
• roadway
• footpath
• cycleway

T MU AM 06007 GU
Version 3.0
• overhead wiring
• water supply
• gas supply
• stormwater system
• electrical supply
• earthing and bonding
Internal interfaces
• trains on tracks
• trains to overhead wiring
• trains to signalling system
• vehicles on thoroughfare
• pedestrians on thoroughfare
• bikes on thoroughfare
• railway tracks to thoroughfare
System operations
Human system integration
• footpath operation
• bike path operation
• maintainer operation
Maintainability
• railway lines mean time to repair
• railway lines maximum time to repair
• thoroughfare mean time to repair
• thoroughfare maximum time to repair
• rail possession frequency
• rail possession duration
• thoroughfare inspection

T MU AM 06007 GU
Version 3.0
• graffiti prevention
• graffiti removal
Reliability
• railway lines reliability normal operating mode
• thoroughfare reliability normal operating mode
System modes and states
• normal operating mode
• maintenance mode
• fault mode
• emergency mode
Physical characteristics
Physical
• railway line location
• thoroughfare location
Adaptability
• additional rail lines
• additional roadway lanes
• dedicated cycle lanes
Environmental conditions
• temperature range
• humidity range
• dirt and dust
• salt spray
• flooding
• railway noise
• railway vibration
• electromagnetic emissions
• ventilation

T MU AM 06007 GU
Version 3.0
System security
Physical security
• access to railway lines
Network security
• access to surveillance video
Information management
• information displays
• video archiving
• video playback
Policies and regulations
• ISO standards
• Australian standards
• ASA standards
• Rail Safety Act
• Disability Discrimination Act
• Work Health and Safety (WHS) Act
• Sustainability Design Guidelines
• Electromagnetic compatibility standards
• RISSB standards
System life cycle sustainment
• operational support facilities
• maintenance support facilities
• training
• competency
• spare parts
• durability of components
• obsolescence of components
• documentation

T MU AM 06007 GU
Version 3.0
• operation manuals
• maintenance manuals
• inspection manuals
Packaging, handling, shipping and transportation
• road deliveries
• rail deliveries
Verification
The system verification plan defines the verification approaches and methods to verify each of
the system requirements.
Assumptions and dependencies
• dependency between the thoroughfare and the geotechnical conditions
• assumption that the roadway alignment is retained
• assumption that railway line alignment is retained
D.2. Example 2 – Rolling stock replacement program

The following is another example of a system requirement specification for a rolling stock
replacement program based on ISO/IEC/IEEE 29148:2011.
Note that this example includes the system requirement headings only and does not
include the actual system requirements.
System purpose
To improve the safety, reliability and overall customer experience on the existing electric rail
network by replacing the electric rolling stock fleet.
System scope
The system is the rolling stock fleet replacement. Defined in the rolling stock replacement
business requirements specification are the business requirements for this project.
The system will replace the existing electric rolling stock fleet with comfortable, safe and reliable
rolling stock.
The system will operate with the existing fixed infrastructure and depots.

T MU AM 06007 GU
Version 3.0
System overview
System context
The system consists of the following major elements:
• trains
• trains on railway lines
• passengers on trains
• train crew on trains
System functions
The major system capabilities are as follows:
• move passengers
• carry passengers
• train crew control
User characteristics
Users of the system have the functions and locations as specified in Table 11.
Table 11 – User functions and locations
User Function Location

Passengers Travelling on trains Trains, stations
Train crew Operating trains Trains, stations, depots
Operational staff Monitoring and controlling trains Stations, control centres,
depots
Revenue protection Inspecting tickets or cards and issuing Trains, stations
officers fines
Police Monitoring and controlling passengers Trains, stations
Maintenance staff Sustaining trains Trains, stations, depots
Trainers Educating train crew, operational and Trains, stations, training
maintenance staff facilities
Cleaners Removing of internal rubbish and dirt Trains, stations, depots
and external washing of trains
System requirement headings

Functional requirements
• propulsion
• guide on track

T MU AM 06007 GU
Version 3.0
• contain passengers and train crew
• contain load
• passenger seating
• passenger standing
• customer experience
• passenger safety
• train crew safety
• heating, ventilation and air conditioning
• platform ingress and egress
• emergency ingress and egress
• fire and life safety
• external lighting
• internal lighting
• headlights
• taillights
• windows
• passenger displays
• announcements
• Wi-Fi
• passenger telephones
• electrical power
• security monitoring
• crew accommodation
• crew controls
• train monitoring
• crew displays
• crew communications

T MU AM 06007 GU
Version 3.0
• signage
• train visibility
• data logging
Usability requirements
• suburban metropolitan and regional rail network
• train crew
• people walking
• people with disabilities
• cyclists
• maintainers
Performance requirements
• seating capacity
• standing capacity
• crashworthiness
• humidity range
• ventilation capacity
• ingress and egress capacity
• station compatibility
• window coverage
• passenger display coverage
• passenger display illumination
• passenger display capacity
• announcement coverage
• announcement levels
• natural light levels
• artificial lighting levels
• ride levels
• noise levels

T MU AM 06007 GU
Version 3.0
• vibration levels
• security monitoring coverage
• security monitoring resolution
• security monitoring retention
• data parameters
• data retention
• crew accommodation capacity
• crew control levels
• train monitoring parameters
• crew communication types
• operating life
• operating speeds
• acceleration
• speed sustainment
• deceleration
• stopping
• supply voltage
• supply frequency
• headlight illumination
• taillight illumination
• exterior light illumination
• power consumption
• availability
• branding
• colour schemes
System interfaces
External interfaces
• railway lines
• overhead wiring

T MU AM 06007 GU
Version 3.0
• signalling systems
• control systems
• telecommunication systems
• earthing and bonding
• platforms
Internal interfaces
• passengers
• train crew
• operational staff
• maintenance staff
System operations
Human system integration
• door operation
• seat operation
• emergency response operation
• emergency door release operation
• train crew controls operation
• maintainer operation
Maintainability
• mean time to repair
• maximum time to repair
• periodic maintenance
• inspection access
• graffiti prevention
• graffiti removal
• internal cleaning
• external cleaning

T MU AM 06007 GU
Version 3.0
Reliability
• reliability normal operating mode
System modes and states
• normal operating mode
• maintenance mode
• fault mode
• emergency mode
Physical characteristics
Physical
• weight
• volume
• dimensions
Adaptability
• additional signalling systems
• additional communication systems
Environmental conditions
• humidity range
• wind
• rain
• snow
• dirt and dust
• noise
• vibration
• electromagnetic emissions
System Security
• access to crew accommodation
• access to surveillance video

T MU AM 06007 GU
Version 3.0
• access to train data
Information management
• video archiving
• data retention
• video playback
Policies and regulations
• Australian standards
• ISO standards
• ASA standards
• Rail Safety Act
• Disability Discrimination Act
• WHS Act
• Sustainability Design Guidelines
• Electromagnetic compatibility standards
• RISSB standards
System life cycle sustainment
• operational support facilities
• maintenance support facilities
• wash facilities
• training
• competency
• spare parts
• durability of components
• obsolescence of components
• documentation
• operation manuals
• maintenance manuals
• inspection manuals

T MU AM 06007 GU
Version 3.0
Packaging, handling, shipping and transportation
• delivery to site
Verification
The system verification plan defines the verification approaches and methods to verify each of
the system requirements.
Assumptions and dependencies
• dependency between train acceleration and the traction power supply
• assumptions that the system will operate with the existing train operating conditions
• assumption that the system will operate with the existing infrastructure

T MU AM 06007 GU
Version 3.0
Appendix E Requirements specification review

This appendix provides guidance for the review of requirements specifications in particular
business, system and subsystem specifications by specialist peers, stakeholders and senior
management. The guidance lists the relevant review criteria used by reviewers of specifications
to improve the quality of the delivered specifications. The three types of reviews for a
specification shown in the correct order are peer review, stakeholder review and approval
review.
Peer (or technical) review

The first review of a specification is a peer (or technical) review by technical specialists with
domain knowledge. The objective of the peer review is to verify the specification technical and
quality correctness. Table 12 specifies the suggested technical review criteria for the
specification and Table 13 specifies the suggested quality review criteria for the specification.
Table 12 – Technical review criteria
Review criteria Yes No

The requirements specify system interfaces
The requirements specify system environmental conditions
The requirements include constraints
The appropriate validation methods are defined for each business requirement
The appropriate verification methods are defined for each system requirement
The appropriate verification methods are defined for each subsystem
requirement
The requirements can be checked reasonably and practically
The requirements are implementation-independent, except where constraints or
limitations mandate a specific implementation solution
The requirements are consistent (no contradictions or conflicts)
The requirements are traceable to the source (no orphan requirements)
Table 13 – Quality review criteria

The requirements use bounded clauses (no open-ended clauses such as “to be
confirmed” or “etc.”)
The requirements use defined terms and acronyms
Consistent terms are used throughout
The requirements are necessary (no duplication of requirements)
The requirements are specific (no ambiguous or vague clauses)
The requirements are atomic (multiple requirements are not concatenated
together)

T MU AM 06007 GU
Version 3.0
Stakeholder (or user) review

The second review is a stakeholder or user review. The objective of the stakeholder review is to
validate the specification is right for the stakeholder needs. Table 14 specifies the suggested
stakeholder review criteria for the specification.
Table 14 – Stakeholder Review Criteria

The requirements meet the needs of the stakeholders
The requirements consider the customer needs
The requirements can be achieved in the context of the stakeholder constraints
The requirements consider long-term value for money
Approval (or senior management) review

Finally, the third review is an approval or senior management review. The objective of the
approval review is to validate the specification development has followed due process. Table 15
specifies the suggested approval review criteria for the specification.
Table 15 – Approval review criteria

The specification has been peer reviewed by individuals
The specification has been reviewed by stakeholders from the relevant groups
Issues identified in the peer reviews have been resolved
Issues identified in the stakeholder reviews have been resolved
The specification supports the business case

Guide To Requirements Definition and Analysis

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Guide To Requirements Definition and Analysis

Uploaded by

Document Information

Original Title

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

Guide To Requirements Definition and Analysis

Uploaded by

Copyright:

Available Formats

T MU AM 06007 GU

Guide to Requirements Definition

© State of NSW through Transport for NSW

For queries regarding this document,

© State of NSW through Transport for NSW

This document is the third issue.

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

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

T MU MD 00009 ST AEO Authorisation Requirements defines the mandatory requirements for

An AEO's engineering management plan, systems engineering management plan or equivalent

It also contains general guidance on requirements management tools, requirements change

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

ISO/IEC/IEEE 29148:2011 Systems and software engineering – Life cycle processes –

Transport for NSW standards

TS 10504 AEO Guide to Engineering Management

TS 10506 AEO Guide to Verification and Validation

TS 20001 System Safety Standard for New or Altered Assets

T MU AM 04003 GU Configuration Management Guide

T MU AM 06010 GU Business Requirements Specification

T MU MD 00009 ST AEO Authorisation Requirements

INCOSE Guide for Writing Requirements

4. Terms and definitions

accountable the obligation of an individual or an organisation to account for its activities,

ASA Asset Standards Authority

assurance a positive declaration intended to give confidence. It provides evidence of effective

authorisation the conferring of authority, by means of an official instruction and supported by

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

COTS commercial off-the-shelf

EMP engineering management plan

framework a basic structure underlying a system, concept, or text

MCD maintenance concept definition

OCD operations concept definition

OMG Object Management Group, Inc.

performance the extent or how well a function or task is conducted

RAM reliability, availability and maintainability

RAMS reliability, availability, maintainability and safety

RATM requirements analysis, allocation and traceability matrix

responsible a duty or obligation to satisfactorily perform or complete a task (assigned by

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

SEMP systems engineering management plan

SRS system requirements specification

TfNSW Transport for New South Wales

WHS work health and safety

• transform the requirements into an effective product

• use the product to provide the required services

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

• sustain the provision of those services

• dispose of the product when it is retired from service

T MU MD 00009 ST AEO Authorisation Requirements states mandatory requirements for

5.1. Objectives of requirements management

• provide a complete set of unambiguous requirements

• define a structure for the storage and management of the requirements

• eliminate conflicting and duplicating requirements

• provide a foundation for system verification and validation

5.2. Requirement types and attributes

• clear and concise

• implementation independent – the needs should be independent of the solution