Section 5 Performance Requirements

5.1.1  This Section is applicable to all Software Development Statuses.

5.1.2 The verified Relevant Hazard Requirements and the requirements for the satisfaction of the relevant Naval Administration are to be provided to the Producer of Software by the Engineering System level stakeholder.

5.1.3 It is to be determined whether and how the failure or unspecified behaviour (see Note 1) of the software could credibly result in:

1. an event that escalates to a Relevant Hazard;
2. impairment of the mitigation of a Relevant Hazard; or
3. impairment of recovery from a Relevant Hazard.

5.1.4 The conclusions of Ch 1, 5.1 General requirements for the production of software 5.1.3 are to be communicated to those responsible at the Engineering System level and, where they deem it appropriate, up to higher System levels as necessary to allow a design to be developed where the software does not result in any of Ch 1, 5.1 General requirements for the production of software 5.1.3.

5.1.5 When an alternative design removing the software as a cause of Ch 1, 5.1 General requirements for the production of software 5.1.3 is not provided at the Engineering System or System level, additional Relevant Hazard Requirements are to be specified for the software to achieve the necessary mitigation. The specification of the new Relevant Hazard Requirements is to satisfy the requirements of Ch 1, 2.1 Context 2.1.3 and Ch 1, 2.1 Context 2.1.4.

5.2.1 When there is one or more Relevant Hazard Requirement, the Production of Software is to demonstrate that the Relevant Hazard Requirements have been met.

5.2.2 An Argument, supported by a body of evidence, that provides a compelling, comprehensible and valid demonstration that the functional objective identified in Ch 1, 4 Functional Objective has been met, is to be made and documented.

5.2.3 Configuration management satisfying the requirements of ISO 10007:2003: Quality management systems – Guidelines for configuration management, or an alternative standard acceptable to LR, is to be used during the Production of Software.

5.2.4 Software is to be produced using a quality management system that satisfies the requirements of 9001:2008: Quality management requirements using the guidance of ISO 90003:2014: Software engineering – Guidelines for the application of ISO 9001:2008 to computer software. When the software implements safety requirements, the part of the safety management system applicable to the Production of Software is to be within the scope of the quality management system.

5.2.5 The Producer of Software is to identify and justify the Software Production Standard to be used.The Justification is to be documented and is to demonstrate that the chosen Software Production Standard is appropriate for the degree of reliance placed on the software by the Relevant Hazard Requirements.

5.2.6 The Producer of Software is to submit the Justification for the chosen Software Production Standard to LR for consideration.

5.2.7 A plan for the Production of Software is to be formulated, documented, and used to direct the Production of Software. If the plan is incorporated into another document, the strategy and the structure of the plan, with a route map to other documentation, are to be documented separately. The level of detail in the plan is expected to increase as the project progresses through the lifecycle phases of the Production of Software. The plan is to be complete with respect to each lifecycle phase before the phase is initiated.

5.2.8 The plan for the Production of Software is to be submitted to LR for consideration in sufficient time to allow for resolution of any comments prior to implementation of the activities specified by the plan.

5.2.9 The plan for the Production of Software is to:

1. include all activities for the Production of Software, including production of the Argument and supporting evidence referred to in Ch 1, 5.2 Production of software 5.2.2;
2. include the processes, methods, techniques and tools required by the agreed Software Production Standard and applicable to the degree of reliance placed on the software by the Relevant Hazard Requirements;
3. take account of factors which influence the introduction of errors, such as the size, complexity, and novelty of the software;
4. justify deviation from the requirements of the Software Production Standard; and
5. justify and record the Software Development Status as New, Modified, or Existing. For a status of Modified, the Justification is to demonstrate that a status of New is not appropriate using an assessment that is to include, but is not limited to:
   1. the proportion of modification of the original product
   2. whether the modification is a new or modified Relevant Hazard Requirement
   3. the number of interactions within the software effected by the modification
   4. the complexity of the function being modified or added
   5. whether the modification represents a fundamental change to the design, such as a change to the scheduling regime, or key data structures
   6. the knowledge within the team making the change modification and the status of the design documentation

5.2.10 The Software Development Status of the software is to be agreed by LR.

5.2.11 When there are changes to Relevant Hazard Requirements which affect the plan for the Production of Software, the plan is to be revised.

5.2.12 When the implementation of the Software Production Standard is changed, the plan for the Production of Software and its Justification are to be updated and submitted to LR for consideration in sufficient time to allow for resolution of any comments prior to implementation of the activities specified by the plan. The Justification is to demonstrate that deviations do not undermine compliance with the Relevant Hazard Requirements or Ch 1, 5.1 General requirements for the production of software 5.1.3.

5.2.13 The Production of Software is to be performed in accordance with the Software Production Standard and the plan for the Production of Software.

5.3.1 This Section of the Rules is additionally applicable to software with a Software Development Status of Modified.

5.3.2 The modification of Software Products is to be undertaken in accordance with defined modification processes which are part of the supplier’s quality management system.

5.3.3 The impact of the modification on previously developed Software Products is to be assessed and used to tailor the Producer of Software’s management systems for the specific software modification. Management systems include its quality management system, safety management system and engineering management system. Ch 1, 5.3 Modified software 5.3.3 is to be repeated during the development to ensure that, as the development progress, the actual impacted elements of the products are identified and the suitability of the management system is maintained.

5.4.1 This Section of the Rules is applicable to software with a Software Development Status of Existing.

5.4.2 All requirements applicable to New Software are applicable to Existing Software, except those directly related to the production of code; that is software design, coding and testing of the code at a level lower than a complete Software Product.

5.4.3 The requirements of Ch 1, 5.1 General requirements for the production of software 5.1.5 only apply where any additional Relevant Hazard Requirements can be implemented through configuration of the Existing Software or by providing New Software to work in co-operation with the Existing Software.