[trustable-software] Exploring the "Hypothesis for software to be trustable"
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 )
> - 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