Hi ich muss mich mit requirement engineering befassen. Was gehört in stakeholder requirements und was in software requirements(die sich von stakeholder reqs ableiten oder auch nicht). Hat jemand eine Antwort?
:
Verschoben durch Moderator
klaus schrieb: > Was gehört in stakeholder requirements und was in software > requirements(die sich von stakeholder reqs ableiten oder auch nicht). > Hat jemand eine Antwort? Ich habe die große Datenkrake mit den Schlagworten 'stakeholder requirements' gefüttert und an 3. Stelle schon eine Erklärung in Muttersprache erhalten - nur lesen/kapieren muss man selber.
Das ist halt der heute übliche "Schwafelsprech", wo man statt Hausmeister halt "Facility Manager" sagt, was das Gleiche bedeutet aber wichtiger klingt. Grob könnte man sagen, dass Requirement Engineering das Zusammenstellen und Bewerten aller Anforderungen an ein Produkt oder Projekt umfasst. Dazu gehört auch die Dokumentation, wie die Anforderungen erfüllt werden können - und wie die Erfüllung später im Verlauf des Projektes überwacht werden können. Früher waren das das Pflichten- und das Lastenheft und die Termin- und Kostenpläne. Software Requirments umfassen neben den zu erledigenden Aufgaben noch die Schnittstellen zu anderen "Tasks", die Testbarkeit und die Produktpflege bei späteren "Updates". Stakeholder Requirements sind ein sehr weicher Begriff. Da werden Wechselwirkungen mit Beteiligten und die Anforderungen an diese erfasst. Im einfachsten Fall sind "Beteiligte" im eigenen Unternehmen. Es können aber auch Zulieferer sein, an deren Qualität die Anforderungen so gestellt werden müssen, dass die Produktanforderungen von denen sicher erfüllt werden. Wenn beispielsweise bei der Software bestimmte Sicherheitsanforderungen bestehen, müssen diese auch von zugelieferten Programmen erfüllt sein. (Gilt z.B. bei sicherheitskritischen Anwendungen.) Bei Flugzeugen gelten hohe Sicherheitsstandards. Wenn da eine Verschraubung defekt ist, darf diese nur mit speziell freigegebenen Bauteilen repariert werden. Eine Schraube aus dem Baumarkt dürfte da nicht eingesetzt werden, selbst wenn sie passt. So etwas ist beispielsweise ein "Requirement", das dokumentiert und an alle Beteiligten verteilt wird. Problem bei den modernen Schlagworten ist, dass darunter jeder etwas Anderes versteht, vor allen Dingen, wenn das Projekt länderübergreifend ist. (Alle glauben zu wissen, was gemeint ist, aber wehe man fragt mal im Detail nach.....)
Günni schrieb: > Stakeholder Requirements sind ein sehr weicher Begriff. Stakeholder ist ein relativ neuer aber sehr treffender Begriff: würde früher nur von Anforderungen geredet und ein Benutzer unterstellt, so umfasst stakeholder alle Interessenten. Neben dem Benutzer (z.b. Heimwerker) auch dessen Frau (WAF), die Kinder (Sicherheit), den Verkäufer (Marge), das Transportunternehmen (Maße, Gewicht), den Kundenservice (wenig Rückfragen/Rückläufer), den Exporteur (Mehrsprachigkeit), etc. pp
Hi hättet ihr paar real life Beispiele? In einem Embedded System wie zum Beispiel ein IOT GPS Tracker 1. Was geht in Stakeholder requirements rein 2. Was in Software Requirements 3. Was in Hardware requirements
klaus schrieb: > 1. Was geht in Stakeholder requirements rein > 2. Was in Software Requirements > 3. Was in Hardware requirements Das musst du die betroffenen Firmen/Personen fragen. Es gibt keine allgemeingültige Regel. Natürlich darfst du dir gerne Meinung dazu bilden, aber die wird für dich in der Praxis nutzlos sein, weil du mit andere zusammen arbeiten musst, deren Meinungen zusammen gebracht werden müssen. Deine eigene Meinung wäre nur eine mehr, um die niemand gebeten hat. Macht es nur noch komplizierter.
2 Guidelines: IEEE Std 830-1984 https://de.wikipedia.org/wiki/Software_Requirements_Specification https://www.microtool.de/en/knowledge-base/what-is-a-software-requirements-specification/
klaus schrieb: > 1. Was geht in Stakeholder requirements rein Es soll ein Fluxkompensator zur Anwendung in Raumschiffen entwickelt werden. Die Anwendung muss nach ISO 9001 und SPICE Level 3 an einem Standort in Westeuropa erfolgen. Es muss ein Resident Engineer vor Ort beim Kunden sein, der bei Problemen innerhalb von einer Stunde am Testplatz sein kann. > 2. Was in Software Requirements Über die Weckleitung muss ein Interrupt ausgelöst werden, der die Subtask DO_HANDLE_THIS_SHT aufruft. Die Latenz darf maximal 124 µs betragen. Der Zustandsübergang von _charge__ zu __run_ erfolgt bei den Triggern X, Y, Z. > 3. Was in Hardware requirements Es ist ein Arduino zu verwenden. Die Anbindung an das Bordnetz muss über einen SBC aus der Verwendungsliste MBN0815 erfolgen. Es dürfen nur Keramikkondensatoren mit fail-safe Struktur oder flexibler Terminierung verwendet werden.
Soul E. schrieb: >> 3. Was in Hardware requirements > > Die Anbindung an das Bordnetz muss über einen SBC aus der > Verwendungsliste MBN0815 erfolgen. Es dürfen nur Keramikkondensatoren > mit fail-safe Struktur oder flexibler Terminierung verwendet werden. Nein, das sind keine Requirements, das sind schon Implementierungsdetails. Wobei ich geneigt solchen Sätzen wie "Kondensatoren mit fail-safe Struktur und Terminierung" die Bewertung "ungequirlter bullshit" zu geben.
Fpgakuechle K. schrieb: > Nein, das sind keine Requirements, das sind schon > Implementierungsdetails. Es kann sein, dass es im Bereich des Designs liegt, also Implementierungsdetail ist. Es kann aber auch genauso gut sein, dass dies eine Vorgabe des Kunden ist, interne Vorgaben oder durch eine Norm. Das Beispiel von Soul E ist einfach verdammt gut und vielseitig > Wobei ich geneigt solchen Sätzen wie "Kondensatoren mit fail-safe > Struktur und Terminierung" die Bewertung "ungequirlter bullshit" zu > geben. Kann sein, aber es entspricht der tagtäglichen Realität. A. S. schrieb > Das Beispiel von Soul E ist einfach verdammt gut und vielseitig
Fpgakuechle K. schrieb: > Nein, das sind keine Requirements, das sind schon > Implementierungsdetails. Und Anforderungen an die Implementierung sind für Dich keine Requirements? In jedem Fall sind es Anforderungen, deren Umsetzung zu dokumentieren und über Testfälle bzw Reviews durchgängig nachzuweisen sind. In DOORS werden diese Anforderungen auch als Requirements behandelt. > Wobei ich geneigt solchen Sätzen wie "Kondensatoren mit fail-safe > Struktur und Terminierung" die Bewertung "ungequirlter bullshit" zu > geben. Für jemanden, der vom Fach ist, sind das aber relativ eindeutige Bezeichnungen. Fail-safe bedeutet dass die Schichtung der Kondensatoren in der Mitte unterbrochen ist, so dass ein einzelner Riss (flex crack) keinen Kurzschluss verursachen kann. "Soft Termination" bzw "erhöhte Biegefestigkeit" beschreibt eine Zwischenschicht unter den Elektroden, die die Lötanbindung etwas flexibler gestaltet.
A. S. schrieb: > Das Beispiel von Soul E ist einfach verdammt gut und vielseitig > >> Wobei ich geneigt solchen Sätzen wie "Kondensatoren mit fail-safe >> Struktur und Terminierung" die Bewertung "ungequirlter bullshit" zu >> geben. > > Kann sein, aber es entspricht der tagtäglichen Realität. > > A. S. schrieb >> Das Beispiel von Soul E ist einfach verdammt gut und vielseitig ??? selbstbezügliches Zitat??? Naja, auch bullshit lässt sich topen. Ich glaub, sowas kommt von sowas: https://www.golem.de/news/software-entwicklung-aneinander-vorbeireden-2009-150711.html Hier wären passende requirements (Auszug): Req-abc: Die verwendeten Bauteile müßen den aktuellen Stand der Technik entsprechend. Req-abc: Die Verfügbarkeit dieser Bauteile ist über x Jahre geährleistet. Req-abc: Es muss mindestens eine zweite Lieferquelle (2nd Source) vorhanden sein. Req-abc: Externe Software wie Bibliotheken dürfen nicht verwendet werden. Req-abc: Es sind Schutzmassnahmen gegen Überspannung von Bordnetz vorzusehen. Info-abc: Schutzmassnahmen verhindern die Zerstörung der Komponenten und verhindern eine Propagation der Störgröße in weitere Komponenten. Schutzmassnahmen wirken in beide Richtungen. ---- Es liegt am Harware-Entwickler, nicht am Requirementsautor, eine Schaltung auszuwählen die auf die Requirements passt. Ferner ist nachzuweisen, das die Implementierung auch die Requirements erfüllt. Eine Implmentierung mit der man keine oder nur schlecht eine Verifizierung durchführen kann ist nicht akzeptabel. -- Wobei der Versuch, Requiremqnts an herausgerissenen Beispielen erklären zu wollen ohnehin fragwürdig ist. Der bessere und schnellere Weg führt über Schulungen resp. Lehrbücher wie ISBN: 978-3-86490-562-9
Soul E. schrieb: > Für jemanden, der vom Fach ist, sind das aber relativ eindeutige > Bezeichnungen. Fail-safe bedeutet dass die Schichtung der Kondensatoren > in der Mitte unterbrochen ist, so dass ein einzelner Riss (flex crack) > keinen Kurzschluss verursachen kann. "Soft Termination" bzw "erhöhte > Biegefestigkeit" beschreibt eine Zwischenschicht unter den Elektroden, > die die Lötanbindung etwas flexibler gestaltet. Nicht in diesem Universum. Terminierung bedeutet eine Anpassung an die Impedanz. Fail-safe bedeudet lediglich das eine einzelne Störgröße katastrophale Folgen hat. Wie ein Riß zu einem Kurzschluß statt zu einem offenen Stromkreis führen soll ist auch völlig unklar und auch ein weiteres Indiz in Richtung "ungequirlter Bullshit". Requirements sind eher nicht Fachchinesisch zu verfassen, sondern in einer Sprache die alle beteiligten Seiten verstehen. Hier also *Der die Reqs erstellende Systemarchitekt, der Beschreibt welche Störgrößen im System auftreten können und was die Komponente funktional tun soll *der die Reqs lesende Hardware-designer, der anhand seines Fachwissens Bauteile/Schaltungen auswählt die die geforderten Funktionen erfüllen *der aus den Reqs Prüfungen ableitende Verifikant, der einen Test/Messung aufstellt, mit dem nachgewiesen wird, daß das was der Hardware-designer implementiert hat, auch das erfüllt was der System-Architekt in den Requirements gefordert hat.
In der Praxis macht der Requirements-Autor meist eine Copy&Paste-Job, in dem er das Lastenheft der Vorgängerkomponente, die von der Normung bereitgestellten Dokumentvorlagen und die seiner Meinung nach relevanten Teile aus mitgeltenden Dokumenten zusammenkopiert. Redundanzen und Widersprüche sind da nicht unüblich. Zusätzlich werden dann bereits auszugweise eingebundene mitgeltende Dokumente nochmal als vollständig verbindlich herangezogen. Auch Implementierungsdetails bis hin zu Schaltplanauszügen sind gängige Praxis. Eigentlich schadet sich der Kunde damit selber, weil er den Lösungsraum zu seiner Aufgabe unnötig einschränkt. Bauteilverantworliche sind heute aber nur noch selten Techniker, die meisten BTV kommen aus der QS oder haben kaufmännischen Hintergrund.
Fpgakuechle K. schrieb: > Nicht in diesem Universum. > Terminierung bedeutet eine Anpassung an die Impedanz. Bullshit. Für jemanden der beruflich Hardware entwickelt (und Keramikkondensatoren verbaut) ist das eine eindeutige Bezeichnung. http://www.avx.com/products/ceramic-capacitors/surface-mount/automotive-mlcc-with-flexiterm/ > Fail-safe bedeudet lediglich das eine einzelne Störgröße katastrophale > Folgen hat. Wie ein Riß zu einem Kurzschluß statt zu einem offenen > Stromkreis führen soll ist auch völlig unklar und auch ein weiteres > Indiz in Richtung "ungequirlter Bullshit". Auch das ist für professionelle HW-Entwickler im Zusammenhang mit MLCC ein feststehender Begriff. https://www.elektroniknet.de/e-mechanik-passive/anspruchsvolle-automotive-applikationen-169714.html > Requirements sind eher nicht Fachchinesisch zu verfassen, sondern in > einer Sprache die alle beteiligten Seiten verstehen. (...) Komm Du mal im Berufsleben an... Ich würde Dich gerne zu unseren Kunden schicken, damit Du denen mal erklärst wie man richtig Lastenhefte schreibt. Das würde an anderer Stelle massenhaft Arbeitszeit einsparen. Das Leben ist kein Ponyhof, die Kunden schreiben keine anständigen Anforderungen in ihre Lastenhefte. Punkt. Wem's nicht passt, der braucht den Auftrag nicht annehmen. Leider hat man als Auftragnehmer da nicht viele Möglichkeiten der Einflußnahme.
Soul E. schrieb: > In der Praxis macht der Requirements-Autor meist eine Copy&Paste-Job, in > dem er das Lastenheft der Vorgängerkomponente, die von der Normung > bereitgestellten Dokumentvorlagen und die seiner Meinung nach relevanten > Teile aus mitgeltenden Dokumenten zusammenkopiert. Redundanzen und > Widersprüche sind da nicht unüblich. > > Auch Implementierungsdetails bis hin zu Schaltplanauszügen sind gängige > Praxis. Eigentlich schadet sich der Kunde damit selber, weil er den > Lösungsraum zu seiner Aufgabe unnötig einschränkt. Genau, deshalb erklärt man ja auch die 'Gängige' Praxis nicht zur Norm, sondern sorgt dafür, das die Norm zur gelebten Praxis wird. Es ist halt ein Unterschied, ob man einen Fertigungs- oder einen Entwicklungsauftrag verfasst. Man ist wohl eher gewöhnt Fertigungsaufträge/Arbeitsanweisungen zu verfassen, also genau zu sagen welche Teile der 'Fertiger' zu verwenden hat, anstatt ihm die Freiheit zu überlassen selbst nach seiner Erfahrung Lösungen auszuwählen. Weil das ja bedeutet, das man dem 'Fertiger' gegenüber Wissenslücken einräumt und dennoch ihm Verantwortung überlässt.
Soul E. schrieb: > Fpgakuechle K. schrieb: > >> Nicht in diesem Universum. >> Terminierung bedeutet eine Anpassung an die Impedanz. > > Bullshit. Für jemanden der beruflich Hardware entwickelt (und > Keramikkondensatoren verbaut) ist das eine eindeutige Bezeichnung. > http://www.avx.com/products/ceramic-capacitors/surface-mount/automotive-mlcc-with-flexiterm/ Nein, Terminierung bedeudet für einen Hardwareentwickler zuerst Abschlusswiderstand: https://en.wikipedia.org/wiki/Electrical_termination >> Fail-safe bedeudet lediglich das eine einzelne Störgröße katastrophale >> Folgen hat. Wie ein Riß zu einem Kurzschluß statt zu einem offenen >> Stromkreis führen soll ist auch völlig unklar und auch ein weiteres >> Indiz in Richtung "ungequirlter Bullshit". > > Auch das ist für professionelle HW-Entwickler im Zusammenhang mit MLCC > ein feststehender Begriff. Nein, das ist die Bedeutung von Fail-Safe: https://de.wikipedia.org/wiki/Fail-Safe > Komm Du mal im Berufsleben an... Naja berufsleben habe ich Altertechnisch grösstenteils hintermir, wohl ganz im Unterschied zu dir ...
Fpgakuechle K. schrieb: > Nein, das ist die Bedeutung von Fail-Safe: Ich verstehe Deinen Einsatz hier nicht so ganz. Da liefert jemand ein gutes Beispiel, mangels Kontext natürlich nicht allgemeingültig, und Du reitest auf Begriffen oder Definitionen rum, die in Deinem Umfeld vielleicht ja eng umrissen sind, in anderen Feldern aber durchaus anders konnotiert sein können. Wie soll ein allgemeines Beispiel denn konkret sein? Und wieso sollte es eine harte Grenze zwischen Implementierungsdetail und Anforderung geben? Wenn meine Kumpel 98nF Cs in 0804 (sic!) fertigt, dann kann ich meinem Entwickler vorgeben, nur diese Cs zu verwenden, wenn funktional ein C im Bereich von 10nF bis 500nF benötigt wird.
A. S. schrieb: > Fpgakuechle K. schrieb: >> Nein, das ist die Bedeutung von Fail-Safe: > > Ich verstehe Deinen Einsatz hier nicht so ganz. Da liefert jemand ein > gutes Beispiel, mangels Kontext natürlich nicht allgemeingültig, und Du > reitest auf Begriffen oder Definitionen rum, die in Deinem Umfeld > vielleicht ja eng umrissen sind, in anderen Feldern aber durchaus anders > konnotiert sein können. Gegenfrage: Warum sollte ich Dir gegenüber begründen warum ich die Frage des TO aus meinem Erfahrungshintergrund als Hardwareentwickler so beantworte wie ich sie beantworte und nicht anders?! Um eben Fehler zwischen abteilungsspezifische Umdefinitionen zu vermeiden, formuliert man Anforderungen erst mal allgemein und überlässt es der beauftragten Abteilung zu entscheiden wie sie diese Funktion implementiert. Vielleicht sind sie ja der Meinung/Erfahrung das diese spezialbruchkondensatoren das Problem einer gegenüber Beschädigung Kurzschluss gesicherten Komponente nicht wirklich löst, die klassische Polyfuse dagegen schon. > Und wieso sollte es > eine harte Grenze zwischen Implementierungsdetail und Anforderung geben? Weil das eine (Reqs) die Eingangsgröße des Prozesses "Entwicklung" ist, und das andere (Implementierung) das Ergebniss dieses Prozesses. Jeder Prozess wird durch Eingangs- und Ausgangsgrößen definiert, alles andere führt zu 'unsauberen'/ungewollten Produkten. https://www.pm-profi.de/wp-content/uploads/Projekt-Schaukel-2-e1407864838103.jpg https://t2informatik.de/wissen-kompakt/requirements-engineering/ > Wenn meine Kumpel 98nF Cs in 0804 (sic!) fertigt, dann kann ich meinem > Entwickler vorgeben, nur diese Cs zu verwenden, wenn funktional ein C im > Bereich von 10nF bis 500nF benötigt wird. Klar kann man das, das steht aber im Widerspruch zu jeden Standardisierungsbemühungen, also möglichst wenig verschiedene Werte aus handelsüblichen Produktreihen zu verwenden. Und wie bereits gesagt, es ist ein Unterschied ob man eine Entwicklungsaufgabe oder eine Fertigung beauftragt.
Nun, da ich nicht aus Kundenlastenheften zitieren darf, sind die oben genannten Sätze alle verfremdet. Der Grundgedanke sollte aber trotzdem erkennbar sein. Die Beispiele sind alle aus der Praxis, nicht aus irgendwelchen Lehrbüchern. Lustig ist halt, dass ausgerechnet die Anforderung mit den MLCC mit Soft Termination Diskussionen auslöst, denn die tauchte bisher mehr oder weniger wortwörtlich in jedem Projekt auf.
Fpgakuechle K. schrieb: > Gegenfrage: Warum sollte ich Dir gegenüber begründen warum ich die Frage > des TO aus meinem Erfahrungshintergrund als Hardwareentwickler so > beantworte wie ich sie beantworte und nicht anders?! ??? Wenn Du sowas machst, hat doch keiner was dagegen. Darum geht es hier aber nicht: Du hast eine sehr gute Antwort als falsch dargestellt und korrigiert. Dafür sollte man schon sehr gute Gründe haben, nicht nur einfach andere Erfahrungen und ein selbstgezimmertes Ideal, wie etwas sein sollte
Das ein Auftraggeber technische Details der Umsetzung vorgibt, ist zwar oft Blödsinn aber dennoch üblich. Als Entwickler sollte man solche Vorgaben ernst nehmen. Der Auftraggeber wird die "perfekte" Lösung nämlich völlig anders bewerten, wenn sie nicht seinen Vorgaben entspricht.
Soul E. schrieb: > Lustig ist halt, dass ausgerechnet die > Anforderung mit den MLCC mit Soft Termination Diskussionen auslöst, denn > die tauchte bisher mehr oder weniger wortwörtlich in jedem Projekt auf. Ich finde das eher traurig, das etwas, was immer wieder Diskussionen hervorruft unverändert (wortwörtlich) in jedem Projekt als Requirement auftaucht. Ein Requirement sollte allgemein verständlich sein und ein Lösungsvorschlag nachvollziehbar - können wir uns darauf einigen?! Ich verstehe es jetzt so, das in der Systembeschreibung ausfallsicher also 'failure Safe' steht. Das verstehe ich jetzt so, das " if and when a "fail-safe" system fails, it remains at least as safe as it was before the failure." (siehe wikipedia). Als Lösungsvorschlag werden jetzt Kerkos mit Sollbruchstelle und weicher Terminierung vorgeschlagen. Unter "weicher Terminierung" kann sich wohl viele was vorstellen, aber jeder was anderes. Deshalb ist das zu erklären. Dann ergibt sich natürlich auch die Frage das, wenn man Schäden durch Bruch erwartet, warum man überhaupt keramische also wenig bruchfeste Bauteile nimmt und nicht Plastik/Folien-C's auswählt? Ohne grundsätzliche Erklärung für Kerkos (Kosten, Volumen, Hitzefestigkeit) trotz deren Nachteile bleibt die Entscheidung für Kerko nicht nachvollziehbar. Und es bleibt die Frage ob Bruch das einzige Ausfallszenario an dieser Stelle ist. IMHO ist es das nicht , es verbleiben u.a. das Szenario Überschlage durch Überspannung, begünstigt durch Verschmutzung und Alterung. Es wird also ein Bauteil als "Fail safe" bezeichnet, was es genaugenommen nur zum Teil ist. Ein Requirement muss nicht inhaltlich falsch, um wenig brauchbar zu sein, es genügt, wenn es un- oder missverständlich ist. Wenn das passiert, dann sollte man wenigstens eine INFO-box und oder eine Begriffserklärung hinzufügen. So wird es jedenfalls in den Lehrtexten zum Requirements-engineering vorgeschlagen. Man kann ja auch mal den Ernstfall durchspielen. Also das Modul fällt aus und es werden Stromschäden an benachtbarten Baugruppen festgestellt. Die Hardware-abteilung zuckt dann nur mit den Schultern und verweist, das sie sich ganz an die Requirements gehalten haben, die Fehlersucher sollen sich also an den Requirementsautor halten. Man hat zwar dem Autor gegenüber darauf hingewiesen, das man nicht verstanden hat, warum man diese Kerkos einsetzen musste, aber es wurde einem auch nicht erklärt. Folglich verabschiedet sich die Hardwareabteilung an dieser Stelle aus dem Prozess der Fehlersuche und Konstruktionsverbesserung ... PS: mag sein das man es in anderen Branchen (z.b. medizintechnik, Luftfahrt) geübter ist 'gute' Requirements zu formulieren, weil man mehr gezwungen ist gegenüber externen (Zertifizierungsstelle) seinen Entwicklungsprozess und Entscheidungen nachvollziehbar offen zu legen.
Ich habe gerade ein Projekt, wo ich Notifizierungen aus einer ActiveMQ Warteschlange abarbeiten soll. Manchmal kommen die Notifizierungen zu früh, und dazu gibt es ganz spezifische Anfordern, wie lange diese nochmal für einen späteren Retry zurück gestellt werden sollen. Der Gag dabei ist, dass dabei Eigenschaften gefordert wurden, die von der vorgeschriebenen ActiveMQ Version gar nicht bereit gestellt werden. Also sind wir gerade ganz kurz davor, hinter diese Queue eine weitere selbst gebaute Queue zu stellen, die das alles wie gefordert macht. Aber eigentlich hatten die Anforderungen den Einsatz einer eigenen Queue generell verboten. Was solls? Ich bin es schon mehr als mein halbes Leben lang gewohnt, das unmöglich möglich zu machen. Wenn es am Ende wie gewünscht funktioniert, schaut sowieso keiner mehr unter die "Motorhaube". Man frickelt sich halt durch. Irgendwann fliegt der Menschheit diese ganze Technik-Scheiße dermaßen von um die Ohren, weil keiner mehr durch blickt. Ich glaube, die Leute, die wieder Schallplatten kaufen, sind auf dem richtigen Weg.
Fpgakuechle K. schrieb: > Ich verstehe es jetzt so, das in der Systembeschreibung ausfallsicher > also 'failure Safe' steht. Das verstehe ich jetzt so, das " if and when > a "fail-safe" system fails, it remains at least as safe as it was before > the failure." > (siehe wikipedia). > Als Lösungsvorschlag werden jetzt Kerkos mit Sollbruchstelle und weicher > Terminierung vorgeschlagen. Nein. Die Anforderung ist, "wenn Du Keramikkondensatoren an KL30 einsetzt, dann müssen diese zwingend und nachweislich die Produktmerkmale "failsafe" oder "soft termination" aufweisen". Was diese Eigenschaften im Zusammenhang mit Keramikkondensatoren bedeuten ist eindeutig definiert und diese Begriffe sind auch jedem bekannt, der sich mit ausfallsicheren Keramikkondensatoren beschäftigt. Dass diese Begriffe in anderem Kontext andere Bedeutung haben ist sicherlich richtig. Darum ging es hier aber nicht. > Und es bleibt die Frage ob Bruch das einzige Ausfallszenario an dieser > Stelle ist. (...) Sicher. Um seine individuelle Gefahrenanalyse kommt man nicht herum, nur weil der Kunde an Einzelbauteile bestimmte Anforderungen stellt. Trotzdem sind diese Anforderungen für sich zu erfüllen, sonst gibt es keine Freigabe. > Ein Requirement muss nicht inhaltlich falsch, um wenig brauchbar zu > sein, es genügt, wenn es un- oder missverständlich ist. Wenn das > passiert, dann sollte man wenigstens eine INFO-box und oder eine > Begriffserklärung hinzufügen. So wird es jedenfalls in den Lehrtexten > zum Requirements-engineering vorgeschlagen. Sicher richtig. Es wäre ja schon toll wenn derjenige, der das Lastenheft zusammenkopiert, wüsste was seine Requirements eigentlich bedeuten. > Man kann ja auch mal den Ernstfall durchspielen. Also das Modul fällt > aus und es werden Stromschäden an benachtbarten Baugruppen festgestellt. > Die Hardware-abteilung zuckt dann nur mit den Schultern und verweist, > das sie sich ganz an die Requirements gehalten haben, (...) Da geht der Trend hin. Früher schickte der Kunde eine Skizze und eine Worddatei als Lastenheft, mit einer ungefähren Beschreibung was er so haben will. Und mit Hinweisen wie "macht mal wie bei Euch üblich, so hat es sich ja bewährt". Daraufhin hat man ein paar A-Muster gebaut und die dem Kunden geschickt. Der hat sich die Teile angeschaut, ein paar Änderungswünsche geäußert, und dann lieft die Sache. Heute haben wir Requirements Management. Das Lastenheft wird Zeile für Zeile analysiert, TITLE, ANNOTATION oder REQUIREMENT. Für jede Anforderung wird ein Umsetzungsverantwortlicher, ein Testfall und ein Testverantwortlicher definiert. Und wenn alles umgesetzt ist und getestet, dann ist man fertig. Ob das Produkt dann funktioniert oder nicht ist Nebensache.
Soul E. schrieb: > Fpgakuechle K. schrieb: > >> Ich verstehe es jetzt so, das in der Systembeschreibung ausfallsicher >> also 'failure Safe' steht. Das verstehe ich jetzt so, das " if and when >> a "fail-safe" system fails, it remains at least as safe as it was before >> the failure." >> (siehe wikipedia). >> Als Lösungsvorschlag werden jetzt Kerkos mit Sollbruchstelle und weicher >> Terminierung vorgeschlagen. > > Nein. Die Anforderung ist, "wenn Du Keramikkondensatoren an KL30 > einsetzt, dann müssen diese zwingend und nachweislich die > Produktmerkmale "failsafe" oder "soft termination" aufweisen". Naja Requirements werden aber in der Regel von jemanden geschrieben, der sich nicht mit Kerkos auskennt und dem diese völlig egal sind. Ich mein, der Entwurf geht durch verschiedene Abstraktionsebenen. Zuerst wird das Produkt beschrieben; was kann es, was soll es aushalten. Dann kommen die verschiedenen Fachbereiche und stellen für ihren Bereich die Reqs so auf, das die übergeordneten Reqs erfüllt sind. > Was diese > Eigenschaften im Zusammenhang mit Keramikkondensatoren bedeuten ist > eindeutig definiert und diese Begriffe sind auch jedem bekannt, der sich > mit ausfallsicheren Keramikkondensatoren beschäftigt. In dem angemoserten Beispiel wird aber nicht der Begriff "soft termination" verwendet, sondern, Zitat: >Es dürfen nur Keramikkondensatoren mit fail-safe Struktur oder flexibler Terminierung verwendet werden. Und unter 'flexible Terminierung' versteht man aber nicht zwangsläufig das selbe wie "soft termination". Besser beim (google-baren) Originalbegriff bleiben, um nicht unnötige Verwirrung zu stiften Und lt. Recherchen ist die ursprüngliche erforderliche Eigenschaft die Biegefestigkeit. Für PCB's die keiner mechanischen Belastung ausgesetzt sind, die zu einer vertikalen Auslenkung von 1.. 2 mm führen (je nach Bauform) ist ein Req. wie oben sinnfrei. Eine IMHO sinnvolle Formulierung wäre daher: Req abc: Vertikale Auslenkungen bspw. durch Vibration bis zu xyz mm dürfen nicht zu system fails durch Kerko-interne Kurzschlüße führen. Idealerweise gekoppelt mit der Info das diesem Req durch die Bestückung mit SMD-Kerkos mit der speziellen Eigenschaft Genüge getan ist. Dann hat auch der Verifikant eine Idee wie er dieses Req. am finalen Produkt testet (Rütteltisch o.ä.). Und dann wird auch klar, warum und unter welchen Bedingungen man ausserhalb automotive, also orstfeste Maschinen, auf dieses Req verzichten kann. Oder auf was man im Rahmen der Obsoloszenzenbeseitigung man achten muß, wenn die speziellen Bauteile nicht mehr lieferbar sind. Oder was man am Labormuster (das aus Verfügbarkeitsgründen) mit anderen Kerkos bestückt wurde testen kann und was nicht. Für ein Target das die Softwareabteilung in hunderterserie für die Entwicklung im Office braucht, ist es grad egal.
A. S. schrieb: > Und wieso sollte es > eine harte Grenze zwischen Implementierungsdetail und Anforderung geben? Anbei Scan aus ISBN: 978-1-4822-0605-0 Darin wird beschrieben wie passende Requirements zu schreiben sind, hier speziell nach Standard DO-254 (Entwicklung digitalelektronik Luftfahrt). Zitat:"Define functionality, not implementation. The Req. should focus on what the hardware does, not how it does it."
Fpgakuechle K. schrieb: > Zitat:"Define functionality, not implementation. The Req. should focus > on what the hardware does, not how it does it." Dir sollte doch inzwischen klar sein, dass ich so etwas weiß. Meine Frage war nicht, wo man Anforderung und wo Implementierung macht, sondern warum Du genau definieren kannst, wo die Grenze dazwischen verläuft. Oder welchen Hinweis es gibt, dass es überhaupt eine definierte Grenze gibt. Beispiele hatte ich genannt.
Soul E. schrieb: > In der Praxis macht der Requirements-Autor meist eine Copy&Paste-Job, in > dem er das Lastenheft der Vorgängerkomponente, die von der Normung > bereitgestellten Dokumentvorlagen und die seiner Meinung nach relevanten > Teile aus mitgeltenden Dokumenten zusammenkopiert. Redundanzen und > Widersprüche sind da nicht unüblich. Zusätzlich werden dann bereits > auszugweise eingebundene mitgeltende Dokumente nochmal als vollständig > verbindlich herangezogen. Genau so sieht's nämlich aus. Weit über 90% der ganzen super-wichtigen Dokumente, die der ach so wichtige Kunde auf den Tisch knallt, sind zusammen kopierte Scheiße aus unterschiedlichsten Quellen. Von völlig sinnfreien Formulierungen, über unterschiedliche Text-Formatierungen, Widersprüche, Referenzierungen auf fremde Unternehmen, Bezüge auf längst zurückgezoge Normen und nicht mehr lieferbare Bauteile, Illustrationen die nicht zum Text passen, etc., alles dabei. Meiner Meinung nach ist das alles nur der Versuch, die Verantwortung möglichst weit wegschieben zu können, und am Ende wundern sich alle, dass die Projekte immer schlechter laufen. Keiner hat mehr die Eier zu sagen, wie es gemacht wird, und keiner hat die Eier zu sagen, passt so. So langsam wundert es mich immer mehr, dass bei diesem Wahnsinn überhaupt noch etwas funktionierendes rauskommt das nicht bei der erst besten Gelegenheit in seine Einzelteile zerfällt. Ganz lustig mit dem Papierblödsinn wird es im Medizin und Pharma-Bereich. Da werden im vollem Bewusstsein Fehler hingenommen oder Blödsinn umgesetzt, weil, ist ja validiert. Ganz lustig wird's bei Software: Zeigt das erstellte Protkoll-PDF den Text "Ok" an, ist alles bestens. Egal ob der Wert stimmt. Steht ja da, es wäre in Ordnung. Aber wehe, der dargestellte Wert ist korrekt, aber keine Auswertung "IO / NIO" dahinter. Weltuntergang. Der totale Wahnsinn. Reale Korrektheit spielt immer weniger eine Rolle, sofern ein Papier existiert, in dem steht, es muss so sein.
Fpgakuechle K. schrieb: > Zitat:"Define functionality, not implementation. The Req. should focus > on what the hardware does, not how it does it." Im Automobilbereich ist das anders. Da gibt es Ausführungsvorschriften für Schaltungsteile, Freigabelisten für Bauteile, Designvorgaben für die Aufbau- und Verbindungstechnik und Codierrichtlinien für die Software.
Bitte 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.