[SystemSafety] [External] Re: Post Office Horizon System

[Steve Tockey]

Nick,
Thanks for the link. A question about your case studies, do you have an example of the kind of information that Kapture is working with? I couldn’t find any detail on that and I’m interested in seeing more to compare it with what I’m doing.

You can find an example of what I’m doing here:

https://www.dropbox.com/sh/gd5qdtf45bqzecd/AAA2r8uzYYSgql6cvqZtnjAPa?dl=0


The file “AppendixD Order Fulfillment SM.pdf” is an example of a Semantic model. Other examples are available.

The file “AppendixL Semantic Modeling SM.pdf” is a semi-formal definition of how Semantic models are to be interpreted.

The remaining *.java files are an example of corresponding Java code that implements the Order Fulfillment Semantic Model. There is an obvious and straightforward correlation between the content in the Semantic model and the corresponding code.


Regards,

— steve



From: Nick Tudor <njt at tudorassoc.com<mailto:njt at tudorassoc.com>>
Date: Wednesday, April 28, 2021 at 11:13 AM
To: Steve Tockey <Steve.Tockey at construx.com<mailto:Steve.Tockey at construx.com>>
Cc: "Driscoll, Kevin" <kevin.driscoll at honeywell.com<mailto:kevin.driscoll at honeywell.com>>, Peter Bernard Ladkin <ladkin at causalis.com<mailto:ladkin at causalis.com>>, "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] [External] Re: Post Office Horizon System

Re the list Kevin came up with, we have been trying to help. Kapture is now being used on a number of software projects from autonomous systems, flight control systems and now on medical devices. See:
https://www.drisq.com/product-kapture.

On Wed, 28 Apr 2021 at 18:10, Steve Tockey <steve.tockey at construx.com<mailto:steve.tockey at construx.com>> wrote:

Kevin Driscoll wrote:

“It depends on the definition of “requirements”.”

Yes. For what it’s worth, I am using the IEEE definition:

(1) A condition or capability needed by a user to solve a problem or achieve an objective
(2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
(3) A documented representation or capability as in (1) or (2)

One thing important to note about the IEEE definition is that it says nothing about the language in which the requirements are expressed. One should be free to express requirements in a wide variety of different languages.


“There are no end to stories of software that met its requirements, which was not fit for purpose.”

True, but that’s not the problem I’m trying to address right now.


“One major problem is completeness (in breadth and depth).”

Yes, and this is not only a very different problem than lack of fitness for purpose, this IS the problem I want to focus on because it IS a largely solve-able problem.


“I would lay down a bet that a substantial number of post mortems (particularly in security and safety-critical CPSs) would have the developers saying: “If we’d only known…”.  Generally, these statements can’t be completed by “… we would have written the software differently” without also including “we would have written the requirements differently”.”

I would certainly not bet against you. But in how many of those cases were the requirements written in a natural language like English: statements of the form “The software (or system) shall …”. The mere fact of depending on natural languages to specify requirements is a dangerous trap that people still fall into. Natural languages are inherently ambiguous and non-concise(?). So I would add that the vast majority of those “If we’d only known…” statements could also easily be replaced with “If we’d only asked…”. The language in which the requirements are expressed is not helping to expose critical ambiguities and subtle but important gaps in detail.

What’s the alternative? Using precise modeling languages. Jeannette Wing wrote a paper titled “A Specifiers Introduction to Formal Methods” (IEEE Computer, September, 1990). The key idea is to have a comfortable surface syntax like (cue Les?—smile) state-transtion diagrams but have the semantics of those diagrams anchored in formal languages like Z, VDM, Larch, etc. The requirements specifier (and the requirements reviewer) can work with the requirements in easy-to-read pictures yet the pictures are directly translate-able into underlying formal languages for analysis. This essentially solves the ambiguity problem. A lot of the incompleteness problem can be solved because things that are difficult to state precisely, concisely in a natural language are easy to say—and are obvious when they are missing—in the right diagraming notations. We can also combine the precise, concise modeling notations with model development and verification guidelines. For example, “Did you consider all events in all states in that state-transition diagram?” as just one of several such powerful guidelines.

 To explain all of this in an email would be quite a chore. On the other hand, if anyone is interested in following up on this, there’s a series of videos on YouTube which provide a lot more detail:

*) An overview of what I call "Semantic Models”, which are really just precise, concise representations of the functional requirements:

https://youtu.be/LqMhha360XM


*) A Deeper Dive into Semantic Models that shows how model content, and modeling guidelines, helps expose (and often totally avoid) a majority of everyday defects in (functional) requirements:

https://youtu.be/FjGh8YMo_tU


*) How  these Semantic models can lead directly to code. After all, unless the model was useful for developing the code then time spent modeling is wasted:

https://youtu.be/8uJg-qfeqVM


*) How the process of turning Semantic models into code can also be largely automated:

https://youtu.be/86XJXE815zs


All of this is not a “someone might want to try it, it might help” situation. I’ve been doing model-based requirements on systems dating back to 1985. I can’t for the life of me see why people continue to fumble with natural language requirements (or, gag, think that user stories on an Agile project have much of anything at all to do with requirements). But I also can’t seem to be able to convince people that there really is a better way.




From: "Driscoll, Kevin" <kevin.driscoll at honeywell.com<mailto:kevin.driscoll at honeywell.com>>
Date: Tuesday, April 27, 2021 at 1:38 PM
To: Steve Tockey <Steve.Tockey at construx.com<mailto:Steve.Tockey at construx.com>>, Peter Bernard Ladkin <ladkin at causalis.com<mailto:ladkin at causalis.com>>
Cc: "systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>" <systemsafety at lists.techfak.uni-bielefeld.de<mailto:systemsafety at lists.techfak.uni-bielefeld.de>>
Subject: RE: [External] Re: [SystemSafety] Post Office Horizon System

PBL >> “Requirements specification is an unsolved engineering problem, and is likely to remain so for quite a while (if not for ever).”
ST > I would disagree, personally. Software requirements can be specified precisely, concisely, etc.
It depends on the definition of “requirements”.  There are no end to stories of software that met its requirements, which was not fit for purpose.
One major problem is completeness (in breadth and depth).
I would lay down a bet that a substantial number of post mortems (particularly in security and safety-critical CPSs) would have the developers saying: “If we’d only known…”.  Generally, these statements can’t be completed by “… we would have written the software differently” without also including “we would have written the requirements differently”.


_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
--
Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com<http://www.tudorassoc.com>
[http://www.tudorassoc.com/wpimages/wpb4e71a5c_0f.jpg]

77 Barnards Green Road
Malvern
Worcestershire
WR14 3LR
Company No. 07642673
VAT No:116495996

www.aeronautique-associates.com<http://www.aeronautique-associates.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20210430/aa230420/attachment-0001.html>