| *** Guest94649 has quit IRC | 03:21 | |
| *** toscalix has joined #trustable | 08:46 | |
| persia | Looking at https://en.wikipedia.org/wiki/Requirement , 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 |
|---|---|---|
| reiterative | Agreed. 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 #trustable | 10:57 | |
| persia | My 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 |
| persia | Given 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 |
| persia | For 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 |
| persia | Mind 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 |
| reiterative | I agree. Do we want to include any statement regarding completeness? | 11:34 |
| persia | I think that we can safely imply that through demonstration in sample patterns for policies. | 11:35 |
| persia | If 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 |
| persia | We 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 |
| persia | More 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 |
| paulsherwood | persia: we already dismantled the 'consistend, complete, non-conjunctive' dogma | 11:50 |
| paulsherwood | https://lists.trustable.io/pipermail/trustable-software/2018-January/000284.html | 11:51 |
| persia | paulsherwood: My read based on that email and https://gitlab.com/trustable/documents/commit/f8457d7290c68a255ef0e936e6822d7b2d4bd777 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 |
| paulsherwood | hmmm.... | 11:55 |
| persia | The current version of definitions.md has both consistent and complete, which is provably impossible, but I think we can proceed forward based purely on consistency. | 11:55 |
| paulsherwood | patches welcome | 11:55 |
| paulsherwood | :) | 11:55 |
| persia | This will require another update, although I expect that will go along with ceasing to use the term "requirements". | 11:55 |
| persia | Yep. Hoping to have something in shape to be a patch in the near future :) | 11:55 |
| reiterative | Working on a patch. | 11:56 |
| paulsherwood | but also... i'm still holding to the model that 'requirements' are optional at best, since so much software doesn't have them | 11:56 |
| persia | Right, 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 |
| persia | Any 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 |
| paulsherwood | i'm happy for it to stay out of our lexicon, but when discussing with others, we'll always need to explain the gap/reasoning | 11:57 |
| persia | So, 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 |
| persia | It 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 |
| paulsherwood | persia: nicely stated | 11:58 |
| persia | Yes. 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 english | 11:59 | |
| * reiterative is happy to serve | 12:00 | |
| paulsherwood | s/about converting/about the feasibility of converting/ :) | 12:01 |
| persia | heh | 12:01 |
| reiterative | I think that conversion / translation is always possible, but there's a risk of losing some precision in translation | 12:03 |
| persia | That'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 |
| persia | I 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 agrees | 12:07 | |
| *** toscalix has quit IRC | 17:44 | |
| *** traveltissues has quit IRC | 18:43 | |
| *** traveltissues has joined #trustable | 18:43 | |
| *** traveltissues has quit IRC | 20:09 | |
| *** traveltissues has joined #trustable | 20:11 | |
| *** traveltissues has quit IRC | 20:11 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!