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

Andrew Banks andrew at andrewbanks.com
Wed Jan 3 15:47:53 GMT 2018


Terminology varies, but an example can be found:
	http://www.informit.com/articles/article.aspx?p=1152528&seqNum=4

Thus:
	Correct = If a requirement contains facts, these facts should be
true:
	Concise = Requirements should not contain unnecessary verbiage or
information.

>> 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
t.requirements?

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.


A


-----Original Message-----
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
be trustable"

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)

br
Paul

[1]
https://gitlab.com/trustable/trustable-mustard/blob/master/markdown/basics.m
d




More information about the trustable-software mailing list