| *** tiagogomes has joined #trustable | 01:38 | |
| *** Guest52267 has quit IRC | 01:38 | |
| *** toscalix has joined #trustable | 08:55 | |
| *** locallycompact has joined #trustable | 09:26 | |
| paulsher1ood | locallycompact: it occurred to me to wonder whether there would be any possibility of implementing a SAT solver for https://gitlab.com/trustable/trustable-mustard/blob/master/markdown/basics.md ? | 15:51 |
|---|---|---|
| persia | Reading that, I'm not sure about the requirement that a t.requirement be current: requirements are subject to change over time (with those changes represented as t.change) | 15:54 |
| persia | (also my usual artifact/artefact grumble) | 15:55 |
| paulsher1ood | well, there's some implication that a t.change may cause some t.requirements to be no longer current | 15:55 |
| persia | Right, hence my uncertainty at "each t.requirement MUST be current" in the t.requirements section, as "a t.change is is any change to t.standards, t.requirements, t.tests, t.inputs, | 16:00 |
| persia | t.documentation, or other materials that affect t.software" specifically includes the implication you mention. | 16:00 |
| * persia isn't sure where the extra carriage return originated | 16:01 | |
| *** locallycompact has quit IRC | 16:05 | |
| paulsher1ood | 'MUST be current' came from andrew + jon iirc | 16:21 |
| persia | It's a common fallacy from folk with lots of experience in requirements analysis. I still have to remind myself that requirements are a snapshot of the intent of the stakeholders at a given moment in time, as I often want to write them down and get them right and then givce them to someone to implement. | 16:23 |
| persia | Unfortunately, the practice of having either "current requirements" or "fixed requirements" ends up significantly slowing the time from desire to implementation, and weakening the ability of a project to ensure that the delivery matches the expectations at delivery time. | 16:24 |
| paulsher1ood | interestingly edmund already mentioned 'intent' to me today | 16:24 |
| paulsher1ood | t.requirements represent the current understanding of stakeholder intent or similar? | 16:24 |
| *** locallycompact has joined #trustable | 16:27 | |
| persia | To my mind, a t.requirement is one component of stakeholder intent, and a collection of consistent t.requirements can be treated as a snapshot of current understanding. | 16:27 |
| persia | But it's hard to truly reach "current" understanding, as each stakeholder may have different views. The closest I think we can approach is the set of t.requirements that has been approved by the approval process by the stakeholders. | 16:27 |
| persia | That is necessarily behind "now", but it is typically in advance of "is implemented". | 16:28 |
| *** locallycompact has quit IRC | 16:28 | |
| *** locallycompact has joined #trustable | 16:28 | |
| paulsher1ood | each t.requirement is believed to represent a stakeholder intent. the set of t.requirements represents what we currently know of all stakeholder intents ?? | 16:29 |
| paulsher1ood | s/is believed to represent/represents/ | 16:30 |
| paulsher1ood | or MUST represent | 16:30 |
| persia | My argument is that I don't believe there is "the set of t.requirements", although I otherwise agree with your statement. | 16:30 |
| persia | I think there are several sets of t.requirements, being things like "all proposed t.requirements", "all approved t.requirements", "all implemented t.requirements", "all t.requirements submitted by the compliance team", etc. | 16:31 |
| paulsher1ood | ah, ok | 16:31 |
| paulsher1ood | do we need t.stakeholder and t.intent? :) | 16:32 |
| persia | But, yes, I think a t.reuirement MUST represent stakeholder intent. I would hope that was covered by semantic assignment of the word "requirement" though. | 16:32 |
| persia | How far do you want to map the semantics :) | 16:32 |
| paulsher1ood | all the way down, ideally ;) | 16:32 |
| persia | I think we can simply assert that t.requirement represtents a statement of stakeholder intent (or maybe a statement of intent, where the approval process separates stakeholders from non-stakeholders). | 16:33 |
| persia | Ouch. Yes, if you want to do that, you have to dig down all the words. | 16:33 |
| persia | Every noun used on that page must be replaced by t.noun, and every noun must be defined in terms of the remainder of the nouns in a closed set. | 16:34 |
| paulsher1ood | yup | 16:34 |
| persia | Best practice is to also define all the verbs in terms of other verbs and nouns. | 16:34 |
| paulsher1ood | yup | 16:34 |
| persia | In that case, we cannot simply assert anything, so yes. | 16:35 |
| persia | t.requirement IS t.statement OF t.stakeholder | 16:35 |
| persia | Where "IS" and "OF" are grammatical particles, "IS" specifying equivalence, and "OF" specifying posession | 16:36 |
| paulsher1ood | eek... maybe later :) | 16:37 |
| persia | Or maybe t.requirement IS t.intent OF t.stakeholder is cleaner. That allows t.intent to be defined as "t.requirement FOR t.feature in t.system" | 16:37 |
| persia | Heh. | 16:37 |
| paulsher1ood | t.requirement is t.evidence | 16:38 |
| persia | Um, no. | 16:41 |
| persia | t.evidence is machine-parseable metadata associated with t.software | 16:41 |
| persia | Or at least, I don't prefer grammars that permit asymmetric equivalence | 16:43 |
| *** toscalix has quit IRC | 17:10 | |
| * paulsher1ood is unclear what the prblem is with that. we do need to be able to parse requirements, and trace them etc | 17:34 | |
| persia | To my mind, a t.evidence object may contain a reference to a t.requirement, but should also contain a t.identity, timestamp, etc. | 17:34 |
| persia | Essentially, who did what when to the t.requirement. | 17:35 |
| persia | So we can query a set of t.evidence to discover current state of a given t.requiremnt, and create t.requirement sets like the examples I listed above. | 17:35 |
| persia | At a semantic level, if "foo IS bar" and "bar IS baz", then I am unhappy if either "foo IS baz" or "baz IS foo" is not also true. | 17:36 |
| persia | But it is possible to create valid grammars that make me unhappy, and it may be that we end up needing such a grammar to express these concepts. | 17:37 |
| paulsher1ood | hmmm. source code is t.evidence also in my worldview, but maybe i'm missing some meta-argument | 17:38 |
| persia | It's precisely the same argument about requirements. | 17:38 |
| persia | To my mind, t.evidence can be about source code, but if we assert equivalence between "source code" and "evidence" and "requirement", then we don't end up with as many nouns. | 17:39 |
| paulsher1ood | are you just distinguising the content and the metadata? | 17:39 |
| persia | Saying "every t.change to t.evidence must contain t.evidence about t.evidence" isn't as comprehensible. | 17:39 |
| paulsher1ood | :) | 17:40 |
| persia | Yes. | 17:40 |
| persia | Use/Mention distinction. | 17:40 |
| paulsher1ood | ok, so t.content needs to be specified, separate from t.evidence | 17:40 |
| persia | So, I suppose I'm arguing about the meaning of the word "is", as much as folk have made fun of others doing this before me. | 17:40 |
| persia | I think t.content IS t.change | 17:41 |
| paulsher1ood | aha | 17:41 |
| persia | In that, I don't think anything exists except as an optimisation snapshot of a given state of the journalled playback of a set of t.evidence | 17:41 |
| paulsher1ood | ack | 17:41 |
| persia | So, we might say "t.evidence REFERENCES t.change" or "t.evidence CONTAINS t.change", depending on the verb definitions. | 17:42 |
| paulsher1ood | i guess i will add t.sourcecode to the t.change list | 17:42 |
| paulsher1ood | just for the benefit of drive-by readers :) | 17:43 |
| persia | I don't think we can use simple grammatical markers (subjective, objective, possessive, locative, etc.), logical operators, or the copula in this relation. | 17:43 |
| * paulsher1ood will leave the interpretation of persia's previous statement to others | 17:44 | |
| *** locallycompact has quit IRC | 21:42 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!