[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
br
Paul
More information about the trustable-software
mailing list