[trustable-software] Exploring the "Hypothesis for software to be trustable"

Paul Sherwood paul.sherwood at codethink.co.uk
Wed Jan 3 08:29:57 GMT 2018

Hi Andrew,

Thanks for this! A couple of questions below...

On 2018-01-03 07:40, Andrew Banks wrote:
> Morning Paul (and the group)... and HNY to you all
> Far be it for me to challenge the combined wisdom of Wikipedia, for
> measures for requirements specification I usually consider (as a
> minimum) the six Cs.
> 	Clear, Concise, Correct, Coherent, Complete and Confirmable.
> Your list covers four of these... so I would suggest the additional
> inclusion of Concise and Correct

- do you mean that 'the set of t.requirements' must be complete, rather 
than each individual one? i'm starting to think that the rest of the 
points should be 'each t.requirement MUST be...'

- what about the situation where we can't possibly get to a complete set 
of t.requirements?

- is there some subtlety in 'Correct' that I'm missing?  i think some 
elements of 'correct' are addressed by 'verifiable'. but depending on 
what you mean, it may be that we should state 'current and correct'?

> 	# t.requirements (derived from wikipedia [2])
> 	   - t.requirements MUST be unitary
> 	   - t.requirements MUST be atomic (non-conjugated)
> 	   - t.requirements MUST be complete				C5 - Complete
> 	   - t.requirements MUST be consistent				C4 - Coherent
> 	   - t.requirements MUST be traceable
> 	   - t.requirements MUST be current
> 	   - t.requirements MUST be unambiguous			C1 - Clear?
> 	   - t.requirements MUST be verifiable				C6 - Confirmable
> 	   - t.requirements MAY be graded by priority/importance

I've pushed the original text to [1] for now, and will make amendments 
there... (although I'm already convinced that mustard is too hard for 
mortals to use in practice)



More information about the trustable-software mailing list