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

Nick Tudor njt at tudorassoc.com
Wed Apr 28 20:13:55 CEST 2021


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>
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>
> Date: Tuesday, April 27, 2021 at 1:38 PM
> To: Steve Tockey <Steve.Tockey at construx.com>, Peter Bernard Ladkin <
> ladkin at causalis.com>
> Cc: "systemsafety at lists.techfak.uni-bielefeld.de" <
> 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
> 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

*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/20210428/53f66265/attachment-0001.html>


More information about the systemsafety mailing list