Requirements Engineering, wie macht Ihr das?

[Matze (Gast)]

Hallo,

wie sind gerade dabei ein neues Gerät zu konzeptionieren.
- Viele Leute sprechen da mit
- Viele Inputs gibt es da

Wie sammelt Ihr sowas, um am Ende dann auch zu einem richtigen 
Anforderungskatalog zu kommen.

Bisher hatte ich das immer im Word oder Excel gemacht, gefällt mir aber 
nicht wirklich.

Was benutzt Ihr dazu?

Gruss
Matze

[Meta-Klaus (Gast)]

Das machen wir auch in Word. Wichtig ist halt ein Format, in dem man den 
Text mit Graphiken (z.B. UML-Modelle) zusammenbringt. Und da setzen alle 
Firmen, in denen ich bisher war, auf Word.

[Unbekannter (Gast)]

> Was benutzt Ihr dazu?

Papier und Farbstifte

[Gurke (Gast)]

http://freemind.sourceforge.net/wiki/index.php/Main_Page

Längere Texte dann als Textfiles dabei (und verlinkt)

[matze (Gast)]

freemind kenne ich, Nutzen wir auch um Ideen zu sammeln und zu 
strukturieren.

Ich dachte schon eher an ein Requirements Tool!

Matze

[Norgan (Gast)]

> Ich dachte schon eher an ein Requirements Tool!

Nur wenn du so richtig auf die K*cke hauen möchtest. Die sind teuer. 
Borland Caliber Analyst, Telelogic DOORS und Focal Point, und IBM 
Requisite Pro, um nur ein paar Namen zu nennen.

Und alle sind sinnlos - wenn man keine adäquate Methode verwendet. 
Zuerst kommt die Auswahl einer Methode, ein die auf das Umfeld passt und 
sich in die vorhandenen Abläufe einbinden lässt, dann erst die Auswahl 
eines Tools, welches die Methode unterstützt. Der SAP-Ansatz (Firma hat 
sich auf Teufel-komm-raus an die !@#$%^ Software anzupassen) taugt 
nichts. "Einfach eine lange Liste machen" ist auch keine Methode.

Die Methode sollte man verstehen. Man sollte in der Lage sein, die 
Methode zur Not nur mit Papier und Bleistift durchzuziehen, und, meine 
ganz persönliche Erfahrung, lieber etwas kleinere Brötchen bei der 
Methode backen, als sich mit Leib und Seele einer allumfassenden, 
vorgeblich heilsbringenden, den Hunger in der Welt beseitigenden und 
Frieden bringenden Methode verschreiben.

Ebenso zu vermeiden sind UML Use-Cases und deren Fanboys. Wer glaubt 
komplexe Anforderungen mit ein paar durch Striche verbundene Elipsen und 
Strichmännchen adäquat beschreiben zu können, hat sie einfach nicht mehr 
alle.

[Gast (Gast)]

lach

"Ebenso zu vermeiden sind UML Use-Cases und deren Fanboys. Wer glaubt
komplexe Anforderungen mit ein paar durch Striche verbundene Elipsen und
Strichmännchen adäquat beschreiben zu können, hat sie einfach nicht mehr
alle."

Ganz meiner Meinung! Sehr gut formuliert! ;-)

[Sebastian (Gast)]

Hallo.

Um es gleich vorwegzunehmen, ich arbeite in der Medizintechnik. Da wir 
sicherheitskritische Systeme bauen und dementsprechend Gesetze und 
internationale Normen einhalten wollen / müssen, sind wir gezwungen nach 
gewissen "Regeln" zu entwickeln. Dazu gehört auch die "Tracebility" zu 
gewährleisten. Wir entwickeln nach dem klassischen V-Modell.

Folgende Requirements werden in DOORS gepflegt:
- Kundenanforderungen
- Technische System Anforderungen
- Subsystem Anforderungen
- Test Spezifikation Modul
- Test Spezifikation System
- Validierung Spezifikation
- ...... und so weiter

DOORS erleichtert die Verlinkung zwischen diesen "Modulen". Damit können 
wir die Rückverfolgbarkeit herstellen da wir nachweisen können, dass 
z.B. alle Requirements durch einen Test verifiziert sind.

Wenn Du "nur" Requirements schreiben möchtest ohne auf die umfangreiche 
Link-Funktionalität (in Verbindung mit der integrierten 
Versionsverwaltung, Reviewfunktionen, QA-Tools, 
Rose/Matlab-Interface,...) angewiesen zu sein benötigst Du DOORS oder 
ähnliche Tools nicht.

Hoffe, dass ich ein wenig helfen konnte.

[matze (Gast)]

Danke für den Input!