RM.12_Authority_SDLC_Requirements.pdf

Systems Development Life Cycle (SDLC) Requirements

December 03, 2019

California High-Speed Rail Authority Agreement No.: HSR 19-13

Track and Systems Systems Development Life Cycle Requirements Page i

Table of Contents

1 INTRODUCTION

1.1 Purpose

1.2 Scope

1.3 System Description

1.4 Reference Standards

1.5 Terms and Acronyms

2 TECHNICAL MANAGEMENT

2.1 Systems Engineering Management Plan

2.2 Scope Management

2.3 Time Management

2.4 Configuration Management

2.5 Organizational Management

2.6 Risk Management

2.7 Subcontractor Management

2.8 Qualification and Training

3 SYSTEMS DEVELOPMENT LIFE CYCLE PHASES

3.1 Systems Development Life Cycle Model

3.2 Mobilization Phase

3.3 System Definition and Operational Context Phase

3.4 System Requirements Phase

3.5 System Architecture Phase

3.6 Final Design Phase

3.7 Manufacturing and Construction Phase

3.8 Field / Site Testing Phase

3.9 System Integration Testing Phase

3.10 System Start-Up Testing Phase

3.11 Pre-Revenue Operation Phase

3.12 System Certification and Acceptance Phase

3.13 Operations and Maintenance Phase

3.14 Handback

4 CROSS-CUTTING SYSTEMS ENGINEERING METHODS

4.1 Requirements Management

4.2 Interface and Integration Management

4.3 Verification and Validation Management

4.4 Testing and Commissioning Management

4.5 System Certification Management

5 SPECIALTY ENGINEERING INTEGRATION

6 REVIEW MILESTONES AND ASSOCIATED DELIVERABLES

6.1 Mobilization Phase Review

6.2 System Definition Review

Systems Development Life Cycle Requirements Page ii

6.3 System Requirements Review

6.4 Preliminary Design Review

6.5 Final Design Review

6.6 First Article Demonstration Review

6.7 Field Testing Review

6.8 System Integration Testing Review

6.9 System Start-Up Testing Review

6.10 Pre-Revenue Operation Review

6.11 System Certification and Acceptance Review

Figures

FIGURE 1: SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC) FRAMEWORK

FIGURE 2: SYSTEMS DEVELOPMENT LIFE CYCLE SCOPE

FIGURE 3: SYSTEMS DEVELOPMENT LIFE CYCLE MODEL

FIGURE 4: HOLISTIC SYSTEM DEVELOPMENT WITH PHASED SUB-SYSTEM DEVELOPMENT

FIGURE 5: SYSTEM ARCHITECTURE VS. SYSTEM INTEGRATION CONCEPT

FIGURE 6: SYSTEM DECOMPOSITION

FIGURE 7: REQUIREMENTS TRACEABILITY MODEL

FIGURE 8: REQUIREMENTS ANALYSIS AND ALLOCATION

FIGURE 9: ENGINEERING ANALYSES

FIGURE 10: RVTM CONTENT AND TRACEABILITY – REQUIREMENTS AND DESIGN

FIGURE 11: RVTM CONTENT AND TRACEABILITY – TESTING AND COMMISSIONING

FIGURE 12: SYSTEM CERTIFICATION METRIC

Tables

TABLE 1: ACRONYMS

TABLE 2: MILESTONE SUBMITTALS – MOBILIZATION PHASE

TABLE 3: MILESTONE SUBMITTALS – SYSTEM DEFINITION REVIEW

TABLE 4: MILESTONE SUBMITTALS – SYSTEM REQUIREMENTS REVIEW

TABLE 5: MILESTONE SUBMITTALS – PRELIMINARY DESIGN REVIEW

TABLE 6: MILESTONE SUBMITTALS – FINAL DESIGN REVIEW

TABLE 7: MILESTONE SUBMITTALS – FIRST ARTICLE DEMONSTRATION

TABLE 8: MILESTONE SUBMITTALS – FIELD TESTING REVIEW

TABLE 9: MILESTONE SUBMITTALS – SYSTEM INTEGRATION TESTING REVIEW

TABLE 10: MILESTONE SUBMITTALS – SYSTEM START-UP TESTING REVIEW

TABLE 11: MILESTONE SUBMITTALS – PRE-REVENUE OPERATION REVIEW

TABLE 12: MILESTONE SUBMITTALS – SYSTEM CERTIFICATION AND ACCEPTANCE REVIEW

Systems Development Life Cycle Requirements Page 1

1 Introduction

1.1 Purpose

The purpose of this document is to define the following TS1 Contract requirements:

1. Systems Development Life Cycle (SDLC) identifies the SDLC phases and milestones.

2. Systems Engineering Management Plan (SEMP) defines the mandatory SEMP outline and content.

3. Systems Engineering Management identifies the key systems engineering (SE) deliverables and associated requirements.

4. SDLC Framework serves as a framework to allocate non-SE Contract deliverables to

SDLC phases and corresponding submittal and review milestones.

Figure 1: Systems Development Life Cycle (SDLC) Framework

The SDLC defined in this document is tailored to and based on prevailing best-practice industry standards that are applied to U.S rail transportation projects and include European Norm (EN) 50126; Institute of Electrical and Electronics Engineers (IEEE) 15288 and 29148; International Council on Systems Engineering (INCOSE) Systems Engineering Handbook; and the United States (U.S.) Department of Transportation (DOT) Federal Railroad Administration (FRA) Monitoring Procedure (MP) 54: Readiness for Revenue Operations.

The purpose of this document is not to define the functional and/or technical requirements for the track and systems elements of California High-Speed Rail (HSR) system. Refer to other TS1 Contract documents for that purpose.

Systems Development Life Cycle Requirements Page 2

1.2 Scope

The Contractor shall serve as the HSR systems integrator, having full responsibility for successfully delivering a fully functioning HSR system (the System) as depicted in Figure 2, including the integration of the HSR system with third parties such as utilities, shared corridors/track, external systems, etc. System Integration shall include operational, procedural, and technical integration. For a detailed scope of work, refer to the corresponding TS1 Contract documents.

The Contractor’s SEMP shall address the full HSR system scope. Software engineering may use its own SDLC (e.g., spiral, agile, scrum) if properly aligned with and integrated into the HSR system SDLC phases and milestones, documented in the SEMP, and approved by the California High-Speed Rail Authority (the Authority).

Unless otherwise noted, all requirements in this document shall be performed by the Contractor.

In the event that a requirement of this document conflicts with another Contract requirement, the most stringent requirement or interpretation shall apply, as determined by the Authority.

Figure 2: Systems Development Life Cycle Scope

Systems Development Life Cycle Requirements Page 3

1.3 System Description

Refer to the 2018 CA High-Speed Rail Authority Business Plan and the 2019 Project Update Report for the HSR system description.

1.4 Reference Standards

• CA High-Speed Rail Authority: 2018 Business Plan

• CA High-Speed Rail Authority: 2019 Project Update Report

• European Union (EU) – Agency for Railways (ERA) – Technical Specifications for Interoperability (TSI): Latest Revisions

• IEEE 12207:2017: ISO/IEC/IEEE International Standard – Systems and Software Engineering – Software Life Cycle Processes

• INCOSE Systems Engineering Handbook Rev. 4: A Guide for System Life Cycle Processes and Activities

• EN 50126:2017: Railway Applications – The Specification and Demonstration of Reliability, Availability, Maintainability and Safety

• EN 50129:2018: Railway Applications – Communication, Signalling and Processing Systems – Safety related Electronic Systems for Signalling

• ISO/IEC/IEEE 15288:2015: Systems and Software Engineering – System Life Cycle Processes

• ISO/IEC/IEEE 29148:2011: Systems and Software engineering – Life Cycle Processes – Requirements Engineering

• Project Management Institute: Project Management Body of Knowledge, Rev 6.0

• U.S. DOT FRA, MP 54: Readiness for Revenue Operations

1.5 Terms and Acronyms

Table 1 provides the acronyms used in this document.

Table 1: Acronyms

Acronym Term ABL Allocated Requirements Baseline ATC Automatic Train Control CA California CBL Contract Requirements Baseline CDRL Contract Data Requirements List, see TCSL CI Critical Item CIL Certifiable Items List CM Configuration Management

Systems Development Life Cycle Requirements Page 4

Acronym Term CSI Construction Specifications Institute DOORS Dynamic Object Oriented Requirements System DOT Department of Transportation DXL DOORS eXtension Language EN European Norm ERA (EU) Agency for Railways EU European Union FAR First Article Demonstration Review FDL Final Design Baseline FDR Final Design Review FRA Federal Railroad Administration F/ST Field/Site Testing FTR Field Testing Review GO General Order (California Public Utilities Commission) HSR High-Speed Rail ICD Interface Control Document IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers INCOSE International Council on Systems Engineering ISO International Organization for Standardization MBSE Model Based Systems Engineering MoM Module of Metrics MP Monitoring Procedure MPR Mobilization Phase Review M&C Manufacturing and Construction NFPA National Fire Protection Association OCC Operations Control Center QA/QC Quality Assurance/Quality Checking PDR Preliminary Design Review PRO Pre-Revenue Operation RAMS Reliability, Availability, Maintainability and Safety RM Requirements Management RVTM Requirements Verification Traceability Matrix SA System Architecture SBL System Requirements Baseline SCAP System Certification and Acceptance Plan SCM System Certification Metric SCR System Certification and Acceptance Review SDLC Systems Development Life Cycle SDOC System Definition and Operational Context

Systems Development Life Cycle Requirements Page 5

Acronym Term SDR Systems Definition Review SE System Element SE Systems Engineering SEMP Systems Engineering Management Plan SI System Integration SIR System Integration Testing Review SIT System Integration Testing SONO Statement of No Objection SOTP System Operational Testing Plan SR System Requirements SRR System Requirements Review SRS Software Requirements Specification SSTP Sub-System Testing Plan STR System Start-Up Testing Review SSRS Sub-System Requirements Specification StRS Stakeholder Requirements Specification SUT System Start-Up Testing SUTP System Start-Up Testing Plan SyRS System Requirements Specification T&C Testing & Commissioning TCP Testing & Commissioning Plans TCR Technical Contract Requirements TCS Technical Contract Submittal TCSL Technical Contract Submittal List TS1 Track and Systems 1 TSI Technical Specifications for Interoperability TWBS Technical Work Breakdown Structure U.S. United States URL Uniform Resource Locator V&V Verification and Validation WBS Work Breakdown Structure

Terms are defined in other Contract documents.

Systems Development Life Cycle Requirements Page 6

2 Technical Management

2.1 Systems Engineering Management Plan

Prepare, submit, and implement a Contractor systems engineering management plan (SEMP) that follows the requirements of this document. The SEMP shall follow the structure of this SDLC document. For each section, describe the Contractor’s management approach.

Describe the planned SDLC methodology and proposed efforts for planning, executing, monitoring and controlling a systematic engineering effort.

The SEMP shall describe the following for each SDLC phase: (1) Inputs, (2) Outputs [Deliverables], (3) Activities, tools and methods used to create the deliverables, (4) Roles and responsibilities, (5) Stakeholder coordination, (6) Submittal and review milestones, and (7) Performance metrics and reports.

2.2 Scope Management

Prepare, submit and implement a hierarchical and deliverable based technical work breakdown structure (TWBS) in accordance with Project Management Body of Knowledge scope management process, and as conceptually presented in Figure 2 and Figure 6. Identify and assign all technical contract submittals (TCS) required in the Contract and planned by the contractor.

Integrate the TWBS with the overall Contract WBS. For a definition of TCS, refer to the General Provisions Schedule 8.

The TWBS shall identify the following for each TCS: (1) Contract reference, (2) Unique TCS identifier, (3) TCS name, (4) SDLC phase, (5) SDLC milestone, (6) Due date, and (7) Authority disposition [i.e., Approval, Statement of No Objection, Review] coordinated with the Contractor’s document control system.

2.3 Time Management

Prepare, submit and implement a technical schedule including all TWBS deliverables in accordance with the Project Management Body of Knowledge time management process.

Integrate the technical schedule with the overall Contract schedule.

The technical schedule shall include (1) SDLC phase, (2) SDLC milestones, (3) TWBS deliverables,

(4) Assigned owner for each TWBS deliverable, and (5) Associated activities for each TWBS deliverable. Identify the technical dependencies [Technical Critical Path] between the TWBS deliverables.

2.4 Configuration Management

Prepare, submit and implement a comprehensive configuration management (CM) process as defined in the latest revision of ISO/IEC/IEEE 15288. Integrate the CM process with the CM requirements described in other Contract documents.

Systems Development Life Cycle Requirements Page 7

The CM process shall include (1) Planning of CM, (2), Performing configuration identification, (3) Performing configuration change management, (4) Performing configuration status accounting,

(5) Performing configuration evaluation, and (6) Performing release control.

As part of the configuration identification process, identify systems, sub-systems, and system elements and associated information (e.g., requirements, documentation) as configuration items (CI). The CIs shall be presented in a hierarchical and structured manner enabling the identification of affected configuration items and baselines for impact assessment. Establish the configuration baselines (BL) identified in Figure 3 and as described throughout the SDLC phases.

2.5 Organizational Management

Prepare and submit an organizational breakdown structure (OBS). The OBS shall present the organizational and reporting relationships, including any Joint Venture partners, subcontractors, and suppliers.

The OBS shall be sufficiently detailed to identify each owner of deliverables identified in the TWBS. Additionally, the OBS shall be sufficiently detailed to identify each owner of HSR sub-systems, systems elements down to the lowest configuration item, and associated interfaces.

The OBS shall be supported by a clear description of roles and responsibilities for each position.

2.6 Risk Management

Perform risk management as described in the Contract documents. Treat technical risk mitigations as technical contract requirements (TCR) following the requirement management process (section 4.1).

2.7 Subcontractor Management

Fully integrate Joint Venture partners, subcontractors and suppliers into the systems engineering management efforts.

2.8 Qualification and Training

Employ one or more senior systems engineer for the life of the project with at least 10 years of systems engineering experience, of which five years shall be in the rail transportation industry.

The senior Systems engineer shall: (1) Be an INCOSE certified / expert systems engineering professional [CSEP/ESEP], (2) Report directly to the project manager, (3) Oversee the SDLC activities described in this book, (4) Have authority to direct and be accountable for all SDLC activities, (5) Have experience with design / build contracts, and (6) Be present at a local project office of at least 50%.

The senior systems engineer shall provide SDLC training to key Contract personnel, including

(1) Executive positions, (2) Director and deputy director positions, (3) Manager positions, (4) Supervising positions, and (5) Positions directly executing SDLC activities such as analysts, designers, testers, and certifiers. Cover all processes described in this document.

Systems Development Life Cycle Requirements Page 8

3 Systems Development Life Cycle Phases

3.1 Systems Development Life Cycle Model

Figure 3 presents the Systems Development Life Cycle (SDLC) model the Contractor shall follow.

The model has been tailored from the generic VEE model defined in the INCOSE Systems Engineering Handbook, the rail specific application to Reliability, Availability, Maintainability and Safety in EN 50126, and has been adjusted to meet the U.S. DOT FRA requirements to demonstrate readiness for revenue operations (i.e., monitoring procedure 54). The model identifies SDLC phase, milestone, and baseline, which is discussed in detail in the following sections.

Figure 3: Systems Development Life Cycle Model

Systems Development Life Cycle Requirements Page 9

While eventually HSR sub-systems (e.g., trackwork) of this Contract may be fast-tracked, the HSR system shall be developed holistically as one system, before advancing to the final design of the sub-systems and/or system elements, as presented in Figure 4.

Failure to complete the HSR system-level SDLC phases before starting final design of HSR sub-systems may result in missing applicable (allocated) sub-system requirements and/or interfaces, may lead to non-conforming designs and/or construction, and may not be noticed before system integration and system testing. Failure to adhere to the SDLC shall be solely the Contractor’s responsibility.

If phased development is utilized, corresponding milestones shall apply to each of the phased sub-systems and/or system elements, as shown in Figure 4.

Figure 4: Holistic System Development with Phased Sub-System Development

3.2 Mobilization Phase

The key purpose of the mobilization phase is to start-up the project, establish project management, and finalize the key deliverables started during the project proposal.

The key deliverables1 of this phase are the project management plan, schedule, and other key plans, strategies, policies, as specified in the Contract.

The review milestone for this phase is the mobilization phase review (MPR). This phase is completed when all MPR phase deliverables defined in the Contract have been accepted by the Authority (i.e., approved or a Statement of No Objection).

3.2.1 Project Plans

Prepare, submit, and implement the Contractor systems engineering management plan (SEMP) as defined in section 2.1.

Prepare, submit, and implement other project planning documents as specified in the Contract.

1 The SDLC defines Systems Engineering deliverables using the SDLC framework, only. For non-SE deliverables, refer to other Contract documents.

Systems Development Life Cycle Requirements Page 10

3.3 System Definition and Operational Context Phase

The key purpose of the system definition and operational context (SDOC) phase is to (1) Create the contract requirements baseline, (2) Define the system and its mission profile including the system boundary, (3) Identify operational constraints, and (4) Develop system testing, certification and acceptance plans.

The key deliverables2 of this phase are (1) Contract requirements baseline, (2) System definition,

(3) a System certification and acceptance plan, and (4) a System operations testing plan.

Follow the general provisions of EN 50126 and IEEE 29148, addressing specifically (1) EN 50126:

7.3 Phase 2: System definition and operational context, and (2) IEEE 29148 6.2 Stakeholder requirements definition process.

The structure and content of the SDOC phase deliverables shall be sufficiently detailed to serve as key input into the (1) System requirements phase [section 3.4] and (2) Pre-revenue operation phase [section 3.11].

The review milestone for this phase is the systems definition review (SDR). This phase is completed when all SDOC phase deliverables defined in the Contract have been accepted by the Authority.

3.3.1 Contract Requirements Baseline

Capture the executed Contract in the requirements management (RM) tool using the requirements management process (section 4.1), and baseline it using RM tool baseline functions.

3.3.2 System Definition

Prepare, submit, and implement the system definition, including (1) Mission profile, (2) System boundary, and (3) Operational environment and constraints.

Define the system and its mission profile, including (1) System objective [the intended purpose],

(2) Description of the system under consideration, (3) Long-term operating strategy and conditions, (4) Long-term maintenance strategy and conditions, (5) Long-term system life-time considerations, and (6) Resulting system functions.

Operations and maintenance strategies shall address (1) Train/Passenger service planning, (2) Train operation, (3) Station operation, (4) Trainset maintenance, (4) Track and systems maintenance, (5) Civil works maintenance, and (6) Any other HSR system relevant operating and maintenance strategies.

Define the system boundary, including (1) Interfaces and interactions with physical environment [e.g., climatic conditions, mechanical conditions, altitude], (2) Interfaces and interactions with other technological systems [e.g., utilities, freight railroads, earthquake early warning systems],

(3) Interfaces and interactions with humans, (4) Interfaces and interactions with other railway

2 The SDLC defines Systems Engineering deliverables using the SDLC framework, only. For non-SE deliverables, refer to other Contract documents.

Systems Development Life Cycle Requirements Page 11 duty holders [e.g., shared corridor, shared track, blended service], and (5) Any other HSR system relevant system boundary.

Identify and establish the operational requirements influencing the characteristics of the system, including (1) Constraints imposed by existing infrastructure [e.g., legacy systems], (2) System operating conditions and constraints, (3) System maintenance conditions, (4) Logistic support considerations, (5) Review of past experience data for similar systems, (6) Influence on operational and maintenance personnel, passengers and public, or how they are prevented, (7) The description of operating procedures, identification of personnel permitted to carry out these actions and indication of the skills, qualifications, and time-resources required, if part of the system operating conditions and constraints, and (8) The different modes of operation [i.e., normal, abnormal/degraded, maintenance mode], states, and transitions and their interactions, if they could have an impact on the systems functionality and safety.

Operations-, maintenance-, and life cycle strategies, conditions, considerations, and constraints shall be prepared and approved by qualified and experienced operations and maintenance personnel, as supported by their resumes, and approved by the Authority.

3.3.3 Stakeholder Requirements

Transform the applicable TCRs from the contract requirements baseline (CBL), the system definition, and any other stakeholder needs, goals, and/or objectives (e.g., from third-party agreements) into well-formed stakeholder requirements following the requirements management process (section 4.1).

Document the stakeholder requirements in a stakeholder requirements specification (StRS) following the provisions of: (1) IEEE 29148 8.2.2 StRS Example Outline, and (2) IEEE 29148 9.3 Stakeholder requirements specification (StRS) document.

3.3.4 System Certification and Acceptance Plan

Prepare, submit, and implement a system certification and acceptance plan (SCAP) describing the Contractors planned strategy to demonstrating that the HSR system is safe, secure, and ready to operate. Follow the system certification management process (section 4.5).

3.3.5 System Operations Testing Plan

Prepare, submit, and implement a system operations testing plan (SOTP) describing the Contractors planned strategy to perform pre-revenue operation testing (section 3.11).

Identify the complete set of stakeholder requirements and applicable TCRs in the CBL subject to testing during the pre-revenue operation phase. For each requirement, define the planned Verification and Validation (V&V) methods as defined in IEEE 29148.

Follow the SDLC phase applicable requirements of the testing and commissioning management process (section 4.4) and V&V management process (section 4.3).

Systems Development Life Cycle Requirements Page 12

3.4 System Requirements Phase

The key purpose of the System Requirements (SR) phase is to (1) Perform requirements analysis transforming the TCRs from the CBL and the stakeholder requirements from the SDOC phase into well-formed system requirements, thereby (2) Establishing the system requirements baseline [SBL], and (3) Develop a system start-up testing plan.

The key deliverables of this phase are: (1) Well-formed system requirements, (2) System requirements baseline, and (3) System start-up testing plan.

Follow the general provisions of EN 50126 and IEEE 29148, addressing specifically: (1) EN 50126:

7.5 Phase 4: Specification of system requirements, and (2) IEEE 29148 6.3 Requirements analysis process.

The structure and content of the SR phase deliverables shall be sufficiently detailed to serve as key input into the (1) System architecture phase [section 3.5] and (2) System start-up testing phase [section 3.10].

The review milestone for this phase is the systems requirements review (SRR). This phase is completed when all SR phase deliverables defined in the Contract have been accepted by the Authority.

3.4.1 System Requirements

Transform the applicable TCRs from the CBL and the stakeholder requirements into well-formed SR following the RM process (section 4.1)

Document the system requirements in a system requirements specification (SyRS) following the provisions of (1) IEEE 29148 8.3.2 SyRS example outline, and (2) IEEE 29148 9.4 System requirements specification [SyRS] document.

3.4.2 System Requirements Baseline

Establish the system requirements baseline (SBL) by capturing the system requirements in the RM tool, and baselining it using RM tool baseline functions.

3.4.3 System Start-Up Testing Plan

Prepare, submit, and implement a system start-up testing plan (SUTP) describing the Contractors planned strategy to system start-up testing (section 3.10).

Identify the complete set of system requirements subject to testing during the system start-up testing phase. For each system requirement, define the planned Verification and Validation (V&V) methods as defined in IEEE 29148.

process (section 4.4) and verification and validation management process (section 4.3).

Systems Development Life Cycle Requirements Page 13

3.5 System Architecture Phase

The key purpose of the system architecture (SA) phase is to (1) Develop a high-level (preliminary) system design from a set of sub-systems and system elements, that (2) Meet the system requirements, (3) Work together as a system, and (4) Develop a system integration testing plan.

The key deliverables of this phase are (1) System and interface breakdown structures, (2) the Allocated requirements baseline, (3) System architecture, and (4) a System integration testing plan.

A well-defined system architecture is critically important for successful system integration, as presented in Figure 5. The structure and content of the SA phase deliverables shall be sufficiently detailed to serve as key input into the (1) Final design phase [section 3.6] and (2) System integration testing phase [section 3.9].

Figure 5: System Architecture vs. System Integration Concept

Follow the general provisions of EN 50126, IEEE 29148, and IEEE 15288, addressing specifically

(1) EN 50126: 7.6 Phase 5: Architecture and apportionment of system requirements, (2) IEEE 29148

6.4.1 Requirements in architectural design, and (3) IEEE 15288 6.4.4 Architecture definition process.

The review milestone for this phase is the preliminary design review (PDR). This phase is completed when all SA phase deliverables defined in the Contract have been accepted by the Authority.

3.5.1 System and Interface Breakdown Structures

Successively decompose the HSR system into its sub-systems and system elements, down to the lowest-level configuration items as presented in Figure 6, resulting in a hierarchical system breakdown structure (SBS) and a hierarchical interface breakdown structure (IBS).

Systems Development Life Cycle Requirements Page 14

Figure 6: System Decomposition

Capture the identified interfaces between the HSR system (boundary) and external (third-party) system, and between the HSR sub-systems and system elements in the IBS, also referred to as the interface register. Manage the interfaces following the interface and integration management process (section 4.2).

Map the OBS (section 2.5) to the SBS and IBS. Each SBS and IBS element shall have only one accountable owner (i.e., JV partners, engineering departments, subcontractors).

Map the TWBS (section 2.2) to the SBS and IBS. It shall be explicitly clear which deliverables will be provided for each SBS and IBS elements.

3.5.2 Allocated Requirements

Analyze and allocate the system requirements to the SBS and/or IBS elements. If necessary, partition system requirements so that they can be wholly allocated to individual SBS and/or IBS elements.

Transform the allocated system requirements into well-formed HSR sub-system and system element requirements (allocated requirements) following the requirements management process (Section 4.1).

Document the allocated requirements in allocated sub-system requirements specifications (SSRS) following the outline and content of SyRSs (section 3.4.1).

3.5.3 Allocated Requirements Baseline

Establish the allocated requirement baseline (ABL) by capturing the allocated requirements in the RM tool, and baselining it using RM tool baseline functions.

Systems Development Life Cycle Requirements Page 15

3.5.4 System Architecture

Generate a system architecture from one or more alternatives that meets the SBL requirements.

Provide the system architecture in a consistent set of views from SBS and IBS elements, including

(1) Behavioral [e.g., operational, functional, logical, sequence, activity], (2) Information [e.g., data, entity relationships], (3) Network [e.g., pattern such as centralized, distributed], and (4) structural [i.e., physical] views.

Demonstrate that the system behavior will satisfy the functional system requirements by providing at last one behavioral view or diagram (i.e., activity, sequence, or state machine diagram) for each system function.

The Contractor is encouraged to employ a model based systems engineering (MBSE) approach, utilizing industry standard architecture frameworks.

3.5.5 System Integration Testing Plan

Prepare, submit, and implement a system integration testing plan (SITP) describing the Contractors planned strategy to perform system integration testing (section 3.9). The SITP shall describe how the HSR sub-systems and system elements will be integrated to form the complete HSR system as presented in the system architecture, prior to system-wide start-up testing.

Identify the complete set of allocated requirements subject to testing during the system integration testing phase, specifically focusing on interfaces between HSR sub-systems and system elements. For each allocated requirement, define the planned Verification and Validation (V&V) methods as defined in IEEE 29148.

Follow the SDLC phase applicable requirements of the testing and commissioning management process (section 4.4) and verification and validation management process (section 4.3).

3.6 Final Design Phase

The key purpose of the final design (FD) phase is to (1) Provide the detailed (final) design of the HSR sub-systems, system elements, and associated interfaces, (2) Demonstrate that HSR sub-systems, system elements conform to the allocated requirements, (3) Create the final design baseline, and (4) Develop a sub-system testing plan.

The key deliverables of this phase are (1) Final design, (2) Final design demonstration, (3) Final design baseline, and (4) Sub-system testing plan.

Follow the general provisions of EN 50126 and U.S. DOT FRA MP 54, addressing specifically (1) EN 50126: 7.7 Phase 6: Design (and implementation), (2) FRA MP 54: Design Completions, and

(3) Design Tests.

The review milestone for this phase is the final design review (FDR). Due to phased development, several FDRs are likely to occur (see Figure 4). This phase is completed when all final design-phase deliverables defined in the Contract have been accepted by the Authority.

Systems Development Life Cycle Requirements Page 16

3.6.1 Final Design

Advance the design of each HSR sub-system, system element, and the associated interfaces the to the final design level as defined in the Contract, in conformance with the allocated requirements.

Provide the final design submittals as defined in the Contract.

3.6.2 Final Design Demonstration

Demonstrate the HSR sub-system, system elements, and the associated interfaces conform to the allocated requirements.

Demonstration shall include the V&V methods identified for the allocated requirements following the verification and validation management process (section 4.3).

3.6.3 Final Design Baseline

Establish the final design baseline after successful completion of the final design but prior to implementation (manufacturing and construction phase), following the configuration management process.

3.6.4 Sub-System Testing Plan

Prepare, submit, and implement a sub-system testing plan (SSTP) describing the Contractors planned strategy for testing during manufacturing and construction (section 3.7), and field and site testing (section 3.8). The SSTP shall describe how the HSR sub-systems and system elements will be independently tested prior to integrating them into the HSR system.

Identify the complete set of applicable requirements allocated to each HSR sub-system, system elements, and the associated interfaces subject to testing. Include any additional requirements that may have been developed during final design (e.g., product and/or construction specifications). For each requirement, define the planned Verification and Validation (V&V) methods as defined in IEEE 29148.

Follow the SDLC phase applicable requirements of the testing and commissioning management process (section 4.4) and verification and validation management process (section 4.3).

3.7 Manufacturing and Construction Phase

The key purpose of the manufacturing and construction (M&C) phase is to realize (implement) the HSR sub-systems, system elements, and associated interfaces. The implementation may vary, depending on the type of implementation (i.e., hardware production, software development, field construction).

The key deliverables of this phase are (1) Manufactured and/or constructed HSR sub-systems, system elements, and associated interfaces, (2) First-article inspections and/or demonstration and other SDLC-phase related tests, and (3) Test plans including schedules, test procedures and test results.

Systems Development Life Cycle Requirements Page 17

Follow the general provisions of EN 50126 and U.S. DOT FRA MP 54, addressing specifically (1) EN 50126: 7.7 Phase 6: Design and Implementation, (2) EN 50126: 7.8 Phase 7: Manufacture, (3) FRA MP 54: Inspections, (4) FRA MP 54: Test plans, procedures and reports, (5) FRA MP 54:

[Design /] component tests, and (6) FRA MP 54: Production / factory acceptance tests.

The review milestone for this phase is the first article demonstration review (FAR). Due to phased development, several FARs are likely to occur. The FAR milestone applies to both manufacturing (e.g., ATC system components) and construction (e.g., sample installation of trackwork). Mass production and/or construction shall only occur once the corresponding FAR milestone has been passed. This phase is completed when all manufacturing and construction phase deliverables defined in the Contract have been accepted by the Authority.

Perform the following types of tests:

• First article inspection/demonstration: Demonstrate that first manufactured and/or constructed article meets the applicable requirements.

• Production run testing: Demonstrate that manufactured and/or constructed articles continue to meet the applicable requirements during mass production.

• Factory acceptance testing: Demonstrate that manufactured HSR sub-systems, system elements, and associated interfaces meet the applicable requirements prior to shipment to site.

• Construction inspection and testing: Demonstrate that constructed HSR sub-systems, system elements, and associated interfaces in the field meet the applicable requirements.

Applicable requirements are defined as the requirements identified as subject to testing in the Sub-System Testing Plan (section 3.6.4).

Follow the SDLC phase applicable requirements of the testing and commissioning management process (section 4.4) and verification and validation management process (section 4.3).

3.8 Field / Site Testing Phase

The key purpose of the field / site testing (F/ST) phase is to transport to the site and install and field-test HSR sub-systems, system elements, and associated interfaces, ensuring that they are properly installed, connected, and are (still) in operable condition.

The key deliverables of this phase are (1) Installed and field-tested HSR sub-systems, system elements, and associated interfaces, and (2) Test plans, including schedules, test procedures and test results.

Follow the general provisions of U.S. DOT FRA MP 54, addressing specifically (1) Field tests, and

(2) Individual system testing.

The review milestone for this phase is the field testing review (FTR). Due to phased development, several FTRs are likely to occur. This phase is completed when all field / site testing phase deliverables defined in the Contract have been accepted by the Authority.

Systems Development Life Cycle Requirements Page 18

Perform the following types of test:

• Site installation testing: Demonstrate that HSR sub-systems, system elements, and associated interfaces meet the applicable installation requirements (e.g., placement, mounting, connections).

• Site performance testing: Demonstrate that HSR sub-systems, system elements, and associated interfaces meet the applicable performance requirements (e.g., functional, non-functional requirements).

Applicable requirements are defined as the requirements identified as subject to testing in the SSTP (section 3.6.4).

Follow the SDLC-phase applicable requirements of the testing and commissioning management process (section 4.4) and V&V management process (section 4.3).

3.9 System Integration Testing Phase

The key purpose of the system integration testing (SIT) phase is to gradually assemble the individual HSR sub-systems and system elements into the complete (fully integrated) HSR system as presented in the system architecture. The focus will be primarily on static testing of the “nearest neighbor” interfaces between the HSR system boundary and external system, and between the HSR sub-systems and system elements, prior to initiating system-wide end-to-end start-up testing (section 3.10).

The key deliverables of this phase are (1) Tested HSR system interfaces, (2) Integrated HSR system, and (3) Test plans, including schedules, test procedures and test results.

Follow the general provisions of EN 50126, IEEE 15288, and U.S. DOT FRA MP 54, addressing specifically (1) EN 50126: 7.9 Phase 8: Integration [7.9.1.a], (2) IEEE 15288: 6.4.8 Integration process, and (3) FRA MP 54: Systems integration testing.

The review milestone for this phase is the system integration testing review (SIR). Due to phased development, several SIRs may occur (i.e., by TS1 segments). This phase is completed when all system integration testing phase deliverables defined in the Contract have been accepted by the Authority

Perform the following types of test, demonstrating conformance to the applicable requirements and interfaces:

• Intra HSR sub-system, intra-site testing: Applies the interfaces between system elements of the same HSR sub-system installed at the same site that have not previously been tested during factory acceptance and/or field / site testing (e.g., at an ATC interlocking site, within operations control center [OCC], maintenance facilities)

• Intra HSR sub-system, inter-site testing: Applies to interfaces between the same HSR sub-system installed at different sites (e.g., between an ATC interlocking site and the OCC)

• Inter-HSR sub-system, intra-site testing: Applies to interfaces between the different HSR sub-systems installed at the same site (e.g., between the wayside power cubicle and the ATC system at the same ATC interlocking site)

Systems Development Life Cycle Requirements Page 19

• Inter-HSR sub-system, inter-site testing: Applies to interfaces between the different HSR sub-systems installed at different sites (e.g., between traction power equipment and traction power facilities and Supervisory Control and Data Acquisition [SCADA] equipment at the OCC)

Applicable requirements are defined as the requirements identified as subject to testing in the system integration testing plan (section 3.5.5).

Follow the SDLC phase applicable requirements of the interface and integration management process (section 4.2), the testing and commissioning management process (section 4.4), and the verification and validation management process (section 4.3).

3.10 System Start-Up Testing Phase

The key purpose of the system start-up testing (SUT) phase is to perform (technical) system-wide end-to-end dynamic testing of the fully integrated HSR system (including civil works, trainsets, etc.), prior to initiating pre-revenue operations testing (section 3.11). Examples of system SUT include energizing the HSR system, dynamic load and clearance testing, dynamic of ATC wayside detection, low-, high- and overspeed testing, etc.

The key deliverables of this phase are (1): Fully tested HSR system, (2) Test plans including schedules, test procedures and test results.

Follow the general provisions of EN 50126, IEEE 15288, and U.S. DOT FRA MP 54, addressing specifically: (1) EN 50126: 7.9 Phase 8: Integration [7.9.1.b], (2) IEEE 15288: 6.4.9 Verification process, and (3) FRA MP 54: Startup tests.

The review milestone for this phase is the system start-up testing review (STR). Due to phased development, several STRs may occur (i.e., by TS1 segment). This phase is completed when all system start-up testing phase deliverables defined in the Contract have been accepted by the Authority.

Perform the following types of test, demonstrating conformance to the applicable requirements:

• Normal HSR system mode: HSR system fully functional

• Abnormal/degraded HSR system modes: Applies to the HSR system operating in unplanned degraded modes due to system failures (e.g., single and/or double electrical contingency modes, failover and failback operation, etc.)

• Maintenance HSR system modes: Applies to the HSR system operating in planned degraded modes due to system maintenance (e.g., taking tracks out of service)

Applicable requirements are defined as the requirements identified as subject to testing in the system startup testing plan (section 3.4.3).

process (section 4.4) and verification and validation management process (section 4.3).

Systems Development Life Cycle Requirements Page 20

3.11 Pre-Revenue Operation Phase

The key purpose of the pre-revenue operation (PRO) phase is to implement and test the HSR system operations and maintenance including rules (rule book) and standard operating procedures (SOP), the safety, security and emergency response program, the asset management and maintenance regime (e.g., availability of spare parts), public education and safety awareness, prior to system certification and acceptance (section 3.12), and entering revenue service (section 3.13). Pre-revenue operation relies on a fully tested HSR system (section 3.10). The Reliability, Availability, and Maintenance (RAM) testing period is expected to begin during pre-revenue operation. Refer to other Contract documents for details.

The key deliverables of this phase are (1): Fully tested HSR system operations and procedures, and (2) Test plans, including schedules, test procedures, and test results.

Follow the general provisions of EN 50126, IEEE 15288, and U.S. DOT FRA MP 54, addressing specifically (1) EN 50126: 7.10 Phase 9: System validation, (2) IEEE 15288: 6.4.11 Validation process, and (3) FRA MP 54: Pre-revenue operation.

The review milestone for this phase is the pre-revenue operation review (PRO). Due to phased development, several PROs may occur (i.e., by TS1 segment). This phase is completed when all system pre-revenue operation phase deliverables defined in the Contract have been accepted by the Authority.

Perform pre-revenue operation testing, demonstrating conformance to the applicable requirements as identified in the system operations testing plan (section 3.3.5).

Follow the SDLC-phase applicable requirements of the testing and commissioning management process (section 4.4) and V&V management process (section 4.3).

3.12 System Certification and Acceptance Phase

The key purpose of the system certification and acceptance (SEA) phase to certify to the authority having jurisdiction that the HSR system is safe, secure, and ready for revenue service (section 3.13).

The key deliverables of this phase are (1) Design case, (2) Test case, (3) Operating case, (4) Safety case, and (5) System certification.

Follow the general provisions of EN 50126 and U.S. DOT FRA MP 54, addressing specifically (1) EN 50126 7.11 Phase 10: System acceptance, and (2) FRA MP 54: Readiness for revenue operations.

The review milestone for this phase is the system certification and acceptance review (SCR). Due to phased development, several SCRs may occur (i.e., by TS1 segment). This phase is completed when all system certification and acceptance phase deliverables defined in the Contract have been accepted by the Authority.

Follow SDLC phase applicable requirements of the system certification management process (section 4.5), supported by the verification and validation management process (section 4.3).

Systems Development Life Cycle Requirements Page 21

3.13 Operations and Maintenance Phase

The key purpose of the operations and maintenance (O&M) phase is to operate, maintain, and support the HSR system such that compliance with contractual requirements is maintained. This includes continuously monitoring and evaluating the HSR system performance and deriving measures to address shortcomings and to achieve improvements.

Follow the general provisions of EN 50126, EN 50129, and IEEE 15288, addressing specifically (1) EN 50126: 7.12 Phase 11: Operation, maintenance and performance monitoring, (2) EN 50129: 8 System safety acceptance and subsequent phases, (3) IEEE 15288: 6.4.12 Operation process, and

(4) IEEE 15288: 6.4.13 Maintenance process.

In case of HSR system modifications and/or retrofits, follow this SDLC for the affected HSR sub-systems, system elements and associated interfaces.

3.14 Handback

Follow the requirements described in the Contract.

4 Cross-Cutting Systems Engineering Methods

Cross-Cutting Systems Engineering Methods are processes that apply to more than one SDLC phase. Apply the Cross-Cutting Systems Engineering Methods to the specific SDLC phases.

4.1 Requirements Management

The key purpose of the requirements management (RM) process is to plan, execute, monitor, and control a structured requirements management, requirements analysis, and requirements engineering process that establishes the HSR system technical contract, stakeholder, system, and allocated requirements, including product and/or construction specifications, which serve as the basis for design, design reviews, implementation, integration, inspecting, testing, commissioning, and finally the system certification. For a definition of technical contract requirements (TCR) refer to the General Provisions Schedule 8.

Apply requirements management to any other requirements if required by Contract (e.g., for environmental or sustainability requirements).

Requirements management includes eliciting, documenting, capturing, baselining, analyzing, allocating, engineering, managing, determining V&V methods, tracing, and communicating requirements. For related verification, validation, and certification of requirements refer to the verification and validation (section 4.3) and system certification (section 4.5) processes.

The key deliverables of this process are (1) Requirements management plan, (2) Requirements management tool, (3) Well-formed requirements [requirements engineering], (4) Requirements specifications, (5) Requirements verification traceability matrix [RVTM], and (6) Certifiable items list [CIL].

Systems Development Life Cycle Requirements Page 22

Manage all requirements in the RM tool, including:

• Contract requirements, including technical contract requirements

• Stakeholder requirements

• System requirements

• Allocated requirements, including interface requirements

• Final design including resulting requirements (e.g., product and/or construction specifications)

Follow the general provisions of IEEE 29148: Systems and Software Engineering – Life Cycle Processes – Requirements Engineering. Coordinate and requirements management process with the requirements management requirements described elsewhere in the Contract.

4.1.1 Requirements Management Plan

Follow the applicable requirements management requirements described elsewhere in the Contract.

Additionally, the requirements management plan shall specifically include a detailed implementation of the RM process in the RM tool (user manual) throughout the SDLC phases, including (1) Graphical presentation of modules and their traceability relationships, (2) Use of formal and link modules, (3) Folder structures, (4) Module names, (5) Attributes & types, (6) DXL code used, (7) Views, and (8) Traceability.

4.1.2 Requirements Management Tool

The RM tool shall be the latest IBM Rational Dynamic Object Oriented Requirements System (DOORS) 9.X version. Do not use IBM Rational DOORS Next Generation.

Provide the Authority with five (5) IBM Rational DOORS Floating User Licenses (Part Number D09LELL at time of writing the Contract) along with software subscription and support by IBM for the duration of the Contract. Other types of licenses such as Authorized User Licenses or Web Access Editor Licenses are not acceptable. This requirement is independent from the web access requirement stated below. The disposition of the licenses will be determined at the end of the Contract.

Additionally, enable web access to the RM tool and provide the Authority with full real-time readability access to the Contractor’s RM tool database. One (1) Authority representative shall be able to access the RM tool at any given time using web access.

Manage the requirements throughout the SDLC phase in the RM tool. Place requirements under configuration control, establish and manage requirements baselines following the CM process.

Demonstrate conformance to the requirements using RVTMs and CILs.