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

[Steve Tockey]

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”.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20210428/cb0dec55/attachment-0001.html>