Schlagwort-Archive: Wünsche

Bedürfnisse – Wünsche – Funktionen – Anforderungen

Der Anlass für ein neues System sind immer Wünsche und Bedürfnisse, die jemand hat. Man hat z.B. das Bedürfnis mit jemandem zu sprechen, wo immer man sich befindet. Also kauft man sich ein Mobiltelefon. Wenn man dieses eine Weile gebraucht hat wünscht man sich, man könne die am meisten gebrauchten Nummern speichern. Also kauft man sich ein Mobiltelefon mit Speicher. Nach einer Weile wünscht man sich, die Leute, die einem anrufen, könnten eine Nachricht hinterlassen, wenn man den Ruf nicht beantworten konnte. Also abonniert man eine Voice Mailbox. Dann sieht man jemand, der mit dem Mobiltelefon Musik hört oder ein Spiel macht. Also hat man plötzlich den Wunsch, ebenfalls mit dem Mobiltelefon Musik hören zu können, obwohl man von alleine gar nie auf diesen Wunsch gekommen wäre. Etc., etc.

  • Bedürfnisse sind zunächst diffus und allgemein. Sie haben folgende Eigenschaften:
  • Bedürfnisse können sich sowohl auf operative als auch auf strategische Funktionen beziehen
  • Bedürfnisse können nicht scharf formuliert werden
  • Bedürfnisse sind mehr Gefühl als Wissen und können daher nur eingeschränkt kommuniziert werden
  • Man ist sich zu keinem Zeitpunkt allen Bedürfnissen bewusst
  • Bedürfnisse entstehen während man sich mit dem System beschäftigt

Hat man sich lange genug mit dem System beschäftigt, dann werden einem die Bedürfnisse bewusst und man kann sie als Anforderungen formulieren. Dies geschieht aber meistens erst im Verlauf oder gar gegen Ende des Projekts. Anforderungen werden als Funktionen spezifiziert. Auch Eigenschaften eines Systems können als Funktionen formuliert werden. So sind z.B. die räumlichen Masse eines Autos eine Funktion, wenn es darum geht, das Auto in eine schmale Garage einzuparkieren.
Andreas Ninck et al. unterscheiden in Systemik – Vernetztes Denken in komplexen Situationen1 funktionale von nicht funktionalen Zielen. Nicht funktionale Ziele sind nach Ninck z.B. Wartbarkeits- oder Erweiterbarkeitsanforderungen. Aber auch die Wartbarkeit kann man als Funktionen spezifizieren. Z.B. ist die Forderung nach einer Backup-Funktion eine Wartbarkeitsanforderung. Soll ein System ausbaufähig sein, dann muss es Funktionen geben, um zusätzliches Memory oder eine zweite CPU zu erkennen, etc. Ein systemtheoretisch zentrales Thema ist die Lebensfähigkeit eines Systems. Auch diese lässt sich über autopoietische Funktionen diskutieren. Stafford Beer meint, dass ein System sich an seine sich stetig verändernde Umgebung anpassen können muss, damit von Lebensfähigkeit gesprochen werden kann. Es muss seine Identität bewahren, Erfahrungen aufnehmen und verwerten können, und es muss lernen und sich weiterentwickeln können. Das sind alles Systemfunktionen. Beer definiert in seinem Viable Systems Model fünf Systemlevel. Das sind Funktionskomplexe des Unternehmenssystems2. Man kann sich trefflich streiten, ob es nun noch etwas anderes gibt, als funktionale Ziele. Wir wollen zumindest in diesem Blog davon ausgehen, als seien alle Bedürfnisse und Ziele als Funktionen formulierbar.

Definitionen:

  • Bedürfnisse, Wünsche: (erstes) vages Bild mit diffusen Strukturen
  • Funktionen: möglichst klar strukturierte Bedürfnisse; möglicherweise können sich mehrere Funktionen überlappen
  • Anforderungen: Katalog von priorisierten Funktionen (muss, wenn möglich, kann, nice to have, etc.)

1Andreas Ninck, Leo Bürki, Roland Hungerbühler, Heinrich Mühlemann. Systemik – Vernetztes Denken in komplexen Situationen. Verlag Industrielle Organisation. Zürich 2004.

2Malik Management Zentrum. Das Modell Lebensfähiger Systeme (Stafford Beer). St. Gallen, 2006

Zertifiziert für das Unmögliche: Anforderungen formulieren

Wie wir aus dem Artikel Von nichts kommt nichts wissen, lassen sich Anforderungen nie abschliessend formulieren. Das macht die Projektarbeit so schwierig. Neuerdings gibt es schon wieder eine Zertifizierung, nämlich diejenige des Certified Requirements Engineers. Dieses Zertifikat gibt es gleich in drei Stufen, einen Foundation, einen Advanced und einen Expert Level. Und wieder steht eine ganze Industrie dahinter, mit vielen teuren Kursangeboten, Büchern und Instituten. Wieder werden Best Practices vermittelt, aber wenig systemische Erkenntnisse. Als ob Wissen durch pauken zustande käme. Die armen Projektleiter! Sie müssen nicht nur

  • das PM Book of Knowledge vom PMI
  • das CISM Review Technical Information Manual nach COBIT
  • den Spice ISO/IEC TR 15504-6 Standard
  • den CMMI SEI Technical Report CMU/SEI-2006-TR-008
  • das Buch Managing Successful Projects with PRINCE2 und
  • die IT Infrastructure Library, beides vom Office of Government Commerce

auswendig lernen, sondern jetzt auch noch Klaus Pohls Kompendium über Requirements Engineering1, um ihre Projekte genauso erfolglos wie bis anhin durchziehen zu dürfen. Und anstatt wirklich etwas zu lernen, müssen sie die Zertifikate für viel Geld periodisch erneuern lassen.
Das Problem der Anforderungen steht am Anfang eines jeden Projekts. Zu Beginn hat jeder Auftraggeber nur eine vage Vorstellung von dem, was er eigentlich will. Die Vorstellungen verdichten sich zu Bedürfnissen, während er sich mit dem Projektgegenstand befasst. Aus den Bedürfnissen schliesslich kondensieren konkrete Anforderungen. Die Emergenz von Anforderungen ist ein Prozess der Selbstorganisation und kann nicht einfach „engineert“ werden. Meist muss das Projekt schon so gut wie fertig sein, wenn die Anforderungen beginnen, sich heraus zu kristallisieren. Ein Auftraggeber wünscht sich nicht nur Funktionen des zu bauenden Systems. Er will mit dem System vielleicht auch noch andere Ziele erreichen, wie z.B. strategische oder marketingbezogene Ziele. Beispielsweise sind die Hauptfunktionen eines Scannerkassensystems sowohl Schnittstelle zum Inventory System, um die Regale stets gefüllt zu halten als auch die Beschleunigung des Inkassovorgangs, um einen grösseren Durchsatz zu erreichen. Aber das Management könnte mit dem Kassensystem auch weitere Ziele verfolgen, wie z.B. Expansion des Marktanteils durch Einführung einer innovativen Technologie vor der Konkurrenz oder – umgekehrt – Schutz des Marktanteils durch Aufrücken zur Konkurrenz, die diese Technologie bereits früher eingeführt hat. Es ist nun denkbar, dass die Konkurrenz Scannerkassensysteme neu bewertet, noch während das Integrationsprojekt läuft. In diesem Fall muss der Auftraggeber seine Anforderung wieder neu definieren. Das geht aber nicht so schnell, wie es Pohl und seine Mannen gerne sehen möchten2. Die Gegebenheiten eines Marktes sind heute derart volatil, dass es unmöglich ist, die Ziele eines Migrations- oder Integrationsprojektes, das mehrere Monate dauert, zu Beginn abschliessend zu formulieren.

Weiter ist zu bedenken, dass softwareintensive Systeme heute immer weniger dediziert entwickelt werden. Im Allgemeinen werden sie in irgend einem Competence Center eines Herstellers entwickelt und dann auf dem Markt angeboten. Siehe z.B. ERP- und Bankenlösungen oder Softswitch Kommunikationslösungen, etc. Solche Systeme werden als Standardsoftware angeboten und in Integrations- und Migrationsprojekten ausgerollt. Kürzlich musste ich für eine Kommunikationsfirma ein Voice Messaging System migrieren. Das neue System wurde irgendwo in der französischen Provinz entwickelt. Das Migrationsprojekt dauerte ein Jahr und kostete (inkl. HW und SW) ungefähr eine Mio Euro. Natürlich hatte der Kunde Anforderungen. Vielleicht wurden diese durch das System unterstützt, vielleicht war die Entwicklung bereit, kleinere Anpassungen zu machen. „Zum Glück“ wies das System Fehler auf. So konnte der Kunde beim Fixen der Mängel gleich noch ein paar seiner Wünsche mit einfliessen lassen.

Schliesslich weise ich immer wieder darauf hin, dass ein Auftraggeber erst dann die richtigen Fragen stellen und sie klar formulieren kann, wenn er sich eine Weile mit einem System beschäftigt und genügend Wissen über das System hat. Erst im Verlauf des Projekts ist der Auftraggeber in der Lage zu definieren, was er in bezug auf das System eigentlich gerne hätte. Das ist beim Bau eines Einfamilienhauses so und das ist bei der Integration eines komplexen Systems in die IT- und Prozesslandschaft eines Grossunternehmens so. Sogar noch dann, wenn das System bereits eingeführt ist und produktiv läuft wird der Betreiber immer wieder neue Anforderungen und Ausbauwünsche haben.

Anforderungen und Ziele von komplexen softwareintensiven Systemen lassen sich heute wegen der Volatiliät des Marktes nicht mehr abschliessend formulieren und definieren. Theorien des Projektmanagements und seines Umfeldes, wie Requirement Analysis, werden immer noch konventionell, auf einem linearen Ursache-Wirkungsdenken beruhend und ohne Berücksichtigung elementarster systemtheoretischer Tatsachen konzipiert. „Best Practices“ gilt als chic obwohl es reines Frequencey Gambling ist und als das immer wieder zu fehlerhaften Entwicklungen führte3

1Klaus Pohl. Requirements Engineering – Grundlagen, Prinzipien, Techniken. Dpunkt Verlag, Heidelberg 2008 und
Klaus Pohl. Basiswissen Requirements Engineering – Aus- und Weiterbildung zum Certified Professional für Requirements Engineering – Foundation Level nach IREB-Standard.

2Frank Houdek, Klaus Pohl: Analyzing Requirements Engineering Processes: A Case Study. DEXA Workshop 2000: 983-990

3Harald Schaub. Menschliches Versagen. Universität Bamberg. 2000
Beim Frequency Gambling wir diejenige Maßnahme ergriffen, die in den bisherigen (oder ähnlichen) Situationen am erfolgreichsten war. Dies muss nicht notwendigerweise falsch sein, doch kann diese Strategie in neuen, unbekannten Situationen schwerwiegende Konsequenzen mit sich bringen. Innovation und Flexibilität sind dem „frequency-gambler“ Fremdwörter, so dass neuartige Systemeigenschaften gar nicht in Rechnung gestellt werden