requirements engineering

Gast #6305347
Lesenswert?

Hi

Für unsere Scheibenwischer Motorsteuerung basiernd auf LIN soll ich 
Firmware requirements schreiben.
Mein Kunde hat mir paar Anforderungen geschrieben wie: verschiedene 
Geschwindigkeiten des Wischers,paar auszulesende Counter ++.

Ich habe die Kundenanforderungen eins zu eins als Firmware 
Anfiorderungen kopiert.
Ist das richtig?

Was gehört da sonst noch hin?
Danke
Gast #6305379
Lesenswert?

Requirements Engineering ist nichts anderes als 
Lastenheft/Pflichtenheft. Aber weil das kaum einer der Pappnasen in dem 
ganzen Auftragnehmer-Auftraggeber-Kindergarten kapiert, schmückt sich 
jeder mit diesem Begriff und so wird nun diese Sau RE durch die Büros 
getrieben und alle gucken wichtig dazu.
Gast #6305427
Lesenswert?

Bastler schrieb:

> Requirements Engineering ist nichts anderes als
> Lastenheft/Pflichtenheft.

Im Prinzip schon. Aber damit die Pappnasen auch richtig dolle was zu tun 
haben gibt es jetzt DOORS, Enterprise Architect und SPICE Level 
3-Zertifizierungen. So ein olles Worddokument mit einem Blockschaltbild, 
einer Beschreibung der Funktionen und der durchzuführenden Tests war 
zwar praktischer, aber so schafft es deutlich mehr Bullshit-Jobs.

Und ja, ohne Grundkenntnisse macht man da gar nichts. Zumindest nicht so 
dass einen der Kunde oder der externe Auditor nicht komplett 
auseinandernimmt. Und dann machst Du die Arbeit doppelt, und die Zeit 
hättest Du auch in ein Seminar investieren können.
Gast #6305524
Lesenswert?

Soul E. schrieb:
> Aber damit die Pappnasen auch richtig dolle was zu tun
> haben gibt es jetzt DOORS,

Haha, genau!

Mir hat mal ein neuer, fachfremder Vorgesetzter erklärt, mit DOORS 
werden alle Requirements erfasst, und dann muss man nur noch auswählen, 
was man haben möchte, und das Tool erstellt die Software automatisch. So 
hätten sie es in seiner alten Firma gemacht...

Das schlimme daran: Der meinte das ernst.

Das gute daran: Er ist weiter gezogen.
#6305586
Lesenswert?

Der Trick beim Aufschreiben der Anforderungen ist einfach nur der, daß 
der Entwickler damit ohne jede Rückfrage das Projekt fertigstellen kann.

Leider wird oft nur um den heißen Brei geredet. Z.B. bei "verschiedene 
Geschwindigkeiten" muß der Entwickler erst nachfragen, welche Werte 
konkret.
Der Rückfrageaufwand kann dadurch nicht selten die eigentliche 
Entwicklungszeit um ein Vielfaches übersteigen.
#6305598
Lesenswert?

Tilo schrieb:
> Ich habe die Kundenanforderungen eins zu eins als Firmware
> Anfiorderungen kopiert.
> Ist das richtig?
>
> Was gehört da sonst noch hin?

Der Kunde wird Dir in der Regel eher funktionale Anforderungen nennen. 
Was er Dir eher nicht sagen wird:

-Was Du laut gängiger Norm alles einhalten musst
-Welche sonstigen, z.B. auch nichtfunktionalen Anforderungen es an das 
Subsystem gibt (z.B. wie lange darf der Controller mit der Firmware zum 
Hochfahren brauchen, wie soll das Ausfallverhalten sein wenn es z.B. 
Probleme mit der Versorgungsspannung gibt, etc.)
Gast #6305621
Lesenswert?

Tilo schrieb:
> Ich habe die Kundenanforderungen eins zu eins als Firmware
> Anforderungen kopiert.
> Ist das richtig?

Bevor man das bauen/programmieren kann, muss man die Anforderungen 
detailliert und unmissverständlich haben. Ausdrücke wie "ein paar", 
"sollte", "könnte", "hätte gerne" sind dann tabu.

Ich würde Dir empfehlen, Test-Kriterien zu verfassen. Dazu der Hinweis: 
Wenn alle obigen Tests bestanden sind, dann ist das Produkt einwandfrei. 
Lass Dir dieses Dokument vom Kunden unterschreiben.

Ich wette, denen werden ganz plötzlich viele weitere Test-Kriterien 
einfallen.

Wenn die dann nachher ein zu kurzes Kabel monieren, aber im Dokument 
nicht drin stand, welche Kriterien das Kabel erfüllen muss, dann haben 
sie einfach Pech. Ein anderes Kabel kann gerne gegen Aufpreis 
nachgerüstet werden.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren