Ist es eine Anforderung oder ist es Design?

In vielen Kursen und Büchern über Anforderungen wird Ihnen gesagt, dass eine gute Anforderung das "Was" eines Bedarfs eines Kunden (oder allgemeiner gesagt, eines Interessenvertreters) beschreibt. Sie werden Ihnen sagen, dass Sie nicht das "Wie" aufschreiben sollten (man nennt das 'Design'), weil Sie dadurch in eine technische Richtung gedrängt werden und andere gute Lösungen verpassen. Das ist ein guter Rat in dem Sinne, dass Sie sich nicht auf eine Lösung beschränken sollten, wenn eine andere Lösung die Bedürfnisse eines Kunden besser erfüllt. Aber wann ist etwas ein Design und wann ist es eine Anforderung? Wenn Sie darüber nachgedacht haben, werden Sie feststellen, dass es schwer ist, die Grenze zu ziehen. Das "Wie" kann zum "Was" werden und umgekehrt. Ein Beispiel, Was: "Das System soll mich von A nach B bringen" Wie: "Das System sollte aus einem Auto bestehen" Überlegen Sie jetzt: Was: "Ich muss in der Lage sein, Besprechungen mit Leuten an verschiedenen Orten abzuhalten" In diesem Fall kann "Das System sollte mich von A nach B bringen" ein gültiges "Wie" sein, ebenso wie "Das System sollte Telekonferenzfunktionen bieten". Welches davon am besten geeignet ist, hängt von den anderen Bedürfnissen der Beteiligten ab, nicht vom "Wie" oder "Was". In seinem Buch "Just Enough Requirements Management" definiert Alan M. Davis zwei Aspekte einer Anforderung, die ich sehr nützlich finde. Er erklärt: "Eine Anforderung ist eine von außen beobachtbare Eigenschaft eines gewünschten Systems". Mit anderen Worten: Es muss möglich sein, die Erfüllung der Anforderung von außen zu überprüfen. Der zweite Aspekt einer Anforderung ist, dass sie ein Bedürfnis eines Stakeholders erfüllen sollte. Eine Anforderung wie "Das Auto sollte in den Farben Rot, Gelb und Blau produziert werden" kann gültig sein. Sie ist sicherlich von außen beobachtbar. Wenn sich herausstellt, dass dies die beliebtesten Farben bei den Käufern des Autos sind und dass die Lackieranlage nur drei verschiedene Farben verarbeiten kann, dann erfüllt sie auch die Bedürfnisse von mehr als einem Stakeholder. Fast jeder Aspekt eines Systems kann von außen beobachtbar sein (im richtigen Kontext, aus der Perspektive eines bestimmten Stakeholders). Nehmen wir ein extremes Beispiel: "Keine Methode in der Programmiersprache Java darf mehr als 1200 Zeichen lang sein (ohne Leerzeichen)". Dies kann unter dem Gesichtspunkt der Wartbarkeit des Codes gültig sein. Vielleicht wird ein Tool verwendet, das nicht so viele Zeichen unterstützt, oder der Stakeholder hat gute Gründe zu glauben, dass dies die Wartung des Codes erleichtert. In diesem Fall ist es eine Anforderung. Sie sollte natürlich immer noch gegen die Bedürfnisse anderer Interessengruppen abgewogen werden. Um festzustellen, ob eine Anforderung gut ist, konzentrieren Sie sich also nicht auf das einfache Mantra "ist es ein Design, dann ist es keine gute Anforderung". Entscheidend ist, inwieweit sie ein Bedürfnis eines Stakeholders befriedigt, und eine bessere Anforderung befriedigt mehr Bedürfnisse oder wichtigere Bedürfnisse als eine schlechtere Anforderung.