Sie sind hier
E-Book

Basiswissen Requirements Engineering

Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level

AutorKlaus Pohl, Chris Rupp
Verlagdpunkt
Erscheinungsjahr2015
Seitenanzahl195 Seiten
ISBN9783864916731
FormatPDF/ePUB
KopierschutzWasserzeichen/DRM
GerätePC/MAC/eReader/Tablet
Preis23,99 EUR
Requirements Engineering (RE) ist eine Schlüsseldisziplin der Systementwicklung und entscheidet maßgeblich über den Erfolg oder Misserfolg eines Projekts. Fachleute, die in diesem Bereich tätig sind, sollten über ein gesichertes RE-Grundlagenwissen verfügen - so wie es im Lehrplan des 'Certified Professional for Requirements Engineering' (CPRE) festgelegt ist.  Entwickelt und eingeführt wurde das CPRE-Zertifikat vom 'International Requirements Engineering Board' (IREB e.V.). Der IREB e.V. setzt sich für die Verbesserung der Requirements-Engineering-Praxis sowie für eine qualitätsgesicherte und standardisierte Aus- und Weiterbildung ein.  Dieses Lehrbuch für die Zertifizierung zum 'Foundation Level' (Version 2.2) des CPRE wurde von IREB-Mitgliedern geschrieben, die an der Entwicklung des Lehrplans beteiligt waren. Es behandelt im Einzelnen die - Ermittlung - Dokumentation - Prüfung und Abstimmung - Verwaltung von Anforderungen sowie die Werkzeugunterstützung. Das Buch eignet sich zur individuellen Vorbereitung auf die Zertifizierungsprüfung und als Begleitliteratur zu den entsprechenden Vorbereitungsschulungen. Die 4. Auflage wurde überarbeitet und ist konform zur aktuellen Ausgabe des IREB-Lehrplans Foundation Level Version 2.2. Über dem Leserkasten: Ergänzende Informationen zum Buch, zum IREB e.V. und zum CPRE finden sich unter: http://www.certified-re.de.

Prof. Dr. Klaus Pohl ist Professor für Software Systems Engineering und Direktor von 'paluno - The Ruhr Institute for Software Technology' an der Universität Duisburg-Essen. Er ist bzw. war Koordinator von mehreren internationalen und nationalen Forschungsprojekten, Vorsitzender des Programmkomitees und 'General Chair' von nationalen und internationalen Konferenzen und ist (Co-)Autor von mehr als 250 begutachteten Publikationen. Als Berater unterstützt er Industrieunternehmen und öffentliche Organisationen darin, die Requirements-Engineering-Prozesse in der Praxis weiter zu verbessern. Chris Rupp OberSOPHISTin (formal: Gründerin und geschäftsführende Gesellschafterin), Chefberaterin, Coach und Trainerin. In 25 Jahren Berufstätigkeit sammelt sich so einiges an ... ein Unternehmen ... 6 Bücher ... 55 Mitarbeiter ... ungezählte Artikel und Vorträge ... und unheimlich viel Erfahrung. Meine Leidenschaft für die Projektberatung ist vermutlich schuld daran, dass ich bis heute nicht 'nur' manage, sondern auch ganz nah am Kunden bin, in Projekten mitarbeite. Gute Ideen so umzusetzen, dass Entwickler, Vertragspartner, direkt und indirekt betroffene Anwender das Gefühl haben, ein intelligentes, durchdachtes und nutzbringendes Produkt vor sich zu haben, ist die Vision die mich dabei antreibt. Dabei arbeite ich mit unterschiedlichsten Methoden und Ansätzen aus dem agilen und nicht agilen Bereich. Um die Qualifikation der Requirements-Engineers/Business-Analysten zu vereinheitlichen habe ich den IREB e. V. (International Requirements Engineering Board) gegründet. Mehr Infos über mich finden Sie unter www.sophist.de. Chris Rupp ist Autorin vieler Bücher, unter anderem 'Requirements-Engineering und -Management' (Carl Hanser Verlag München 2014) und 'UML2 glasklar' (Carl Hanser Verlag München 2012).

Kaufen Sie hier:

Horizontale Tabs

Leseprobe

1 Einleitung und Grundlagen


Die Bedeutung des Requirements Engineering (RE) für die erfolgreiche, den Kunden zufriedenstellende Entwicklung von Systemen ist mittlerweile kaum mehr zu übersehen. In der Praxis ist es üblich, einen entsprechenden Aufwand für das Requirements Engineering einzuplanen. Immer häufiger findet man zudem die Erkenntnis, dass der Requirements Engineer eine eigenständige Rolle mit anspruchsvollen Tätigkeiten ist.

1.1 Einleitung


Wozu Requirements Engineering?

Glaubt man den Zahlen im Chaos Report 2006 der Standish Group, so hat sich in den zwölf Jahren zwischen 1994 und 2006 bei der erfolgreichen Abwicklung von Softwareprojekten einiges zum Besseren gewendet. Sind im Jahre 1994 noch gut 30% der untersuchten Softwareprojekte gescheitert, so waren es 2006 nur noch knapp 20%. Die Anzahl der Projekte, die mit starken Zeit- oder Budgetüberziehungen und/oder nicht zur Zufriedenheit der Kunden abgeschlossen werden konnten, verringerte sich von 53% auf 46% [Chaos 2006]. Jim Johnson, Vorsitzender der Standish Group, nennt als einen von drei Gründen für die positive Entwicklung der Zahlen seit 1994 die Tatsache, dass Anforderungen besser kommuniziert würden als noch vor zehn Jahren. Interessant sind diese Zahlen, da der Umgang mit Anforderungen eines Systems eine signifikante Ursache für Projektfehlschläge bzw. für Zeit- und Budgetüberschreitungen darstellt.

1.1.1 Zahlen und Fakten im Projektalltag

Requirements Engineering als Fehlerquelle

Studien belegen, dass etwa 60% der Fehler in Systementwicklungsprojekten bereits im Requirements Engineering entstehen [Boehm 1981]. Irrtümer aus dem Requirements Engineering werden jedoch oft erst in späteren Projektphasen oder im Betrieb des Systems entdeckt, da fehlerhafte oder unvollständige Anforderungen für Entwickler so interpretiert werden können, dass sie subjektiv schlüssig sind oder aus der subjektiven Perspektive der Entwickler (unbewusst) vervollständigt werden. Fehlende Anforderungen werden im Entwurf und in der Realisierung häufig nicht entdeckt, da man sich hier auf die qualitativ hochwertige Arbeit des Requirements Engineer verlässt. Es wird umgesetzt, was man aus dem Anforderungsdokument entnehmen kann oder glaubt, entnehmen zu können. Missverständliche, unvollständige oder falsche Anforderungen führen somit unausweichlich zu einem System, das wichtige Eigenschaften nicht besitzt oder Eigenschaften aufweist, die nicht gefordert wurden.

Kosten von Fehlern im Requirements Engineering

Je später ein Fehler in den Anforderungen im Verlauf des Entwicklungsprojekts behoben wird, umso höher sind die damit verbundenen Kosten. So wird beispielsweise für die Beseitigung eines Anforderungsfehlers, der erst beim Programmieren entdeckt wird, ein um ca. den Faktor 20 höherer Aufwand notwendig, als wenn derselbe Fehler während des Requirements Engineering behoben worden wäre – für die Fehlerbeseitigung in der Abnahmephase des Systems geht man von dem Faktor 100 aus [Boehm 1981].

Symptome und Gründe für mangelhaftes Requirements Engineering

Symptome für mangelhaftes Requirements Engineering sind ebenso zahlreich wie ihre Ursachen. Häufig fehlen Anforderungen oder sie sind unklar formuliert. Wenn beispielsweise die Anforderungen nicht genau den Kundenwunsch widerspiegeln oder die Anforderungen zu ungenau beschrieben und damit verschiedenartig interpretierbar sind, hat dies häufig zur Folge, dass das erstellte System nicht den Erwartungen der Auftraggeber bzw. Nutzer entspricht.

Der häufigste Grund für fehlerhafte Anforderungen ist die falsche Annahme der Stakeholder, dass vieles selbstverständlich ist und nicht explizit genannt werden muss. Es entstehen Kommunikationsprobleme zwischen den Beteiligten, die oft aus unterschiedlichem Erfahrungs- bzw. Wissenstand resultieren. Erschwerend kommt hinzu, dass besonders der Auftraggeber in vielen Fällen kurzfristige Ergebnisse in Form eines produktiven Systems erhalten möchte.

Die Bedeutsamkeit von gutem Requirements Engineering

Die steigende Bedeutung von Systemen mit einem signifikanten Softwareanteil in industriellen Projekten sowie die Notwendigkeit, innovativere, individuellere und umfangreichere Systeme schneller, besser und mit höchster Qualität auf den Markt zu bringen, setzen ein leistungsfähiges Requirements Engineering voraus. Fehlerfreie und vollständige Anforderungen sind die Basis für eine erfolgreiche Systementwicklung. Bereits im Requirements Engineering müssen potenzielle Risiken aufgedeckt und soweit möglich behoben werden, um einen erfolgreichen Projektablauf zu ermöglichen. Fehler und Lücken in Anforderungsdokumenten müssen frühzeitig erkannt werden, um langwierige Änderungsprozesse zu vermeiden.

1.1.2 Requirements Engineering – was ist das?

Um ein Entwicklungsprojekt zum Erfolg führen zu können, muss zunächst bekannt sein, was die Anforderungen an das System sind, und diese müssen geeignet dokumentiert sein.

Definition 1–1: Anforderung

Eine Anforderung ist:

(1) Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur 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).

Übersetzt aus [IEEE Std 610.12-1990]

Stakeholder

Der Stakeholder (Projektbetroffener) ist einer der zentralen Begriffe im Requirements Engineering. Stakeholder dienen u.a. als wichtigste Quellen für Anforderungen, und das Übersehen eines Stakeholders hat häufig zur Konsequenz, dass die ermittelten Anforderungen an das System lückenhaft sind [Macaulay 1993]. Stakeholder sind also alle diejenigen Personen oder Organisationen, die Anforderungen in irgendeiner Weise beeinflussen. Das können natürliche Personen sein, die das System später nutzen werden (z.B. der Nutzer oder der Administrator), natürliche Personen, die Interesse an dem System haben, es aber nicht nutzen werden oder sollen (z.B. das Management oder ein Hacker, vor dem man das System schützen muss), aber auch juristische Personen, Institutionen usw., da diese letztlich durch natürliche Personen vertreten werden, die die Anforderungen des betrachteten Systems beeinflussen bzw. definieren können.

Definition 1–2: Stakeholder

Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.

Ziel des Requirements Engineering

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 gesamten Lebenszyklus des Systems hinweg zu verwalten [Pohl 1996].

Definition 1–3: Requirements Engineering

Das Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation 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 vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.

(2) Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren 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.

Vier Haupttätigkeiten im Requirements Engineering

Die vier damit einhergehenden Haupttätigkeiten sind:

  • Ermitteln:

    Beim Ermitteln der Anforderungen werden verschiedene Techniken genutzt, um die Anforderungen der Stakeholder und anderer Quellen zu gewinnen, zu detaillieren und zu verfeinern (siehe Kapitel 3).

  • Dokumentieren:

    Durch die Dokumentation werden erarbeitete Anforderungen adäquat beschrieben. Hierfür können unterschiedliche Techniken eingesetzt werden, um Anforderungen in natürlicher Sprache oder in Modellen zu dokumentierten (siehe Kapitel 4, 5, 6).

  • Prüfen und abstimmen:

    Dokumentierte Anforderungen müssen frühzeitig geprüft und abgestimmt werden, um zu gewährleisten, dass sie allen geforderten Qualitätskriterien genügen (siehe Kapitel 7).

  • Verwalten:

    Die Anforderungsverwaltung (Requirements Management) geschieht flankierend zu allen anderen Aktivitäten und umfasst alle Maßnahmen, die notwendig sind, um Anforderungen zu strukturieren, für unterschiedliche Rollen aufzubereiten sowie konsistent zu ändern und umzusetzen (siehe Kapitel...

Blick ins Buch
Inhaltsverzeichnis
Inhaltsverzeichnis15
1 Einleitung und Grundlagen21
1.1 Einleitung21
1.1.1 Zahlen und Fakten im Projektalltag21
1.1.2 Requirements Engineering – was ist das?23
1.1.3 Einbettung des Requirements Engineering in Vorgehensmodelle25
1.2 Kommunikationstheoretische Grundlagen26
1.3 Eigenschaften eines Requirements Engineer27
1.4 Arten von Anforderungen28
1.5 Bedeutung und Kategorisierung von Qualitätsanforderungen30
1.6 Zusammenfassung31
2 System und Systemkontext abgrenzen33
2.1 Systemkontext33
2.2 System- und Kontextgrenzen bestimmen34
2.2.1 Die Systemgrenze festlegen35
2.2.2 Die Kontextgrenze bestimmen38
2.3 Den Systemkontext dokumentieren39
2.4 Zusammenfassung40
3 Anforderungen ermitteln41
3.1 Anforderungsquellen41
3.1.1 Stakeholder und deren Bedeutung42
3.1.2 Der Umgang mit Stakeholdern im Projekt42
3.2 Anforderungskategorisierung nach dem Kano-Modell44
3.3 Ermittlungstechniken46
3.3.1 Arten von Ermittlungstechniken46
3.3.2 Befragungstechniken47
3.3.3 Kreativitätstechniken48
3.3.4 Dokumentenzentrierte Techniken50
3.3.5 Beobachtungstechniken51
3.3.6 Unterstützende Techniken52
3.4 Zusammenfassung53
4 Anforderungen dokumentieren55
4.1 Dokumentgestaltung55
4.2 Arten der Dokumentation56
4.2.1 Die drei Perspektiven von Anforderungen57
4.2.2 Dokumentation von Anforderungen in natürlicher Sprache57
4.2.3 Dokumentation von Anforderungen durch konzeptuelle Modelle58
4.2.4 Mischform von Anforderungsdokumenten59
4.3 Dokumentenstrukturen59
4.3.1 Standardisierte Dokumentenstrukturen59
4.3.2 Angepasste Standardinhalte61
4.4 Verwendung von Anforderungsdokumenten63
4.5 Qualitätskriterien für das Anforderungsdokument64
4.5.1 Eindeutigkeit und Konsistenz65
4.5.2 Klare Struktur65
4.5.3 Modifizierbarkeit und Erweiterbarkeit65
4.5.4 Vollständigkeit66
4.5.5 Verfolgbarkeit (Traceability)66
4.6 Qualitätskriterien für Anforderungen67
4.7 Glossar69
4.8 Zusammenfassung71
5 Anforderungen natürlichsprachig dokumentieren73
5.1 Sprachliche Effekte73
5.1.1 Nominalisierung74
5.1.2 Substantive ohne Bezugsindex75
5.1.3 Universalquantoren75
5.1.4 Unvollständig spezifizierte Bedingungen76
5.1.5 Unvollständig spezifizierte Prozesswörter77
5.2 Konstruktion von Anforderungen mittels Satzschablone77
5.3 Zusammenfassung81
6 Anforderungen modellbasiert dokumentieren83
6.1 Der Modellbegriff83
6.1.1 Eigenschaften von Modellen84
6.1.2 Konzeptuelle Modellierungssprachen85
6.1.3 Anforderungsmodelle85
6.1.4 Vorteile von Anforderungsmodellen86
6.1.5 Kombinierter Einsatz von Anforderungsmodellen und natürlicher Sprache86
6.2 Zielmodelle87
6.2.1 Zieldokumentation mit Und-Oder-Bäumen87
6.2.2 Beispiel für Und-Oder-Bäume88
6.3 Use Cases89
6.3.1 UML-Use-Case-Diagramme89
6.3.2 Use-Case-Spezifikationen92
6.4 Drei Perspektiven auf die Anforderungen95
6.5 Anforderungsmodellierung in der Strukturperspektive96
6.5.1 Entity-Relationship-Diagramme97
6.5.2 UML-Klassendiagramme99
6.6 Anforderungsmodellierung in der Funktionsperspektive102
6.6.1 Datenflussdiagramme102
6.6.2 Modelle der Funktionsperspektive und Kontrollfluss104
6.6.3 UML-Aktivitätsdiagramme105
6.7 Anforderungsmodellierung in der Verhaltensperspektive109
6.7.1 Statecharts109
6.7.2 UML-Zustandsdiagramm111
6.8 Zusammenfassung114
7 Anforderungen prüfen und abstimmen115
7.1 Grundlagen der Prüfung von Anforderungen115
7.2 Grundlagen der Abstimmung von Anforderungen116
7.3 Qualitätsaspekte für Anforderungen117
7.3.1 Qualitätsaspekt »Inhalt«118
7.3.2 Qualitätsaspekt »Dokumentation«119
7.3.3 Qualitätsaspekt »Abgestimmtheit«120
7.4 Prinzipien der Prüfung von Anforderungen121
7.4.1 Prinzip 1: Beteiligung der richtigen Stakeholder121
7.4.2 Prinzip 2: Trennung von Fehlersuche und Fehlerkorrektur122
7.4.3 Prinzip 3: Prüfung aus unterschiedlichen Sichten122
7.4.4 Prinzip 4: Geeigneter Wechsel der Dokumentationsform123
7.4.5 Prinzip 5: Konstruktion von Entwicklungsartefakten123
7.4.6 Prinzip 6: Wiederholte Prüfung123
7.5 Techniken zur Prüfung von Anforderungen124
7.5.1 Stellungnahme124
7.5.2 Inspektion125
7.5.3 Walkthrough126
7.5.4 Perspektivenbasiertes Lesen127
7.5.5 Prüfung durch Prototypen129
7.5.6 Einsatz von Checklisten in der Prüfung131
7.6 Abstimmung von Anforderungen132
7.6.1 Konfliktidentifikation132
7.6.2 Konfliktanalyse133
7.6.3 Konfliktauflösung134
7.6.4 Dokumentation der Konfliktlösung136
7.7 Zusammenfassung137
8 Anforderungen verwalten139
8.1 Attributierung von Anforderungen139
8.1.1 Attributierung von natürlichsprachigen Anforderungen und Anforderungsmodellen139
8.1.2 Attributierungsschema140
8.1.3 Attributtypen für Anforderungen141
8.2 Sichten auf Anforderungen143
8.2.1 Selektive Sichten auf die Anforderungsbasis144
8.2.2 Verdichtende Sichten auf die Anforderungsbasis145
8.3 Priorisierung von Anforderungen146
8.3.1 Vorgehen zur Priorisierung von Anforderungen146
8.3.2 Techniken zur Priorisierung von Anforderungen147
8.4 Verfolgbarkeit von Anforderungen150
8.4.1 Nutzen der Verfolgbarkeit von Anforderungen151
8.4.2 Verwendungszweckbezogene Definition der Verfolgbarkeit152
8.4.3 Klassifikation von Verfolgbarkeitsbeziehungen152
8.4.4 Repräsentation der Verfolgbarkeit von Anforderungen154
8.5 Versionierung von Anforderungen156
8.5.1 Versionen von Anforderungen157
8.5.2 Konfigurationen von Anforderungen158
8.5.3 Anforderungsbasislinien159
8.6 Verwaltung von Anforderungsänderungen160
8.6.1 Anforderungsänderungen160
8.6.2 Das Change-Control Board161
8.6.3 Der Änderungsantrag162
8.6.4 Klassifikation eingehender Änderungsanträge163
8.6.5 Prinzipielles Vorgehen bei korrektiven und adaptiven Änderungen164
8.7 Messung von Anforderungen166
8.7.1 Produkt- vs. Prozessmetriken166
8.7.2 Beispiele für Metriken166
8.8 Zusammenfassung167
9 Werkzeugunterstützung169
9.1 Allgemeine Werkzeugunterstützung169
9.2 Modellierungswerkzeuge170
9.3 Requirements-Management-Werkzeuge171
9.3.1 Spezialisierte Werkzeuge für das Requirements Management172
9.3.2 Standard-Büroanwendungen173
9.4 Werkzeugeinführung173
9.5 Beurteilung von Werkzeugen175
9.5.1 Projektsicht176
9.5.2 Benutzersicht176
9.5.3 Produktsicht177
9.5.4 Prozesssicht177
9.5.5 Anbietersicht177
9.5.6 Technische Sicht178
9.5.7 Betriebswirtschaftliche Sicht178
9.6 Zusammenfassung178
Literatur179
www.dpunkt.de0

Weitere E-Books zum Thema: eBusiness - Marketing - Advertising

Software in 30 Tagen

E-Book Software in 30 Tagen

Mit Scrum lässt sich bei der Softwareentwicklung flexibel auf veränderte Marktbedingungen reagieren. Noch während der Entwicklung können neue Erkenntnisse in die weitere Planung integriert ...

Projekt Phoenix

E-Book Projekt Phoenix

Bill ist IT-Manager bei Parts Unlimited. An einem Dienstagmorgen erhält er auf der Fahrt zur Arbeit einen Anruf seines CEO. Die neue IT-Initiative der Firma mit dem Codenamen Projekt Phoenix ist ...

Projektmanagement mit Merlin

E-Book Projektmanagement mit Merlin

Immer mehr Anwender wählen bei der Neuanschaffung eines PC einen Mac. Diese Entwicklung macht auch vor Unternehmen nicht halt. Eine der zentralen Aufgaben im beruflichen Umfeld ist zweifellos ...

Weitere Zeitschriften

Berufsstart Gehalt

Berufsstart Gehalt

»Berufsstart Gehalt« erscheint jährlich zum Sommersemester im Mai mit einer Auflage von 50.000 Exemplaren und ermöglicht Unternehmen sich bei Studenten und Absolventen mit einer ...

BONSAI ART

BONSAI ART

Auflagenstärkste deutschsprachige Bonsai-Zeitschrift, basierend auf den renommiertesten Bonsai-Zeitschriften Japans mit vielen Beiträgen europäischer Gestalter. Wertvolle Informationen für ...

Burgen und Schlösser

Burgen und Schlösser

aktuelle Berichte zum Thema Burgen, Schlösser, Wehrbauten, Forschungsergebnisse zur Bau- und Kunstgeschichte, Denkmalpflege und Denkmalschutz Seit ihrer Gründung 1899 gibt die Deutsche ...

Courier

Courier

The Bayer CropScience Magazine for Modern AgriculturePflanzenschutzmagazin für den Landwirt, landwirtschaftlichen Berater, Händler und generell am Thema Interessierten, mit umfassender ...

küche + raum

küche + raum

Internationale Fachzeitschrift für Küchenforschung und Küchenplanung. Mit Fachinformationen für Küchenfachhändler, -spezialisten und -planer in Küchenstudios, Möbelfachgeschäften und den ...

Demeter-Gartenrundbrief

Demeter-Gartenrundbrief

Einzige Gartenzeitung mit Erfahrungsberichten zum biologisch-dynamischen Anbau im Hausgarten (Demeter-Anbau). Mit regelmäßigem Arbeitskalender, Aussaat-/Pflanzzeiten, Neuigkeiten rund um den ...

VideoMarkt

VideoMarkt

VideoMarkt – besser unterhalten. VideoMarkt deckt die gesamte Videobranche ab: Videoverkauf, Videoverleih und digitale Distribution. Das komplette Serviceangebot von VideoMarkt unterstützt die ...

Evangelische Theologie

Evangelische Theologie

 Über »Evangelische Theologie« In interdisziplinären Themenheften gibt die Evangelische Theologie entscheidende Impulse, die komplexe Einheit der Theologie wahrzunehmen. Neben den ...