[SystemSafety] A Common Programming Language for the Department of Defense

[Les Chambers]

Michael

‘what vs how’  can be a wicked problem. I once spent months working with a client in telecommunications developing a software requirements specification for a system that parsed service orders and automatically configured telephone exchanges. The client representatives were all telephone switch engineers. You don't get any nerdier than that - these were deep and technical dudes. They insisted that service order syntax be expressed in Backus–Naur form. You could say that's a how 'not'  a 'what'. But of course they got what they wanted - call it a design constraint. 

RE: “Don’t break this actuator” 
I've also had many arguments with people who insist that a requirements specification should state only what the system must do, not what it must NOT do. My argument is that "don't" is an essential component of many safety requirements. For example, traffic lights are explicitly required to not display green aspects in north-south as well as east-west directions at the same time. This gives rise to the development of a conflict monitor which detects which aspects are active and shuts the system down if two greens are showing. This would not exist without a "don't" in the requirements specification.

BTW your thoughts on 'machines' inspired some of the words in this production:
http://www.chambers.com.au/video_public/specifying_software_requirements.php
Thank you.

Les

-----Original Message-----
From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Michael Jackson
Sent: Tuesday, May 2, 2017 11:28 PM
To: Matthew Squair
Cc: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] A Common Programming Language for the Department of Defense

Yes. 

The purpose of executing the software by computing equipment is to affect behaviour in the physical world—the effects spreading outwards from the computers’ I/O ports: the further from the ports the more unpredictable and the more attenuated these effects are. Requirements are desired properties, effects and consequences of this behaviour. They can be formalised or informal, located almost anywhere: from “Don’t break this actuator” to “Don’t surprise the pilot” to “Make the product attractive to EU governments.” 

Yes, ‘what vs how’ hierarchies are involved, but developing a structure of behaviours will be bottom-up as well as top-down, won’t it? 

— Michael Jackson  
 

      
> On 2 May 2017, at 12:20, Matthew Squair <mattsquair at gmail.com> wrote:
> 
> At the highest level yes. 
> 
> A requirement states a need which is in the operational (capability) domain. 'But' between that and a requirement that a solution can be crafted for is a 'what vs how' hierarchy. That progressive refinement is of course where many problems arise.
> 
> Matthew Squair
> 
> MIEAust, CPEng
> Mob: +61 488770655
> Email; Mattsquair at gmail.com 
> Web: http://criticaluncertainties.com
> 
> On 2 May 2017, at 8:24 pm, paul_e.bennett at topmail.co.uk wrote:
> 
>> On 02/05/2017 at 10:58 AM, "Michael Jackson" <maj at jacksonma.myzen.co.uk> wrote:
>>> 
>>> Paul: 
>>> 
>>> Are “Requirements” a description of the stakeholders’ needs, 
>>> purposes and 
>>> desires that the product should fulfil? Or the specification of a 
>>> product that 
>>> will fulfil them? Or are these two just the same thing?
>>> 
>> 
>> Requirements are the statement of stake-holder needs. Within such a 
>> document I would expect a clearly identified end goal and sufficient
>> constraint and expectational expression that can be identified and
>> tested.
>> 
>> It does no good for a requirements specification to say that the resultant
>> product should use a fast processor. It should, instead, state what the
>> expected maximum response times should be to user input, the latency
>> in managing interrupts and other measurable speed criteria.
>> 
>> Out of the stakeholder Requirements, the Technical Specifications are
>> produced which do focus on the more tangible assets to be provided.
>> These also should meet the six C's criteria.
>> 
>> Regards
>> 
>> Paul E. Bennett IEng MIET
>> Systems Engineer
>> 
>> -- 
>> ********************************************************************
>> Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
>> Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
>> Mob: +44 (0)7811-639972
>> Tel: +44 (0)1392-426688
>> Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
>> ********************************************************************
>> 
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety at TechFak.Uni-Bielefeld.DE

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE