Hallo,
ich muss auf Geräte- und Baugruppenebene Spezifikationen schreiben.
HRS, SRS, SSS.
Kennt jemand gute Templates die nicht zu akademisch sind?
Wenn ich vergleichbare Dokumente suche, dann ist da teilweise echter
Murks bei. Da wird entweder ganz grob oder total detailliert
spezifiziert. Teilweise fragt man sich auch wie man das jemals
nachweisen will.
Hat ihr auch jemand Literaturempfehlung.
Das meiste im Requirement Engeneeringvkommg aus der Software. Ich habe
jedoch mehr mit Hardware oder embedded Programmierung zu tun. Da wirken
viele Ansätze zu Larifari.
Viele Grüße
Freddy schrieb:> Teilweise fragt man sich auch wie man das jemals> nachweisen will.
Parallel zu den Spezifikationen auch gleich den Verifikationsplan
schreiben und verlinken (Bei uns Beispielsweise beides zusammen in
DOORS). Dann ist sichergestellt, dass ein Requirement etwas fordert,
dass auch überprüft werden kann.
Wie mit vielem im Ingenieurwesen, wo es zwar um harte Fakten und Physik
geht, ist das schreiben von guten Spezifikationen eine eigene Kunst.
Also üben üben üben. (Bin hier selber noch unerfahren genug).
Hi,
mein Problem ist, dass ich genügend Beispiele und Literatur für
Requirement Engeneering für Software finde.
In dem Bereich kann ich die Ansätze von Req.Eng. ganz gut
nachvollziehen.
Und ja, wenn man weiß wie man die Anforderungen testen und verifizieren
soll dann ist allen dabei geholfen.
Im Hardwareansatz finde ich es schwieriger.
Ich soll per Req.Eng. Definition keine Lösung vorgeben, kann aber auch
nicht einfach nur schreiben:
Es muss eine Versorgungsspannung per Stecker zugeführt werden.
Wenn ich das so schreibe, habe ich je nach Entwickler von Drehtstrom,
USB bis zu Gardena alles dabei.
Freddy schrieb:> Hat ihr auch jemand Literaturempfehlung.
Du brauchst wohl auch ne Literaturempfehlung für die Verwendung von
Klopapier.
Mann kann es kaum glauben dass Deutschland mal führend in der
Ingenieurskunst war. Freddy kann aber sicher seinen Namen ganz toll
vortanzen scheitert aber schon am "Requirementengineering".
Früher hat man sowas in der Pause aufs Butterbrotpapier geschmiert und
es gab nicht mal nen Namen für sowas. Wenn einer angekommen wäre und
solche Fragen wie oben gestellt hätte, was für mich immer noch undenkbar
ist, hätte man den sofort rausgeworfen.
Freddy schrieb:> Im Hardwareansatz finde ich es schwieriger.> Ich soll per Req.Eng. Definition keine Lösung vorgeben, kann aber auch> nicht einfach nur schreiben:> Es muss eine Versorgungsspannung per Stecker zugeführt werden.>> Wenn ich das so schreibe, habe ich je nach Entwickler von Drehtstrom,> USB bis zu Gardena alles dabei.
Deshalb gibt es ja (Industrie)-Normen auf die man referenzieren kann und
muß.
Also beispielsweise:
die Komponente muss entsprechend der Niederspannungsrichtlinie
2014/35/EU versorgt werden. Oder ggf "Das Gerät muß konform nach DIN EN
61140 (Schutzkleinspannung) versorgt werden.
https://de.wikipedia.org/wiki/Richtlinie_2014/35/EU_(Niederspannungsrichtlinie)
Dazu kommen noch die üblichen Requirements wie Langzeitverfügbarkeit,
CE-Kennzeichen, raummaße, Standartisierte Gehäusesysteme, etc. pp. und
schon kommt da ein Profi-Gerät wie gewünscht raus ohne das man eine
konkrete Lösung vorgeben muß.
BTW:
Du solltest mal überlegen, ob es nicht besser wäre diese Aufgabe an
jemanden abzugeben, der die nötige Qualifikation (Entwicklung
elektrischer Geräte entsprechend gesetzlicher Vorgaben) hat und diese
nachweisen kann (passender Ausbildungs-/Studiumsabschluß). Also
Softwerker biste offensichtlich schon mit den 'Basics' überfordert.
Freddy schrieb:> Im Hardwareansatz finde ich es schwieriger.> Ich soll per Req.Eng. Definition keine Lösung vorgeben, kann aber auch> nicht einfach nur schreiben:> Es muss eine Versorgungsspannung per Stecker zugeführt werden.>> Wenn ich das so schreibe, habe ich je nach Entwickler von Drehtstrom,> USB bis zu Gardena alles dabei.
Dann war die Anforderung eben nicht spezifisch genug. Wenn Du nun
schreibst:
1.) Versorgungsspannung
1.1 Es muss eine Versorgungsspannung per Stecker zugeführt werden.
1.2 Die Spannung soll 230 Volt (+/- 10%) betragen mit einer Frequenz von
50 Hertz.
1.3 Der Stecker soll ein Kaltgerätestecker C13/C14 nach IEC-60320 sein.
dann wird ein Schuh draus.
Meiner Meinung nach ist Requirements Engineering ein Handwerk. Man lernt
es erst dann so richtig, wenn man es aktiv durchführt. Weil man dann auf
all die Probleme stößt, die sich in der Zusammenarbeit mit anderen
Kollegen, Abteilungen, Zulieferern etc. ergeben.
Stell Dir vor, Du müsstest nach den Anforderungen entwickeln, die Du
selbst schreibst. Welche Informationen bräuchtest Du?
Was muss man dem Entwickler vorgeben?
--> Das sind die harten Anforderungen, die erfüllt werden müssen.
Was kann oder darf der Entwickler selbst entscheiden?
--> Das sind die internen Details der Implementierung. Diese können im
Prinzip völlig beliebig sein, solange natürlich die Anforderungen
erfüllt sind.
Mark B. schrieb:> 1.3 Der Stecker soll ein Kaltgerätestecker C13/C14 nach IEC-60320 sein.>> dann wird ein Schuh draus.
Der zu verwendetet Stecker ergibt sich aber auch aus der IP-Schutzart
(Spritzwasser, Staub,...), Umgebungstemperatur, Vibrationen und
Leistungsaufnahme. Wenn man diese als Requirement vorgibt, brauch man
sich nicht selber durch die Steckerauswahl quälen.
Aber wahrscheinlich zählt der TO die Umweltbedingungen zum Larifari-Teil
der Requirements vor dem er sich gerne mittels dumben Kopieren eines
'Templates' drücken möchte.
IQ130+ schrieb:> Der zu verwendetet Stecker ergibt sich aber auch aus der IP-Schutzart> (Spritzwasser, Staub,...), Umgebungstemperatur, Vibrationen und> Leistungsaufnahme.
Richtig, auch sowas muss man vorgeben. Eine Maschine, die in einer
beheizten Fabrikhalle in Deutschland steht, muss wahrscheinlich keine
-20° Celsius aushalten können. ;-)
Mark B. schrieb:> Richtig, auch sowas muss man vorgeben. Eine Maschine, die in einer> beheizten Fabrikhalle in Deutschland steht, muss wahrscheinlich keine> -20° Celsius aushalten können. ;-)
In weiten teilen Deutschlands auch ausserhalb dieser Halle nicht,
Klimaerwärmung sei Dank. Weiss gar nicht mehr, wenn es zuletzt -20°C in
Kölle hatte, muss irgendwann im letzten Jahrhundert gewesen sein.
Der bekannte Dauerschwätzer Senf D. schrieb:> Im Jahr 2012 dürfte das der Fall gewesen sein.> https://www.n-tv.de/auto/Diesel-versagt-bei-extremer-Kaelte-article5430791.html
Nee, in Kölle definitiv nicht, das war damals ein Problem in Bayern und
Co... und da auch stark typabhängig.
https://www.wetterkontor.de/de/wetter/deutschland/rueckblick.asp?id=103&datum0=09.12.2011&datum1=02.02.2012&jr=2020&mo=12&datum=02.02.2013&t=8&part=2
Während der Diesel-Passat vom Ingenieur zwar etwas zickte beim Anfahren
aber sonst ruhig tuckerte, blieb der Techniker in seinem Ford irgendwo
auf der Strecke liegen. Liegt wohl auch daran, wie gut die
Treibstoffleitung vorm Wind und damit vorm Chill-Out geschützt ist.
Und dann wäre noch der Unterschied zwischen Betriebs- und
Lager/Transporttemperatur. Für beides gelten unterschiedliche
Requirements bezüglich der Umweltbedingungen. Und das kann auch in der
Elektronikentwicklung wichtig sein wenn man ein Gerät per Luftfracht
verschickt. Da hat sich schon mancher gewundert, was so der Unterdruck
und Temperatur in 11000m im nichtklimatisierten Frachtraum an Schäden
anrichtet.
Freddy schrieb:> Ich soll per Req.Eng. Definition keine Lösung vorgeben, kann aber auch> nicht einfach nur schreiben:> Es muss eine Versorgungsspannung per Stecker zugeführt werden.>> Wenn ich das so schreibe, habe ich je nach Entwickler von Drehtstrom,> USB bis zu Gardena alles dabei.
Dir fehlt kein Tool oder Template, sondern Erfahrung und Chuzpe.
Du kannst beim ersten Projekt auch alle Anforderungen ohne Doors & Co
mit einem Collegeblock erfassen. Ist halt nur mehr Arbeit.
Viel wichtiger ist es, selbst zu erfahren, warum die Verfahrensweisen so
sind, wie sie sind. Und so lange die Erfahrung fehlt, das als grobe
Richtung zu sehen.
Z.B. dein Einwand, Anforderungen sollen keine Lösung vorgeben: natürlich
nicht. Falls jemand das ganze ohne Strom oder mit Batterien hinkriegt,
super. Nur führt das zu nichts. Vor allem dann, wenn das nur interne
eine künstliche Schnittstelle zwischen 2 Kollegen ist.
Auf Deiner Seite (den Anforderungen) muss ein Kunde, ein Chef, ein
Designer oder inbetriebnehmer sein, der das Ding wirklich haben will und
weiss, was es können muss. Und mit dem kannst Du alles von außen
sichtbare durchgehen, was wo wie sein muss. Vom Kabel über die
Bedienelemente, tempbereich Stromverbrauch bis zur Gehäusefarbe. Ob es
vorgegeben oder egal ist, kritisch oder unkritisch.
Und andere machen später das wie, ob und welchen uC und welches OS. Und
Du bzw. Dein Kollege muss beide Seiten kennen und verhandeln: wird das
OS doch vorgegeben, weil die Entwickler sonst wieder Raumschiffe bauen?
Wird doch am RAL-Wert gedreht, in Verhandlung mit dem stakeholder, weil
es sonst zu teuer ist.
Die reine Lehre, einer wünscht, der andere liefert, ist Wunschdenken.
Und jemand könnte alle Anforderungen aufzählen, ... Lenkrad? Sie haben
ein Lenkrad nie erwähnt!
