Direkt zum Hauptbereich

Wer macht' s?

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...

Kommentare

  1. 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.

    Dein 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 :-)

    AntwortenLöschen
  2. Gleich vorweg: Das beschriebene Problem ist keines (zumindest kein großes) in der alltäglichen Arbeit, da alle Beteiligten eigentlich dieses implizite Wissen haben.

    Nimmt 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.

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Code Retreat: Keine If-Ausdrücke

Ich hatte am letzten Samstag einen Code Retreat organisiert. Dabei hatten wir auch zwei Sessions mit der Vorgabe, keine If-Ausrücke (auch keine switches oder ?-Operatoren) zu verwenden.

Folgendes fand sich daraufhin haufenweise im Code eines Paares:

while (a == 1) { //do somethingbreak; }
Soviel also zum Ziel, saubereren Code zu schreiben...

Europäische Federalist Papers

Zunächst einmal die gute Nachricht: Als sich 1774 die amerikanischen Kolonien von der britischen Regierung lossagten, kam es erst einmal zum Krieg, an dessen Ende die Sezession erfolgreich war. Und auch als sich 1861 die Südstaaten von der amerikanischen Bundesregierung lossagten, kam es zum Krieg, an dessen Ende die Sezession nicht erfolgreich war. Europa hat aus diesen Erfahrungen zumindest soviel gelernt, dass es ein juristisches Regelwerk geschaffen hat, dass eine Sezession ohne blutige Auseinandersetzung ermöglicht. Ein großer Pluspunkt.
Jedoch ist wahrscheinlich die selbe bürokratische Gründlichkeit dafür verantwortlich, dass der gescheiterte europäische Verfassungsentwurf 30 mal länger ist als sein amerikanisches Pendant [1]. Außerdem vermisse ich ganz besonders ein europäisches Gegenstück zu den amerikanischen Federalist Papers. Für eine europäische Verfassung ist der Zug bereits abgefahren und wird voraussichtlich auch nicht allzu bald wieder bei uns anhalten. Aber für europ…

Activity sampling

Wenn ich in den letzten Jahren Schülerpraktikanten betreut habe, ließ ich diese immer einen "Activity Tracker" entwickeln. Damit sie in den anderthalb bis zwei Wochen einen wirklichen Einblick in den Arbeitsalltag bekommen, habe ich ihnen am Anfang immer eine Einführung in den Softwareentwicklungsprozess gegeben, den sie dann so auch nachvollziehen mussten: Analyse, Design, Implementierung, Test, Wartung - das klassische Wasserfallmodell eben (Softwareentwicklung ist nicht nur Programmierung).

Ich hoffe, ich konnte ihnen auch das zu bearbeitende Problem so erläutern, dass sie die Motivation dahinter verstanden und damit die Aufgabenstellung als sinnvoll empfanden und nicht nur als Beschäftigungstherapie begriffen:

Ich erklärte ihnen, dass wir oft mehrere Projekte parallel bearbeiten und auch innerhalb eines Projekts verschiedene Tätigkeiten ausführten (siehe die verschiedenen Phasen oben) und dass wir diese Tätigkeiten zur Nachverfolgung, der Kostenermittlung und für später…