The new regulations of EN 50716 for project organization

Introduction

In the previous blog posts "Die neue EN 50716:2023 die-neue-en-50716-2023-«anforderungen-für-software-entwicklung»-teil-2"Requirements for Software Development" Part 1 and Die neue EN 50716:2023 "Requirements for Software Development" Part 2, an overview of the changes from [SN EN 50128:2011] to [SN EN 50716:2023] was provided. In this article, we would like to delve into the topics of "Independence of Roles" and "Competence." We will explore the different requirements for personnel independence across various integrity levels.

Independence of Roles

The standard demands the independence of roles for two main reasons:

Firstly, the allocation of roles should ensure that individuals can view the work results unbiasedly and from different perspectives. This aims to prevent false solutions arising from the same misunderstandings.

Secondly, independence should prevent incorrect decisions regarding validation and acceptance of the product, which may arise from pressure to achieve overarching project goals or economic objectives.

A fundamental organizational structure for managing various roles and their responsibilities must be defined. These requirements align with the guidelines of [SN EN ISO 9001:2015].

All individuals involved in development or maintenance according to [SN EN 50716:2023] must be explicitly named. The allocation of roles must be documented accordingly and traceable when organizational changes occur.

Updates in SN EN 50716:2023

Chapter 5 of [SN EN 50716:2023], which describes the organization of software development, has been refined and specified compared to the predecessor standard [SN EN 50128:2011]. Unrealistic restrictions, such as the prohibition of organizational changes during the project duration, have been removed.

The [SN EN 50716:2023] exhibits the following major changes compared to the predecessor standard:

1. Basic Integrity (SIL0 in [SN EN 50128:2011]): An assessor is no longer required.

2. Designation of the Assessor: The assessor can now be designated by either the supplier or the customer and may be part of any stakeholder organization (customer, supplier, or third-party organization). However, they must still be independent from the project team and belong to a different organizational unit.

3. Role of the Integrator: This role has been abolished. The responsibilities of the integrator have been transferred to the tester and other roles. The tester is now responsible for the creation of the integration test specifications (SW integration and SW/HW integration) as well as the associated test reports. Appendix B.3 stipulates that the implementer leads the integration process, primarily concerning the technical implementation. The planning and control of the integration process are typically managed by the project manager.

4. Role Switching Between Verifier and Validator: Switching between these roles is no longer prohibited, but it is not recommended either. To maintain consistently high quality in verification and validation, the roles of the verifier and the validator should be firmly assigned at the project level and remain unchanged throughout the project course. If a switch becomes necessary, it must be documented and justified.

Figure 1: Differences Between Roles (own representation, based on Figure 2 from [SN EN 50128:2011] and [SN EN 50716:2023]

Differences in Role Independence for Basic Integrity, SIL2, and SIL4

For all integrity levels, roles can generally be shared by multiple individuals in the project, and, where not explicitly prohibited, one person can also perform multiple roles.

A requirements manager may always also be a designer or implementer.

Some dual roles are explicitly prohibited, such as the validator not being simultaneously an implementer. Therefore, it is important to read Chapter 5.1.2.10 to 5.1.2.12 carefully when defining roles. These sections describe the exceptions to the general requirements.

Three levels of independence requirements are generally distinguished:

• Basic Integrity

• SIL1 & SIL2

• SIL3 & SIL4

Below are the differences between the three levels.

Basic Integrity

An assessor is not required.
Tester, verifier, and validator can be the same person.

SIL1 & SIL2

An independent assessor must be designated.

Generally, a verifier or validator should not also function as a tester. If a verifier or validator in SIL1 to SIL4 nonetheless undertakes test activities, these activities and documents must be reviewed by a second validator or verifier.

In SIL1 to SIL4, a requirements manager, designer, or implementer should not act as a tester for the same software component. However, they can test other software components that have been developed by other developers.

SIL3 & SIL4

In addition to the restrictions for SIL1 and SIL2, the following requirements arise for SIL3 and SIL4:

It is expressly forbidden for the validator to be subordinate to the project manager. For lower integrity levels, this is allowed.

The verifier and the validator should generally not be the same person. If a validator takes on verification tasks in SIL3 and SIL4, their work must be reviewed by another validator according to the same independence requirements.

Competencies of Personnel

The [SN EN 50716:2023] extensively describes the competencies that personnel in software development must possess. As already in the [SN EN 50128:2011], the specific requirements for the various roles are listed in the standard's Appendix B.

The supplier's organization must implement procedures that enable the maintenance and management of the personnel's competencies. Evidence of the required competencies must be carefully documented. Ensuring competencies remains necessary even after confirmation by the assessor. Procedures are recommended, such as those required and described in the standards [SN EN ISO 9001:2015] and [ISO IEC IEEE 90003:2018].

It is advisable to actively maintain a competency matrix for employees, which also covers the competencies specifically required in [SN EN 50716:2023]. The training and further education conducted as part of the employee development, as well as the professionally acquired competencies, must be included in this competency matrix.

In addition to the actual technical competencies in software development and the application of development tools, methodological competencies and knowledge of the area where the developed products are to be applied are also required.

Acquiring these competencies does not necessarily have to take place through classic training courses with corresponding training certificates. Knowledge can also be acquired through joint workshops or other forms of exchange. "On-the-job training" and "mentoring" are also helpful forms for further developing personnel accordingly.
CSA Engineering AG actively engages in the development of its employees. Besides classic external training, internal meetups and technology afternoons are regularly held, during which employees can share their specific know-how. Thus, CSA Engineering AG significantly contributes to promoting and maintaining the competencies of its personnel.

Summary

The requirements for role independence and the competencies of the involved personnel are extensive despite the revision of the standard [SN EN 50716:2023] and must be carefully considered when assembling the development team.

With more requirements for personnel independence comes a higher demand for personnel, which is why it is essential to thoroughly consider at the project start which integrity levels are applicable in software development and how the project team should accordingly be assembled. It also makes sense to define deputies for the respective roles to be prepared for any changes or absences in a critical phase of the project.

Do you have questions about software development according to [SN EN 50716:2023], implementing the standard requirements in your development project, or do you need support for specific roles?

We have requirements engineers, implementers, testers, verifiers, and validators and are happy to assist you in your endeavor. Contact us for a non-binding discussion on the possibilities and the most suitable support.