Visualised Systems Engineering on Railway Projects

Overview Requirements in Systems Engineering are statements that define characteristics of a system, product, or service to satisfy contractual obligations, laws & regulations, technical specifications, and environmental conditions. Contractors or developers must verify and validate these requirements throughout the project life cycle contractually and technically. Why requirements management process? In the Testing and Commissioning (T&C) phase, non-compliance items can occur due to: ▪ Engineers misunderstanding the project requirements. ▪ Errors in the technical aspects themselves. ▪ Interface and/or interference errors. ▪ Neglecting certain requirements for various reasons. According to requirements management specialists, 40~50% of non-compliance stems from engineers misunderstanding the requirements. However, engineers can mitigate their misunderstanding and neglecting requirements by following a structured requirements management process. While performing the requirements management process, the scope of the project becomes clear, and issues like interface and safety are easily derived. Requirements management is related to scope management and interface management, including other requirements such as safety, human factors integration, EMC (Electro-Magnetic Compatibility), etc., Framework of requirements management The framework for requirements management primarily consists of requirements database, requirement items, and control methodologies, as illustrated in Figure 20. Figure 20 - Framework of requirements management To manage the traceability of requirements, establishing a database is essential due to the typically large volume of requirement-related information. All requirement-related data should be stored in a dedicated database. However, this does not imply that every requirement manager must use specific software; for smaller volumes of information, Microsoft Excel may serve as a more effective management tool than specialised databases. All requirements will progress through the stages of identification, development, allocation, reporting, design, and actualisation. Throughout these stages, the requirements will be controlled, verified, and validated with the output of the requirements management activities also stored in the database. Types of requirements Requirements can be classified into the following types: ▪ Contractual requirements: These include requests for proposal (RFP), contractor proposal, and contractual documents. ▪ Mandatory requirements: These are imposed if specified in the contractual documents, including laws and the client company’s internal regulations. ▪ Technical requirements: These are applicable if included in the contractual documents, encompassing technical specifications, domestic standards, and international standards. ▪ Environmental requirements: These are also contingent upon the contractual documents, covering natural environmental conditions and social conditions. ▪ Outcomes from the previous phase: These may include preliminary design. Figure 21 shows the contents of both technical and non-technical requirements. Since non-technical requirements, such as the project schedule, can sometimes affect the quality of technical ones, they should also be managed. Figure 21 – Technical & non-technical requirementss Requirements management process and structure Below is the requirements process: ▪ Gather and review all contractual documents. ▪ Define and clarify all requirements. ▪ Decompose each requirement (in a downwards direction as shown in Figure 22) until a sub-requirement can be designed and actualised by sub-contractors and suppliers. Thus, a sub-requirement at the lowest level should be verifiable. ▪ After design and manufacture, each deliverable should be verified and/or validated with evidence (in an upwards direction as shown in Figure 22). At the upper level, requirements are finally checked with verification/validation evidence. Figure 22 - Requirements decomposing and integration integrating From the standpoint of the system integrator at the top level in the organisational structure of the railway projects, it is not reasonable to manage all requirements from the top-level requirements governed by client to the lowest level requirements controlled by sub-contractors and suppliers. This approach is inefficient. In the case of the system integrator hired by the client, their scope of work regarding requirement management will cover only the requirements allocated to the contractors hired by the client, not those allocated to the subcontractors hired by the contractors. As shown in Figure 22, the system integrator can manage the A and A1 levels. However, if A1-1 is transferred from a contractor to its subcontractor, the responsibility for control shifts to the contractor. The depth of the system integrator’s responsibility will be determined based on contractual relationship.