frage zu requirement engineering

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.