[trustable-software] Exploring the "Hypothesis for software to be trustable"
paul.sherwood at codethink.co.uk
Wed Jan 3 08:29:57 GMT 2018
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
- 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 )
> - 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  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