Section 5 Definitions

5.1 Definitions

Table 1.5.1 Definitions

Argument	An Argument explains why something can be deduced as true from supporting evidence. See ISO 15026-2 2011: Systems and software engineering - Systems software assurance, Part 2: Assurance case.
Engineering System	See Vol 2, Pt 1, Ch 1, 3 Engineering system designation 3.1 in the Rules and Regulations for the Classification of Naval Ships, January 2017 [reproduced in this document as Section 7 Extract from the Naval Ship Rules].
Justification	A Justification gives the reason that something has been used or applied. See ISO 15026-2: 2011.
Producer of Software	The organisation that is responsible for delivering the software as part of an Engineering System. This may be the same organisation that delivers the Engineering System. In respect of commercial off-the-shelf (COTS) software and equipment, the Producer of Software might be the original developer or supplier, an organisation reselling or acting as an agent for the original developer or supplier, or an integrator of multiple Software Products.
Production of Software	The process of interpreting requirements and realising those requirements as a Software Product by using suitable software lifecycle steps and applying the requirements of quality, safety and other management systems. Production of Software includes all lifecycle phases from requirements (including Relevant Hazard Requirements) to support for system integration and system testing. Where iterative or cyclical lifecycles are used, the Production of Software includes all iterations or cycles. The Production of Software includes tailored lifecycle phases where Existing or Modified Software is used.
Relevant Hazards	The hazards related to the necessity for the Engineering Systems as described for the different categories in Vol 2, Pt 1, Ch 1, 3 Engineering system designation 3.1 in the Rules and Regulations for the Classification of Naval Ships, January 2017 [reproduced in this document as Ch 1,7 Extract from the Naval Ship Rules].
Relevant Hazard Cause	The cause of a Relevant Hazard. It should be noted that while Relevant Hazards are associated with the system level, Relevant Hazard Causes or contributions to Relevant Hazard Causes can come from any level, including the software level.
Relevant Hazard Requirements	Software requirements which cover how the software mitigates a Relevant Hazard Cause including, but not limited to: (a) specific functional behaviour to mitigate Relevant Hazard Causes, fault indications, accuracy and response times; (b) what it must not do; and (c) the degree of reliance placed on the achievement of the Relevant Hazard Requirements. A Relevant Hazard Requirement can be separated into components corresponding to sub-systems, each of which is itself called a Relevant Hazard Requirement.
Software	Intellectual creation comprising the programs, procedures, data, rules and any associated documentation relating to the operation of a data processing system or complex hardware, where complex hardware includes but is not limited to custom micro-coded components including Application Specific Integrated Circuits (ASIC), Programmable Logic Devices (PLD), Field Programmable Gate Arrays (FPGA), or similar electronic technologies.
Software Development Status	A category assigned to software that is to be one of the following: (a) New - Software that is totally or significantly a new development; (b) Existing - Software that is to be used without modification. Existing Software includes, but is not limited to: operating system, third party communications protocols, graphics libraries, and reused supplier-developed code; (c) Modified - Software based on an Existing Software Product but changed for the system being assessed against these Rules. Modifications can range from setting/configuration changes to modifications that require the software to be recompiled. Note: Configuration of Existing Software does not alter its function, only specified characteristics such as changing set points. Configuration of Modified Software might cause a different algorithm to be executed.
Software Product	Software considered by its supplier to be an individual entity. For example, the software for an Engineering System developed as a core, generic product with specific applications using the core as a service would be a single deliverable. However, for the purposes of these Rules, the core and applications are separate products. Software will still be considered as part of a whole Engineering System to assure that the combined elements meet all Relevant Hazard Requirements. Therefore, when a software system is separable into Software Products (as described above) the software system is to be considered a Software Product in its own right.
Software Production Standard	An international or national standard to be applied to the Production of Software.