[trustable-software] Evidence Relationships in SDLC

[Paul Sherwood]

On 2018-03-29 08:34, Paul Sherwood wrote:
<snip>
>> And such a requirement should be Unitary and Cohesive. That is to say
>> that it should address one and only one behavior.
> 
> I'm afraid I no longer agree with that, hence there is no such
> assertion in the basics.md file you mentioned above.
> 
> Dan Firth on this list provided a logic argument which appeared to
> nail it last year:
> 
> https://lists.trustable.io/pipermail/trustable-software/2018-January/000284.html

So in my faulty memory, I thought we had actually revised the 
t.requirements definition in light of Dan's logic argument, but I'm 
clearly mistaken.

And now I'm feeling like an idiot because on re-reading the argument, I 
don't think the example holds up.

Help, please! :-)

>>   * Atomic - only one statement, e.g. it should be blue, not it should
>>     be blue and made of plastic
>> 
> 
> This one in particular makes no sense. It's impossible to express any
> implication this way. I'll resurrect the example from the SAT solver we
> investigated early last year to demonstrate.
> 
> 1. A box contains electrical wires that can be powered 'on' or 'off'

This is not a requirement; it's a description of a situation.

> 2. The workman can either be either in the state 'at risk' or 'safe'

Ditto.

> 3. The box door can either be open or closed

Ditto.

> 4. When the box is open and the power on, the workman is 'at risk'

Ditto.

> 5. When the box is closed, the workman is 'safe'

Ditto.

> 6. When the door is opened, the power is turned off

Ditto, unless we change s/is turned off/must be/

In that case this is a requirement, and I think it's unitary.

> 7. When the door is closed, the power is turned on

Ditto.

> 8. The workman should never be at risk

This is a requirement, and I think it's unitary/cohesive as written.

It may lead to several other implied requirements (e.g. we need to power 
off the door when it's opened) for a given implementation.

> 1,2,3 are all of the form A \/ B
> 4,5,6,7 are all of the form A => B, equivalently B \/ ¬A
> 
> There's no way to express goodany requirement with a non-trivial amount 
> of
> semantic content without allowing conjunctive/disjunctive requirements.

This may still be correct, but it's not proved by the given example IMO. 
As always, I may be wrong.

br
Paul