Anforderungen ermitteln

Sie wissen bereits, wie Planung grundsätzlich funktioniert. Jetzt kümmern wir uns die Planung von Inhalt und Umfang Ihres Projektes. Wenn die Anforderungen an Ihr Projekt, Ihren Projektgegenstand bereits im Projektauftrag ausreichend beschrieben sind, schätzen Sie sich glücklich und springen gleich in die weiteren Planungsschritte. Leider wird dies oft nicht oder nur unvollständig der Fall sein. Und Sie müssen sich erst im Rahmen der Auftragsklärung und der Anforderungsanalyse mit den Inhalten Ihres Projekts beschäftigen. Die Fachdisziplin hierfür heißt Anforderungsmanagement oder Requirements Engineering. Requirement, Englisch für Anforderung, und Engineering, Englisch für Technik oder Ingenieurswesen. In diesem Film bekommen Sie einen ersten Überblick über diese Disziplin. Die initiale Klärung der Anforderungen mündet in einem systematischen Anforderungsmanagement für Ihr Projekt. Da Anforderungen mitunter die Eigenschaft haben, sich im Laufe der Zeit zu verändern, neu hinzuzukommen oder wegzufallen, das Thema Anforderungsmanagement wird Sie also durch Ihr Projekt begleiten. Wir starten also wieder bei der Frage nach ihrem Projektgegenstand, dem Was. Was für einen Schatz soll Ihr Projekt bergen? Und wie soll dieser Schatz beschaffen sein? Sprich, welchen Anforderungen muss er genügen? Reicht ein kleiner Schatz? Muss es ein Goldschatz sein oder darf es auch ein Silberschatz sein? Wie schwer darf der Schatz sein? Und, und, und. Anforderungen konkretisieren und beschreiben die Ziele für Ihr Projekt. Klar definierte Anforderungen liefern Ihnen überprüfbare Erfolgskriterien für Ihr Projekt gegenüber den anfangs oft noch sehr weichen, unscharfen Beschreibungen in vielen Projektaufträgen. Klar definierte Anforderungen liefern insofern auch Rechtssicherheit. Ein Anforderungsmanagement dient in einem Projekt somit auch als Selbstschutz. Es gibt eine ganze Reihe von Methoden zur Ermittlung von Anforderungen, die wir hier nur streifen können. Als Erstes wären Kreativitätstechniken zu nennen, angefangen von Brainstorming, Mindmaps, morphologischem Kasten usw. Eine weitere Möglichkeit resultiert aus Beobachtungstechniken, egal ob Feldbeobachtung oder Naturbeobachtung, die sog. Bionik. Oder Sie gehen testweise in die Lehre, das Apprenticing. D.h., Sie versuchen Erfahrungen in der Bewältigung einer Aufgabe zu gewinnen, bevor Sie die Anforderungen an einem allgemeinen Lösungsprozess für diese Aufgabe definieren. Weiter zu nennen wären Befragungstechniken. Fragen Sie doch Experten, Nutzer, Kunden oder andere Stakeholder. Sie werden erstaunt sein, welches Wissen bereits vorhanden ist. Auch Vergangenheitsanalyse kann Ihnen helfen, Anforderungen zu identifizieren. Wieso das Rad neu erfinden? Allerdings birgt dies die Gefahr, auch die Fehler der Vergangenheit fortzuschreiben und innovative Ansätze auszublenden. Es gibt aber auch noch weitere unterstützende Methoden, die Ihnen helfen können, Anforderungen zu ermitteln. Angefangen von Anforderungsworkshops, die Definition von Anwendungsfällen, sog. Use Cases, User Stories, wörtlich übersetzt also Benutzergeschichten, und viele mehr. Im Folgenden werden wir im Schnellflug einige Darstellungsvarianten betrachten, um Ihnen ein Gefühl für Anforderungen und Anforderungsermittlungen zu geben. Wir beginnen mit einem Use Case, einem Anwendungsfall. Hier im Beispiel einer Karteikarte mit der Beschreibung des Use Cases. So eine standardisierte Form der Beschreibung erleichtert den Vergleich und später auch die Priorisierung von verschiedenen Use Cases. Ein Use Case beschreibt Anforderungen nicht aus Sicht des Zielsystems, sondern aus Sicht des Anwenders. Es können bereits Akteure identifiziert werden, die beteiligt sind, egal ob Menschen oder Systeme. Vorbedingungen, Ergebnis und Trigger, also fachliche Auslöser, werden beschrieben, genauso wie der Ablauf. Etwas knifflig sind nicht-funktionale Anforderungen. Im Gegensatz zu funktionalen Anforderungen, die beschreiben, was ein System leisten soll, funktional, geben nicht-funktionale Anforderungen an, wie gut ein System etwas leisten soll, also qualitativ. Dahinter verbergen sich Themen wie Usabilität, Sicherheit, Leistungsanforderungen, besondere Qualitätsanforderungen oder weitere Randbedingungen, die ansonsten leicht vergessen werden. Geht es die Entwicklung eines technischen Systems, kann die Interaktion der Akteure mit dem System samt der darin enthaltenen Use Cases in einem System-Use-Case-Diagramm dargestellt werden. Wir haben das System, das Sie im Rahmen Ihres Projektauftrags entwickeln und bauen wollen, Ihre Schatztruhe. In diesem System sollen verschiedene Use Cases bearbeitet, abgewickelt werden. Wie Sie solche Use Cases beschreiben können, haben Sie gerade gelernt. Sie kennen bereits die beteiligten Personen, die Akteure, und wissen, welcher Akteur in welchem Use Case mitwirkt. Neben menschlichen Akteuren gibt es im Rahmen der Use Cases aber auch Interaktionen mit anderen Systemen. Neben den Use-Case-Beschreibungen oder dem System-Use-Case-Diagramm gibt es noch eine Vielzahl von Möglichkeiten, um Anforderungen zu beschreiben, auf die wir hier gar nicht eingehen können, z.B. Snowcards, Aktivitäts- und Sequenzdiagramme und viele mehr. Während das Requirements Engineering historisch seine Wurzeln vor allem in Hardware- und Softwareentwicklung hat, kennen Sie sicher auch Dokumente aus anderen Branchen, die Anforderungen spezifizieren, sei es der Bauplan des Architekten, eine technische Zeichnung, Stücklisten oder andere technische Spezifikationen. Wir können hier nur ganz kurz in die Welt der Anforderungsermittlung hineinschnuppern. Die Bedeutung von Anforderungen für Ihr Projekt sind aber immens, wie Sie gesehen haben. Sie entscheiden über Wohl und Wehe Ihres Projekterfolgs. Sie haben die Anforderungen ganz zu Anfang Ihres Projektes ermittelt. Sie pflegen die Anforderungen während des Projektes laufend weiter, aber spätestens bei den Themen Qualität und Abnahme holen Sie die Anforderungen wieder ein. Gute Anforderungsbeschreibungen berücksichtigen daher auch Qualitäts-, Test- und Abnahmekriterien.