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

Paul Sherwood paul.sherwood at codethink.co.uk
Wed Jan 24 08:57:33 GMT 2018

Hi Andrew,
On 2018-01-23 13:56, Andrew Banks wrote:
> Generally, I like this - but I'd like to debate your Specifications 
> bit:

Thanks :)

> 	Specifications state:
> 	- the problem
> 	- the expected solution
> 	- how to verify the solution
> How about:
> 	Specifications state the WHAT:
> 	- the requirements that need to be met
> 	Plans will state the HOW:
> 	- the HOW it will be DONE		= the design plan
> 	- the HOW it will be VERIFIED		= the verification (test?) plan
> 	- the HOW it will be MANAGED		= the management plan
> 	- etc

On reflection I think 'Specifications' may be muddying the waters.

I'm reluctant to introduce the concept of 'plans', not least because 
many of the plans i see in practice are works of fiction :)

Imagine this document in the context of parachuting into jrandom 
project; what is the minimum set of things that would give us confidence 
that the project is well-run?

Maybe it's better to drop 'specifications' and avoid 'plans', by 
referring to changes/issues (which we've already mentioned earlier in 
the document):

Issues/changes include evidence of:
- what the problem is
- what the expected solution is
- how the solution is (or will be) implemented
- how the solution is (or will be) verified
- how the solution is (or will be) landed/integrated


More information about the trustable-software mailing list