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

Daniel Silverstone daniel.silverstone at codethink.co.uk
Wed Jan 3 11:35:58 GMT 2018

On Wed, Jan 03, 2018 at 07:40:12 -0000, Andrew Banks wrote:
> 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
> 	# 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

'Concise', to me, is covered by the 'atomic' entry in the list.  As for
'Correct' that's difficult to say.  What you mean by that I am unsure.

If, for example, you mean 'The requirements must correctly describe what must
be there to meet the business needs' then that requires that we think of
requirements in a heirarchy at which point we can introduce some statement
about that heirarchy and 'Correct' actually devolves to a sub-case of
'Complete' combined with a sub-case of 'Coherent'.

What is your understanding of the 'Correct' entry, and do you accept my
interpretation of 'Atomic' for 'Concise' ?


Daniel Silverstone                           http://www.codethink.co.uk/
Solutions Architect               GPG 4096/R Key Id: 3CCE BABE 206C 3B69

More information about the trustable-software mailing list