20100708o Sophist Molekulares Requirements-Engineering

 Home | News | Hefte | Mediadaten | Online-Artikel | Kommentare | Trends | Wir-ueber-uns | Tipps | Impressum | CeBIT 2012

»manage it« als

E-Paper  5-6 2011
E-Paper  3-4 2011
E-Paper  1-2 2011
E-Paper  11-12 2010
E-Paper  9-10 2010
E-Paper  7-8 2010
E-Paper  5-6 2010
 

Molekulares Requirements-Engineering (M-RE)

Der Bauplan einer perfekten Anforderung

Anforderungen in der Systementwicklung sind unverzichtbar. Sie tragen praktisch die Grundinformation eines Systems in sich. Man könnte mit Fug und Recht behaupten, Requirements-Engineering lebt von den Anforderungen. Und ein Projekt lebt vom Requirements-Engineering. Diese schicksalhafte Wechselbeziehung ist indes tiefgreifend: Das eine kann nicht ohne das andere existieren. Gute Anforderungen haben heilende Wirkung. Sie sind im Grunde so etwas wie die Antioxidantien im Kampf gegen schädliche Projektkrebszellen. Wir sollten daher besonders umsichtig mit unseren Anforderungen umgehen und sie dementsprechend pflegen. Denn sind sie erst einmal durch fahrlässige Behandlung in Mitleidenschaft gezogen worden, können sie sich nur unter großer (vor allem finanzieller) Kraftanstrengung erholen.

ir möchten Ihnen folgenden Beitrag zeigen, wie Sie Ihre Anforderungen so resistent und fehlerfrei wie möglich machen. Und das gelingt Ihnen, indem Sie bei der Grundstruktur einer jeden Anforderung ansetzen und ihren internen Bauplan optimieren. Wir führen Sie ein in die Grundlagen des Molekular-RE. Keine Sorge: Das Ganze funktioniert gänzlich ohne Doppelhelix und Stammzellendaten. Alles was Sie dazu brauchen sind ein paar Schablonen. 

Wissenschaftliche Ausgangslage & Gegenstandsbereich

Die Gesamtheit der Anforderungen an ein System bildet die sogenannte Anforderungsspezifikation. Die Ausgangsbasis für eine Anforderungsspezifikation schaffen wir, indem wir sämtliche Stakeholder möglichst umfassend nach ihren Meinungen, Wünschen und Befürchtungen zu einem zu entwickelnden System befragen. Alternativ existieren eventuell bereits erste vage Beschreibungen des Systems durch einige Stakeholder selbst, beziehungsweise in Form der Dokumentation von Alt- beziehungsweise Vorgängersystemen. All diese Beschreibungen versuchen wir dann Satz für Satz in ihre Bestandteile zu zerlegen und jede Information zu erfragen, die noch fehlen könnte, um auf die wirkliche Essenz der Aussagen zu stoßen. Ein sehr aufwendiges und langwieriges Verfahren, gegen das es jedoch per se nichts einzuwenden gibt, können doch sämtliche Anforderungen aus diesem gesammelten Datenfundus konstruktiv und analytisch erhoben werden. Dennoch werden Sie bei stilistisch sehr unterschiedlichen Anforderungen enden. Vor allem dann, wenn nicht in der Muttersprache oder von unterschiedlichen Personen formuliert wird.

____________________________________

Anforderung: Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen muss, beziehungsweise von einem Benutzer (Person oder System) zur Lösung eines Problems oder Erreichung eines Ziels benötigt wird.

Quelle: Klaus Pohl & Chris Rupp

____________________________________

Stakeholder: Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.

Quelle: Klaus Pohl & Chris Rupp

Antworten unterscheiden sich nicht nur in ihrer Satzstellung, Wortwahl und den verwendeten Begriffen, sondern vor allem auch in inhaltlicher Hinsicht. Es gelingt wahrscheinlich keiner Stakeholdergruppe, ein und denselben Sachverhalt mit all seinen Aspekten auf Anhieb vollständig zu nennen und zu beschreiben. Zudem werden semantisch ähnliche, aber nicht zwangsläufig tatsächlich sinnverwandte Wörter verwendet, wie zum Beispiel »Kunde/Ausleiher« oder »zuweisen/abbilden«. Letztendlich lebt jeder Stakeholder in seiner eigenen Wirklichkeit und die Frage stellt sich, ob es überhaupt möglich ist, dass alle Beteiligten ein gemeinsames einheitliches Verständnis von dem zu erstellenden System entwickeln können.

Solch eine Problematik ist bereits seit langer Zeit Gegenstand intensiver wissenschaftlicher Forschung. Angefangen bei den Sophisten des antiken Griechenlands über Ludwig Wittgenstein, Gottlob Frege bis hin zu Noam Chomsky und John Searle sowie vielen anderen modernen Linguisten und Philosophen. Sie alle beschäftigten sich mit Fragen dieser Art:

·                     Wie »funktioniert« Sprache?

·                     Was ist die innerste Natur von Sprache?

·                     Wie lässt sich Sprache formal beschreiben?

·                     Wie lernen Menschen Sprache?

·                     Können sich Menschen durch Sprache überhaupt angemessen verständigen?

Wir müssen also festhalten, dass die Beschäftigung mit Anforderungen als sprachlich autonome Einheiten eine komplexe Angelegenheit ist. Ihre Substanz sind sprachliche Zeichen und damit verbunden sind leider auch sämtliche Probleme, die eine sprachliche Kommunikation mit sich bringt. Um diese Schwierigkeiten zu berücksichtigen, ist ein verlässlich genaues Vorgehen dringend notwendig.

Das Sophist-Anforderungslabor für angewandte Mikroanalyse

Die Gedanken der Philosophie wollen wir nun übertragen auf ein etwas konkreteres Wissensgebiet. Wir wollen Ergebnisse und die erzielen wir am besten mit messbaren Methoden der Forschung. Anforderungen sollten nicht wahllos und willkürlich geschrieben werden. Dazu sind sie zu komplex. Sie müssen kontrolliert und vor allem zentral erstellt werden. Unser hauseigenes Anforderungslabor kümmert sich deswegen vor allem um die Aufzucht der Jüngsten unter ihnen. Das bedeutet, dass wir unsere Schützlinge von ihrer allerersten Stunde an begleiten. Solche behüteten Anforderungen verfügen über völlig andere Dispositionen, wenn sie von Kindesbeinen an gepflegt und umsorgt werden. Sie sind wesentlich robuster und gesünder als ihre vernachlässigten Artgenossen. Werden sie nämlich erst zu einem späteren Zeitpunkt umsorgt, also dann wenn sie nachweislich bereits erkrankt sind, könnten die Aufwände zu ihrer Medikation die anvisierten Zeit- und Kostenrahmen eines Entwicklungsprojektes mit Leichtigkeit sprengen. Den besten Schutz erhalten Anforderung also bei ihrer Entstehung. Zu diesem Zweck haben unsere Requirements-Ingenieure die Anforderungsschablonen entwickelt, die Ihnen bei der Konstruktion und bei der Qualitätssicherung von Anforderungen behilflich sind. Sie erzeugen damit von Grund auf gesunde und qualitativ hochwertige Anforderungen.

____________________________________

Anforderungsschablone: Eine Anforderungsschablone (Requirements Template), auch Satzschablone genannt, ist ein Bauplan für die syntaktische Struktur einer einzelnen Anforderung.

Quelle: Klaus Pohl & Chris Rupp

Schablonen bestimmen vordergründig bereits die syntaktische Ordnung einer Anforderung. Eine Anforderungsschablone ist demnach ein Bauplan, der die Struktur eines einzelnen Anforderungssatzes festlegt. Wenn solch ein Bauplan einer Anforderung zu Grunde gelegt wird, schränkt dies die Fehlerhaftigkeit von Anforderungen um ein Vielfaches ein, etwa lassen sich dann typische Formulierungsfehler von vorn herein vermeiden. Im Folgenden werden wir auf solche Schablonen genauer zu sprechen kommen.

Die RE-Biosynthese – Anforderungsmutation per Baukasten

Hier sehen Sie, wie die Anforderungsschablonen konkret aussehen und welche Schritte Sie durchführen müssen, um die einzelnen Bestandteile des Bauplans mit Inhalt zu füllen.

Abbildung 1: Anforderungsschablone

Eine Anforderungsschablone bildet den Grundstrukturplan für Ihre Anforderungen. Die unterschiedlichen Bestandteile der Schablone betrachten wir als separate Elemente beziehungsweise Platzhalter, die Sie mit den jeweils passenden Substanzen füllen müssen. Diese einzelnen Elemente beziehungsweise Glieder der Schablone stehen dabei in einer äußerst feinfühligen Beziehung zueinander. Wie ein hochempfindliches Nervengerüst geben sie die Impulse der einzelnen Glieder an die nächsten weiter und optimieren sich gewissermaßen im Kollektiv selbstständig. Sie sollten daher Ihre Schablone stets mit Bedacht füllen. Fügen Sie an einer Stelle die falsche Substanz ein, kann dies die Gesamtstruktur Ihrer Anforderung empfindlich stören. Um dies zu vermeiden liefern wir Ihnen hier einen kurzen Beipackzettel mit, bei dessen Beachtung die Implantierung der Schablone zum reinen Kinderspiel wird.

Schritt 1: Legen Sie fest, wie wichtig Ihnen die Anforderung ist. Auf die Auswahl dieser sogenannten »rechtlichen Verbindlichkeit« kommen wir zu späterem Zeitpunkt noch einmal zurück.

(1)  Das System muss / sollte / wird ...

Schritt 2: Identifizieren Sie die geforderte Funktionalität.

Im Mittelpunkt jeder Anforderung steht die geforderte Funktionalität (wie drucken, speichern, übertragen, berechnen usw.), die wir im Folgenden mit dem Begriff Prozess bezeichnen.

Prozesse sind Vorgänge oder Tätigkeiten und sollten ausschließlich durch Vollverben definiert werden – den sogenannten Prozesswörtern. Vollverben sind die Verben eines Anforderungssatzes, die die alleinige Funktionalität auf sich vereinen. Weitere Verben im selben Satz würden zu gefährlichen semantischen Unschärfen führen. Die Funktionalität bildet im Prinzip das zentrale Nervensystem einer Anforderung und Sie sollten darauf achten, auch wirklich nur eine dieser empfindsamen Steuereinheiten einzusetzen. Prozesswörter stellen daher die wichtigste Füllsubstanz für Ihre Anforderungen dar. Sie sind elementare Leiterelemente und werden später noch einmal ausführlich behandelt.

(2) Das System muss drucken.

Schritt 3: Legen Sie die Art der geforderten Funktionalität fest. Eng mit dem Prozesswort verknüpft ist die Systemaktivität. Bemühungen diese zu klassifizieren zeigen, dass folgende drei Arten von Systemaktivitäten für das Schreiben von Anforderungen relevant sind:

·         Selbstständige Systemaktivität: Das System startet den Prozess selbstständig und führt den Prozess auch selbstständig aus. Der Benutzer tritt dabei nicht in Erscheinung.

·         Benutzerinteraktion: Das System stellt dem Benutzer eine Funktion beziehungsweise Interaktionsmöglichkeit zur Verfügung. Mit dem Benutzer ist in Abgrenzung zur dritten Möglichkeit immer ein Mensch gemeint.

·         Schnittstellenanforderung: das System führt einen Prozess in Abhängigkeit von einem Dritten (etwa ein Fremdsystem, nicht aber ein Benutzer) aus, ist an sich passiv und wartet auf ein externes Ereignis.

Je nach intendierter Aussage einer Anforderung kann also deren Struktur drei verschiedene Varianten annehmen, indem sich das Prozesswort an einer der drei möglichen Funktionalitäten ausrichtet. Die selbstständige Systemaktivität erfordert keine Umstrukturierung der Schablone gegenüber Schritt 2. Nur wenn Sie Ihre Anforderung für eine Benutzerinteraktion oder Schnittstellenanforderung ausrichten wollen, müssen Sie ihren Bauplan modifizieren.

Ihnen mag die Frage auf den Lippen liegen, ob nicht auch eine Anforderung an die Benutzerinteraktion einfach nur eine Schnittstellenanforderung ist. Das stimmt bis zu einem gewissen Grad: Bei einer Schnittstellenanforderung ist unserem System gleichgültig, welches System an die entsprechende Schnittstelle angedockt ist. Bei einer Benutzerinteraktion wird sehr häufig genau spezifiziert, welches Verhalten welcher Benutzergruppe auf welche Art und Weise zur Verfügung gestellt wird. Daher haben wir die Benutzerinteraktion in eine eigene Schablone gepackt, die diesen Aspekt mit spezifiziert. Hier ein paar Beispiele:

(2) Das System muss drucken.

Selbstständige Systemaktivität: Das System löst das Drucken aus. Wir müssen an der Anforderung laut Schablone nichts ändern, da die Funktionalität bereits in Schritt 2 festgelegt wurde und das System die Systemaktivität selbstständig durchführt.

(3) Das System muss dem Mitarbeiter die Möglichkeit bieten zu drucken.

Benutzerinteraktion: Der Benutzer löst das Drucken aus.

(4) Das System muss fähig sein, Geschäftsdaten einer anderen E-Kartei zu empfangen.

Schnittstellenanforderung: Ein eingehendes Ereignis aus einem externen System löst das Verhalten aus.

Schritt 4: Identifizieren Sie das Objekt und dessen Ergänzungen, für das die Funktionalität gefordert wird.

In all unseren Anforderungen ist keineswegs klar, was gedruckt oder wo gedruckt werden soll. Sprachwissenschaftler würden hierbei von fehlenden Objekten und Ergänzungen sprechen, wirkungspsychologisch ausgedrückt fehlt es an der näheren oder ergänzenden Bestimmung des Prozesswortes und Biochemiker würden einen eklatanten Nährstoffmangel zur Aufrechterhaltung der Anforderungsfunktion diagnostizieren. Es fehlt also noch die dritte wichtige Substanz im Bauplan: Objekte und ihre Ergänzungen. Sie werden in der Anforderungsschablone vor dem Prozesswort eingefügt. Unsere Anforderung sieht demnach so aus:

(5) Das System muss dem Mitarbeiter die Möglichkeit bieten, einen Genehmigungsantrag auf dem Netzwerkdrucker zu drucken.

Objekte sind in Zusammenhang mit dem Prozesswort lebenserhaltend für eine Anforderung. Ohne ihr Mitwirken würde die Kommunikation im Bauplan verebben. Implantieren Sie ausgewählte Objekte deshalb an den richtigen Stellen der Anforderungsanatomie, um ihre Vitalfunktionen zu gewährleisten und zu stärken. Damit liegt eine Anforderung vor, die bereits eine gute gesundheitliche Statur aufweist. Die Qualität können wir allerdings noch steigern, indem wir einen weiteren Schritt unternehmen. Wir können in die Anforderung auch noch Bedingungen integrieren, unter denen ein Prozess ausgeführt werden soll.

Schritt 5: Legen Sie die Bedingungen fest, unter denen die geforderte Funktionalität durchgeführt wird.

Für Anforderungen ist es typisch, dass die geforderte Funktionalität nicht fortwährend, sondern nur unter bestimmten zeitlichen oder logischen Bedingungen ausgeführt oder zur Verfügung gestellt wird. Genau dieses Charakteristikum macht Anforderungen so komplex und filigran. Je komplexer ihre Struktur, desto anfälliger werden sie. Und dies geht erheblich zu Lasten von Eindeutigkeit und Aussagekraft. Um zeitliche von logischen Bedingungen klar zu unterscheiden, empfiehlt unser Testlabor daher für zeitliche Bedingungen die Konjunktionen »nachdem« und »sobald«, um einen Zeitpunkt auszudrücken und die Konjunktion »solange«, wenn wir einen Zeitraum beschreiben wollen. Für logische Bedingungen verwenden wir die konditionale Konjunktion »falls«. Damit sind sämtliche potenziellen Bedingungsverläufe abgedeckt, ohne die Komplexität einer Anforderung unnötig aufzublähen. Bedingungen stehen in einem Nebensatz am Anfang der Anforderung, so dass sie die Bauplanstruktur nicht zerreißen.

Abbildung 2: Schablone mit Bedingung

(6) Nachdem das System die Geschäftsdaten gespeichert hat, muss das System dem Mitarbeiter die Möglichkeit bieten, einen Genehmigungsantrag auf dem Netzwerkdrucker zu drucken.

Nach dem fünften Schritt weist jede nach Anforderungsschablone konstruierte Anforderung eine vollständige Satzstruktur auf. Unabhängig davon ist die Anforderung aber noch nicht perfekt. Eine feste Struktur bietet der Anforderung noch nicht so viel Immunität, um sich vor schädlichen äußeren Einflüssen zu schützen, die in ihrem Inneren zu bösartigen Mutationen führen können. Daher ist es nun an der Zeit, die einzelnen Elemente mit wirkungsvollen Substanzen zu füllen, und zwar mit wohl überlegten und dosierten Substanzen. Damit ist konkret gemeint, die Bandbreite an Ausdrücken und Begriffen für die Platzhalter der Schablone per exakter Definition so weit einzuschränken, dass alle Bezugsfelder und Fachbereiche eines Projekts abgedeckt sind und das Gesamtvokabular für alle Projektbeteiligten überschaubar und verständlich erscheint. Andernfalls könnte der verantwortliche Anforderungsschreiber ein beliebiges Objekt oder Prozesswort wählen und nach persönlichem Gutdünken einsetzen. Die Schablonen nützen allerdings wenig, wenn jeder Autor nach dem allseits beliebten Feuer-frei-Befehl handelt. Aus diesem Grund befassen wir uns im Folgenden mit der semantischen Präzisierung der Anforderungsschablone.

Die stoffliche Zusammensetzung des Bauplans

Um die Anforderung rundum wetterfest zu machen, müssen wir die Bestandteile der Schablone hinsichtlich ihrer Semantik konkretisieren. Denn eine Anforderungsschablone bildet erst mal nur eine elastische und flexible Hülle, die die Bestandteile als syntaktische Platzhalter integriert. Das Auffüllen dieser Bestandteile ist Ihre Aufgabe. Die Anleitung zum Füllen der einzelnen Bestandteile mit den richtigen Substanzen haben Sie ja bereits erhalten. Hüten Sie sich dabei aber vor Stoffgemischen. Solche Experimente haben nachweislich negative Einflüsse auf eine Anforderung. Konkret heißt das: Für die einzelnen Bestandteile innerhalb der Anforderungsschablone müssen semantisch einheitliche und unmissverständliche Begriffsdefinitionen erstellt werden.

Dass unterschiedliche Personen wirklich die gleiche Wortwahl treffen, ist nämlich nur dann möglich, wenn der zur Verfügung stehende Wortschatz begrenzt und die Bedeutung der verwendbaren Wörter eindeutig definiert ist. Jetzt heißt es also: Mundschutz auf, Pipette füllen und ein ruhiges Händchen bewahren, sonst landen die Tröpfchen an den falschen Stellen. Hier sind die wichtigsten Substanzen einer Anforderung nochmal im Detail erläutert.

Das Prozesswort – der IT-Kohlenstoff des Lebens

Prozesswörter bilden das essenzielle Element Ihrer Anforderungen. Ohne sie gäbe es keine Anforderungen und keine Systeme. Anforderungen müssen daher immer ein Prozesswort enthalten. Doch auch hier genügt eine kurze Orientierung an der Natur. Kohlenstoff als Verbindung oder in konzentrierter Form ist Gift. So auch für unsere Anforderung. Ein einzelnes Prozesswort, klar und rein, bedeutet eine ideale Ausstattung. Mehr wird nicht gestattet. Aus gesundheitlichen Gründen gelten hier strikte Vorschriften.

Rein sprachlich gesehen sind Prozesswörter Vollverben. Sie geben die Funktionalität des Systems wieder und damit den Kern der Anforderung. Zur Klarstellung dieser Funktionalität ist es wichtig, genau zu wissen, was der Autor der Anforderung fordert. Abseits unseres sterilen Anforderungslabors bedarf es daher einiger Feldvorbereitung, denn die sorgfältig eingeimpften Prozesswortmoleküle müssen ja schließlich auch erkannt und verstanden werden. Sie können also nicht irgendwelche Prozesswörter verwenden, sondern tunken Ihre Pipette nur in einen Pool eigens ausgesuchter vordefinierter Stoffe. Und das funktioniert am besten so: Geht es in Ihrem Umfeld etwa bei »eingeben«, »einsetzen« und »einfügen« um verschiedene Dinge, müssen Sie das explizit darstellen. Es gilt dabei, die Prozesswörter genauer zu untersuchen und konkret zu definieren. Wir verfolgen hiermit das Ziel, dass jeder Verfasser oder Leser einer Anforderung exakt das gleiche unter einem bestimmten Verb versteht. Als Hilfsmittel dafür eignet sich eine Prozesswortliste im täglichen Gebrauch. Darin werden – wiederum zentral – alle Vollverben, die in den Anforderungen Verwendung finden, gesammelt und definiert. Somit erhalten Sie einen Pool sauberer Prozesswörter. Vorgefertigte Prozesswortlisten in Deutsch und Englisch sowie weitere Informationen zu den Themen Anforderungen und Requirements-Engineering finden Sie auch im Downloadbereich unserer Homepage auf www.sophist.de.

Substantive – Ein Stoffgemisch der besonderen Art

Substantive sind ebenfalls von elementarer Bedeutung für ein Anforderungsleben. Eine Anforderung ohne Substantive wäre funktionsuntüchtig, die in ihr definierte Funktion würde sie ständig auf sich selbst zurückwerfen. Substantive wirken demnach gezielt auf die Anforderungsaktivität. Substantive kommen eher als Verbindung denn als Reinstoff vor: Im Anforderungsbauplan werden die Platzhalter »System«, »Objekte« sowie deren »Ergänzungen« von Substantiven gebildet. Wegen ihrer Häufigkeit ist es gerade hier ganz besonders wichtig, Anforderungen nicht mit irgendwelchen Substantiven zu füttern, sondern, wie bereits bei den Prozesswörtern, auf gereinigtes Material zurückzugreifen. Wie bei den Prozesswörtern gilt auch hier die Regel, die zu verwendenden Substantive zu begrenzen und eindeutig zu definieren. Zu diesem Zweck eignet sich etwa ein Glossar.

Rechtliche Verbindlichkeiten – reaktive Elemente

Rechtliche Verbindlichkeiten muten auf den ersten Blick eher unscheinbar an, haben aber große Auswirkungen auf eine Anforderung. Sie werden von den sogenannten Modalverben gebildet. Diese Modalverben lauten »muss«, »sollte«, und »wird« und beschreiben den Geltungsanspruch einer Anforderung. Die rechtliche Verbindlichkeit ist Gradmesser der Bedeutung, die ein Stakeholder den Angaben in der Anforderungsspezifikation beimisst. In Fachkreisen existieren wesentlich mehr dieser Schlüsselwörter, wir sind jedoch der Meinung, dass obige drei vollkommen ausreichen. Hinsichtlich ihrer Bedeutung unterscheiden sich unserer Modalverben wie folgt:

·         Der Ausdruck muss wird benutzt, um verpflichtende Anforderungen zu definieren, deren Erfüllung für das Produkt vorgeschrieben ist.

·         Der Ausdruck sollte wird benutzt, um wünschenswerte Anforderungen zu definieren. Anforderungen dieser Art sind juristisch nicht verpflichtend, weisen aber auf bestimmte Vorteile für ein Produkt bei entsprechender Berücksichtigung hin.

·         Der Ausdruck wird wird benutzt, um Anforderungen zu definieren, die in der Zukunft integriert werden müssen. Anforderungen mit diesem Schlüsselwort sind demnach verbindlich. Sie helfen, in der aktuellen Entwicklung Vorbereitungen zu treffen, um zukünftige Änderungen später reibungslos zu integrieren.

Und auch hier müssen Sie natürlich wieder praktische Einführungsarbeit leisten: Die Schlüsselwörter für die rechtliche Verbindlichkeit einer Anforderung sowie die exakte Bedeutung dieser Schlüsselwörter müssen festgelegt werden. Dies geschieht am sinnvollsten in einer Tabelle. Eingrenzungen beziehungsweise Erweiterungen der Bedeutung von Schlüsselwörtern stehen ihnen selbstverständlich offen, achten Sie aber unbedingt darauf, dass alle Bedeutungsaspekte widerspruchsfrei und vollständig in der Tabelle aufgeführt sind.

Vom Labor in die Natur – Tipps für die Praxis

Die Anforderungsbaupläne funktionieren nicht nur für technische Systeme. Sie können mit den Schablonen ganz allgemein Systeme jeder Art beschreiben. Damit sind sie vielseitig einsetzbar und verfügen auch über die eigentlichen Projektgrenzen hinaus über einen beträchtlichen Wirkradius. Neben ihrer Allzwecktauglichkeit haben die Schablonen jedoch einen weiteren großen Vorteil. Sie helfen Ihnen nämlich dabei, jede Menge Geld zu sparen. Durch die systematische Dokumentation von Anforderungen werden Widersprüche und Fehler innerhalb einzelner Anforderungen wie auch zwischen Anforderungen untereinander frühzeitig erkannt und können neutralisiert werden. Noch besser: Durch die optimierende Anforderungsstruktur entstehen erst gar keine Fehler und müssen daher auch nicht gefunden werden. Das erspart Ihnen obendrein noch viel Zeit und Arbeit. Voraussetzung dafür ist natürlich, dass eine schablonenbasierte Anforderungsanalyse Projektpraxis wird. Werden im Zuge unterschiedlicher Dokumentationstechniken unausgereifte oder fehlerhafte Anforderungen zu spät bemerkt, kann dies für kostspielige Projekte im schlimmsten Fall das Aus bedeuten. Es wäre nicht das erste Mal. Scheuen Sie die unerhebliche zeitliche Investition zu Projektbeginn nicht und machen Sie die Projektteams mit den Schablonen vertraut. Ihr System sollte es Ihnen Wert sein. Die Qualität dieser Anforderungen ist nachweislich viel höher als Anforderungen in episch ausuferndem Prosatext.

Setzen Sie die Schablonentechnik in erster Linie dann ein, wenn sich in Ihren Projekten die Bereitschaft der Mitarbeiter herauskristallisiert, die Anforderungsschablonen auch wirklich anzuwenden. Neben der reinen Methodenkenntnis müssen Ihre Anforderungsautoren bereit sein, sich einer stark normierten Vorgehensweise zu unterwerfen. Den meisten wird aber sehr schnell bewusst, dass eine Anforderung nach Schablonenart wesentlich einfach zu lesen und vor allem zu verstehen ist, als herkömmliche Anforderungstypen. Außerdem genügen Anforderungen nach Bauplan viel eher den geltenden Qualitätskriterien.

Müssen sie eine Fremdsprache verwenden, sind die meisten Projektmitarbeiter für Templates, Glossare und möglichst klare Vorgaben dankbar. Für die Einführung der Schablonen erstellen Sie ein vier- bis sechsseitiges Dokument, in dem Sie kurz und bündig erklären, was es mit den Schablonen auf sich hat. An einem Beispiel beschreiben Sie die wenigen Schritte, die durchzuführen sind, um die Schablone zu füllen. Dieses Dokument dient als Nachschlage- und Lehrwerk für Ihre Projektbeteiligten. Laden Sie alle Projektbeteiligten, die mit Anforderungen zu tun haben oder haben werden, zu einem Meeting ein. In diesem Rahmen bringen Sie ihnen die Schablonen näher und üben das Schreiben anhand einiger Beispiele. Wichtig ist dabei zunächst nur der Satzaufbau. Geben Sie den Teilnehmern dann noch Ihr vorbereitetes Dokument mit und Sie haben bereits den ersten Schritt der Einführung getan.

Bei der Qualitätssicherung der Anforderungen sollten Sie Folgendes bedenken: Das Lesen von dutzenden gleichstrukturierten Anforderungen stellt eine gewisse Hürde dar, ist ermüdend und erfordert eine Menge Konzentration. Erwarten Sie nicht, dass jemand das gesamte Anforderungsdokument liest. Strukturieren Sie Ihr Dokument so, dass unterschiedliche Leser ohne großen Suchaufwand an genau die Stellen gelangen, die für sie von Interesse sind.

Eine letzte wichtige Erkenntnis aus unserer Projekterfahrung: Nutzen Sie technische Unterstützung! Das erleichtert die Arbeit enorm. Die Verwendung der Anforderungsschablonen und eines begrenzten definierten Wortschatzes lässt sich in Requirements-Management-Tools durch Assistenten/Wizards realisieren. Dadurch, dass sich die meisten Werkzeuge, die für das Dokumentieren und Verwalten von Anforderungen genutzt werden, anpassen lassen, können Sie das »Zusammenbauen« von Anforderungen in einem gewissen Maß automatisieren. Wenn Sie sich durch unseren Artikel angeregt gefühlt haben, sich einen tieferen Einblick in den Gegenstandsbereich zu verschaffen, seien Ihnen nachfolgend einige Quellen zur weiteren Lektüre empfohlen. In diesem Sinne wünschen wir Ihnen viel Erfolg mit der Aufzucht Ihrer neuen Generation von Anforderungen.

Chris Rupp, Rainer Joppich, Christian Wünch

Literatur:

·          Chris Rupp: Requirements-Engineering und –Management. Professionelle, iterative Anforderungsanalyse für die Praxis. Hanser Verlag, München, 2007.

·          Klaus Pohl & Chris Rupp: Basiswissen Requirements Engineering. Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level. dpunkt Verlag, Heidelberg, 2009.

·          Internetpräsenz des International Requirements Engineering Board (IREB): http://certified-re.de/

Die Sophisten im Internet:

Folgen Sie »manage it«

auf Google+

Copyright © 2003-2012  ap Verlag GmbH