[trustable-software] Exploring the "Hypothesis for software to be trustable"
andrew at andrewbanks.com
Wed Jan 3 15:47:53 GMT 2018
Terminology varies, but an example can be found:
Correct = If a requirement contains facts, these facts should be
Concise = Requirements should not contain unnecessary verbiage or
>> 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...'
Good question... IMHO:
... the SET of requirements must be Complete and Coherent/Consistent
... each INVIDIDUAL requirement must meet the other criteria
>> what about the situation where we can't possibly get to a complete set of
This is a problem in all cases - not just trustable... I suggest that where
there are known omissions, then we must specify the appropriate assumptions.
From: Paul Sherwood [mailto:paul.sherwood at codethink.co.uk]
Sent: 03 January 2018 08:30
To: Trustable software engineering discussion
Cc: Andrew Banks
Subject: Re: [trustable-software] Exploring the "Hypothesis for software to
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
- 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 -
> - t.requirements MUST be consistent C4 -
> - t.requirements MUST be traceable
> - t.requirements MUST be current
> - t.requirements MUST be unambiguous C1 - Clear?
> - t.requirements MUST be verifiable C6 -
> - 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