[HN Gopher] Formal Requirements Elicitation Tool
___________________________________________________________________
Formal Requirements Elicitation Tool
Author : xo5vik
Score : 49 points
Date : 2021-12-12 11:15 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Rochus wrote:
| Reminds me of Planguage by Tom Gilb, see e.g.
| https://www.amazon.com/-/de/dp-0750665076/dp/0750665076.
|
| Many attempts have been made with varying degrees of
| formalization. Another one is e.g.
| https://en.wikipedia.org/wiki/Gellish.
|
| It would be interesting to know what FRET is supposed to be able
| to do better than previous approaches.
| lmilcin wrote:
| 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.
|
| 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).
|
| 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.
|
| 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.
| basilgohar wrote:
| 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.
|
| 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.
|
| [0] https://en.wikipedia.org/wiki/NASA_Open_Source_Agreement
| User23 wrote:
| The work was probably done by a contractor. In that case it's
| not a work of the US Government and the government can be
| assigned copyright.
| Rochus wrote:
| > which, sadly, is not GPL-compatible
|
| A lot of even more common open-source licences are not "GPL
| compatible", mostly because they don't require "copyleft"
| (which also applies to the NASA license). All approaches have
| their specific advantages and disadvantages. GPL has
| disadvantages as well.
| detaro wrote:
| A license doesn't have to be copyleft to be GPL compatible.
| Rochus wrote:
| Unless you want to use GPL code in your project which uses
| a non-copyleft license?
| detaro wrote:
| I.e. then GPL is not "your non-copyleft
| license"-compatible. License compatibility often is not
| bidirectional.
| yjftsjthsd-h wrote:
| CDDL and GPL are both copyleft. They are not compatible.
| Rochus wrote:
| Pls define "compatible"; this is a totally
| ambiguous/undefined term; that's why I put it in quotes
| in all of my comments.
| yjftsjthsd-h wrote:
| It's a perfectly well accepted term in context (jargon);
| if it's new to you then that's fine but it's not a fault
| of the term. When you use open source code, you have to
| comply with the license requirements on that code.
| Sometimes, it's possible to combine code because the
| licenses can both be applied to the combined result at
| the same time. For instance, many permissive licenses
| boil down to a requirement that you include the original
| author in credits for the program. The GPL requires that
| you share the source code that went into a binary with
| anybody who gets a copy of binary (basically). Since you
| can fulfill both of these requirements at the same time,
| you can freely combine code into the two licenses
| (although the result will _effectively_ be all GPL), so
| they 're compatible. Because GPL & CDDL both require that
| the relevant code must be licensed under their license
| specifically, you can't fulfill both requirements at the
| same time unless the code was originally dual-licensed by
| the original authors, because you can't change GPL code
| to CDDL or vice-versa.
|
| (IANAL and this is simplified; tread cautiously)
| Rochus wrote:
| Thanks. The question was meant more rhetorically, since
| lawyers (I also studied law) usually have a hard time
| with OSS licenses, and many developers make assumptions
| that often don't match reality. A seemingly "well
| accepted" assumption often turns out to be a costly
| mistake. I therefore share your recommendation: tread
| cautiously.
| pc86 wrote:
| Why do lawyers have a hard time with OSS licenses?
| Rochus wrote:
| Because the licenses often do not use the established
| legal language, or are not formulated with respect to
| existing legislation or international agreements.
| fluidcruft wrote:
| "Compatible" means that two licenses don't have
| terms/conditions that contradict. CDDL was deliberately
| designed to conflict with GPL.
|
| For example https://www.fsf.org/licensing/zfs-and-linux
| Rochus wrote:
| > means that two licenses don't have terms/conditions
| that contradict
|
| This approach is too simplistic. It should also be
| remembered that each state has its own legislation and
| the effect and enforceability (and thus the
| "compatibility") of the licenses differs in each country.
| It also depends on what you specifically intend to do
| with the OSS licensed components. A conclusion can only
| be reached for the specific case at hand, not in general.
| As long as there are no supreme court rulings for the
| specific case or a sufficiently similar case, the legal
| situation remains uncertain.
| fluidcruft wrote:
| There's plenty of enforcement precedent. The fact that
| big-pocket companies settle rather than go to court
| against the FSF says more than you think it does.
| Rochus wrote:
| > There's plenty of enforcement precedent.
|
| Unfortunately not. There are some rulings on a few
| issues, but far too few to establish solid practice.
|
| > settle rather than go to court
|
| Unfortunately, this is a practice that is already known
| from the patent field, and which unfortunately also opens
| the door to trolls. Especially the big companies would
| have the necessary budget to have important license
| issues clarified in court. By the way, the FSF and others
| could also take legal action on various unclear points of
| their license, but they knowingly refrain from doing so
| because the risk is too great for them, too.
| fluidcruft wrote:
| FSF and SFC take plenty of enforcement actions and are
| quite successful. You seem to be just spreading lawyer
| FUD.
| Rochus wrote:
| Then maybe you can provide references to the leading
| judgments in matters of e.g. "Tivoization" or
| termination/reinstatement of the license.
| fluidcruft wrote:
| Tivoization doesn't violate GPLv2. It was one of the
| major motivations for GPLv3.
| detaro wrote:
| Why did you think the question was about rulings about
| GPLv2 and not GPLv3?
| yjftsjthsd-h wrote:
| > As long as there are no supreme court rulings for the
| specific case or a sufficiently similar case, the legal
| situation remains uncertain.
|
| By that standard, no open Source license is
| understandable or tested in any situation, forget
| combining them.
| Rochus wrote:
| This is a reason why many companies still avoid using OSS
| altogether.
| p_l wrote:
| CDDL wasn't deliberately designed to be incompatible with
| GPL - that's _one_ person 's off-hand remark at one
| conference. Simultaneously we know that teams that
| insisted against GPLv3 expected that CDDL code will be
| compatible with GPLv2 projects like linux.
| fluidcruft wrote:
| There are many licenses that have fewer requirements than
| a GPL or copyleft license. People can take that code and
| make their own versions that are proprietary/closed
| source for example. If the license is "compatible" then
| it allows anything the GPL or copyleft requires and is
| similar to a company taking the code and making it
| proprietary as far as the original license is concerned.
| yjftsjthsd-h wrote:
| In fact, permissive licenses are much more likely to be GPL
| compatible/combine-able because they don't care if you
| relicense the combined work to GPL, whereas copyleft
| licenses are much more likely to include a provision that
| the result can only be under the same license, and since
| GPL imposes the same requirement you're left with
| incompatibility.
| bubble_instr wrote:
| i wonder what tool was used to gather the requirements for FRET?
| throwawaybutwhy wrote:
| It requires python2. Guess there was some red tape involved.
| derefr wrote:
| 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.
|
| Instead, it's:
|
| 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
|
| 2. communicating that impossibility/impracticality back to the
| client, so that they'll _understand_ 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.)
|
| Is there any tool in this category that tries to eliminate at
| least _some_ 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?
|
| 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" _in front of_ 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.
| andrewviren wrote:
| This looks comprehensive. What commercial software does this
| replace / compete with? Does one exist?
| johnwalkr wrote:
| There are a lot. I work in the industry and IBM Doors is the
| traditional tool but everyone hates it. Jama and Valispace are
| more modern tools, and there are various addons for JIRA as
| well. Those are all for general use, if you consider software
| requirements there are a ton of other tools.
|
| MS Word plus manual tracking is also common but revision and
| configuration is control is a nightmare.
___________________________________________________________________
(page generated 2021-12-12 23:01 UTC)