Anforderungen aufnehmen ist der erste Schritt bei der Planung eines Software Projekts. Über Anforderungen werden die Ziele des Projektes klar und die Umsetzung kann eingeleitet werden. Aus der Anforderungsaufnahme resultiert – grob gesprochen – eine Übereinkunft von Auftraggeber und Auftragnehmer. Es wird klar, was die Inhalte des Projekts sind und was letztlich vom Auftragnehmer umgesetzt werden muss.
Der gesunde Menschenverstand sollte uns an dieser Stelle also sagen, dass, je besser Anforderungen an ein Projekt aufgenommen wurden und eine entsprechende Detailtiefe besitzen, desto genauer und gezielter kann mit der Umsetzung begonnen werden. Es würde also nicht zu Projektverzug kommen, wenn von vornherein die Richtung klar gewesen wäre.
Unklare Anforderungen – Der Beginn des Chaos
Es ist nicht selten der Fall, dass Anforderungen an Projekte nicht länger als eine DIN-A-4 Seite lang sind und recht salopp formuliert sind – wenn sie nicht gerade mal mündlich besprochen werden. Formulierungen am Telefon, wie „Ich vermute, dass die User dann das brauchen…“ sind auch keine Seltenheit. Das Resultat daraus ist oft pures Chaos: Der Entwickler hätte sich nicht an Absprachen gehalten, der Auftraggeber hätte sich nicht klar ausgedrückt, der Projektverzug wird immer größer und die Schuldzuweisungen werden immer heftiger. Glücklicherweise gibt es da eine recht einfache Lösung, die mal wieder aus dem User Experience Bereich kommt. Sie nennt sich User Requirements Engineering und kann Problemen von Beginn an vorbeugen.
Falsche Erwartungen, Missverständnisse und Annahmen
Als Auftraggeber haben Sie eine konkrete Vorstellung davon, wie das Projekt aussehen soll. Doch in der Vermittlung dieser Ziele entstehen allzu oft Missverständnisse. Nicht zuletzt, weil sich vieles „von selbst erklärt“, oder „doch eigentlich klar sein sollte“. Als Auftragnehmer sollten bei Ihnen die Alarmglocken schrillen, denn ab diesem Zeitpunkt hat sich das Projekt in eine Art Glücksspiel verwandelt – haben Sie wirklich alles richtig verstanden? Ist es wirklich selbst erklärend? Ist zur Erreichung des Projektzieles die Implementierung dieses einen Features nun absolut notwendig, oder trifft YAGNI (you ain’t gonna need it) eher zu? Bei der nächsten Begutachtung des Standes, stellen dann beide Seiten dann verärgert fest, dass sie aneinander vorbei geredet haben und eben nicht „alles klar“ war.
Anforderungen bilden die Basis des Projekts
Wer auf Sand baut, muss sich nicht wundern, wenn das Gebäude wegsackt. Gute Anforderungen bilden die Basis des Projektes. Sie helfen nicht nur ungemein beim weiteren Projektverlauf, sondern bilden vielmehr die Basis für ein insgesamt gut laufendes Projekt. Wenn auf beiden Seiten klar ist, was zu tun ist, was die Ziele sind und vor allem, wenn klar ist, was am Ende des Projektes als fertiges Endprodukt herausfällt, sind sowohl Auftraggeber, als auch Auftragnehmer gut bedient. Das Problem, was sich an dieser Stelle oft ergibt ist, dass Anforderungen vor allem auf Vermutungen beruhen – und das von beiden Seiten aus.
Anforderungen aufnehmen durch User Requirements Engineering
User Requirements Engineering ist ein Teilbereich der User Experience und bildet somit einen Teil der Mensch-Computer-Interaktion. Für die Aufnahme von Anforderungen bedeutet dies, dass vor allem der End-Nutzer im Mittelpunkt steht, eine Voraussetzung, die oftmals grundsätzlich vernachlässigt wird. Der Nutzer sieht letztendlich die Benutzeroberfläche und das ist für ihn auch gleichzeitig das eigentliche Produkt, nicht die Technik, die dem Produkt zu Grunde liegt. Technik nimmt der Nutzer immer als gegeben wahr, nicht jedoch die Interaktionsmöglichkeiten. Für das User Requirements Engineering bedeutet das, im ersten Schritt Anforderungen zu erkennen, die wiederspiegeln, was der Nutzer am fertigen Produkt erkennen, eingeben oder auswählen muss, um an sein Ziel zu gelangen. Systemanforderungen sind (zunächst) vernachlässigbar. Diese Art von Anforderung wird auch als Nutzungsanforderung bezeichnet.
Wie ermittle ich Nutzungsanforderungen?
Wenn der Nutzer eine Aufgabe erledigt, geschieht das immer in einem bestimmten Nutzungskontext. Dabei arbeitet der Nutzer mit gewissen Ressourcen, die ihm an dieser Stelle zur Verfügung stehen (Hardware, Software, Materialien, etc.) und er bewegt sich dabei immer in einer bestimmten physischen, sozialen und kulturellen Umgebung. Die Grundlage der Gestaltung des Nutzungskontextes, hat das einen direkten Einfluss auf das Handeln des Nutzers.
Um ein genaueres Bild vom Nutzungskontext zu bekommen, sind Interviews hilfreich, die mit den Personen durchgeführt werden, die für das zu entwickelnde Produkt letztlich von Interesse sind, weil sie die End-Nutzer repräsentieren. Als Alternative können wir den Nutzer auch bei seiner täglichen Arbeit begleiten, um die physische, soziale und kulturelle Umgebung besser kennen zu lernen und zu sehen, mit welchen Ressourcen der Nutzer aktuell arbeitet. Informationen, die hier zusammengetragen werden, werden durch sog. Kontext-Szenarien beschrieben. Das sind erzählende Formulierungen, wie Nutzer ihre Aufgaben in ihrem Nutzungskontext durchführen.
Die Ergebnisse der Analyse des Nutzungskontextes
Der wohl wichtigste Schritt bei der Aufnahme von Anforderungen ist nun die Ableitung von sog. Erfordernissen aus den Informationen zum Nutzungskontext. Erfordernisse beschreiben dabei die notwendigen Voraussetzungen, mit denen ein Nutzer ein Ziel erreichen kann. Die Formulierung klingt daher meistens so: „Der Nutzer muss X wissen/können/Fähigkeit besitzen, um Y zu erreichen.“ Somit resultieren Erfordernisse immer in einer Aktivität, die nur dann effizient und effektiv erreicht wird, wenn die jeweiligen Voraussetzungen, oder Kenntnisse dafür gegeben sind.
Aus Erfordernissen zur Nutzungsanforderung
Sind die Erfordernisse erarbeitet, folgt die Umwandlung in Nutzungsanforderungen. Diese beschreiben, was der Nutzer am Produkt erkennen, eingeben oder auswählen muss, während er eine Aufgabe im Nutzungskontext erfüllt. Hierzu verhelfen die folgenden drei Fragen:
- 1. Was muss der Nutzer erkennen, damit sein Erfordernis erfüllt wird?
- 2. Was muss der Nutzer eingeben, damit sein Erfordernis erfüllt wird?
- 3. Was muss der Nutzer auswählen, damit sein Erfordernis erfüllt wird?
Die hier erwähnten Szenarien, liegen bereits sehr nah an der Interaktion mit einer Applikation. Sie sind zudem zielgerichtet und leiten sich aus realistischen Fällen ab, die nicht nur aus Vermutungen bestehen, sondern auf der Arbeitsweise von Personen beruhen, die mit dem fertigen Produkt interagieren müssen. Designfragen und Oberflächengestaltungen werden erst dann berücksichtigt, wenn klar ist, wohin die Reise geht.
Eine gute Vorlage nicht nur für agiles Projektmanagement
Die Aufnahme von Anforderungen über User Requirements Engineering lässt sich zudem wunderbar in agiles Projektmanagement einfließen. Ob Sie an dieser Stelle mit Kanban arbeiten, oder mit einem ganzen Scrum-Team ist dabei egal. Wenn die Arbeitspakete formuliert sind, können Sie User-Stories formulieren, die einen echten Bezug haben und nicht auf Vermutungen basieren. Zudem ist gewährleistet, dass Sie hierdurch die Ziele des Nutzers umsetzen werden. Dies liegt daran, dass Sie Klarheit durch es durch die Analyse des Nutzungskontextes, das Herausarbeiten von Erfordernissen und die Ableitung von Nutzungsanforderungen schaffen.
User Requirements Engineering ist zertifizierbar!
Dieses Vorgehen hat sich bei der Aufnahme von Anforderungen bewährt und zudem zertifizierbar. Die Zertifizierungsstelle ist hier der UXQB, der auch Unterlagen bereit stellt, die Sie sich im Selbststudium näher bringen können. So steht Ihnen beim Aufnehmen von Anforderungen nichts mehr im Wege.
Auch wir können beim Aufnehmen von Anforderungen weiter helfen!
Sie müssen jedoch nicht alles können. Anforderungen aufnehmen, kann eine sehr zeit intensive Angelegenheit werden Nehmen Sie gerne Kontakt zu uns auf und wir übernehmen für Sie sie Aufnahme von Anforderungen für Ihr Softwareprojekt.
[su_button url=“/kontakt“ style=“soft“ background=“#262626″ size=“4″ wide=“yes“ center=“yes“ icon=“icon: pencil-square-o“]Wir helfen gerne![/su_button]
Letzten Beitrag verpasst? Kein Problem! Lesen Sie hier über Fullstack-Entwickler – Mythos oder Realität?
