IRC logs for #trustable for Monday, 2019-01-21

*** Guest94649 has quit IRC03:21
*** toscalix has joined #trustable08:46
persiaLooking at , it occurs to me that there may be value to a development group in asserting that delivered requirements must be all of consistent, complete, and non-conjunctive.  Given that the first two are mutually exclusive, and the third precludes any complex behaviour, this means that delivered requirements may always be found wanting, allowing the eternal support for "the specification wasn't correct".10:45
reiterativeAgreed. So if we value requirements (or constraints and intents) then we need to be clear about what this means. For example, a "consistent vs complete" conflict might be resolved by distinguishing the context within which contradictory requirements apply.10:50
*** traveltissues has joined #trustable10:57
persiaMy preference would be to assert no value to completeness, and focus on consistency.  This supports the model where one develops a small number of requirements, and then adds more over time, as one understands the goal more clearly.11:29
persiaGiven the popularity of iterative development models, and the advantages in ensuring team overlap through parallel workstreams (e.g. development may begin before analysis is complete), I suspect this will work.11:31
persiaFor organisations that want a more traditional approach, it becomes just a matter of shifting the time of each activity.  Also, given that it isn't particularly easy to prove "complete", it may be very difficult to know when something is actually done.11:32
persiaMind you, this does end up shifting blame, because if the development work has results that are inconsistent with a given consistent snapshot of requirements, questions are to be asked of those engaged in development, without much range for disagreement, but this is probably healthy for the overall initiative even if it might be awkward for a given development group.11:33
reiterativeI agree. Do we want to include any statement regarding completeness?11:34
persiaI think that we can safely imply that through demonstration in sample patterns for policies.11:35
persiaIf we say "requirements are necessarily incomplete", that is a subject for argument.  If nothing about the completeness of requirements is written, and there exists a pattern for tight-loop iterative development starting with the minimal viable product, followed by refinement, I suspect that folk will internalise the flexibility.11:36
persiaWe might also show a pattern where requirements are not expected to change after release to the development teams, but the only real cases of that I've seen involve delivery into series production, with an expectation that the requirements *will* change, that a new series will be produced based on the new requirements, and that older equipment will be upgraded to match the new requirements (so iterative, just over longer timescales).11:38
persiaMore concretely, if all patterns include an expectation of continuous future refinement of the understanding of safety and security hazards, causing new constraints to be understood, this firmly implies the incompleteness of the requirements in a way that is very easy to explain.11:40
paulsherwoodpersia: we already dismantled the 'consistend, complete, non-conjunctive' dogma11:50
persiapaulsherwood: My read based on that email and is that it only debunked the "non-conjunctive" bit, or at least, that was the only one removed.  In following up that history, I had the insight that there may be a rationale for the content of the wikipedia page.11:54
persiaThe current version of has both consistent and complete, which is provably impossible, but I think we can proceed forward based purely on consistency.11:55
paulsherwoodpatches welcome11:55
persiaThis will require another update, although I expect that will go along with ceasing to use the term "requirements".11:55
persiaYep.  Hoping to have something in shape to be a patch in the near future :)11:55
reiterativeWorking on a patch.11:56
paulsherwoodbut also... i'm still holding to the model that 'requirements' are optional at best, since so much software doesn't have them11:56
persiaRight, this is part of why we need to not use that word.11:56
paulsherwood(exception being for system properties e.g. safety requirements, security requirements)11:56
persiaAny system that any entity wishes to use for any purpose necessarily has some constraints.  Some of those constraints are formally documented, some implied.  We are only capable of validating against the formally documented constraints.11:57
paulsherwoodi'm happy for it to stay out of our lexicon, but when discussing with others, we'll always need to explain the gap/reasoning11:57
persiaSo, I assert that in order for any entity to make any claim that a system does something, there must be a set of constraints to evaluate whether it does.11:57
persiaIt is entirely unimportant whether the developers of a software component of that system were aware of those constraints at the time of development.11:58
paulsherwoodpersia: nicely stated11:58
persiaYes.  Once we have a tighter formal grammar, we need to demonstrate how that grammar applies to a variety of actual development methodologies.11:58
* paulsherwood wonders how reiterative feels about converting from persian into simple english11:59
* reiterative is happy to serve12:00
paulsherwoods/about converting/about the feasibility of converting/ :)12:01
reiterativeI think that conversion / translation is always possible, but there's a risk of losing some precision in translation12:03
persiaThat's probably useful, in that many of my statements are considered overprecise by others.12:04
reiterative(My redraft of the nomenclature is already feeling over-technical)12:04
reiterative(I'll share it ASAP, so that we can decide how to proceed)12:06
persiaI suspect there needs to be at least a pair of documents.  One providing a formal vocabulary and grammar as the underpinning for a provable minimal set of requirements for evidence collection, and one providing a human-consumable explanation of the sort of processes and tools appropriate.12:06
* reiterative wholeheartedly agrees12:07
*** toscalix has quit IRC17:44
*** traveltissues has quit IRC18:43
*** traveltissues has joined #trustable18:43
*** traveltissues has quit IRC20:09
*** traveltissues has joined #trustable20:11
*** traveltissues has quit IRC20:11

Generated by 2.15.3 by Marius Gedminas - find it at!