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

[Michael Jackson]

Steve: 

Yes: the notion of ‘requirement’ is vague enough to embrace anything 
a stakeholder wants—for example, constraints on the native language, 
composition, remuneration, and location of the development team—
and this certainly includes constraints on every aspect of the technical 
implementation at every level. 

We propose only to identify the ‘properties, effects and consequences 
of the system behaviour in the problem world' as a matter of crucial  
interest deserving distinct attention and technique separately from the 
technical implementation and deployment of the software. 

Regards, 

— Michael

   
> On 2 May 2017, at 22:10, Steve Tockey <Steve.Tockey at construx.com> wrote:
> 
> 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.