Requirements Engineering - Versionsgeschichte

De Signer: da kannte einer offensichtlich nicht die automatische Zeilenumbruchfunktion

2012-12-30T20:15:28Z

da kannte einer offensichtlich nicht die automatische Zeilenumbruchfunktion

8-D am 30. Dezember 2012 um 19:56 Uhr

2012-12-30T19:56:08Z

62.128.18.243: /* Requirements Engineering */

2010-06-16T11:56:02Z

Requirements Engineering

Ttogun: kat

2010-03-31T12:51:03Z

kat

Ttogun: interwiki

2010-03-31T12:46:08Z

interwiki

Ttogun: Kat & Linkfix

2010-03-31T12:43:07Z

Kat & Linkfix

62.128.18.243: Die Seite wurde neu angelegt.

2010-03-31T12:28:57Z

Die Seite wurde neu angelegt.

Neue Seite

'''
== 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 z.B. 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.

@@ Zeile 1: / Zeile 1: @@
-'''
+'''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 [[Person]]engruppen 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.
-'''Requirements Engineering''', auch manchmal Anforderungsanalyse oder
+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 dem eigenen Schreibtisch stehen, sondern Computer in allen [[Form]]en und [[Farbe]]n, 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 [[Kamel]]e zum [[Beispiel]] endlich mit dem Denken aufhören und anfangen, planlos und gedankenverloren durch die [[Wüste]]n zu wandern.
-Ein System ist in diesem Zusammenhang im weitesten [[Sinn]]e zu verstehen, also
+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 [[Mund]]arten 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.
-Die Fachkräfte des Requirements Engineering geben sich gerne die
+== Einsatzgebiete ==
-selbstgefällige Bezeichnung „Systemanalytiker“ und sprechen im gleichen
+Requirements Engineering, kurz auch RE genannt, können Sie prinzipiell ü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 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:
-.    ein System am Ende der [[Entwicklung]] besonders gut funktionieren soll.
+# ein System am Ende der [[Entwicklung]] besonders gut funktionieren soll.
+# das System von seinen Benutzern am Ende auch gemocht werden soll.
-.    das System von seinen Benutzern am Ende auch gemocht werden soll.
+# man für alles was man tut prinzipiell einen [[Plan]] benötigt.
+# man so wenig [[Rückgrat]] hat, dass jeder dahergelaufene IT- Experten einem seine Vorschläge aufs [[Auge]] drücken kann.
-''2.  Dokumentieren''
+==Requirements Engineering im Detail==
-Bei dieser Tätigkeit machen sich die Analytiker die Mühe, die
+=== 1.  Erheben ===
-identifizierten Anforderungen akribisch aufzuschreiben. Im Prinzip ergibt
+Hier werden allerlei [[Technik]]en 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 [[wissenschaft]]licher, 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.
-''3.  Prüfen''
+=== 2. Dokumentieren ===
-Beim Prüfen von Anforderungen gegen eine festgelegte Doktrin ausgewählter
+=== 3. Prüfen ===
-und knallharter Testfälle gibt es wiederum unterschiedliche
+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''
+=== 4. Verwalten ===
-Der äußerst [[Bürokratie|bürokratische]] Akt des Verwaltens hat unübersehbare Parallelen
+{{sn}} [[Projekt:Bürokratenspiel|Bürokratenspiel]]
 [[wiki:Anforderungserhebung]]

@@ Zeile 52: / Zeile 52: @@
 .    man für alles was man tut prinzipiell einen [[Plan]] benötigt.
-.    man so wenig Rückgrat hat, dass jeder dahergelaufene IT- Experten
+.    man so wenig [[Rückgrat]] hat, dass jeder dahergelaufene IT- Experten
 einem seine Vorschläge aufs [[Auge]] drücken kann.

← Nächstältere Version		Version vom 31. März 2010, 12:51 Uhr
Zeile 108:		Zeile 108:
	[[Kategorie:Herdenverhalten]]		[[Kategorie:Herdenverhalten]]
	[[Kategorie:Kommunikation]]		[[Kategorie:Kommunikation]]
		+	[[Kategorie:Dienstleistung]]

@@ Zeile 95: / Zeile 95: @@
 ''4.  Verwalten''
-Der äußerst bürokratische Akt des Verwaltens hat unübersehbare Parallelen
+Der äußerst [[Bürokratie|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,
@@ Zeile 103: / Zeile 103: @@
 verlieren.
 [[Kategorie:Computer]]
 [[Kategorie:Herdenverhalten]]
 [[Kategorie:Kommunikation]]