Hier jetzt mal ein Gedanke zum - Überraschung - Schreiben von Anforderungen. Da schwanke ich hin und her zwischen Pragmatismus ("Sieh‘ s nicht so streng. Der Leser weiß schon was gemeint ist.") und erkenntnistheoretischen Dogmatismus ("Die Anforderungen muss vollständig, konsistent und für jeden unmissverständlich sein. Definieren wir deswegen als erstes, was ein 'Mensch' ist!").
Ein Schlachtfeld in diesem Krieg (zwischen mir und meiner Wenigkeit) ist die Formulierung von Nutzeraktivitäten.
Da liest (und schreibt) man z.B. "Das Programm muss dem Nutzer die Möglichkeit bieten, eine Datei zu öffnen." oder "Falls der Nutzer ein neues Objekt angelegt hat, muss das Programm eine Meldung ausgeben."
Doch eigentlich verständlich, oder? Ja, aber dennoch falsch! Denn nicht der Nutzer öffnet die Datei, sondern das Programm. Der Nutzer wählt die Datei aus und gibt dem Programm den Auftrag, sie zu öffnen. Und auch das Objekt wird nicht vom Nutzer angelegt, sondern von der Software. Der Nutzer gibt nur den Auftrag, dass das Objekt angelegt werden soll.
Korrekt müsste es also z.B. heißen: "Das Programm muss dem Nutzer die Möglichkeit bieten, eine Datei auszuwählen, die zur Anzeige vom Programm geöffnet werden soll." und "Falls der Nutzer den Menüpunkt "New Object" auswählt, muss das Programm ein neues Objekt anlegen und eine Meldung ausgeben."
Das macht die Anforderungen länger und schwerer lesbar? Na und! Schreiben von Anforderungen ist schließlich kein prosaisches Hobby, sondern eine philosophische Arbeit. Wir konstruieren eine Welt aus Worten und sie muss perfekt sein.
An dieser Stelle rücken meine Kollegen jetzt merklich etwas weiter von mir weg. Das hat sicher nichts damit zu tun, dass ich aufgesprungen bin und den Stuhl umgeworfen habe.
Nachdem ich wieder aus dem Raum heraus darf, zu dem ich zur Beruhigung eingeschl... äh der mir zur weiteren Problemanalyse bereitgestellt wurde, gebe ich bereitwillig ("Was sind das nur für schöne bunte Pillen?") nach. Letztlich weiß ja jeder was gemeint ist.
Und dann, nach Monaten des Durchhaltens, der Rückschlag beim Review: "Falls der Nutzer ein Objekt instanziiert, muss das Programm ein leeres Objekt erzeugen." Kommentar eines Reviewers "Es sollte beschrieben werden, was 'Instanziieren' bedeutet." Ja, das sollte es. Oder man verwendet ein deutsches Wort. Dann jedoch wird deutlich, dass die jeweiligen Verantwortungen nicht geklärt sind: "Falls der Nutzer ein Objekt erzeugt, muss das Programm ein leeres Objekt erzeugen."
Dann sieht man, dass der Nutzer eben nichts erzeugt oder instanziiert, sondern lediglich den Auftrag dafür an das Programm erteilt, das dann stattdessen die Erzeugung vornimmt.
Ja so etwas ist wichtig... Was?... Nein heute Morgen noch nicht...Die schmecken mir nicht so gut....Wirklich?...Oh, die sind aber schön bunt...
Ein Schlachtfeld in diesem Krieg (zwischen mir und meiner Wenigkeit) ist die Formulierung von Nutzeraktivitäten.
Da liest (und schreibt) man z.B. "Das Programm muss dem Nutzer die Möglichkeit bieten, eine Datei zu öffnen." oder "Falls der Nutzer ein neues Objekt angelegt hat, muss das Programm eine Meldung ausgeben."
Doch eigentlich verständlich, oder? Ja, aber dennoch falsch! Denn nicht der Nutzer öffnet die Datei, sondern das Programm. Der Nutzer wählt die Datei aus und gibt dem Programm den Auftrag, sie zu öffnen. Und auch das Objekt wird nicht vom Nutzer angelegt, sondern von der Software. Der Nutzer gibt nur den Auftrag, dass das Objekt angelegt werden soll.
Korrekt müsste es also z.B. heißen: "Das Programm muss dem Nutzer die Möglichkeit bieten, eine Datei auszuwählen, die zur Anzeige vom Programm geöffnet werden soll." und "Falls der Nutzer den Menüpunkt "New Object" auswählt, muss das Programm ein neues Objekt anlegen und eine Meldung ausgeben."
Das macht die Anforderungen länger und schwerer lesbar? Na und! Schreiben von Anforderungen ist schließlich kein prosaisches Hobby, sondern eine philosophische Arbeit. Wir konstruieren eine Welt aus Worten und sie muss perfekt sein.
An dieser Stelle rücken meine Kollegen jetzt merklich etwas weiter von mir weg. Das hat sicher nichts damit zu tun, dass ich aufgesprungen bin und den Stuhl umgeworfen habe.
Nachdem ich wieder aus dem Raum heraus darf, zu dem ich zur Beruhigung eingeschl... äh der mir zur weiteren Problemanalyse bereitgestellt wurde, gebe ich bereitwillig ("Was sind das nur für schöne bunte Pillen?") nach. Letztlich weiß ja jeder was gemeint ist.
Und dann, nach Monaten des Durchhaltens, der Rückschlag beim Review: "Falls der Nutzer ein Objekt instanziiert, muss das Programm ein leeres Objekt erzeugen." Kommentar eines Reviewers "Es sollte beschrieben werden, was 'Instanziieren' bedeutet." Ja, das sollte es. Oder man verwendet ein deutsches Wort. Dann jedoch wird deutlich, dass die jeweiligen Verantwortungen nicht geklärt sind: "Falls der Nutzer ein Objekt erzeugt, muss das Programm ein leeres Objekt erzeugen."
Dann sieht man, dass der Nutzer eben nichts erzeugt oder instanziiert, sondern lediglich den Auftrag dafür an das Programm erteilt, das dann stattdessen die Erzeugung vornimmt.
Ja so etwas ist wichtig... Was?... Nein heute Morgen noch nicht...Die schmecken mir nicht so gut....Wirklich?...Oh, die sind aber schön bunt...
Ich glaube, ihr sollte das eher von Nutzergeschichten (User Stories) formulieren, denn dann beschreibst du die Erwartungshaltung der jeweiligen Rolle und nicht, wer was zu tun hat.
AntwortenLöschenDein Beispiel oben wäre dann etwa:
Als ein Nutzer möchte ich eine Datei öffnen können.
Als ein Nutzer erwarte ich einen Hinweis, wenn XYZ.
Dass ich als Nutzer dies immer im Bezug auf das zu erstellende Programm meine, ist implizit enthalten.
Man kann Nutzergeschichten auch in Tabellen erfassen. Erste Spalte ist die Rolle, zweite Spalte die Erwartung, dritte Spalte eine eventuelle Bedingung. Das zwingt dann zu kurzen prägnanten Sätzen. Es ähnelt dann einer strukturierten Sprache. Nichts für lauschige Abende im Sessel vorm Kamin, aber ziemlich effizient :-)
Gleich vorweg: Das beschriebene Problem ist keines (zumindest kein großes) in der alltäglichen Arbeit, da alle Beteiligten eigentlich dieses implizite Wissen haben.
AntwortenLöschenNimmt man jedoch einen streng theoretischen Standpunkt ein (und das mache ich immer wieder gern :-)), ist implizites Wissen ein nicht im Modell formuliertes Wissen und damit ist das Modell unvollständig:
Ich kann aus den natürlichsprachlichen Anforderungen einfach keinen Code generieren (echt mal!).
Und gerade wenn man die User Stories (die es auch gibt) detailieren und Anforderungen an Teilsysteme und Komponenten formulieren (ableiten) will, wird es wichtiger, genau zu klären, welche Komponente nun die Datei öffnen und damit welcher Entwickler dies umsetzen soll.
Eine weitere Randbedingung ist, dass wir Anforderungen nach dem SOPHIST REgelwerk formulieren - was ich sehr begrüße, da die Anforderungen so formaler werden und gewisse Mindeststandards erfüllen.