To me, the most laborious part of the requirements-gathering process, isn't anything to do with driving the collection of the client's description of the problem domain and (hypothetical) solution domain.<p>Instead, it's:<p>1. having domain experts understand the requirements well-enough to recognize and push back on impossible/impractical requirements (this being the reason the person doing the requirements-gathering is almost always an engineer of some kind); and<p>2. communicating that impossibility/impracticality back to the client, so that they'll <i>understand</i> it well-enough to be able to iterate on the requirements (or, potentially, realize that the problem is now entirely impossible/impractical to be solved with the general approach they have in mind.)<p>Is there any tool in this category that tries to eliminate at least <i>some</i> of this human labor, acting as a "compiler for requirements" that can be fed "requirements validation rules" — or maybe constructing the requirements into an expert system or proof-language and running it to find contradictions?<p>Not as something to assist the engineer in validating, to be clear (there's plenty of those); but rather as something to sit as the equivalent of a "level-one CSR" <i>in front of</i> engineers, to give some level of pre-validation to things before they're tasked with fully validating them. Something that could live on the backend of a "Requirements Elicitation" tool like this, to act as a CI system, preventing clients from "finalizing" their requirements until they've corrected any obvious errors.
Reminds me of Planguage by Tom Gilb, see e.g. <a href="https://www.amazon.com/-/de/dp-0750665076/dp/0750665076" rel="nofollow">https://www.amazon.com/-/de/dp-0750665076/dp/0750665076</a>.<p>Many attempts have been made with varying degrees of formalization. Another one is e.g. <a href="https://en.wikipedia.org/wiki/Gellish" rel="nofollow">https://en.wikipedia.org/wiki/Gellish</a>.<p>It would be interesting to know what FRET is supposed to be able to do better than previous approaches.
This is the first time I heard about the "NASA Open Source Agreement" [0] software license, which, sadly, is not GPL-compatible. I am confused why a government agency can release something more restrictive than the public domain.<p>I wish license awareness was a part of more discussions. I've noticed a trend on HN to be dismissive or unaware of the implications of such things until it's too late.<p>[0] <a href="https://en.wikipedia.org/wiki/NASA_Open_Source_Agreement" rel="nofollow">https://en.wikipedia.org/wiki/NASA_Open_Source_Agreement</a>
This is fantastic if you don't mind your requirements being out of date by the time you finish writing them down. That is assuming your business stays alive long enough.<p>Jokes aside, I would suggest not to corrupt your mind by looking at it, unless you are responsible for a complex safety critical application (never good idea to mix complex and safety critical -- you likely have more important problem to solve) or where a single software error can cause multi-billion dollar loss (never good idea to design your application so that single error can cause huge loss -- you likely have more important problems to solve).<p>I have seen many attempts to formalise requirements this way and they all utterly failed. Main reason being that the people who tried to implement it were not ready for the vast effort needed to actually get it done and then to maintain it as requirements inevitably change.<p>But the more fundamental reason for all these failures was that there always have been much more important things to get done and people who pushed these tools just did not understand what is important and this usually ends in project failure.