The new EN 50716 rules for project organisation

Introduction

The previous blog posts New standard EN 50716:2023 “Requirements for Software Development” Part 1 and New EN 50716:2023 “Requirements for Software Development” Part 2 provided an overview of the changes from [SN EN 50128:2011] to [SN EN 50716:2023]. In this article, we would like to take a closer look at the topics of “separation of roles” and “competencies”. We will highlight the different requirements in terms of staff independence for the various levels of integrity.

 

Separation of roles

The standard requires that individual roles be independent from one another for two main reasons:

Firstly, the distribution of roles should ensure that staff are able to view work results in an unbiased way and from different perspectives. This is intended to prevent incorrect solutions from being developed due to similar misunderstandings.

Second, this independence of roles is intended to prevent the wrong decisions from being made about product validation and acceptance as a result of pressure from above to achieve project or commercial objectives.
A basic organisational structure for managing different roles and their responsibilities must be defined. These requirements are in line with the specifications set out in SN EN ISO 9001:2015.

All persons involved in development or maintenance according to SN EN 50716:2023 must be named. The allocation of roles must be appropriately documented and traceable in case of changes to the organisation.

 

New elements in SN EN 50716:2023

Chapter 5 of SN EN 50716:2023, which describes the organisation of software development, has been refined and defined more clearly compared to its predecessor SN EN 50128:2011. Unrealistic limitations, such as the ban on making organisational changes during the course of a project, were also removed.

Compared to the previous version, SN EN 50716:2023 includes the following main changes:

  1. Basic Integrity (SIL0 in SN EN 50128:2011): An assessor is no longer required.
  2. Appointment of assessor: The assessor can now be designated by the supplier or customer and may be part of any stakeholder organisation (customer, supplier or third-party organisation). However, he/she must remain independent of the project team and belong to another organisational unit.
  3. Role of the integrator: This role has been scrapped. The responsibilities of the integrator have been transferred to the tester and other roles. The tester is now responsible for producing the integration test specifications (SW integration and SW/HW integration) and the corresponding test reports. Annex B.3 requires the implementer to lead the integration process, mainly for the technical implementation. The planning and management of the integration process is usually carried out by the project manager.
  4. Role change between verifier and validator: Switching between these roles is no longer prohibited, but is also not recommended. In order to ensure a consistently high quality of verification and validation, the roles of verifier and validator should be fixed at the project level and remain unchanged throughout the course of the project. However, if a change becomes necessary, it must be documented and justified.
Blogbeitrag RollenEN50716 GR en

Figure 1: Differences in roles (own diagram based on Figure 2 from SN EN 50128:2011 and SN EN 50716:2023)

Differences in the independence of roles for Basic Integrity, SIL2 and SIL4

For all integrity levels, roles may in principle be shared by several people in the project and, where not expressly prohibited, one person may also exercise several roles.

A requirements manager can always also be a designer or an implementer.
Some dual roles are expressly forbidden, for example, a validator may not also be an implementer at the same time. It is therefore important to carefully read Chapters 5.1.2.10 to 5.1.2.12 when defining the roles. Exceptions to the general requirements are described here.

Generally speaking, there are three levels of requirements when it comes to role separation:

  • Basic Integrity
  • SIL1 and SIL2
  • SIL3 and SIL4

 

Let us look at the differences between the three levels.

Basic Integrity

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

 

SIL1 and SIL2

An independent assessor must be appointed.
In principle, a verifier or validator should not also act as a tester. Should a verifier or validator nevertheless performing testing at SIL1 to SIL4, these tests and documents must be reviewed by a second validator or verifier.
For SIL1 to SIL4, a requirements manager, designer or implementer should not act as a tester for the same software component. However, they may test other software components created by other developers.

 

SIL3 and SIL4

In addition to the limitations for SIL1 and SIL2, the following requirements apply to SIL3 and SIL4:

It is expressly prohibited for the validator to be the project manager’s subordinate. This is allowed for lower integrity levels.

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

 

Staff competencies

SN EN 50716:2023 describes in detail the skills that software development personnel must have. As with SN EN 50128:2011, the specific requirements for the different roles are listed in Annex B of the standard.

A supplier’s organisation is required to implement procedures that enable staff competencies to be maintained and managed. Evidence of the required competencies must be carefully documented. It is still necessary to ensure competencies even after confirmation by the assessor. Methods such as those required and described in standards SN EN ISO 9001:2015 and ISO IEC IEEE 90003:2018 are recommended in this case.

It makes sense to actively maintain a skills matrix for employees that also covers the competencies specifically required by SN EN 50716:2023. The training and development provided as part of employee development, as well as the professional competencies acquired, must be included in this skills matrix.

In addition to actual technical competencies in software development and the use of development tools, methodological skills and knowledge of the area in which the developed products are to be used are also required.
These skills do not necessarily have to be acquired in traditional courses with corresponding training certificates. They can also be learned in joint workshops or other forms of training and information sharing. On-the-job training and mentoring are also helpful ways of developing staff in the necessary areas.

CSA Engineering AG is actively involved in helping its employees reach new heights. In addition to traditional external training courses, regular internal meet-ups and technology afternoons are held where employees can share their expertise in a specific area. By doing this, CSA Engineering AG is able to make a significant contribution to promoting and maintaining the skills of its employees.

 

Summary

Despite the revision of the standard SN EN 50716:2023, the requirements regarding the separation of roles and the competencies of the staff involved are extensive and must be carefully considered when assembling a development team.

With higher demands on staff independence, there is a greater need for staff, which is why it is important to consider in detail at the start of a project which integrity levels are to be applied in software development and how the project team is to be put together accordingly. It also makes sense to define deputies for each of the major roles in order to be prepared for any changes or failures at a critical phase of the project.

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

We have requirements engineers, implementers, testers, verifiers and validators and would be happy to support you in your project. Contact us for an informal discussion about the options available and how we can support you.

Contact us