mikrocontroller.net

Forum: PC-Programmierung Tool für Requirements Management?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich suche ein kostenloses Tool zum verwalten von (software) 
Requirements.

Kennt da jemand etwas passendes?

Danke

von A. S. (rava)


Bewertung
0 lesenswert
nicht lesenswert
open source kenne ich jetz gerade keines, man kann natürlich irgednwas 
mit Tabellenkalulation bauen, aber das finde ich eher dämlich.

warum nicht einfach markdown auf einem git repo?
Kann die gewünschte Automatisierung geskriptet werden? z.B. mit Python?

von Np R. (samweis)


Bewertung
1 lesenswert
nicht lesenswert
OSRMT
aNimble

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank.
Hab mir beide angesehen.

OSRMT wäre evtl. sogar noch brauchbar.
Allerdings auch bereits ziemlich alt und hat einige Bugs.

Ich bin überrascht, dass es zu diesem Thema so wenig OpenSource gibt.

von Mark B. (markbrandis)


Bewertung
-3 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ich bin überrascht, dass es zu diesem Thema so wenig OpenSource gibt.

OpenSource Entwickler sind halt alle Frickler. Was willst Du da groß an 
Requirements Management erwarten? ;-)

von IQ-Reflektor (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ich bin überrascht, dass es zu diesem Thema so wenig OpenSource gibt.

Ich bin überrascht das es dafür überhaupt spezialisierte 
Computerunterstützung braucht, grosse Projekte und all ihre requirments 
wie beispielsweise bei der Mondlandung konnten Ingenieure auch mit 
Papier und Bleistift managen.

https://nodis3.gsfc.nasa.gov/displayDir.cfm?Internal_ID=N_PR_7150_002B_&page_name=AppendixC

Wichtig an den Requirements sind ihre exakte Formulierung und 
Strukturierung, wie man diese festhält, ob Karteikartensammlung, 
selbstgestricktes Excel oder Datenbank wie DOORS ist doch nebensächlich.

Ohne dieses Grundverständniss ... a fool with a tool remains a fool.

von Ingo D. (ingo2011)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

schau Dir doch mal ein Bugtracker wie Mantis an
https://www.mantisbt.org/

Oder auch GitLab , dort hast Du neben den Git-Repos auch einen 
Issue-Tracker.
https://packages.gitlab.com/gitlab/gitlab-ce

Gruß Ingo

von DPA (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Holger K. schrieb:
> Ich bin überrascht, dass es zu diesem Thema so wenig OpenSource gibt.

Hallo Welt, gib mir deine Requirements. Ich schreib das Programm ja 
nicht für mich oder weil ich das machen will, ich will, dass mir das 
jemand vorschreibt!

Nö, also wenn ich ein Programm Schreibe und dann auch warte, dann 
schreib ich in die Readme, wofür es gedacht ist. Normalerweise nutzen 
dann die meisten meine Version, und damit sag ich dann, was da rein 
kommt und was nicht. Gute Maintainer haben recht hohe Standards, und es 
kann viel Aufwand sein, bis man ein Feature, dass man upstreamen will, 
akzeptiert wird. Das sichert die Qualität. Wer was braucht und macht ist 
so auch immer gut geregelt, da braucht es dann kein spezielles Tool mehr 
für Requirements Management. Ne Mail oder ein Issue Tracker reicht für 
sowas.

Beispiel, ich versuche seit über nem Monat beim Program "consolation", 
welches copy&paste per Maus in der linux console bietet, mouse reporting 
hinzuzufügen, weil ich das Feature benötige: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923181
Irgendwann werden die Fragen geklärt, und der Code in Ordnung sein, und 
dann bekommt es hoffentlich teil von Mainline.

von A. S. (rava)


Bewertung
1 lesenswert
nicht lesenswert
Mark B. schrieb:
> OpenSource Entwickler sind halt alle Frickler. Was willst Du da groß an
> Requirements Management erwarten? ;-)

ich kenn Req Engineers, die keine Ahnung von SW-Entwicklung haben und 
dann irgendwelches wildes, nicht messbares zeug in ihr teures, 
zertifiziertes Tool schreiben.

Da haben OpenSource Entwickler einen klaren Vorteil. Das haben auch 
schon viele Firmen erkannt.

von Hans W. (hans-)


Bewertung
0 lesenswert
nicht lesenswert
OSEE bzw RMF ? Beides Eclipse Projekte...

73

von Der Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> ich kenn Req Engineers, die keine Ahnung von SW-Entwicklung haben und
> dann irgendwelches wildes, nicht messbares zeug in ihr teures,
> zertifiziertes Tool schreiben.
>
> Da haben OpenSource Entwickler einen klaren Vorteil. Das haben auch
> schon viele Firmen erkannt.

Das liegt dann aber  an der Art der reg engs die dort arbeiten! Viele 
Firmen handhaben die requirments parallel zu der Entwicklung, losgelöst 
um formale Anforderungen zu erfüllen. War mal bei einer Firma in München 
(Ostbahnhof) im Projekt A400M. Die haben das einfach hinterher gemacht, 
weil alles schon fertig war.

Die stellen dann einfach ein paar billige BWLler dran, die keinen Job 
kriegen und daher sehr preisgünstig den Dateneingabe-Lackel machen.

Unter Systemingenieur - und die SOLLTEN das eigentlich tun - verstehen 
wir hier etwas grundlegend anderes.

von Imonbln (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich tendiere auch dazu die Requierments, in einen Bugtracker zu 
verwalten.
Ob Redmine, track, Mantis, Bugzilla, Jira oder auch ganz old school als 
Postit auf dem Whiteboard, spielt dabei letztendlich keine Rolle und 
hängt ein wenig von den Umfeld ab in welchen man Arbeitet.

Meine Erfahrung nach Harmoniert, dass nutzen der gleichen Bugtracker 
Software (aber ein anderes Board) mit dem was die Entwicklung benutzt am 
besten mit dem Workflow des Team. Und eignet sich mindesten genau so wie 
eine Spezialsoftware um den Überblick zu erhalten.

von keinLichtAufGing (Gast)


Bewertung
3 lesenswert
nicht lesenswert
@Holger:

Ich habe da früher - berufsbedingt - auch schon mal gesucht.
RQ-Management-Systeme im OS-Bereich gibt tatsächlich verschwindend
wenige. Das liegt meines Erachtens in der Natur der Sache. Ich
formuliere mal mit Absicht ziemlich scharf:

* Klassisches Requirement-Management ist eher mit einem industriell
bzw. tayloristisch geprägten IT-Verständnis verknüpft. Ideal ist,
die Software "am Fliessband zu bauen wie die Autos". Daraus ergibt
sich dann auch zwanglos der klassische Wasserfall ;-)

* Requirement-Management-Tools sind, wie der Name schon sagt, Tools
zum Verwalten von An-Forderungen, die der Kunde Dir als Entwickler
stellt und die Du erfüllen sollst oder gar musst. Wenn dann noch
Traceability gefordert wird, zeigt das ganz schnell die 
Machtverhältnisse
auf: Du musst Dein Produkt rechtfertigen und nachweisen, daß Du keine
Anforderung ausgelassen hast.
Der klassische Open-Source-Ansatz läuft genau andersherum: Oft hast
Du ein Programm geschrieben, um ein Problem bei Dir zu lösen. Da es
Dir keinen Nutzen bringt, es geheim zu halten, stellst Du es ins Netz
"in hope that it will be useful", so daß sich andere daran bedienen
und es ggf. anpassen können, wie Du Dich bei anderen bedienst. Im
Idealfall wächst dann langsam ein immer besseres Programm heran.

Was ich sagen will: Was sollte ein OS-Projekt mit einem RQ-System
anfangen? Wenn Du ein Programm für Dich schreibst, weisst Du doch
selbst, was herauskommen soll, und brauchst dafür keine Dokumente
(und wenn es was größeres wird, wäre für Dich eine automatische
Testpyramide wohl wertvoller als ein reines RQ-Dokument).

Warum also sollte ein OS-Projekt ein RQ-Management-System nutzen oder
bauen? Und umgekehrt: Welchen Anreiz hätte zum Beispiel ein
Automobilhersteller, ein solches Tool, teuer entwickelt und
SPICE-zertifiziert, der Öffentlichkeit (und damit der Konkurrenz)
preiszugeben?

von Rolf M. (rmagnus)


Bewertung
3 lesenswert
nicht lesenswert
Genau. Requirements sind an sich ein Kommunikationsmittel zwischen Kunde 
und Lieferant - und natürlich ein Mittel zur Prüfung des Ergebnisses. 
Bei OpenSource-Enwticklung gibt es eine solche Beziehung Kunde - 
Lieferant oft nicht, also wer sollte da für wen Requirements 
aufschreiben?

IQ-Reflektor schrieb:
> Holger K. schrieb:
>> Ich bin überrascht, dass es zu diesem Thema so wenig OpenSource gibt.
>
> Ich bin überrascht das es dafür überhaupt spezialisierte
> Computerunterstützung braucht, grosse Projekte und all ihre requirments
> wie beispielsweise bei der Mondlandung konnten Ingenieure auch mit
> Papier und Bleistift managen.

Beim Mondflug war auch ein Computer an Bord, der aus Einzelgattern 
zusammengelötet war und 4 kB RAM hatte. Nur weil das damit auch möglich 
war, heißt das ja nicht, dass man für immer und ewig dabei bleiben muss.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
keinLichtAufGing schrieb:
> Wenn Du ein Programm für Dich schreibst, weisst Du doch
> selbst, was herauskommen soll, und brauchst dafür keine Dokumente

Den Punkt würde ich sogar noch zuspitzen: du weißt nur grob, was 
herauskommen soll, der Appetit kommt erst beim Essen. Wenn etwas neu 
oder innovativ ist, dann kennt man es nicht, und mit jedem Schritt 
eröffnen sich neue Perspektiven.

Ich bin immer entsetzt, mit welcher Inbrunst unsere Manager und 
Verfahrenstechniker glauben, etwas neues in ein paar Kränzchen so 
entwerfen zu können, dass es programmiert werden kann. Als wären iPhone, 
Facebook oder Autos am Reissbrett entstanden. Oder gar durch das 
Aufstellen von Anforderungen. Nein. Die meisten Anforderungen werden gar 
erst im Projektverlauf sichtbar.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
IQ-Reflektor schrieb:
> Wichtig an den Requirements sind ihre exakte Formulierung und
> Strukturierung, wie man diese festhält, ob Karteikartensammlung,
> selbstgestricktes Excel oder Datenbank wie DOORS ist doch nebensächlich.

Spätestens wenn man sicherheitsrelevante Software entwickelt, für die 
man diverse Nachweise führen muss, ist man recht schnell aufgeschmissen 
wenn man dem Gutachter eine Karteikartensammlung übergibt. ;-)

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
> Spätestens wenn man sicherheitsrelevante Software entwickelt, für die
> man diverse Nachweise führen muss, ist man recht schnell aufgeschmissen
> wenn man dem Gutachter eine Karteikartensammlung übergibt. ;-)

Das stimmt nur halb. Zum einen schaut der Gutachter meist nur, ob der 
Workflow fähig ist und gelebt wird.

Zum anderen sind die 1% Sicherheit kein Grund, einen vorauseilenden 
Formalismuswahn auch auf die davon unberührten 99% auszudehnen.

Das ist quasi wie nassi shneydermann der 80er und 90er.

von Le X. (lex_91)


Bewertung
1 lesenswert
nicht lesenswert
Es gibt Projekte da ist (toolgestütztes) Requirements Engineering 
sinnvoll und teilweise notwendig, und es gibt Projekte da ist das 
weniger sinnvoll.
Wie immer halt.

OSS lebt eher vom Wildwuchs, da kann ich mir schlecht vorstellen wie man 
das vorher formal sauber spezifizieren will (mal davon abgesehen dass da 
keiner Bock drauf hat weil alle fancy Sachen coden wollen).
Deswegen gibt es entsprechend wenig OSS-Tools die dir hier weiterhelfen.

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
In der Arbeit verwenden wir DOORS und MagicDraw (für Requirements in 
SysML). Beide nicht OSS.

Für SysML gibt es das Papyrus Plugin für Eclipse, das sowas vielleicht 
schon kann. Allerdings glaube ich, dass Papyrus keine Tracability 
Tabellen beherrscht.

von C. A. Rotwang (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
>> Wichtig an den Requirements sind ihre exakte Formulierung und
>> Strukturierung, wie man diese festhält, ob Karteikartensammlung,
>> selbstgestricktes Excel oder Datenbank wie DOORS ist doch nebensächlich.
>
> Spätestens wenn man sicherheitsrelevante Software entwickelt, für die
> man diverse Nachweise führen muss, ist man recht schnell aufgeschmissen
> wenn man dem Gutachter eine Karteikartensammlung übergibt. ;-)

Nein, die Gutachter mit denen ich es zu tun hatte, legen tatsächlich 
viel Wert auf Papier insbesonders das Deckblatt, weil dort die 
Verantwortlichen (die nächsten Interviewpartner im Audit) unterschrieben 
haben. Inzwischen sind sie aber auch zufrieden wenn das Deckblatt mit 
den Unterschriften gescannt und elektronisch in der Dokumentenverwaltung 
abgespeichert ist.
--
Anbei eine gekürzte Seite aus dem Kapital Requirements aus dem 
Standardwerk:
ISBN: 978-1482206050.

Wie man sieht, geht es tatsächlich viel um schreiben und Ausdruck und 
das Tool für der dergleichen ist eine Textverarbeitung. Da aber 
requirements hauptsächlich als Referenz für weitere Dokumente wie 
Systemarchitektur, Verifikationsplan, -report dienen nimmt man auch gern 
ein aufgepimptes Excel, weil man damit besser querweisen und in Spalten 
ordnen kann als Word&Co.
--
>Das liegt dann aber  an der Art der reg engs die dort arbeiten! Viele
>Firmen handhaben die requirments parallel zu der Entwicklung, losgelöst
>um formale Anforderungen zu erfüllen. War mal bei einer Firma in München
>(Ostbahnhof) im Projekt A400M. Die haben das einfach hinterher gemacht,
>weil alles schon fertig war.

Ja die Welt ist klein, vor 8 Jahren hatte ich (wohl?) an der Hardware 
für das selbe Rhode&Schwarz Produkt (SDR-UKW-Funk) zu tun.
Das lief aus meiner Sicht etwas anders ab, als hier dargestellt. Zuerst 
gab es das SDTR-Gerät (für Fahrzeuge) das dann später zum SDAR (für 
Flieger) werden sollte. Der Prozess fürs SDTR war schon ähnlich 
gestaltet wie für eine Flugzertifizierung nötig, um sich doppelte Arbeit 
später zu sparen also vorzuziehen. Und an den Hardware-requirements 
haben keine billigen BWL'er gesessen sondern Elektroingenieure aller 
Coleur. Allerdings ist dann später die Entwicklung zwischen R&S München 
und Stuttgart hin und her geschoben worden, das da schon der Eindruck 
entstehen kann, da wären die Reqs nachher entstanden. Genutzt wurde 
übrigens ein in Clearquest eingebettets DOOR -ach was haben wir über die 
Software geflucht.

von Günter M. (redround)


Bewertung
0 lesenswert
nicht lesenswert
Wir nutzen JAMA als als Requirement-Tool und ich muss sagen, dass es 
schon einen deutlichen Mehrwert bringt - wenn man es richtig nutzt. Ist 
aber leider keine Freeware.

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Danke für eure Beteiligung.

Leider haben viele missverstanden, was ich gemeint habe.
Es geht mir nicht darum, ein RQ-Tool FÜR OpenSource Projekte zu finden.

Sondern ich suche ein RQ-Tool welches selbst OpenSource ist aber für 
andere, nicht zwingen OpenSource, Projekte verwendet wird.

Konkret, ich brauche ein RQ-Tool und möchte kein Geld ausgeben.
Daher habe ich nach einer OS-Lösung gesucht.

von Np R. (samweis)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Leider haben viele missverstanden, was ich gemeint habe.

Ich glaube, Du hast missverstanden, was viele hier gemeint haben:
Weil die OS-Gemeinde einen anderen "Development Life Cycle" hat und 
andere Entwicklungsmethoden, hat sie wenig Bedarf an einem RQM Tool. 
Daher gibt es nur wenige, die FOSS sind.

Requirements Management ist gefühlt angestaubt, riecht nach reguliertem 
Umfeld und nach schwierigen Kundenbeziehungen. Das ist nicht das, was 
dem "freien" (freiwilligen) Programmierer vorschwebt, der ja oft in 
erster Linie etwas für sich selbst programmiert.

Etwas modernere Stichwörter wie "SCRUM" oder "Agile" führen da schon zu 
mehr Treffern.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Konkret, ich brauche ein RQ-Tool und möchte kein Geld ausgeben.

Schau, offensichtlich haste Computer mit der Möglichkeit der Texteingabe 
und abspeicherung, damit haste auch ein RQ-Tool.

Was du brauchst ist eher ein Lehrbuch zum Thema.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
Holger K. schrieb:
> Konkret, ich brauche ein RQ-Tool und möchte kein Geld ausgeben.

Das widerspricht sich meist in der Art, dass so ein Tool meist nur in 
einem professionellen Umfeld gebraucht wird, wo Arbeitszeit bezahlt wird 
und ein paar k€ Peanuts sind

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
Holger K. schrieb:
> Danke für eure Beteiligung.
>
> Leider haben viele missverstanden, was ich gemeint habe.

Nein, haben sie nicht. Du wurdest von mehreren Leuten darauf 
hingewiesen, dass vernünftige Tools für Requirements Management in aller 
Regel etwas kosten.

> Konkret, ich brauche ein RQ-Tool und möchte kein Geld ausgeben.

Das passt meines Erachtens nach nicht zusammen.

Entweder Du musst Normen erfüllen, um eine Zulassung für das zu 
erhalten, was entwickelt wird: Dann wird auch Geld für professionelle 
Tools da sein.

Oder die Form, in der die Anforderungen festgehalten werden, ist völlig 
beliebig: Dann kann man die auch in Word oder Excel oder mit einem 
beliebigen Texteditor aufschreiben. Die Datei mit einer Versionsnummer 
versehen und in einem Repository abspeichern - fertig.

: Bearbeitet durch User
von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> Nein, die Gutachter mit denen ich es zu tun hatte, legen tatsächlich
> viel Wert auf Papier insbesonders das Deckblatt, weil dort die
> Verantwortlichen (die nächsten Interviewpartner im Audit) unterschrieben
> haben.

Ja schon. Aber erstellt wird dieses Papier ja doch mit entsprechenden 
Tools. Nicht etwa an der Schreibmaschine ;-)

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
> Ja schon. Aber erstellt wird dieses Papier ja doch mit entsprechenden
> Tools. Nicht etwa an der Schreibmaschine ;-)

Zum einen reichen hier (freie) Word und Excel, zum anderen wäre 
Handschrift bei Lesbarkeit für den Gutachter vertrauenserweckender als 
jeweils der letzte ausgedruckte  Stapel mit nicht erkennbaren 
aufhübschungen vom Vortag.

Der Gutachter prüft nicht das Produkt oder den Inhalt der Dokumente, er 
prüft, ob die Prozesse fähig sind und gelebt werden. Handschriftliche 
Protokolle/Checklisten sind wesentlich schwieriger zu faken als 
Word-Dokumente.

von C. A. Rotwang (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Mark B. schrieb:
> C. A. Rotwang schrieb:
>> Nein, die Gutachter mit denen ich es zu tun hatte, legen tatsächlich
>> viel Wert auf Papier insbesonders das Deckblatt, weil dort die
>> Verantwortlichen (die nächsten Interviewpartner im Audit) unterschrieben
>> haben.
>
> Ja schon. Aber erstellt wird dieses Papier ja doch mit entsprechenden
> Tools. Nicht etwa an der Schreibmaschine ;-)

Naja es spricht IMHO auch regulatorisch nichts dagegen, die Requirements 
erstmal auf Karteikarten zu sammeln und zu sortieren.
Manche machen es sich mit Papier und "schmierzettel" einfacher als 
gleich an einem Computer mit seinen 1000 Ablenkmöglichkeiten (bspw. 
Forumsbeiträge zu schreiben ;-)) zu setzen.

 Und wenn der Zeitpunkt der ersten Diskussion oder Freigabe gekommen 
ist, wird das ganze "ins Reine" geschrieben, ob wie Computer oder 
Schreibmaschine ist grad egal.
Manche schieben den Beginn der Requirementerstellung mit den 
fadenscheinigen Grund, sie hätten das Tool dazu grad nicht bei der Hand 
auf den Tag St. Nimmerlein. Da hilft IMHO der Hinweis, das am 
wichtigsten an den Requirements die Requirements selbst sind und nicht 
das Tool zu ihrer Verwaltung.

von Le X. (lex_91)


Bewertung
1 lesenswert
nicht lesenswert
A. S. schrieb:
> zum anderen wäre Handschrift bei Lesbarkeit für den Gutachter
> vertrauenserweckender

Jetzt musste ich echt kurz laut auflachen ;-)

von keinLichtAufGing (Gast)


Bewertung
1 lesenswert
nicht lesenswert
um den TO nochmal aufzugreifen:

Holger K. schrieb:
> Konkret, ich brauche ein RQ-Tool und möchte kein Geld ausgeben.
> Daher habe ich nach einer OS-Lösung gesucht.

"ich brauche" heisst für mich, dass Du das Tool nicht ganz freiwillig 
nutzt.

Um was für ein Projekt handelt es sich überhaupt? Und warum musst Du 
Requirements verwalten?
Wenn Du uns das mitteilst, können wir dir vielleicht eine Alternative 
zeigen.

Rolf M. schrieb:
> Genau. Requirements sind an sich ein Kommunikationsmittel zwischen Kunde
> und Lieferant - und natürlich ein Mittel zur Prüfung des Ergebnisses.

Das muss ich mir merken. So schön hätte ich es auch gerne auf den Punkt 
gebracht :-)

> Bei OpenSource-Enwticklung gibt es eine solche Beziehung Kunde -
> Lieferant oft nicht, also wer sollte da für wen Requirements
> aufschreiben?

Ich würde sogar noch weiter gehen - dort ist die Machtbeziehung gerade 
umgekehrt zum klassischen Prozeß.
In der Industrie ist der Kunde gegenüber dem Zulieferer oft 
wirtschaftlich übermächtig - daher auch
An- Forderungen.

Einem OS-Projekt gegenüber kannst Du typischerweise keine Forderungen 
stellen - wenn Du ein Programm etwas anders haben möchtest, dann kommt 
ganz schnell die Antwort "mach es selbst". Und selbst wenn Du Deine 
Änderungen als Patches an die Maintainer schickst, liegt es in deren 
Entscheidung, ob es in die offizielle Version wandert.

von Dickbrettbohrmaschine (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Auch wenn das Thema schon alt ist:
Ich wurde vor kurzem darauf angesprochen. Da habe ich das OSS-Angebot in 
dem Bereich mal gesichtet - vielleicht hilft das Ergebnis ja mal 
jemandem:

* aNimble: Verwaist. Scheint ein gescheitertes Startup-Projekt zu sein 
(für die Online-Doku muszte man sich registrieren!). Idee war wohl, die 
fertige Version 1.0 kommerziell zu machen. Das ganze ist in Java/Grails 
programmiert und unter Java 8+ mW nicht mehr lauffähig.

* OSRMT: War anscheinend durch aNimble eine ganze Weile verwaist, seit 
kurzem versucht sich jemand auf github.com an einer Wiederbelebung. Es 
scheint aber wenig zu passieren.

* ProR/RMF: Ein Eclipse-Projekt, das anscheinend von einer 
Uni-Forschungsgruppe betrieben wurde und inzwischen in eine Firma 
ausgegründet ist. Laut Wikipedia läuft unter aktuellem Eclipse nur noch 
die ältere Version 0.10 (früher letzter Stand 0.14). Neuere Versionen 
sind anscheinend closed source und kommerziell.

* ReqCycle: "ReqCycle is simply dying now." Guckst Du hier: 
https://polarsys.org/forums/index.php/t/549/

Die Lage ähnelt verblüffend der bei freien UML-Editoren:

* ArgoUML dümpelt seit Jahren dahin

* Die StarUML-Entwickler haben wieder auf Closed-Source umgestellt - es 
ging nicht mehr anders.

* "Umbrello needs love"

Vielleicht auf Dauer ein Thema für IT-Archäologen, falls es so was gibt.

von Mark B. (markbrandis)


Bewertung
0 lesenswert
nicht lesenswert
Dickbrettbohrmaschine schrieb:
> Auch wenn das Thema schon alt ist:
> Ich wurde vor kurzem darauf angesprochen.

Hast Du demjenigen auch gesagt, dass man dafür jeden beliebigen 
Texteditor verwenden kann? Man sollte nur die Datei mit den 
Anforderungen in ein Versionskontrollsystem einstellen. Dann passt das 
schon.

von Bernd (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
> dass man dafür jeden beliebigen
> Texteditor verwenden kann?
Kann man.
Wie immer, gibt es aber ggf. auch geeignetere Werkzeuge.

Keine Ahnung, wie gut das geht, hatte nur mal ganz kurz 
reingeschnuppert:
https://www.mentor.com/company/news/reqtracer-automates-requirements-of-electronic-design-projects

von Holger K. (holgerkraehe)


Bewertung
0 lesenswert
nicht lesenswert
Danke für das Update... :)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.