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

[Steve Tockey]

Are people implying (or even asserting) that the stakeholders cannot place
constraints (I.e., ³requirements²) on technology? I might be a bank, so
the desired properties, effects, and consequences should be limited to the
banking domain. But, if I already have a site license and support
infrastructure for Oracle shouldn¹t I be able to require all new systems
to also use Oracle as the database? Requirements can be just as much
constraints on automation technology as they are on the ³business² to be
automated.


Cheers,

‹ steve



-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of Michael Jackson <maj at jacksonma.myzen.co.uk>
Reply-To: "jacksonma at acm.org" <jacksonma at acm.org>
Date: Tuesday, May 2, 2017 at 6:27 AM
To: Matthew Squair <mattsquair at gmail.com>
Cc: "systemsafety at lists.techfak.uni-bielefeld.de"
<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