Requirements Engineering Methoden

Anforderungen müssen 'atomar' sein, schreibt die einschlägige Requirements-Engineering-Literatur.

Nachdem ich in der Vergangenheit viele atomare Anforderungen geschrieben habe und vor einigen Jahren dann zu Use-Cases als Dokumentationswerkzeug übergegangen bin, möchte ich dem widersprechen.
Atomare Anforderungen mögen formal toll sein, nützlich sind sie nicht.

Mein Hauptkritikpunkt an atomaren Anforderungen ist die erschwerte Lesbarkeit. Dokumentation dient in erster Linie dazu, gelesen zu werden und sollte leicht lesbar und möglichst gut verständlich sein.
Insbesondere der Kontext einer Anforderung und die Zusammenhänge zwischen den einzelnen Anforderungen sollen IMHO leicht erfassbar sein können, um es dem Leser einfach zu machen, die Komplexität zu erfassen.
Aus einer Menge atomarer Anforderungen diese Komplexität zu erfassen, ist fast unmöglich für einen untrainierten Leser.

Lt. Wikipedia soll das Kriterium für ein "Atom" die Entscheidbarkeit einer Anforderung sein.
Formal gesehen muss also in einer Anforderung alle Information enthalten sein, um zu entscheiden ob sie erfüllt ist. Das heißt, der gesamte Kontext, insbesondere alle Vorbedingungen zum Erreichen der Anforderung, müssen in der Anforderung genannt sein!?

Da das viel zu aufwendig und nicht mehr lesbar ist, ergibt sich der Kontext meist aus den umstehenden Anforderungen. Oftmals gibt es für eine Handvoll zusammenhängender Anforderungen einen Übersichtsabschnitt, der den Kontext und den Zusammenhang der Anforderungen erklärt, bevor dann die einzelnen atomaren Anforderungen aufgezählt werden.
Dieser Übersichtsabschnitt ist demnach redundant zu den umstehenden Anforderungen, er bündelt nur die Einzelpunkte mit dem Ziel der Lesbarkeit. Manchmal nennt er auch ein übergeordnetes Ziel, die atomaren Anforderungen dann die Details.

Beiden Varianten würde ich die Integration der Informationen vorziehen. Ich lasse die Detailanforderungen weg und integriere sie in den Übersichtsabschnitt!

Alle potenziellen Leser profitieren von leichter Lesbarkeit. Selbst Tester, die atomar entscheiden sollen, ob eine Anforderung erfüllt ist, profitieren von den Zusammenhängen für ihre Testfälle.
Das einzige Szenario, das mir einfällt, in dem atomare Anforderungen notwendig sind, ist die Abnahme mit dem Anwalt – eine Situation, in die ich hoffentlich nicht kommen werde...

Hallo Andreas,

vielen Dank für Deinen treffenden Beitrag.
Ich bin ähnlicher Ansicht. Siehe auch

http://planetproject.wikidot.com/writing-atomic-functional-requirements
http://planetproject.wikidot.com/how-to-determine-if-a-requirement-is-atomic

Zur Sache mit dem Anwalt: Es mag Fälle gegeben haben, oder noch geben, wo sich die Anwälte von Auftraggeber und Auftragnehmer um die Erfüllung einer Spezifikation gestritten haben. Falls sie das anhand einer Beschreibung mit atomaren Anforderungen tun, empfinde ich Mitleid mit dem Auftraggeber. Warum?
Weil dann unglaublich viel Kleinkram zu diskutieren ist, der sehr wahrscheinlich rein gar nichts dazu beiträgt, dass der AG bekommt, was er wollte. Ich ziele auf die Dekomposition ab: Atomare (funktionale) Anforderungen sind Lösungen für Anforderungen höherer Ebene. Was der AG wirklich will ist - falls es beschrieben ist - mindestens 3 Ebenen abstrakter als die atomare Anforderung. Ich wage auch die Aussage, dass es den Auftraggebern selten um Funktion geht, sondern meist um eine oder mehrere Qualitäten (Eigenschaften, wie Preis, Robustheit).
Somit rate ich dazu, sehr genaue, unzweideutige Beschreibungen von Anforderungen HÖHERER Ebene zu anzufertigen, damit die Erwartung klar transportiert wird. Vermutung: Der Drang, atomare Anforderungen zu schreiben kommt aus dem Unvermögen, klare Beschreibungen dieser Qualitäten hin zu bekommen.
Nur einmal in meinen 15 Jahren Erfahrung als Business Analyst hatte ich das dringende Bedürfnis nach kleinteiligen, nahe-atomaren Anforderungen. In diesem Fall habe ich mich dazu entschlossen, zusätzlich zu sehr spezifischen Anforderungen hoher Ebene Testfälle in der allbekannten GIVEN-WHEN-THEN Form zu schreiben. Da konnten dann Entwickler UND Tester was damit anfangen. Wichtig: Vorrang erklären, weil sich die beiden Ebenen garantiert irgendwo widersprechen. Wer über Vorrang unterschiedlicher Beschreibungsebenen nachdenkt kommt darauf, dass die höhere Ebene "verbindlicher" ist, weil sie eher ausdrückt, was der AG erreichen will.
Ansonsten gilt wie immer dummerweise was, was Neulinge irre macht: Es kommt darauf an.... :-)

Dieser Artikel sagt wirklich das aus, was wichtig ist. Atomare Anforderungen gibt es nicht! Jede Anforderungen sollte nur hinreichend für den Level auf den sie sich bezieht beschrieben sein. Also Systemanforderungen müssen nicht auf Bit und Byte zur Softwareentwicklung heruntergebrochen werden.
Weitere Interessante Informationen sind auch unter http://www.parityblog.net zu finden