• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Qz Req Eng Ebert Rudorfer 2011 V3
 

Qz Req Eng Ebert Rudorfer 2011 V3

on

  • 927 views

Was macht Projekte erfolgreich? Warum scheitern Projekte und liefern nicht das, was ihre Auftraggeber erwarten? Nach wie vor ist unzureichendes Requirements Engineering der Hauptgrund für ...

Was macht Projekte erfolgreich? Warum scheitern Projekte und liefern nicht das, was ihre Auftraggeber erwarten? Nach wie vor ist unzureichendes Requirements Engineering der Hauptgrund für abgebrochene Projekte oder solche, die ihre Ziele nicht erreichen. Technologische Herausforderungen sind per se keine wichtigen Projektrisiken, ihr Management dagegen schon. Doch es gibt auch genügend Projekte, die ihre Ziele erreichen. Grund genug, sich mit den Praktiken des Requirements Engineering auseinanderzusetzen und wesentliche Praxistipps zu geben. Dieser Übersichtsbeitrag basiert teilweise auf dem Buch „Systematisches Requirements Engineering“, das im Dpunkt-Verlag erschienen ist [1]. Unsere Erfahrungen in verschiedenen Industrieprojekten aus einer Vielzahl von Systemen und Anwendungen zeigen, dass ein gutes Verständnis sowie eine systematische Behandlung von Anforderungen erfolgskritisch sind. Wir zeigen mit praktischen Beispielen und einem Praxisbeispiel aus ei-ner sicherheitsrelevanten Anwendung z. B. aus der Medizintechnik, wie Requirements Engineering konkret und erfolgreich umgesetzt wird. Damit können die Kosten für Nacharbeiten um ca. 30% gesenkt werden.

Statistics

Views

Total Views
927
Views on SlideShare
922
Embed Views
5

Actions

Likes
0
Downloads
6
Comments
0

1 Embed 5

http://www.linkedin.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Qz Req Eng Ebert Rudorfer 2011 V3 Qz Req Eng Ebert Rudorfer 2011 V3 Document Transcript

    • Systematisches Requirements EngineeringVersionierung:QZ, 16.02.2011, v3Autor:Christof Ebert, Vector GmbH, Stuttgart, GermanyArnold Rudorfer, Siemens AG, Erlangen GermanyKontaktadressen: Dr. Christof Ebert Arnold Rudorfer Vector Consulting Services GmbH Siemens AG Healthcare Sector Ingersheimer Straße 24 Imaging & Therapy SYNGO D-70499 Stuttgart D-91052 Erlangen Germany Germany Phone: +49-711-80670- 175 Phone: +49-9131-84-2299 Fax: +49- 711- 80670- 444 Fax: +49- 9131-84-8691 E-Mail: Christof.Ebert@vector.com E-Mail: Arnold.Rudorfer@siemens.comLebenslauf der Autoren:Dr. Christof Ebert ist Geschäftsführer und Partner der Vector Consulting Ser-vices. Er unterstützt Unternehmen weltweit bei der Verbesserung der techni-schen Produktentwicklung sowie im Veränderungsmanagement. Zuvor warer fünfzehn Jahre in Engineering- und Führungsfunktionen weltweit in Tele-kommunikation, IT und Transport tätig. Er lehrt an der Universität Stuttgart.Sein Buch „Systematisches Requirements Engineering“ ist das führendePraxisbuch zum Thema und ist gerade in der dritten Auflage bei DPunkt er-schienen.Arnold Rudorfer ist Direktor Software Initiative und Prozess Improvement beiSiemens Healthcare Imaging und Therapy Division (SYNGO). Er ist verant-wortlich für die Einführung von innovativen Software Engineering Technolo-gien, mit dem Ziel, die Entwicklungskosten zu optimieren sowie die Entwick-lungseffizienz zu steigern. Zuvor war er Manager des User Interface DesignCenters von Siemens Corporate Technology in Princeton, NJ (USA). Späterübernahm er die Verantwortung des Global Technology Fields RequirementsEngineering mit Kompetenz Zentren in Princeton, Erlangen, Peking undMünchen. Er ist Koautor des Buches "Software Systems Requirements Engi-neering" (McGraw Hill, April 2009). In der Siemens Software EngineeringCommunity verantwortet er die Organisation von Best Practice SharingEvents.
    • 1Systematisches Requirements EngineeringChristof Ebert, Vector GmbH, Stuttgart, GermanyArnold Rudorfer, Siemens AG, Erlangen GermanyWas macht Projekte erfolgreich? Warum scheitern Projekte und liefern nicht das, was ihre Auftragge-ber erwarten? Nach wie vor ist unzureichendes Requirements Engineering der Hauptgrund für abge-brochene Projekte oder solche, die ihre Ziele nicht erreichen. Technologische Herausforderungen sindper se keine wichtigen Projektrisiken, ihr Management dagegen schon. Doch es gibt auch genügendProjekte, die ihre Ziele erreichen. Grund genug, sich mit den Praktiken des Requirements Engineeringauseinanderzusetzen und wesentliche Praxistipps zu geben. Dieser Übersichtsbeitrag basiert teilwei-se auf dem Buch „Systematisches Requirements Engineering“, das im Dpunkt-Verlag erschienen ist[1]. Unsere Erfahrungen in verschiedenen Industrieprojekten aus einer Vielzahl von Systemen undAnwendungen zeigen, dass ein gutes Verständnis sowie eine systematische Behandlung von Anfor-derungen erfolgskritisch sind. Wir zeigen mit praktischen Beispielen und einem Praxisbeispiel aus ei-ner sicherheitsrelevanten Anwendung z. B. aus der Medizintechnik, wie Requirements Engineeringkonkret und erfolgreich umgesetzt wird. Damit können die Kosten für Nacharbeiten um ca. 30% ge-senkt werden.ProjektrisikenIn ihrer aktuellen Umfrage 2008/9 zur Erfolgsquote von IT-Projekten zeigt die Standish Group, dass32% aller Projekte erfolgreich sind, während 44% ihre Ziele nicht erreichen und 24% komplett abge-brochen werden (Abb. 1 ) [1]. Unzureichendes Requirements Engineering ist dabei nach wie vor derHauptgrund für den Misserfolg. Bedenklicher jedoch ist der aktuelle Trend, der die Autoren sogar dazuveranlasste, die Studie nochmals eingehend zu prüfen und erst mit einem halben Jahr Verzögerungfreizugeben. Wie bereits in der Krise 2002/3 ist die Erfolgsrate auch in der aktuellen Krise wieder ein-gebrochen. Als Hauptgrund nannten die Autoren, dass vorbereitende Tätigkeiten wie Anforderungs-analyse nicht mehr ausreichend gemacht werden. Erfolgsquote von SW- und IT-Projekten 24% Erfolgreich 32% Zu spät oder über Budget Abgebrochen 44% Hauptgründe für Projektprobleme Prozessfähigkeit 91% Organisationsmanagement 87% Requirements Engineering 87%Abb. 1 Unzureichendes Requirements Engineering gefährdet ProjekteDer Kriminalautor Gilbert Keith Chesterton schrieb: „It isn’t that they can’t see the solution. It is thatthey can’t see the problem.“ Und er meint damit, dass wir häufig zu schnell auf eine vermeintliche Lö-sung aufspringen bevor wir das Problem richtig verstanden haben. Hand aufs Herz. Wer kennt nichtdie Szene, dass man in einem Review mit Kunde oder Auftraggeber sitzt und sich ob der Schwerfäl-
    • 2ligkeit in der Bestimmung der Anforderungen am liebsten hinsetzen würde und einfach die Softwareso umzusetzen, wie man es ja bereits eine ganz Zeit verstanden hat. Ist doch nur Zeitverschwendung,sagen sich da viele. Das ist auch der Grund, warum in Krisenzeiten die Problem durch unzureichen-des Requirements Engineering anwachsen. Man meint, Geld sparen zu können, wenn weniger Auf-wand in diese Vorbereitung gesteckt wird.Auf was sollten wir im Requirements Engineering achten? Aus unterschiedlichen Praxiserfahrungenlassen sich die wichtigsten Risiken im Requirements Engineering ableiten. Die Risiken zu kennen,heißt, dass man sich darauf vorbereiten kann, um sie beim nächsten Mal zu vermeiden. Die folgendeListe wurde ursprünglich von drei erfahrenen Praktikern erstellt [2] und ist für diesen Beitrag nochmalsaktualisiert.Risiko 1: Kunden sind unzureichend repräsentiert. Unzureichende Einbeziehung der Benutzerführt zu nicht akzeptierten Produkten und zu unzufriedenen Kunden. Oftmals erscheint es einfacher,die Anforderungen zu Projektbeginn vom Kunden oder Benutzer – oder intern vom Vertrieb oder Mar-keting –zu ermitteln, und danach das Projekt zu beginnen, um diese Anforderungen zu implementie-ren. Häufig übernehmen interne Stellen die Rolle des Kunden, ohne ihn direkt einzubeziehen. DasProblem dabei ist, dass sich das Projekt in zwei getrennte Richtungen entwickelt. Schließlich lernensowohl die Projektmitarbeiter als auch der Kunde ständig dazu. Da der Kunde allerdings nicht weiß,wie er damit umgehen soll, wartet er. Das Gleiche gilt für den Projektmanager, der eine Liste führt,was er beim nächsten „offiziellen“ Projektreview auf den Tisch bringen will. Bei diesem nächsten Pro-jektreview sind dann die Divergenzen sehr viel größer, als wenn es kontinuierliche Konsultationen ge-geben hätte. Eine andere Facette ist, dass es beim Kunden verschiedene Rollen gibt, aber nur dessenEinkauf repräsentiert ist. Auch das führt später zu einem bösen Erwachen, wenn man feststellenmuss, dass der Einkauf primär auf formale Kriterien achtete, aber nicht auf Benutzbarkeit oder Effi-zienz des Produkts. Machen Sie also im Vorfeld die Rollen der Kunden bei der Projektarbeit sehrdeutlich und klären Sie wie bei jedem anderen Projekt (ohne Kundenmitarbeit) vor Projektstart, wasdas Projekt zu liefern hat.Risiko 2: Kritische Anforderungen werden übersehen. Eine der Schlüsselregeln im RequirementsEngineering besagt, dass man dem Kunden das liefern muss, was er will, und nicht das, was erbraucht. So flapsig das klingt – ein wahrer Kern steckt darin. Im Zweifelsfall zählt, was vertraglich ab-gestimmt wurde. Allerdings sollte ein Lieferant im Interesse einer nachhaltigen Kundenbeziehung imVorfeld zu klären, was der Kunde braucht, um dann vor Projektbeginn eine Abstimmung zu erreichenzwischen dem, was gebraucht und gewünscht (also vertraglich festgehalten) wird. Eine wirksame Ba-sis für erfolgreiches Kundenmanagement ist es, zuallererst den Business Case des Kunden zu ver-stehen. Dabei geht es darum zu erkennen, was der Kunde – anders – machen will, wenn er erst ein-mal das gewünschte Produkt in Händen hält. Den Business Case zu verstehen, bedeutet, dass manals Produkt- oder Projektmanager versteht, welche Funktionen oder Anforderungen an das Projektden größten Nutzen bringen. Man versucht, aus der späteren Anwendung innerhalb der Geschäfts-prozesse des Kunden heraus einzuschätzen, welche Anforderungen kritisch sind und ob vielleicht be-stimmte Einschränkungen übersehen wurden.Risiko 3: Qualitätsanforderungen bleiben unberücksichtigt. Anforderungen haben verschiedeneAusprägungen, wie wir gesehen haben. Neben den funktionalen Anforderungen gibt es die Qualitäts-anforderungen, wie beispielsweise Performanz, Benutzbarkeit oder Sicherheit. Zudem gibt es gibt esauch noch Randbedingungen an das Projekt oder Produkt, beispielsweise Kosten. Nur die Hinterfra-gung aller dieser Typen macht die Anforderungsdokumentation vollständig. Wichtig wird diese Voll-ständigkeit vor allem auch bei der Testspezifikation. Testfälle müssen alle diese Kategorien von An-forderungen abdecken.Risiko 4: Unkontrollierte Änderungen von Anforderungen. Anforderungen, die sich ständig ändernund deren Änderungen nicht beherrscht werden, führen zu Kosten- und Terminüberschreitungen undreduzieren die Qualität. Häufig existiert eine gewisse Basis von Anforderungen, mit denen dann einProjekt gestartet wird. Einige Punkte sind noch offen und sollen rasch geklärt werden. Da das Projektläuft, hat der Kunde manches Mal kein großes Interesse mehr, diese Punkte zu klären. Schließlich
    • 3könnte er bei der Abnahme davon profitieren, wenn nicht alles so läuft, wie abgesprochen, denn dasist die einmalige Chance, komplett neue Anforderungen als Kompensation für diesen Projektfehlerkostenlos zu erhalten. Anforderungen ändern sich in beinahe jedem Projekt. Die Änderungsrate unter-scheidet sich zwischen Projekten und ist abhängig vom Wiederholungsgrad der Technologie bei Liefe-rant und Benutzer und der Anwendung beim Benutzer. Zur Minderung dieses Risikos ist es wichtig,die Änderungsrate zu verfolgen. Zu bestimmten Meilensteinen muss die Änderungsmenge reduziertwerden, um die nächste Phase erfolgreich durchlaufen zu können. Üblich ist es, mit einem Puffer zuarbeiten, der sowohl Schätzungenauigkeiten als auch Anforderungsänderungen abfangen kann. Eineweitere Maßnahme ist die so genannte Rückwärtsplanung von der Übergabe an zurück ins Projekt,um zu erkennen, ab wann der kritische Pfad keine Parallelarbeit als Puffer mehr zulässt. MancherProjektmanager und auch Kunde wird überrascht sein, wie früh im Projekt dies der Fall ist. Als Regelgilt, dass in der zweiten Projekthälfte nur noch sehr wichtige Änderungen zugelassen werden – inzeitkritischen Projekten bereits früher als zur Hälfte. Eine dritte Maßnahme ist schließlich, Änderungengrundsätzlich nur zu diskutieren, wenn eine Analyse der Auswirkungen stattgefunden hat. Andernfallsverschwenden beide Seiten ihre Zeit. In diesem „Spiel“ wird gern gepokert, nur um zu sehen, wie sichder Lieferant verhält. Oftmals genügt daher ein einfacher Projektplan, um zu zeigen, dass die vorge-schlagene Änderung Kosten und Projektdauer unzulässig erhöhen wird.Risiko 5: Beschreibung von Anforderungen als Entwurf. Anforderungsbeschreibungen und Ent-wurfsbeschreibungen sind zwei grundlegend unterschiedliche Dinge. Das leuchtet jedem ein. Es gehtbei den Anforderungen darum, was geliefert werden muss. Bei der Entwurfsbeschreibung geht esdarum, wie die Lösung entwickelt wird. Trotzdem werden diese Was- und Wie-Perspektiven immerwieder vermischt. Häufig geschieht dies aus einer vermeintlichen Zeitersparnis heraus. Man beginntAnforderungen zu notieren. Im Beschreiben kommen erste Ideen zu gegenseitigen Abhängigkeitenund zur möglichen Realisierung, die einfach mit der Anforderung zusammen notiert werden. Selbstwenn man dies in getrennten Teilen der Anforderung macht, sollte es klar sein, dass prinzipiell nieeine 1:1-Abbildung möglich ist. Die nächste Anforderung hat vielleicht überlappende Einflüsse undschon passt das Muster nicht mehr. Schlimm wird es vor allem, wenn sich Anforderungen später än-dern oder gestrichen werden. Wohin mit der teilweisen Analyse, die vielleicht auch noch von anderenAnforderungen gebraucht wird? Hier gilt die klare Regel, immer zwei Spezifikationsdokumente zu hal-ten, nämlich die Liste der Anforderungen (Lastenheft) und die Liste der Lösungsspezifikation (Pflich-tenheft). Verfolgbarkeit durch eindeutige Bezeichner und eventuell eine angepasste Werkzeugunter-stützung erlauben später, auch umfangreiche Änderungen schnell in trockene Tücher zu bekommen.Risiko 6: Anforderungen werden nicht geprüft. Zu stark vereinfachte oder oberflächliche Spezifika-tionen resultieren später in fehlender oder falscher Funktionalität. Aus Zeitgründen und zur Vereinfa-chung werden Anforderungen häufig wortwörtlich von Kunden- oder Benutzerinterviews übernommen.Dies ist allerdings nur eine Rohfassung, die erweitert und präzisiert werden muss. Nehmen Sie sichdie Zeit, Anforderungen mit Reviews und Inspektionen zu prüfen und prüfen zu lassen. Auf der Seitedes Projekts erledigen das die Systemanalysten, Projektmanager, Produktmanager und Tester. Mehr-deutige Anforderungen bedeuten Mehrarbeit im gesamten Projekt. Gerade Tester finden sehr vieleAmbivalenzen, die sonst erst sehr viel später entdeckt werden, wenn sie vielleicht vom Entwickler be-reits falsch implementiert wurden.Risiko 7: Perfektionierung von Anforderungen und Spezifikationen. „Gold Plating“, also Ver-schnörkelungen der Entwickler und Benutzer, bringt unnötige Funktionen, Verzögerungen und zu ho-he Kosten ins Projekt. Entwickler versuchen oft, Anforderungen, die sie verstanden haben, mit Lebenzu füllen, und entwickeln weitere Funktionen, die nie vereinbart wurden. Im besten Fall passiert garnichts, denn der Kunde wird sich hüten, solche verzichtbaren Funktionen zu würdigen. Im Normalfallallerdings wird diese Komplexität unbeherrschbar, weil ja keine Ressourcen dafür vorgesehen wur-den. Jede weitere Funktion bringt Abhängigkeiten zu anderen Funktionen, Sonderfälle, Ausnahmesi-tuationen – und damit zusätzlichen Entwicklungs-, Korrektur- und Testaufwand. Anforderungen sollenwiderspiegeln, was der Kunde als relevant betrachtet. Wenn sich Kunde oder Benutzer nicht sichersind, werden sie weggelassen. Das Gleiche gilt für Spezifikationsdokumente. Dies sind Dokumente,die straff beschreiben, was oder wie gearbeitet wird. Es sind keine detaillierten Entwurfsbeschreibun-
    • 4gen. Hilfreich ist es, von vornherein mit verschiedenen Dokumenten zu arbeiten, so dass Entwurfsent-scheidungen von Beginn an im richtigen Dokument – also der Architektur- oder der Entwurfsbeschrei-bung – dokumentiert werden, ohne den Umweg über ein Spezifikationsdokument, wo solche Informa-tionen nicht hingehören. Im Unterschied zu diesen Verschnörkelungen sollten allerdings Ausnahme-behandlungen der regulären Anforderungen durchaus mit dem Kunden geklärt und als Erweiterungder Anforderung spezifiziert werden. Use-Cases beispielsweise haben bereits in ihrem Template einesolche Ausnahmebehandlung vorgesehen. Wird die Behandlung von Ausnahmen nicht vorab abge-stimmt, kann dies zu sehr verwickelten und inkonsistenten Realisierungen führen.AnforderungenEine Anforderung beschreibt, was der Kunde oder Benutzer vom Produkt erwartet (Bedingungen, At-tribute, Ziele, Nutzen etc.). Formal lassen sich Anforderungen wie folgt definieren [1,6]: Eigenschaft oder Bedingung, üblicherweise vom Kunden festgelegt, um ein Problem zu lösen oder ein Ziel zu erreichen. Eigenschaft oder Bedingung, die ein System oder eine Systemkomponente erfüllen muss, um ei- nen Vertrag, einen Standard, eine Spezifikation oder andere formal festgelegte Dokumente zu er- füllen. Eine dokumentierte Repräsentation einer Eigenschaft oder Bedingung wie in den vorigen Punkten beschrieben.Wir trennen klar zwischen Anforderungen und Lösungen. Eine Anforderung beschreibt ein Bedürfnisoder einen Nutzen, der erreicht werden soll. Sie beschreibt nicht, wie dieser Nutzen zu realisieren ist.Diese Implementierungssicht wird durch die Lösung beschrieben. Abb. 2 veranschaulicht diesen Un-terschied durch die Trennung zwischen Problemraum (Marktanforderungen, Lastenheft, etc.) und Lö-sungsraum (Lösungsspezifikation, Pflichtenheft, Design, Fachkonzept, etc.). Der Problemraum ist zu-nächst immer nur unscharf umrissen und wird im Verlauf der Lösungskonzeption eingeschränkt. Marktanforderungen / Kunden- / Benutzer- / Geschäfts- anforderungen / Ziele / Bedürfnisse Warum? Problemraum Produktanforderungen / Eigenschaften / SLA / Service- / Systemanforderungen Was? Lösungsraum Komponenten- anforderungen / Softwareanforderungen Wie?Abb. 2 Anforderungen und LösungenEs gibt nicht die „Anforderung“ schlechthin. Zu einer Anforderung gehört immer die Perspektive ausder sie beschrieben wird. Eine Anforderung ist eine Bedingung oder eine Fähigkeit, die ein Benutzerbenötigt, um ein Problem zu lösen oder um ein Ziel zu erreichen. Das heißt, sie hängt von der Per-spektive ab. Ein Benutzer kann der Kunde sein, der für die Lösung bezahlt, aber es kann auch einEntwickler sein, der daraus eine Architektur ableitet. Entsprechend unterschiedlich sind die Schwer-punkte und Inhalte, die durch diese Anforderung beschrieben werden. Was dem einen die Anforde-rung ist, ist dem anderen die Lösung. Man trennt daher in der Praxis unterschiedliche Arten von „An-forderungen“, beispielsweise Marktanforderungen oder Komponentenanforderungen, und vermeidetvon einer „Anforderung“ ohne Präzisierung zu sprechen.Drei verschiedene Sichten auf Anforderungen werden im Laufe der Lösungskonzeption unterschie-den:
    • 5 Marktanforderungen: Sie werden auch als Kunden-, Benutzer-, Geschäftsanforderungen, Bedürf- nisse bezeichnet. Sie sind die Ziele, die Benutzer und die Außenwelt mit dem zu entwickelnden Produkt erreichen wollen. Sie beschreiben, warum ein Projekt überhaupt durchgeführt wird. Produktanforderungen: Dies sind Eigenschaften des Produkts und Systemanforderungen, die aus der Sicht des Produkts beschrieben werden. Sie beschreiben, was verschieden Benutzer mit dem Produkt machen können in der Sprache des Produkts, also auch nichtfunktionale Anforderungen mit den nötigen Details. Sie definieren den Lösungsraum und die Prioritäten. Komponentenanforderungen: Dies sind die konkreten Softwareanforderungen, die aus Entwickler- sicht beschreiben, wie zu entwickeln ist. Sie umfassen Komponenten, Architektur, Technologien, Struktur und Dynamik sowie Algorithmen. Sie sind hinreichend klar, um eine Komponente durch einen externen Lieferanten entwickeln zu lassen, der den gesamten Systemkontext nicht kennt.Abb. 2 zeigt diese drei Sichten, die sich durch Verfeinerung auseinander ergeben. Offensichtlich istdiese Dreiteilung rekursiv: Die Komponentenanforderung an einen Lieferanten ist dort wiederum eineMarktanforderung. Diese drei Sichten und ihre Trennung sind also nicht im Voraus definiert, sondernhängen von der Lösungsstruktur ab. Beispielsweise könnte ein Benutzer oder Kunde die Anforderungwie folgt stellen:M-Req-11-18: Das System verwaltet die Kundendaten im Format Name, Vorname, Adresse.Der Requirements-Ingenieur spezifiziert dazu eine Lösung mit der folgenden Komponentenanforde-rung:K-Req-11-24: Die Datenbank zur Verwaltung der Kundendaten wird mit Oracle 10 realisiert.Offensichtlich sind dies zwei Anforderungen an die Datenhaltung, die aus verschiedener Perspektivebeschrieben sind, nämlich Nutzung und Realisierung. Nun könnte aber auch der Kunde bereits einetechnische Anforderung zur Realisierung haben, da er eine mySQL-Umgebung einsetzt und Kompati-bilität sowie günstigere Lizenzkosten will. Er spezifiziert:M-Req-11-19: Die Datenbank zur Verwaltung der Kundendaten wird mit mySQL realisiert.Nun wird aus der bisherigen Komponentenanforderung (K-Req-11-24) eine Marktanforderung (M-Req-11-19). Gleichermaßen gibt es Situationen, wo das Lastenheft und die Geschäftsanforderungen sovage sind, dass das Pflichtenheft auch als Problembeschreibung fungiert. Anstatt über solche Feinhei-ten zu debattieren, ist es wichtig, dass die Anforderungen immer mit ihrer jeweiligen Quelle spezifiziertwerden. Dann ist zu jedem Zeitpunkt klar, wie es zur Anforderung kam, und welche Freiheitsgrade füreine Änderung bestehen, so dies die Realisierung erleichtert. M-Req-11-19 lässt sich sehr viel schwe-rer beeinflussen als die konzeptionell gleiche K-Req11-24, da die M-Req-11-19 direkt vom Kundenstammt, und daher unsere Lösung bereits definiert.Requirements EngineeringRequirements Engineering (RE) ist das disziplinierte und systematische Vorgehen (d.h. "Engineering")zur Ermittlung, Strukturierung, Spezifikation, Verifikation, Analyse, Evolution und Verwaltung von An-forderungen unter kundenorientierten, technischen, wirtschaftlichen und erfolgsorientierten Vorgaben.Gutes Requirements Engineering macht den Unterschied aus zwischen einem erfolgreichen Produktund einer Feature-SammlungRequirements Engineering beschreibt die Disziplin innerhalb der Softwaretechnik und der System-technik, die sich mit den gewünschten Eigenschaften und Einschränkungen von Softwaresystemenbefasst. Damit ist gutes Requirements Engineering eine unabdingbare Voraussetzung für gutes Pro-jektmanagement: Das Ziel von Requirements Engineering ist es, qualitativ gute – nicht perfekte – Anforderungen zu generieren, die es erlauben, das Projekt mit einem akzeptablen Risiko zu beginnen.
    • 6 Der Zweck des Requirements Engineering ist es, ein Einverständnis zwischen dem Kunden und dem Softwareprojekt (also dem Lieferanten) über jene Anforderungen zu erreichen, die durch das Softwareprojekt abgedeckt werden.Requirements Engineering ist damit eine sehr bunte und spannende Disziplin. Sie reicht weit über dieSoftwaretechnik hinaus. Sie bedient sich der Erfahrungen aus der Systemtechnik, der Psychologie,der Betriebswirtschaftslehre, dem Marketing, dem Produktmanagement, dem Projektmanagement undnatürlich der Informatik. Durch Requirements Engineering werden Ziele konkretisiert, Wünsche ge-weckt und Realitäten geschaffen. Da es keine absoluten Wahrheiten gibt, kommt dem RequirementsEngineering die einmalige Aufgabe zu, Wahrnehmungen und Ziele zu entwickeln. Requirements En-gineering stellt sicher, dass der Projektmanager das Projekt zu jedem Zeitpunkt unter Kontrolle hat –ohne dass die Eigendynamik aus Kundenbeziehungen, Herausforderungen in der Realisierung undden zahlreichen politischen Risiken ihn zu einem Spielball externer Interessen machen.Requirements Engineering ist die systematische Vorgehensweise (Abb. 3), um alle Anforderungen(also Prozessanforderungen, funktionale und nichtfunktionale Produktanforderungen) zu ermitteln, zu spezifizieren zu validieren, zu analysieren, zu vereinbaren und einem Projekt zuzuweisen, im Projekt zu verwalten und Änderungen konsistent umzusetzen. Requirements Engineering und Management Ermittlung Analyse Vereinbarung Bedürfnisse, Vision, Einschränkungen Markt-, Einflüsse, Prioritäten Projekt, Produkt Marktan- Produkt- Aufwand, Zeitpunkte forderungen anforderungen, Risiko Status Modelle Spezifikation Validierung Komponenten- anforderungen Abhängigkeiten Status Spezifikationen, Testfälle VerwaltungAbb. 3 Aktivitäten und Ergebnisse im Requirements EngineeringWir haben hier bewusst keinen Prozess (also eine Abfolge von Schritten über die Zeit) dargestellt,denn der hängt von den Randbedingungen an das Projekt ab (Abb. 4). Beispielsweise fordert ein agi-les Requirements Engineering mehr Flexibilität und Kundenbeteiligung als ein relativ starres Vorgehenin Konsortien verschiedener Unternehmen. Die Abbildung impliziert aber eine gewisse Ordnung, dieunabhängig vom Vorgehensmodell gilt. Offensichtlich kommt die Analyse der Anforderungen nachderen Ermittlung. Unterschieden wird eher dabei, wie viele Anforderungen sinnvollerweise ermitteltsein müssen, um ein Projekt zu schätzen oder zu starten. Dies erklärt im oberen Teil die Sequenz vonSchritten. Der untere Teil der Spezifikation/Verifikation sowie Verfolgung/Änderungsmanagement istzeitlich nicht limitiert. Änderungsmanagement muss es bis zum Projektende geben, und der Bedarfdafür wird im Laufe des Projekts eher größer.Standardisierte Prozesse schaffen Wiederholbarkeit, Transparenz und Effizienz. Aber, so wenig eseinen einzigen überall gültigen Entwicklungsprozess aus dem Buch gibt, so wenig passt ein einzigerProzess für das Requirements Engineering. Markterfordernisse, Produkte und Projekte sind zu unter-schiedlich, um alle Prozesse über einen Kamm zu scheren. Allerdings kann und sollte es für bestimm-te Projekttypen im Unternehmen definierte Prozess für das Requirements Engineering geben. WennSie beispielsweise eine Produktlinie haben, die sowohl eine Plattform als auch Varianten davon fürKunden produziert, dann macht es sicherlich Sinn, die Variantenproduktion durch einen definierten
    • 7Prozess zu steuern. Ein solcher Prozess könnte beispielsweise Zugriff auf alle existierenden Funktio-nen der ganzen Produktlinie bieten, so dass Entscheidungen zu Durchführbarkeit und Aufwand ver-einfacht und reproduzierbar werden.Prozesse sind durch die Dokumente oder Arbeitsergebnisse am Eingang und Ausgang von Prozess-schritten definiert (Abb. 5) [1,5]. Jeder Prozess bearbeitet bestimmte Dokumente, verändert sie undführt damit schrittweise zum endgültigen Produkt. Definierte Meilensteine und Freigabekriterien in derVerifikation und Validierung sichern eine ausreichende Qualität dieser Dokumente. Die Meilensteineim Produktlebenszyklus prüfen, ob diese Dokumente frei gegeben sind. Im Requirements Engineeringwerden verschiedene Dokumente erzeugt beziehungsweise bearbeitet, auf die nachher weitere Ent-wicklungsschritte aufbauen. Abb. 5 bildet die wesentlichen Arbeitsergebnisse auf die Aktivitäten desRequirements Engineering ab. Anforderungen werden frühzeitig Anforderungen Anforderungen vereinbart. Änderungen erfordern viele ändern sich noch im werden im Projekt Abstimmungen. Projekt. entwickelt. Komplexität Großes Projekt Lange Lebensdauer Hoher Wartungsanteil Wasserfall- Inkrementelle Viele Varianten / modell, Entwicklung Releases V-Modell Mehrere Standorte / Prototyping, Lieferanten evolutionär Kleines Projekt Kurze Lebensdauer Agile Prozesse Ein Standort Unsicherheiten Anforderungen stabil Anforderungen volatil, unbekannt Wenig Kundeneinfluss Starke KundenbeteiligungAbb. 4 Vorgehensmodelle und deren Eignung in Abhängigkeit von ProjekteigenschaftenMit diesen Herausforderungen und dieser zahlreichen externen Einflüssen ist Requirements Enginee-ring aber auch sehr schwierig in der erfolgreichen Umsetzung! Betrachten wir ein einfaches Beispiel,die Änderungen von Anforderungen. Eine gemeinsame Eigenschaft jeglicher Software und damit auchvon Softwareanforderungen ist, dass sich die Anforderungen im Lebenszyklus ständig ändern. Anfor-derungen sind in aller Regel unsicher. Sie ändern sich mit einer monatlichen Rate, die 1-5 Prozentdes gesamten Projektaufwands betragen kann [1,4]. Das heißt, dass sich von Anforderungen, die mitinsgesamt 100 Personenwochen Projektaufwand ursprünglich abgeschätzt wurden, pro Monat Anfor-derungen im Umfang von bis zu 5 Wochen ändern. Diese 5 Wochen relative Änderung sind nicht im-mer mit 5 Personenwochen Aufwand zu erledigen. Stellen Sie sich vor, dass die Änderung erstkommt, nachdem die Anforderung bereits integriert ist. Dann kann eine Änderung ein Vielfaches desursprünglich dafür nötigen Aufwands betragen. Diese Hebelwirkung unterstreicht den Geschäftsnut-zen eines systematischen Requirements Engineering. Was über diesen 5 Prozent Änderungsrate proMonat liegt, gefährdet den Projektverlauf massiv und kann eigentlich nur mit evolutionären Vorge-hensweisen abgefangen werden.Gutes Requirements Engineering stellt sicher, dass der Projektmanager zu jedem Zeitpunkt aus Kun-densicht weiß, welche Anforderungen bereits implementiert, getestet oder freigegeben sind. Er mussdies wissen, um bei Gefahr von Terminüberschreitungen rechtzeitig niedrig priorisierte Anforderungenverschieben zu können.Requirements Engineering ist vor diesem Hintergrund eine Sisyphusarbeit, denn es ist bereits frühklar, dass es Verluste gibt, wenn man nicht aufpasst. Ob die Verluste letztendlich in Ihrem Unterneh-men auftreten oder auf der Kundenseite, ist nahezu egal. Ein Projekt kennt in der Regel nur Gewinneroder Verlierer. Ein Kunde, der zu lange warten muss und der nicht erhält, was er will, ist unzufrieden –
    • 8selbst, wenn das Projekt im Budget abgeschlossen hat. Er wird diese Unzufriedenheit auf vielfältigeArt zum Ausdruck bringen. Requirements Engineering muss also versuchen, diese verschiedenenInteressen und Sichtweisen unter einen Hut zu bringen. Es hat sehr viel weniger technische Aspekteund sehr viel mehr „politische“ und psychologische Aspekte, als man gemeinhin wahr haben will. Ermittlung Analyse Validierung Verein- Verwaltung Arbeitsergebnis barung Vision x Use Case / x Szenario Bewertung x x x x Lastenheft x x x x x Projektplan x x x x Teststrategie x x x Lösungsmodell x x x Pflichtenheft x x x x Releaseplanung x x x Produktkatalog x x Vertrag x x x Abnahme x xAbb. 5 Arbeitsergebnisse und Dokumente im Requirements EngineeringProjekterfahrungen in der MedizintechnikSoftware-intensive medizinische Systeme stehen in einem immensen Marktdruck. Während sie tech-nologisch und hinsichtlich ihrer Sicherheit kompromisslos innovativ sein müssen, fordern die Kranken-häuser und auch Gesundheitskostenreformen eine immer kürzere Zykluszeit bei gleichzeitig ange-spannten Budgets. Requirements Engineering hat eine Schlüsselstelle als Erfolgsfaktor im Gesund-heitswesen. Traditionelle Entwicklungsprozesse, die Innovation und Qualität über einen schwerfälligenProzess erreichten, sind nun mehr selten zeitgemäß. Viele Unternehmen der Industrie ändern ihreEntwicklungsansätze in Richtung iterativer und concurrent Engineering Ansätze [6]. Diese Fallstudiezeigt Erfahrungen und bietet Orientierung hin zu Requirements Engineering in medizinischen Syste-men.Die Innovationsrate im Gesundheitswesen beschleunigt sich ständig, und entsprechend wachsen dieAnforderungen auf die Medizintechnik. Heute sind ein drittel aller Produkte jünger als drei Jahre, Ten-denz steigend. Beispielsweise stieg die Verbreitung von medizinisch-technischen Geräten um 52% imZeitraum von 2000 bis 2009. Software ist heute die Schlüsselkomponente in der Automatisierung vonklinischen Abläufen schlechthin. Der Softwaregehalt eines medizinisch-technischen Geräts lag im Jahr2000 etwa bei 30%. Heute (2011) umfasst der Anteil der Software bei einem Anteil größer 60%. Esgeht dabei zunehmend um lösungsorientierte Interoperabilität klinischer Informationssysteme im Inter-esse kosteneffizienter medizinischer Workflows (Abb. 6). Während die Medizingeräteentwicklung global entwickelt ausgerichtet ist, müssen regulatori-sche Freigaben pro Markt erreicht werden.Ohne ein systematisches Requirements Engineering ist die Wahrscheinlichkeit hoch, dass ein Projektscheitert. Werden beispielsweise die Qualitätsanforderungen missverstanden, entstehen z.B. Proble-me in der Benutzbarkeit und der Performanz. Ärzte und Krankenpfleger sind Entscheidungsträger füroder gegen ein Produkt. Ist das Produkt Portfoliomanagement von der Entwicklung entkoppelt, passendie Funktionen nicht zu den Marktanforderungen. Anforderungsänderungen werden erst zu spät er-kannt und führen zu unnötigen Non-Conformance Kosten. Da klinische Abläufe aufgrund der hohenkombinatorischen Komplexität und einer eher geringen Standardisierung sowie ihres ad-hoc Charak-
    • 9ters nur schwer zu modellieren sind, muss das Requirements Engineering spezifische Techniken fürdie Medizintechnik und das Gesundheitswesen entwickeln.Wir wollen den Nutzen des systematischen Requirements Engineering anhand der Entwicklung derBenutzerschnittstelle für ein klinisches Abrechnungssystem darstellen. Das Projekt wurde mit vierzigMitarbeitern in sechs Scrum Teams (Requirements Ingenieure, UI Designer, Architekten, Produkt Ma-nager, Subject Matter Experten) umgesetzt. Die Dauer war achtzehn Monate. Projektziele waren dasRedesign der Schnittstelle hin zu bessere Benutzbarkeit, da dies das Schlüsselkriterium der Kaufent-scheidung bei klinischen Informationssystemen darstellt. Lean Development wurde mit RequirementsEngineering kombiniert, um die Anforderungen kundenorientiert zu spezifizieren und schrittweise zuverfeinern. Zudem musste ein innovativer klinischer Workflow beispielsweise für das Bettenmanage-ment umgesetzt werden. Im Projekt wurden fünfzehn End-to-End Abläufe mit 160 Lines of Code inJava implementiert, und die neue Benutzerschnittstelle realisiert [9].In einem zweiten Projekt von einem anderen Geschäftsgebiet wurde Produktlinien Requirements En-gineering für die Entwicklung einer bildgebenden Plattform syngo.via eingeführt mit Einsatz von meh-reren hundert Entwicklern an unterschiedlichen Standorten weltweit. Dieses Projekt umfasste mehr alsfünftausend Anforderungen. Auch hier wurden die Ergebnisse erreicht. Fortan bildet der ProduktlinienEngineering Ansatz auch die Grundlage für weitere Verbesserungsmaßnahmen wie etwa die Verkür-zung der Produktentwicklungsdurchlaufzeit über einen Scrum-basierten Entwicklungsansatz. Weiterzeigt eine durchgeführte Kosten-Nutzen Rechnung, dass dieser Ansatz mehrere Millionen Euro anEffizienzsteigerung gesamtheitlich in der Produktdefinition (~25%), Projektplanung (~ 23%), Architek-tur (~ 7%) sowie in der Verifikation (~ 45%) bringt.In den beschrieben Projekten wurden die folgenden Erfahrungen (Best Practices) gemacht, die auchin anderem Kontext nutzbar sind.1. Saubere Trennung von Problem- und Lösungsraum. Die Entwicklung einer Lösung beeinflusstdie Sicht auf eine Problemstellung – und dann somit zu falschen Lösungen führen (vgl. Abb. 2). Mitder sauberen Trennung des Problem- und Lösungsraumes, werden die späteren Änderungswünscheeffektiv reduziert. Weiters liefert diese Praktik, die Möglichkeit, eine Impact Analyse durchzuführen,damit die Änderungen in der Architektur abgeschätzt werden können.2. Entwickeln eines geeigneten Verständnisses von Kundenanforderungen. Kunden haben oftimplizites komplettes Verständnis für die Anforderungen. Jedoch sind diese manchmal schwer in derLage, diese präzise zu artikulieren. Sie wollen einen Nutzen erreichen, der allerdings noch in Spezifi-kationen umgesetzt werden muss. Dazu sollten Anforderungen sollten so früh wie möglich verfeinertwerden. Wir nutzen dazu ein Glossar, das immer den Bezug zur Nutzersprache gewährleistet, sowieRapid Prototyping zur Erstellung von Benutzerschnittstellen Konzepten.3. Nutzung von Storyboards für Workflows mit hohem User Interface Anteil. Dabei dient dasStoryboard als Container für Anforderungen, User Interface Visualisierung sowie Testfälle. Es erlaubt,den Erfolgsfall sowie die Fehlerfälle darzustellen und wird mit Timeboxing iterativ verfeinert. Typi-scherweise kann Microsoft PowerPoint als Werkzeug zur Erstellung der Spezifikation verwendet wer-den.4. Verwendung strukturierter Anforderungen zur Planung und Budgetierung. Am Projektanfangmuss der Aufwand zur Strukturierung spendiert werden. Entsprechend der eignen Erfahrung solltenProjektleiter etwa acht bis zehn Prozent des Projektbudgets veranschlagen. Damit werden Abhängig-keiten zwischen Funktionen besser verstanden und damit Fehler aus unverstandener Komplexität ver-ringert. Nach unseren Erfahrungen ergibt sich die geeignete Anforderungsstrukturierung nach der drit-ten bis vierten Verfeinerung. Damit erreicht man eine Stabilität für die weitere Entwicklung des Projek-tes. Die Anforderungen sollten am besten entlang bestimmter funktionaler (z.B. klinischer) Domänenhierarchisch organisiert werden [6].5. Entwicklung eines geeigneten Traceability Modells. Ad-hoc Verknüpfungen zwischen Anforde-rungen und Ergebnissen von der Spezifikation bis zu den Testfällen und der Dokumentation ohne kla-re Strategie reduziert die Qualität und erhöht Nacharbeiten. Daher muss die Traceability mit einer kla-
    • 10ren Zielstellung und inhaltlichen Orientierung aufgebaut sein (vgl. Abb. 5). Sie sollte die nötigen Arte-fakte, die verknüpft werden müssen definieren, deren Granularität vorgeben, sowie Mechanismen zurMethodik und deren Umsetzung in Werkzeuge beschreiben. Dies ist bei medizinisch-technischen An-wendungen von entscheidender Bedeutung für die Zulassung zum Markt. Wesentlich ist die Pflegeder Abhängigkeitsbeziehungen. Wir empfehlen, die Verantwortungen vorab festzulegen, und den nöti-gen Aufwand einzuplanen. Damit ist eine frühzeitige Einflussanalyse möglich sowie Fortschrittsmes-sung, Kostenkontrolle (Earned Value) und Testfortschritt auf Basis der Abdeckung erreichter Anforde-rungen möglich.6. Disziplinierter Einsatz von Standards und Reviews. Nur mit klaren internen Vorgaben zumRequirements Engineering, den Arbeitsergebnissen sowie Vorgehensweisen und Verantwortungensind die Ergebnisse nachher konsistent und können produktübergreifend für die Lösungsentwicklung,wie sie im klinischen Bereich heute üblich ist, wirtschaftlich genutzt werden. Wir empfehlen den Ein-satz von Industriestandards, die an die Notwendigkeiten des Projektes angepasst werden. Dokumen-tenvorlagen erlauben die Einhaltung von Dokumentationsstandards. Zudem stellen Standards die nö-tige Routine für die Reviews von Anforderungen sicher, die häufig im Projektdruck vernachlässigtwerden – mit aufwändiger und zeitraubender Nacharbeit.Requirements Engineering hat eine Schlüsselstelle als Erfolgsfaktor im Gesundheitswesen. Traditio-nelle Entwicklungsprozesse, die Innovation und Qualität über einen schwerfälligen Prozess erreichten,sind nicht mehr zeitgemäß. Unsere Studien zeigen, dass in der Medizintechnik die Kosten für Nachar-beiten über den Produktlebenszyklus hinweg durch eine Verbesserung des Requirements Engineeringum 30-50% gesenkt werden können.Abb. 6 Integrierte Klinische Workflows (Onkologie Workflow)ZusammenfassungDie Einführung und systematische Umsetzung von Requirements Engineering braucht Aufwand so-wohl in der Entwicklung als auch an ihren Schnittstellen, also Produktmanagement, Produktmarketingund Vertrieb. Häufig wird dieser Aufwand als zu hoch und zu zeitraubend gesehen, so dass die Anfor-derungen weiterhin ad-hoc in das Projekt hineinpurzeln und dort bruchstückhaft und mit vielen Na-charbeiten umgesetzt werden, bis einmal mehr das Projekt seine Ziele verfehlt oder abgebrochenwerden muss. Aus unserer Beratungspraxis sowie den Industrieerfahrungen der Medizintechnik ken-nen wir das Dilemma: Verbesserungen in Methodik, Prozessen, Ausbildung und Werkzeugen werdennicht angegangen, da der Anfangsaufwand, um diese Verbesserungen anzustoßen als zu hoch be-trachtet wird. Daher wollen wir zum Schluss die Nutzen eines systematischen Requirements Enginee-
    • 11ring quantitativ unterstreichen und vor allem konkrete Hinweise geben, wie Sie in Ihrer eigenen Um-gebung den Nachweis führen können, dass sich der Aufwand für das Requirements Engineeringlohnt. Eine weitaus umfangreichere Darstellung der ROI-Konzepte und zugrunde liegenden Projekt-aufwandsdaten findet sich in [1,4,6].Der Nutzen eines guten Requirements Engineering kann an verschiedenen Faktoren festgemachtwerden. Im Folgenden geben wir Anhaltspunkte für die eigene Nutzenrechnung, die wir aus verschie-denen Kundenprojekten in unterschiedlichen Branchen konkret realisiert hatten [1,4,6]. Produktivitätsverbesserung. Typischerweise werden 30-50% des Entwicklungsaufwands für Feh- lerbehebung und nicht entwicklungsbezogene Aktivitäten eingesetzt. Die Hälfte der Fehler kommt direkt aus unzureichenden Anforderungen und unkontrollierten Änderungen. Im Systemtest sind es 80% der Fehler, die von unvollständigen (31%) oder falschen (49%) Anforderungen resultieren. Verbesserte Projektplanung und Ressourcen-Einteilung, weniger Verzögerungen vor Projektstart, eine schnellere Anlaufphase sowie Termintreue aufgrund von bekannten Anforderungen und kla- ren Verantwortungen im Projektteam und im Vertrieb. Mehr Aufwand für Entwicklung und konse- quente Umsetzung und Test der Anforderungen schafft eine Verbesserung der Termintreue und reduziert Verzögerungen auf unter 20%. Kürzere Durchlaufzeiten durch Fokus auf jene Aktivitäten und Inhalte, die Wert schaffen. Über die Hälfte aller Funktionen eines Softwaresystems werden nicht genutzt. Das gilt sowohl in der IT wie auch in technischen Produkten. Weniger Anforderungen reduzieren die Komplexität und machen damit die Projekte verlässlicher sowie die Qualität besser. Weniger Nacharbeiten von inkonsistenten Anforderungen durch Einflussanalyse bei sich ändern- den Anforderungen und Verfolgbarkeit zu den betroffenen Arbeitsergebnissen. Werden die Anfor- derungen so umgesetzt, wie sie vom Kunden oder Benutzer beschrieben werden, führt das zu Nacharbeiten, die im Schnitt 45% des Projektaufwands ausmachen. Wiederverwendung von Anforderungen und davon abgeleiteten Arbeitsergebnissen, beispielswei- se Mechanismen zur Systemsicherheit und zur Benutzbarkeit. Bessere Kundenzufriedenheit durch konsistentes Verständnis über die wirklichen Anforderungen und Entwicklung einer Lösung für die wirklichen Bedürfnisse.Einige dieser Faktoren, wie Termintreue oder weniger Nacharbeiten, schaffen einen unmittelbar greif-baren Nutzen. Andere, wie beispielsweise die Kundenzufriedenheit sind eher opportunistisch undwerden in Form nachhaltig guter Kundenbeziehungen und weiterer Projekte greifbar. Insgesamt zei-gen unsere Erfahrungen, dass eine Verdoppelung des Aufwands für Requirements Engineering hin zu10% des Projektaufwands in den Bereichen Methodik, Prozesse, Training und Werkzeugunterstüt-zung konkret realisierbarem Projektnutzen von über 20% schaffen. Das ist ein ROI von mehr als 4,und damit sind nur die direkt messbaren Vorteile berücksichtigt. Genügend Gründe, dass Sie Ihr eige-nes Requirements Engineering hinterfragen und optimieren.Sidebar: Tipps für die PraxisTrennen Sie bei der Anforderungsentwicklung zwischen der externen Sicht (Marktanforderungen, Be-dürfnisse, Problembeschreibung) und der internen Sicht (Produktanforderungen, Lösungskonzeption,Komponentenanforderungen).Bilden Sie in der Spezifikation der Anforderungen drei Typen von Anforderungen, nämlich Marktanfor-derungen, Produktanforderungen und Komponentenanforderungen. Vermischen sie nicht diese dreiverschiedenen Sichtweisen, denn sie helfen bei der Strukturierung und Entwicklung der späteren Lö-sung und bei der sauberen Behandlung von Änderungen auf einer dieser drei Abstraktionsebenen.Vermischen Sie niemals das Was und das Wie. Beginnen Sie nicht zu früh mit der Lösung, solangenoch nicht klar ist, was die wesentlichen Bedürfnisse sind.Modellieren Sie beim Übergang von der Problembeschreibung (z.B. Lastenheft) zur Lösungskonzepti-on (z.B. Pflichtenheft) sowohl die Systemumgebung als auch die zu entwickelnde Systemarchitektur.
    • 12Beim Übergang zu den Komponentenanforderungen muss die Systemarchitektur bereits hinreichenddetailliert sein, um Auswirkungen von Entwurfsentscheidungen (z.B. Partitionierungen) bewerten zukönnen.Antworten Sie immer auf der Basis der Konsequenzen auf den Projektplan, falls es zu Änderungsvor-schlägen kommt. Begeben Sie sich nie in eine Situation, in der Änderungswünsche isoliert von denAuswirkungen im Projekt und der Rückwirkung auf andere Funktionen behandelt werden.Berücksichtigen Sie alle Anforderungen. Fragen Sie relevante Interessenvertreter, ob etwas überse-hen worden ist. Machen Sie dabei klar, dass die Ermittlung von Anforderungen noch keine Garantiefür deren Lieferung ist. Geliefert wird nur, was vereinbart und bezahlt wird.Betrachten Sie Requirements Engineering als projektbegleitend. Requirements Engineering ist nichtmit dem Erfassen von Anforderungen abgeschlossen. Als Prozess begleitet es die weitere Entwick-lung bis zum Projektabschluss und darüber hinaus in die Betriebs- und Wartungsphase – bis zum Le-bensende.Setzen Sie Methodik und Werkzeuge im Requirements Engineering situativ ein. Ein Werkzeug alleinbringt keine Verbesserung. Die Basis für gute Ergebnisse ist Systematik und Disziplin. Zuerst mussein schlanker Prozess für das Requirements Engineering für alle Projektbeteiligten (auch Vertrieb)verpflichtend vereinbart werden. Der Prozess kann durch sehr einfache Spreadsheets unterstütztwerden. Werkzeuge werden dann eingeführt, wenn sie einen messbaren Vorteil bringen.Überlegen Sie sich gut, was Sie mit einem Werkzeug erreichen wollen. Was billig aussieht, bleibt esnicht. Hausgemachte Werkzeuge auf der Basis von Datenbanken wachsen oftmals in einen Bereich,wo ein kommerzielles Werkzeug im unteren Kostenbereich sehr viel günstiger gewesen wäre. Grund-sätzlich gilt heute, dass kein Unternehmen mehr solche Werkzeuge selbst machen sollte – außer Siewollen es anschließend verkaufen oder aber im Bereich von kundenspezifischen Dienstleistungeneinsetzen.Optimieren Sie das Requirements Engineering, und Sie werden in den Projekten beträchtlichen Auf-wand sparen. Systematisches Requirements Engineering reduziert Nacharbeiten, Zusatzaufwändedurch Inkonsistenzen und vor allem Fehler, die erst spät entdeckt werden.Literatur[1] Ebert, C.: Systematisches Requirements Engineering und Management. Dpunkt-Verlag, Heidel-berg, Germany, dritte überarbeitete Auflage 2010.[2] Standish Group: Chaos Report 2009. http://www.standishgroup.com. Zitiert: 14.02.2011.[3] Lawrence, B., Wiegers, K, Ebert, C.: The Top Risks of Requirements Engineering. IEEE Software,Vol. 18, No. 6, pp. 62-63, Nov. 2001.[4] Ebert, C. und R. Dumke: Software Measurement. Springer, Heidelberg, New York, 2007.[5] Davis, A. M.: Just Enough Requirements Management. Dorset House, New York, USA, 2005.[6] Berenbach B., Paulish D., Kazmeier J., Rudorfer A.: Software Systems Requirements Engineering,McGraw Hill, 2009.