requirements engineering mit dem sap solution...
TRANSCRIPT
Studiengang Informatik | Fachbereich 3
Requirements Engineering
mit dem SAP Solution Manager
Diplomarbeit vorgelegt von
Scharif Elsawa
Mat. Nr. 2003548
Gutachter: Prof. Dr. Karl-Heinz Rödiger
Dr. Dieter Müller
In Zusammenarbeit mit:
BTC Business Technology Consulting AG (BTC AG)
- Oldenburg -
Betreuer (BTC AG):
Dipl. Ing. (FH) Arne Steinkamp
19.12.2012
Erklärung
Hiermit bestätige ich, dass
die vorliegende Diplomarbeit selbständig durch den Verfasser und ohne Be-
nutzung anderer als der angegebenen Quellen und Hilfsmittel angefertigt wur-
de.
die benutzten Quellen wörtlich oder inhaltlich als solche kenntlich gemacht
wurden.
diese Arbeit in gleicher oder ähnlicher Form noch keiner Prüfungskommission
vorgelegt wurde.
Bremen, den 19.12.2012
__________________
Scharif Elsawa
Danksagung
An dieser Stelle möchte ich mich bei all denen bedanken, die mich bei der Anferti-
gung meiner Diplomarbeit so kräftig unterstützt haben.
Ich bedanke mich bei der der BTC Business Technology Consulting AG (BTC AG) für
die Zusammenarbeit und die praxisnahe Erarbeitung meiner Diplomarbeit.
Ganz besonders bedanke ich mich bei Prof. Dr. Karl-Heinz Rödiger, der mich mit
sehr viel Engagement, Ideen und Beratung unterstützt hat. Ebenfalls bedanke ich
mich herzlich bei meinem zweiten Gutachter Dr. Dieter Müller.
Meinen ganz speziellen Dank richte ich an meinen Betreuer Dipl. Ing. (FH) Arne
Steinkamp, der mich während meiner Zeit im Unternehmen stets mit Rat und Tat un-
terstützt hat.
Außerdem möchte ich mich bei meinen Eltern bedanken, die mich während des Stu-
diums zu einem großen Teil finanziell unterstützt haben und auch moralisch immer
eine Stütze für mich waren.
1 Einleitung ............................................................................................................ 1
1.1 Ziel der Arbeit ................................................................................................ 1
1.2 Übersicht über das Dokument ....................................................................... 2
2 Requirements Engineering ............................................................................... 3
2.1 Wichtigkeit des Requirements Engineerings ................................................. 3
2.2 Requirements Engineering – Was ist das? .................................................... 5
2.3 Grundbegriffe und Definitionen ...................................................................... 5
2.4 Kernaktivitäten im Requirements Engineering ............................................. 10
2.4.1 Ermittlung von Anforderungen .............................................................. 10
2.4.1.1 Anforderungsquellen .......................................................................... 10
2.4.1.2 Ermittlungstechniken ......................................................................... 11
2.4.2 Dokumentation von Anforderungen ...................................................... 13
2.4.2.1 Qualitätskriterien für Anforderungen .................................................. 13
2.4.2.2 Glossar .............................................................................................. 15
2.4.2.3 Anforderungen natürlichsprachig dokumentieren .............................. 16
2.4.2.4 Anforderungen modellbasiert dokumentieren .................................... 18
2.4.3 Prüfung von Anforderungen und Konfliktmanagement ......................... 20
2.4.3.1 Prüfung von Anforderungen ............................................................... 20
2.4.3.2 Konfliktmanagement .......................................................................... 23
2.4.4 Requirements Management .................................................................. 26
3 Requirements Engineering: Herleitung eines Soll Prozesses ..................... 30
3.1 Rahmenbedingungen und Abgrenzungen ................................................... 30
3.2 Daten (Attributliste) ...................................................................................... 31
3.2.1 Gesamtbild des RE-Soll-Prozesses ...................................................... 34
3.3 Phasen ........................................................................................................ 36
3.3.1 Aufnahme.............................................................................................. 36
3.3.2 Qualitätsprüfung .................................................................................... 39
3.3.3 Konfliktmanagement ............................................................................. 41
3.3.4 Aufwandschätzung / Bewertung ............................................................ 43
3.3.5 Freigabeprozess ................................................................................... 44
3.4 Bewertung und Reflexion des Prozesses .................................................... 45
4 Werkzeuge zum Requirements Engineering ................................................. 46
4.1 Arten von RE-Werkzeugen .......................................................................... 46
4.1.1 Spreadsheets ........................................................................................ 47
4.1.2 Wikis ..................................................................................................... 48
4.1.3 Workflow-Tools ..................................................................................... 48
4.1.4 Entwicklungsumgebungen und Modellierungswerkzeuge ..................... 49
4.1.5 Spezielle RE-Werkzeuge ...................................................................... 49
4.2 Beispiel: DOORS ......................................................................................... 50
4.3 Beispiel: Integrity ......................................................................................... 53
4.4 Kriterien für die Werkzeugeinführung .......................................................... 55
4.5 Der SAP Solution Manager ......................................................................... 57
5 Umsetzung (Abbildung) des hergeleiteten RE-Soll-Prozesses .................... 59
5.1 Prozessdefinition ......................................................................................... 59
5.2 Customizing ................................................................................................. 62
5.2.1 Status definieren ................................................................................... 64
5.2.2 Partnerfunktionen definieren ................................................................. 65
5.2.3 Aktionen definieren ............................................................................... 66
5.2.4 Bedingungen definieren ........................................................................ 68
5.2.5 Textschema definieren .......................................................................... 69
5.2.6 Sachverhaltsprofile definieren ............................................................... 70
5.2.7 Kategorie bearbeiten und dem Vorgang zuordnen ............................... 70
5.2.8 Terminprofil definieren .......................................................................... 71
5.3 Offene Punkte der Umsetzung .................................................................... 72
6 Fazit ................................................................................................................... 73
7 Verzeichnisse ................................................................................................... 74
7.1 Literaturverzeichnis ..................................................................................... 74
7.2 Abbildungsverzeichnis ................................................................................. 76
7.3 Tabellenverzeichnis ..................................................................................... 78
7.4 Anhang ........................................................................................................ 79
1
1 Einleitung
„ It isn‘t that they can‘t see the solution. It is that they can‘t see the problem! “
[Gilbert Keith Chesterton]
Viel zu oft kommt es vor, dass wir uns den Kopf zerbrechen über eine Lösung, ohne
wirklich verstanden zu haben, was für ein Problem tatsächlich gelöst werden soll.
Oder wir im Berufsalltag zu Besprechungen einladen, ohne vorher zu reflektieren,
welchen Zweck diese erfüllen sollen. So ist es auch häufig in der IT-Welt: Es werden
Funktionen für ein Softwaresystem entwickelt, ohne genau zu wissen, welchen Wert
sie für eventuelle Benutzer ausmachen.
Daher ist es sehr wichtig, sich von vorne herein genau Gedanken zu machen, welche
Anforderungen an ein zu entwickelndes System gestellt werden. Softwaresysteme
werden zunehmend komplexer und es ist daher unumgänglich, ein professionelles
Requirements Engineering in der Entwicklung in Betracht zu ziehen.
Auch SAP Systeme nehmen immer mehr an Komplexität zu. Ohne eine systemati-
sche Vorgehensweise wird es sehr schwer sein, ein komplexes System, welches un-
überschaubar viele Anforderungen enthält, zu erfassen, zu dokumentieren, zu kon-
trollieren und zu verwalten.
1.1 Ziel der Arbeit
Das Ziel der Diplomarbeit ist es deshalb, anhand von aktueller Literatur die genauen
Aktivitäten des Requirements Engineering zu erfassen, um diese anschließend in
einem geeignetem Prozess mit einzubeziehen, da es keinen Standard-RE-Prozess
gibt. Dieser, aus der Literatur hergeleitete Prozess, soll anschließend in das SAP
Tool „SAP Solution Manager“ abgebildet werden. Der SAP Solution Manager ist ein
Application LifeCycle Management Tool für die SAP Landschaft, der auf dem ITIL-
Standard basiert. Neben dem Solution Manager sollen weitere RE-Tools zum Ver-
gleich veranschaulicht werden.
2
1.2 Übersicht über das Dokument
In Kapitel 2 wird das Thema Requirements Engineering aufgearbeitet und mit den
wichtigsten Aktivitäten des Requirements Engineering beschrieben. Hierzu sollen
insbesondere die Kernaktivitäten, wie zum Beispiel das Ermitteln von Anforderungen,
das Dokumentieren von Anforderungen, das Prüfen von Anforderungen mit dem da-
mit verbundenen Konfliktmanagement und das Requirements Management (das
Verwalten von Anforderungen) beleuchtet werden.
Des Weiteren folgt in Kapitel 3 die Herleitung eines RE-Prozesses. Dabei werden
die wichtigsten Aktivitäten vom Requirements Engineering analysiert und in sinnvolle
Phasen unterteilt. Zudem wird eine angepasste Attributliste veranschaulicht und der
hergeleitete Prozess erläutert.
In Kapitel 4 werden dann die verschiedenen Arten von RE-Werkzeugen aufgezeigt
und anhand von zwei verschiedenen Tools (DOORS und Integrity) beispielhaft dar-
gestellt. Außerdem werden Kriterien für eine geeignete Werkzeugeinführung aufge-
zeigt. Abschließend wird eine Beschreibung von dem SAP Solution Manager erfol-
gen.
In Kapitel 5 soll dann die Umsetzung (in SAP auch oft Abbildung genannt) des her-
geleiteten Prozesses in dem SAP Solution Manager erfolgen. Hierzu wird eine ange-
passte Übersicht aufgezeigt und beschrieben. Screenshots sollen die Abbildung un-
termauern. Anschließend erfolgt eine Beschreibung der Grenzen dieses Prozesses.
In Kapitel 6 werden die Ergebnisse der Diplomarbeit zusammengefasst und sollen
abschließend einen Ausblick über das Thema Requirements Engineering geben. Da-
zu soll beschrieben werden, in wie weit sich der SAP Solution Manager für das Re-
quirements Engineering eignet und wo die Grenzen liegen.
Zuletzt erfolgt eine Angabe der Verzeichnisse, außerdem folgen im Anhang komplet-
te Screenshots aus dem SAP Solution Manager.
3
2 Requirements Engineering
In den letzten Jahren ist Requirements Engineering ein immer wichtigeres Thema in
der Softwareentwicklung geworden.
In diesem Kapitel wird eine Einführung in das Thema Requirements Engineering fol-
gen, warum es so wichtig ist und wie es aktuell betrieben wird. Hierzu werden die
Kernaktivitäten des Requirements Engineering verdeutlicht..
2.1 Wichtigkeit des Requirements Engineerings
Warum soll man ein System für einen Kunden entwickeln was nicht wirklich den
Kundenwünschen entspricht? Anhand dieser zentralen Frage lässt sich erkennen,
dass man von vornerein, also vor Beginn der Entwicklungsphase, sich genau den
Wünschen des Kunden bewusst ist und diese auch genau versteht und spezifiziert.
Eine Studie der Standish Group von 2010 zeigt, dass gut ein Drittel aller Projekte
erfolgreich abgeschlossen wird. Ein Fünftel wird abgebrochen und die restlichen Pro-
jekte entweder zu spät oder nur mit erhöhtem Budget. [Standish 2011]
Abbildung 1: Gründe für das Scheitern von IT-Projekten (vgl. [Standish 2011])
Jedoch werden Mängel, die in der der Analysephase, also im Requirements Enginee-
ring-Prozess, erst viel zu spät bzw. gar nicht erkannt und können somit für einen ex-
21%
37%
42%
21% Abgebrochen 37% Erfolgreich 42% Zu spät oder über Budget
4
ponentiellen Anstieg der Projektkosten sorgen. Je später Anforderungsfehler ent-
deckt werden umso höher sind die damit verbundenen Kosten einer Korrektur. Somit
kann ein entdeckter Anforderungsfehler in der Entwicklungs- bzw. Programmierpha-
se die Kosten für dessen Korrektur um einen Faktor 20 erhöhen. Ein Fehler in der
Abnahmephase kann sogar für einen Faktor von 100 sorgen (vgl. [Pohl 2008], S. 11).
Aus diesen Zahlen lässt sich erkennen was für eine Wichtigkeit das Requirements
Engineering im Softwareentwicklungsprozess spielt. Laut [Pohl 2008] wären noch
folgende weitere Hauptgründe für die stetige Bedeutung von Requirements Enginee-
ring aus der Praxis zu erwähnen:
Das Scheitern von Projekten von mangelhaften Anforderungsspezifikationen
Die Herausforderung, innovativere, individuellere und komplexere softwarein-
tensive Systeme schneller, mit höherer Qualität und zu immer geringeren
Preisen auf den Markt zu bringen
Die steigende Bedeutung von Softwaresystemen in zahlreichen Industriezwei-
gen mit wachsenden Funktionsumfängen, engerem Integrationsbedarf mit an-
deren Systemen sowie differenzierterer Nutzung
Meist liegen die Ursachen für ein mangelhaftes Requirements Engineering in den
Anforderungen selbst. Häufig werden diese nicht klar formuliert oder fehlen schlicht-
weg einfach. Bei einer nicht klar formulierten Anforderung kann es dazu führen, dass
das System nicht den Wünschen des Kunden entspricht. Weiterhin entstehen häufig
Unklarheiten aufgrund von Kommunikationsproblemen zwischen Stakeholdern (Pro-
jektbetroffenen) (vgl. [Pohl 2008], S. 11).
5
2.2 Requirements Engineering – Was ist das?
Dem Requirements Engineering im Entwicklungsprozess kommt die Aufgabe zu, die
Anforderungen der Stakeholder zu ermitteln, zweckmäßig zu dokumentieren, zu
überprüfen und abzustimmen sowie die dokumentierten Anforderungen über den ge-
samten Lebenszyklus des Systems zu verwalten [Pohl 1996].
Die daraus vier herausgeleiteten Hauptaktivitäten des Requirements Engineering
sind: Ermitteln, Dokumentieren, Prüfen von Anforderungen inkl. dem Konfliktma-
nagement (Abstimmen von Anforderungen) und das Requirements Management
(Verwalten von Anforderungen).
Die einzelnen Unteraktivitäten werden in den folgenden Kapiteln näher erläutert. Die
Requirements-Engineering-Phase gilt als die wichtigste Phase in der Software-
Entwicklung überhaupt. Zentrale Frage die sich dabei stellt: „Welchen Nutzen hat es,
ein nach Informatik-Gesichtspunkten perfektes System zu entwickeln, wenn es nicht
das System ist, das die Kunden wünschen?“
2.3 Grundbegriffe und Definitionen
Requirements Engineering und Requirements Management
Eine passende Definition von Requirements Engineering findet sich in [Rupp 2009]
wieder:
Definition Requirements Engineering laut [Rupp 2009]:
Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spe-
zifikation und zum Management von Anforderungen mit den folgenden Zielen:
1. Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern
über die Anforderungen herzustellen, die Anforderungen konform zu vorgege-
benen Standards zu dokumentieren und die Anforderungen systematisch zu
managen.
6
2. Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentie-
ren sowie die Anforderungen zu spezifizieren und zu managen, um das Risiko
zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der
Stakeholder entspricht.
Aus der Definition kann man somit herausgreifen, dass Requirements Management
ein Teil bzw. ein paralleler Prozess des Requirements Engineering ist. Requirements
Management beschäftigt sich mit der Pflege, Verwaltung und Weiterentwicklung der
Anforderungen und unterstützt somit den eigentlichen Requirements Engineering
Prozess. Es ergreift alle Maßnahmen um Anforderungen zu strukturieren, für unter-
schiedliche Rollen aufzubereiten sowie konsistent zu ändern und umzusetzen. Die
genauen Tätigkeiten vom Requirements Management werde ich in Kapitel 2.4.4 dar-
stellen und erläutern.
Anforderung
Die Definition laut [IEEE610] und [Rupp et al. 2011] und lautet:
Eine Anforderung ist:
1. Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System)
zu Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
2. Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder
besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere,
formell vorgegebene Dokumente zu erfüllen
3. Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß
1. oder 2. .
Anforderungen dienen im Requirements Engineering allen Beteiligten die Grundlage
für Kommunikation, Diskussion und Argumentation und spiegeln daher die konkreten
Vorstellungen und Ideen der Stakeholder. Zudem beeinflussen sie die zukünftige Ar-
chitektur des zu erstellenden Systems da sie als Basis dienen.
7
Die daraus resultierende Anforderungsspezifikation(also die Menge der beschriebe-
nen Anforderungen) eignet sich daher sehr gut als Grundlage für eine zukünftige
Vertragsgestaltung. (vgl. [Rupp 2009], S. 13)
Arten von Anforderungen
Anforderungen werden in den drei verschiedenen Arten unterschieden:
Abbildung 2: Arten von Anforderungen
Definition laut IREB [Rupp et al. 2011] für eine funktionale Anforderung:
Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines
Verhaltens, das von einer Funktion des Systems bereitgestellt werden soll.
Funktionale Anforderungen beschreiben somit Aktionen was das System bzw. eine
Komponente zukünftig genau ausführen soll.
Definition laut IREB [Rupp et al. 2011] für eine Qualitätsanforderung:
Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal
bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.
Qualitätsanforderungen werden auch oft als nicht-funktionale Anforderung bezeich-
net. Typische Beispiele für Qualitätsanforderungen sind Performance, Verfügbarkeit,
Zuverlässigkeit, die Skalierbarkeit oder die Portabilität bezüglich eines Systems.
Definition laut IREB [Rupp et al. 2011] für eine Randbedingung:
Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen
einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Quali-
tätsanforderungen zu erfüllen.
Anforderungen
Funktionale
Anforderungen
Qualitäts-
anforderungen
Rand-
bedingungen
8
Randbedingungen sind nicht direkt umsetzbar sondern schränken ein System bzw.
dessen Umsetzungsmöglichkeiten ein und sind daher nur schwer oder gar nicht än-
derbar. Beispiele für eine Randbedingung wäre "Das System soll durch Webservices
realisiert werden" oder " Das System soll bis spätestens Ende März auf dem Markt
sein".
Stakeholder
Definition laut IREB [Rupp et al. 2011] für Stakeholder:
Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder
indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.
Stakeholder dienen deshalb u.a. als die wichtigste Quelle zur Identifikation für Anfor-
derungen. Es können Personen oder Organisationen sein, die mit dem geplanten
System in irgendeiner Weise beteiligt sind und haben daher Einfluss auf die Anforde-
rungen. Beispiele sind z.B. Nutzer des Systems, Entwickler, Administratoren, Auf-
traggeber, Tester, Regulierungsbehörden oder auch Kontrollgremien sein.
Werden Stakeholder im Requirements Engineering Prozess nicht richtig identifiziert,
kann das fatale Folgen bzgl. des zu realisierenden Systems haben, da fehlende An-
forderungen erst bei der Inbetriebnahme des Systems erkannt werden und eine
nachträgliche Umsetzung dieser Anforderung evtl. mit sehr hohen Kosten verbunden
sein kann.
9
Einbettung des Requirements Engineering in Vorgehensmodelle
In den sogenannten schwergewichtigen Vorgehensmodellen (wie z.B. dem Wasser-
fallmodell [Royce 1987] oder dem V-Modell [V-Modell 2006]) wird das Requirements
Engineering als eigenständige Einleitungsphase gesehen (s. Abb.3). Somit versucht
man am Ende dieser ersten abgegrenzten Phase eine vollständige Anforderungs-
spezifikation aufzustellen und zu dokumentieren die alle Anforderungen an das zu-
künftige System stellt, beinhaltet.
Abbildung 3: Requirements Engineering als abgeschlossene Phase ([Pohl 2008], S.30)
Im Gegensatz dazu verhält sich das Requirements Engineering bei den sogenannten
leichtgewichtigen Modellen (wie z.B. dem Extreme Programming [Beck 1999] oder
Scrum [Schwaber et al. 2001]) eher als begleitender Prozess. Diese agilen (Synony-
me für agil sind z.B. dynamisch oder flexibel) Vorgehensmodelle basieren darauf,
dass es schwierig sei die kompletten Anforderungen von vornerein zu bestimmen da
sie sich im Laufe eines Projektes verändern können. Somit wird hier das Require-
ments Engineering als ein kontinuierlicher, phasenübergreifender Prozess gese-
hen(s. Abb. 4).
Abbildung 4: Requirements Engineering als begleitender Prozess ([Pohl 2008], S.31)
Entwicklungsprojekt A
RE für System A
Entwicklungsprojekt A
RE für System A
Entwicklungs-
projekt A
RE für System
A
Entwicklungs-
projekt B
RE für System
B
10
Der Requirements Engineer
Der Requirements Engineer spielt die zentrale Rolle im Requirements Engineering.
Ihm ist wichtige Rolle gegeben so gesagt als "Dolmetscher" zwischen allen Stake-
holdern zu vermitteln, die Bedürfnisse hinter ihren Aussagen zu erkennen und diese
dann so aufzubereiten, dass fachfremde Architekten und Entwickler sie verstehen
und umsetzen können. Der Requirements Engineer muss zudem über genug IT-
Know-how verfügen um sich der Probleme der Entwickler klar zu sein und mit ihnen
gleichberechtigt kommunizieren zu können. Wichtige Eigenschaften die zu erwähnen
wären sind empathische Fähigkeiten, Kommunikationsfähigkeit, Konflikt-
lösungsfähigkeit und Moderationsfähigkeit (vgl. [Rupp et al. 2011], S. 14 ff.).
2.4 Kernaktivitäten im Requirements Engineering
2.4.1 Ermittlung von Anforderungen
In diesem Kapitel werde ich die wichtigsten Anforderungsquellen angeben und erläu-
tern. Anschließend werde ich die aus der Praxis effektivsten Ermittlungstechniken
darstellen und beleuchten.
2.4.1.1 Anforderungsquellen
Laut IREB [Rupp et al. 2011] werden drei verschiedene Anforderungsquellen unter-
schieden: Dokumente, Systeme im Betrieb sowie Stakeholder.
Dokumente hat man eine gute Möglichkeit Anforderungen entnehmen zu können.
Diese Beispiele für Dokumente aus denen man wichtige Informationen entnehmen
könnte sind vor allem aus allgemeingültigen Dokumenten (z.B. Normen, Standards
oder Gesetzestexten), branchen- oder organisationsspezifische Dokumente (z.B.
Fehlerberichte, Schulungsunterlagen oder das Anforderungsdokument des Altsys-
tems).
11
Systeme im Betrieb können Alt- bzw. Vorgängersysteme aber auch Konkurrenzsys-
teme sein. Stakeholder können auf Basis dieser Systeme (z.B. durch Ausprobieren)
Erweiterungen oder Änderungen als Anforderungen erheben.
Stakeholder sind Personen oder Organisationen die (direkt oder indirekt) Einfluss
auf die Anforderungen haben. Sie sind die wirklichen Wissensquellen für Anforde-
rungen und wurden daher im Kapitel 2.3 näher erläutert.
2.4.1.2 Ermittlungstechniken
Ermittlungstechniken aller Art dienen hauptsächlich der Ermittlung von Anforderun-
gen der Stakeholder. Es gibt aus der Praxis aber keine Universalvorschrift wie man
Anforderungen ermitteln kann. Empfehlenswert ist daher eine Kombination verschie-
dener Techniken. Ich werde folgend die sich aus der Praxis und Literatur ([Rupp et
al. 2011], S. 34 ff.) am effektivsten Techniken kurz erläutern.
Befragungstechniken basieren darauf, die Stakeholder gezielt nach ihren Wün-
schen zu befragen. Daher ist es nötig, dass der Stakeholder sich der Anforderung
bewusst ist und diese auch sprachlich erläutern kann. Klassische Methoden für Be-
fragungstechniken sind Fragebögen und Interviews.
Vorteil der Fragebögen ist das viele Informationen in geringer Zeit eingeholt werden
können und evtl. auch automatisiert ausgewertet können. Nachteile ist der hohe
Aufwand bei der Erstellung und dass die Fragen auf das Wissen bzw. Vermutungen
des Requirements Engineer beruhen. Im Gegensatz dazu ist der große Vorteil bei
den Interviews die direkte Rückkopplung von den Stakeholdern.
Kreativitätstechniken helfen dabei eine erste Vision eines Systems zu entwickeln.
Sie eignen sich daher sehr gut für die Ermittlung von innovativen Ideen um auf un-
bewusste Anforderungen der Stakeholder zu gelangen. Bekannte Beispiele für Krea-
tivitätstechniken sind vor allem das Brainstorming und das Brainstorming paradox.
Beim Brainstorming werden in einer kleinen Gruppe in einer bestimmten Zeit (typi-
scherweise 20 Minuten) Ideen gesammelt und vom Moderator notiert ohne diese zu
12
bewerten. Vorteil dieser Methode ist das viele Ideen und kurzer Zeit gesammelt wer-
den können und dass diese Ideen auch schnell weitere Ideen entwickeln können.
Nachteil ist dass die Teilnehmer in der gleichen Zeit (auch wenn virtuell über eine
Moderationssoftware) anwesend sein müssen.
Brainstorming paradox basiert auf dem gleichen Prinzip nur dass hier Ideen ge-
sammelt werden die nicht erreicht werden sollen. Der große Vorteil des Brainstor-
mings paradox ist dass sich oft Risiken identifizieren lassen.
Bei allen Kreativtechniken ist vor allem aber eine gute Gruppendynamik gefragt. Als
unterstützende Technik bei den Kreativitätstechniken kann das Mindmapping dienen.
Dokumentenzentrierte Techniken eignen sich gut im Falle einer Ablösung eines
Altsystems durch ein Neusystem da hier eine Identifikation der bestehenden Funktio-
nalitäten erfolgen kann. Dokumentenzentrierte Techniken sollten aber mit Kreativi-
tätstechniken kombiniert werden um dann zusätzlich neue Funktionen an das zu
entwickelnde System zu ermitteln. Bekannte Techniken dieser Kategorie sind die
Systemarchäologie und die Wiederverwendung(Reuse).
Bei der Systemarchäologie werden Dokumente (wie. z.B. Benutzerhandbuch, Test-
fälle, Implementierungscode) als Informationsquelle benutzt. Der große Vorteil bei
dieser Ermittlungstechnik ist das durch die Analyse vom bestehenden Systems si-
chergestellt wird keine der bereits implementierten Funktionalitäten vergessen wird
und falls gefordert diese wieder in dem Neusystem übernommen werden. Nachteil
dieser Methode ist dass sie sehr aufwändig ist und die Dokumente in guter Quali-
tät(z.B. nicht veraltet, etc.) vorhanden sein müssen.
Bei der Wiederverwendung(Reuse) werden Anforderungen von einem schon mal
ähnlich entwickelten System wiederverwendet. Wenn man diese Technik richtig an-
wendet kann man somit sehr viel Einsparungspotential erlangen. Dokumentenzen-
trierte Techniken sollten aber im Allgemeinen mit Kreativitätstechniken kombiniert
werden um an neue Anforderungen und Ideen zu gelangen.
13
Beobachtungstechniken eignen sich sehr gut wenn die Stakeholder ihre Tätigkei-
ten und Wissen nicht gut in Worte fassen und oder aufgrund ihrer Zeit das Wissen an
den Requirements Engineer vermitteln können. Durch geschicktes Hinterfragen kann
der Requirements Engineer eine gute Sollsituation ermitteln. Hier kommen vorwie-
gend die Feldbeobachtung und das Apprenticing zum Einsatz.
Bei der Feldbeobachtung beobachtet und dokumentiert der Requirements Engineer
den Anwender dessen Handgriffe und Arbeitsabläufe. Großer Vorteil bei dieser
Technik ist dass, auch unbewusste Arbeitsschritte, welche in komplexen Abläufen
stecken, zum Vorschein kommen können, die der Anwender aus Gewohnheit für
selbstverständlich hält.
Beim Apprenticing("in die Lehre gehen") werden die Rollen umgedreht und der der
Requirements Engineer schlüpft in die Rolle des Anwenders nachdem er die Tätig-
keiten des Stakeholders erlernt hat und hat dann die Möglichkeit wie ein Lehrling Ar-
beitsschritte zu hinterfragen. Zusätzlich können Audio- und Videoaufzeichnungen die
Beobachtungstechniken unterstützen. Diese Techniken haben den Nachteil dass sie
meist sehr zeit- und kostenaufwändig werden können.
2.4.2 Dokumentation von Anforderungen
In diesem Kapitel werde ich zunächst die Qualitätskriterien für einzelne Anforderun-
gen (in Anlehnung an [Rupp et al. 2011], S. 52 ff.) darstellen und erläutern. Daraufhin
folgt die Erklärung eines Glossars im Requirements Engineering und im Anschluss
wie man Anforderungen laut [Rupp 2009] und [Rupp et al. 2011] natürlichsprachig
und modellbsiert dokumentieren sollte.
2.4.2.1 Qualitätskriterien für Anforderungen
Um zu erkennen ob eine Anforderung gut ist oder nicht können die Qualitätskriterien
vom IEEE-Standard 830 [IEEE Std 830-1998] für ein Anforderungsdokument auch
für einzelne Anforderungen definiert werden. Diese werden folgend genannt und kurz
erläutert (wobei die wichtigsten drei Qualitätskriterien vollständig, konsistent und kor-
rekt etwas hervorgehoben sind):
14
Vollständig [IEEE Std 830-1998]:
Jede einzelne Anforderung muss die geforderte und zu liefernde Funktionalität
vollständig beschreiben. Evtl. unvollständige Anforderungen müssen kenntlich
gemacht werden.
Konsistent [IEEE Std 830-1998]:
Eine Anforderung ist konsistent wenn sie über allen Anforderungen und über
sich selbst widerspruchsfrei ist.
Korrekt [IEEE Std 830-1998]:
Eine Anforderung ist korrekt wenn sie die Vorstellung des Stakeholders adä-
quat wiederspiegelt. D.h. sie darf nicht über die Erwartungen des Stakehol-
ders gehen.
Bewertet [IEEE Std 830-1998]:
Die Anforderungen sollten ab einer gewissen Komplexität eines Systems z.B.
nach Wichtigkeit, rechtlicher Verbindlichkeit oder Priorität bewertet werden.
Eindeutig [IEEE Std 830-1998]:
Alle Leser müssen zu einem einzigen konsequenten Verständnis der Anforde-
rung gelangen. (keine anderen Sachverhalte hinein interpretierbar)
Prüfbar [IEEE Std 830-1998]:
Eine Anforderung ist prüfbar, wenn sie (bzw. die Funktionalität) sich durch ei-
nen Test oder Messung nachweisen lässt.
Verfolgbar [IEEE Std 830-1998]:
Eine Anforderung ist nachvollziehbar, wenn sowohl der Ursprung der Anforde-
rung als auch deren Umsetzung und die Beziehung zu anderen Dokumenten
nachvollziehbar sind. Sichergestellt wir dies über einen eindeutigen
Anforderungsidentifikator.
Zusätzlich werden laut [Rupp et al. 2011] folgende Qualitätskriterien hinzugefügt um
die Anforderung als "exzellent" zu bezeichnen:
Gültig und aktuell:
Die dokumentierte Anforderung muss in Hinblick auf den aktuellen Gegeben-
heiten (Vorstellungen der Stakeholder, externe Schnittstellen) aktuell und gül-
tig sein.
15
Abgestimmt:
Die Anforderung ist korrekt und alle Stakeholder akzeptieren diese als gültige
Anforderung.
Realisierbar:
Ein Entwickler kann bzgl. der Realisierung einer Anforderungen konkret Fak-
ten aufzeigen in Hinsicht auf Umsetzung und evtl. Kosten.
Verständlich:
Die Anforderungen müssen für alle Stakeholder verständlich sein. Hierzu ist
es wichtig die Bedeutung der verwendeten Begrifflichkeiten festzulegen (s.
Kapitel 2.4.2.2)
2.4.2.2 Glossar
Um Konflikte im Requirements Engineering zu vermeiden, ist es notwendig, dass alle
Stakeholder eine konsistente Terminologie verwenden. In Glossaren werden alle
Fachbegriffe definiert, die für das Verständnis eines Projekts notwendig sind. Dazu
werden für jeden Fachbegriff seine Definition, Synonyme für diesen Begriff, verwand-
te Begriffe und Beispiele bzw. Gegenbeispiele aufgelistet. Zum einen helfen Glossa-
re natürlich dabei Missverständnisse zu vermeiden, sie erleichtern aber auch die
Einarbeitung von Mitarbeitern. Allerdings beheben Glossare nur die Vagheit von Be-
griffen, die anderen Nachteile existieren nach wie vor.
Ein Glossar ist eine Sammlung von Begriffsdefinitionen und enthält beispielsweise
Folgendes:
Kontextspezifische Fachbegriffe
Abkürzungen und Akronyme
Alltägliche Begriffe, die im gegebenen Kontext eine spezifische Bedeutung
haben
Synonyme: verschiedene Begriffe mit gleicher Bedeutung
Homonyme: Begriff mit verschiedenen Bedeutungen
16
2.4.2.3 Anforderungen natürlichsprachig dokumentieren
Oft werden noch Anforderungen an das zu entwickelnde System anhand von natürli-
cher Sprache dokumentiert. Der Vorteil ist der, dass die Stakeholder (weitestgehend)
alles verstehen und - im Gegensatz zur modellbasierten Dokumentation - sich nicht
in eine bestimmte Notation einarbeiten müssen. Trotzdem kommt es aufgrund von
"Transformationseffekten" (also von der persönlichen Wahrnehmung über das damit
verbundene persönliche Wissen bis hin zum sprachlichen Ausdruck) oft zu Missver-
ständnissen. Die im Requirements Engineering häufig eintretenden Transformations-
prozesse sind Nominalisierung, Substantive ohne Bezugindex, Universalquantoren,
unvollständig spezifizierte Bedingungen, unvollständig spezifizierte Prozesswörter.
([Rupp et al. 2011] S.60 ff.)
Um eine Reduzierung dieser sprachlichen Effekte zu reduzieren sollte man sich einer
leicht erlernbaren Satzschablone bedienen.
Definition laut [Rupp et al. 2011]:
Eine Satzschablone (Requirements Template) ist ein Bauplan für die syntaktische
Struktur einer einzelnen Anforderung.
Die folgenden fünf Schritte erläutern die Benutzung der Satzschablone:
1. Festlegen der rechtlichen Verbindlichkeit (Wichtigkeit):
Mit den Modalverben muss(verpflichtend), sollte(wünschenswert) und
wird(wird in Zukunft integriert) lässt sich die rechtliche Verbindlichkeit sehr gut
ausdrücken.
2. Der Kern der Anforderung
Die geforderte Funktionalität (Prozess) steht im Mittelpunkt jeder Anforderung.
Diese Prozesse (Tätigkeiten, Vorgänge) sollten ausschließlich durch Verben
beschrieben werden (z.B. drucken, speichern, etc.).
3. Charakterisieren der Aktivität des Systems
Selbstständige Systemaktivität: Das System führt den Prozess selbst-
ständig durch. (DAS SYSTEM <Systemname> <muss|sollte|wird>
<Prozesswort>)
Benutzerinteraktion: Das System stellt dem Nutzer eine Funktionalität
zu Verfügung (z.B. über eine Eingabe- oder Auswahlmaske) oder tritt
17
mit ihm in Interaktion. (DAS SYSTEM <Systemname>
<muss|sollte|wird> <wem> DIE MÖGLICHKEIT BIETEN <Prozess-
wort>)
Schnittstellenanforderung: Das System führt eine Aktion aus wenn
Nachrichten oder Daten von Dritten(z.B. Fremdsystem) eintreffen (also
in Abhängigkeit) (DAS SYSTEM <Systemname> <muss|sollte|wird>
FÄHIG SEIN <Prozesswort>)
4. Objekte einfügen
In diesem Schritt sollte man das Objekt und dessen Ergänzungen, für das die
Funktionalität gefordert wird identifizieren. Hierbei werden die Schablone um
das WAS oder WO ergänzt. (Beispiel: Das Bibliothekssystem sollte dem Be-
nutzer die Möglichkeit bieten, einen Benutzerausweis auf dem Netzwerkdru-
cker zu drucken.)
5. Formulierung von logischem und zeitlichen Bedingungen
In dem Schritt legt man die Bedingungen(zeitlich oder logisch) fest, unter der
eine geforderte Funktionalität durchgeführt werden soll. Für eine zeitliche Kon-
junktion sollte man sobald und für die logische falls benutzen. Die Konjunktion
wenn sollte vermieden werden, da sie sowohl für zeitliche als auch logische
Bedingungen angewendet werden kann und daher zu Missverständnissen
führen kann. Durch die Einführung einer Bedingung ändert sich die Satzstel-
lung sodass eine neue Schablone dafür entsteht.
DAS SYS-
TEM SOLLT
E
MUSS
WIRD
-
<wem?>
DIE MÖGLICHKEIT BIE-
TEN
<Prozesswort>.
FÄHIG SEIN
<Prozesswort>.
<Objekt &
Ergänzung
des Ob-
jekts>
<Prozesswort>.
Schritt 1:
Wichtigkeit
Schritt 3:
Art der Funktionalität
Schritt 2:
Funktionalität identifizieren
Schritt 4:
Objekt identifizieren
Abbildung 5: Vollständige Satzschablone ohne Bedingung ([Rupp 2009], S. 162)
18
Die dargestellten Anforderungsschablonen haben den großen Vorteil da sie sehr ein-
fach zu verstehen sind. Dies gilt insbesondere auch für Personen, die keine Experten
im Bereich der Software Engineering sind. Wichtiger Grund ist dafür die Nähe zur
natürlichen Sprache. Durch die Anwendung dieser Schablonentypen ist eine stark an
die natürliche Sprache angelehnte Formulierung möglich. Die Schablonen können
sowohl für funktionale, als auch für nichtfunktionale Anforderungen verwendet wer-
den. Da schon zu Beginn, durch das Einhalten der Regeln, qualitativ hochwertigere
Anforderungen entstehen können und somit das spätere Verbessern seltener nötig
wird.
Ein großer Nachteil mit der Anwendung der Anforderungsschablonen ist der, dass
mit der zunehmenden Komplexität einer Anforderung diese sehr unübersichtlich wer-
den kann. Es können somit unter Umständen sehr lange und schwer verständliche
Sätze bzw. Anforderungen entstehen.
2.4.2.4 Anforderungen modellbasiert dokumentieren
Zusätzlich können Anforderungen mit diversen Modellen beschrieben werden. Dies
hat den großen Vorteil das grafische (bildhafte) Darstellungen der Anforderungen
besser und schneller verstanden werden können. Dies benötigt aber, dass das Mo-
dell vom Leser bekannt ist. Somit benötigt diese Art der Modellierung im Gegensatz
zur natürlichsprachlichen Dokumentation eine Einarbeitung in die Modelle mit denen
die Anforderung beschrieben ist.
DAS SYS-
TEM SOLLT
E
MUSS
WIRD
-
<wem?>
DIE MÖGLICHKEIT BIE-
TEN
<Prozesswort>.
FÄHIG SEIN
<Prozesswort>.
<Objekt &
Ergänzung
des Objekts
<Prozesswort>.
Wann?
Unter welcher
Bedingung?
Schritt 5: logische oder zeitliche
Bedingung formulieren
Abbildung 6: Die vollständige Satzschablone inklusive Bedingung ([Rupp 2009], S. 166)
19
Die Unified Modeling Language(UML) hat sich in den letzten Jahren zu einem De-
facto-Standard für modellbasierte Dokumentationen für Softwaresysteme etabliert.
Sie besitzt verschiedene Modelle um eine Softwaresystem von verschiedenen Per-
spektiven (Struktur, Funktion, Verhalten) zu beleuchten. Ich werde einige Modelle
erwähnen die sich in der Praxis als empfehlenswert erwiesen haben und diese kurz
erläutern. Dazu werde ich nicht allzu tief in die einzelnen Modelle eingehen, da sonst
der Umfang der Arbeit zu groß werden würde und ich mich in dieser Arbeit eher auf
die natülichsprachige Dokumentation konzentrieren werde. Für eine detaillierte Be-
schreibung mit zusätzlichen Beispielen finden sich in [Rupp 2009] und [OMG 2007].
Use Cases (Anwendungsfälle) geben einen guten Überblick über die Funktionalitä-
ten eines bestehenden bzw. zukünftigen Systems. Sie setzen sich meist aus Use-
Case-Diagrammen und Use-Case-Spezifikationen zusammen. In den Use-Case-
Diagrammen werden die Funktionalitäten und ihre Beziehungen mit den Akteuren
(Person oder System) dargestellt. Für eine detaillierte Beschreibung für ein Use-
Case kann eine Use-Case-Beschreibung sehr hilfreich sein. Empfehlenswert ist hier
eine Referenzschablone zur Dokumentation von Use Cases zu benutzten. ([Rupp et
al] S.78 ff.])
Zur Modellierung von Anforderungen in der Strukturperspektive eignen sich vor allem
die UML-Klassendiagramme da sie durch ihre vielfältigen Modellelemente eine gro-
ße Beschreibungsmächtigkeit besitzt. Es stellt die verschiedenen Klassen deren
Schnittstellen und ihre Beziehungen(Assoziationen) eines Systems dar. Zusätzlich
beinhaltet es Modellelemente um Operationen auf den Objekten der einzelnen Klas-
sen zu präzisieren. Einen vollständigen Überblick der Modellelemente finden sich in
erwähnten Literaturen wieder.
Als Modellierung in der Funktionsperspektive sind vermehrt die UML-
Aktivitätsdiagramme vorzufinden. Diese Art der Modellierung eignet sich besonders
gut um Abläufe und deren Regeln eines Systems in detaillierter Form darzustellen.
Großer Vorteil ist dass diese Diagramme leicht erlernbar sind solange sie nicht allzu
in die Tiefe gehen.
Für die Anforderungsmodellierung in der Verhaltensperspektive haben sich die UML-
Zustandsdiagramme als sehr geeignet erwiesen. Der Fokus dieser Modellierung
liegt in den Zuständen(Situation bzw. Zeitraum) und Ereignissen die zu Zustandsän-
20
derungen (Verhaltensänderungen) führen. Vorteil der Zustandsdiagramme ist dass er
durch seine vielen Detailebenen von verschiedenen Stakeholdern genutzt werden
kann. Auch hier verweise ich für detailreichere Informationen auf die Literaturen
[Rupp 2009] und [OMG 2007].
2.4.3 Prüfung von Anforderungen und Konfliktmanagement
Um den Qualitätskriterien für die Dokumentation (s. Kapitel 2.4.2.1) zu entsprechen
müssen einzelne Anforderungen das Anforderungsdokument einer Prüfung unterzo-
gen werden. Hierzu werde ich kurz die Qualitätsaspekte Inhalt, Dokumentation und
Abgestimmtheit kurz erläutern und einige Techniken zur Prüfung von Anforderungen
darstellen. Zudem müssen Konflikte zwischen Stakeholdern identifiziert, analysiert
und aufgelöst werden. Dies geschieht im kontinuierlichen Prozess genannt als "Ab-
stimmung von Anforderungen".
2.4.3.1 Prüfung von Anforderungen
Qualitätsaspekte für Anforderungen
Laut [Rupp et al. 2011] sollten Anforderungen auf die Qualitätsaspekte Inhalt, Doku-
mentation und Abgestimmtheit überprüft werden, die ich im einzeln kurz erläutern
werde.
Der Qualitätsaspekt Inhalt stellt sicher dass die ermittelten und dokumentierten An-
forderungen den Qualitätskriterien für das Anforderungsdokument und für einzelne
Anforderungen (s. Kapitel 2.4.2.1) genügen. In folgender Tabelle sind acht Prüfkrite-
rien um den Qualitätsaspekt Inhalt sicherzustellen.
Der Qualitätsaspekt Dokumentation dient der Überprüfung von Anforderungen und
Anforderungsdokumenten hinsichtlich der Dokumentationsvorschriften wie z.B. Ver-
ständlichkeit der verwendeten Dokumentationsformate. Die Nichteinhaltung kann zu
21
Unverständlichkeit, Unvollständigkeit oder gar zum Übersehen von Anforderungen
führen. Zusätzlich kann es zu einer Behinderung von Entwicklungsaktivitäten beitra-
gen, wenn diese auf ein bestimmtes Dokumentationsformat aufbauen. In folgender
Tabelle sind fünf Prüfkriterien um den Qualitätsaspekt Dokumentation sicherzustel-
len.
Der Qualitätsaspekt Abgestimmtheit soll sicherstellen dass alle Anforderungen zwi-
schen den Stakeholdern abgestimmt sind. Stakeholder erlangen in der Requirements
Engineering Phase neues Wissen über das System und die kann zur Folge haben,
dass sich die Meinung zu einer Anforderung ändert. Unten sind drei Prüfkriterien für
den Qualitätsaspekt Abgestimmtheit.
Detaillierte Fragen die man bezüglich der Qualitätsaspekte berücksichtigen sollten
finden sich in ([Rupp et al. 2011], S. 103 ff.) wieder.
Techniken zur Prüfung von Anforderungen
Meist werden als Prüftechniken die Reviews eingesetzt. Laut [Rupp et al. 2011] wird
unter den Reviews folgende drei Techniken eingeschlossen: Die Stellungnahme, die
Inspektion und das Walkthrough. Nach [Rupp et al. 2011] empfiehlt es sich zusätzlich
folgende Techniken einzusetzen: Das perspektivbasierte Lesen, die Prüfung durch
Prototypen und dem unterstützendem Einsatz von Checklisten. Folgend werde ich
die einzelnen Techniken in komprimierter Form erläutern. Eine sehr ausführliche Be-
schreibung findet sich in ([Rupp 2009] S.293 ff.) wieder.
Bei der Stellungnahme reicht der Autor seine Anforderungen an eine weitere Person
weiter um diese auf vorgegebene Qualitätskriterien kontrollieren zu lassen. Anschlie-
ßend wird der Autor über identifizierte Mängel aufgeklärt.
Die Inspektion ist eine verläuft nach einem eher striktem Schema und bedarf daher
den größten Zeitaufwand bei den Reviewtechniken. Sie ist in die Phasen Planung,
Übersicht, Fehlersuche, Fehlersammlung und -konsolidierung unterteilt. In der Pla-
nungsphase werden u.a. Ziel und Durchführung der Inspektion festgesetzt. Zusätz-
lich werden hier die Rollen Organisator, einen neutralen Moderator, Autor, Inspekto-
ren und Protokollant besetzt. In der Übersichtsphase erläutert der Autor die Anfor-
derungen um ein gemeinsames Verständnis zu erlangen. In der Phase Fehlersuche
22
werden durch die Inspektoren mögliche Fehler in den Anforderungen im Team bzw.
individuell aufgedeckt. In der Phase Fehlersammlung werden die identifizierten Feh-
ler gesammelt, konsolidiert (doppelte Fehler oder falsch angenommene Fehler identi-
fiziert), und dokumentiert. Es entsteht letztlich eine Fehlerliste mit Korrekturmaßnah-
men.
Das Walkthrough ist eher ein leichtgewichtiges Review und verläuft weniger strikt
als bei der Inspektion. Es wird in einem kleineren Maß zwischen den Rollen unter-
schieden. Hierzu werden die Rollen Reviewer, Autor und Protokollant meist besetzt.
Beim Walkthrough werden in einer Gruppensitzung identifizierte Qualitätsmängel dis-
kutiert und durch den Protokollanten festgehalten.
Beim Perspektivbasiertes Lesen werden die Anforderungen aus verschiedenen
Perspektiven(Blickwinkel) aus geprüft. Mögliche Perspektiven wären z.B. Kunde bzw.
Nutzer, Softwarearchitekt oder auch Tester. Es können zusätzlich weitere Perspekti-
ven anhand des individuellen Kontexts des Entwicklungsprojekts ergeben. Auch die
Qualitätsaspekte Inhalt, Dokumentation und Abgestimmtheit die im Kapitel 2.4.3.1
dargestellt wurden, können als Perspektive dienen. Evtl. sollten detaillierte Anwei-
sungen für die Durchführung der Prüfung definiert werden (z.B. mit Checklisten)
wenn Prüfer mit einem bestmimten Blickwinkel nicht so wirklich vertraut sind.
Die Prüfung durch Prototypen ist eine effektive Methode um Fehler bzw. Abwei-
chungen zwischen den Vorstellungen der Stakeholder und dem zukünftigen System
zu identifizieren. Hierzu sollte man sich anfangs zwischen einem Wegwerfproto-
typ(wird nicht mehr weiterentwickelt) oder einem evolutionärem Prototyp(wird spä-
ter weiterentwickelt und bedarf daher einen größeren Realisierungsaufwand) ent-
schieden werden. Um eine erfolgreiche Prüfung anhand eines Protottypen zu garan-
tieren sollten für die Prüfer die folgenden Vorbereitungen getroffen werden: Hand-
buch(Information über Bedienung des Prototyps), Prüfszenarien(Nutzungsabläufe)
und Checklisten mit Prüfkriterien(Kriterien anhand derer die Prüfer den Prototypen
überprüfen können).
Der Einsatz von Checklisten kann in jeglicher Art von Prüfung zusätzlich eingesetzt
werden. Hierzu sollten als Quellen u. a. dienen: die drei Qualitätsaspekte, Qualitäts-
kriterien für Anforderungen und Anforderungsdokument sowie die Erfahrung der Prü-
fer aus vergangenen Projekten. Checklisten sollten stetig einer Verbesse-
23
rung(Mehrdeutigkeit, etc.) unterzogen werden und sollte als Leitfaden während einer
Prüfung(also dem Review) dienen.
2.4.3.2 Konfliktmanagement
Im Requirements Engineering kommt es immer wieder zu Konflikten zwischen Anfor-
derungen. Deshalb sollte der Requirements Engineer durchgehend darauf achten
diese frühzeitig zu erkennen. Zur Abstimmung von Anforderungen an ein zu entwi-
ckelndes System ist es daher erforderlich, Konflikte zwischen Stakeholdern zu iden-
tifizieren, zu analysieren und geeignet aufzulösen. Hierzu werde ich die Phasen Kon-
fliktanalyse, Konfliktauflösung des Konfliktmanagement erläutern. Damit die Auf-
lösung von Konflikten nachvollziehbar wird, ist eine Dokumentation der Konfliktlö-
sung unvermeidbar.
In der Konfliktanalyse wird die Ursache eines Konfliktes identifiziert. Die folgende
Tabelle stellt die verschiedenen Konflikttypen mit einer kurzen Beschreibung dar (in
Anlehnung an [Moore 2003]).
Konflikttyp Beschreibung / Erläuterung
Sach-konflikt
Mangel an Information, durch Fehlinformation oder unterschiedliche Interpre-
tation einer Information.
Beispiel: "Das System soll höchstens eine Sekunde betragen." → Ansicht von
Stakeholder 1: "zu langsam" | Ansicht von Stakeholder 2: "nicht realisierbar")
Interessen-
konflikt
Verschiedene subjektive oder objektive Interessen der Stakeholder.
Beispiel: Stakeholder 1 strebt geringe Kosten an | Stakeholder 2 strebt eine
hohe Qualität an. Der Interessenkonflikt besteht darin, wenn der erste Stake-
holder die Anforderung aus Kostengründen ablehnt, der zweite Stakeholder
die Anforderung aus Qualitätsgründen umsetzten möchte.
Werte-
konflikt
Verschiedene Kriterien (z.B. kulturelle Unterschiede, persönliche Ideale)
Beispiel: Stakeholder 1 bevorzugt Open-Source-Technologie | Stakeholder 2
bevorzugt Closes-Source-Technologie
Beziehungs-
konflikt
Ist durch starke Emotionen, schlechte Kommunikation oder negatives zwi-
schenmenschliches Verhalten der Stakeholder untereinander charakterisiert.
Beispiel: Zwei gleichrangige Stakeholder lehnen gegenseitig ihre Anforderun-
24
gen ab um sich durch Einbringen ihrer Anforderung in einem Projekt auszu-
zeichnen.
Struktur-
konflikt
Kann bei ungleichen Macht- und Autoritätsverhältnissen auftreten.
Beispiel: Ein Vorgesetzter lehnt prinzipiell Anforderungen von einem bestimm-
ten Mitarbeiter ab, da er ihm die Fähigkeit zur Definition von Anforderungen
abspricht.
Tabelle 1: Konfliktarten
In der Praxis können häufig die auftretenden Konflikte nicht direkt einem bestimmten
Typ zugeordnet werden. Um geeignete Auflösungsstrategien anzuwenden, sollte
man aber die Konflikte auf die oben erwähnten Typen hin untersuchen. [Rupp et al.
2011]
In der Konfliktauflösung werden versucht die identifizierten Konflikte geeignet auf-
zulösen. Eine gute Konfliktauflösung kann viel zu einer positiven Kooperationsbereit-
schaft zum geplanten System der Stakeholder beitragen. Zudem ist es sehr wichtig
und notwendig alle Stakeholder die in einem Konflikt beteiligt sind bei der Konfliktlö-
sung mit einzubeziehen um die Meinung und Standpunkte aller Stakeholder mit ein-
zubeziehen.
Eine Auswahl an verschiedenen Konfliktauflösungsmethoden werde ich in der fol-
genden Tabelle kurz erläutern:
Methode Beschreibung / Erläuterung
Einigung /
Kompromiss
Die Konfliktpartner diskutieren über ihre jeweiligen Informationen, Argu-
mente und Meinungen. Anschließend einigen sich die Stakeholder auf
eine Lösungsalternative. Die Lösungsalternative kann entweder aus ei-
ner Kombination verschiedener Lösungsalternativen sowohl auch einer
völlig neu entwickelte Konfliktauflösung sein.
Abstimmung
Es werden verschiedene Lösungsalternativen vorgestellt und die Stake-
holder haben die Möglichkeit eine Stimme abzugeben. Die am meisten
abgestimmte Alternative wird als Konfliktlösung festgelegt.
Varianten- Durch eine Variantenauswahl oder Parametrierung(also die Eingabe von
25
bildung Variablen bzw. Übergabewerte) werden verschiedene Systemvarianten
realisiert um somit den verschieden Wünschen der Stakeholder zu ent-
sprechen.
Consider-all-
Facts (CAF)
Es werden wenn möglich alle Einflussfaktoren des Konflikts analysiert
um viele Informationen über den Konflikt zu erhalten. Durch Priorisierung
wird die Wichtigkeit der Einflussfaktoren festgelegt. Als Bewertung kann
anschließend die Plus-Minus-Interesting (PMI) Methode dienen.
Plus-Minus-
Interesting (PMI)
Es werden die drei Kategorien Plus(positiv), Minus(negativ) und
Interesting(weder noch) zur Bewertung der Auswirkungen der Lösungs-
alternativen erstellt. Die Lösungsalternativen in der Kategorie Interesting
sollten weiter analysiert werden um eine genauere Bewertung erheben
zu können.
Ober-sticht-
Unter
Die Konfliktpartei mit dem höheren organisatorischen Rang gewinnt den
Konflikt. Bei gleichrangigen wird die Entscheidung einer übergeordneten
(z.B. Vorgesetzten) überlassen. Die Ober-sticht-Unter Methode sollte
eher angewendet werden wenn andere Lösungstechniken nicht erfolg-
reich waren.
Tabelle 2: Konfliktauflösungsmethoden
Dokumentation der Konfliktlösung
Da mit Sicherheit Konflikte im Requirements Engineering behandelt und geeignet
aufgelöst werden, sollte man darauf achten diese so gut wie möglich zu dokumentie-
ren um diese nachvollziehbar zu machen. Mögliche Gefahr könnte z.B. die Wieder-
holte Behandlung von Konflikten ausmachen. Als weiteren Punkt kann durch eine
gute Dokumentation die Überprüfung von Konfliktauflösungen (z.B. wenn man im
späteren Verlauf herausstellt, dass eine ungeeignete Konfliktlösung gewählt wurde)
nachzuvollziehen.
26
2.4.4 Requirements Management
Definition laut IREB [Rupp et al. 2011] für Requirements Management:
Das Requirements Management umfasst alle Maßnahmen, die notwendig sind, um
Anforderungen zu strukturieren, für verschiedene Rollen aufzubereiten sowie konsis-
tent zu ändern und umzusetzen.
Das Requirements Management beschäftigt sich damit, die dokumentierten Anforde-
rungen als auch die damit verbundenen Informationen über den gesamten Lebens-
zyklus des Systems bereitzustellen und angebracht zu strukturieren. Die mit dem
Requirements Management verbundenen Aktivitäten bzw. Aufgaben – Sichten auf
Anforderungen, Attributierung, Priorisierung, Verfolgbarkeit, Versionierung und Ände-
rungsmanagement von Anforderungen – werde ich im Folgenden erläutern.
Sichten auf Anforderungen
Um die Übersicht über die Menge an Anforderungen zu behalten, ist es unerlässlich
einen selektiven Zugriff und somit das Filtern von Anforderungen in Abhängigkeit
von der Verwendung vorzunehmen. Es sollten somit verschiedene Sichten für ver-
schiedene Rollen (Softwarearchitekt, Programmierer, Projektmanager, Tester) zur
Verfügung stehen, da z.B. einerseits der Projektmanager die Aufwände für die Um-
setzung der Anforderungen und andererseits der Requirements Engineer die Anzahl
der Anforderungen die noch nicht formuliert sind einsehen. Eine bestimmte Sicht auf
Anforderungen kann aber auch für verschiedene Rollen verwendet werden (vgl.
[Rupp et al. 2011], S. 129 ff.).
Attributierung von Anforderungen
Um die relevanten Informationen(Attribute – bestehend aus Attributtyp und Attribut-
wert) für eine Anforderung festzuhalten, hat es sich in der Praxis bewährt eine Art
schablonenbasierte Attributierung zu benutzen. Diese Schablone kann man als eine
Tabelle betrachten in dem diese Informationen gesammelt werden. Wichtige Informa-
27
tionen über eine Anforderung wären beispielsweise der eindeutige Identifikator, der
Name, die Beschreibung, Autor und weitere Verantwortliche der Anforderung.
Attributname Belegung des Attributs
Anforderungsnummer (ID) z.B. Anf-123
Anforderungsname z.B. Zusätzliche Bestätigung beim speichern
Beschreibung z.B. Das System sollte dem Benutzer beim Speichern
zusätzlich ein Bestätigungsfenster anzeigen.
Tabelle 3: Beispiel für eine Attributierung
Die Menge aller Attribute bezeichnet man als Attributschema. Dieses Attributschema
kann sich unter Berücksichtigung folgender Aspekte unterscheiden (vgl. [Rupp et al.
2011], S.126):
Spezifische Merkmale eines Projekts z.B. Projektgröße, lokale bzw. verteilte
Entwicklung oder Projektrisiko
Vorgaben seitens des Unternehmens, z.B. Unternehmensstandards und
-vorschriften
Eigenschaften und Vorschriften des Anwendungsgebiets, z.B. Referenzmodel-
le, Modellierungsvorschriften, Standards
Randbedingungen und Restriktionen des Entwicklungsprozesses, z.B. Haf-
tungsrecht und Prozessstandards
Ein angepasstes Attributschema werde ich in Kapitel 3.2 darstellen und erläutern.
Der große Vorteil der schablonenbasierten Weise der Informationsdarstellung ist der,
dass der Leser der Anforderung (z. Auftraggeber, Entwickler, etc.) gleichartige Infor-
mationen am gleichen Ort wieder findet. Speziell für den Requirements Engineer bie-
tet die schablonenbasierte Anforderungsattributierung darüber hinaus den Vorteil,
dass er wichtige Informationen nur schwer übersehen kann und dass diese Informa-
tionen, unterstützt durch die Schablonenstruktur und die vorgegebenen Attributwert-
bereiche, in der Regel auch zweckmäßig und richtig dokumentiert werden (vgl. [Rupp
et al. 2011], S.126).
28
Priorisierung von Anforderungen
Anforderungen im Requirements Engineering werden in der Regel einem
Priorisierungsprozess unterzogen. Eine Anforderung kann durch einen oder durch
mehrere Attributtypen (z.B. Priorität des Auftraggebers, Priorität hinsichtlich der
Dringlichkeit der Umsetzung) festgelegt werden. Typische Priorisierungskriterien
sind: Kosten, Risiko, Schaden bei nicht erfolgreicher Umsetzung, Volatilität, Wichtig-
keit und Zeitdauer für die Umsetzung (vgl. [Rupp et al. 2011], S. 132).
Verfolgbarkeit und Versionierung von Anforderungen
„Die Verfolgbarkeit(Traceability) einer Anforderung ist die Fähigkeit, eine Anforde-
rung über den gesamten Lebenszyklus des Systems hinweg nachvollziehen zu kön-
nen“ ([Rupp et al. 2011], S. 136). Um eine Anforderung im Nachhinein zurückverfol-
gen zu können, muss eine Verfolgbarkeit sichergestellt werden um eine gewisse
Transparenz über die Historie einer Anforderung zu ermöglichen. Historie ist ein Pro-
tokoll, das immer erweitert wird welche Person an welchem Datum zu welcher Uhr-
zeit, gleichgültig ob das Ausbessern eines Rechtschreibfehlers, eine fachliche inhalt-
lich Änderung oder ein Zustandsübergang.
Um die Verfolgbarkeit erleichtern zu machen sollte man eine Versionierung der An-
forderung vornehmen. Die neue Version einer Anforderung sollte mit der alten ver-
knüpft sein. Der Vorgang einer Versionierung ist in detaillierter Form in ([Rupp 2009],
S. 400 ff.). wiederzufinden.
Änderungsmanagement von Anforderungen
Über den gesamten Entwicklungs- und Lebenszyklus eines Systems können sich
Anforderungen verändern. Zum Beispiel können neue Anforderungen hinzukommen
oder bestehende Anforderungen geändert oder entfernt werden. Ursachen für Anfor-
derungsänderungen sind sehr vielseitig z.B. ein Nutzungswandel der Stakeholder,
Gesetzesänderungen oder zusätzliche Konkurrenz am Markt. Anforderungsänderun-
gen sind für sich nichts Negatives da es der Indikator ist, dass sich die Stakeholder
mit dem System mehr auseinandergesetzt haben. (vgl. [Rupp et al. 2011], S. 146)
29
Für die Bearbeitung der Änderungsanträge ist typischerweise das Change-Control-
Board (CCB) zuständig. Das CCB entscheidet über die Annahme bzw. die Ableh-
nung von Änderungsanträgen. Es priorisiert die Änderungsanträge und schätzt die
Auswirkungen der Änderung auf alle Entwicklungsartefakte sowie die zur Umsetzung
der Änderung benötigten Ressourcen ein. Das prinzipielle Vorgehen bei Änderungen
mit den genauen Änderungsinformationen finden sich in ([Rupp et al. 2011], S. 147
ff.) wieder.
30
3 Requirements Engineering: Herleitung eines
Soll Prozesses
Innerhalb dieses Kapitels wird eine Begründung des hergeleiteten Soll-Prozesses im
Bereich des Requirements Engineering beleuchtet.
Zunächst werden Eingrenzungen, die bezüglich des Requirements Engineering ent-
standen sind, erwähnt. Anschließend folgt die Veranschaulichung der angepassten
Attributliste einschließlich einer kurzen Erläuterung der Attribute.
Im Anschluss daran wird das Gesamtbild des RE-Soll-Prozesses dargestellt, inner-
halb der weiteren Kapitel findet eine genauere Betrachtung der einzelnen Phasen
des Prozesses statt. Abschließend erfolgt eine Reflexion des Prozesses.
3.1 Rahmenbedingungen und Abgrenzungen
In Kapitel 2 wurde ausführlich das Requirements Engineering eruiert und unter Zuhil-
fenahme aktueller Literatur fundiert belegt. Innerhalb dieses Kapitels sollen Rahmen-
bedingungen und Einschränkungen bezüglich des hergeleiteten RE-Soll-Prozesses
dargestellt und begründet werden.
Der Soll-Prozess des Requirements Engineering im Rahmen dieser Diplomarbeit
wird sich, beginnend mit der Definition von Anforderungen über Qualitätsprüfungen
und Konfliktmanagement bis hin zur Entscheidung eines Verantwortlichen innerhalb
eines entsprechenden Anforderungsprofils zuspitzen.
In der Theorie befasst sich das Requirements Engineering vollständig mit der Ermitt-
lung von Anforderungen (s. Kapitel 2.4.1) mit Zuhilfenahme entsprechender erforder-
licher Ermittlungstechniken bis zur schlussendlichen kompletten Anforderungsspezi-
fikation.
Im Rahmen dieser Diplomarbeit wird es sich um Sachverhalte handeln, die eine Än-
derung bzw. Anpassung in einem bestehenden SAP-System darstellen sollen.
31
Hierzu können in einer grafischen Benutzeroberfläche (GUI) einzelne Schwerpunkte
eingetragen werden. Die erwähnten und erläuterten Ermittlungstechniken im Requi-
rements Engineering (s. Kapitel 2.4.1.2) können im Vorfeld natürlich angewendet
werden, um Anforderungen zu erheben, wobei aber weiterhin kein gesonderter Fo-
kus darauf gesetzt wird.
Zur Dokumentation der Anforderungen wird ausschließlich die natürliche Sprache
benutzt. Hierzu sollten aber, wie in Kapitel 2.4.2.3 erwähnt, Satzschablonen als Un-
terstützung bzw. Hilfestellung für die Formulierung einer Anforderung dienen. Ent-
sprechend positive Beispiele werden in Kapitel 3.3.2 dargelegt.
Es ist die Aufgabe des Requirements Engineer, welche Techniken er für die Auflö-
sung eines Konfliktes einsetzt, ein detaillierter Prozessdurchlauf ist daher für die
Phase des Konfliktmanagements nicht vorgesehen.
3.2 Daten (Attributliste)
Wie in Kapitel 2.4.4 schon erwähnt, ist es laut [Rupp et al. 2011] empfehlenswert,
eine schablonenbasierte Attributierung der Anforderungen einzusetzen. Im Folgen-
den wird eine zusammengestellte Attributliste aufgeführt, um die wichtigsten Daten in
punkto Anforderungen zu sammeln. Die Liste basiert auf ([Rupp et al. 2011], S. 126
ff.) und ([Ebert 2012], S. 110 ff.).
Attributname Bedeutung
Anforderungsnummer (ID) Die eindeutige Identifikation einer Anforderung, die in allen Pro-
jekten eingehalten wird.
Anforderungsname (Bezeich-
nung) Eindeutiger, charakterisierender Name der Anforderung.
Beschreibung Beschreibt den Inhalt der Anforderung.
Quelle
Ursprung der Anforderung. Sollte in der Lage sein, die Anforde-
rung konkret zu beschreiben und ein Budget zur Realisierung zur
Verfügung stellen.
Autor Erfasser dieser Anforderung, der später als Ansprechpartner zur
Verfügung steht, wenn weitere Informationen nötig sind.
Juristische Verbindlichkeit /
Wichtigkeit
Benennt die juristische Verbindlichkeit für die Anforderung bzw.
die Wichtigkeit [muss (verpflichtend), sollte (wünschenswert), wird
(in Zukunft integriert).
Anforderungstyp Benennt abhängig vom eingesetzten Differenzierungsschema
32
den Typ der Anforderung (funktionale Anforderung, Qualitätsan-
forderung, Rahmenbedingung).
Release Benennt das Release, in dem die Anforderung umgesetzt werden
soll.
Priorität
Benennt die Priorität der Anforderung hinsichtlich der gewählten
Merkmale zur Priorisierung, z. B. Bedeutung für die Akzeptanz
am Markt, Reihenfolge der Umsetzung, Schaden bzw. Opportuni-
tätskosten durch Nichtrealisierung.
Abhängigkeiten / Querbezüge
Benennt Beziehungen zu anderen Anforderungen. Zum Beispiel,
wenn bekannt ist, dass eine Realisierung dieser Anforderung die
vorherige Realisierung einer anderen Anforderung voraussetzt.
Vorbedingung(en)
Benennt evtl. Vorbedingung(en) die für diese Anforderung nötig
sind.
Erstelldatum Das Erstelldatum der Anforderung.
Versionsnummer Aktueller Versionsstand der Anforderung.
Stabilität
Stabilität in dem Sinne, ob diese Anforderung künftig evtl. Verän-
derungen ausgesetzt ist (mögliche Unterscheidung: fest, gefes-
tigt, schwankend).
Historie Stellt die Historie (also die verschiedenen Änderungen) dar.
Status der Überprüfung Benennt den aktuellen Status der Validierung, z. B. ungeprüft, in
Prüfung, überprüft, fehlerhaft, in Korrektur.
Status der Einigung Benennt den aktuellen Status der Abstimmung (z. B. nicht abge-
stimmt, abgestimmt, konfliktär).
Aufwand Tatsächlicher Umsetzungsaufwand der Anforderung.
Kosten Benennt die Realisierungskosten der Anforderung.
Zusätzliche Information
In diesem Attribut können beliebige, für relevant erachtete Infor-
mationen, zu dieser Anforderung dokumentiert werden.
Zum Beispiel, wenn die Abstimmung dieser Anforderung auf dem
nächsten Treffen mit einem Auftraggeber vorgesehen ist.
System oder Geschäftsprozess Benennt das System oder den Geschäftsprozess, indem die An-
forderung hauptsächlich umgesetzt werden soll.
Fertigstellungstermin (Realisie-
rungsdatum) Benennt den gewünschten Fertigstellungstermin.
Projektleiter Benennt den Projektleiter des des Aufgabenbereichs, in dem die
Anforderung zukünftig umgesetzt werden soll.
Requirements Engineer
Benennt den Requirements Engineer bzw. das RE-Team, der/das
für diese Anforderung zuständig ist bzw. war.
In Konflikt stehende Anforde- Soll Anforderungen benennen, die mit der aktuellen Anforderun-
33
rung(en) gen in Konflikt stehen.
Grund der Ablehnung / Zu-
rückstellung
Dokumentiert den Grund in Bezug auf eine Entscheidung über die
Anforderung im Falle einer Ablehnung oder Zurückstellung.
Tabelle 4: Attributliste
34
3.2.1 Gesamtbild des RE-Soll-Prozesses
Phase: Aufwandsschätzung und
Bewertung
Phase: Freigabe
Pflichtattribute nach Vorgaben ausfüllen
Anforderung stellenAnforderer / Stakeholder
Alles nötige komplett und
korrekt?
Requirements Engineer
(Team; Org. Einheit)
Neue Begrifflichkeiten?
Ja
Glossar aktualisieren
Ja
Grobe Aufwand- und
Kostenschätzung (PERT-Schätzung) / Priorität festlegen
Nein
Gibt es Konflikte?
Entwickler / Projektleiter
Ja
Konfliktlösung durch Anforderer
von dem in Konfliktstehenden +
Projektleiter
Verantwortlichen (Je nach
Kostenhöhe) befragen
Nein
Entscheidung über Anforderung
Anforderung ablehnen
Anforderung zurückstellen
Anforderung freigeben
Grund dokumentieren und
Anforderer mitteilen
Grund dokumentieren und
Anforderer mitteilen
Konflikt dokumentieren
Die im Konflikt stehenden
Anforderungen anpassen
Requirements Engineer
(Team; Org. Einheit)
Phase: Qualitätsprüfung
Prüfung 2: Abstimmung / Konfliktmanagement
Phase: Aufnahme
Konflikt gelöst
Nein; zurück an Anforderermit Begründung
Abbildung 7: Gesamtbild des RE-Soll Prozesses
35
Die obige Abbildung 7 stellt den Prozess als Ganzes dar. Die einzelnen Phasen wer-
den in den folgenden Kapiteln näher dargestellt und begründet. Hierzu soll der Bezug
zur Literatur veranschaulicht werden und verdeutlicht werden, um näher zu eruieren,
welche Personen bzw. Rollen in den einzelnen Phasen agieren.
1. Phase: Aufnahme
Aufnahme der Anforderung mit den zugehörigen Attributen.
2. Phase: Qualitätsprüfung
Die Anforderung auf die Qualitätskriterien hin überprüfen.
3. Phase: Abstimmung / Konfliktmanagement
Hier werden eventuelle Konflikte aufgedeckt und aufgelöst bzw. abgestimmt.
4. Phase: Aufwandsschätzung / Bewertung
In dieser Phase erfolgt eine Kosten- und Aufwandsschätzung. Zusätzlich sollte
spätestens hier eine Priorität feststehen.
5. Phase: Freigabe
In dieser Phase erfolgt ein entsprechender Genehmigungsschritt über die An-
forderung.
36
3.3 Phasen
3.3.1 Aufnahme
Abbildung 8: Phase: Aufnahme
Als Ausgangspunkt ist eine Anforderung nötig, um einen Anforderungsprozess aus-
zulösen. Diese Voraussetzung kann in Form einer wünschenswerten Funktion aus-
gedrückt werden, aber auch eine Änderung in einem bestehenden System beinhal-
ten. Im SAP-Bereich handelt es sich meist um eine Änderung bzw. Anpassung in
einem bestehenden System.
Diese Anforderung wird von einem berechtigten Anforderer (Stakeholder) aufgege-
ben, der anhand einer „Tabelle“ bzw. durch Formulareingaben innerhalb einer grafi-
schen Benutzeroberfläche (GUI) agiert. Nachfolgend sind Angaben aufgelistet, die zu
belegen wären. Eine Erklärung der Attribute erfolgte innerhalb einer Attributtabelle in
Kapitel 3.2. Folgend wird kenntlich gemacht (durch Unterstreichung), welche Attribute
automatisch vervollständigt werden:
<Anforderungsnummer (ID)>, <Anforderungsname>, <Beschreibung>, <Quelle>,
<Autor>, <Juristische Verbindlichkeit / Wichtigkeit>, <Anforderungstyp>, <Release>,
<Erstelldatum>, <Versionsnummer>, <Historie>,
Folgende Attribute könnten sowohl in der derzeitigen als auch in weiteren Phasen
des RE-Soll-Prozess besetzt bzw. geändert werden:
<Priorität>, <Abhängigkeiten / Querbezüge>, <Vorbedingung(en)>, <Zusätzliche In-
formation>, <System oder Geschäftsprozess>, <Fertigstellungstermin>, <Stabilität>
37
Da die Problematik und der Kern in der Beschreibung der Anforderung liegen, sollte
diese mithilfe einer Schablone (Template) erstellt werden, wie im Kapitel 2.4.2.3 er-
läutert. Hierdrauf wird am Schluss dieses Kapitels näher eingegangen und sowohl
positive als auch negative Beispiele gegenübergestellt.
In der Aufnahme-Phase kann der Anforderer bereits Vorbedingung(en) oder Abhän-
gigkeiten angeben, wenn ihm diese bekannt sind.
Eine Vorbedingung setzt andere Kriterien voraus als eine Voraussetzung, die vor-
gegeben werden muss, damit die Ausführung einer Funktion ein definiertes Ergebnis
erbringt (z. B. „um diese Funktion umsetzen zu können, muss das Enhanced
Package 5.0 installiert sein“). Besteht eine Vorbedingung, sollte diese demnach in
die Anforderung eingetragen und dokumentiert werden. Unterstützend wirken würden
eine Zeitschiene, in der vermerkt ist, zu welchem Zeitpunkt diese Vorbedingung zu
erfüllen ist.
Besteht eine Abhängigkeit (eine andere Anforderung muss zuerst realisiert werden,
um die neue Anforderung umsetzen zu können) sollte diese ebenso vermerkt und
dokumentiert werden. Eine optimale Lösung bestände darin, einen Verweis (Hyper-
link) auf die in Abhängigkeit stehende Anforderung zu setzen. Auch an dieser Stelle
wäre eine Zeitschiene zu empfehlen, um die Reihenfolge für eine Umsetzung der
Anforderungen übersichtlich zu erfassen.
Beschreibungsvorgaben
Wie in Kapitel 2.4.2.3 schon dargestellt, wird mit dem Ansatz der Anforderungs-
schablonen eine schnelle und einfache Erzeugung qualitativ hochwertiger Anforde-
rungen verfolgt. Der Ansatz dieser Vorgehensweise beruht darauf, die Syntax der
natürlichen Sprache etwas zu beschränken, aber trotzdem gleichzeitig ausdrucks-
stark zu sein. Der Vorteil von Anforderungsschablonen soll daher auch innerhalb des
RE-Soll-Prozesses in einer Umsetzung Beachtung finden. Folgend werden Beispiele
für „gute Anforderungen“, die mithilfe der Anforderungsschablonen erstellt wurden (s.
Abbildung 5 und Abbildung 6 im Kapitel 2.4.2.3), dargelegt.
38
Beispiele ohne Bedingung:
Selbstständige Systemaktivität (verpflichtend):
Das System muss die Kundendaten permanent speichern.
Benutzerinteraktion (verpflichtend):
Das System muss dem Kunden die Möglichkeit bieten, sich über Seminare
und Veranstaltungen zu informieren.
Benutzerinteraktion (wünschenswert):
Das System soll dem Seminarsachbearbeiter die Möglichkeit bieten, Semi-
nare und Veranstaltungen mit selbst erstellten Suchanfragen auszuwerten.
Schnittstellenanforderung (wünschenswert):
Das System muss fähig sein, dem Buchhaltungssystem Rechnungsdaten-
sätze mindestens einmal am Tag zur Verfügung zu stellen.
Beispiele mit Bedingungen:
Selbstständige Systemaktivität (verpflichtend):
Falls ein Kunde im Zahlungsverzug ist, muss das System eine neue Buchung
nicht erlauben.
Benutzerinteraktion (wünschenswert):
Falls ein Kunde seit mehr als einem Jahr keine Bestellung mehr aufgegeben
hat, soll das System jedem Administrator die Möglichkeit bieten, diesen
Kunden zu löschen.
Schnittstellenanforderung (verpflichtend):
Sobald ein Administrator innerhalb der Kundenverwaltung einen Kunden
auswählt, muss das System fähig sein, ihm den Namen des Kunden, seine
Adresse und die letzten drei Bestellungen anzuzeigen.
39
3.3.2 Qualitätsprüfung
Abbildung 9: Phase: Qualitätsprüfung
Anschließend wird die Anforderung bzw. die ausgefüllte Attributtabelle gesichert und
an den Requirements Engineer (Anforderungsmanager) weitergegeben, der den Sta-
tus als aktueller Bearbeiter erhält. Dieser manifestiert sich häufig in einem Team bzw.
als eine organisatorische Einheit, die für Anforderungen bzw. für Anforderungsprü-
fungen zuständig ist. Im Folgenden werde ich mich aber im weiteren Verlauf der Ar-
beit auf den Begriff „Requirements Engineer“ festlegen. Nachdem eine entsprechen-
de Anforderung somit dem Requirements Engineer vorgelegt wird, soll diese auf
Vollständigkeit und Richtigkeit der Attributfelder kontrolliert werden. Die Überprüfung
der Felder, hauptsächlich die Beschreibung, sollte nach Qualitätskriterien hin unter-
sucht werden (wie in Kapitel 2.4.3.1 beschrieben). Bei bestehenden Fehlern inner-
halb der Anforderung, wird diese wieder an den Anforderer mit einer Beschreibung
der Ungenauigkeiten (z. B. als E-Mail) zurückgeschickt.
Werden vom Requirements Engineer bereits jetzt Konflikte mit anderen Anforderun-
gen erkannt, sollten diese in dem Attribut <In Konflikt stehende Anforderung(en)>
kenntlich machen, um diese in der anschließenden Phase des Konfliktmanagements
geeignet aufzulösen.
In den Soll-Prozess wird auch die Pflege eines Glossars (Kapitel 2.4.2.2) einfließen.
Bestehen laut dem Requirements Engineer keine Fehler innerhalb der Anforderung
bzw. hat er eine korrigierte Anforderung erhalten, sollte noch überprüft werden, ob
besondere Begrifflichkeiten benutzt worden sind, die in zukünftigen Prozessen evtl.
40
anders zu deuten sind (z. B. Synonyme oder Homonyme). Diese sollten mit einer
eindeutigen Beschreibung in das Glossar aufgenommen werden, um in Zukunft Wi-
dersprüche mit spezifischen Fachbegriffen innerhalb eines Projektes zu vermeiden.
Folgende Attributfelder sind in dieser Phase vom Requirements Engineer auszufül-
len:
<Projektleiter>, <Requirements Engineer>, <Status der Überprüfung>
Folgende Attribute können sowohl in der aktuellen Phase als auch in weiteren Pha-
sen angepasst werden:
<In Konflikt stehende Anforderung(en)>, <Priorität>, <Abhängigkeiten / Querbezü-
ge>, <Vorbedingung(en)>, <Zusätzliche Information>, <System oder Geschäftspro-
zess>, <Fertigstellungstermin>, <Stabilität>
41
3.3.3 Konfliktmanagement
Abbildung 10: Phase - Konfliktmanagement
In der Phase des Konfliktmanagements werden Anforderungen gegenüber dem Re-
quirements Engineer auf Konflikte mit weiteren Voraussetzungen überprüft. Somit
wird in der zweiten Prüfung die Abgestimmtheit verifiziert.
Werden keine Konflikte entdeckt, kann die Anforderung einem Verantwortlichen
bzw. dem Entscheider vorgelegt werden. Dieser Prozessschritt wird im anschließen-
den Unterkapitel erläutert.
Werden Konflikte hinsichtlich dieser Anforderung entdeckt, sollte der Requirements
Engineer sich darum kümmern, diese Unstimmigkeiten geeignet aufzulösen bzw.
mit den betroffenen Stakeholdern abzustimmen. Besteht dadurch ein Konflikt, sollte
ein Vermerk zu der in Ungereimtheit stehenden Anforderung gemacht werden. Die-
ser sollte dokumentiert werden und zu einer Konfliktlösung führen. Hierzu sollte der
Requirements Engineer alle an dieser Anforderung bzw. am Konflikt beteiligten Sta-
42
keholder kontaktieren, um eine Abstimmung zu finden. Verschiedene Konfliktlö-
sungsmethoden wurden im Kapitel 2.4.3.2 vorgestellt und erläutert. Die in Unstim-
migkeit stehenden Anforderungen sollten mithilfe aller Beteiligten erläutert und ange-
passt werden. Dieses kann auch gerne über eine virtuelle Konferenz geschehen.
Nach dieser Phase sollten folgende Attribute besetzt werden:
<Status der Einigung>, <In Konflikt stehende Anforderung(en)>
Folgende Attribute können gegebenfalls angepasst werden:
<Stabilität>, <Abhängigkeiten / Querbezüge>, <Zusätzliche Information>, <Vorbedin-
gung(en)>
43
3.3.4 Aufwandschätzung / Bewertung
Abbildung 11: Phase: Aufwandschätzung / Bewertung
Nachdem eventuelle Konflikte aufgelöst wurden, kann die Anforderung dem Projekt-
leiter oder auch einem vorläufigen Entwickler vorgelegt werden, damit dieser eine
grobe Schätzung (z. B. eine PERT-Schätzung) geben und Angaben zu Kosten und
Aufwand in die Anforderung eintragen kann. Evtl. kann hier nochmals die Priorität
bzgl. der Anforderung angepasst werden. Zudem kann der Projektleiter weitere Ab-
hängigkeiten oder Vorbedingungen angeben, sofern diese bis zum jetzigen Zeitpunkt
noch nicht entdeckt wurden.
Somit wären folgende Attribute zu besetzen:
<Aufwand>, <Kosten>
Anpassungen können in den folgenden Attributen getroffen werden:
<Stabilität>, <Abhängigkeiten / Querbezüge>, <Zusätzliche Information>, <Vorbedin-
gung(en)>, <Priorität>, <Fertigstellungstermin>
44
3.3.5 Freigabeprozess
Nachdem die Anforderung soweit aufbereitet wurde, mögliche Konflikte behandelt
und eine Schätzung abgegeben wurde, kann eine Entscheidung über die Vorge-
hensweise getroffen werden. Je nach Kostenhöhe sollte ein geeigneter Verantwortli-
cher kontaktiert und diesem die Anforderung vorgelegt werden. Zum Beispiel könnte
der Fachbereich eigenhändig eine Entscheidung über die Aufgabenstellung abge-
ben, wenn diese im Rahmen des Budgets liegt. Bei höheren Kosten sollte die Ent-
scheidung von einem Gremium bzw. vom Vorstand getroffen werden.
Eine Anforderung kann demnach abgelehnt, zurückgestellt oder freigegeben werden.
Im Falle einer Ablehnung oder Zurückstellung (wenn es sich zum Beispiel um eine
sinnvolle Anforderung handeln, diese aber zu einem späteren Zeitpunkt eventuell
umgesetzt werden sollte) sollte der Grund dokumentiert werden und dem Anforderer
diese Begründung mitgeteilt werden.
Demnach sollten folgende Attribute vervollständigt werden:
<Zusätzliche Information>, <Priorität>, <Fertigstellungstermin>, <Grund der Ableh-
nung / Zurückstellung>
45
3.4 Bewertung und Reflexion des Prozesses
Der hergeleitete Prozess sollte weitgehend alle in der Theorie beschriebenen Aktivi-
täten beinhalten. Im Unterkapitel wird ein hergeleiteter AM-Prozess der Theorie ge-
genübergestellt.
Aus Kapitel 2.4.1.2 lässt sich erkennen, dass eine große Anzahl an verschiedenen
Methoden existiert, um Anforderungen aufzunehmen. Der hergeleitete Prozess be-
ginnt daher mit der Phase einer Aufnahme, in der gewünschte Anforderungen aufge-
nommen werden.
Wie in Kapitel 2.4.2.1 erwähnt, sollten die Anforderungen bestimmten Qualitätskrite-
rien unterliegen. Daher wird zunächst eine Prüfung der Qualitätskriterien bezüglich
dieser Anforderungen auch im Prozess beachtet, die vom Requirements Engineer
durchgeführt werden sollten. Die Auswahl einer bzw. mehreren Techniken zur Über-
prüfung unterliegt dem Requirements Engineer und wird daher erst in einer „kompri-
mierten" Prüfungsphase deutlich. Zusätzlich wurde auch der Einbezug eines Glos-
sars (wie im Kapitel 2.4.2.2 aus der Theorie empfohlen) Beachtung finden.
Bei Konflikten mit Anforderungen wird eine Phase „Konfliktmanagement“ eingeleitet,
um eine Abstimmung zu vollziehen, wie aus dem Theorie-Kapitel 2.4.3.2 zu erkennen
ist.
Als sinnvoller Zusatzschritt wurde eine grobe Kosten- und Aufwandsschätzung hin-
zugefügt, um die jeweiligen benötigten Attribute durch Experten zu füllen.
Um zum Schluss eine Entscheidung über eine entsprechende Anforderung zu erlan-
gen, ist es überdies passend ein Freigabeprozessschritt zu durchlaufen.
Der hergeleitete AM-Prozess hat, wie oben veranschaulicht, weitestgehend alle
wichtigen Aktivitäten aus dem Theorieteil mit einbezogen. Eine Komprimierung
hat lediglich in der Wahl einer bestimmten Technik stattgefunden.
46
4 Werkzeuge zum Requirements Engineering
Um Requirements Engineering in der Praxis effizient einzusetzen sollte man sich ei-
nem Werkzeug als Unterstützung bedienen. In dem folgenden Kapitel werde ich die
verschiedenen Arten der Requirements Engineering Werkzeuge laut [Ebert2012]
aufzeigen und erläutern. Anschließend werde ich zwei Werkzeuge als Beispiel dar-
stellen und zum Schluss noch Kriterien für eine Werkzeugauswahl erläutern.
4.1 Arten von RE-Werkzeugen
Laut [Ebert 2012] werden Werkzeuge die folgenden Arten an RE-Werkzeugen unter-
scheiden, die in den folgenden Unterkapiteln erläutert werden:
Spreadsheets
Wikis
Workflow-Tools
Entwicklungsumgebungen und Modellierungswerkzeuge
auch gerne Anwendungs- oder Produktlebenszyklus-Management (ALM oder
PLM) genannt
Spezielle RE-Werkzeuge
Bei der Einführung eines Werkzeuges sollte beachtet werden, dass ein komplexeres
Werkzeug auch höhere Kosten mit sich bringt. Folgende Abbildung 12 verdeutlicht
diese Aussage:
47
4.1.1 Spreadsheets
Spreadsheets sind selbst gemachte Templates in einer Tabellenkalkulation und die
einfachste Form eines Werkzeugs für Requirements Engineering. Sie sind optimal für
kleinere Projekte anzuwenden da sie den großen Vorteil in ihrer leichten und flexib-
len Handhabung und direkte Nutzung mit verschiedenen Stakeholdern besitzen.
Als Beispiel eignet sich ein selbsterstelltes Excel-Sheet dass über die verschiedenen
Phasen eines Projektes benutzt werden kann. Der spätere Übergang in ein komple-
xeres RE-Werkzeug ist meist auch kein Problem, da Tabelleninhalte und Templates
werkzeugübergreifend gut übertragen werden. (vgl. [Ebert 2012], S. 329)
Abbildung 13: Einfaches Spreadsheet-Template für Anforderungen ([Ebert 2012], S. 98)
Komplexität
Ko
ste
n
Solution
Manager
Wikis
Workflow-
Tools
Spreadsheets
ALM oder
PLM
Spezielle RE-
Werkzeuge
Abbildung 12: Arten von RE-Werkzeuge
48
4.1.2 Wikis
Seit der Einführung von Web 2.0 nehmen Wiki-Umgebungen immer mehr an Zu-
wachs. Wikis erlauben den unmittelbaren Zugriff verschiedener Benutzer zur Organi-
sation von Anforderungen. Hierzu kann man ein vohandenes Template oder auch ein
komplettes Hosting von einer externen Quelle übernehmen und an den eigenen Be-
dürfnissen anpassen. Der große Vorteil ist, dass die Benutzer keinerlei HTML-
Kenntnisse brauchen, um die Einträge zu bearbeiten oder zu verwalten.
OpenColletive1 bietet eine Beschreibung, wie Wiki-Umgebungen für Requirements
Engineering aufgebaut und genutzt werden. (vgl. [Ebert 2012], S. 329)
4.1.3 Workflow-Tools
Bei der Übertragung von Aufgaben zwischen verschiedenen Benutzern bzw. bei ver-
teilten Projekten können Workflow-Tools als große Unterstützung für das Require-
ments Engineering dienen. Ihre Stärke ist die Beschreibung der Abfolge von Schrit-
ten, beispielsweise von der Ermittlung bis zur Freigabe, die dann automatisch an
verschiedene Personen weitergeleitet werden können. Diese werden darüber infor-
miert, dass Anforderungen, Arbeitspakete, Fehlermeldungen oder Testfälle zu bear-
beiten sind. Als bekanntes Open-Source-Tool für hat sich Bugzilla2 erwiesen. Viele
große Open-Source-Projekte verwenden Bugzilla, um Fehlermeldungen und Wün-
sche von Benutzern zu sammeln ([Ebert 2012], S. 329).
1 http://www.codeproject.com/aspnet/OpenCollective.asp
2 http://bugzilla.org
49
4.1.4 Entwicklungsumgebungen und Modellierungswerk-
zeuge
Einen Schritt weiter in der Werkzeugskala liegen die Entwicklungsumgebungen die
auch gerne als ALM- oder PLM(Anwendungs- oder Produktlebenszyklus-
Management) bezeichnet genannt werden. Sie entwickeln, pflegen und verwalten
Informationen über den Lebenszyklus des Produkts hinweg. (vgl. [Ebert 2012], S.
329)
Da der SAP Solution Manager ein ALM Werkzeug ist siedelt es sich in dieser Katego-
rie der Werkzeuge an. Einen kurzen Überblick über den SAP Solution Manager wer-
de ich in Kapitel 4.5 darstellen.
4.1.5 Spezielle RE-Werkzeuge
Komplexere RE-Werkzeuge unterstützen die Verwaltung und Nachverfolgung von
Anforderungen, Spezifikationen und weiteren Dokumenten (z.B. Testfällen) sowie die
Verknüpfung dieser Dokumente zur Projektkontrolle. Vereinzelt werden diese spezi-
ellen Werkzeuge auch Computer Assisted Requirements Engineering(CARE) ge-
nannt. Solche Werkzeuge bieten eine gute grafische Umgebung an, mit der Anforde-
rungen, Workflows, Abhängigkeitsbeziehungen und Modelle beschrieben werden
können. Vielfältige Filter erlauben die Verknüpfung, Gruppierung Weiterbearbeitung
und Verwaltung auch komplexer Anforderungsbeziehungen. Um eine bestmögliche
Durchgängigkeit zu erreichen verwenden diese Werkzeuge eine Verknüpfung zwi-
schen Anforderungsspezifikationen, deren Verwaltung und Modellierungswerkzeuge.
Der Standard für die Modellierungssprache ist die UML-Notation (vgl. [Ebert 2012], S.
329).
50
4.2 Beispiel: DOORS
IBM Rational DOORS3 (im Folgenden nur DOORS genannt) wird bei den großen
Analysten wie z.B. der Standish Group als Marktführer im Bereich Anforderungsma-
nagement gesehen (vgl. [Ebert 2012], S. 336). DOORS unterstützt den Benutzer sei-
ne Spezifikationen basierend auf beliebigen Standards und Prozessmodellen wie
z.B. ITIL zu erstellen und zu pflegen.
Durch den Webclient DOORS Web Access können Anforderungen unternehmens-
weit erfasst, geprüft und gepflegt werden, ohne dass ein dedizierter Client dafür not-
wendig ist. Hierbei passt sich DOORS den Prozessen und der Informationsarchitek-
tur im konkreten Einsatzszenario an, ohne den Projekten vorgefertigte Strukturen
aufzuzwingen.
Zusätzlich werden durch die Integration zu anderen Lösungen von IBM Rarional und
anderen Herstellern die Transparenz und die Verfolgbarkeit der Anforderungen ge-
steigert.
Durch eine offene, freie und nichtproprietären Schnittstelle unterstützt DOORS die
Integration zu Tools aus Change-, Test- und Architekturmanagement.
DOORS stellt Anforderungen und andere Informationselemente in einer hirarischen
Dokumentenstruktur dar, so wie man es von den klassischen Textverarbeitung Sys-
temen kennt. Über beliebig definierbare Attribute kann eine Klassifizierung von An-
forderungen erstellt werden.
3 http://www.ibm.com/software/awdtools/doors
51
Abbildung 14: Screenshot von DOORS - Anforderungen mit den zugehörigen Attributen ([Ebert 2012],
S.337)
Da ein Projektmitarbeiter meist nur einen Teil der Informationen aus einem Anforde-
rungsdokument benötigt um eine bestimmte Aufgabe zu lösen, lassen sich in
DOORS individuelle konfigurierbare Sichten anpassen. Durch zusätzliche Filter-
und/oder Sortierbedingungen wird diese individuelle Anpassung noch gestärkt. Ab-
bildung 15 zeigt verschiedene Sichten auf dasselbe Anforderungsdokument.
52
Abbildung 15: Verschiedene Sichten auf dasselbe DOORS-Dokument ([Ebert 2012], S. 338)
Um Zusammenhänge zwischen den Anforderungen zu dokumentieren können in
DOORS Links zwischen den Anforderungen erstellt werden. Um nicht einen un-
durchschaubares Chaos zwischen den Abhängigkeiten der Anforderungen zu erhal-
ten bietet DOORS die Möglichkeit die Erstellung von Abhängigkeiten einzuschrän-
ken.
Um eine Differenz zwischen den Anforderungen und dem entstehenden System zu
vermeiden ist eine enge Verzahnung von Anforderungsmanagement mit allen Pha-
sen des Entwicklungsprozess notwendig. Dies wird in DOORS durch eine Verknüp-
fung von Anforderungen mit den für die Umsetzung wesentlichen Design- und Im-
plementierungsartefakten. Somit kann für jede Anforderung der Weg der Realisie-
rung über den gesamten Entwicklungsprozess verfolgt werden. Ein weiterer großer
Vorteil dieser Verknüpfung spiegelt sich bei der Aufwand- und Risikoabschätzung
wider. Falls sich eine Anforderung ändert machen sich die Auswirkungen in allen be-
troffenen Designelementen und Modulen bemerkbar und können realistisch einge-
schätzt werden.
53
4.3 Beispiel: Integrity
Integrity4 ist eine Plattform für das Application Lifecycle Management (ALM). Mit ihr
kann man den gesamten Softwareentwicklungszyklus (vom Requirements Manage-
ment bis zum Testmanagement) betreuen. (vgl. [Ebert 2012], S. 340 ff.)
Integrity enthält eine Lösung für das Requirements Engineering und wird sowohl von
kleinen Entwicklungsteams wie auch von größeren und IT- und Entwicklungs-
abteilungen multinationaler Unternehmen angewendet. (vgl. [Ebert 2012], S. 340)
Abbildung 16: Konfigurierbare Benutzeroberfläche von Integrity mit Dokumenten- und Beziehungsansich-
ten ([Ebert 2012], S. 342)
Integrity vereinfacht die Verwaltung mit Dokumenten und soll Unternehmen bei dem
Requirements Engineering bei Herausforderungen unterstützen, die sich ergeben,
wenn bisher hauptsächlich auf traditionelle Bürosoftware gesetzt wurde (Dokumente,
Excel-Tabellen). (vgl. [Ebert 2012], S. 341)
4 http://www.mks.com
54
Integrity verwaltet Dokumentinhalte in einer datenbankgestützten Client-Server-
Architektur und löst so wesentliche Probleme in der Kommunikation. Statt einzelne
Kopien zu erstellen, die später wieder miteinander in Übereinstimmung gebracht
werden müssen, können Teammitglieder ihre Anforderungsinformationen in Echtzeit
»online« bearbeiten. Dies erleichtert erheblich die Kommunikation in der Abstim-
mungsphase.
Ein konfigurierbarer Workflow kann automatische Regeln und Prozesse definieren,
beispielsweise Änderungen verhindern, sobald eine Anforderung einen bestimmten
Status erreicht, oder E-Mail-Benachrichtigungen senden, wenn Änderungen vorge-
nommen wurden sind.
Integrity ersetzt die häufig in Unternehmen verwendeten spezifischen Dokumente zur
Nachverfolgung indem Daten, Metadaten sowie die Beziehungen zu anderen Anfor-
derungen in einer Datenbank gespeichert werden.
Zudem kann je nach Bedarf Projektinformationen in Diagrammen oder Tabellen dar-
gestellt werden. Somit kann ein Projektmanager sich einen Bericht erstellenlassen,
um den "Durchsatz" eines Projekts zu bewerten, also zu ermitteln, wie viele Anforde-
rungen kürzlich verändert oder bearbeitet wurden. Dies ist ein wichtiges Kriterium,
um festzustellen, ob Anforderungen stabil genug sind, damit mit dem Design und der
Entwicklung begonnen werden kann.
Da Unternehmen Tausende von Anforderungen für Hunderte von Komponenten ma-
nagen müssen, genügt es nicht Anforderungen in einer Liste oder einem Dokument
zu verwalten. Zudem können Anforderungen für mehrere gleichzeitig entwickelte Va-
rianten eines Produkts gemeinsam genutzt werden. Daher wird Integrity auch gerne
zur Verwaltung komplexer Abhängigkeitsbeziehungen verwendet.
Integrity wird zur Koordination von über den ganzen Globus verteilten Teams, von
externen Mitarbeitern und anderen Anwendern der Anforderungen (z.B. Kunden und
Lieferanten) eingesetzt (vgl. [Ebert 2012], S. 342).
Ein erheblicher Effizienzgewinn entsteht für diese Unternehmen durch die Unterstüt-
zung der Entwicklung von Softwareproduktlinien durch Integrity. Bei Softwareprodukt-
linien (SPL) handelt es sich um die zusammengefasste Entwicklung ähnlicher Pro-
dukte auf Basis gemeinsamer Bestandteile. Das ist häufig in der Mobilfunkindustrie
55
wiederzufinden. Dort sind die Mehrheit der Anforderungen in vielen oder allen Pro-
duktvarianten identisch und sollten diese zugunsten der Effizienz parallel verwaltet
werden. Die Wiederverwendung von Anforderungen und ihre gemeinsame Nutzung
in den Produktlinien verringern den Aufwand und verbessern die Zusammenarbeit
der Teams, was wiederum für eine höhere Produktqualität und eine schnellere
Markteinführung sorgt (vgl. [Ebert 2012], S. 343).
4.4 Kriterien für die Werkzeugeinführung
Laut ([Ebert 2012], S. 351) sind die folgenden Punkte als mögliche Anforderungen an
RE-Werkzeuge zu sehen. Man sollte aber nicht alle Punkte mit einbeziehen da diese
Anforderungen je nach Anwendungsgebiet nicht gleichermaßen relevant sind.
1. Benutzbarkeit
Es sollte darauf geachtet werden, dass alle vorgesehenen Benutzergruppen
mit dem Werkzeug produktiv arbeiten können.
2. Spezifikation von Anforderungen
Aufnahme und Dokumentation aller Arten von Anforderungen, Randbedingun-
gen etc. sowie deren Status in einer einzigen Datenbank. Wichtig ist, sich
klarzumachen, was die Informationen sind, die Sie als Anforderungen – heute
und in Zukunft – ablegen wollen.
3. Organisation von Anforderungen
Verwaltung der Anforderungsinformationen wie z.B. die einfache Aufzeich-
nung von Autoren, Änderungen und Zeitpunkten sowie der einfache Zugriff auf
Inhalte.
4. Änderungsmanagement der Anforderungen
Die Änderungen von Anforderungen sind häufig die Ursache für ständig ver-
schobene Termine und unzureichende Projektergebnisse. Daher ist das Ände-
rungsmanagement ein Hauptgrund, Werkzeuge einzusetzen. Sie erlauben, ei-
56
ne aktualisierte Konfigurationsbasis zu erstellen oder kontrollierte Schnapp-
schüsse von Funktionslisten unternehmensweit zur Verfügung zu stellen.
5. Wiederverwendung von Anforderungen
Anforderungen und zugehörige Artefakte wie Testfälle sollten so weit wie mög-
lich wiederverwendbar sein, wenn es an Versionierung und Variantenbildung
geht.
6. Filterung von Inhalten
Um Inhalte zielorientiert darstellen zu können und um Ausgaben oder Reports
zu reduzieren, sollten Filter eingesetzt werden.
7. Zugriff mit anderen Werkzeugen auf andere Datenbanken
Unterstützung anderer Werkzeuge um aus der RE-Datenbank Information
auslesen zu können oder umgekehrt.
8. Verteilte Nutzung der Daten und Kollaboration
Verwendung der Anforderungen von ganz verschiedenen Benutzergruppen an
verschiedenen Standorten
9. Adaptierbarkeit an und Integrierbarkeit mit vorhandenen Geschäftspro-
zessen
Es sollte keine Beeinträchtigung vorhandener Geschäftsprozesse mit Einfüh-
rung des Werkzeugs geschehen.
10. Hersteller, Stabilität und Support
Es sollte die Stabilität des Herstellers berücksichtigt werden.
11. Kosten
Es sollten Kosten für Anschaffung, Wartung und Service berücksichtigt wer-
den.
57
4.5 Der SAP Solution Manager
Der SAP Solution Manager eine Softwarelösung für das Application Lifecycle Mana-
gement und dem Betrieb von Softwarelösungen. Seine Funktionen decken alle Be-
reiche von Softwarelebenszyklen ab, also von der Implementierung über die Produk-
tivsetzung und den Betrieb bis hin zur kontinuierlichen Verbesserungen von Soft-
warelösungen. Lebenszyklen umfassen wie in der Abbildung dargestellt sechs Pha-
sen:
Abbildung 17: Lebenszyklus von IT-Lösungen ([Schäfer et al. 2011], S. 30)
1. Requirements
Erfassung der Anforderungen für neue Anwendungen oder für die Verbreitung
bestehender Anforderungen. oder Änderung von bestehender Software.
2. Design
Übersetzung der Anforderungen in detaillierte Spezifikationen.
3. Build and Test
Anwendungskonfiguration und Erstellung eines Organisationsmodells gemäß
den Spezifikationen.
Require-ments
Design
Build and Test
Deploy
Operate
Optimize
Application
Manage-
ment
58
4. Deploy
Übertragung der Änderungen und des Organisationsmodells in die bestehen-
de produktive IT-Landschaft.
5. Operate
Bereitstellung von IT-Services, die für den fortlaufenden Betrieb erforderlich
sind.
6. Optimize
Analyse der Service-Level-Erfüllung und möglicher Start von Maßnahmen zur
Verbesserung der Ergebnisse
Der SAP Solution Manager unterstützt zudem die etablierten und standardisierten
ITIL V3 Prozesse. In erster Linie dient er dazu eine SAP-Systemlandschaft eines Un-
ternehmens zu Warten, Verwalten und zu Überprüfen.
Die komplexe und vielfältige Applikation stellt unter anderem Werkzeuge und Funkti-
onalitäten zur Verfügung, um den technischen Support in den Systemen zu vereinfa-
chen und zu unterstützen. Kunden werden bei der funktionalen und technischen Im-
plementierung sowie bei der kontinuierlichen Verbesserung und Optimierung der
SAP-Systemlandschaft durch die hilfreichen Werkzeuge wie IT-Service, Incident,
Problem und Change Management unterstützt. Zusätzlich stellt der Solution Manager
Vorlagen oder auch Vorgehensweisen in Form von Roadmaps und Services für die
Implementierung und zum Betrieb der SAP Applikationen zur Verfügung. Unterneh-
men benötigen daher keine weiteren Managementtools für die Verwaltung ihrer Sys-
temlandschaft.
Der Solution Manager bietet Unternehmen eine Verwaltungsplattform für ihr gesam-
tes SAP-Lösungsportfolio und reduziert, mit Hilfe der zur Verfügung gestellten Funk-
tionen, die Komplexität von heterogenen IT-Landschaften sowie die Gesamtbetriebs-
kosten durch standardisiertes Vorgehen und Methoden.
Des Weiteren ermöglicht der Solution Manager die Anbindung von Partnerprodukten
oder Nicht-SAP Komponenten (Nicht SAP Komponenten sind Produkte, die nicht von
der SAP AG hergestellt wurden, z.B. das Modellierungstool ARIS), damit auch das
gesamte Potenzial des Tools effizient genutzt werden kann. (vgl. [Schäfer et al.
2011], S. 29 ff.)
59
5 Umsetzung (Abbildung) des hergeleiteten
RE-Soll-Prozesses
5.1 Prozessdefinition
Um den erarbeiteten RE-Soll-Prozess im SAP Solution Manager technisch abbilden
zu können, sollte der Prozess soweit aufbereitet werden, dass passende Status und
Aktionen sichtbar sind. Infolgedessen wird innerhalb dieses Kapitels der RE-Soll-
Prozess auf die wesentlichen Punkte zusammengefasst. Hierzu werden sinnvolle
Bezeichnungen für die Status und deren Statusübergänge vergeben. Folgende Ab-
bildung stellt den für den SAP Solution Manager aufbereiteten RE-Soll-Prozess dar:
In Qualitätsprüfung
Zur Qualitätsprüfung übergeben
In Nachbearbeitung
Qualitätsprüfung nicht erfolgreich;
In Kalkulation
Zu genehmigen
Genehmigt AbgelehntZurückgestellt
Nacharbeit bestätigen lassen;
Konflikt(e) - Zu spezifizieren
Konflikte(e) - In Abstimmung
Konflikt gelöst;
Qualitätsprüfung erfolgreich+ Konflikt(e) entdeckt;
Qualitätsprüfung erfolgreich+ keine Konflikt(e) entdeckt;
Angelegt
Legende:
Initialstatus
Status
Finalstatus
Statusübergang(Aktion)
Zur Kalkulation übergeben
Zur Qualitätsprüfung übergeben
Zur Nachbearbeitung übergeben
Zur Genehmigung übergeben
Zum Konfliktmanagementübergeben
Zur Konflikt–Abstimmungübergeben
Zur Kalkulationübergeben
Anforderunggenehmigen
Anforderungzurückstellen
Anforderungablehnen Getilgt
Anforderung tilgen
Abbildung 18: RE-Soll Prozess mit den einzelnen Status und Statusübergängen (Aktionen)
60
Da er komplette Soll-Prozess im Kapitel 3 detailliert erläutert wurde, wird folgend eine
komprimierte Erläuterung des Soll-Prozesses für den SAP Solution Manager gege-
ben. Hierbei wird der Soll-Prozess aus das System zugeschnitten dargestellt um eine
Umsetzung zu erleichtern.
Die Phasen wurden sinnvoll unbenannt um den aktuellen Bearbeiter besser zu ver-
deutlichen was gerade zu tun ist (z.B. In Nachbearbeitung). Der Initialstatus und die
Finalstatus wurden anders dargestellt als die weiteren. Die Statusübergänge wurden
auch sinnvoll benannt und beschrieben in welchem Fall der jeweilige Statusübergang
relevant ist.
Der Soll-Prozess für den SAP Solution Manager beginnt mit dem Initialstatus Ange-
legt. Nachdem der aktuelle Bearbeiter die benötigten Attribute ausgefüllt hat, kann
dieser die Anforderung zur Qualitätsprüfung übergeben (eine Auflistung der genauen
Attribute in dem jeweiligen Staus wird weiterhin in diesem Kapitel dargestellt). An-
schließend befindet sich die Anforderung im Staus In Qualitätsprüfung in der die An-
forderung auf die Qualitätskriterien hin geprüft wird. Von hier kann die Anforderung
wieder zur Nachbereitung übergeben werden, wenn Fehler gefunden worden sind.
Ansonsten kann die Anforderung in die folgenden die weiteren Status In Kalkulation
oder Konflikt(e) zu spezifizieren übergehen, jeweils ob Konflikte bestehen oder nicht.
Wenn Konflikte existieren sollten diese abgestimmt werden und eventuelle Anforde-
rungen die anschließend nicht mehr relevant sind getilgt werden. Als letzten Schritt
sollte die Anforderung genehmigt werden.
Zusätzlich stellt folgende Tabelle die einzelnen Status mit dem zugehörigen Bearbei-
ter, die zu besetzenden Attributen sowie die möglichen ausführbaren Aktion(en) des
aktuellen Zustandes übersichtlich dar.
Automatisch ausgefüllte Attribute werden unterstrichen dargestellt.
Attribute, die in mehr als an einer Statusposition angepasst werden können,
werden kursiv dargestellt.
Die Beschriftung in Klammern soll die Bezeichnung darstellen, die im SAP So-
lution Manager verwendet wird.
61
Status Aktueller Be-
arbeiter Attribute Ausführbare Aktion(en)
Aufgenommen Anforderer (Autor)
Anforderungsnummer (ID)
Anforderungsname (Bezeichnung)
Beschreibung
Quelle
Autor
Anforderungstyp (Sachverhalt)
Juristische Verbindlichkeit / Wich-
tigkeit (Kategorie)
System oder Geschäftsprozess
Erstelldatum
Versionsnummer
Historie
Stabilität
Fertigstellungstermin (Realisie-
rungsdatum)
Release
Abhängigkeiten / Querbezüge
Vorbedingung(en)
Priorität
Zusätzliche Information
E-Mail versenden
Zur Qualitätsprüfung übergeben
In Qualitätsprüfung Requirements Engi-
neer
Requirements Engineer
Status der Überprüfung
Projektleiter
In Konflikt stehende Anforde-
rung(en)
Release
Stabilität
Abhängigkeiten / Querbezüge
Vorbedingung(en)
Priorität
Zusätzliche Information
E-Mail versenden
Zur Nachbearbeitung übergeben
Zum Konfliktmanagement über-
geben
Zur Kalkulation übergeben
In Nachbearbeitung Anforderer (Autor) - E-Mail versenden
Zur Qualitätsprüfung übergeben
Konflikt(e) - Zu spezi-
fizieren
Requirements Engi-
neer
In Konflikt stehende Anforde-
rung(en)
E-Mail versenden
Zur Konflikt-Abstimmung über-
geben
Konflikte(e) - In Ab-
stimmung
Requirements Engi-
neer
Status (Einigung)
Release
Stabilität
Abhängigkeiten / Querbezüge
Vorbedingung(en)
Priorität
Zusätzliche Information
E-Mail versenden
Zur Kalkulation übergeben
62
In Kalkulation Projektleiter
Kosten
Aufwand
Release
Stabilität
Abhängigkeiten / Querbezüge
Vorbedingung(en)
Priorität
Fertigstellungstermin (Realisie-
rungsdatum)
Zusätzliche Information
E-Mail versenden
Zur Genehmigung übergeben
Zu genehmigen Quelle
Grund der Ablehnung / Zurück-
stellung
Zusätzliche Information
E-Mail versenden
Anforderung genehmigen
Anforderung zurückstellen
Anforderung ablehnen
Tabelle 5: Statustabelle
5.2 Customizing
Zunächst wurde ein Geschäftspartner (GP), Scharif Elsawa, mit dem Benutzerken-
nung „SCELSAWA“ und der ID „3334“ angelegt. Dieser kann eine Person, Organisa-
tion oder eine Gruppe von Personen eines Unternehmens symbolisieren, die ein ge-
schäftliches Interesse haben. Jeder Geschäftspartner ist einem Benutzernamen so-
wie einer eindeutigen Identifikationsnummer zugeordnet.
Anschließend wurde der Vorgang „Änderungsantrag“ aus dem Standard selektiert
und mit allen Unterpunkten kopiert, um keine Änderungen über die Standardeinstel-
lung zu generieren. Alle zukünftigen Konfigurationen (Customizing) wurden somit
ausschließlich im kopierten Vorgang vorgenommen. Es wurde die Vorgehensweise
über den „Änderungsantrag“ aus dem Grund ausgewählt, da an dieser Stelle der Sta-
tusübergang funktioniert hat.
Der kopierte Vorgang wurde von „SDCR“ in einen eigenen Z-Namensraum „ZSRE“
übertragen und umbenannt, damit der Standard erhalten bleibt und individuelle An-
passungen nicht am originalen Vorgang vorgenommen werden können. Folgende
Profile sind durch diesen Kopiervorgang betroffen gewesen:
63
Beschreibung Standard Geändert in
Partnerschema SDCR0001 ZSRE0001
Statusschema SDCRHEAD ZSREHEAD
Aktionsprofil SDCR_ACTIONS ZSRE
Textschema SDCR ZSRE
Terminprofil SDCR_HEADER ZSRE_HEADER
Tabelle 6: Bezeichnungen vom kopierten Vorgang
Die kopierten Profile und Schemas wurden alle dem Vorgang „ZSRE“ zugeordnet.
Zusätzlich wurden zwei weitere Profile kopiert, die „Proxy-Instanz“ und die „Einstel-
lungen für Änderungsvorgänge“, um einen funktionsfähigen Statusübergang zu er-
möglichen.
Anschließend musste vor dem eigentlichen Customizing der Folgebeleg abgestellt
bzw. verhindert werden, da dieser eine Weiterschaltung des Status verhindert, wenn
die Bedingung eines Wartungsprojekts nicht erfüllt wird. Diese Einstellung nimmt der
User unter dem Aktionsprofil im „Aktionsprofile und Aktionen“ über dem Cutomizing-
Leitfaden vor.
Abbildung 19: Ausschnitt „Aktionsprofil Scharif RE“
Alle weiteren Aktivitäten werden im Verlauf des Customizings ausschließlich über
den entsprechenden Leitfaden durchgeführt.
64
Abbildung 20: Ausschnitt vom Customizing-Leitfaden
5.2.1 Status definieren
Innerhalb dieses Abschnitts werden Definitionen für die Status des RE-Soll-
Prozesses erläutert. Die einzelnen Status wurden in Abbildung 18 und Tabelle 5
schon übersichtlich dargestellt. Statusverwaltungen werden über den Punkt „Status-
verwaltung“ im Customizing-Leitfaden durchgeführt. Es wurde ein neues Status-
schema ZSREHEAD erstellt und die einzelnen Status <Aufgenommen>, <In Quali-
tätsprüfung>, <In Nachbearbeitung>, <Konflikt(e) zu spezifizieren>, <Konflikt(e) In
Abstimmung>, <In Kalkulation>, <Zu genehmigen>, <Genehmigt>, <Zurückgestellt>
und <Abgelehnt> hinzugefügt.
Anschließend wurden Anfangs- und Endstatus festgelegt, indem der Status <Aufge-
nommen> als Initialstatus gekennzeichnet wurde und die Staus <Genehmigt>, <Zu-
rückgestellt> und <Abgelehnt> mit dem Attribut FINI für Finalstatus markiert wurden.
65
Abbildung 21: Ausschnitt vom „Statusprofil“
Um die Reihenfolge der Anzeige auf dem Beleg zu bestimmen, werden dementspre-
chende Ordnungsnummern vergeben (s. Abbildung 21)
5.2.2 Partnerfunktionen definieren
Als nächstes müssen die Partnerfunktionen im Partnerschema ZSRE0001 zugeord-
net werden. Dieses schließt sämtliche benötigten Partnerfunktionen eines Vorgangs
ein.
Wie in Tabelle 5 zu entnehmen, werden die Partnerfunktionen (Rollen)
<Anforderer(Autor)>, <Quelle>, <Requirements Engineer> und <Projektleiter> benö-
tigt. Da der SAP-Standard des Solution Managers einige der Rollen- bzw. Partner-
funktionen nicht beinhaltet, müssen diese zunächst definiert werden. Eine entspre-
chende Zuteilung der Partnerfunktionen wird im Customizing-Leitfaden unter dem
Punkt „Partnerfunktionen definieren“ deklariert.
Abbildung 22: Ausschnitt Partnerfunktion definieren
66
Anschließend erfolgt die Zuordnung der benötigten Partnerfunktionen zum erstellten
Partnerschema ZSRE0001. Dieses kann unter dem Menüpunkt „Partnerschema de-
finieren“ vorgenommen werden.
Abbildung 23: Ausschnitt Partnerschema ZSRE0001 (Scharif RE - Partnerschema)
5.2.3 Aktionen definieren
Um einen Statusübergang zu ermöglichen, müssen Aktionen definiert werden, die
diesen Statusübergang auslösen. Die dazugehörige Zuteilung der Status wurde in
Kapitel 5.2.1 dargestellt.
Unter dem Menüpunkt „Aktionsprofile und Aktionen definieren“ im Customizing-
Leitfaden nimmt der User Einstellungen mit Bezug auf entsprechende Aktionen vor.
Da das Aktionsprofil ZSRE eine Kopie des Aktionsprofils SDCR_ACTIONS darstellt,
wurden auch sämtliche Aktionen ebenfalls kopiert. Diese mussten noch angepasst
bzw. bei Nichtgebrauch inaktiv gesetzt werden. Anpassungen wurden innerhalb der
Beschreibung und des „Initialwerts“ vorgenommen.
67
Abbildung 24: Ausschnitt vom Aktionsprofil ZSRE
Der Initialwert bestimmt dabei den zu erreichenden Status. Nachfolgend die Liste der
Status mit den dazugehörigen Initialwerten.
Abbildung 25: Statusliste mit Initialwerten
Eine Aktion, die einen Statusübergang erzeugen soll, muss im Initialstatus die Be-
zeichnung des zu erreichenden Anwenderstatus beinhalten (z. B. E0006).
Abbildung 26: Beispiel für einen Initialwert
Beispielsweise in dem Fall, wenn ein Statusübergang in Richtung <In Kalkulation>
ermöglicht werden soll, dann müsste als Initialwert E0007 eingetragen werden. Wei-
68
tere Einstellungen wurden getätigt, sodass eine Aktion erst nach dem Speichern
ausgeführt werden soll. Der Auftrag „E-Mail versenden“ wurde mit „(Dummy)“ ge-
kennzeichnet, da es sich hier um keine funktionstüchtige Aktion handelt und lediglich
zur Demonstration dienen soll.
5.2.4 Bedingungen definieren
Nachdem im Aktionsprofil ZSRE Aufgaben definiert worden sind, müssen für ent-
sprechende Bedingungen definiert werden, um einzuschränken, in welchem Status
Aktionen sichtbar und damit auch durchführbar sind. Diese Einstellungen werden
unter dem Menüpunkt „Bedingungen definieren“ im Customizing-Leitfaden vorge-
nommen. Die vorher definierten Aufgaben sind in der Liste Aktionsprofile zusam-
mengefasst und können entsprechend ausgewählt werden. Anschließend muss eine
„Einplanbedingung“ definiert werden, d.h. die Aktion wird nur dann im Arbeitsvorrat
angezeigt, sofern eine entsprechende Voraussetzung erfüllt ist.
Abbildung 27: Ausschnitt aus der "Bedingungen definieren" Konfiguration
69
Die obige Abbildung 27 zeigt die Bedingung für eine Aktion „Zur Konflikt-Abstimmung
übergeben“ an. Innerhalb dieser Vorgabe wird angegeben, inwiefern die Aktion „Zur
Konflikt-Abstimmung übergeben“ lediglich angezeigt wird, wenn sich der User im
Anwenderstatus E0005 („Konflikt(e) zu spezifizieren“) befindet. Es können auch meh-
rere Einplanbedingungen mitsamt logischen Verknüpfungen „And“, „Or“ oder „Not“
versehen werden. Diese Konfiguration wurde analog für jede Aktion durchgeführt.
5.2.5 Textschema definieren
Unter dem Menüpunkt „Textschema definieren“ im Customizing-Leitfaden hat der
Anwender die Möglichkeit, Textfelder einzustellen. Hierzu wurden lediglich passende
Textfelder für das Textschema ZSRE0001 (Scharif RE – Texte) aus dem Standard-
bereich ausgewählt, da für eine Definition eigener Textfelder komplexere Einstellun-
gen vorgenommen werden müssten und dieses Vorgehen den Rahmen der Arbeit
sprengen würde.
Abbildung 28: Ausschnitt aus dem Menüpunkt "Textfelder definieren"
70
5.2.6 Sachverhaltsprofile definieren
Die Bezeichnung Sachverhalt wurde für die Hinterlegung des Attributs <Anforde-
rungstyp> (also für eine Auswahl zwischen „funktionaler Anforderung“, „Qualitätsan-
forderung“ oder „Rahmenbedingung“) benutzt.
Abbildung 29: Ausschnitt aus dem RE-Vorgang mit der Auswahl des Sachverhalts
Zunächst musste dafür unter dem Menüpunkt „Codegruppenprofile definieren“ der
Katalog IS (Katalog Issues) ausgewählt werden. Anschließend wurde eine neue
Codegruppe Z1 (Requirement Anforderungstyp) erstellt und entsprechende Codes
„Z1 Funktionale Anforderung“, „Z2 Qualitätsanforderung“ und „Z3 Rahmenbedin-
gung“ hinterlegt. Anschließend wurde für das Codegruppenprofil SLFI00001 (Profile
for Issue / Top Issue) die Codegruppe Z1 (Requirement Anforderungstyp) zugewie-
sen, weil dieses für die Anzeige des Sachverhalts grundlegend ist.
5.2.7 Kategorie bearbeiten und dem Vorgang zuordnen
Die Bezeichnung Kategorie wurde genutzt, um das Attribut <Juristische Verbindlich-
keit / Wichtigkeit> auswählen zu können.
Abbildung 30: Ausschnitt aus dem RE-Vorgang mit der Auswahl der Kategorie
71
Für die Konfiguration der Kategorie wurden mithilfe der Suchfunktion die Menüpunkte
„Kategorien bearbeiten“ und „Kategorie den Vorgangsarten zuordnen“ ausfindig ge-
macht. Unter dem Menüpunkt „Kategorie bearbeiten“ hat man die Möglichkeit weitere
Kategorien anzulegen. Hierbei wurden die Kategorien „MUS (MUSS)“, „SOL (SOLL)“
und „WIR (WIRD)“ angelegt. Anschließend wurden unter dem Menüpunkt „Katego-
rien den Vorgangsarten zuordnen“ die erstellten Kategorien dem Vorgang ZSRE
Scharif RE zugeordnet (s. Abbildung 31).
Abbildung 31: Ausschnitt aus dem Menüpunkt "Kategorien den Vorgangsarten zuordnen"
5.2.8 Terminprofil definieren
Um Zeiterfassungen zu tätigen, bietet der SAP Solution Manager unter dem Menü-
punkt „Terminprofil definieren“ aus dem Customizing-Leitfaden die Möglichkeit, Da-
tumsattribute zu definieren. Für den RE-Soll-Prozess werden lediglich das Erstell-
(Erfassungsdatum) und das Realisierungsdatum benötigt. Da der Standard diese
Zeiterfassungsmöglichkeiten anbietet, mussten diese lediglich im Terminprofil
ZSRE_HEADER (Scharif RE - Terminprofil) den Terminarten zugeordnet werden (s.
Abbildung 32).
Abbildung 32: Einstellung im Terminprofil
72
5.3 Offene Punkte der Umsetzung
Eigene Textfelder, Formulare und Auswahllisten sind mit einem etwas höheren Ent-
wicklungsaufwand verbunden und konnten im Rahmen dieser Arbeit nicht umgesetzt
werden. Hierzu zählen beispielsweise das Attribut <Abhängigkeiten / Querbezüge>
oder auch die Eigenschaft <In Konflikt stehende Anforderungen>. Ein optimaler Lö-
sungsweg bestände aus einer direkten Verlinkung der Attribute mit den dazugehöri-
gen Anforderungen. Auch das ist mit einem höheren Entwicklungsaufwand verbun-
den.
Weiterhin bedarf es einer Umsetzung bezüglich der Attribute <Aufwand> und <Kos-
ten>. Auch hier müssten aufwendige Anpassungen getätigt werden, um dem RE-
Soll-Prozess zu genügen.
Ein weiterer offener Punkt besteht darin, dass in verschiedenen Status jeweils pas-
sende Pflichtfelder gesetzt werden könnten. Auch das war leider im Rahmen dieser
Arbeit nicht möglich.
Ein Hauptkriterium, das einen offenen Punkt darstellt, ist das Erstellen von Anforde-
rungsbeschreibungen anhand bzw. mithilfe von Anforderungsschablonen wie in Kapi-
tel 2.4.2.3 beschrieben wurde sowie passenden Beispielen innerhalb des Kapi-
tels 3.3.2.
Weiterhin war es auch mit einem höheren Entwicklungsaufwand verbunden, ein
Glossar zu pflegen.
73
6 Fazit
Schnelle Veränderungen, Kostendruck, Trend, globaler Wettbewerb, Wert und Nut-
zen - all diese Eigenschaften zeigen die Notwendigkeit vom systematischen Requi-
rements Engineering.
Das Ziel der Arbeit bestand darin, die aktuellen Tätigkeiten vom Requirements Engi-
neering aufzuarbeiten, einen geeigneten Prozess zu erarbeiten und diesen in dem
SAP Solution Manager abzubilden.
Folgend hat sich aus der Erarbeitung des Themas Requirements Engineering und
der daraus hergeleitete RE-Prozess herausgestellt, dass es nicht den einen richti-
gen Requirements Engineering Prozess gibt. Vielmehr müssen alle Projektbeteiligte
gemeinsam einen sinnvollen und individuellen Prozess entwickeln.
Des Weiteren wurde klar ersichtlich, dass die hauptsächlichen Tätigkeiten des Requi-
rements Engineering überwiegend auf Methoden der Sozialwissenschaften basieren
und folgedessen die dazugehörigen Werkzeuge lediglich als Unterstützung dienen.
Die Aktivitäten liegen somit grundlegend beim Benutzer. Die Hauptproblematik liegt
insbesondere in der Beschreibung der Anforderungen.
Bei dem Betrachten der Werkzeuge hat sich ergeben, dass RE-Tools lediglich als
reine Unterstützung für das Management von Anforderungen dienen. Bei der Aus-
wahl eines geeigneten Tools sollte vorab genau reflektiert werden, ob der Einsatz
dieses neuen Tools einen wirklichen messbaren Vorteil mit sich bringt.
Der SAP Solution Manager stieß bei der Umsetzung des RE-Prozesses an seine
Grenzen. Individuelle Funktionen sind meist mit einem höheren Entwicklungsauf-
wand verbunden, wie beispielsweise die Umsetzung für die Aufnahme spezieller At-
tribute oder die Pflege eines Glossars. Daher ist es wichtig, grundsätzlich vorher zu
reflektieren, ob ein vorhandenes kommerzielles Werkzeug in dem Bereich nicht
günstiger wäre. Der große Vorteil, den Einsatz des SAP Solution Managers zu un-
termauern, wäre die einfache Anbindung in eine vorhandene SAP Landschaft.
74
7 Verzeichnisse
7.1 Literaturverzeichnis
[DeBono 2006] E. DeBono: Edward DeBono’s Thinking Course: Powerful Tools to
Transform your Thinking. BBC Active, Harlow, 2006.
[Ebert 2012] Systematisches Requirements Engineering: Anforderungen ermitteln,
spezifizieren, analysieren und verwalten. dpunkt-Verlag, Heidelberg, 2012.
[IEEE 610] IEEE Standards Board: IEEE Std 610.12.-1990. IEEE Standard Glossary
of Software Engineering Terminology. IEEE Press, 1990.
[IEEE 830] IEEE Standards Board: IEEE Std 830-1998. IEEE Recommended Prac-
tice for Software Requirements Specification. IEEE Press, 1998.
[OMG 2007] OMG: Unified Modeling Language: Superstructure, Version 2.1.1. OMG
document formal/2007-02-05.
[Pohl 1996] K. Pohl: Process-Centered Requirements Engineering. Research Study
Press, Taunton Somerset, 1996.
[Pohl 2008] K. Pohl: Requirements Engineering: Grundlagen, Prinzipien, Techniken.
dpunkt-Verlag, Heidelberg, 2008.
[Royce 1987] W. W. Royce: Managing the Development of Large Software Systems.
In: Proceedings oft he 9th International Conference on Software Engineering
(ICSE‘87), IEEE Computer Society Press, Los Alamitos, 1987.
[Rupp 2009] C. Rupp, Requirements Engineering und Management: Professionelle,
Iterative Anforderungsanalyse für die Praxis, Carl Hanser Verlag, München Wien,
2009.
[Rupp et al. 2011] C. Rupp, K. Pohl.: Basiswissen Requirements Engineering: Aus-
und Weiterbildung zum Certified Professional for Requirements Engineering
Foundation Level. dpunkt-Verlag, Heidelberg, 2011.
[Schäfer et al. 2011] Marc O. Schäfer, Matthias Melich: SAP Solution Manager. Gali-
leo Press, Bonn, 2011.
75
[Schwaber et al. 2001] K. Schwaber, M. Beedle: Agile Software Development with
Scrum. Prentice Hall, Upper Saddle River, 2011.
[Standish 2011] Standish Group: Chaos Manifesto 2011. The Standish Group Inter-
national, West Yarmouth, USA, 2011, http://www.standishgroup.com.
[V-Modell 2006] V-Modell: V-Modell XT, 2006, Entwicklungsstandard für IT-Systeme
des Bundes: Das V-Modell XT. Webseite, Bundesrepublik Deutschland, 2006.
http://www.cio.bund.de/DE/Architekturen-und-Standards/V-Modell-
XT/vmodell_xt_node.html
76
7.2 Abbildungsverzeichnis
Abbildung 1: Gründe für das Scheitern von IT-Projekten (vgl. [Standish 2011]) ......... 3
Abbildung 2: Arten von Anforderungen ....................................................................... 7
Abbildung 3: Requirements Engineering als abgeschlossene Phase ([Pohl 2008],
S.30) ........................................................................................................................... 9
Abbildung 4: Requirements Engineering als begleitender Prozess ([Pohl 2008], S.31)
................................................................................................................................... 9
Abbildung 5: Vollständige Satzschablone ohne Bedingung ([Rupp 2009], S. 162) ... 17
Abbildung 6: Die vollständige Satzschablone inklusive Bedingung ([Rupp 2009], S.
166) .......................................................................................................................... 18
Abbildung 7: Gesamtbild des RE-Soll Prozesses ..................................................... 34
Abbildung 8: Phase: Aufnahme ................................................................................ 36
Abbildung 9: Phase: Qualitätsprüfung ...................................................................... 39
Abbildung 10: Phase - Konfliktmanagement ............................................................. 41
Abbildung 11: Phase: Aufwandschätzung / Bewertung ............................................ 43
Abbildung 13: Einfaches Spreadsheet-Template für Anforderungen ([Ebert 2012], S.
98) ............................................................................................................................ 47
Abbildung 12: Arten von RE-Werkzeuge .................................................................. 47
Abbildung 14: Screenshot von DOORS - Anforderungen mit den zugehörigen
Attributen ([Ebert 2012], S.337) ................................................................................ 51
Abbildung 15: Verschiedene Sichten auf dasselbe DOORS-Dokument ([Ebert 2012],
S. 338) ...................................................................................................................... 52
Abbildung 16: Konfigurierbare Benutzeroberfläche von Integrity mit Dokumenten- und
Beziehungsansichten ([Ebert 2012], S. 342) ............................................................ 53
Abbildung 17: Lebenszyklus von IT-Lösungen ([Schäfer et al. 2011], S. 30) ........... 57
Abbildung 18: RE-Soll Prozess mit den einzelnen Status und Statusübergängen
(Aktionen) ................................................................................................................. 59
Abbildung 19: Ausschnitt „Aktionsprofil Scharif RE“ ................................................. 63
Abbildung 20: Ausschnitt vom Customizing-Leitfaden .............................................. 64
Abbildung 21: Ausschnitt vom „Statusprofil“ ............................................................. 65
Abbildung 22: Ausschnitt Partnerfunktion definieren ................................................ 65
Abbildung 23: Ausschnitt Partnerschema ZSRE0001 (Scharif RE - Partnerschema) 66
Abbildung 24: Ausschnitt vom Aktionsprofil ZSRE ................................................... 67
77
Abbildung 25: Statusliste mit Initialwerten ................................................................ 67
Abbildung 26: Beispiel für einen Initialwert ............................................................... 67
Abbildung 27: Ausschnitt aus der "Bedingungen definieren" Konfiguration ............. 68
Abbildung 28: Ausschnitt aus dem Menüpunkt "Textfelder definieren" ..................... 69
Abbildung 29: Ausschnitt aus dem RE-Vorgang mit der Auswahl des Sachverhalts 70
Abbildung 30: Ausschnitt aus dem RE-Vorgang mit der Auswahl der Kategorie ...... 70
Abbildung 31: Ausschnitt aus dem Menüpunkt "Kategorien den Vorgangsarten
zuordnen" ................................................................................................................. 71
Abbildung 32: Einstellung im Terminprofil ................................................................. 71
78
7.3 Tabellenverzeichnis
Tabelle 1: Konfliktarten ............................................................................................. 24
Tabelle 2: Konfliktauflösungsmethoden .................................................................... 25
Tabelle 3: Beispiel für eine Attributierung ................................................................. 27
Tabelle 4: Attributliste ............................................................................................... 33
Tabelle 5: Statustabelle ............................................................................................ 62
Tabelle 6: Bezeichnungen vom kopierten Vorgang .................................................. 63
79
7.4 Anhang
Abbildung 33: Einführungsleitfaden (Customizing-Leitfaden) - Teil 1
Abbildung 34: Einführungsleitfaden (Customizing-Leitfaden) - Teil 2
80
Abbildung 35: SAP Menü
Abbildung 36: RE-Vorgang - Teil 1
81
Abbildung 37: RE-Vorgang - Teil 2
Abbildung 38:Vorgang RE - Aufgenommen mit eingeblendeter Aktion
82
Abbildung 39: Vorgang (Anpassung)