Nobert Eder hat sich zu einem Streitgespräch Gedanken gemacht. Dabei hat er, so ich verstehe Wert auf Anforderungen gelegt.
Wer sich für den Inhalt interessiert und der Meinung ist nichts aus dem Kontext gerissenes lesen zu wollen, darf gerne seinen Post durchlesen.
Er sagt
- Die Anforderungen müssen bekannt, verständlich und vollständig sein.
- Die Bewertung wurde durch die Entwicklung durchgeführt. An dieser Bewertung ist nicht zu rütteln. Bei Engpässen der Ressourcen muss (und das sollte es ohnehin) mit Prioritäten gearbeitet werden.
- Die Bewertung der Entwicklung stellt die Diskussionsgrundlage zwischen Projektverantwortlichen und Kunden dar. An dieser Stelle kann über Prioritäten oder Änderung der Funktionalität diskutiert werden. Bei Änderungen ist eine erneute Bewertung durch die Entwicklung notwendig.
Wer sich mal Lektüre zu Anforderungsmanagement zur Seite genommen hat, der weiß, das hier noch eine ganze Menge mehr dazu gehört. Ich zitiere hier mal gerne Wikipedia:
- Korrekt
- Unzweideutig
- Vollständig
- Konsistent
- Bewertet nach Wichtigkeit und/oder Stabilität
- Verifizierbar
- Modifizierbar
- Verfolgbar (Traceable)
Richtig Anfordern
Hat Norbert an all das gedacht? Vielleicht hat er es. Aber ich konnte es nicht aus dem Text nicht explizit entnehmen.
Wie kann ich etwas verifizieren? Verifizieren heißt bei Software zu zeigen, dass man das richtige gemacht hat! Nur weil ich sage, ich kann ein Haus bauen und etwas hinstelle, heißt es noch lange nicht, das es ein Haus ist. Die Anforderungen müssen also überprüft werden können.
Beispiele für schlechte Anforderungen, die nicht verifizierbar sind:
- Das UI soll bunt sein
- Die Ergebnissdateien sollen verglichen werden
- Das Laden der Datei soll schnell sein
Ist schwarz und rot schon bunt? Oder rot, blau, gelb? Wie soll verglichen werden? Zeilengleichheit? Hashwert? Phonetische Übereinstimmung? Wie sind 2 Minuten schnell? sind 10 Sekunden schnell? Die Trennung von Technischem Inhalt und Beschreibung der Anforderung, sei es aus Benutzersicht, oder dem zu entwickelnden System, gehören erst einmal weg. Es sei denn, der Benutzer ist versiert und es gehört direkt zu seinen Anforderungen (z.B. einen MSSQL zu nutzen). Sie sind alleine deswegen schon getrennt zu betrachten, da Modifizierbarkeit sonst schwer fällt. Wenn sich Änderungen in der Infrastruktur ergeben, die Anforderungen aber nicht betroffen sind, was muss hier gemacht werden? Anpassungen an Dokumentation!
Ganzheit Betrachten
Anforderungen sind speziell im Kontext des Gesamtsystems zu betrachten! Für ein Echtzeitsystem können 5ms schon langsam sein. Messbar heißt im besten Fall also immer mit einer Einheit hinterlegt. Maßeinheiten sind in aller Regel genormt. Hier könnte ich jetzt zu geeigneten Messmitteln abschweifen. Wer sagt mir, das 20 cm wirklich diese Länge haben? Wenn ich auf die anderen Punkte tiefer eingehen würde, kämen wir zu folgendem Ergebnis:
Ohne ein ordentliches Werkzeug tut diese Handarbeit ganz schön weh! Die Versionierung der Anforderungen und der Dazugehörigen Dokumente gehört bei ISO konformem Arbeiten nämlich auch dazu! Ihr wollt gar nicht wissen, was für einen Ratenschwanz das alles nach sich zieht. Hoch lebe die Bürokratie. Schauen wir uns mal im groben an, was für Anforderungen alles so notwendig wird:
Über die Reihenfolge und den Tiefgang möchte ich mich hier gar nicht unterhalten, denn Möglichkeiten der Prozessoptimierung, also wann was sinnvoll ist, kommt auf das System, bzw. die Projektstruktur an. Und Software ist dabei eventuell nur ein kleiner Teil, wenn wir uns nicht nur in reinen Software Projekten befinden.
Reflektion Ermöglichen
Rückverfolgbarkeit über die Prozesskette hinweg ist eine Welt für sich.Spaß macht diese Art der Arbeit allerhöchstens dann, wenn einem die richtigen Werkzeuge die notwendige Infrastruktur abnehmen und ich mich auf den Inhalt konzentrieren kann, also den funktionalen Anteil dessen, was von mir gefordert wird! Und da ist es egal, ob ich Anforderungen schreibe, Design Files entwerfe, Projekt und Testpläne erstelle, oder einen Bericht zu dem Test ausfülle. Mal ehrlich. IDs pflegen über 100 von Dokumentationsseiten ist nichts, was für Menschenhand gedacht ist
Ihr denkt euch sicherlich, das schießt alles über das Ziel hinaus. Da mögt ihr für euch auch recht haben, denn es zwingt euch keiner. Wer diesen Prozess einer ISO konformen Arbeitsweise aber mal miterlebt, kann dann auch wirklich reflektieren, was hier eigentlich an Qualitätskontrollen vorgenommen werden und wozu diese gut sind.
Daraus schließe ich bezugnehmen auf die obige Auflistung von Anforderungen
- Was nicht Korrekt beschrieben ist, kann nicht “richtiger” werden
- Was zweideutig ist, kann falsch interpretiert werden
- Was nicht vollständig ist, kann nicht zusammen gestellt werden
- Was nicht konsistent ist, provoziert Fehlverhalten
- Was nicht bewertet wird, kann nicht eingeordnet und terminiert werden
- Was nicht beweisbar ist, kann nicht überprüft werden
- Was nicht modifizierbar ist, kann nicht weiter entwickelt werden
- Was nicht verfolgbar ist, kann nicht gefunden werden
Und vor allem vor jedem Auditor: Was nicht unterzeichnet auf Papier steht existiert nicht.
Wie können wir also ein System nach qualitativen Aspekten auf den Markt bringen wenn wir keine Differenzierte Betrachtung machen und technische Aspekte nur dort lassen, wo sie hingehören: In das System (Design)
Stellt euch also mal beim nächsten Hack-a-thon was ihr damit eigentlich erreichen wollt. Sind es rein funktionale Aspekte, oder gehen diese weit darüber hinaus, weil sie nicht nur meine Persönliche Befindlichkeit oder vorlieben spiegeln?