Requirements Engineering ist ein wesentlicher Teilschritt eines Software Entwicklungsprozesses. Im Rahmen eines Moduls Software Engineering, das den gesamten Prozess abdecken soll, steht hierfu¨r jedoch nur wenig Raum fu¨r die Ausbildung zur Verfu¨gung. In diesem Paper wird beschreiben, wie - neben der erforderlichen Wissensvermittlung - in der Kombination von einem verpflichtenden Praktikum mit einer Vorlesung Fallanalyse, Dokumentation und Qualita¨tssicherung eingeu¨bt werden. Ausgangspunkt der kompetenzorientierten Gestaltung ist dabei die Ermittlung eines geeigneten Learning Outcomes, aus dem die Lehrform im Sinne des Constructive Alignment abgeleitet wird. Requirements Engineering ist ein wesentlicher Baustein im Software Entwicklungsprozess. Fehler, die in diesem Schritt gemacht werden, wirken sich extrem stark auf das Endprodukt aus. Dieses gilt fu¨ r klassische Entwicklungsprozesse ebenso wie f u¨r agile Prozesse, da auch innerhalb eines kurzen Sprints die jeweiligen Anforderungen klar sein mu¨ ssen. Mit den Themen des Requirements Engineerings kann man inzwischen ein ganzes Modul f u¨llen. Oftmals ist das Requirements Engineering allerdings nur Teil eines oder mehrerer Software Engineering Module innerhalb des Curriculums der Informatik-Ausbildung. Entsprechend wenig Zeit steht zur Verfu¨ gung. Was sind die wesentlichen Teile, die vermittelt werden sollen? Die Erfassung von Requirements; psychologische Aspekte; Kano-Modell; Lasten-/Pflichtenheft oder User Stories und Tasks; Requirement-Engineering Tools; formale Spezifikation; Dokumentation, Qualita¨tssicherung, Tracing, Maintenance der Requirements, ... sind nur einige der Aspekte. Besser ist die Frage, was die Studierenden mitnehmen sollen? Was ist fu¨ r sie an dieser Stelle der Ausbildung wichtig? Was sollen sie am Ende der Software Engineering Module Copyright c 2016 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors.
wissen und vor allem ko¨nnen? Da der Requirements-Prozess dem Design-Prozess vorgelagert ist und sich das Design auf die Requirements bezieht, ergibt sich die Frage, was man fu¨r einen guten Design-Prozess beno¨tigt? Offensichtlich gute Requirements! Man kann die Frage aus Sicht des Entwicklungsprozesses also reduzieren auf die Kernfrage: ”Was sind gute Requirements?” Aus Sicht der Studierenden bedeutet diese Kernfrage, sie sollen in der Lage sein, gute Requirements zu erstellen. Die erstellten Requirements sollten angemessen strukturiert, schriftlich erfasst und von entsprechend hoher Qualita¨t sein. Wichtig dabei ist, dass die Studierende selber Requirements aufschreiben und deren Qualita¨t pru¨fen und beurteilen ko¨nnen. Studierende haben oft Schwierigkeiten mit dem Formulieren entsprechender Texte. Gerade hierin besteht ein hohes Potential der Weiterentwicklung auf Seiten der Studierende. Ein weiterer didaktischer Aspekt ist, dass Ma¨ngel und Fehler bei anderen besser erkannt werden als bei einem selber, was bei der Ausbildung der Qualita¨tssicherung genutzt werden kann. 2
Aus diesen U¨ berlegungen heraus wurde das Learning Outcome [Ke08, BT07] fu¨r den Teilbereich des Requirements Engineering innerhalb des Software Engineering Moduls im 3. Semester entwickelt. Aus diesem Learning Outcome ko¨nnen dann untergeordnete Learning Outcomes abgeleitet und schließlich in Lehreinheiten u¨berfu¨hrt werden (vgl. [LB15]). Das hier entwickelte Learning Outcome folgt der Form, die von Oliver Reis [ASD, Re13] vorgeschlagen wurde: ”Die Studierenden ko¨nnen als Ausgangspunkt weiterer Entwicklungen Requirements systematisch dokumentieren, indem sie 1.) die Wu¨nsche des Kunden, die Abla¨ufe und den Kontext identifizieren, 2.) strukturiert dokumentieren und 3.) geeignete Qualita¨tssicherungsmaßnahmen durchfu¨hren.” Um dieses Ziel zu erreichen, wa¨re eine ideale Ausbildungsform die Begleitung eines erfahrenen Requirements Engineers, die Verhandlung mit einem echten Kunden, sowie die Ausarbeitung von Requirements, die in einem industriellen Entwicklungsprozess eingesetzt werden. Die Qualita¨t in der Ausfu¨hrung dieser Prozessschritte wu¨rde dabei gepru¨ft und benotet werden. Unter den Rahmenbedingungen der Hochschule ist dieser Aufwand einer solchen Individualbetreuung nicht realisierbar. Standardlehrmethoden (vgl. [MHV12]), wie Gruppenpuzzle oder a¨hnliches, greifen unserer Meinung nach auch nicht. In der Informatik der HAW Hamburg sieht der Rahmen eines Moduls derzeit wie folgt aus: seminaristische Vorlesung an 12 Terminen mit nicht-verpflichtender Teilnahme, ca. 45 Studierende. Der Vorlesung sind vier Labortermine zugeordnet. Typischerweise besteht eine Laborgruppe aus 12-16 Studierende pro Termin. Die Teilnahme ist verpflichtend und ist Pru¨fungsvorleistung. Aufgaben im Praktikum werden in dieser Vorlesung in 4er Teams durchgefu¨hrt. Didaktisch wichtiger Aspekt des Laborpraktikums ist somit, dass alle Studierenden einer Praktikumsgruppe verpflichtend im gleichen Zeitraum am gleichen Ort sind, zusammen mit den Betreuern. Hieraus ergibt sich eine personelle Planungssicherheit fu¨r die eingesetzte Lehrmethode.
Es stehen fu¨r das Thema Requirements Engineering und somit zum Erreichen des Learning Outcomes zwei Vorlesungstermine (insgesamt 4-6 h) und ein Labortermin (3 h) zur Verfu¨gung. Das Lehrkonzept aus Vorlesung und Labor sieht deshalb wie folgt aus: Die Vorlesung wird mit seminaristischem Unterricht fu¨r die Wissensvermittlung, Diskussion und fu¨r integrierte U¨bungen verwendet. Der Labortermin wird zur abschließenden gemeinsamen Arbeit an einem Thema genutzt. Die Bearbeitung der Laboraufgabe ist wesentlich, da hier die Studierenden das vermittelte Wissen anwenden sollen und dieser Prozess durch die Betreuer beobachtbar ist.
Der Labortermin ist dabei folgendermaßen konzipiert: Die Studierenden erhalten die Fallbeschreibung eines technischen Systems im Umfang von ungefa¨hr einer Seite. Im letzten Semester war es die Beschreibung des autonomen Fahrzeugs, das am Carolo Cup [FAU] teilgenommen hat. Die Fallbeschreibung muss den Kunden ersetzen, da das Fu¨hren eines Gespra¨ches zur Requirements-Erhebung zu viel Zeit in Anspruch nehmen wu¨rde. Einzelne Aspekte in der Fallbeschreibung sind ausreichend schwammig oder interpretierbar formuliert, um die Problematik eines ”unwissenden” Kunden zu verdeutlichen. Auch wird in der Fallbeschreibung der Kontext - in diesem Fall das Fahrzeug und der Wettbewerb - thematisiert; Teile der Bearbeitung beziehen sich dagegen auf die Steuerungssoftware, die in ihrer Funktionalita¨t nicht explizit beschrieben wird.
Als Vorarbeit muss der Text analysiert, der Systemkontext ermittelt werden, sowie zusammen mit einem Use Case, Requirements und ausgewa¨hlten Testfa¨llen dokumentiert werden. Hierdurch werden die Punkte 1 und 2 des Learning Outcomes, die Erhebung und Dokumentation der Anforderungen, angesprochen.
Die erste Version an Requirements wird am Beginn des Labortermins abgegeben und einer Schnellpru¨fung durch den Dozenten unterzogen. Sie gilt als Zulassung zum Termin und soll vornehmlich pru¨fen, ob die nachfolgenden Schritte mit der eingereichten Lo¨sung durchgefu¨hrt werden ko¨nnen.
Die restliche Zeit des Labortermins von ca. 3 h wird fu¨r die Durchfu¨hrung eines ReviewProzesses genutzt. Dazu werden die Lo¨sungen der 4er-Teams jeweils einem anderem Team zum Review und zur Erstellung einer Ma¨ngelliste gegeben. Hierdurch wird der 3. Punkt des Learning Outcomes, die Qualita¨tspru¨fung, angesprochen.
Im Praktikumslabor werden Review-Stationen aufgebaut, d.h. es wird jedem Team ein Beamer oder Großbildschirm zur Verfu¨gung gestellt sowie ein Computer fu¨r das Fu¨hren des Protokolls. Oftmals kann letzteres entfallen, da die Studierenden ihre eigenen Laptops verwenden. Wichtig ist, dass das Team und die Dozenten das zu pru¨fende Dokument gemeinsam betrachten ko¨nnen.
Das Review erfolgt strukturiert mit einem Moderator/Protokollant und Reviewern im Sinne eines moderierten Technical Reviews. Der Moderator wa¨hlt die zu betrachtenden Punkte aus, d.h. einen Abschnitt oder nur ein einzelnes Requirement. Nach einer kurzen ruhigen Denkphase, gesteuert durch den Moderator, werden die Reviewer um ihre Meinung gebeten. Die Reviewer mu¨ssen zuna¨chst alle ihre Meinung zu dem Punkt abgeben, erst danach wird die Diskussion ero¨ffnet. Der Moderator soll explizit darauf achten, dass alle zuna¨chst ihre Meinung ungesto¨rt a¨ußern ko¨nnen. Das Ergebnis der Diskussion wird vom Moderator festgehalten. Dann geht es zum na¨chsten Punkt. Die Moderatoren sollen nicht mitdiskutieren und die Rolle des Moderators wechselt innerhalb des Teams nach ca. 20-30 min. Alle Studierende aus dem Team sollen mindestens ein mal die Rolle des Moderators inne haben.
Das strikte Vorgehen aus Auswahl, Ruhe, Meinungen a¨ußern und Diskussion hat folgende Hintergru¨nde, die den Studierenden auch erla¨utert werden: Erfolgt keine konsequente Einhaltung des Vorgehens, so werden zu viele u¨ber das Dokument gestreute Aspekte gleichzeitig diskutiert. Erfolgt sofort eine freie Diskussion, so setzen sich immer die Alpha-Tiere durch und das Gespra¨ch konzentriert sich schnell auf einige wenige Aspekte des betrachteten Abschnitts. Durch die Ruhephase und das einzelne Abfragen der Reviewer haben die introvertierteren Studierenden Zeit zum Denken und ko¨nnen und mu¨ssen sich ungesto¨rt a¨ußern. Die Moderatoren sind aufgefordert auch bei der Diskussion gezielt auf ruhige Kommillitonen zu achten. Nebenbei ist ein ”ich schließe mich der Meinung an” in der ersten Runde nicht zula¨ssig, d.h. selbst schwache Studierende mu¨ssen mindestens den Vorredner in eigenen Worten wiederholen. Falls Zeit vorhanden ist, kann man den Unterschied in der unstrukturieren und der strukturierten Vorgehensweise im Rahmen der Vorlesung demonstrieren.
Die Reviews erfolgen unter Beobachtung des Dozenten und des Labormitarbeiters. Diese wandern zwischen den Teams und beobachten zuna¨chst aus dem Hintergrund, da sich die Studierenden sonst sofort kontrolliert fu¨hlen. Nach und nach wird von der Dozentenseite steuernd eingegriffen.
Von Dozentenseite wird auf die Einhaltung des Prozesses und der Rolleneinteilung geachtet, ebenso auf die Zeiteinteilung, da alle Teilbereiche des Dokuments begutachtet werden sollen und nicht in 3 h nur der Systemkontext intensiv bearbeitet wird. Weiterhin werden Hinweise zum Review gegeben. Stimmt der Kontext, werden Synonyme verwendet, wird hier nicht gerade ein Passivsatz verwendet? Diese Aspekte sind den Studierenden aus Vorlesung und einer beigelegten Checkliste bekannt, werden aber oft nicht angewendet oder wahrgenommen. Es erfolgt zunehmend die Aufforderung, Texte auf die sprachliche Goldwaage zu legen. Gerade hierbei wird dann der Unterschied zwischen dem, was man meint zu lesen und dem, was dort wirklich steht offenbar (vgl. [Sc01]). Gezielt wird hier eine U¨ bersensibilisierung betrieben, da aus der Vergangenheit genu¨gend Beispiel gibt, wo kleine Missinterpretationen zu Katastrophen fu¨hrten, wie beispielsweise dem Mars Climate Orbiter [St99]. Auf solche Beispiele wird vorab im Rahmen der Vorlesunge eingegangen. Am Ende werden die Ma¨ngellisten den Autoren u¨bergeben und die Ma¨ngel sollen innerhalb von einer Woche als Nacharbeit behoben werden. Es erfolgt dann noch eine stichprobenartige Kontrolle der u¨berarbeiteten Versionen durch den Dozenten.
In der Abschlussrunde des Praktikums als Stand-up Meeting wird sichtbar, dass nun die Studierenden auch bei ihren eigenen Versionen deutliche Ma¨ngel sehen. Insbesondere was sie meinten zu schreiben und was sie wirklich geschrieben haben. Durch das Spielen mit Sprache entwickelten einige Studierende auch einen deutlichen Spaß wa¨hrend der Bearbeitung der Aufgabe. So sollte beispielsweise das Fahrzug an einer Stop-Markierung kurz anhalten. Daraus wurde das Requirement ”Die Steuersoftware soll mit Hilfe der KameraDaten Stoppmarkierung auf der Fahrbahn erkennen und kurz anhalten.” gemacht. Aus dem Kontext ist das Requirement versta¨ndlich, nimmt man den reinen Text, so muss die Software kurz anhalten. 3
Bis zum Wintersemester 2015 wurde im Modul Software Engineering eine Klausur als Pru¨fungsform gewa¨hlt. Im Themenbereich Requirements Engineering wurden dabei vorwiegend Wissens- und Versta¨ndnisfragen gestellt. Daneben wurde eine Liste von Requirements gegeben, die deutlich ma¨ngelbehaftet war. Die Ma¨ngel sollten lokalisiert und benannt werden. Das Schreiben von Requirements oder das Erstellen eines Use Cases wird (noch) nicht gefordert, da der Aufwand der Bewertung als zu hoch angesehen wird (Pru¨fungso¨konomie). Hier muss im Rahmen der Mo¨glichkeiten der Pru¨fungsvorleistung auf das Erreichen eines Mindestmaß geachtet werden.
Ab dem Wintersemester 2015 erfolgt eine mu¨ndliche Pru¨fung. Hier ist vorgesehen, dass die Studierenden auf Basis einer mu¨ndlichen Fallbeschreibung Requirements formulieren oder Teile eines Use Cases formulieren sollen. Hier kann dann direkt u¨ber das Vorgehen oder die erzielte Qualita¨t als Pru¨fungsgespra¨ch diskutiert werden.
Indirekt erfolgt eine weitere Pru¨fung im nachgelagerten Modul Embedded System Engineering, in dem die Vorlesung Software Engineering 2 eingebettet ist. Im Rahmen dieses Moduls mu¨ssen die Studierenden als Projekt eine Steuerungssoftware fu¨r eine Produktionsanlage erstellen. Hierbei mu¨ssen die Methoden und Techniken aus Software Engineering 1 angewendet werden und unter anderem aus der allgemeinen Aufgabenbeschreibung die Requirements erstellt und umgesetzt werden. 4
Aus Dozentensicht ist diese Art der Laborgestaltung konsistent im Sinne eines Constructive Alignment [BT07] mit dem Learning Outcome. In der Klausur wird neben Wissensfragen auch die Beurteilung und Aufdeckung von Ma¨ngeln gefordert. Hierdurch wird auf verschiedenen Taxonomiestufen [Bl72] gepru¨ft, was derzeit noch ein Mangel in der Pru¨fungsform bzw. der Aufgabenstellungen darstellt. In der mu¨ndlichen Pru¨fung kann direkt die Anwendug des Wissens gefordert und beobachtet werden.
Ein Evaluierung des Konzeptes auf Basis von Klausurergebnissen hat nicht statt gefunden. Dieses ist auch schwierig, da mit dieser Neukonzipierung sich der Abschnitt Requirements Engineering deutlich gea¨ndert und damit auch die Pru¨fungsanforderungen/aufgaben gea¨ndert haben. Als Indiz soll nun das Verhalten in der nachfolgenden Veranstaltung beobachtet werden, ob hier die Methoden und Werkzeuge des Software Engineerings im Rahmen des Projekts selbstversta¨ndlicher und konsequenter angewendet [ASD] [BT07] [FAU] [Ke08] [LB15] [Re13] [Sc01] [St99] werden. Parallel findet ein zweiter Durchgang des Moduls Software Engineering 1 unter Beru¨cksichtigung des vorgestellten Konzepts statt.
Es kann daher bisher nur folgende Beobachtung fu¨r den Lernerfolg herangezogen werden: Die Studierenden kommen mit einer Lo¨sung ins Praktikum, die sie zwar mit mittlerem Aufwand erstellt haben, aber doch ihrer Meinung nach eine solide Lo¨sung darstellt. Am Ende des Praktikums sind diese Meinungen zum Teil deutlich revidiert und zwar nicht durch Ru¨ckmeldung der Betreuer, sondern auf Basis der eigenen Betrachtung. Auch das u¨bertrieben akribische Betrachten der Anforderungsvorschla¨ge mit bewusst missverstandener und dabei oft komischer Interpretation motiviert und sensibilisiert die Studierenden. In einem anderen Fallbeispiel fu¨r die Software eines Garagentorantriebs wurde das vorgeschlagene Requirement ”Das Garagentor wird mit Hilfe der Fernbedienung geo¨ffnet.” hinterfragt mit ”Nutze ich die Fernbedienung als Hebel und hebel das Tor auf?”. Diese mag zwar Quatsch sein, fu¨hrt aber zu einem sportlichen Hinterfragen des geschriebenen. Wenn man als Dozent auch noch den Spaß am kritischen Arbeiten und Hinterfragen weckt - um so besser. Wenn dann die Studierenden bei nachfolgenden Laboraufgaben sofort die Eindeutigkeit der Aufgabenformulierung monieren, dann kann man diese Frage als Erfolg der Ausbildung werten.
Kompetenzorientiert Lehren, Lernen und Pru¨fen an der HAW Hamburg, http://www.hawhamburg.de/qualitaet-in-der-lehre/asd/kompetenzorientierung.html.
Bloom, Benjamin S.: Taxonomie von Lernzielen im kognitiven Bereich. Beltz Verlag, Weinheim und Basel, 4. Auflage, 1972.
Biggs, J.; Tang, C.: Teaching for Quality Learning. McGraw-Hill Companies,Inc., 2007. FAUST - Fahrerassistenz und autonome Systeme. hamburg.de.