Requirements Engineering: Unterschied zwischen den Versionen

aus Kamelopedia, der wüsten Enzyklopädie
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt.)
Markierung: WK: Sackgassenseite
 
K (Kat & Linkfix)
Zeile 4: Zeile 4:
  
 
'''Requirements Engineering''', auch manchmal Anforderungsanalyse oder
 
'''Requirements Engineering''', auch manchmal Anforderungsanalyse oder
Anforderungserhebung genannt, ist ein Prozess zur Erhebung und Ermittlung
+
Anforderungserhebung genannt, ist ein [[Prozess]] zur Erhebung und Ermittlung
von Anforderungen an ein beliebiges System. Betrachtet man diesen Prozess
+
von Anforderungen an ein beliebiges [[System]]. Betrachtet man diesen Prozess
 
in all seinen Detailstufen und Ausprägungen, so stellt man fest, dass er
 
in all seinen Detailstufen und Ausprägungen, so stellt man fest, dass er
äußerst komplex ist und viele unterschiedliche Personengruppen involviert.
+
äußerst komplex ist und viele unterschiedliche [[Person]]engruppen involviert.
Auch haben eine Menge IT-Gurus, Halbgötter und Volkshelden an der
+
Auch haben eine [[Menge]] IT-Gurus, Halbgötter und Volkshelden an der
 
Erschaffung mitgewirkt, man kann also getrost davon ausgehen, dass
 
Erschaffung mitgewirkt, man kann also getrost davon ausgehen, dass
 
Requirements Engineering rundum gut ist und man damit nichts falsch machen
 
Requirements Engineering rundum gut ist und man damit nichts falsch machen
 
kann sondern alles besser.
 
kann sondern alles besser.
  
Ein System ist in diesem Zusammenhang im weitesten Sinne zu verstehen, also
+
Ein System ist in diesem Zusammenhang im weitesten [[Sinn]]e zu verstehen, also
nicht nur durchschnittlich große Computer wie sie bei Mediamarkt oder auf
+
nicht nur durchschnittlich große [[Computer]] wie sie bei [[Mediamarkt]] oder auf
dem eigenen Schreibtisch stehen, sondern Computer in allen Formen und
+
dem eigenen Schreibtisch stehen, sondern Computer in allen [[Form]]en und
Farben, vom binären Kleinod bis zum elektrosynaptischen Gigahirn. Dabei
+
[[Farbe]]n, vom binären Kleinod bis zum elektrosynaptischen Gigahirn. Dabei
 
macht sich Requirements Engineering vor allem um das Gedanken, was hinter
 
macht sich Requirements Engineering vor allem um das Gedanken, was hinter
solchen Büchsen steckt. Also die Software, die dem Stück Designerblech die
+
solchen Büchsen steckt. Also die [[Software]], die dem [[Stück]] Designerblech die
nötige Denkleistung verschafft. Dank schlauer Software, die uns Arbeit
+
nötige Denkleistung verschafft. Dank schlauer Software, die uns [[Arbeit]]
abnimmt, konnten wir Kamele z.B. endlich mit dem Denken aufhören und
+
abnimmt, konnten wir [[Kamel]]e zum [[Beispiel]] endlich mit dem Denken aufhören und
anfangen, planlos und gedankenverloren durch die Wüsten zu wandern.
+
anfangen, planlos und gedankenverloren durch die [[Wüste]]n zu wandern.
  
 
Die Fachkräfte des Requirements Engineering geben sich gerne die
 
Die Fachkräfte des Requirements Engineering geben sich gerne die
Zeile 28: Zeile 28:
 
Qualifikationen eines herausragenden Systemanalytikers gehört es nicht nur,
 
Qualifikationen eines herausragenden Systemanalytikers gehört es nicht nur,
 
sich blitzschnell in die Denkweise eines Systems versetzen zu können (einer
 
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
+
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
 
dieser Situation reagieren?“). Er muss darüber hinaus auch ein Spezialist
und Kenner der unterschiedlichsten gebräuchlichen Mundarten sein, z.B. den
+
und Kenner der unterschiedlichsten gebräuchlichen [[Mund]]arten sein, z.B. den
 
wichtigen Personen nach dem Mund reden, den unwichtigen Leuten den Mund
 
wichtigen Personen nach dem Mund reden, den unwichtigen Leuten den Mund
 
abquatschen, den Entscheidern den Mund wässrig und sich selber dabei
 
abquatschen, den Entscheidern den Mund wässrig und sich selber dabei
Zeile 38: Zeile 38:
  
 
Requirements Engineering, kurz auch RE genannt, können Sie prinzipiell
 
Requirements Engineering, kurz auch RE genannt, können Sie prinzipiell
überall und zu jeder Tageszeit anwenden. Zur Ausübung brauchen Sie im
+
überall und zu jeder [[Tag]]eszeit anwenden. Zur Ausübung brauchen Sie im
Prinzip erst einmal gar nichts, nicht mal ein System selbst. Sie sollten
+
[[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
+
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
 
sind. Wenn Sie kein System gebrauchen oder Systeme generell nicht ausstehen
können, ist Requirements Engineering definitiv nichts für Sie.
+
können, ist Requirements Engineering definitiv nichts für [[Sie]].
  
 
Requirements Engineering wird vor allem dann praktiziert, wenn:
 
Requirements Engineering wird vor allem dann praktiziert, wenn:
  
1.    ein System am Ende der Entwicklung besonders gut funktionieren soll.
+
1.    ein System am Ende der [[Entwicklung]] besonders gut funktionieren soll.
  
 
2.    das System von seinen Benutzern am Ende auch gemocht werden 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.
+
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
 
4.    man so wenig Rückgrat hat, dass jeder dahergelaufene IT- Experten
einem seine Vorschläge aufs Auge drücken kann.
+
einem seine Vorschläge aufs [[Auge]] drücken kann.
  
  
 
'''Requirements Engineering im Detail'''
 
'''Requirements Engineering im Detail'''
 +
 
Um dem Prozess des Requirements Engineering einen halbwegs
 
Um dem Prozess des Requirements Engineering einen halbwegs
 
wissenschaftlichen Anstrich zu verpassen, hat man sich kurzerhand dazu
 
wissenschaftlichen Anstrich zu verpassen, hat man sich kurzerhand dazu
Zeile 64: Zeile 65:
 
''1.  Erheben''
 
''1.  Erheben''
  
Hier werden allerlei Techniken eingesetzt, um sämtliche Anforderungen an
+
Hier werden allerlei [[Technik]]en eingesetzt, um sämtliche Anforderungen an
ein zu entwickelndes System aus Kamel und Maschine heraus zu kitzeln. Dabei
+
ein zu entwickelndes System aus Kamel und [[Maschine]] heraus zu kitzeln. Dabei
 
können die unterschiedlichsten Verfahren zum Einsatz kommen. Wichtig ist
 
können die unterschiedlichsten Verfahren zum Einsatz kommen. Wichtig ist
hier vor allem Masse, Kreativität und Raffinesse. Denn Sie wissen ja
+
hier vor allem [[Masse]], Kreativität und Raffinesse. Denn Sie wissen ja
bereits, je komplizierter, desto wissenschaftlicher, desto toller. Wenn Sie
+
bereits, je komplizierter, desto [[wissenschaft]]licher, desto toller. Wenn Sie
 
Ihr System am Ende des Prozesses allerdings wieder wegschmeißen wollen (und
 
Ihr System am Ende des Prozesses allerdings wieder wegschmeißen wollen (und
 
sich z.B. doch für ein iPhone entscheiden), können Sie sich die restlichen
 
sich z.B. doch für ein iPhone entscheiden), können Sie sich die restlichen
Zeile 78: Zeile 79:
 
identifizierten Anforderungen akribisch aufzuschreiben. Im Prinzip ergibt
 
identifizierten Anforderungen akribisch aufzuschreiben. Im Prinzip ergibt
 
das Ganze nicht mehr als ein schlecht geführtes Vokabelheft mit zwei
 
das Ganze nicht mehr als ein schlecht geführtes Vokabelheft mit zwei
Spalten für mindestens acht unterschiedliche Sprachen.
+
Spalten für mindestens acht unterschiedliche [[Sprache]]n.
  
 
''3.  Prüfen''
 
''3.  Prüfen''
Zeile 86: Zeile 87:
 
Aufgabenbereiche für beinharte Spezialisten. Hier gibt es etwa die
 
Aufgabenbereiche für beinharte Spezialisten. Hier gibt es etwa die
 
Rabiatoren, die Zer-Hacker, die Abrissdirnen, die Demonteure oder auch die
 
Rabiatoren, die Zer-Hacker, die Abrissdirnen, die Demonteure oder auch die
C-Sharpshooter . Je nach Projekt sind aber noch viele weitere Spezialisten
+
C-Sharpshooter . Je nach [[Projekt]] sind aber noch viele weitere Spezialisten
 
im Einsatz. Eine Anforderung hat es nicht leicht, gegen solch eine wilde
 
im Einsatz. Eine Anforderung hat es nicht leicht, gegen solch eine wilde
 
Horde zu bestehen. Erst im Anschluss dieses digitalen Martyriums hat das
 
Horde zu bestehen. Erst im Anschluss dieses digitalen Martyriums hat das
Zeile 101: Zeile 102:
 
dabei keine einzige dieser wuseligen Requirements aus den Augen zu
 
dabei keine einzige dieser wuseligen Requirements aus den Augen zu
 
verlieren.
 
verlieren.
 +
 +
 +
[[Kategorie:Computer]]
 +
[[Kategorie:Herdenverhalten]]
 +
[[Kategorie:Kommunikation]]

Version vom 31. März 2010, 14:43 Uhr

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. doch für ein iPhone 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.