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

[Michael Jackson]

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