Minutes 18 Sep 2025

Host: Paul Albertella

Participants: Pete Brink, Igor Stoppa

Agenda

• How can we manage the ‘audience effect' when framing objectives, procedures, claims, etc as part of a process?
• How can we ensure that an audience understands or considers these topics in the intended context?

Notes

Pete: Difference between computer science / software development and software engineering is not well understood in the tech industries where it is (theoretically) practised / relevant

• This is reflected in the safety standards’ insistence on describing processes

Igor: If you understand the context within which safety applies, and have some guiding principles like SMART

• Something clear and simple that can be followed in any context

Pete: There are descriptions of these processes in other standards and resources such as SWEBOK

• Each of the topics involved in software engineering are potentially very deep
• Igor: But can we apply some higher level guiding principles

One of the founding principles is: establish the context within which your subject is intended to be used

Two aspects to this:

• The context within which your engineering is undertaken
• The contexts within which the results may be used where safety is relevant

Pete: Extend SMART to SMARTTT - add traceability and testability

Pete: Gab’s efforts at describing how maintainers can document requirements for the kernel is an example of trying to apply this, and the challenges;

• Need both effective engineers and domain experts to create good software

Igor: ‘Architects’ who only work in powerpoint are less useful that those who can express solutions in code

Paul: Since there are many ways to do engineering, it is more useful to describe the objectives of engineering processes, rather than how work is organised or the required formalisms of documentation, etc

Pete: You are describing software quality - which is very rarely applied in practice

• Covers process and product quality

Paul: Including some of these verification measures as CI jobs that act as a ’gateway’ to acceptance can change the way that teams are organised, and allow individuals of different levels of competence to contribute

• The sequence of engineering process activities does make sense, though
• Doing safety analysis early in the process makes sense, for example
• Also, capturing the understanding of what we have done (e.g. in design docs) can make it easier for others to engage with it in the future

Igor: Some interesting LLMs are available that can interact with your codebase and start to produce some of this material for you

• Which might be OK, provided that you have someone competent to evaluate the validity of that material

How can we express this in a way that can be more widely understood?

• Pete: This is a competency framework!