Kennen Sie das babylonische Sprachgewirr in Ihrer Firma? Die Silos des Verstehens? Garantiert ist Ihnen das schon begegnet. Deshalb bersucht man seit langem die Technik mit Methoden wie SOPHIS, EARS, INCOSE es zumindest besser zu machen.
Neulich, in einer Firma. „Die Ingenieure müssen jetzt erst mal Requirements Engineering lernen. Lehrjahre sind keine Herrenjahre.“
Ich habe widersprochen. Der obige Satz ist halb richtig. Die falsche Hälfte kostet Sie Geld.
Wie ein Ingenieur denkt#
Ein Ingenieur stellt zwei Fragen: Was brauche ich? Was muss das Ding dafür können?
Seine Antwort schreibt er in dieser Art auf:
Steuergerät → Bedienpanel: Betriebszustand. Im Automatikbetrieb. Höchstens 200 ms.
Das ist exakt. Wer liefert, steht da. Wer bekommt, steht da. Was fließt, wann es gilt, wie gut es sein muss: alles da. Genau dafür hat er studiert.
Dann soll er daraus eine Anforderung machen. In ganzen Sätzen. Heraus kommt oft das:
Das Bedienpanel soll den aktuellen Zustand der Anlage zeitnah anzeigen.
Jetzt fehlt fast alles. Wer schickt den Zustand? Welcher Zustand ist gemeint? Gilt das immer oder nur im Automatikbetrieb? Was heißt „zeitnah“? Das Wissen war vorhanden. Es ist beim Schreiben verloren gegangen.
Dazu kommt dass in den Anforderungen zwischen Non Fuctional (Sic!) == Merkmalen und Functional Requirements unterscheidet und gleichzeitig in der ISO 29148 Functional requirements Merkmale verlangen und ebenso ein paar seiten später sagt - ey Du - kannst auch weglassen.
Der Ingenieur hat nicht unexakt gedacht. Er hat exakt gedacht und unexakt geschrieben. Das sind zwei verschiedene Fähigkeiten.
Was der Abteilungsleiter richtig sieht#
Ein Teil muss gelernt werden. Ohne Abkürzung.
- Wofür und für wen? Jede Anforderung braucht einen Empfänger. Wer ihn nicht benennen kann, hat keine Anforderung.
- Wann gilt es? Ohne Bedingung gilt alles immer. Das stimmt selten.
- Woran prüfe ich es? Ohne Wert und Grenze gibt es keinen Test.
Das ist Denkarbeit. Das ist Ingenieursarbeit. Das nimmt kein Werkzeug dem Ingenieur ab.
Wo der Fehler liegt#
Typische Schulungen im Requirements Engineering lehren aber noch etwas anderes. Satzschablonen. Die richtigen Modalverben. Passiv vermeiden. Weiche Wörter streichen.
Das ist Übersetzungsarbeit. Der Ingenieur hat die exakte Information schon. Er lernt, sie verlustfrei in Prosa zu übertragen. Danach lernt der Prüfer, sie aus der Prosa wieder herauszulesen. Zweimal Arbeit für dieselbe Information.
Die Ursache liegt nicht beim Ingenieur. Sie liegt in der Arbeitsteilung. Die Firma lässt eine Person zwei Dinge tun: wissen und formulieren. Das Wissen ist seine Stärke. Das Formulieren liegt quer dazu.
So sieht das im Alltag aus:
- Reviews streiten über Wortlaut statt über Inhalt.
- Test und Lieferant fragen nach, was gemeint war.
- Lücken bleiben im Satz versteckt. Sie fallen erst im Test oder beim Kunden auf.
„Lehrjahre sind keine Herrenjahre“ macht daraus ein Ausbildungsproblem. Es ist ein Einsatzproblem.
Was Sie morgen ändern können#
Lassen Sie Ihre Ingenieure keine Sätze mehr schreiben. Lassen Sie sie Felder füllen. Eine Anforderung ist ein Datensatz:
| Feld | Frage | Beispiel |
|---|---|---|
| Bedingung | Wann gilt es? | im Automatikbetrieb |
| Quelle | Wer liefert? | Steuergerät |
| Tätigkeit | Was passiert? (feste Verbliste) | senden |
| Fluss | Was fließt? | Betriebszustand |
| Senke | Wer bekommt es? | Bedienpanel |
| Merkmal | Wie gut? Wert, Einheit, Grenze | Latenz höchstens 200 ms |
Das ist die Notiz des Ingenieurs. Nur mit festen Plätzen.
Den Satz baut danach eine Regel zusammen:
Im Automatikbetrieb muss das Steuergerät den Betriebszustand an das Bedienpanel senden. Latenz: höchstens 200 ms.
Für den Anfang reicht eine Tabelle. Eine Spalte je Feld. Die Tätigkeit wählen Sie aus einer kurzen, festen Liste. Den Satz brauchen Sie nur noch für Dokumente nach außen.
Der Nebeneffekt ist der eigentliche Gewinn: Ein leeres Feld fällt sofort auf. Fehlt die Senke, sehen Sie es beim Eintragen. In der Prosa hätten Sie es erst im Test gesehen.
Satzschablonen gibt es seit Langem, etwa EARS oder die Schablonen von SOPHIST. Der Unterschied hier: Der Ingenieur füllt die Schablone nicht als Satz aus. Er füllt Felder. Den Satz erzeugt die Regel.
Wie Sie prüfen, ob das wirkt#
Glauben Sie mir das nicht. Messen Sie es.
Annahme: Die freie Formulierung ist die Ursache für Nacharbeit an Anforderungen.
Maßnahme: Ein Team schreibt ein Projektinkrement lang Anforderungen nur noch als Datensatz.
Messgrößen, die Sie selbst erheben:
- Review-Befunde zum Wortlaut je 100 Anforderungen.
- Rückfragen von Test und Lieferanten je 100 Anforderungen.
- Fehler, die erst im Test auffielen und deren Ursache in der Anforderung lag.
Baseline: dieselben drei Zahlen aus dem letzten abgeschlossenen Projekt.
Frist: ein Projektinkrement, höchstens drei Monate.
Auswertung: Sinken die Zahlen, war die Formulierung die Ursache. Sinken sie nicht, bleiben die Felder leer oder falsch gefüllt. Dann fehlt das Denken in Anforderungen. Dann hat Ihr Abteilungsleiter recht, und die Schulung gehört genau dorthin. Auch das wissen Sie dann. Mit Zahlen, nicht aus dem Bauch.
Wer entscheidet: der Entwicklungsleiter. Er legt fest, in welcher Form Anforderungen geschrieben werden. Niemand sonst kann das ändern.
Was Nichthandeln kostet: Ihre besten Leute arbeiten am Wortlaut statt an der Technik. Die Lücken finden Kunde oder Auditor.
Und SysML?#
SysML geht einen Schritt weg von der Prosa, hin zum Modell. Das ist näher an der Denkweise des Ingenieurs. Es verlangt aber wieder eine eigene Sprache: Notation, Diagrammtypen, Werkzeug. Das Muster bleibt dasselbe. Der Ingenieur lernt die Sprache des Werkzeugs. Besser wäre ein Werkzeug, das die Sprache des Ingenieurs spricht. Das ist meine Einschätzung, keine Messung.
In eigener Sache#
Ich entwickle mit OTSM ein Werkzeug genau für diesen Weg. Der Ingenieur trägt ein, was er braucht und von wem. Den Satz, die Struktur und die Prüfungen erzeugt das System. Das ist eine Anbieteraussage. Prüfen Sie sie an einer Demo am Referenzsystem, nicht an meinem Text.
Die Methode dahinter ist bereits beschrieben: Anforderungen als Datensatz. Als Ein-Seiten-Karte finden Sie sie im Quick Reference Handbook.
Die Tabelle aus diesem Artikel brauchen Sie dafür nicht. Sie funktioniert ab morgen. Mit Excel.