Requirements Engineering in der Spieleentwicklung: Wie Du Kunden-Anforderungen richtig ermittelst

Kennst Du das: Du sollst für einen Kunden ein Game oder eine andere App/Software entwickeln, Du bist Feuer und Flamme und entwickelst Tage oder sogar wochenlang. Aber als Du fertig bist und Du Deinem Kunden Dein tolles Endprodukt präsentierst, zeigt sich dieser gar nicht begeistert. Schon erlebt? Hoffentlich nicht 😉

Denn das ist ein typisches Zeichen dafür, dass am Anfang des Projektes die Anforderungen des Kunden nicht richtig aufgenommen bzw. definiert wurden.

Requirements Engineering

Ich habe mich in den letzten Monaten beruflich etwas intensiver mit dieser Thematik auseinander gesetzt und habe dabei festgestellt, dass sich mittlerweile ganze Berufszweige mit dem Ermitteln von Anforderungen beschäftigen, dem sogenannten Requirements Engineering.

Die Berufsgruppe der Requirements Engineers befasst sich mit der korrekten (und vollständigen) Aufnahme, dem Dokumentieren, Prüfen und Managen von Anforderungen eines Kunden an einer zu entwickelnden Software, z.B. einer 3D-Anwendung (Game, Architekturvisualisierung, VR-Simulationen etc.) .

Bei kleinen Projekten ist das vollständige Aufnehmen von Anforderungen noch nicht ganz so kritisch. Denn wenn Du alleine eine kleine App für einen Kunden entwickelst und es treten Unklarheiten auf, dann rufst Du kurz beim Kunden an und fragst wie er das genau haben möchte (zumindest solltest Du das so machen 😉 ).

Hast Du aber ein größeres Projekt, bei dem Du die Umsetzung später vielleicht nicht alleine machst oder auf Kundenseite mehrere Ansprechpartner hast, dann müssen diese Anforderungen im Vorwege sauber aufgenommen werden. Schließlich wäre es ziemlich unprofessionell, wenn beim Umsetzen alle paar Minuten beim Kunden das Telefon klingt, weil mal wieder irgendein Detail nicht ganz klar ist.

Wobei das noch nicht mal das schlimmste wäre. Der Worst Case ist natürlich, wenn man als Entwickler selbständig ohne Rücksprache mit dem Kunden etwas entscheidet und umsetzt, was sich am Ende als falsch herausstellt.

Vorgehen beim Requirements Engineering

Aber wie geht man nun richtig beim Aufnehmen von Anforderungen vor? Wie gesagt, das ist ein recht großes Thema. Ich habe mir hierzu u.a. das Buch Business Analyse und Requirements Engineering von Peter Hruschka durchgelesen, das wirklich gut das Vorgehen beschreibt und eine Menge Tipps bereithält (den Buch-Link findet Ihr weiter unten). Aber ich will die wichtigsten Punkte im Folgenden einmal zusammenfassen.

Am Ende hast Du auf jeden Fall ein Dokument, in dem alle wichtigen Dinge drinstehen, die man als Entwickler/Designer etc. wissen muss. Wenn Du ein klassischer Spieleentwickler bist, wird dir das bestimmt bekannt vorkommen. Denn dies ist das typische Game-Design-Dokument.

Aber wenn Du heutzutage als Spieleentwickler Deine Dienste anbietest, wirst Du auch Architekturvisualisierungen, VR-Simulatoren und andere Anwendungen entwickeln. Damit wirst Du auch Kunden haben, die noch nie etwas von einem Game-Design-Dokument gehört haben.

Was ich damit sagen möchte ist folgendes: Gehe nicht davon aus, dass Dein Kunde ein fertiges Dokument bereit hält, in dem alle Anforderungen detailliert enthalten sind. Du wirst die Anforderungen des Kunden selber ermitteln und dokumentieren müssen. Und dann stehst Du vor der Frage, wie man dies am geschicktesten macht.

Ziele definieren

Das aller erste, was Du am Anfang definieren solltest, sind zunächst einmal die großen Ziele der Applikation. Im 2D/3D-Applikationsbereich könnten das zum Beispiel Merkmale wie die folgenden sein:

  • Welche Art von Anwendung soll es werden? (2D-Platformer-Game, 3D-Shooter, Architektur-Visualisierung, VR-Anwendung zum Simulieren von…)
  • Auf welchen Plattformen soll sie laufen?
  • Soll damit Geld verdient werden und was für ein Modell ist angedacht?

Allerdings müssen und sollten auch nicht diese Ziele bereits zu detailliert formuliert werden. So kann z.B. eine Antwort auf die Frage nach dem Geld „Werbefinanziert“ lauten. Wie diese Werbefinanzierung im Detail aussieht, welche Werbenetzwerke eingebunden werden sollen etc. kann später definiert werden. Wichtig ist nur, dass das Ziel festgelegt wird und in der weiteren Analyse  nicht mehr darüber geredet wird, ob und wie man es nicht vielleicht doch z.B. kostenpflichtig anbieten könnte.

Wer sind die Stakeholder?

Als Stakeholder werden die Personen bezeichnet, die von etwas profitieren oder an etwas direkt oder indirekt beteiligt sind. Und wer das ist, ist natürlich für die Aufnahme der Anforderungen wichtig. Schließlich will man ja keinen Beteiligten, der Anforderungen hat, vergessen.

Aber wer ist ein Stakeholder? Natürlich sind die Nutzer der Software Stakeholder (bei Games sind das dann die Spieler). Nicht selten werden diese durch interne und/oder externe Tester (oder auch den Auftraggeber selber) repräsentiert. Nutzer und Tester könnten aber auch je nach Applikationstyp unterschiedliche Stakeholder sein, die auch unterschiedliche Anforderungen haben.

Aber auch die IT-Abteilung des Kunden ist ein potentieller Stakeholder, da sie am Ende vielleicht das Game/die Anwendung bereitstellen muss oder für die Verteilung auf die verschiedenen Plattformen zuständig ist. Dies wiederum kann man manchmal schon von den Zielen (s.o.) ableiten.

Was ist mein Scope?

Eine weitere Frage, die bereits am Anfang geklärt werden muss, ist der Projektumfang (im Englischen auch Scope genannt). Was befindet sich in meinem Betrachtungsraum und was ist außerhalb? Oder anderes gesagt: Was muss ich alles beim Entwickeln beachten?

Bei Games ist es z.B. gängig, dass Fremdsysteme wie Ad-Server oder Social Networks eingebunden bzw. angebunden werden. Dies zu wissen, ist natürlich wichtig, wenn ein Game entwickelt wird. Und genau dies wird bei der Scope-Betrachtung analysiert bzw. festgehalten.

Um noch etwas tiefer zu gehen, wird hier noch zwischen dem Product-Scope und dem Business-Scope unterschieden:

  • Der Product-Scope beschreibt, wie man schon am Namen erkennt, das eigentliche Produkt, das entwickelt werden soll.
  • Der Business-Scope beschreibt, welche Systeme und  anderen Inputs und Outputs (der die Spieler, Admins, Statistiken etc) mit dem zu entwickelnden Produkt interagieren.

Ein Ad-Server eines Fremdanbieters wäre z.B. im Business-Scope, nicht aber im Product-Scope. Der Geldtransfer vom Werbeanbieter zu Deinem Kunden, ist dann in gar keinem Scope, da dieser nicht mit der App interagiert und somit Deine Entwicklung überhaupt nicht beeinflusst. Solltest Du allerdings im Rahmen des Projektes auch noch einen eigenen Ad-Server für den Kunden entwickeln, wäre diese wieder im Product-Scope.

Du merkst schon, diese Betrachtung ist nicht ganz irrelevant.

Funktionale und nicht funktionale Anforderungen

Wenn Du nun die Ziele, die Stakeholder und den Scope definiert hast, kannst Du endlich damit beginnen die eigentlichen Anforderungen für Deine Software aufzunehmen. Im klassischen Requirements Engineering unterscheidet man hier noch einmal zwischen funktionalen und nicht funktionalen Anforderungen, wobei unter den nicht funktionalen meistens Qualitätsanforderungen und Randbedingungen verstanden wird.

Im Gaming-Bereich und bei anderen 2D/3D-Anwendungen haben wir aber natürlich noch wesentlich mehr Anforderungen nicht funktionaler Natur, wie z.B. optische Anforderungen und auch soundtechnische Anforderungen. Aber auch Vorgaben bzgl. Input-/Steuerungsvorgaben usw. sind nicht typische funktionale Anforderungen. Deshalb ist am Ende gar nicht mal so wichtig was für ein Typ an Anforderung etwas ist, sondern vor allem, dass sie festgehalten und bei der Entwicklung berücksichtigt werden.

Um Anforderungen zu dokumentieren, gibt es drei unterschiedliche Möglichkeiten:

  • Du beschreibst Anforderungen in Textform. Hierbei ist natürlich zu beachten, dass der Text auch wirklich genau die Anforderung des Kunden trifft und nicht eine Interpretation des Gesagten vom Kunden darstellt, die ggf. falsch ist.
  • Du dokumentierst Anforderungen in Form von Grafiken und Diagrammen. So kannst Du z.B. Bewegungsabläufe mit Zeichnungen und Pfeilen darstellen oder Tastenkombinationen mit Flussdiagrammen darstellen (was passiert wenn ich die und die Taste und danach eine andere Taste drücke…).
  • Du nutzt sogenannte Simulationen. Darunter versteht man z.B. Referenz-Produkte, Mock-Ups oder Prototypen. Gerade das Nutzen von Referenz-Anwendungen ist eine sehr einfache Möglichkeit etwas zu beschreiben, nach dem Motto „So wie die Funktion in diesem Game soll sich jenes und welches verhalten“. Dieses Verfahren eignet sich übrigens auch sehr gut, um z.B. Sounds und Soundtracks zu definieren. Denn es ist sicher einfacher bei Klängen einen Referenz-Sound (oder Soundrack) zu nennen, als diese mit Worten zu beschreiben.

Das schöne ist, dass Du natürlich diese drei Techniken je nach Anforderung auch beliebig kombinieren kannst. Wichtig ist nur, dass Du am Ende die Anforderung so genau wie möglich dokumentierst, damit die Entwickler nachher keine Fragen haben wie etwas gemacht werden sollte. Deshalb solltest Du bei der Anforderungsanalyse auch darüber nachdenken, was der Entwickler oder Grafiker noch ggf. wissen muss.

Glossar

Sehr oft kommt es vor, dass einige Parteien der Anforderungsaufnahme unterschiedliche Fachsprachen sprechen. So meinst Du vielleicht mit „Unity“ die Entwicklungsumgebung, der Kunde versteht darunter aber vielleicht die Benutzeroberfläche für Ubuntu. Es können aber auch die unterschiedlichen Fachabteilungen des Kunden sein, die unterschiedliche Vorstellungen von internen Fachbezeichnungen haben.

Aus diesem Grund ist es notwendig die genutzten Fachbegriffe und Abkürzungen einmal in einem Glossar zusammen zutragen und zu definieren.

Übrigens, manchmal merkt man erst beim Definieren von Fachbegriffen, dass die unterschiedlichen Parteien verschiedene „Sprachen“ sprechen 😉

Abnahme

Wenn Du am Ende nun fertig bist, muss der Kunde natürlich auch nochmal das gesamte Anforderungsdokument prüfen und abnehmen.

Denn nur so kannst Du sicher sein, dass Du die Anforderungen auch richtig dokumentierst hast.

Vertragliche Auswirkungen von Anforderungsdokumenten

Nicht selten sind Anforderungsdokumente auch Bestandteil von Beauftragungen, also Verträgen. Deshalb muss auch darauf geachtet werden, ob einzelne Kundenanforderungen Muss- oder Kann-Anforderungen sind, und ob diese gleich bei der Initialauslieferung enthalten sein sollen oder auch später nachgeliefert werden können.

Solche Unterschiede müssen natürlich in den Anforderungsdokumenten entsprechend berücksichtigt und kenntlich gemacht werden. Achte also darauf, wie Du eine Anforderung dokumentierst. So ist es ein gewaltiger Unterschied, ob die App etwas erfüllen „muss“ oder etwas erfüllen „sollte“.

Fazit

Wie Du siehst ist das Aufnehmen von Anforderungen kein Hexenwerk, es sollten aber unbedingt einige Dinge beachtet werden.

In dem Eingangs erwähnten Buch Business Analysis und Requirements Engineering* (Amazon-Partnerlink) von Peter Hruschka wird natürlich noch viel Tiefer in die einzelnen Themen eingetaucht, die ich oben eigentlich nur grob angerissen habe. So, wird z.B. auch darauf eingegangen wie man mit Anforderungen in „lebenden“ Anwendungen umgeht, die z.B. regelmäßige Releases haben (z.B. bei Online-Games) oder wie man nachvollzieht wie und wo bestimmte Anforderungen umgesetzt wurden. Wenn Du Dich also mehr mit dem Thema beschäftigen möchtest, kann ich das Buch nur empfehlen.

Aber um einen guten Einstieg zu erhalten, was Du am Anfang eines Projektes machen kannst, um am Ende einen zufriedenen Kunden zu haben, sollte dies auf jeden Fall reichen 🙂

Wenn Dir dieser Artikel gefallen hat, würde ich mich sehr freuen, wenn Du ihn über Deine sozialen Kanäle teilst! Wenn Du zudem bereits selber Erfahrungen mit dem Aufnehmen von Anforderungen gemacht hast oder einfach Deine Meinung kundtun möchtest, dann kannst Du mir diese auch gerne unten in den Kommentaren mitteilen!

Gruß,

Dein Carsten

Comments
  1. Moe
  2. Carsten
  3. Michi
  4. Carsten