Requirements Engineering

Requirements Engineering, auch manchmal Anforderungsanalyse oder Anforderungserhebung genannt, ist ein Prozess zur Erhebung und Ermittlung von Anforderungen an ein beliebiges System. Betrachtet man diesen Prozess in all seinen Detailstufen und Ausprägungen, so stellt man fest, dass er äußerst komplex ist und viele unterschiedliche Personengruppen involviert. Auch haben eine Menge IT-Gurus, Halbgötter und Volkshelden an der Erschaffung mitgewirkt, man kann also getrost davon ausgehen, dass Requirements Engineering rundum gut ist und man damit nichts falsch machen kann sondern alles besser.

Ein System ist in diesem Zusammenhang im weitesten Sinne zu verstehen, also nicht nur durchschnittlich große Computer wie sie bei Mediamarkt oder auf dem eigenen Schreibtisch stehen, sondern Computer in allen Formen und Farben, vom binären Kleinod bis zum elektrosynaptischen Gigahirn. Dabei macht sich Requirements Engineering vor allem um das Gedanken, was hinter solchen Büchsen steckt. Also die Software, die dem Stück Designerblech die nötige Denkleistung verschafft. Dank schlauer Software, die uns Arbeit abnimmt, konnten wir Kamele zum Beispiel endlich mit dem Denken aufhören und anfangen, planlos und gedankenverloren durch die Wüsten zu wandern.

Die Fachkräfte des Requirements Engineering geben sich gerne die selbstgefällige Bezeichnung „Systemanalytiker“ und sprechen im gleichen Atemzug von der Unentbehrlichkeit ihres Sach- und Fachverstandes. Zu den Qualifikationen eines herausragenden Systemanalytikers gehört es nicht nur, sich blitzschnell in die Denkweise eines Systems versetzen zu können (einer der beliebtesten Kick-Off-Szenarien ist z.B.: „Wie würde der Terminator in dieser Situation reagieren?“). Er muss darüber hinaus auch ein Spezialist und Kenner der unterschiedlichsten gebräuchlichen Mundarten sein, z.B. den wichtigen Personen nach dem Mund reden, den unwichtigen Leuten den Mund abquatschen, den Entscheidern den Mund wässrig und sich selber dabei oftmals den Mund fusselig reden.

Einsatzgebiete

Requirements Engineering, kurz auch RE genannt, können Sie prinzipiell überall und zu jeder Tageszeit anwenden. Zur Ausübung brauchen Sie im Prinzip erst einmal gar nichts, nicht mal ein System selbst. Sie sollten allerdings damit rechnen, am Ende eins zu haben, wenn Sie nicht völlig blöd sind. Wenn Sie kein System gebrauchen oder Systeme generell nicht ausstehen können, ist Requirements Engineering definitiv nichts für Sie.

Requirements Engineering wird vor allem dann praktiziert, wenn:

1. ein System am Ende der Entwicklung besonders gut funktionieren soll.
2. das System von seinen Benutzern am Ende auch gemocht werden soll.
3. man für alles was man tut prinzipiell einen Plan benötigt.
4. man so wenig Rückgrat hat, dass jeder dahergelaufene IT- Experten einem seine Vorschläge aufs Auge drücken kann.

Requirements Engineering im Detail

Um dem Prozess des Requirements Engineering einen halbwegs wissenschaftlichen Anstrich zu verpassen, hat man sich kurzerhand dazu entschieden, das Vorgehen nochmal in vier verschiedene Tätigkeitsbereiche zu gliedern.

1. Erheben

Hier werden allerlei Techniken eingesetzt, um sämtliche Anforderungen an ein zu entwickelndes System aus Kamel und Maschine heraus zu kitzeln. Dabei können die unterschiedlichsten Verfahren zum Einsatz kommen. Wichtig ist hier vor allem Masse, Kreativität und Raffinesse. Denn Sie wissen ja bereits, je komplizierter, desto wissenschaftlicher, desto toller. Wenn Sie Ihr System am Ende des Prozesses allerdings wieder wegschmeißen wollen (und sich z.B. auch für ein iPad entscheiden), können Sie sich die restlichen Schritte getrost sparen.

2. Dokumentieren

Bei dieser Tätigkeit machen sich die Analytiker die Mühe, die identifizierten Anforderungen akribisch aufzuschreiben. Im Prinzip ergibt das Ganze nicht mehr als ein schlecht geführtes Vokabelheft mit zwei Spalten für mindestens acht unterschiedliche Sprachen.

3. Prüfen

Beim Prüfen von Anforderungen gegen eine festgelegte Doktrin ausgewählter und knallharter Testfälle gibt es wiederum unterschiedliche Aufgabenbereiche für beinharte Spezialisten. Hier gibt es etwa die Rabiatoren, die Zer-Hacker, die Abrissdirnen, die Demonteure oder auch die C-Sharpshooter . Je nach Projekt sind aber noch viele weitere Spezialisten im Einsatz. Eine Anforderung hat es nicht leicht, gegen solch eine wilde Horde zu bestehen. Erst im Anschluss dieses digitalen Martyriums hat das System seine Feuertaufe bestanden und darf sich selbst ein System (Abzeichen variieren hier je nach Nation) nennen.

4. Verwalten

Der äußerst bürokratische Akt des Verwaltens hat unübersehbare Parallelen zum früheren preußischen Beamtenapparat auf der einen und zu bewährten Stasi-Spionagetechniken auf der anderen Seite. Hier gilt es nämlich, penibel genau, absolut unbestechlich und mit emotionsloser Methodik und Rationalität jede kleinste Änderung einer Anforderung zu registrieren und dabei keine einzige dieser wuseligen Requirements aus den Augen zu verlieren.

 Siehe besser nicht:  Bürokratenspiel

wiki:Anforderungserhebung