Hallo zusammen Ich suche ein kostenloses Tool zum verwalten von (software) Requirements. Kennt da jemand etwas passendes? Danke
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?
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.
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? ;-)
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.
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
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.
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.
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.
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.
@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?
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.
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.
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. ;-)
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.
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.
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.
Angehängte Dateien:
-
Req_washed.jpg
88 KB
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.
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.
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.
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.
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.
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
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
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 ;-)
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.
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.
A. S. schrieb: > zum anderen wäre Handschrift bei Lesbarkeit für den Gutachter > vertrauenserweckender Jetzt musste ich echt kurz laut auflachen ;-)
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.
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.
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.
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
Rolf M. schrieb: > 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? > Der Beitrag ist zwar älter, aber das kann ich so nicht stehen lassen. Es gibt etliches im Bereich Softwareentwicklung bei dem Requirements Pflicht sind. Steuer mit einem Mikrocontroller eine Maschine an, welche sicherheitsfeature hat. EN 61508: Funktionale Sicherheit von Steuerungssystemen - du brauchst eine Entwicklung mit V-Modell. Die Requirements brauchen dabei nicht von einem externen Kunden kommen. Ein interner Verantwortlicher/Produktmanager o.ä. wird für den Prozess benötigt. Abgesehen davon macht es Entwicklung einfacher, Requirements an eine Software irgendwo zu erfassen. Entweder wenn man schaut warum eine Software tut was sie tut oder was sie alles tut. Vor allem wenn man sie mal gegen eine neuere ablösen muss.... Und da es auch kommerzielle OpenSource Entwicklung gibt ( einfach da schon irgend etwas aus dem OpenSouce Bereich genutzt wird...) .. nun ja.
Muss ich widersprechen. Wenn du mal eine FDA Prüfung mitgemacht hast - die schauen in die Tools. Handschriftlich und V-Modell passt nicht zusammen. Archivierung muss stimmen. etc.pp.
offler schrieb: > Steuer mit einem Mikrocontroller eine Maschine an, welche > sicherheitsfeature hat. EN 61508: Funktionale Sicherheit von > Steuerungssystemen - du brauchst eine Entwicklung mit V-Modell. > > Die Requirements brauchen dabei nicht von einem externen Kunden kommen. > Ein interner Verantwortlicher/Produktmanager o.ä. wird für den Prozess > benötigt. > > Abgesehen davon macht es Entwicklung einfacher, Requirements an eine > Software irgendwo zu erfassen. Entweder wenn man schaut warum eine > Software tut was sie tut oder was sie alles tut. Vor allem wenn man sie > mal gegen eine neuere ablösen muss.... Das darf man aber nicht vermischen: Die Steuerung einer Maschine ist etwas ganz anderes als ihre funktionale Sicherheit. Konkret: Was sie tun soll, bestimmt der Kunde, legt es fest und nimmt es ab. Vieles kann man realisieren, manches nicht und viele Dinge muss man selber sinnvoll gestalten. Es ist weder alles noch das meiste spezifiziert, noch kann alles spezifizierte eingehalten werden. Die Sicherheitsfunktionen hingegen - ergeben sich aus einer Analyse der Gefahrenpotentiale - haben oft mit dem Kunden und seinen Wünschen wenig zu tun - sind per Forderung einfach (also mit bewährter Technik und Methoden, im Gegensatz zur eigentlichen Steuerung, die im Normallfall ja innovativ sein sollte) - Müssen nach V-Modell entwickelt werden, ja, aber dann schreib auch dabei warum: Weil die Anforderungen (und nur die) ganz genau so umgesetzt werden müssen, wie sie als Ausgangslage festgelegt wurden. Das ist bei normalen Entwicklungen selten der Fall. Innovation oder Weiterentwicklung ist dabei nämlich 0. Natürlich meinen viele, hier eine Abkürzung nehmen zu können, indem Steuerungs-HW/SW und Sicherheits-Funktions-HW/SW ja eins sein können. Nein, können sie in der Regel nicht. Es sind getrennte, wechselwirkende aber separate Aufgaben.
Mark B. schrieb: > 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. Ich schätze, alle FuSi-SW-Entwicklung läuft am Schluss auf eine Zulassung hinaus - entweder direkt über Behörden oder indirekt über die Haftpflichtversicherung. Und das spricht dann tendenziell gegen Open Source: Selbst wenn das Motorsteuergerät als OSS entwickelt würde, müsste irgendwann jemand für einen bestimmten Stand die Zulassung durchführen. Die gilt dann aber nur für genau den einen Software-Stand. Also darf die Software nicht mehr vom Anwender geändert werden. Und im FuSi-Bereich müssen teilweise auch die Tools zugelassen werden ("qualifiziert"). Für das kommerzielle DOORS wird da zum Beispiel erheblicher Aufwand getrieben: * http://www.validas.de/TQS/2013/abstracts/Slides_Ducharme.pdf * https://nohau.eu/products/rational-doors/ (Abschnitt "It includes:") Wer solche Nachweise fordert und bezahlt, wird sicher keine Open-Source-Requirements-Verwaltung nutzen, die er selber (weit teurer) qualifizieren müsste. Und umgekehrt: Wenn die IBMler solche Nachweise liefern, sind sie sicher, dass das Tool auch für kritische Anwendungen eingesetzt werden wird - und haben sich entsprechend versichert. In der "normalen" Entwicklung tut man sich den Aufwand mit Requirement-Engineering etc. seit dem Siegeszug von Agile kaum noch an. Kurz: Ein OSS Requirement-Management-Tool wäre ein "Dinosaurier". Holger K. schrieb: > Ich suche ein kostenloses Tool zum verwalten von (software) > Requirements. Ich weiss immer noch nicht, was er damit vorhatte?
keinLichtAufGing schrieb: > Für das kommerzielle DOORS wird da zum Beispiel > erheblicher Aufwand getrieben: Ich kenne 26262 nicht (nur 61508), aber ich habe oft erlebt, dass der Tüv halte Dinge nach irgendwas bescheinigt, der Scope aber derart eng ist, dass sich daraus kaum ein Nutzen, geschweige denn eine Notwendigkeit ergibt. Ist das > "Fit for Purpose” certificate beispielsweise ein echtes Zertifikat, was ein Tool im 26262-Prozess haben muss?
A. S. schrieb: > 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. So siehts aus. Und ich halte in privaten Projekten allein schon deshalb schriftlich fest was ich haben will, um mich nicht zu verheddern. Neue Ideen (die ich dann natürlich auch gerne implementieren will) kommen weitaus schneller als ich sie einbauen kann. Aber wenn ich immer nur das mache was mir als Letztes einfällt, komme ich mit einem Projekt nie in den Status "brauchbar", und dann wird es irgendwann frustrierend.
Hallo zusammen, ich möchte zwei weitere Tools (OSS & free) in die Runde werfen: https://github.com/shuart/ephemeris System Engineering and requirements management application. Features Manage Stakeholders, Requirements, Functions and Products in one place and link them together Record Requirements and Actions trough the "meeting" panel Build the project breakdown structure Generate overview diagrams, ERD and mindmaps from the project relations Produce text specifications based on your model Create interfaces matrix from specific part of your project Link pictures and documents to your Products and Requirements Perform V&V on your projects Schedule your projects with Gantt charts and capacity plannings View next actions in a Kanban layout import archimate file to work on existing data or import from CSV using custom scripts Latest release: Apr 28, 2020 MIT License https://github.com/shuart/ephemeris/blob/master/LICENSE https://cairis.org/index.html CAIRIS stands for Computer Aided Integration of Requirements and Information Security. It is a platform for eliciting, specifying, and validating secure and usable systems. It was built from the ground up to support all the elements necessary for usability, requirements, and risk analysis. Is CAIRIS free? Yes. CAIRIS has been made freely available under an Apache Software License. You can find the source code for CAIRIS on github. Is CAIRIS used in the real world? CAIRIS has been and is currently being used commercially, particularly in critical infrastructure domains such as Defence, Health, Transport, and Water Treatment. We’re always keen to hear from companies (both large and small) interested in using CAIRIS. Please get in touch if you want to use CAIRIS and need help gettting started. Ich selber habe als ersten Schritt Requirements gerade aus einem PDF in Excel kopiert, um sie besser zu managen zu können. Diese werde ich vielleicht in Confluence importieren, damit sie im Team besser diskutiert werden können. Tasks dazu werden in Jira getrackt. Das ist ein kruder Hack, den ich keinem empfehlen möchte. Confluence & Jira sind für kleine Teams (<= 10 User) in der Cloud kostenlos. On-Premise war mal 50$ pro Komponente, wird aber zukünftig eingestellt. Ansonsten fasst dieser Thread die Situation gut zusammen. Eine weitere Lösung (OSS & free, multiplattform), die ich öfters verwende und erwähnen möchte, ist die toolgestützte Erstellung einer Mindmap mit https://docs.freeplane.org/. Gerade zu Projektbeginn hilft mir dies dabei den Überblick zu bekommen. Weil ich viel Text in die Mindmap-Knoten kopiere und die Mindmap durchsuchbar ist, ist es für mich nützlich. Viele Grüsse Frank
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.