dpunkt.

verlag
Chris Rupp
Ein berblick
2., aktua||s|erte Auage
Chris Rupp
SOPHIST GmbH
Vordere Cramergasse 13
90478 Nrnberg
chris.rupp@sophist.de
www.sophist.de
2., aktualisierte Auage 2010
Copy Editing: Susanne Rudi
Satz und Herstellung: Frank Heidt
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck: Wrmann PRODUCTION CONSULT, Heidelberg
Artikel-Nr. 077.95731
Copyright 2010 dpunkt.verlag GmbH
Ringstrae 19 b
69115 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschtzt. Alle Rechte vorbehal-
ten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die
schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies
gilt insbesondere fr die Vervielfltigung, bersetzung oder die Verwendung in
elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-
Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen
Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz
unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit grter Sorgfalt kontrol-
liert. Weder Autor noch Verlag knnen jedoch fr Schden haftbar gemacht werden,
die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Chris Rupp
Requirements Engineering
Ein berblick
2., aktualisierte Auage
Liebe Leser,
diese Broschre soll Ihnen einen kleinen Einstieg in die vielschichtige Dis-
ziplin des Requirements Engineering bieten. Sie basiert auf Basiswissen
Requirements Engineering, dem ofziellen Lehrbuch fr die Zertizie-
rung zum Certied Professional for Requirements Engineering (CPRE)
Foundation Level, verfasst von Klaus Pohl und Chris Rupp, den Auto-
ren der auagenstrksten Bcher zum Thema Requirements Engineering.
Die Entscheidung der Autoren, jenes Buch gemeinsam zu verfassen, kam
nicht von ungefhr. Es sollten langjhrige Praxiserfahrungen mit Lehr- und
Forschungserkenntnissen zum Thema Requirements Engineering zusam-
mengefhrt werden.
Die immer strker an Bedeutung gewinnende Disziplin Requirements
Engineering befasst sich mit Anforderungen in der Systementwicklung:
mit ihrer Ermittlung, ihrer Dokumentation, ihrer Validierung und ihrer
Verwaltung. Die vorliegende Broschre mchte Ihnen vermitteln, was ge-
nau Requirements Engineering ist, und Ihnen seine verschiedenen Bereiche
vorstellen. Sie erfahren Grundstzliches ber das Persnlichkeitsprol und
Berufsbild des Requirements Engineer und lernen einige Aspekte seiner tg-
lichen Berufspraxis kennen.
Ich hoffe, dass Sie gerne mit mir und dieser Broschre auf die Reise in
die spannende Welt des Requirements Engineering gehen. Wenn Sie nach
der Lektre Interesse haben, das Thema zu vertiefen, nden Sie am Ende
der Broschre weiterfhrende Informationen und Literatur.
Chris Rupp
Nrnberg, im Juli 2010
Requirements Engineering was ist das? 3
Requirements Engineering was ist das?
Die Bedeutung des Requirements Engineering (RE) fr die erfolgreiche,
den Kundenwnschen entsprechende Entwicklung von Systemen ist mitt-
lerweile kaum mehr zu bersehen. In der Praxis ist es blich, einen ent-
sprechenden Aufwand fr das Requirements Engineering einzuplanen.
Immer huger ndet man zudem die Erkenntnis, dass der Requirements
Engineer eine eigenstndige Rolle mit anspruchsvollen Ttigkeiten ist.
Glaubt man den Zahlen im Chaos Report 2006 der Standish Group,
so hat sich in den zwlf Jahren von 1994 bis 2006 bei der erfolgreichen
Abwicklung von Softwareprojekten einiges zum Besseren gewendet.
Sind im Jahre 1994 noch gut 30 Prozent der untersuchten Soft-
wareprojekte gescheitert, so waren es 2006 nur noch knapp 20 Prozent.
Die Anzahl der gefhrdeten Projekte, die mit starken Zeit- oder Budget-
berziehungen und/oder nicht zur Zufriedenheit der Kunden abgeschlos-
sen werden konnten, verringerte sich von 53 Prozent auf 46 Prozent.
Abb. 1 Vergleich der Zahlen des Chaos Report von 1994 und 2006
Jim Johnson, Vorsitzender der Standish Group, nennt als einen von drei
Grnden fr die positive Entwicklung der Zahlen seit 1994 die Tatsache,
dass Anforderungen besser kommuniziert wrden als noch vor zehn Jah-
ren. Interessant sind diese Zahlen, da der Umgang mit Anforderungen ei-
nes Systems eine signikante Ursache fr Projektfehlschlge bzw. fr Zeit-
1994
2006
0
10
20
30
40
50
60
gescheitert
gefhrdet
erfolgreich
Requirements Engineering was ist das? 4
und Budgetberschreitungen darstellt: Die Mehrheit der schweren Fehler
passieren laut einer Studie von Barry Boehm [Boehm] nicht in den spte-
ren Phasen der Systementwicklung, sondern bereits in der Analysephase.
Je spter ein Fehler in den Anforderungen im Verlauf des Entwicklungs-
projekts behoben wird, desto hher sind die damit verbundenen Kosten.
So wird beispielsweise fr die Beseitigung eines Anforderungsfehlers, der
erst beim Programmieren entdeckt wird, ein um zirka den Faktor 20 h-
herer Aufwand angenommen fr die Fehlerbeseitigung in der Abnah-
mephase geht man von dem Faktor 100 aus.
Ziel des Requirements Engineering ist es, mglichst vollstndige Kun-
denanforderungen in guter Qualitt zu dokumentieren und dabei Fehler
mglichst frhzeitig zu erkennen und zu beheben.
Der Stakeholder (Projektbetroffener) ist einer der zentralen Begriffe im
Requirements Engineering. Stakeholder dienen u. a. als wichtigste Quellen
fr Anforderungen, und das bersehen eines Stakeholders hat hug zur
Konsequenz, dass die ermittelten Anforderungen an das System lckenhaft
sind. Stakeholder sind also alle diejenigen Personen oder Organisationen,
die Anforderungen in irgendeiner Weise beeinussen. Das knnen natr-
liche Personen sein, die das System spter nutzen werden (z. B. der Nut-
zer oder der Administrator), oder solche, die es nicht nutzen werden oder
sollen (z .B. das Management oder ein Hacker, vor dem man das System
Denition Anforderung
Eine Anforderung ist:
(1) Eine Bedingung oder Fhigkeit, die von einem Benutzer (Person oder
System) zur Lsung eines Problems oder zur Erreichung eines Ziels
bentigt wird.
(2) Eine Bedingung oder Fhigkeit, die ein System oder Teilsystem erfllen
oder besitzen muss, um einen Vertrag, eine Norm, eine Spezikation oder
andere, formell vorgegebene Dokumente zu erfllen.
(3) Eine dokumentierte Reprsentation einer Bedingung oder Eigenschaft
gem (1) oder (2).
bersetzt aus [IEEE]
Requirements Engineering was ist das? 5
schtzen muss), aber auch juristische Personen, Institutionen usw., da diese
letztlich durch natrliche Personen vertreten werden, die die Anforderun-
gen des betrachteten Systems beeinussen bzw. denieren knnen.
Requirements Engineering ist kaum noch wegzudenken, wenn es darum geht,
den Kunden zufriedenstellende Systeme zu entwickeln und dabei Budget-
und Zeitplne einzuhalten. In der heutigen Zeit kann sich kein Unternehmen
ein halbherziges Anforderungsmanagement bzw. eine fahrige Anforderungs-
erhebung leisten. Moderne Systeme sollen schneller, besser, innovativer sein.
Fehler mssen so frh wie mglich entdeckt und behoben werden.
Mittlerweile haben viele Unternehmen einen etablierten Requirements-
Management-Prozess. Unter anderem hat die Mglichkeit der Zertizie-
rung zum Certied Professional for Requirements Engineering (CPRE)
dazu beigetragen, dass der Requirements Engineer immer mehr als eine
eigene, spezialisierte Rolle gesehen und mit eigenen Ressourcen fr seine
anspruchsvolle Arbeit ausgestattet wird.
Denition Stakeholder
Ein Stakeholder eines Systems ist eine Person oder Organisation, die
(direkt oder indirekt) Einuss auf die Anforderungen des betrachteten
Systems hat.
Denition Requirements Engineering
Das Requirements Engineering ist ein kooperativer, iterativer, inkrementeller
Prozess, dessen Ziel es ist zu gewhrleisten, dass:
(1) alle relevanten Anforderungen bekannt und in dem erforderlichen
Detaillierungsgrad verstanden sind,
(2) die involvierten Stakeholder eine ausreichende bereinstimmung ber
die bekannten Anforderungen erzielen,
(3) alle Anforderungen konform zu den Dokumentationsvorschriften doku-
mentiert bzw. konform zu den Spezikationsvorschriften speziziert sind.
Der Requirements Engineer und die Zertizierung 6
Der Requirements Engineer
und die Zertizierung
Berufsbild und Persnlichkeitsprol des
Requirements Engineer
Der Requirements Engineer als Projektrolle steht hug im Mittelpunkt
des Geschehens. Er pegt in der Regel als Einziger direkten Kontakt zu
allen Stakeholdern und hat die Chance und Verantwortung, sich ausrei-
chend in das Fachgebiet der Stakeholder einzuarbeiten sowie die Sprache
in den verschiedenen Fachgebieten zu erlernen und zu verstehen. Er ist
derjenige, der die Bedrfnisse hinter den Aussagen der Stakeholder erken-
nen und so aufbereiten muss, dass fachfremde Architekten und Entwick-
ler sie verstehen und umsetzen knnen.
Man kann sich den Requirements Engineer also als eine Art Dol-
metscher vorstellen, der sowohl das Fachgebiet und dessen Sprache aus-
reichend kennt als auch ber genug IT-Know-how verfgt, um sich der
Probleme der Entwickler bewusst zu sein und mit diesen gleichberechtigt
kommunizieren zu knnen. Um allen Aufgaben gerecht werden zu kn-
nen, bentigt der Requirements Engineer weit mehr als Methodenwissen.
Viele der bentigten Fhigkeiten setzen entsprechende praktische Erfah-
rungen voraus.
Analytisches Denken
Der Requirements Engineer muss fhig sein, sich in ihm unbekannte
Fachgebiete und Sachverhalte schnell einzuarbeiten und dabei kompli-
zierte Probleme und Zusammenhnge zu verstehen und zu analysieren.
Da Stakeholder oft in konkreten Beispielen und (suboptimalen) Lsun-
gen ber das eigentliche Problem und die zugehrigen Anforderungen
sprechen, muss der Requirements Engineer in der Lage sein, konkrete
Aussagen der Stakeholder zu abstrahieren.
Empathie
Der Requirements Engineer hat die schwierige Aufgabe zu erkennen, was
ein Stakeholder tatschlich bentigt. Hierfr ist ein ausgeprgtes Einfh-
lungsvermgen eine der zentralen Voraussetzungen.
Der Requirements Engineer und die Zertizierung 7
Kommunikationsfhigkeit
Um die Anforderungen der Stakeholder zu erheben, richtig zu interpretie-
ren und zu kommunizieren, muss der Requirements Engineer ber hohe
kommunikative Fhigkeiten verfgen. Er muss zuhren knnen, zur
rechten Zeit die richtigen Fragen stellen, bemerken, wenn Aussagen nicht
den gewnschten Informationsgehalt haben, und rechtzeitig erforderliche
Rckfragen stellen.
Koniktlsungsfhigkeit
Durch unterschiedliche Meinungen der Stakeholder kommt es im Requi-
rements Engineering hug zu Konikten. Der Requirements Engineer
muss Konikte erkennen, zwischen den Parteien vermitteln und schlie-
lich durch den Einsatz geeigneter Techniken den Konikt ausen.
Moderationsfhigkeit
Der Requirements Engineer muss zwischen unterschiedlichen Meinungen
vermitteln und Diskussionen leiten knnen. Dies gilt sowohl fr Einzel-
besprechungen als auch in Gruppengesprchen oder in Workshops.
Selbstbewusstsein
Da der Requirements Engineer hug im Mittelpunkt steht und dabei
gelegentlich auch Kritik ausgesetzt ist, bentigt er ein selbstbewusstes
Auftreten und die Fhigkeit, sich auch durch hartnckige Ablehnungen
nicht aus dem Konzept bringen zu lassen. Er sollte Kritik niemals persn-
lich nehmen.
berzeugungsfhigkeit
Der Requirements Engineer ist unter anderem eine Art Anwalt fr die
Anforderungen seiner Stakeholder. Er muss fhig sein, diese nach auen
und in Besprechungen und Prsentationen zu vertreten.
Der Requirements Engineer und die Zertizierung 8
Das International Requirements Engineering Board und
die Zertizierung zum Certied Professional for Requirements
Engineering
Im Jahr 2007 wurde das International Requirements Engineering Board
(IREB e.V.) gegrndet. Es setzt sich aus unabhngigen, weltweit aner-
kannten Experten aus den Bereichen Industrie, Beratung, Forschung und
Lehre zusammen.
Das International Requirements Engineering Board hat sich der Auf-
gabe verschrieben, das Requirements Engineering zu professionalisieren.
Professionalitt bedeutet hierbei, anerkannte Methoden und Verfahren
einzusetzen, eine standardisierte Begriffsbildung und Begriffsverwendung
zu frdern, aber auch den Nachweis zu fhren, dass Methoden, Verfahren
und Begriffe von verantwortlichen Personen korrekt eingesetzt werden.
Die Mitglieder des Boards haben gemeinsam einen Lehrplan fr den
Bereich Requirements Engineering erarbeitet und ein darauf basieren-
des Zertikat, den Certied Professional for Requirements Engineering
(CPRE), entwickelt. Ziel ist es, eine qualittsgesicherte Standardisierung
der Aus- und Weiterbildung im Requirements Engineering und damit
letztlich eine breite Verbesserung der tglichen Requirements-Enginee-
ring-Praxis zu erreichen.
Im Jahre 2007 begann das IREB sehr erfolgreich seine Arbeit in
Deutschland, sterreich und der Schweiz. Seit der Bereitstellung des
Lehrplans in englischer Sprache kommen stetig neue Lnder hinzu, in
denen zum CPRE zertiziert wird, z. B. die USA, Indien und Israel. Am
Zertizierungsprozess sind vier Hauptakteure beteiligt: das International
Requirements Engineering Board, die anerkannten Schulungsanbieter
(Trainingsprovider), die Zertizierungsstellen in den einzelnen Lndern
und natrlich die Kursteilnehmer bzw. die zu prfenden Personen. Das
Schaubild in Abbildung 2 zeigt die Struktur und Aufgabenverteilung im
Rahmen der Zertizierung zum CPRE. Das IREB erarbeitet den Lehr-
plan, erstellt die zugehrigen Prfungsfragen, deniert und regelt das
Prfungsverfahren, beauftragt Zertizierungsstellen mit der Prfungsab-
nahme und erkennt Trainingsprovider an, die lehrplankonforme Schu-
lungsmanahmen zum CPRE anbieten.

Der Requirements Engineer und die Zertizierung 9
Abb. 2 Struktur der Zertizierung mitsamt den Beteiligten
In den einzelnen Lndern fhren vom IREB beauftragte Zertizierungs-
stellen die Prfungen fr das Zertikat durch. Formell besitzt der IREB-
Lehrplan den gleichen Charakter wie die Lehrplne anderer etablierter
Aus- und Weiterbildungsstandards (z. B. ISTQB Certied Tester) und
bercksichtigt dabei einschlgige internationale Normen der ISO und
des IEEE. Der Lehrplan fr den Foundation Level umfasst das Grundla-
genwissen zum Requirements Engineering auf den Gebieten Ermittlung,
Dokumentation, Prfung und Verwaltung von Anforderungen.
Der fachliche Inhalt des IREB-Zertikats kann im ffentlich zugng-
lichen Lehrplan nachgelesen werden. Durch seinen Lehrplan gibt das
IREB genau den Umfang, den Inhalt und die Zeit fr die Erreichung der
Lernziele sowie die Themen der praktischen bungen vor. Des Weiteren
knnen auf den Internetseiten des IREB (http://certied-re.de) auch das
vollstndige aktuelle Glossar und nhere Informationen zu den Prfungs-
modalitten nachgeschlagen werden.
International
Requirements
Engineering
Board
(IREB)
- Lehrplan
erarbeiten
- Prfungsfragen
erstellen
- Prfungsverfahren
regeln
- Zertifizierungs-
stellen beauftragen
- Trainingsprovider
anerkennen
Anerkannte
Trainingsprovider
- Kurse durchfhren
Zertifizierungsstelle
- Prfungen durchfhren
- Zertifikate erstellen
Kursteilnehmer
und
zu prfende
Person
- Kursprogramm aufbauen
(max 2 pro Land)
Die Kerndisziplinen des Requirements Engineering 10
Die Kerndisziplinen des
Requirements Engineering
Um ein Entwicklungsprojekt zum Erfolg fhren zu knnen, muss zu-
nchst bekannt sein, was die Anforderungen an das System sind, und
diese mssen geeignet dokumentiert sein.
Dem Requirements Engineering im Entwicklungsprozess kommt die
Aufgabe zu, die Anforderungen der Stakeholder zu ermitteln, zweckm-
ig zu dokumentieren, zu berprfen und abzustimmen sowie die doku-
mentierten Anforderungen ber den gesamten Lebenszyklus des Systems
hinweg zu verwalten.
Die vier damit einhergehenden Hauptttigkeiten sind das Ermitteln,
Dokumentieren, Prfen und Abstimmen sowie das Verwalten von An-
forderungen.
Abb. 3 Die Kerndisziplinen des Requirements Engineering
Anforderungen ermitteln
Die Disziplin Anforderungen ermitteln umfasst viele Ttigkeiten. Zu-
allererst mssen Ziele festgelegt und das System von seiner Umwelt klar
abgegrenzt werden. Nur so wissen alle Projektbeteiligten, was Teil des
Systems und daher Gegenstand der detaillierten Systemanalyse sein wird
und zu welchen Nachbarsystemen und menschlichen Nutzern Schnittstel-
len speziziert werden mssen.
Meist sogar noch vor Zieldenition und Kontextabgrenzung muss
ermittelt werden, welche Anforderungsquellen in welchem Rahmen zur
Verfgung stehen.
Eine wichtige Anforderungsquelle sind Stakeholder. Dies sind nicht nur
die zuknftigen Nutzer des Systems, sondern auch z. B. die Marketingab-
teilung, die Absatzziele im Kopf hat und den Kunden als Stakeholder intern
vertritt, wenn der Kunde ein momentan noch anonymer groer Markt ist.
Ermitteln Dokumentieren Verwalten Prfen
Die Kerndisziplinen des Requirements Engineering 11
Das Management als Entscheider und Sponsor ist ebenso Stakeholder wie
die Personen, die spter das System warten und administrieren sollen, das
Schulungspersonal, der Betriebsrat, der Ergonomieexperte und viele mehr.
Aber auch Dokumente sind wichtige Anforderungsquellen, von denen
viele Anforderungen abgeleitet werden knnen. Beispiele hierfr sind all-
gemeingltige Dokumente wie z. B. Normen/Standards oder Gesetzestexte
sowie branchen-/organisationsspezische Dokumente, z. B. Anforderungs-
dokument, Benutzungshandbuch oder Fehlerberichte des Altsystems.
Auch Systeme in Betrieb kommen als Anforderungsquelle in Frage.
Dies knnen sowohl Alt- bzw. Vorgngersysteme als auch Konkurrenz-
systeme sein.
Ermittlungstechniken
Um das Wissen und die Anforderungen der Stakeholder zu ermitteln,
kann man sich unterschiedlicher Ermittlungstechniken bedienen. Denn
so unterschiedlich Projektrahmenbedingungen, Systeme sowie die Per-
snlichkeiten der Stakeholder sind, so unterschiedlich sind die Techniken,
die bei der Ermittlung von Anforderungen Erfolg versprechen. Daher ist
eine bewusste und situationsbezogene Entscheidung fr eine bestimm-
te Kombination von Ermittlungstechniken ntig. Ermittlungstechniken
werden nach Befragungstechniken, Kreativittstechniken, dokumenten-
zentrierten Techniken und Beobachtungstechniken unterschieden.
Fr die Anforderungsermittlung ist das Wissen, welche Bedeutung
die Anforderungen fr die Zufriedenheit der Stakeholder haben, sehr
hilfreich. Diese Zufriedenheit wird mit den jeweiligen Merkmalen eines
Produkts, von denen sie abhngen, nach dem Modell von Kano in drei
Kategorien eingeteilt (siehe auch Abb. 4):
Basisfaktoren sind selbstverstndlich vorausgesetzte Systemmerkmale
(unterbewusstes Wissen).
Leistungsfaktoren sind die explizit geforderten Systemmerkmale
(bewusstes Wissen).
Begeisterungsfaktoren sind Systemmerkmale, die der Stakeholder nicht
kennt und erst whrend der Benutzung als angenehme und ntzliche
berraschungen entdeckt (unbewusstes Wissen).
Die Kerndisziplinen des Requirements Engineering 12
Abb. 4 Das Kano-Modell
Whrend bei der Anforderungsermittlung Befragungstechniken vor allem
zum Abfragen von explizitem Wissen geeignet sind, also der Leistungs-
faktoren nach Kano, knnen Beobachtungstechniken und einige doku-
mentenzentrierte Techniken besonders gut fr die Erhebung von impli-
zitem Wissen, den sogenannten Basisfaktoren, eingesetzt werden. Um an
die unbewussten Wnsche der Stakeholder zu gelangen, die hug die
Begeisterungsfaktoren im Kano-Modell ausmachen, mssen Wnsche er-
raten oder durch Kreativittstechniken an die Oberche geholt werden.
Befragungstechniken
Mit Befragungstechniken wird versucht, direkt vom Stakeholder eine
mglichst genaue und unverflschte Aussage ber seine Anforderungen
an das System zu erhalten. Alle Befragungstechniken setzen voraus, dass
Zeit*
Erfllungsgrad
sehr zufrieden
vllig
unzufrieden
Zufriedenheit
vllig unzureichend
vollstndig
Begeisterungs-
faktoren
Leistungs-
faktoren
Basisfaktoren
*mit der Zeit werden
Begeisterungsfaktoren
zu Leistungsfaktoren
und schlielich zu
Basisfaktoren
Erfllungsgrad
Die Kerndisziplinen des Requirements Engineering 13
der Befragte sein Wissen explizit ausdrcken kann und dass er bereit ist,
Zeit und Engagement in die Ermittlung zu investieren. Befragungstech-
niken sind tendenziell vom Requirements Engineer getrieben, da dieser
die Fragen vorgibt. Dadurch knnen Anliegen der Stakeholder eventuell
verdrngt, vergessen oder vernachlssigt werden.
Klassische Befragungstechniken sind das Interview und der Frage-
bogen.
Kreativittstechniken
Kreativittstechniken dienen dazu, innovative Anforderungen zu ent-
wickeln, die erste Vision eines neuen Systems festzulegen und Begeiste-
rungsfaktoren zu ermitteln. Kreativittstechniken eignen sich allerdings
in der Regel nicht dazu, detaillierte Anforderungen an das Systemverhal-
ten herauszuarbeiten.
Klassische Kreativittstechniken sind das Brainstorming sowie eine
Modikation desselben, bei der Ergebnisse gesammelt werden, die nicht
erreicht werden sollen, um so in der anschlieenden Diskussion Ma-
nahmen zur Risikovermeidung abzuleiten, das sogenannte Brainstorming
paradox.
Techniken, die mit Perspektivenwechseln arbeiten, betrachten das
Problem von mehreren Seiten oder aus unterschiedlichen Sichten, wh-
rend durch Analogietechniken hnliche Problemstellungen (und Lsun-
gen) anhand analoger Strukturen in der Natur (Bionik) oder auch auer-
halb (Bisoziation) gesucht werden.
Dokumentenzentrierte Techniken
Dokumentenzentrierte Techniken verwenden Lsungen und Erfahrun-
gen bestehender Systeme wieder. Im Falle der Ablsung eines Altsystems
stellt diese Technik sicher, dass die gesamte Funktionalitt des Altsystems
identiziert werden kann. Dokumentenzentrierte Techniken sollten mit
anderen Ermittlungstechniken kombiniert werden, um die Gltigkeit der
ermittelten Anforderungen zu bestimmen und um neue Anforderungen
an das zu entwickelnde System herauszunden.
Die Kerndisziplinen des Requirements Engineering 14
Beobachtungstechniken
Fr Situationen, in denen Fachspezialisten nicht die Zeit besitzen, das be-
ntigte Wissen an den Requirements Engineer weiterzugeben, oder nicht
fhig sind, dieses Wissen zu formulieren, eignen sich Beobachtungstech-
niken. Dabei werden die entsprechenden Stakeholder vom Requirements
Engineer bei ihrer Arbeit beobachtet, ihre Arbeitsschritte dokumentiert
und daraus die vom System zu untersttzenden Arbeitsablufe, aber auch
potenzielle Fehler, Risiken und offene Fragen ermittelt und die Anfor-
derungen abgeleitet. Als positiven Nebeneffekt lernt der Requirements
Engineer dabei den jeweiligen Fachjargon, was ihm weitere Befragungen
erleichtert. Beispiele fr Beobachtungstechniken sind Feldbeobachtung
und Apprenticing (in die Lehre gehen).
Anforderungen dokumentieren
Im Requirements Engineering werden unterschiedliche Informationen
dokumentiert, die in den einzelnen Aktivitten anfallen bzw. erarbeitet
werden. Hierzu gehren z. B. Protokolle von Interviews, Berichte zu
berprfungs- und Abstimmungsaktivitten oder auch nderungsantr-
ge. Die Hauptaufgabe der Dokumentation im Requirements Engineering
ist es jedoch, die Anforderungen an das zu entwickelnde System geeignet
zu dokumentieren.
Die wesentlichen Grnde fr die Dokumentation von Anforderungen
sind:
Anforderungen sind Basis fr die Systementwicklung: Anforde-
rungen werden in jeglicher Form im Requirements Engineering,
beim Entwurf, in der Realisierung oder im Test direkt oder indi-
rekt auf das Projektgeschehen einwirken. Die Qualitt einer An-
forderung bzw. des Anforderungsdokuments hat entscheidenden
Einuss auf den spteren Projektverlauf und somit auf den Pro-
jekterfolg.
Anforderungen sind rechtlich relevant: Durch die schriftliche Do-
kumentation der Anforderungen knnen im Streitfall rechtliche
Konikte zwischen den Beteiligten zgig geklrt werden.
Die Kerndisziplinen des Requirements Engineering 15
Anforderungsdokumente sind komplex: Systeme, die Tausende
von Anforderungen besitzen, die wiederum vielschichtig mitein-
ander in Beziehung stehen, stellen in der Praxis keine Ausnahme
dar. Ohne geeignete Dokumentation wird es fr alle Beteiligten
schwierig, den berblick zu bewahren.
Anforderungen sollten allen Beteiligten zugnglich sein: Projekte
durchwandern mit der Zeit eine Entwicklung sowohl inhaltlich
als auch personell. Durch die Gewhrleistung einer permanenten
Verfgbarkeit des aktuellen Informationsstands vermeidet man
Unklarheiten und ermglicht Personen, die neu ins Projekt kom-
men, eine schnelle Einarbeitung.
Anforderungen in natrlicher Sprache dokumentieren
Die natrliche Sprache, insbesondere Prosa, ist die in der Praxis am
hugsten genutzte Dokumentationsform fr Anforderungen. Gegen-
ber anderen Notationsformen hat Prosa einen entscheidenden Vorteil:
Keiner der Stakeholder muss eine neue Notation erlernen. Weiterhin
ist Sprache sehr vielseitig einsetzbar der Requirements Engineer kann
mittels natrlicher Sprache alle Arten von Anforderungen ausdrcken.
Allerdings birgt die natrliche Sprache auch das Risiko von Missver-
stndnissen und falschen Interpretationen sowie Auslassungen und im-
pliziten Annahmen. Diese sogenannten sprachlichen Effekte knnen
jedoch weitgehend vermieden werden, wenn natrlichsprachige Anfor-
derungen systematisch formuliert und hinterfragt werden. Im folgenden
Kapitel Aus der Praxis des Requirements Engineer stellen wir Ihnen
eine bewhrte Mglichkeit zur Formulierung von natrlichsprachigen
Anforderungen vor.
Um Probleme zu vermeiden, die aus einem uneinheitlichen Begriffs-
verstndnis resultieren, ist es notwendig, dass alle am Entwicklungspro-
zess beteiligten Personen eine konsistente Terminologie verwenden. Hier-
zu sind alle relevanten Begriffe in einem Glossar zu denieren.
Anforderungen durch konzeptuelle Modelle dokumentieren
Konzeptuelle Modelle stellen die dokumentierten Anforderungen im
Vergleich zum Einsatz natrlicher Sprache kompakter und somit fr den
gebten Leser verstndlicher dar. Zudem bieten konzeptuelle Modelle
Die Kerndisziplinen des Requirements Engineering 16
aufgrund ihres hheren Grades an Formalitt einen hheren Grad der
Eindeutigkeit (d. h. weniger Mglichkeiten zur Interpretation) als natr-
liche Sprache.
Allerdings setzt der Einsatz einer konzeptuellen Modellierungsspra-
che zur Dokumentation von Anforderungen spezische Modellierungs-
kenntnisse voraus.
Zu den hug im Requirements Engineering eingesetzten konzeptuel-
len Modellen zhlen Zielmodelle (z. B. in Form von Und-Oder-Bumen)
und Use-Case-Diagramme sowie konzeptuelle Modelle zur Dokumenta-
tion von Anforderungen aus den drei Perspektiven: Strukturperspektive,
Funktionsperspektive und Verhaltensperspektive. Fr jede dieser drei
Perspektiven existieren geeignete Modellierungssprachen, um die in der
Perspektive jeweils betrachteten Informationen in zweckmigen kon-
zeptuellen Modellen zu dokumentieren. So werden zur Dokumentation
von Ablufen in der Funktionsperspektive gerne Aktivittsdiagramme
der UML sowie Datenussdiagramme herangezogen, whrend die Struk-
turperspektive entweder durch Entity-Relationship-Modelle oder durch
Klassendiagramme der UML dargestellt wird. Zur Modellierung der Ver-
haltensperspektive nden hug State Charts oder Zustandsautomaten
der UML Einsatz.
Anforderungen prfen und abstimmen
Die Prfung und Abstimmung von Anforderungen im Requirements En-
gineering stellen sicher, dass die dokumentierten Anforderungen festge-
legten Qualittskriterien gengen. Bewhrte Prinzipien und Techniken
knnen dabei zur Prfung und Abstimmung einzelner Anforderungen,
aber auch zur Prfung und Abstimmung von Anforderungsdokumenten
eingesetzt werden.
Anforderungen prfen
Im Rahmen der berprfung von Anforderungen wird die Entscheidung
getroffen, ob eine Anforderung die ntige Qualitt aufweist und ob die
Anforderung fr weitere Entwicklungsaktivitten (Entwurf, Realisierung
und Test) freigegeben werden kann. Diese Entscheidung sollte anhand
von vorher festgelegten Prf- und Abnahmekriterien erfolgen.
Die Kerndisziplinen des Requirements Engineering 17
Das Ziel der berprfung von Anforderungen ist es somit, Fehler
in den dokumentierten Anforderungen zu entdecken. Typische Beispiele
fr Fehler in Anforderungen sind Mehrdeutigkeit, Unvollstndigkeit und
Widersprche.
Anforderungsdokumente sind Referenzdokumente fr alle weiteren
Entwicklungsaktivitten. Daher beeintrchtigen Fehler in Anforderungen
alle weiteren Entwicklungsaktivitten. Ein Anforderungsfehler, der erst
im Betrieb des erstellten Systems identiziert wird, erfordert die berar-
beitung aller Artefakte, die von dem Fehler betroffen sind, wie beispiels-
weise Quellcode, Testartefakte oder Architekturbeschreibungen. Die Be-
seitigung von Anforderungsfehlern verursacht somit erhebliche Kosten.
Zur berprfung der Anforderungen existieren verschiedene Tech-
niken, die abhngig von den aktuellen Projektgegebenheiten und Ziel-
setzungen ausgewhlt und zweckmig kombiniert werden sollten. Zu
den verbreiteten Prfungstechniken fr Anforderungen gehren dabei
die verschiedenen Ausprgungsformen des Reviews von Anforderungen
( z. B. Stellungnahme, Inspektion, Walkthrough) sowie das perspektiven-
basierte Lesen und der Einsatz von Prototypen und Checklisten.
Anforderungen abstimmen
Das Ziel der Abstimmung von Anforderungen ist es, unter den Stakehol-
dern ein gemeinsames und bereinstimmendes Verstndnis bezglich der
Anforderungen an das zu entwickelnde System herbeizufhren.
Besteht hinsichtlich der Anforderungen unter den Stakeholdern ein
Widerspruch in der Art, dass die Anforderungen nicht gemeinsam in
einem System umgesetzt werden knnen, so entsteht ein Konikt zwi-
schen den widersprchlichen Anforderungen und ebenso zwischen den
Stakeholdern, die diese Anforderungen wnschen. Zum Beispiel knnte
ein Stakeholder fordern, dass das zu erstellende System im Fehlerfall ab-
schaltet, wohingegen ein anderer Stakeholder verlangen knnte, dass das
System im Fehlerfall neu startet.
Die Akzeptanz eines geplanten Systems wird durch unaufgelste Kon-
ikte gefhrdet, da diese dazu fhren, dass die Anforderungen mindestens
einer Gruppe von Stakeholdern nicht umgesetzt werden. Im schlimmsten
Fall kann ein unbeachteter Konikt dazu fhren, dass die Entwicklung
eines Systems nicht weiter durch die betroffenen Stakeholder untersttzt
wird und dadurch die Entwicklung gnzlich scheitert.
Die Kerndisziplinen des Requirements Engineering 18
Neben den genannten Risiken sind Konikte allerdings auch eine
Chance fr das Requirements Engineering, da Konikte zwischen Stake-
holdern eine Lsung erfordern, die unter Umstnden auch zur Entwick-
lung von neuen Ideen beitragen oder mgliche Optionen in der Entwick-
lung aufzeigen kann.
Anforderungen verwalten
Ziel des Verwaltens von Anforderungen (Requirements Management) ist
es, die dokumentierten Anforderungen sowie andere relevante Informati-
onen bis hin zu vollstndigen Anforderungsdokumenten ber den gesam-
ten Lebenszyklus des Systems bzw. Produkts hinweg persistent verfgbar
zu machen, sinnvoll zu strukturieren sowie den selektiven Zugriff auf die-
se Informationen zu gewhrleisten (z. B. durch geeignete Attributierung
und Sichtenbildung). Die Verwaltung von Anforderungen umfasst dabei
Techniken der folgenden Kategorien:
Attributierung von Anforderungen: Um die Verwaltung von An-
forderungen zu ermglichen, werden Merkmale von Anforderun-
gen durch Anforderungsattribute dokumentiert, z. B. eindeutiger
Identikator, Autor, Quelle, Kritikalitt.
Priorisierung von Anforderungen: Anforderungen werden zu ver-
schiedenen Zeitpunkten in verschiedenen Aktivitten nach unter-
schiedlichen Kriterien priorisiert. Je nach Priorisierungsziel und
Priorisierungsgegenstand sind fr die Priorisierung unterschiedli-
che Techniken einzusetzen.
Verfolgbarkeit von Anforderungen: Im Rahmen der Verwaltung
von Anforderungen werden Verfolgbarkeitsinformationen von
Anforderungen aufgezeichnet, organisiert und gepegt, um Infor-
mationen ber Querbezge und Abhngigkeiten von Anforderun-
gen untereinander oder von Anforderungen zu anderen Entwick-
lungsartefakten nutzen zu knnen.
Die Kerndisziplinen des Requirements Engineering 19
Versionierung von Anforderungen: Die Versionierung und Kon-
guration von Anforderungen ermglicht es, ber den Lebens-
zyklus eines Systems oder Produkts hinweg spezische Entwick-
lungsstnde von Anforderungen und Anforderungsdokumenten
verfgbar zu halten.
nderungsmanagement von Anforderungen: Fr die Bearbeitung
der nderungsantrge ist typischerweise das Change Control
Board zustndig. Das Change Control Board entscheidet ber
die Annahme bzw. die Ablehnung von nderungsantrgen. Im
Vorfeld der Entscheidung priorisiert es die nderungsantrge und
schtzt die Auswirkungen der nderung auf alle Entwicklungsar-
tefakte sowie die zur Umsetzung der nderung bentigten Res-
sourcen ab.
Aus der Praxis des Requirements Engineer 20
Aus der Praxis des Requirements Engineer
Nachdem wir Ihnen in den bisherigen Kapiteln das theoretische Funda-
ment des Requirements Engineering vorgestellt haben, gehen wir in die-
sem Kapitel auf zwei praktische Aspekte ein.
Zunchst zeigen wir Ihnen eine bewhrte Methode, natrlichspra-
chige Anforderungen anhand einer Satzschablone so zu formulieren,
dass jede Anforderung alle fr ihre Umsetzung relevanten Informationen
transportiert.
Danach stellen wir Ihnen die Eigenschaften und Vorzge spezialisier-
ter Werkzeuge fr das Requirements Management vor und zeigen Ihnen
auf, warum klassische Broanwendungen fr die Verwaltung von Anfor-
derungen eigentlich gnzlich ungeeignet sind.
Die Satzschablone
Die oft genannten Vorteile der Dokumentation in natrlicher Sprache
sind die Lesbarkeit und die universelle Anwendbarkeit fr verschiedenste
Sachverhalte ohne besonderes Vorwissen bezglich der Notation. Demge-
genber stehen aber die Nachteile, die aus der fehlenden Formalisierung
stammen, z .B. die Mehrdeutigkeit. Da Projektbeteiligte aufgrund unter-
schiedlichen Wissens, sozialer Prgung und Erfahrung die dokumentier-
ten Anforderungen verschieden interpretieren, kommt es in der Praxis
immer wieder zu Missverstndnissen. Diese Nachteile knnen durch die
Verwendung einer Satzschablone und das Prfen auf sprachliche Effekte
vermindert werden.
Eine Satzschablone (Requirement Template) ist ein Bauplan fr die
syntaktische Struktur einer einzelnen Anforderung. Der Einsatz der Satz-
schablone untersttzt den Autor einer Anforderung darin, die syntak-
tische Eindeutigkeit der Anforderung zu erreichen und Anforderungen
hoher Qualitt in einem optimalen Zeit- und Kostenrahmen zu verfassen.
Die Satzschablone sollte dann eingesetzt werden, wenn sich in den
Projekten die Bereitschaft der Mitarbeiter herauskristallisiert, einer stark
normierten Vorgehensweise zu folgen, denn die stilistischen Freiheitsgra-
de der Schreibenden bei der Formulierung von Anforderungen werden
Aus der Praxis des Requirements Engineer 21
dabei stark eingeschrnkt. Den besten Erfolg erzielt man, wenn man die
Satzschablonen nicht als ein Muss vorschreibt, sondern die Methode
schult und die Schablone als Hilfsmittel darstellt.
Die richtige Anwendung der Schablone erfordert fnf Schritte:
Schritt 1: Festlegen der rechtlichen Verbindlichkeit
Legen Sie als Erstes die rechtliche Verbindlichkeit der Anforderung fest.
Eine Mglichkeit, die Verbindlichkeit einer Anforderung auszudrcken,
stellen die Modalverben muss, sollte und wird dar.
Schritt 2: Den Kern der Anforderung bestimmen
Im Mittelpunkt jeder Anforderung steht die geforderte Funktionalitt
(z. B. drucken, speichern, bertragen, berechnen). In Schritt 2
whlen Sie das Verb (Prozesswort), das den bentigten Vorgang oder die
Ttigkeit beschreibt.
Schritt 3: Charakterisieren der Aktivitt des Systems
Fr funktionale Anforderungen lsst sich die Systemttigkeit in drei rele-
vante Arten klassizieren:
In Schritt 3 ist anhand der Art der geforderten Systemaktivitt einer der
drei Typen der Satzschablone zu whlen.
Typ 1: Selbststndige Systemaktivitt:
Das System fhrt den Prozess selbststndig durch.
Typ 2: Benutzerinteraktion:
Das System stellt dem Nutzer die Prozessfunktionalitt zur Verfgung.
Typ 3: Schnittstellenanforderung:
Das System fhrt einen Prozess in Abhngigkeit von einem Dritten
(z. B. einem Fremdsystem) aus, ist an sich passiv und wartet auf ein externes
Ereignis.
Aus der Praxis des Requirements Engineer 22
Abb. 5 Die Satzschablone nach Schritt 3
Lesart der Schablonentypen:
Typ 1: DAS SYSTEM MUSS/SOLLTE/WIRD <Prozesswort>.
Typ 2: DAS SYSTEM MUSS/SOLLTE/WIRD <wem?> DIE MGLICH-
KEIT BIETEN <Prozesswort>.
Typ 3: DAS SYSTEM MUSS/SOLLTE/WIRD FHIG SEIN <Prozess-
wort>.
Schritt 4: Objekte einfgen
Manche Prozesswrter bentigen zur Ergnzung ein oder mehrere Ob-
jekte. In Schritt 4 werden daher die noch fehlenden Objekte und Ergn-
zungen der Objekte in der Anforderung identiziert und ergnzt.
Schritt 5: Formulierung von logischen und zeitlichen Bedingungen
Fr Anforderungen ist es typisch, dass die geforderte Funktionalitt nicht
fortwhrend, sondern nur unter bestimmten zeitlichen oder logischen Be-
dingungen ausgefhrt oder zur Verfgung gestellt wird. Um zeitliche von
logischen Bedingungen klar unterscheiden zu knnen, whlen wir fr
zeitliche Bedingungen als temporale Konjunktion sobald, fr logische
Bedingungen als konditionale Konjunktion falls und stellen die Bedin-
gung an den Satzanfang.
SOLLTE
MUSS -
WIRD FHIG SEIN
DAS SYSTEM
<Systemname>
<Prozesswort>
<wem?> DIE
MGLICHKEIT BIETEN
Aus der Praxis des Requirements Engineer 23
Werkzeuge in der Anforderungsverwaltung
Die verschiedenen Aktivitten im Requirements Engineering werden
durch geeignete Werkzeuge untersttzt, die idealerweise integriert sind
und die jeweils abgelegten Informationen nutzen und weiterverarbeiten
knnen. Dies knnen Informationen sein, die im Requirements Enginee-
ring erzeugt wurden (z. B. natrlichsprachige oder modellbasierte An-
forderungen) oder als Basis fr die Anforderungen genutzt wurden (z. B.
Besprechungsprotokolle, Zieldokumentationen, Stakeholderlisten). Viele
Werkzeuge, die eigentlich ein anderes Einsatzgebiet haben, knnen auch
im Requirements Engineering Verwendung nden.
Die in der Praxis bekannteste Form von Werkzeugen fr das Requi-
rements Engineering sind solche, die auf die Verwaltung von Anforde-
rungen (Requirements-Management-Werkzeuge, kurz RM-Werkzeuge)
ausgelegt sind.
Jedoch werden in vielen Projekten Standard-Broanwendungen fr
die Verwaltung von Anforderungen genutzt, auch wenn ihre Nachteile
gegenber spezialisierten RM-Werkzeugen nicht zu unterschtzen sind.
Allgemeine Werkzeuguntersttzung im Requirements Engineering
Eine Vielzahl von Werkzeugen, die im Rahmen der Systementwicklung
eingesetzt werden, kann neben dem eigentlichen Einsatzgebiet auch
fr Aufgaben des Requirements Engineering genutzt werden. So bieten
Testverwaltungs-, Fehlerverfolgungs- oder Kongurationsmanagement-
Werkzeuge oftmals Funktionen zur Anforderungsverwaltung oder kn-
nen mithilfe von Anpassungen dazu eingesetzt werden. Ein Vorteil beim
Einsatz dieser Werkzeuge z. B. zur Verwaltung von Anforderungen ist die
Integration, die zwischen Anforderungen und den Entwicklungsartefak-
ten erreicht wird, fr die diese Werkzeuge ursprnglich konzipiert wur-
den (wie Testflle oder nderungsantrge). Werden z. B. die Anforde-
rungen im Testverwaltungswerkzeug gepegt und nicht separat in einem
RM-Werkzeug, so fllt eine Werkzeugschnittstelle weg, und die Verknp-
fung von Anforderung und zugehrigen Testfllen kann leichter erfolgen.
Wiki-Technologien knnen zum kooperativen Aufbau von Glossaren
genutzt werden, im Brainstorming entworfene Mindmaps knnen als
Gliederungsstruktur dienen, mit Prsentationswerkzeugen kann man ein
grobes Analysekonzept erzeugen.
Aus der Praxis des Requirements Engineer 24
Des Weiteren werden im Requirements Engineering auch Werkzeuge,
die die alltglichen Arbeitsablufe im Ofce-Betrieb untersttzen, einge-
setzt: von Mailsystemen ber Chatsoftware, Adressbcher, Terminplaner,
Groupware-Plattformen bis hin zu Werkzeugen fr das Projektmanage-
ment bzw. fr die Projektplanung und das Projektcontrolling. Sie unter-
sttzen die Stakeholder im Requirements Engineering bei der Kommuni-
kation sowie der Planung und Koordination von Aufgaben.
Neben den natrlichsprachigen Informationen werden im Requirements
Engineering auch Informationen in Form von Modellen dokumentiert, die
mithilfe von Modellierungswerkzeugen erstellt werden. Diese Werkzeuge
bieten nicht nur die Mglichkeit, Modelle zu erstellen, sondern verfgen
oftmals auch ber Funktionen zur syntaktischen Analyse dieser Modelle.
Eine Fragestellung, die sich im Zusammenhang mit dem ergnzen-
den Einsatz verschiedener Werkzeuge ergibt, ist die Integration und Ver-
folgbarkeit zwischen Artefakten der verschiedenen Werkzeuge (z. B. Use
Cases, Verhaltensmodelle und Testflle). Die Wahl des Modellierungs-
werkzeugs oder des Werkzeugs fr das Requirements Management ist
so zu treffen, dass eine Schnittstelle zwischen den beiden Werkzeugen
besteht oder geschaffen werden kann, die es ermglicht, Verfolgbarkeits-
beziehungen zwischen Artefakten (Anforderungen, Modellelementen,
Anforderungsdokumenten, Testfllen usw.) zu setzen und zu verwalten.
Wenn sich Anforderungen ndern, ist es unerlsslich, dass die entspre-
chenden nderungen auch an den betroffenen Modellelementen vorge-
nommen werden knnen. In gleicher Weise gilt dies fr nderungen in
Anforderungsmodellen, die ggf. auch in die entsprechenden natrlich-
sprachigen Anforderungen integriert werden mssen.
Requirements-Management-Werkzeuge
Einschlgige Requirements-Management-Werkzeuge bieten Unterstt-
zung fr die Verwaltung von Anforderungen. Um die im Abschnitt An-
forderungen verwalten beschriebenen Techniken der Anforderungsver-
waltung optimal zu untersttzen, sollte ein Requirements-Management-
Werkzeug dabei folgende grundlegende Eigenschaften aufweisen:
Verwalten verschiedener Informationen (z. B. natrlichsprachige
Anforderungen, konzeptuelle Modelle, Skizzen, Testplne, nde-
rungswnsche)
Aus der Praxis des Requirements Engineer 25
Verwalten von logischen Beziehungen zwischen verschiedenen In-
formationen (Verfolgbarkeit, z. B. zwischen Anforderungen, zwi-
schen Anforderungen und deren Umsetzung)
Eindeutige Identizierbarkeit (z. B. sollte jedes verwaltete Arte-
fakt ber eine eindeutige ID verfgen)
Bearbeiten der verwalteten Informationen (Mehrbenutzerfhig-
keit, Zugriffskontrolle, Kongurations- und Versionsmanage-
ment)
Bilden von unterschiedlichen Sichten auf die verwalteten Informa-
tionen je nach Einsatzzweck
Organisieren der verwalteten Informationen (Gruppierung, Hier-
archiebildung, Attributierung und Annotation zustzlicher Infor-
mationen)
Erstellen von Reports oder Auswertungen ber die verwalteten
Informationen (z. B. Reports ber nderungsantrge fr Anfor-
derungen)
Generieren von Ergebnisdokumenten unterschiedlicher Form aus
den verwalteten Informationen (z. B. Erstellen von Anforderungs-
dokumenten fr spezische Systemreleases)
Aufgrund des Funktionsumfangs und der Abdeckung der grundlegenden
Funktionen lassen sich Werkzeuge, die fr das Requirements Manage-
ment eingesetzt werden knnen, in zwei Kategorien gruppieren: speziali-
sierte Werkzeuge sowie Standard-Broanwendungen.
Spezialisierte RM-Werkzeuge wurden speziell zur Untersttzung der
verschiedenen Techniken zur Verwaltung von Anforderungen konzipiert
und entwickelt und beherrschen bzw. untersttzen die Aufgaben in der
Verwaltung von Anforderungen am besten. Die charakteristischen Eigen-
schaften solcher Werkzeuge sind:
Verwaltung von Anforderungen und Attributen auf der Basis von
Informationsmodellen
Organisation von Anforderungen (mittels Hierarchieebenen)
Kongurations- und Versionsmanagement auf Anforderungsebene
Denition von Anforderungsbasislinien (Baselining)
Mehrbenutzerzugriff und -verwaltung (z. B. Zugriffskontrolle)
26 Aus der Praxis des Requirements Engineer
Verfolgbarkeitsmanagement (Traceability Management)
Konsolidierung der erfassten Anforderungen
(z. B. Sichtenbildung)
Untersttzung des nderungsmanagements (nderungskontrolle)
Die verschiedenen am Markt verfgbaren RM-Werkzeuge besitzen ei-
nen hnlichen Aufbau. So verfgen die einschlgigen Werkzeuge ber
eine Benutzungsoberche, ber die der Anwender mit dem Werkzeug
arbeitet und alle zur Verfgung gestellten Funktionen nutzen kann. Die
verwalteten Daten werden in einer Datenbank gespeichert und ber einen
integrierten Editor eingegeben und gendert. Verschiedene Import- und
Exportmechanismen fr Dokumente und Reporte stellen sicher, dass Da-
ten von externen Systemen in das Werkzeug eingelesen sowie aus dem
Werkzeug in externe Systeme ausgeleitet werden knnen.
Requirements-Management-Werkzeuge erreichen damit eine sehr
hohe Abdeckung der grundlegenden Funktionen.
Eine vergleichende Auistung der gngigsten Requirements-Manage-
ment-Werkzeuge nden Sie unter:
http://www.paper-review.com/tools/rms/read.php
Standard-Broanwendungen
In einer Vielzahl von Projekten werden jedoch trotz der wachsenden Ver-
breitung spezialisierter RM-Werkzeuge nach wie vor Standard-Broan-
wendungen (z. B. Textverarbeitung und Tabellenkalkulation) zur Verwal-
tung von Anforderungen eingesetzt. Die hauptschlichen Grnde hierfr
liegen einerseits in der weiten Verbreitung dieser Werkzeuge und ande-
rerseits darin, dass zur Nutzung kein zustzlicher Schulungs- bzw. Ein-
arbeitungsaufwand notwendig ist. In Verbindung mit dem Einsatz von
Schablonen, wie z. B. Schablonen zur Anforderungsdokumentation (siehe
vorheriger Abschnitt), eignen sich diese Werkzeuge fr die Dokumen-
tation und eingeschrnkt fr die Verwaltung von Anforderungen (z. B.
knnen Verfolgbarkeitsbeziehungen durch Hyperlinks etabliert werden).
Allerdings untersttzen solche Werkzeuge die grundlegenden Funkti-
onen des Requirements Management nur in geringem Umfang. So bieten
sie weder eine Versionsverwaltung auf Anforderungsebene noch verfgen
sie ber untersttzende Funktionen fr spezische Techniken in der Ver-
waltung von Anforderungen (z. B. die Mglichkeit, Verfolgbarkeitsbezie-
27 Aus der Praxis des Requirements Engineer
hungen zwischen einzelnen Artefakten automatisiert zu pegen). Einige
der grundlegenden Funktionen knnen mithilfe anderer Werkzeuge nach-
gebildet werden. So erfllt etwa eine Broanwendung, wenn sie in Ver-
bindung mit einem Versionsverwaltungswerkzeug eingesetzt wird, ggf.
die Anforderungen an eine Versionsverwaltung oder an den geregelten
Mehrbenutzerzugriff.
Trotz allem kann mit Standard-Broanwendungen bei der Verwal-
tung von Anforderungen in der Regel nicht die Leistungsfhigkeit spezi-
alisierter Werkzeuge erreicht werden.
Literatur 28
Literatur
[Boehm] B. Boehm: Software Engineering Economics, Prentice Hall, En-
glewood Cliffs 1981
[IEEE] Institute of Electric and Electronic Engineers: IEEE Standard
Glossary of Software Engineering Terminology (IEEE Std 610.12-
1990), IEEE Computer Society, New York 1990
Weiterfhrende Informationen
Die vorliegende Broschre basiert auf
Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering, ofzi-
elles Lehrbuch fr die Zertizierung zum Certied Professional for Requi-
rements Engineering Foundation Level, dpunkt.verlag, Heidelberg 2010
Das Buch Basiswissen Requirements Engineering basiert auf den bei-
den auagenstrksten Bchern zum Thema Requirements Engineering:
Klaus Pohl: Requirements Engineering Grundlagen, Prinzipien, Tech-
niken, dpunkt.verlag, Heidelberg 2008
sowie
Chris Rupp und die SOPHISTen: Requirements-Engineering und
-Management Professionelle, iterative Anforderungsanalyse fr die Pra-
xis, Hanser Fachbuchverlag, Mnchen 2009
Informationen zum International Requirements Engineering Board e. V.
sowie zur Zertizierung zum Certied Professional for Requirements En-
gineering nden Sie unter: http://www.certied-re.de.
Grau is alle Theorie
entscheidend is auffen Platz
Das Ganze bieten wir
in Form von Vortrgen,
Trainings, Beratung und
Coaching.
Wir bewahren Sie vor der
Abseitsfalle.
Sprechen Sie mit uns ber
Ihren Trainingsplan unter
+49 /911/40 9000.
Oder schreiben Sie eine
Mail an
heureka@sophist.de
Wir coachen dabei
v Anforderungen an
Systeme zu erheben und
zu dokumentieren.
v Widersprche und
Redundanzen in Model-
len zu erkennen.
v Notationen richtig
anzuwenden und
perfekt zu modellieren.
v eine Architektur zu
whlen, die lnger als
bis zur Abnahme aktuell
ist.
Adi Preiler
Genau! Deshalb mssen sich Mannschaften auch auf den Platz
optimal vorbereiten. Am besten geht das mit
Profitrainern wie den SOPHISTen.
www.sophist.de
Kleben Sie sich die RE & OO
Experten an die Wand
...oder legen Sie sich einen auf den Tisch.
Legale Spickzettel fr den Requirements Engineer und Modellierer.
Schicken Sie uns eine E-Mail an heureka@sophist.de mit dem
Codewort CPRE-Booklet.
Bitte geben Sie an, ob Sie Interesse an RE oder OO/UML haben.
SOPHIST GmbH
Vordere Cramergasse 13
90478 Nrnberg
fon: +49 (0)9 11 40 900-0
fax: +49 (0)9 11 40 900-99
www.sophist.de
2
.
,

a
k
t
u
a
lis
ie
r
t
e

A
u
f
la
g
e
Klaus Pohl Chris Rupp
Basiswissen
Requirements Engineering
Aus- und Weiterbildung nach IREB-Standard zum
Certied Professional for Requirements Engineering
Foundation Level
2., aktualisierte Auage
2010, 192 Seiten, Festeinband
b 29,90 (D)
ISBN 978-3-89864-708-3
d
p
u
n
k
t
.
r
e
q
u
i
r
e
m
e
n
t
s

e
n
g
i
n
e
e
r
i
n
g
Im Requirements Engineering hat sich der Certied Professional for Requirements
Engineering (CPRE) nach dem IREB-Standard als international standardisiertes Aus-
und Weiterbildungsprogramm etabliert.
Dieses Buch ist das erste Lehrbuch fr die Zertizierung zum Foundation Level
(Version 2.1) des CPRE, geschrieben von Mitgliedern des International Requirements
Engineering Board (IREB e. V.), die an der Entwicklung des Lehrplans beteiligt waren. Es
umfasst das Grundlagenwissen in den Gebieten Ermittlung, Dokumentation, Prfung
und Verwaltung von Anforderungen.
Das Buch eignet sich zum Selbststudium und als Begleitliteratur zu entsprechenden
Schulungen.
Klaus Pohl
Requirements Engineering
Grundlagen, Prinzipien,Techniken
2., korrigierte Auage
2008, 764 Seiten, Festeinband
b 49,00 (D)
ISBN 978-3-89864-550-8
Requirements Engineering ist der Schlssel zur erfolgreichen Entwicklung von
Software und softwareintensiven Systemen. Das moderne Requirements Engineering
gewinnt neue, innovative Anforderungen an solche Systeme und berfhrt sie in
detaillierte, mglichst vollstndige Anforderungsspezikationen.
Das Buch bietet eine umfassende Einfhrung in die Grundlagen, Prinzipien und
Techniken des Requirements Engineering. Die kompakte Darstellung der Inhalte sowie
deren Strukturierung anhand eines Rahmenwerks machen es zugleich zu einem Nach-
schlagewerk fr Praxis, Lehre und Forschung.
Mit zahlreichen Beispielen, Checklisten und praktischen Hinweisen.
d
p
u
n
k
t
.
s
o
f
t
w
a
r
e
e
n
t
w
i
c
k
l
u
n
g
4
.
,

b
e
r
a
r
b
e
it
e
t
e

u
n
d

a
k
t
u
a
lis
ie
r
t
e

A
u
f
la
g
e
dpunkt.verlag
Aus- und Weiterbildung
zum Certied Tester
- IoundaIon Ievel
- nach IS1OB-SIandard
Andreas Spllner - 1lo Inz
Andreas Spillner Tilo Linz
Basiswissen Softwaretest
Aus- und Weiterbildung zum Certied Tester Foundation
Level nach ISTQB-Standard
4., berarbeitete und aktualisierte Auage
2010, 308 Seiten, Festeinband
b 39,90 (D)
ISBN 978-3-89864-642-0
Andreas Spillner Thomas Roner Mario Winter Tilo Linz
Praxiswissen Softwaretest Testmanagement
Aus- und Weiterbildung zum Certied Tester
Advanced Level nach ISTQB-Standard
2., berarbeitete und aktualisierte Auage
2008, 438 Seiten, Festeinband
b 42,00 (D)
ISBN 978-3-89864-557-7
Graham Bath Judy McKay
Praxiswissen Softwaretest
Test Analyst und Technical Test Analyst
Aus- und Weiterbildung zum Certied Tester
Advanced Level nach ISTQB-Standard
2010, 430 Seiten, Festeinband
b 42,00 (D)
ISBN 978-3-89864-591-1
Bernd Hindel Klaus Hrmann Markus Mller
Jrgen Schmied
Basiswissen Software-Projektmanagement
Aus- und Weiterbildung zum Certied Professional for
Project Management nach iSQI-Standard
3., berarbeitete und erweiterte Auage
2009, 287 Seiten, Festeinband
b 39,00 (D)
ISBN 978-3-89864-561-4
Chris Rupp
Requirements Engineering
Requirements Engineering ist eine Schlsseldisziplin der Systementwicklung
und entscheidet mageblich ber den Erfolg oder Misserfolg eines Projekts.
Mit dieser Broschre erhalten Sie einen Einstieg in die vielschichtige Disziplin
des Requirements Engineering. Sie erfahren, was genau Requirements
Engineering ist, und lernen dessen verschiedene Ttigkeitsfelder kennen: die
Ermittlung, Dokumentation, Validierung und Verwaltung von Anforderungen.
Dabei wird Grundstzliches ber das Berufsbild und das Persnlichkeits prol
des Requirements Engineer vermittelt, und Sie bekommen einen Einblick in
einige Aspekte seiner tglichen Berufspraxis.
Die Broschre basiert auf Basiswissen Requirements Engineering, dem
ofziellen Lehrbuch fr die Zertizierung zum Certied Professional for
Requirements Engineering (CPRE) Foundation Level nach dem IREB-Standard,
verfasst von Klaus Pohl und Chris Rupp, den Autoren der auagenstrksten
deutschsprachigen Bcher zum Thema Requirements Engineering.
Art.-Nr.: 077.95731
Schutzgebhr: 3,00
www.dpunkt.de