analyse und bewertung eines requirements engineering ... · zusammenfassung ein lokales unternehmen...

Gottfried Wilhelm

Leibniz Universität Hannover

Fakultät für Elektrotechnik und Informatik

Institut für Praktische Informatik

Fachgebiet Software Engineering

Analyse und Bewertung eines

Requirements Engineering Prozesses in

einem lokalen Unternehmen

Diplomarbeit

im Studiengang Mathematik mit Studienrichtung Informatik

von

Konstanze Krüger

Prüfer: Prof. Dr. Kurt Schneider

Zweitprüfer: Prof. Dr. HeribertVollmer

Betreuer: Raphael Pham, Eike Michel

Hannover, 10. Mai 2012

Zusammenfassung

Ein lokales Unternehmen arbeitet nach einem auf Erfahrung basierenden, historischgewachsenen Requirements Engineering Prozess(REP) um Anforderungen zu entdecken,zu analysieren und umzusetzen. Dieser REP ist nicht lückenlos de�niert. Eine Analysewurde durchgeführt, um Schwachstellen und Verbesserungspotential aufzudecken.

Wichtigster Punkt ist die häu�g unvollständige und unverständliche Dokumentationvon Anforderungen und die daraus resultierenden Rückfragen durch Entwickler. Diesekosten Zeit und damit Geld. Die folgenden zwei Maÿnahmen zur Qualitätsverbesserungwurden behandelt: Entwicklung eines Fragenkatalogs auf Grundlage eines Qualitätsmo-dells. Dieser wurde unter den Mitarbeitern evaluiert. Weiterhin wurde ein Vorgehenzur Anforderungsdokumentation mit einer Anforderungsschablone und das REgelwerk -ein Regelwerk für RE - vorgestellt. Verbesserungsvorschläge für weitere Schwachstellenwurden erläutert.

Im dritten Teil der Arbeit wurden Vorschläge zur Strukturierung der groÿen Menge anAnforderungen erarbeitet. Durch Verlinkungen der Anforderungen untereinander wirddie Übersichtlichkeit erhöht.

Ziel aller Maÿnahmen ist eine E�ektivitätssteigerung des PEP, damit das jahrelangeWachstum fortgesetzt werden kann: weniger Rückfragen durch die Entwickler, klarde�nierte Arbeitsabläufe, bessere Übersicht über alle o�enen Kundenwünsche und eineschnellere Einarbeitung neuer Mitarbeiter anhand der Prozessdokumentation.

Abstract

A local company uses a Requirements Engineering Process (REP) in order to discover,analyse and instantiate requirements. The process was developed on the basis of expe-rience over years and therefore lacks in a thorough and consistent concept. An analysiswas conducted in order to detect weaknesses and strategies for improving the process.

The most important weakness is the incomplete and incomprehensible documentationof requirements, which creates confusion among the developers and thus slows down theworking process. The following two major measures were taken in order to improve thequality of the REP: �rst of all a check-list for documents, which is based upon a modelof quality aspects, was developed and evaluated by company's employees. Furthermore atemplate for writing documents and a system of rules (the REgelwerk) was introduced.In addition to that, possibilities to handle other weak points are discussed in this paper.

The third part of the thesis contains suggestions on how to handle the large amountof requirements. One idea is to link requirements among each other and thus establishmore clarity in the process.

The aim of all measures is to increase the e�ciency of the REP, which can be determinedby the following sub-goals: less questions or confusion among the developers, a betteroverview of all open customer requests, a clearly de�ned work�ow and a faster familiari-sation of the REP for new employees with the help of the developed documentation.

iii

Inhaltsverzeichnis

1. Motivation und Ziele 1

2. Das lokale Unternehmen 32.1. Selbstdarstellung und Produktpalette . . . . . . . . . . . . . . . . . . . . 32.2. Wirtschaftliche Positionierung . . . . . . . . . . . . . . . . . . . . . . . 32.3. Mitarbeiterstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3. IST-Analyse 53.1. Chronologische Prozessbeschreibung . . . . . . . . . . . . . . . . . . . . 5

3.1.1. Quellen der Anforderungen . . . . . . . . . . . . . . . . . . . . . 53.1.2. Eintrag in der Approach DB . . . . . . . . . . . . . . . . . . . . . 73.1.3. Erstellung einer Anforderungsbeschreibung . . . . . . . . . . . . 73.1.4. Priorisierung und Projektplan . . . . . . . . . . . . . . . . . . . . 83.1.5. Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.6. Test und Auslieferung . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2. Entwicklungszyklen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3. Dokumente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.1. Einträge in der Approach DB . . . . . . . . . . . . . . . . . . . . 103.3.2. FeatureSpeci�cation . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.3. ImplementationConcept . . . . . . . . . . . . . . . . . . . . . . . 153.3.4. TestManual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.5. ToDo-Liste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4. Das Priorisierungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . 173.4.1. Die Bewertungmatrix . . . . . . . . . . . . . . . . . . . . . . . . 173.4.2. Die Gewichtungsmatrix . . . . . . . . . . . . . . . . . . . . . . . 19

3.5. Rollenbasierte Prozessbeschreibung . . . . . . . . . . . . . . . . . . . . . 203.5.1. Aufgaben der Rollen . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.2. Zuordnung der beteiligten Rollen zu den Abteilungen . . . . . . . 22

3.6. Quality Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.7. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4. Der Team Foundation Server 254.1. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2. Folgen der Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5. Anforderungen an Anforderungen 315.1. Qualitätskriterien für Anforderungen . . . . . . . . . . . . . . . . . . . . 315.2. Der Fragenkatalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

v

Inhaltsverzeichnis

5.2.1. Die Fragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.2. Begründung und Messbarkeit der Fragen . . . . . . . . . . . . . . 34

5.3. Bestimmung und Verbesserung der Qualität natürlichsprachlicher Doku-mente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.1. ... mit MS Word . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.2. ... mit einem Lesbarkeitsindex . . . . . . . . . . . . . . . . . . . . 415.3.3. ... mit einer lexikalischen, syntaktischen und semantischen Text-

analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3.4. ...über ein Template . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.5. Sechs Schritte für gute Anforderungsbeschreibungen . . . . . . . 465.3.6. Erweiterung der Schablone . . . . . . . . . . . . . . . . . . . . . . 495.3.7. Das SOPHIST REgelwerk . . . . . . . . . . . . . . . . . . . . . . 51

5.4. Negativbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.5. Evaluation des Fragekatalogs . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5.1. Aufbau und Inhalt der Evaluation . . . . . . . . . . . . . . . . . 605.5.2. Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6. Strukturierung der Anforderungen untereinander 656.1. Bisherige Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1.1. WAR-Zustand: Approach DB . . . . . . . . . . . . . . . . . . . . 656.1.2. IST-Zustand: Team Foundation Server . . . . . . . . . . . . . . . 66

6.2. Regeln zur Strukturierung . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2.1. Parent-Child-Hierarchien . . . . . . . . . . . . . . . . . . . . . . 706.2.2. Nachfolger/Vorfahren . . . . . . . . . . . . . . . . . . . . . . . . 736.2.3. A�ects/A�ected By . . . . . . . . . . . . . . . . . . . . . . . . . 736.2.4. Related . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.2.5. Einführung des Verlinkungstypen Themenkomplex/Anforderung 746.2.6. Kombination verschiedener Linktypen . . . . . . . . . . . . . . . 776.2.7. De�nition neuer Verlinkungstypen . . . . . . . . . . . . . . . . . 77

7. Zusammenfassung und Ausblick 79

A. Glossar 81

B. Umfragebogen zum Fragenkatalog für KundenPL 83

C. Datensatz zur Umfrage 89

Literaturverzeichnis 91

Erklärung der Selbstständigkeit 93

vi

1. Motivation und Ziele

Grundlage der vorliegenden Arbeit ist eine Anfrage der Firma TOUCCEA an dasFachgebiet Software Engineering der Leibniz Universität Hannover. Eine Analyse desRequirement Engineering Prozesses soll Schwachstellen zeigen. Anschlieÿend werdenVerbesserungsmöglichkeiten diskutiert. Der Hintergrund ist folgender: TOUCCEA istein aufstrebendes mittelständiges Unternehmen aus der Region Hannover. Viele Mit-arbeiter sind bereits seit Jahren in der Firma, sodass viele Abläufe erfahrungsbasiertsta��nden. Ein lückenlos de�nierter Requirements Engineering Prozess liegt nicht vor.Auf Grund der guten wirtschaftlichen Entwicklung wurden und werden viele neue Mitar-beiter eingestellt. Diese neuen Kollegen verfügen verständlicherweise nicht über dieselbejahrelange Erfahrung. Um ihnen die Einarbeitung zu erleichtern, werden die Prozesseanalysiert und dokumentiert.

Parallel wurde von einem Mitarbeiter des Fachgebiets Software Engineering - RaphaelPham - ein Prozessmodell mit der FLOW-Methode erstellt. Basierend auf sechs Mitar-beiterinterviews wurde eine gra�sche Darstellung der Prozesse entwickelt. Die Prozess-analyse der vorliegenden Arbeit beruht auf diesen Interviews und auf weiteren Quellen:interne Dokumentation, (informelle) Gespräche mit weiteren Mitarbeitern und die Teil-nahme an Meetings. Damit konnten weitere Aspekte betrachtet werden, beispielsweiseUnterschiede zwischen dem tatsächlichen Geschehen und dem de�nierten Prozess.

Während der Analyse zeigten sich Schwachstellen bzw. Verbesserungspotentiale beiden Arbeitsabläufen. Für einige davon werden Verbesserungsvorschläge diskutiert. ZumBeispiel gibt es starke Qualitätssschwankungen bei den Dokumente zur Anforderungs-beschreibung. Gegenmaÿnahmen wie eine Schablone zur Anforderungsdokumentationwerden vorgestellt. Ein Fragenkatalog als unterstützende Handreichung für die Autorender Anforderungsdokumente wird entwickelt.

Ein weiteres Kapitel dieser Arbeit beinhaltet ein mögliches Konzept zur Handhabungder groÿen Menge an Anforderungen. Grundlage dafür war die Einführung eines neuenProjektmanagementtools, dem Team Foundation Server. Anforderungen können unter-einander verlinkt werden. Werden beispielsweise Gruppen ähnlicher Kundenwünschegebildet, erhöht sich die Übersichtlichkeit.

Hiermit möchte ich mich ganz herzlich bei meinen Betreuern für die gute Begleitungbedanken: Herrn Eike Michel, TOUCCEA und Herrn Raphael Pham, Fachgebiet fürSoftware Engineering!

Abschlieÿend muss gesagt werden, dass zur Verbesserung der Lesbarkeit grundsätzlichdas generische Maskulinum verwendet wird. Damit sollen sich ausdrücklich sowohl Män-ner wie auch Frauen angesprochen fühlen.

1

1. Motivation und Ziele

2

2. Das lokale Unternehmen

2.1. Selbstdarstellung und Produktpalette

Bei dem �lokalen Unternehmen�, das in dieser Arbeit untersucht wird, handelt es sichum die 1985 gegründete TOUCCEA1 mit Hauptsitz in Hannover. Die sich selbst sobeschreibt:�TOUCCEA entwickelt Engineering Software für den gesamten Lebenszyklus von Maschi-nen, Anlagen und mobilen Systemen.TOUCCEA-Lösungen reichen vom Flieÿbild über die Leit- und E-Technik in Groÿanla-gen bis zum modularen Bordnetz in der Automobilindustrie.TOUCCEA scha�t die Verknüpfung von Unternehmensprozessen durch seine einzigar-tige Kooperationsplattform. �Das Unternehmen bietet seinen Kunden eine E�zienzsteigerung durch automatisiertesEnginieering. Das Hauptprodukt ist die Plattform2. Weitere Produkte mit deutlichgeringerer Bedeutung, aber mit ähnlichen Zielen und Möglichkeiten, sind vorhanden.Mit diesen Produkten kann der gesamte Lebenszyklus von Maschinen, Anlagen undmobilen Systemen begleitet werden. So reichen die TOUCCEA-Lösungen vom Flieÿbildin Groÿanlagen bis hin zu zweidimensionalen Aufbauplänen für Schaltschränke. Die Ver-kabelung eines Autos kann zunächst am Computer geplant werden. Dann berechnet diePlattform die Länge der jeweils benötigten Kabel. Auf Grundlage dieser Berechnungenkann eine Maschine die Kabel schneiden. Die Logistiker bestellen daraufhin die benötigteMenge bei einem Zulieferer. Die TOUCCEA-Lösungen können auch zur Dokumentationgenutzt werden, sowie ein Teil des Qualitätsmanagement sein. Mit dieser Verknüpfungvon verschiedenen Unternehmensprozessen hat TOUCCEA eine einzigartige Koopera-tionsplattform gescha�en. Dieser Ansatz spiegelt sich in ihrem Motto wieder: CreateSynergy - Connect Processes. Alle Produkte sind so gestaltet, dass sie �exibel und an-passungsfähig sind, um die Wünsche der Kunden optimal umzusetzen. Die Produktewerden durch regelmäÿige Feedbackschleifen mit den Kunden ständig verbessert. DiePlattform von TOUCCEA arbeitet ausschlieÿlich auf dem Betriebssystem Windows.Weitere Microsoftpodukte wie Visio und Excel sind Grundpfeiler der Plattform.

2.2. Wirtschaftliche Positionierung

Seit den Gründungszeiten wurde aus dem Nischenanbieter ein Generalist mit Markt-führerschaft. Als ehrgeizige Ziele stehen bis 2015 die Verdopplung des Umsatzes (2010:

1Aus Datenschutzgründen wird dieser Phantasiename verwendet. Der korrekte Name ist dem Autorbekannt.

2siehe Anmerkung zum Firmennamen

3

2. Das lokale Unternehmen

26,5 Millionen Euro) und eine Mitarbeitersteigerung um 50% auf mehr als 220 Personenan. Das Unternehmen ist Inhabergeführt und existiert als Aktiengesellschaft ohne freihandelbare Anteile.Im Vergleich zur Konkurrenz ist TOUCCEA branchenübergreifend aufgestellt. So wirddie Plattform in vier Versionen verkauft: Power, Instrumentation, Cable und Electrical.Allen gemein ist ein �Kern� auf dem die Anpassungen für den jeweiligen Sektor auf-bauen. Die Spanne der Anwendungen ist folglich sehr groÿ und reicht vom Kraftwerk,Anlagen zur Produktion von Zement oder Öl über Auto-, Satelliten- und Panzerbau biszu Schaltschränken für den Maschinenbau. Zusammengenommen kommt TOUCCEA soauf 1000 bis 1500 Kunden mit ca. 30.000 Plattform-Installationen. Zu den Kunden vonTOUCCEA zählen u.a. RWE, VW, die Flughafen Wien AG, die Kanzler Verfahren-stechnik und die Daimler AG.In den letzten Jahren wurde eine Verschiebung des Firmenschwerpunktes vorgenommen.Dabei wurden groÿe Potentiale in gewerbeübergreifenden Bereichen aufgeschlossen. Zeit-gleich trat das reine Elektro-Engineering in den Hintergrund. Die Altprodukte werdenaktuell nur geringfügig weiterentwickelt, da das Hauptaugenmerk auf der Plattform liegt.

Durch die Fülle von Anwendern schwankt die Lebensdauer, Aktualisierunsmöglichkeiten,sowie die Test- und Wartbarkeit sehr. Ein Kraftwerk hat eine groÿe Laufzeit von bis zu30 Jahren. Regelmäÿige Wartungsarbeiten werden durchgeführt. Dabei ist es möglich,Aktualisierungen vorzunehmen. Allerdings sind keine Tests an Prototypen möglich, dadies zu teuer wäre. Im Satellitenbau werden ebenfalls wenige Exemplare hergestellt,damit sind Tests im Vorfeld schwer möglich. Ein einmal gestarteter Satellit kann aller-dings nicht mehr gewartet und aktualisiert werden. Im Autobau wiederum gibt es voneinem entwickelten Produkt sehr viele Exemplare. Diese können gut gewartet werden,haben eine vergleichsweise kurze Lebensdauer und werden nicht aktualisiert. Ein Pro-totypenbau ist üblich und kann mehrfach erfolgen.Allen Kunden bietet TOUCCEA qualitativ hochwertige Lösungen.

2.3. Mitarbeiterstruktur

Die Firma hat 166 Mitarbeiter, davon etwa 50 in der Entwicklung. Sie verteilen sichim deutschsprachigen Raum auf die Hauptstandorte in Hannover und Frankfurt, sowieNiederlassungen in Konstanz und Salzburg. Im weltweiten Kontext arbeitet die Firmamit Tochterunternehmen, Vertriebspartnern und Dienstleistern zusammen. TOUCEAhat Kunden in Europa, wie auch in den USA, Kanada, Brasilien, China, Indien, Südafrikaund Saudi Arabien.

An der Entwicklung neuer Funktionalitäten sind folgende Abteilungen beteiligt:

• Professional Services (Aufgabe: Projektmanagement und Consulting)

• Productmanagement (Aufgabe: strategische Produktplanung)

• Entwicklung (Aufgabe: Programmierung, Dokumentation, Qualitäts Management)

Weitere Abteilungen sind Training (für Kunden), Vertrieb, Buchhaltung, Lager, Emp-fang, Service Center und Vorstand.

4

3. IST-Analyse

Im folgenden Kapitel werden die Prozesse der Firma TOUCCEA beschrieben (Stand:November 2011). Grundlage der Analyse sind sechs FLOW-Interviews, Dateien zur inter-nen Mitarbeiterschulung, Nachfragen bei den Mitarbeitern und der Flurfunk. Letzteremkommt eine groÿe Bedeutung zu, da viele Abweichungen des IST- zum SOLL-Prozessesvon den Mitarbeitern nebenbei erwähnt werden. Gleiches gilt für Kritikpunkte, die z.B.beim Mittagessen, während der Bahnfahrt in den Feierabend oder zwischendurch imBüro erwähnt werden.Die Interviews führte ein Mitarbeiter des Fachgebiets Software Engineering durch.

3.1. Chronologische Prozessbeschreibung

Zunächst erfolgt die Prozessbeschreibung anhand des Werdegangs eines Features. SpätereAbschnitte enthalten Beschreibungen der Dokumententation und der beteiligten Rollen.

3.1.1. Quellen der Anforderungen

Weg 1 - Neukunden: Die Gewinnung von Neukunden ist Aufgabe der Abteilung Sales.Diese bewirbt die Plattform in ersten Gesprächen. Sobald technische Fragen auftreten,übernimmt die Abteilung für Presales (siehe Abb. 3.1).

Abbildung 3.1.: Vereinfachte Prozessdarstellung

5

3. IST-Analyse

Die Prozesse der potentiellen Kunden sollen durch die Plattform abgebildet werden.Meist reicht dafür eine Anpassung der Plattform. Bei dieser - als Customizing bezeichneten-Kon�guration werden bestimmte Optionen installiert.

Manche Abläufe lassen sich nicht durch Customzing abbilden. Die Plattform muss umneue Funktionalitäten erweitert werden. Diese Anforderungen werden mit dem Kun-den formuliert - stichpunktartig und sehr allgemein. In dieser Phase existieren nochkeine Verträge. Die Phase ist von kurzer Dauer: falls kein Vertrag zustande kommt,wurden nur wenig Mitarbeiterstunden, also Geld, vergebens investiert. Sobald ein Ver-trag abgeschlossen wurde, tritt die Abteilung für Professional Service in Aktion. EinProjektmanagement wird gestartet und ein Projektleiter (auch KundenPL oder eng-lisch Cust-PM) wird benannt. Die Anforderungen werden verfeinert, indem die für dieAnforderungsdokumentation nötigen Informationen ergänzt werden. Diese als Projektbezeichnete Phase wird mit einem Priorisierungsverfahren fortgeführt. Es folgt die Re-alisierung durch die Abteilung Entwicklung. In der anschlieÿenden Testphase werdendie neuen Funktionalitäten vom KundenPL getestet. Sobald diese erfolgreich beendetwurden, kommt es zur Auslieferung an den Kunden. Der Support bietet Hilfe und Kri-tikmöglichkeiten, solange der Kunde die Plattform nutzt.Die Dauer der Projekt- und Testphase variiert zwischen 1,5 Monaten und 3 Jahren.

Dieser kleine Exkurs soll einen ersten Gesamteindruck vermitteln. Die skizzierten Schrittewerden später genauer betrachtet.

Weg 2 - Supportabteilung: Die Mitarbeiter der Supportabteilung oder der Kun-denPL nehmen Kritik der Kunden auf, wenn es während des Betriebs zu Problemenkommt. Die Kunden melden in den Telefonaten neben Problemen auch Wünsche undAnregungen.Weg 3 - Product Management: Das Product Management erstellt Anforderungen.Hierbei handelt es sich um Visionen. Sie beobachten den Markt und die Konkurrenz undsorgen für ein zukunftsfähig aufgestelltes Unternehmen. Sowohl die Firma Meltwater wieauch die Marketingabteilung unterstützt die Product Manager. Sie melden Marktlückenund Themen mit Brisanz. Weitere Hinweise kommen von Kunden bei Messen, Besuchenoder Präsentationen.Beispiel: 3D-Planung und Ansicht, Unterstützung zusätzlicher BetriebssystemeWeg 4 - Entwicklung: Die Entwickler selbst äuÿern Wünsche, wie Redesign des Codes.Hierbei werden keine neuen Funktionen implementiert und somit kein Mehrwert für dieFirma gescha�en. Allerdings wird die weitere Entwicklung erleichtert, sowie die Wart-und Testbarkeit erhöht.

Weitere o�ene Aufgaben: Die Testabteilung wird nicht als extra Weg betrachtet, dasie (eigentlich) keine neuen Anforderungen aufwirft. Sie ist Teil der Qualitätssicherungund �ndet Fehler, so genannt Bugs. Manche Fehler entpuppen sich als so gravierend, dasszur Behebung sehr viel Aufwand nötig ist. Dann kann die Testabteilung dies als neueAnforderung formulieren. Eine Unterscheidung zwischen Bug und neuer Anforderung istwichtig, da Fehlerbehebung ein Teil des Supports ist. Die Kosten trägt TOUCCEA. Wirdhingegen eine neue Anforderung formuliert, trägt der Kunde die Kosten der Entwicklung.

6

3.1. Chronologische Prozessbeschreibung

Fazit: Es gibt ein breites Spektrum von Anforderungen: von strategischer Entwicklungbis hin zu Kundenwünschen und akuten Problemen. TOUCCEA entwickelt nicht �vonder grünen Wiese�, sondern nimmt Ergänzungen an einem bestehenden Produkt vor.

3.1.2. Eintrag in der Approach DB

Je nach Projektfortschritt teilt der Kunde seine Anforderungen dem KundenPL oderdem Presales mit. Danach nimmt der TOUCCEA-Mitarbeiter eine Eintragung in dieApproach DB vor: er erstellt ein �Ticket�. Die Anforderung wird in 1-2 Sätzen kurzbeschrieben. Die Approach DB weiÿt dem Ticket eine eindeutige ID zu.Der Ticketersteller wird TOUCCEA-intern als Kunde betrachtet, sodass Rückfragen imProzess meistens an den KundenPL gestellt werden. Dieser kann bei Bedarf Rücksprachemit dem �richtigen� Kunden halten.Auch Anforderungen, die über Weg 2 bis 4 gefunden werden, werden in die ApproachDB eingetragen. Jeder Mitarbeiter kann einen Eintrag vornehmen. Die Anforderungbe�ndet sich im Status New.

Findet die Testabteilung Fehler, trägt sie diese auch in die Approach DB ein. Durch diezugewiesene ID ist ein Tracking der Einträge möglich. Die Tester weisen Fehler nichtdirekt an den Programmierer zurück, weil dann kein Tracking möglich wäre. Auÿerdemist nicht immer klar, welcher Entwickler für die Fehlerbehebung zuständig ist.Meist gibt es mehr Fehler als behoben werden können.

3.1.3. Erstellung einer Anforderungsbeschreibung

Jeder KundenPL erstellt die ausführliche Anforderungsbeschreibung zu Tickets, die erin die Appraoch DB eingetragen hat. Der Product Manager erstellt das Dokument für dierestlichen Tickets. In dieser Zeit be�ndet sich die Anforderung im Status Specification.Die Product Manager beobachten die Approach DB und beschleunigen oder bremsenMitarbeiter bei der Bearbeitung ihrer Tickets. Viele Tickets sollen absichtlich nicht so-fort ausführlich beschrieben werden, da sie sich anderweitig klären lassen (meist reichtdoch das Customizing). Diese Tickets werden aus der DB gelöscht, ohne dass eine Doku-mentation benötigt wird.Die KundenPLs schicken Anforderungen oft direkt an die Product Manager per Mail,Anruf oder Flurgespräch. Diese weisen sie darauf hin, dass sie einen Eintrag in der Ap-proach DB machen sollen. Hier zeigt sich eine Abweichung des IST- vom SOLL-Prozess.

Ein Product Manager erweitert die Anforderungsbeschreibungen um technische, platt-formspezi�sche Angaben. Dieser Status heiÿt Planning. Gegebenenfalls muss er dafürbei dem KundenPL oder dem Presales Rückfragen stellen. Dies ist sehr häu�g nötig,da die Qualität der Einträge in die Approach DB bzw. die Anforderungsbeschreibun-gen teilweise unvollständig sind. Oft werden nur Lösungsansätze anstatt der Problemebeschrieben. Die gewünschte neue Funktionalität ist so nicht erkennbar. Es besteht dieGefahr, dass �am Problem vorbei� verbessert wird.Die Auswahl und die Reihenfolge in der Anforderungsbeschreibungen angereichert wer-den, bestimmt jeder Product Manager erfahrungsbasiert selbst.

7

3. IST-Analyse

Eine genaue Beschreibung der Inhalte der oben genannten Dokumente folgt in Kapitel3.3. Vorschläge zur Verbesserung der Qualität der Anforderungsbeschreibung werden inKapitel 5 erörtert.

3.1.4. Priorisierung und Projektplan

Anhand einer Bewertungsmatrix (siehe Kapitel 3.4) priorisieren die Product Managerdie neuen Tickets. Man spricht nun von einem Feature, statt einem Ticket.

Sobald ein Product Manager ein Ticket verfeinert, sendet er eine E-Mail an den Pro-gramm Manager. Dieser fügt das Feature mit niedrigster Priorität in den Projektplanein. Automatisch wird eine Zeile in der Bewertungsmatrix für das Feature angelegt.Sobald die Matrix angewandt wurde, schhiebt sich das Feature automatisch im Projekt-plan an die der Priorität entsprechende Position. So mischen sich die neuen Featuresmit den bereits vorhandenen. Über die Änderung der Reihenfolge gibt es keine automa-tischen Mitteilung an die Entwickler. So kommt es vor, dass diese eventuell an mittler-weile nicht mehr hochpriorisierten Features arbeiten. Dies führt zu Verstimmungen inder Belegschaft.

Abbildung 3.2.: Prozessausschnitt: vom Kunden zum Projektplan

Die Product Manager bearbeiten jede Anforderungen mindestens zweimal: bei der An-reicherung der Anforderungsbeschreibung und bei der Priorisierung. Damit entfällt einGroÿteil des Requirements Engineering auf sie. Einen weiteren Teil übernehmen die Kun-denPL: sie nehmen die Anforderungen vom Kunden entgegen und verfassen eine ersteBeschreibung. Das Requirements Engineering bei TOUCCEA ist dezentral organisiert,

8

3.2. Entwicklungszyklen

da viele Mitarbeiter Aufgaben übernehmen.

3.1.5. Implementierung

Nach der Priorisierung weist der Porgramm Manager jedem Feature einen Featurever-antwortlichen (auch FeatureLead genannt) zu. Diese Aufgabe bekommt der Program-mierer, der die meisten Kenntnisse und Anteile an der folgenden Umsetzung hat. DerFeatureverantwortliche bestimmt Kollegen, die bei der Umsetzung mitarbeiten. Damitdas Feature aus dem aktuellen Status Design in den Status Development wechseln kann,muss ein Konzept zur Umsetzung des Features vorliegen. Dies wird vom Featureverant-wortlichen geschrieben. Nun wird das Feature implementiert. Im gelebten Prozess wirdnicht klar zwischen Design und Development unterschieden: oft implementiert ein Ent-wickler zuerst und dokumentiert anschlieÿend sein Vorgehen. Dies stellt eine weitereDi�erenz zwischen IST- und SOLL-Prozess dar.

Wichtige Features werden teilweise ohne die Verfeinerung des Product Managers prior-isiert. So kommt es häu�g vor, dass Entwickler hochpriorisierte Features implementierenwollen, es aber nicht können, da die Verfeinerungen fehlen. Entwickler müssen oft nieder-priorisierte Features vor wichtigen Anforderungen umsetzten, wenn bei letzteren dasUmsetzungskonzept fehlt. Die Reihenfolge der Bearbeitung entnehmen die Mitarbeiterdem Projektplan.

3.1.6. Test und Auslieferung

Fertiger Code wird vom Entwickler im Source Safe eingecheckt. Der Status des Featureswechselt zu Ready for Test. Nun erstellt der Entwickler das Übergabedokument undgibt es persönlich bei der Testabteilung ab. Das Features wechselt in den Status Test.

Der KundenPL testet die Features, die er angestoÿen hat. Er hat das nötige Kunden-wissen, um aussagekräftige Tests durchzuführen. Die Testabteilung ist für den Test vonneuen Versionen zuständig. Hierfür braucht es Wissen über die komplette Plattform.Nach erfolgreichem Test kommt es zur Auslieferung an den Kunden. Die Support-abteilung steht zukünftig als Ansprechpartner bereit, falls der Kunde Fragen, Wünscheoder Probleme hat. Das fertige Feature be�ndet sich im Status Complete.

3.2. Entwicklungszyklen

Ziel der Firma TOUCCEA ist es, pro Quartal eine neue Version der Plattform zuverö�entlichen. Ein Quartal wird in die drei Phasen Entwicklung, Stabilizing und Testaufgeteilt (siehe Tabelle 3.1 auf der nächsten Seite).

Es kommt vor, dass alle Aktivitäten von Eintrag in die Approach DB bis Test und Aus-lieferung in einem Entwicklungszyklus abgearbeitet werden. Oft wird die Anforderungs-beschreibung in einem vorangegangenen Zyklus erstellt. Dies ist möglich, da der Zyklusnur für die Entwicklungsabteilung gilt. Die KundenPLs als Autoren der Dokumente sind

9

3. IST-Analyse

Phase AufgabenEntwicklung Entwicklung neuer Funktionalitäten durch Implementierung von An-

forderungenStabilizing Behebung von Bugs, keine Implementierung neuer Funktionalitäten

Test Test der neuen Version, Beseitigung auftretender Fehler

Tabelle 3.1.: Phasen eines Entwicklungszyklus

Mitarbeiter der Abteilung Professional Service und damit davon unabhängig.

3.3. Dokumente

Im folgenden Abschnitt werden alle im Prozess entstehenden Dokumente betrachtet.Es gibt den Eintrag in der Approach DB, die FeatureSpeci�cation, das Implementation-Concept und das TestManual. Neben den bereits erwähnten Quellen (Interviews, interneDokumentation etc.), basiert die Analyse der verschiedenen Dokumente auf exempla-risch ausgewählten Beispieldokumenten - insgesamt ca. 200 Stück.

Alle Dokumente werden auf dem Share Point Server hinterlegt und sind damit für alleMitarbeiter zugänglich. Zur besseren Übersicht gibt es für jede Version der Plattformeinen eigenen Ordner für die gescha�enen Dokumente.

Folgende Punkte sind wichtig bei der Analyse eines Dokuments: Wer erstellt es wann?Was wird in welcher Form festgehalten? Wer liest es?

3.3.1. Einträge in der Approach DB

Alle Mitarbeiter können Einträge in die Approach DB vornehmen. Anforderungen tra-gen meistens die KundenPL oder das Product Management ein. Fehler kommen von derTestabteilung. Die Datenbank bietet keine Unterscheidung zwischen Fehlern und An-forderung an. Es ist der erste Eintrag zu einem Feature und dient als grober Überblickund Gedankenstütze für mögliche neue Funktionen. TOUCCEA-Beispiel eines Kun-denPL: �Kunde XY benötigt 1000 neue kundenspezi�sche Attribute vom Typ Text.�Laut Aussage der KundenPLs reicht dies zur Weiterverarbeitung. Die entsprechendenMitabeiter negieren dies teilweise.

Folgende Attribute sind neben der Beschreibung möglich: das aktuelle Datum, der ein-tragende Mitarbeiter, einer Plattform-Version (die Version, auf den sich der Fehler bzw.die Anforderung bezieht), der Kunde, welche Testumgebung genutzt wird (z.B. Win-dows Vista, Windows XP) und die zugewiesene ID. Im weiteren Prozessablauf kannfestgehalten werden in welcher Version die Anforderung wahrscheinlich behoben wird,ein Kontext (z.B. Plattform Cable, Plattform Instrumentation, Embedded Worksheet,Installation, Performance und viele mehr), der Typ, ein Entwickler, die Priorität (hoch,mittel, niedrig), Notizen, der Status, ein Tester und das Datum des Tests.

Unter Typ wird festgehalten, ob es sich um einen S-, A-, B- oder C-Fehler handelt. Durch

10

3.3. Dokumente

die verschieden Fehlerkategorien kann die Schwere der Fehler abgebildet werden. VonS- zu C-Fehlern nimmt diese ab und damit auch die Wahrscheinlichkeit der Behebung.Kriterien anhand derer die Einteilung vorzunehmen ist, sind vorhanden. Beispielsweiseist ein Systemabsturz bei der Installation sehr schwerwiegend. Anders verhält es sichbei einem verrutschten Button. Anforderungen sind vom Typ Änderung oder Neuerungim Entwurf, Auftrag, Zusagen oder Wunsch.

Die Angabe des Status wird regelmäÿig aktualisiert. Es gibt 18 Möglichenkeiten dafür:Bleibt so, Cancelled, Complete, Design, Development, in Bearbeitung, Klä-

rung, Muÿ, New, nicht OK, Nicht reproduzierbar, Offen, OK, Planning, Ready

for Test, Später, Specification und Test. Damit übernimmt die Approach DBAufgaben des Projektmanagements.

Aus dem chronologischen Ablauf lassen sich Complete, Design, Development, New,

Planning, Ready for Test, Specification und Test wieder�nden. Bleibt und nichtreproduzierbar sind Zustände für Fehler. In Bearbeitung, Klärung, Muss, nicht

OK, Offen, OK, Später und Cancelled sind in der internen Dokumentation zum Pro-zessablauf als Status nicht de�niert. Diese wurden von Mitarbeitern ergänzt als ihnenkeiner der vorgegebenen Stati passend erschien. Dabei fällt auf, dass keine einheitlicheSprache (deutsch/englisch) und Schreibweise (Groÿ-Kleinschreibung) verwendet wurde.Die Erweiterungen sind kritisch zu betrachten, da vom Prozess abgewichen wurde. Fallses keinen passenden Status gibt, ist der Prozess schlecht modelliert. Dieses Fazit kon-nte nicht gezogen werden (siehe Kapitel 3.7), daher sollten die Mitarbeiter aufgefordertwerden den Prozess zu befolgen.

Die groÿe Anzahl von Stati führt dazu, dass die Übersicht verloren geht. Im Zusammen-hang mit der Umstellung auf den Team Foundation Server wurde auÿerdem festgestellt,dass gewisse Stati nur zum �Parken� und �Wegschieben� unbeliebter Features genutztwurden. In der täglichen Arbeit mit mehr als 10 000 Einträgen in der Datenbank werdennur Filterfunktionen genutzt. Für einige der selbstde�nierten Stati war keiner zuständig.Die Einträge wurden nicht herausge�ltert und waren praktisch gelöscht. Eine Problemlö-sung hierfür muss nicht diskutiert werden, da seit der Einführung des Team FoundationServers immer ein zuständiger Mitarbeiter anzugeben ist.

Am 13.12.11 waren insgesamt 10404 IDs vergeben.Die Product Manager beobachten die Datenbank.

3.3.2. FeatureSpeci�cation

Bisher wurde salop von der Anforderungsbeschreibung gesprochen. Dies wird nun präzi-siert. Im TOUCCEA-Prozess gibt es eine Namensdopplung: als FeatureSpeci�cationwird einmal ein Dokument bezeichnet. Andererseits wird der Begri� verwendet, um daserste Kapitel des gleichnamigen Dokuments zu beschreiben. Um Missverständnisse zuvermeiden, wird im Folgenden das erste Kapitel als Speci�cation bezeichnet. In einemälteren Prozessmodells gab es eine Speci�cation. Diese ent�el bei der letzten Änderung.Der Begri� wird hier wieder aufgegri�en, da er im täglichen Umgang der Mitarbeiternoch präsent ist; ebenso wie die abgewandelte Form Ausgangsspec. Häu�g wird der Be-

11

3. IST-Analyse

gri� der ebenfalls abgescha�ten FuncSpec verwendet. Insbesondere heiÿt so der Ordnerauf dem Share Point Server, der alle Dokumente enthält. Dokumente in besagtem Ordnerwerden manchmal auch mit Speci�cation oder RealisationConcept beschrieben, damitman schneller sieht in welchem Status sich das Dokument be�ndet. Separate Dokumentemit diesem Namen gibt es nach Prozessde�nition nicht.Dies kann leicht zu Verwirrungen führen. Daher wird eine durchgehende Benennungwärmstens empfohlen. So könnten komplett neue Namen für die Dokumente vergebenwerden. Dies hat den Nachteil, dass die Mitarbeiter neue Bezeichnungen lernen müssenund die alten Bezeichnungen möglicherweise weiterhin genutzt werden.

Die FeatureSpeci�cation besteht aus folgenden vier Teilen:

• Übersicht und Change History

• Speci�cation: eine Beschreibung des Features aus Kundensicht.

• RealisationConcept: eine Beschreibung, wie das Feature auf Plattformebene umge-setzt wird.

• Approval Protocol: eine Sammlung von Testfällen und ein Abnahmeprotokoll.

Die FeatureSpeci�cation wird in mehreren Schritten erstellt. Daher werden die Fragen�Wer erstellt es wann? Was wird in welcher Form festgehalten? Wer liest es?� bei deneinzelnen Teilen beantwortet. Ziel der Zusammenfassung in einer FeatureSpeci�cationist es, dass fast alle relevanten Texte zu einem Feature in einer Datei auf dem SharePoint Server sind. Dies beugt langen Dokumentsuchen vor. Auÿerdem wird die Anzahlan Dokumenten auf dem Server gering gehalten.

Als Hilfe bei der Erstellung gibt es ein Template mit vier Kapiteln. Es ist sowohl indeutscher wie in englischer Sprache vorhanden. Alle gesichteten Dokumente wurdendamit erstellt. Es konnte in Einzelfällen beobachtet werden, dass die Sprache innerhalbeines Dokuments wechselt. So wurden deutsche Texte geschrieben, die Gra�ken abermit englischen Beschriftungen versehen. Dies könnte zu Verwirrungen führen. Beispiel:eine gewünschte Funktion wird mit �create a table of worksheets� und mit �erstelleeine Arbeitsblattübersicht� beschrieben. Das englische Wort table ist präziser als dasdeutsche Übersicht, denn dazu kann auch eine Gra�k gezählt werden.Fazit: Dokumente sind durchgängig in einer Sprache zu schreiben!

Übersicht und Change History

In die tabellarische Übersicht auf der ersten Seite der FeatureSpeci�cation soll der Fea-turename, ein verantwortlicher Mitarbeiter, ein Kunde und die ID eingetragen werden.Oft ist nur ein Teil ausgefüllt. Zusätzlich gibt es eine Change History. Dort soll eingetra-gen werden, wer was wann an dem Dokument geändert hat. Dadurch kann leicht verfolgtwerden, wie sich das Dokument verändert hat. Die Tabelle ist allerdings oft leer.

Abb. 3.3 zeigt eine ausgefüllte Change History. Man kann eine Vermischung der Sprachensehen: das englische Template wurde für eine deutschsprachige Beschreibung verwendet.

Beim Vergleich des deutschen und englischen Templates fällt auf, dass aus dem eng-lischen the Customer in der Übersicht, im Deutschen ein Stakeholder ist. Es gibt mehr

12

3.3. Dokumente

Abbildung 3.3.: TOUCCEA-Beispiel einer ausgefüllten Change History

mögliche Stakeholder (zu Deutsch: Geschäftsinteressent, Akteur) als Customer: z.B.kann Greenpeace ein Stakeholder beim Bau einer Autobahn sein. Sie wollen wahrschein-lich die Autobahn verhindern, um die Natur zu schützen. Damit sind sie kein zahlungs-bereiter Stakeholder im Sinne eines Customers.Ausgefüllt wird diese Zelle mal mit einem Mitarbeiter aus dem Produktmanagement,mal mit eine Firma und in Einzelfällen ist sie leer.

Die Speci�cation

Die Speci�cation ist das erste Kapitel der FeatureSpeci�cation und enthält die Beschrei-bung der Anforderung aus Sicht des Kunden. In der �rmeninternen Dokumentation heiÿtes: �WAS soll das Feature WIE tun, ohne dass die Plattform dabei an sich berücksichtigtwerden muss?� Ein TOUCCEA-Beispiel ist in Abb. 5.4 zu sehen.

Geschrieben wird sie vom Mitarbeiter, der den Eintrag in der Approach DB vorgenom-men hat, meist der KundenPL oder ein Product Manager. Die Speci�cation ist für dieProduct Manager Entscheidungshilfe beim Priorisierungsverfahren.

Das RealisationConcept

Das RealisationConcept wird meist von einem Product Manager verfasst. Möglich istauch ein Entwickler als Autor. Die Aufgabenverteilung wird meist spontan durch Tele-fonate und Flurfunk geklärt. Das zweite Kapitel der FeatureSpeci�cation beinhaltet einemögliche Realisierung des Features aus Entwicklersicht. Durch Screenshots von User in-terfaces wird die angestrebte Einbettung der Funktion in die Plattform dargestellt. Dader Kunde das Konzept mit einer Unterschrift bestätigen soll, muss es verständlich seinund darf insbesondere keine Code- oder Architekturaspekte behanndeln.

Es kann beobachtet werden, dass häu�g nicht klar zwischen ersten und zweiten Kapitelgetrennt wird. Zum Beispiel werden Ober�ächen und Einstiegspunkte (wo wird in derPlattform die Funktion gestartet) in Kapitel 1 behandelt. Diese Punkte gehören in dasRealisationConcept.

Das Approval Protocol

Das dritte und vierte Kapitel des Templates enthält eine Liste mit Testfällen und einAbnahmeprotokoll. Mit einer Unterschrift bestätigt der Kunde und der KundenPL das

13

3. IST-Analyse

Dokument. Die Abnahme des fertigen Features kann durch eine weitere Kundenunter-schrift bestätigt werden. Beide Kapitel waren in allen Fällen leer. Insbesondere werdenTestfälle erst später - wenn überhaupt- geschrieben. Damit kann ein Features nichtauf Grundlage erfolgreicher Akzeptanztest beendet werden. Der Kunde bekommt keineMöglichkeit eventuelle Missverständnisse zu berichtigen. Die interne Prozessbeschrei-bung sieht diese Unterschrift nicht vor, allerdings bietet das Template die Möglichkeit.Hier o�enbart sich groÿes Verbesserungspotential.Im Frühjahr 2012 wurde die Testabteilung angehalten zukünftig nur noch eine Featuresmit Testfällen entgegenzunehmen.

Fazit FeatureSpeci�cation:Das Template gibt eine Mindestanzahl von 4 Seiten vor. Die Seitenanzahl der Doku-mente schwankt insgesamt, aber auch die Verteilung der Inhalte auf die Kapitel. Es gibtDokumente mit 4 Seiten und welche mit 19 Seiten. Manche Dokumente haben einenkurzen Absatz als Kapitel 1 und einer ausführlichen Beschreibung bei Kapitel 2 oderandersherum. Die Vermutung liegt nahe, dass die Mitarbeiter nicht wissen, wie mit demTemplate umzugehen ist.

Die Vermutung des Programm Managers, dass nicht alle Kapitel ausgefüllt werden,konnte bestätigt werden. Eine Umstrukturierung ist geplant. Zur Zeit sind allerdingsalle Ressourcen mit der Umstellung auf den Team Foundation Server belegt.

Ein zweiter Punkt betri�t die Anzahhl der priorisierten Features: 505 Einträge der Ap-proach DB wurden priorisiert. Das entspricht einem Anteil von nur 4,9% aller Einträge.Dieser Anteil ist sehr gering und hat mehrere Gründe:

• Viele Mitarbeiter tragen vorschnell Anforderungen ein. Wird die Anforderungnicht schnell implementiert, hat der KundenPL Zeit sich über andere Lösungs-möglichkeiten Gedanken zu machen. Oft lässt sich das Problem doch durch Cus-tomizing lösen. Die Anforderung wird über�üssig.

• Es gibt sehr viele alte Einträge, die nie gelöscht wurden.

• Es gibt nur drei Product Manager mit begrenzter Zeit für die Priorisierung.

Es ist den Product Managern nicht möglich die Anzahl der bewerteten Einträge beigleichbleibender Qualität zu erhöhen. Wöchentlich werden 20-25 neue Anforderungeneingetragen. 10 Anforderungen pro Woche sind laut Product Management für die Priori-sierung optimal. Deshalb muss die Anzahl der Einträge verringert werden. Ein ProductManager schlägt vor, die Speci�cation vom Kunden schreiben zu lassen. Oft stellen sieviel mehr Anforderungen als nötig, weil es Ihnen keine Mühe macht. Dann würden sieüberlegen, ob die Anforderung so wichtig ist, dass sie die Zeit investieren. Problema-tisch ist allerdings, dass die Qualität der eingehenden Beschreibungen vermutlich sehrstark schwanken wird. Den eigenen Mitarbeitern kann man Vorschriften machen, wiedie Dokumente aussehen sollen, bei Kunden ist dies schwieriger. Dafür weiÿ der Kunde,was er haben will und kann die Funktionalität gut beschreiben. TOUCCEA spart Mitar-beiterstunden bei den KundenPL. TOUCCEA könnte einen Mitarbeiter einstellen, derdie Beschreibungen der Kunden überarbeitet und für die Einhaltung gewisser Standardssorgt. So wird die Anzahl der eingehenden Anforderungen reduziert ohne die Qualitätzu senken.

14

3.3. Dokumente

3.3.3. ImplementationConcept

Das ImplementationConcept wird von dem Featureverantwortlichen geschrieben. Beikomplexen Features wird er vom Plattformarchitekten unterstützt. Der Autor dokumen-tiert die Umsetzung des Features. Dies geschieht im SOLL-Prozess vor der Umsetzung.Die Praxis weicht davon ab, wenn die selbe Person beide Arbeiten ausführt: Dokumentewerden nachträglich verfasst. Es ergeben sich kaum Unterschiede, sodass die Abweichungtoleriert werden kann. Das ImplementationConcept wird zur Dokumentation erstellt. Es�ndet keinen Eingang in den weiteren Prozess, sondern erhöht die Wartbarkeit.

Wie für die FeatureSpeci�cation gibt es ein Template. Dieses beginnt auch mit einerÜbersicht und einer Change History. Diese sind öfter ausgefüllt als die der Realisa-tionConcepte. Mit Kapitel 5 wird die FeatureSpeci�cation fortgeführt. Es enthält dieUmsetzungsdokumentation. Im Template enthalten sind ebenso ein Kapitel 6: Test In-structions und Aufgaben (Tasks), die zur Umsetzung nötig sind. Es folgen eine Checklisteund ein Übergabeprotokoll für den Test. Es fällt auf, das Kapitel 6 sehr häu�g leer ist.Der Umfang der ImplementationConcepte schwankt zwischen 6 und 13 Seiten.

3.3.4. TestManual

Das TestManual ist freiwillig. Der Tester kann dort seine Gedanken zum jeweiligen Fea-ture festhalten: eine Gedankenstütze zur persönlichen Dokumentation. Das entsprechendeTemplate besteht nur aus der Beschreibung der Ziele des Dokuments: �... dienen demTester als Checkliste, die neue Funktionen im Gesamtkontext zu überprüfen�. WeitereStrukturvorgaben gibt es nicht. Die Dokumente haben einen Umfang von 5 bis 11 Seiten.

3.3.5. ToDo-Liste

Die ToDo-Liste ist eine Ergänzung zum Prozess. In dieser einen Datei werden Ideenund Anforderungen der Entwickler gesammelt. Jeder Entwickler kann eine Beschrei-bung unter seinem Namen hinterlegen. Es gibt eine Spalte für die Priorität. Sobald dieAnregung erledigt wurde, kann dies in die Spalte Datum und Status eingetragen werden.Es fällt auf, dass der Name nur selten eingetragen wird.

3.3.6. Zusammenfassung

Es gibt für jede Plattformversion deutlich mehr FeatureSpeci�cations als Implementa-tionConcepts und nur einige wenige TestManuals. Der Anteil dieser Dokumente beliefsich auf ca. 10 % (absolut: 18). Die Unterschiede lassen sich dadurch erklären, dass einTeil der Features durch eine niedrige Priorisierung nicht weiterverfolgt wird. Es gibt keinImplementationConcept bzw. TestManual.

Die folgende Tabelle fasst die Dokumente zur Beschreibung eines Kundenfeatures zusam-men. Zur besseren Übersicht wird PM statt Product Manager geschrieben.

15

3. IST-Analyse

Dokument Ersteller InhaltApproach DB KundenPL grober Überblick, Vergabe einer ID für das

ProjektmanagementFeature Speci�cation Bestandteile: Speci�cation und Realisation-

Concept• Speci�cation PM/

KundenPLFeaturebeschreibung aus Kundensicht

• RealisationConcept PM Featurebeschreibung aus Entwicklersicht (inwelchem Teil der Plattform wird das Featureumgesetzt)

Implementation-Concept

Feature-verantwort-licher

Dokumentation der Umsetzung, Taskliste undTesthinweise

Tabelle 3.2.: Dokumente zur Featurebeschreibung

Folgende Gra�k wird zur internen Mitarbeiterschulung verwendet: In der letzten Zeile

Abbildung 3.4.: Dokumente im Prozessablauf

steht die Rollenbezeihnung des Mitarbeiters, der die jeweilige Aufgabe ausführt. Darüberist der Status des Features angegeben. Ganz oben in den unteren Kästchen steht derName des Dokuments, das erstellt wird.Es fehlt die Approach DB und der Begri� FeatureSpeci�cation. Dafür wird der o�ziellnicht mehr aktuelle Begri� Speci�cation verwendet.

Fazit Dokumentation: Es gab keine Kritik der Mitarbeiter an Art und gewolltemInhalt der Dokumente, ebenso sind keine logischen Lücken in der Dokumentation zu�nden. Daher werden die Verbesserungsvorschläge den existierenden Prozess optimieren,statt ihn zu revolutionieren.

16

3.4. Das Priorisierungsverfahren


Auf Grundlage der FeatureSpeci�cation führen die drei Product Manager einmal proWoche das Priorisierungsverfahren durch. Dabei wird die Reihenfolge, in der die Featuresrealisiert werden, festgelegt. Das Verfahren setzt sich aus dem Ausfüllen der Bewer-tungsmatrix und dem Anwendung der Gewichtungsmatrix zusammen.

3.4.1. Die Bewertungmatrix

Jedes Feature wird unter verschiedenen Gesichtspunkten bewertet. Diese sind in Abb.3.5 dargestellt: die erste Zeile zeigt den Geischtspunkt und die zweite Zeile die Bewer-tungsmöglichkeiten. Die Bewertungen werden in eine Exceltablle eingetragen. Zusätzlichwird die ID, der Name, der Kunde und der Status laut Projektplan festgehalten. DieProduct Manager können neue Bewertungspunkte hinzunehmen, wenn diese der Vor-stand genehmigt.

Abbildung 3.5.: Punkte der Bewertungsmatrix

17

3. IST-Analyse

Durch Instrumentation, Cable, Power, Electrical oder Migration wird die Zugehörigkeitzu den verschiedenen Ausprägungen der Plattform gekennzeichnet. Die Anzahl der Tiersgibt an, welche Schichtenarchitektur der Plattform beim Kunden verwendet wird, dasheiÿt auf welche Art verschiedene Workstations vernetzt sind. Das Priorisierungsver-fahren kann neben Anforderungen auch auf Fehler angewendet werden. Daher gibt esdas Fehlerfeld zur Bewertung der Schwere der Fehler.

Unter QM Adjust und PM Adjust können die Qualitätsbeauftragten bzw. die ProductManager weitere Punkte nach eigenem Ermessen verteilen. Dies wurde in 5 von 127Features (Stand 14.12.11) genutzt und damit eher selten. In diesen 5 Fällen wurdennegative Werte eingetragen und somit die Priorität des Feature gesenkt. Alle weiterenBewertungspunkte tragen selbsterklärende Namen.

Abb. 3.6 ist zeigt zwei ausgefüllte Zeilen der Bewertungsmatrix.

Abbildung 3.6.: Eine Beispielzeile aus der Bewertungsmatrix

Das Feature �Worksheet hochzählen� betri�t einen Kunden mit 1 - 4 Lizenzen, derAnwendernutzen wird auf wenig geschätzt und das Budget auf einen halben Tag. Damitist das Feature nicht sehr wichtig, es wurde ausgewählt, da der Leser es ohne groÿesHintergrundwissen nachvollziehen kann. Der Eintrag �Signi�cance = 50� wird spätererläutert.

Das Feature �Beschränkung auf die erste Anzeigesprache� ist für die Plattform-AusprägungInstrumentation ein sinnvolles Feature, ebenso für Cable, Power, Electrical, Migration.Es liegt eine Tier 1 Hierarchie vor und betri�t einen Kunden mit 11-50 Lizenzen. DieErgebnisse sind wenig sichtbar, aber der Anwendernutzen ist vorhanden. Allerdingswürde eine Umsetzung 5-10 Tage in Anspruch nehmen. Es gibt kein akzeptiertes Risikowie auch alle weiteren Attribute mit 0 gewertet wurden.

Es fällt auf, dass die Spalte für Status immer leer ist. Dort soll der Status des Featuresaus dem Projektplan eingetragen werden. In der Praxis wird dies nicht getan. Damitgibt es eine weitere Di�erenz zwischen dem SOLL- und dem IST-Prozess.

18


3.4.2. Die Gewichtungsmatrix

Die Signi�kanz eines Features ergibt sich aus der Gewichtung der Einträge der Bewer-tungsmatrix anhand der Gewichtungsmatrix. Das heiÿt

Signifikanz = 10 · (∑

Gesichtspunkte

WertGesichtspunkt ·GewichtGesichtspunkt)

Abbildung 3.7.: Gewichtungsmatrix(Stand 14.12.11)

Die Priorität lässt sich aus derSigni�kanz ableiten: je höher derWert destso höher die Priorität.Das heiÿt insbesondere, dass einFeature mit bestimmter Signi�kanzunterschiedliche Priorität habenkann. Beispiel: ein Feature hat Sig-ni�kanz 100. Einmal hat es höch-ste Priorität, dann nämlich, wennalle anderen Features Signi�kanzenzwischen 30 und 95 haben. Und ein-mal geringe Priorität, wenn es Fea-tures mit Signi�kanz 30, 110, 130und 250 gibt. In Abb. 3.7 sind dieGewichte dargestellt. Diese legt derVorstand fest.

Beispiel: Die Signi�kanz für das Feature �Worksheet hochzählen� aus dem letzten Ab-schnitt ergibt sich wie folgt:

Signifikanz

= 10 · (WertStatusPM ·GewichtStatusPM +WertInstrumentation ·GewichtInstrumentation

+ ...+WertPMAdjust ·GewichtPMAdjust)

= 10 · (0 · 30 + 0 · 8 + 0 · 8 + 0 · 4 + 0 · 2 + 0 · 4 + 0 · 3 + 1 · 1 + 2 · 1 + 0 · 2 + 2 · 1+ 4 · 0 + 0 · 0 + 0 · 20 + 0 · 1 + 0 · 1)

= 10 · (1 · 1 + 2 · 1 + 2 · 1)= 10 · 5 = 50

Und für das Feature �Beschränkung auf die erste Anzeigenprache� ergibt sich:

Signifikanz

= 10 · (0 · 30 + 2 · 8 + 2 · 8 + 2 · 4 + 2 · 2 + 2 · 4 + 2 · 3 + 1 · 1 + 3 · 1 + 1 · 2 + 3 · 1+ 2 · 0 + 0 · 0 + 0 · 20 + 0 · 1 + 0 · 1)

= 670

19

3. IST-Analyse

Das zweite Feature hat eine höhere Priorität als Feature eins.

Die Summe wird mit 10 multipliziert um gröÿere Werte zu bekommen. Laut ProgrammManager sollen diese groÿen Werte die Entwickler zusätzlich motivieren, da die gefühltePriorität bei einer Signi�kanz von 140 ist höher als von 14.Auf den ersten Blick erscheint ein Gewicht 0 kontraproduktiv, da der Aufwand fürdie Bewertung vergebens, aber nicht umsonst ist. Für dieses Quartal ist das korrekt,allerding werden die Gewichte im nächsten Quartal anders sein.

Im Alltagsgeschäft dürfen keine zwei Features gleichpriorisiert sein, da dann der Entwick-ler entscheiden muss, welches Feature zuerst bearbeitet wird. Die Formel verhindert diesnicht. In der Praxis gab es diesbezüglich bisher keine Probleme.

Der Vorteil des 2-stu�gen Verfahrens liegt in der Möglichkeit leicht die Ausrichtungder Firma zu ändern. Die Gewichte können quartalsweise verändert werden. Möchte derVorstand z.B. den Cable-Bereich pushen, muss nur das entsprechende Gewicht von 8 aufz.B. 10 gehoben werden und die Signi�kanz von Anforderungen aus dem Cable-Bereichsteigt.

Das Gesamtgewicht von 86 ist zufällig und schwankt zwischen den Quartalen. Man sollteein konstantes Gesamtgewicht festgelegen. Beispiel: vereinfachend wird angenommen,dass nur für Instrumentation und Budget Gewichte ungleich Null verteilt werden. Imersten Quartal ist das Gewicht je 1, im zweiten Quartal je 15. Eine Anforderung 1 inQuartal 1 hat 2 und 4 Punkte und damit eine Signi�kanz von 6. Anforderung 2 inQuartal 2 hat je einen Punkt. Es ergibt sich eine Signi�kanz von 30. Anforderung 2 istdamit deutlich höher priorisiert, obwohl die Punkte viel geringer waren (6 vs 2). DieVergleichbarkeit der Signi�kanz über ein Quartal hinaus ist aktuell nicht gegeben.

3.5. Rollenbasierte Prozessbeschreibung

Im Folgenden wird der in Kapitel 3.1 chronologisch dargestellte Prozess aus Sicht derverschiedenen Rollen betrachtet. Da nur der Gesichtspunkt wechselt, wird ein Teil derErörterungen bereits erläuterte Sachverhältnisse wiederholen. Manche Sachverhältnissewerden verfeinert dargestellt.

Folgende Rollen sind am Requirements Engineering Prozess beteiligt: Presales, ProductManager, Programm Manager, Project Manager, Entwickler, Design (Architekt), QMund schlieÿlich der Test und der Support. Auf die Salesmitarbeiter wird in diesem Ab-schnitt nicht mehr eingegangen, da sie nur den ersten Kundenkontakt herstellen undkeinen Anteil am eigentlichen Requirements Engineering Prozess haben.

20

3.5. Rollenbasierte Prozessbeschreibung

3.5.1. Aufgaben der Rollen

Rolle Input Aufgabe Output Bemerkung

Presales

Wünsche undProbleme ausKundenge-sprächen

Eintrag derWünsche bzw.Probleme in dieApproach DB

Ticket in derApproach DB

ProjectManager

Vorarbeit derPresales, eigeneKundenge-spräche

Intern als Kundebetrachtet,Ticketerstellung,Speci�cationschreiben

Ticket, Speci�-cation

Begri�wird nichtdurchge-hendgenutzt,meist Kun-denPLgenannt

ProductManager

ApproachDB, Bewer-tungsmatrix,Speci�cation

RealisationCon-cept schreiben,Priorisierung

RealisationCon-cept, Signi�kanzeines Features

Häu�geRückfragenan Kun-denPL, umRealisation-Conceptschreiben zukönnen

ProgrammManager

Signi�kanzender Features

Verwaltung desProjektplans,Bestimmungder Featurever-antwortlichen

Projektplan,Featureverant-wortliche

EntwicklerFeatureSpeci�-cation, Projekt-plan

Implementation-Conceptschreiben, Im-plementierung

Implementation-Concept, Code

Design(Ar-chitekt)

FeatureSpeci�-cation, Imple-mentationCon-cept

Review bzgl. Ar-chitekturaspekte,Unterstützungbei der Erstellung

Fragen zu kriti-schen Punkten,Au�orderung zuVerbesserungen

QM/TestÜbergabeproto-koll, Code

Testen des CodesEinträge in derApproach DBbei Fehlern

QM wirdmit Testgleichgesetzt

SupportTelefonanrufeder Kunden

Beratung desKunden

Einträge inder ApproachDB bei Proble-men/Fehlern

Tabelle 3.3.: Rollen im Prozess

21

3. IST-Analyse

Ergänzung zum Programm Manager: Bei der Erstellung des Projektplans gilt, dasstheoretisch jeder Entwickler alles implementieren kann. Allerdings gibt es hier eineDiskrepanz zwischen Theorie und Praxis. So haben Mitarbeiter gewisses Expertenwis-sen. Bestimmte Mitarbeiter sind für bestimmte Bereiche (z.B. Datenbankzugri�, Ober-�ächen) zuständig. Bei der Verwaltung des Projektplans muss der Programm Manager,Features einfügen und einen Featureverantwortlichen festlegen. Er kümmert sich umdie Organisation bei Krankheit, Weiterbildung und Urlaub der Mitarbeiter, sodass allemöglichst e�zient arbeiten können.

Es kommt zu Rollendopplungen: der Product Manager und der ProgrammManager wer-den gelegentlich als Presales aktiv. Der Programm Manager ist einmal auch Featurever-antwortlicher. Weiterhin gibt es Personalunionen zwischen Presales und KundenPL.Prinizipiell ist dies nicht schlecht. Allerdings wird der Prozess anfälliger gegenüber demAusfall wie Krankheit oder Firmenwechsel von Mitarbeitern, da gegebenenfalls sehr vieleAufgaben nicht erledigt werden. Positiv ist, dass Schnittstellen wegfallen, da mit jederInformationsweitergabe zwischen Mitarbeitern die Fehlerwahrscheinlichkeit steigt.

3.5.2. Zuordnung der beteiligten Rollen zu den Abteilungen

Rolle AbteilungSales Vertrieb

Presales Service CenterKundenPL Professional Service

Product Manager ProduktmanagementProgramm Manager Entwicklung

Entwickler EntwicklungDesign (Architekt) Entwicklung

Test/QM EntwicklungSupport Service Center

Tabelle 3.4.: Verteilung der Rollen auf Abteilungen

Fazit: Mitarbeiter mehrerer Abteilungen sind am Prozess beteiligt. TOUCCEA sagtüber sich, dass sie sehr kurze Entscheidungswege haben. Dies widerspricht sich trotz derverschiedenen Abteilungen nicht, da alle auf den Share Point Server zugreifen können.Die Mitarbeiter sitzen im selben Haus und es ist üblich über Telefon oderpersönllich Nachfrage spontan zu kommunizieren. Es gibt keine zentrale Person, die fürdas Requirements Engineering zuständig ist.

TOUCCEA könnte einen Mitarbeiter einstellen, der während des gesamten Prozessesauf Qualitätsaspekte achtet.

22

3.6. Quality Gates

3.6. Quality Gates

Quality Gates im Sinne des Requirements Engineering gibt es nicht. Was einem QualityGate nahekommt, ist die Übergabe eines Features an den Test, die nur erfolgen kann,wenn ein Übergabeprotokoll existiert. Dies wurde erst im Dezember 2011 festgelegt undist noch kein etablierter Teil des Prozesses. Die Terminus Quality Gate �ndet sich inder internen Prozessbeschreibung nicht.

Ein zeitlicher Rahmen pro Status ist nicht vorgegeben. Qualität geht vor Termin. JedeAufgabe wird so schnell wie möglich bearbeitet. Deadlines gibt es nur im Zusammen-hang mit den Entwicklungszyklen, wenn eine neue Version verö�entlicht werden soll.Der Übergang eines Features in den nächsten Status erfolgt, sobald der zuständige Mit-arbeiter die Aufgaben als erledigt betrachtet. Eine unabhängige Kontrolle ist nicht einge-plant. Der Mitarbeiter des folgenden Status kann das Feature zurückweisen, wenn erNachbearbeitungsbedarf sieht.

Ein Feature kann auch abgebrochen werden, der formale Weg sieht dafür kein durchgefal-lenes Quality Gate vor. Der Product Manager kann eine erneute Priorisierung vornehmen.Gegebenenfalls entfällt das Feature danach.

Laut TOUCCEA werden Quality Gates nicht benötigt, da man miteinander reden kann.Ein Mitarbeiter ist dafür zuständig, alle in seinen Augen kritischen Speci�cationendurchzusehen. Damit gibt es ein Review: nach erfahrungsbasierter Auswahl und nichtfest im Prozess verankert. Es soll eher kurzfristig angesetzte Meetings oder Rückfragengeben, statt einer starren Prozessde�nition.

3.7. Fazit

TOUCCEA sagt von sich selbst, dass ihr Prozess featuredriven ist und �exibel gehand-habt wird. Statt starrer Prozesse, setzt man auf Kommunikation miteinander. DieseAussage wurde durch die Analyse bestätigt. Der Prozess ist angemessen und zielführend.Einem entgegengesetzten Fazit widerspricht das jahrelange Wachstum der Firma. DieMitarbeiter sind zufrieden.

Nichtsdestsotrotz gibt es Verbesserungspotential. Folgende Schwachstellen hat RaphaelPham, Mitarbeiter des Fachgebiets, auf Grundlage des angefertigten FLOW-Modellserkannt:

• Die Aufnahme von Anforderung in der Approach DB erfolgt ohne Struktur. DieEinträge sind oft schwer verständlich, da der Kontext der Anforderung fehlt.

• Es gibt Personen, die mehrere Rollen innehaben. Dadurch ergeben sich Prozess-abkürzungen.

• Im Priorisierungsverfahren gibt es eine Schleife zwischen Bewertungsmatrix undProjektplan.

• Das ThinDocument- und LongLine-Muster treten auf.

23

3. IST-Analyse

Nach der IST-Analayse kann ergänzt werden:

• Starke Qualitätsschwankungen in der Anforderungsdokumentation insbesonderein der Speci�cation

• Abweichungen des IST- vom SOLL-Prozess

� Die KundenPLs leiten Anforderungen häu�g gleich an die Product Managerweiter, statt einen Eintrag in der Approach DB vorzunehmen.

� Die Grenzen zwischen den Stati Development und Design verschwimmen:die Reihenfolge wird getauscht oder die Aufgaben parallel abgearbeitet.

� Die Change History und die Übersicht in der FeatureSpeci�cation sind oftleer oder nur teilweise ausgefüllt.

� Das 3. Kapitel und 4. Kapitel der FeatureSpeci�cation sind immer leer. Test-fälle werden nicht frühzeitig formuliert und der Kunde nimmt des Realisa-tionConcepts nicht ab.

• Uneinheitliche Nomenklatur der Dokumente

• Medienumbruch zwischen Approach DB, E-Mail-Kommunikation und Share PointServer

• Häu�g keine Protokollierung von Meetings mit Beschlüssen

• Im dezentralen Requirements Engineering Prozess gibt es keinen Mitarbeiter, derwährend des gesamten Prozesses auf Qualitätsaspekte achtet.

24

4. Der Team Foundation Server

4.1. Grundlagen

Am 15.11.2011 ist TOUCCEA auf den Visual Studio Team Foundation Server 2011(kurz: TFS) umgestiegen. Die Quellcode- und Dokumentenverwaltung wurden bishermit dem Share Point Server und Visual SourceSafe (VSS) bewältigt. Gleiches gilt fürdas Versionsmanagement. Die Aufgabenverwaltung basierte auf einer Exceltabelle - demProjektplan. Neue Anforderungen und Fehler wurden in der Appraoch DB gesammelt,wobei ein manueller ID-Übertrag zwischen den verschiedenen Werkzeugen nötig war.Microsoft hat den regulären Support des VSS im Jahre 2011 eingestellt, der erweit-erte Support läuft 2016 aus. Als Nachfolgeprodukt wurde der TFS entwickelt, der mehrMöglichkeiten bereithält. So bietet der TFS eine Aufgabenverwaltung, ein Buildman-agement, Anforderungsverfolgung im Sinne von Fortschrittsreports für das Projekt-management an. Es können alle Datein der Softwareentwicklung hinterlegt werden: An-forderungen, UML-Diagramme, Entwürfe, Dokumentationen, Beispieldaten und Quell-code . Damit be�nden sich alle Dokumente an einem Ort. Über eine Verknüpfung derDokumente mit dem entsprechenden Work-Item kann ein langes Suchen nach Dateinvermieden werden. Des weiteren gibt es Schnittstellen zu den bekannten Microsoft-produkten: so lassen sich Daten nach Excel exportieren und dort mit den bekanntenFunktionen auch in groÿen Mengen bearbeiten. Eine Einbindung von Visional Studioist möglich und wird bei TOUCCEA täglich praktiziert. Eine e�zientere Arbeit durchdie verbesserte Synchronisation soll erreicht werden.

Um den Umstieg auf den TFS für die Mitarbeiter zu erleichtern, gibt es eine interne 23Seitige Anleitung, die das neue Programm vorstellt und die Funktionsweise anhand vonzahlreichen Bildern erläutert. Technisch betrachtet, besteht der TFS aus zwei Schichten:einer Anwendugsschicht (Application Tier) und einer Datenschicht (Data Tier) als SQLServer.

25


4.2. Folgen der Einführung

... für den Prozessablauf

Grundlage des TFS beim Projektmanagement ist ein Vorgehensmodell nach CMMI Pro-cess Improvement 1 Diese Prozessvorlage beschreibt einen formalen Ansatz der Softwa-reentwicklung (im Gegensatz zu einem agilen Ansatz). TOUCCEA hat das vorgegebeneVorgehensmodell angepasst. So wurden Stati umbenannt um die bisherigen TOUCCEA-Begri� beizubehalten. In geringem Umfang wurde der im dritten Kapitel vorgestellteProzess geändert. Dazu später mehr. Der TFS liefert einen detaillierten Prozessleitfaden,sodass erstmals eine vollständige gra�sche Dokumentation der Abläufe existiert.

Was in der Approach DB ein Ticket ist, ist im TFS ein Work-Item. In der ApproachDB war es nicht möglich zwischen Anforderung und Fehlern zu unterscheiden. Dies än-derte sich mit der Einführung des TFS. Jeder Eintrag bekommt einen Typen. FolgendeWork-Item-Typen sind möglich: Requirement (Anforderung), Bug (Fehler), Change Re-quest (Antrag auf Änderung eines Requirement), Dump (Protokoll eines Plattform-Absturzes), Hot�x, Issue (Fehler in der Umgebung), Shared Steps (Gemeinsamer Schrittfür mehrere TestCases), Task (vom FeatureLead eingetragene Unterpunkt von Require-ment und Bug; enthält die konkrete Aufgaben und eine Zeitschätzung) und TestCase(Testschritte für einen Testfall). Weitere Typen können je nach Bedarf de�niert werden.

Ein Work-Item besitzt folgende Attribute: ID, Work Item Type, Title, Assigned To(zuständiger Mitarbeiter) und State (Status). Dies sind P�ichtangaben. Freiwillig ergänztwerden kann eine Beschreibung, ein Kunde, betro�enes Produkt (hier die Plattformoder ein Altprodukt) und eine Area (grobe Angabe zu welchem Themenfeld der Eintraggehört, z.B. Look and Feel, Installation,.NET Integration).

Am 4.1.12 waren 10806 Einträge vorhanden. Die Work-Items verteilen sich wie folgt aufdie Typen: 0 Dumps, Shared Steps und TestCases, 4 Hot�xes, 8 Change Requests, 9Issues, 71 Taks, 3690 Requirements und 7022 Bugs. Man sieht, dass u.a. Dumps undShared Steps kein Bestandteil des TOUCCEA-Prozesses sind. Es gibt keine Einträgedieser Art. Zur Erhöhung der Übersichtlichkeit sollten diese Typen gar nicht angebotenwerden.

Für jeden Work-Item-Typ gibt es einen anderen Work�ow (Ablauf). Beispielsweise mussfür einen Fehler kein ImplementationConcept geschrieben werden oder eine Anforderungkann nicht behoben worden sein. Abb. 4.1 zeigt den Work�ow eines Requirements.

1Bei der Capability Maturity Model Integration handelt es sich um eine Sammlung von Referenzmo-dellen zum Prozessablauf. Mittels dieser Modelle sollen Unternehmen ihren Prozess verbessern.CMMI kann zur Zerti�zierung der Reife eines Prozesses verwendet werden. Die Modelle sind sehrallgemein gehalten, sodass sie in verschiedensten Bereichen Anwendung �nden können. Es wirdbeschrieben welche Ziele wann erreicht werden sollen, nicht aber wie man dahin kommt. Dafür mussjede Firma für sich angemessene Wege festlegen.

26


Abbildung 4.1.: Work�ow eines Requirements

Der Ablauf setzt sich aus verschiedenen Stati zusammen, z.B. Proposed, Specification

und Test. Ein Feature kann nur in den nächsten Status wechseln, wenn eine der Über-gangsbedingungen erfüllt ist. Welche dies sind steht auf den Pfeilen. Gibt es mehreremögliche Bedingungen ist der Wert in den eckigen Klammern der Meistbenutzte. Bei-spielsweise wechselt ein Feature nur nach Beendigung des RealisationConcepts vonPlanning zu Design. Ab sofort ist in jedem Status eine Person für das Feature ver-antwortlich, z.B. im Status Implementation der FeatureVerantwortlich. Damit wirdverhindert, dass gewisse Stati zum �Dauerparken� genutzt werden.

Weitere Änderungen

• Fertiger Quellcode wird auf dem TFS abgelegt, statt wie bisher auf dem VisualSourceSafe. Der TFS ersetzt die Approach DB und den Projektplan. Der Share

27


Point Server ist weiterhin der Ablageort für Dokumente. Diese können bei dementsprechenden Work-Item im TFS verlinkt werden.

• Es besteht die Möglichkeit, dass Mitarbeiter automatisch Benachrichtigungen perE-Mail bei Änderungen an von ihnen ausgewählten Work-Item bekommen. Damitwird ein Wunsch vieler KundenPL erfüllt. Um den Fortschritt eines Features zuerfahren, brauchen sie künftig keine Nachfragen mehr zu stellen.

• Die Stati eines Work-Items tragen nur englische Namen. Bisher gab es paralleldeutsche und englische Namen.

• Anlagen können direkt im TFS gespeichert werden, sodass keine zusätzliche E-Mail-Kommunikation zum Austausch von Beispieldaten o.ä. erfolgen muss.

• Folgende Begri�e wurden umbenannt:

alt neu ErgänzungTestManual TestDocument Dokument

New Proposed StatusDevelopment Implementation StatusReady for Test Ready for QM Status

Tabelle 4.1.: Umbenennungen in Folge der TFS-Einführung

Wobei der alte Begri� Ready for Test die Situation besser beschreibt als Readyfor QM. Qualitätsmanagement ist mehr als die Durchführung von Tests. Genaudies ist aber die Aufgabe des Status. Ein QM soll auch die Einhaltung der vorgegebe-nen Prozesse überprüfen. Ein erfolgreiches QM �ndet daher parallel zum gesamtenProzess statt. Mit Ready for QM wird die Beachtung von Qualitätsaspekten aufden Test reduziert.

• Zu jeder Zeit muss dem Feature ein verantwortlicher Mitarbeiter zugewiesen sein,z.B. der Speci�cation Creator. Diese Person erledigt die anfallenden Arbeiten nichtzwingend selbst. Gegebenenfalls muss er die Aufgaben delegieren. �Tote � Einträgewie sie bei der Umstellung auf den TFS aufgetaucht sind, werden nicht erneutangesammelt. Die Priorisierung dieser ca. 2000 Einträge wird Jahre dauern. Ent-standen sind die Einträge indem Tickets auf Stati gesetzt wurden für die niemandzuständig war (siehe Kapitel 3.3.1). Erfreuliches Zitat eines KundenPL: �Frühergingen Anforderungen verloren, das passiert heute nicht mehr.�

• Es ist möglich Items per Mail zu verschicken und somit einem Medienumbruchzu vermeiden. Statt riesiger Anhänge reicht nun eine E-Mail mit dem Link zumentsprechenden Item.

• Es ist nicht mehr nötig, die ID manuell zwischen Visual SourceSafe, Approach DBund Projektplan abzugleichen.

• Parallel zur TFS-Einführung wird ein Wiki eingerichtet um Erfahrungen der Mit-arbeiter zu dokumentieren und weiterzugeben.

• Beim Priorisierungsverfahren entfällt ein Medienumbruch. Eine extra Exceltabelle

28


wird nicht mehr benötigt, da die Bewertungen im TFS gespeichert werden können.

• Durch gra�sche Anzeigen kann man auf einen Blick erkennen, wer wann was aneinem Work-Item geändert hat. Dies erhöht die Übersichtlichkeit. Alle könnenschnell einsehen in welcher Phase sich ein Feature be�ndet. Die oben erwähntenNachfragen diesbezüglich entfallen. Der aktuelle Ansprechpartner ist ersichtlich.Abb. 4.2 zeigt das TOUCCEA-Beispiel eines Requirements: in den groÿen Kästchenstehen die durchlaufenen Stati, über den Pfeilen steht der entsprechende Mitar-beiter und das Datum der Aktion. Unter dem Pfeil steht die Begründung desStatuswechsels.

Abbildung 4.2.: Gra�sche Darstellung eines Requirementsablauf

• Es ist leicht und schnell möglich Berichte -insbesondere Gra�ken- über den Projekt-fortschritt zu generieren: wieviel Code wurde in der letzten Woche eingescheckt,wieviele o�ene Bugs der höchsten Stufe sind noch nicht bearbeitet?

• Möglich sind Gated Checkins (abgegrenzter Eincheckvorgang): der Code wird ineinen Zwischenspeicher eingecheckt, es läuft ein Build und nur wenn dieses erfolg-reich war, wird es endgültig eingecheckt. Dies ist ein Mittel zur Qualitätssicherung.

• Eine Anforderung kann in mehrere Tasks geteilt werden, diese können dann ver-schiedenen Personen zugewiesen werden und separat abgearbeitet werden. Weit-ere Strukturierungsmöglichkeiten und eine mögliche Nutzung werden in Kapitel 6vorgestellt.

• Jeder Mitarbeiter kann sich �seine � noch o�enen Work-Items angezeigen lassen - inentsprechender Prioritätenreihenfolge. Früher wurde der Namen der zuständigenPerson in den Dokumenten festgehalten, jetzt erfolgt dies im TFS. Die zugrunde-liegende Datenbank kann auf alle Attributen ge�ltert werden - auch auf Personen.

• Die Suchfunktion hat sich verbessert. Alle Attribute können auf das Stichwort hindurchsucht werden. Insbesondere auch in der Beschreibung. Früher wurde nur derTitel einbezogen. Diese Art der Suche war mühsam.

Der TFS wurde nach bestem Wissen und Gewissen eingeführt. Änderungsvorschlägeseitens der Mitarbeiter sind willkommen, wenn dadurch die Nutzung des TFS optimiertwerden kann. Dies wurde ausdrücklich kommuniziert.

29


Folgende Punkte sind während des Studiums vieler Work-Items aufgefallen:

• Auf dem Share Point Server hinterlegte Dokumente werden häu�g nicht verlinkt.Sie müssen manuell, zeitaufwändig gesucht werden.

• Es gibt Work-Items, denen kein verantwortlicher Mitarbeiter zugewiesen ist. Diesist zu kritisieren, da tote Einträge ähnlich denen der Approach DB zu befürchtensind.

Fazit:Auch wenn die Mitarbeiter über ein neues Programm stöhnen, hat dessen Einführungzu vielen Verbesserungen geführt. Die auslaufende Unterstützung des Visual SourceSafehat einen Umstieg erzwungen. Die Mitarbeiter hätten so oder so ein neues Tool erlernenmüssen.

30

5. Anforderungen an Anforderungen

Der Prozessablauf von TOUCCEA sieht vor, dass verschiedenste Personen Anforderungs-dokumente schreiben. Die meisten davon sind Techniker ohne grundlegende Kenntnisseim Requirements Engineering bzw. in der Anforderungsdokumentation. Daher schwanktdie Qualität der Dokumente sehr stark. Teilweise wurden Dokumente als �Katastrophe�beschrieben.In diesem Kapitel werden allgemeine Qualitätskritierien für Anforderungen vorgestellt.Daraus wurden Verbesserungsmöglichkeiten für das jeweils erste Kapitel der Feature-Speci�cation abgeleitet. Alle weiteren Kapitel können mit den vorgestellten Methodenbearbeitet werden. Der Schwerpunkt liegt klar auf dem ersten Kapitel. Eine Check-liste zur Verbesserung der Qualiät der 2. Kapitel wird aktuell (Stand 16.4.2012) vomQualitätsmanagement erarbeitet. Dort müssen viele technische Aspekte beachtet wer-den(z.B.Anzahl der Buttons). Laut TOUCCEA-Aussage sollen die Autoren keine um-fassenden Schulungen bekommen, da sie die Interessen der Kunden vertreten und sichihr Blickwinkel auf Prozesse und Wünsche der Kunden nicht verändern soll.Ziel der Qualitätssteigerung ist eine Reduzierung kosten- und zeitintensiver Nachfragenund damit eine Erhöhung der E�ektivität.

5.1. Qualitätskriterien für Anforderungen

[Rup04] und der Standard IEEE 830 benennen folgende Qualitätskriterien als Grundlageguter Anforderungen:

• Vollständig: Jede Anforderung muss die geforderte und zu liefernde Funktiona-lität vollständig beschreiben.

• Korrekt: Eine Anforderung gilt als korrekt, wenn sie vollständig die Vorstellungdes Stakeholders wiedergibt.

• Klassi�zierbar: Rechtliche Aspekte einer Anforderung müssen festgelegt sein.

• Konsistent: Eine Anforderung darf keine Widersprüche gegenüber anderen An-forderungen haben. Eine Anforderung ist in sich widerspruchsfrei.

• Prüfbar: Eine Anforderung muss mittels Testfällen als vollständig funktionsfähigbestätigt werden können. Bei Testfällen sind konkrete Grenzen und Maÿeinheitenanzugeben.

• Eindeutig: Eine Anforderung darf nur auf eine Art und Weise verstanden werden.Es darf nicht möglich sein, andere Sachverhalte hineinzuinterpretieren.

• Verstehbar: Es ist eine Dokumentationsform zu wählen, die von allen Stakehold-ern verstanden wird.

31


• Gültig und aktuell: Ändert sich eine bestimmende Gröÿe, müssen alle dadurchbetro�enen Anforderungen aktualisiert werden. Ziel ist eine aktuelle und gültigeBeschreibung.

• Realisierbar: Eine Anforderung muss innerhalb der gegebenen Grenzen umsetz-bar sein. Dabei sind Grenzen technischer, zeitlicher und �nanziellen Natur zuberücksichtigen.

• Notwendig: Eine Anforderung fordert nur Leistungen oder Eigenschaften, die zurUmsetzung der Kundenwünsche tatsächlich gebraucht werden.

• Verfolgbar: Jede Anforderung muss für sich eindeutig während des gesamtenLebenszyklus zu identi�zieren sein.

• Bewertet: Eine Anforderung ist nach Wichtigkeit, Dringlichkeit oder Prioritätbewertbar.

Diese Kriterien bilden die Grundlage des folgenden Fragenkatalogs. Weiterhin sindWünsche bzw. Kritikpunkte von TOUCCEA-Mitarbeitern an bestehenden Dokumenteneinge�ossen.

5.2. Der Fragenkatalog

Die TOUCCEA-Dokumentation wird in Prosa(Natural Language (deutsch: natürlich-sprachlich): Deutsch oder Englisch)verfasst. Problematisch an natürlichsprachlichen Doku-menten sind mögliche Mehrdeutigkeiten, bewusst oder unbewusst belassene Interpreta-tionsspielräume und schlechte automatische Plausibilitätsprüfungen. Denkbar wäre eineUmstellung auf gra�sche Notationen(Modeling Language, z.B. UML). Dafür sind Wissenund Kenntnisse nötig, die bei sehr vielen Mitarbeitern nicht vorhanden sind. Eine Einar-beitung wäre teuer und eventuell nicht zielführend, da nicht das gesamte Spektrum derAnforderungen für gra�sche Notation geeignet ist (z.B. nicht-funktionale Anforderungenwie Performancesteigerung).

Für eine textuelle Beschreibung spricht desweiteren die erheblich leichtere Kommunika-tion mit dem Kunden, der sehr wahrscheinlich keine Kenntnisse über gra�sche Notatio-nen besitzt.Nichtsdestsotrotz hat eine Anforderungsdokumentation in gra�scher Darstellungen Vorteile:

• Sie sind besser automatisch verarbeitbar, vor allem überprüfbar.

• Es gibt viele Beschränkung durch Strukturvorgaben. So kann das Fehlen wichtigerAngaben vermieden werden: z.B. kann die Angabe eines Auslöser erzwungen wer-den.

• Es gibt wenig Spielraum für Interpretationen und Mehrdeutigkeiten.

• Beispiele für UML sind Use Cases und Sequenzdiagramme. Dort wird das Ver-halten des Systems ausgehend von einer Aktion des Kunden mit dem Systembeschrieben.

Da für TOUCCEA die Vorteile natürlichsprachlicher Dokumentation überwiegen, sind

32


alle folgenden Betrachtungen und Verbesserungsvorschläge darauf ausgelegt. HabenTechniker bereits Kenntnisse in UML, sollte man sie in der Nutzung dieser Dokumen-tationsart bestärken. Für viele Anforderungen sind Use Cases oder Sequenzdiagrammeeine sehr gute Alternative! Wenn die Mitarbeiter in späteren Prozessphasen keine Weit-erbildung im Umgang mit gra�scher Notation brauchen, wurde eine kostenneutraleVerbesserungsmöglichkeit gefunden. Die Mitarbeit der Entwicklungsabteilung solltenkeine Probleme haben, da UML Teil ihrer Ausbildung ist. Mitarbeiter der Testabteilungsollten anhand der dokumentierten Testfälle ihre Arbeit weiterhin gut erledigen können-gegebenenfalls auch ohne UML-Kenntnisse, da die Testfälle, die Grundlage des Testssind, natürlichsprachlich dokumentiert werden. Eventuell müssten die Product Managerals Autor des 2. Kapitels der FeatureSpeci�cation UML lernen. Da es �nur � drei ProductManager gibt, erscheint der Aufwand vertretbar.

Zurück zum Fragebogen. Folgende Nutzung ist denkbar:

• Als Hilfsmittel bei der Erstellung der Dokumente: parallel zum Schreiben kannsich der Autor an ihnen entlang arbeiten.

• Als Checkliste bei einem Quality Gate(QG): ein Feature wechselt nur in die nächstePhase, wenn das Dokument das QG bestanden hat. Dies setzt voraus, dass zu je-dem feature ein Dokument existiert. Dies würde im täglichen Geschäft wahrschein-lich eine Nutzung als Hilfsmittel zur Folge haben (wenn man weiÿ was und wiegeprüft wird, kann man sich dementsprechend vorbereiten). Es ist möglich, dasssomit Dokumente nur auf QG-Fähigkeit getrimmt werden und der Inhalt in denHintergrund tritt.

• Als Grundlage für Reklamationen von Mitarbeitern einer späteren Phase: mangel-hafte Dokumente können zurückzuweisen werden, wenn eine Fragen nicht realisiertwurde.

5.2.1. Die Fragen

1. Ist Ihre Anforderung nicht bereits im TFS vorhanden?

2. Werden keine Entwurfs-, Architektur-, Test- und Implementierungsentscheidungenbehandelt? Gefragt sind Problembeschreibungen und keine Lösungsansätze.

3. Ist der Text eindeutig: gibt es keine uneindeutigen Begri�e? Werden Formulierun-gen beim Kunden anders verstanden und verwendet als TOUCCEA-intern? LegenSie gegebenenfalls ein Glossar mit strittigen Begri�en an.

4. Wurden Haupt- und Alternativstränge identi�ziert und in logischer Abfolge voll-ständig beschrieben? Haben Sie mögliche Fehlerfälle und Ausnahmen erläutert?

5. Ist Ihr Dokument sprachlich korrekt? Dies betri�t Rechtschreibung, Grammatik,Lesbarkeit und die Vermeidung von Interpretationsspielräumen.

6. Enthält Ihr Dokument weder Redundanz noch fehlen nötige Angaben? Ist IhrDokument widerspruchsfrei?

7. Haben Sie Testfälle angegeben, die die Erfüllung der Abnahmekriterien belegen?

33


Gibt es zu jedem Testfall einen Sollwert?

8. Ist Ihre Anforderung klar in den Prozess eingebettet, d.h. sind Vorbedingungen,auslösendes Ereignis, eine Startsituation und Nachbedingungen gegeben?

9. Haben Sie Beispieldaten angegeben?

10. Haben Sie einen angemessenen Detaillierungsgrad verwendet?

5.2.2. Begründung und Messbarkeit der Fragen

Im Folgenden wird die Aufnahme der einzelnen Fragen begründet und Möglichkeitenzur Messbarkeit dargestellt.Die Fragen können in zwei Gruppen eingeteilt werden: Einerseits gibt es allgemeingültigeFragen (2-7). Weitere Fragen (1 und 8-10) ergeben sich aus dem einmaligen Prozessesvon TOUCCEA. Sie sollen helfen Unklarheiten, Unverständliches, Unvollständiges unddie daraus resultierenden Rückfragen zu vermeiden. Gravierende Probleme treten auf,wenn Mitarbeitern im Umgang mit Dokumenten nicht klar ist, dass sie einen Aspektfalsch verstanden haben. In diesem Fall werden keine Nachfragen formuliert. Der Fehlerkann sich durch den kompletten Prozess ziehen.Es wurden nur 10 Fragen aufgenommen, um die Übersichtlichkeit zu erleichtern. EineHilfestellung, die selbst länger ist als das entstehende Dokument, wird schwerlich bei denAutoren Beachtung �nden. Weniger als 10 Fragen können den Umfang der Anforderun-gen an Anforderungen nicht sinnvoll abdecken.

Es handelt sich ausschlieÿlich um Entscheidungsfragen bzw. Hinweise. Werden die Fra-gen als Hilfestellung bei der Erstellung der Texte genutzt, soll der Autor alle Fragenmit �Ja� beantworten können. Entscheidungsgrundlage ist die Expertenmeinung desTOUCCEA-Mitarbeiters.Sollen die Fragen hingegen als Grundlage für ein Quality Gate verwendet werden,wäre eine automatische Überprüfbarkeit wünschenswert, da manuelle Reviews teuer undaufwändig sind. Eine manuelle Erhebung ist bei allen Punkten möglich, teilweise abernicht sinnvoll, da automatisierte Verfahren schneller und weniger fehlerhaft sind. Au-tomatische Textauswertungen sind reproduzierbar, d.h. eine erneute Prüfung ergibt dasselbe Ergebnis. Dies ist bei manuellen Reviews nicht immer der Fall. Zusätzlich hängenmanuelle Erbenisse stark vom Reviewer ab. Leider ist eine automatische Datenerhebungnicht in allen Punkten möglich bzw. sinnvoll. Messergebnisse sollten kritisch hinterfragtwerden: Spezi�kationen, in denen kein Fehler gefunden wurde, sind nicht per se gut,eventuell hat der Prüfer die Fehlerquellen übersehen. Weiterhin treten soganannte �falsepositives� auf. Die Prüfung meldet einen Fehler, weil bestimmte Regeln verletzt sind,allerdings handelt es sich nicht um Fehler und können von den Autoren als korrektbestätigt werden.Wird das Dokument vor dem manuellen Review eine automatische Prüfung unterzogen,kann sich die Reviewtätigkeit des Menschen auf wichtige, nicht automatisch prüfbareAspekte konzentrieren (z.B. enthält das Dokument nach einer Rechtschreibprüfung keineFehler dieser Art mehr, wird der Mitarbeiter nicht von Kommafehlern o.ä. abgelenkt)Eine Kombination von automaitschen und manuellen Reviews spart Zeit und erhöht die

34


Qualität, da Menschen bei automatisch überprüfbaren Aspekten eine deutlich höhereFehlerquote als der Computer haben, aber der Computer nicht alle Aspekte abdeckenkann.

Bei manuellen wie bei automatischen Erhebung muss prinzipiell zwischen relativen undabsoluten Messwerten unterschieden werden. Da die Anforderungen ein sehr breitesSpektrum abdecken, werden gewisse Werte im Verhältnis zur Länge des Dokumentgemessen (relativ). Absolute Messungen beziehen keine Relationen ein. Beide Artenhaben ihre Berechtigung: Sobald ein Widerspruch im Dokument ist (absolute Messung),kann es nicht umgesetzt werden, unabhängig davon ob es drei Zeilen oder drei Seitenlang ist. Andererseits kann ein drei Seiten langes Dokument mit 3 Rechtschreibfehlerngebilligt werden, anders ein 3 Zeilen langes Dokument mit 3 Fehlern (relative Messung).

1. Dopplungen: Es kommt häu�g vor, dass Anforderungen oder Bugs doppelt imSystem vorhanden sind. Die entstandene Redundanz sollte vermieden werden. Mitder Einführung des Team Foundation Server hat sich dieses Problem im Vergleichzur Approach DB abgeschwächt, da nun eine wirkungsvolle Suchfunktion überalle Einträge zur Verfügung steht. Dadurch können alte Einträge schnell gefundenwerden. Früher war die Suche innerhalb existierender Einträgen sehr aufwändigund wurde gescheut und eine Anforderung eher erneut eingetragen. Mit einemeindeutigen Titel lassen sich Anforderungen besser �nden.Eine automatische Prüfung kann ähnliche Anforderungen ermitteln und aufzeigen.Der konkreten Abgleich, ob die Anforderung bereits eingetragen ist, kann nurmanuell erfolgen. Wurde die Anforderung bereits ins System eingetragen, ist dasQuality Gate negativ beendet, andernfalls positiv. Beantwortet der Autor dieseFrage zuerst, wird verhindert, dass bereits vorhandenen Texte neu geschriebenwerden.

2. Abwesenheit von Entwurfs-, Architektur- und Implementierungsent-scheidungen: Es sollen im Anforderungsdokument nur zu entwickelnde Funktion-alitäten beschrieben werden. Jeder Mitarbeiter soll nur seinen Aufgabenteil erledi-gen und die Suche nach Lösungen obliegt nicht den Autoren des Anforderungs-dokuments. Deshalt wird Neutralität gegenüber Entwurfs-, Architektur- und Im-plementierungsentscheidungen gefordert. Bei Zuwiderhandlung kann die Kreati-vität der Mitarbeiter in späteren Phasen eingeschränken sein, wodurch bessereLösungen verhindern werden. Auÿerdem ist es irreführend. Die Übersichtlichkeitder Dokumente leidet durch einen erhöhten Umfang und die Komplexität kanndeutlich steigen.Eine Überprüfung kann automatisch erfolgen: eine Filterung auf fehlerhinweisendeWörter. Wörter wie z.B. Klasse und Exception werden in einer Datenbank hinter-legt. Diese wird kontinuierlich erweitert.

Anzahl_fehlerhinweisender_Woerter ≤ Grenzwert (5.1)

Manchmal lässt sich die Nutzung dieser Wörter nicht vermeiden, daher könnte derGrenzwert für das Bestehen des Quality Gates bei 5 Wörtern liegen. Eine andereMöglichkeit ist eine relative Betrachtung: ein Grenzwert in Bezug auf die Anzahl

35


der verwendeten Wörter.

Anzahl_fehlerhinweisender_Woerter

Anzahl_aller_Woerter· 100 ≤ Grenzwert (5.2)

Der Grenzwert im zweiten Fall könnte auch bei 5 liegen, d.h. 5 von 100 Wörternsind fehlerhinweisend. Die Multiplikation mit 100 bewirkt, dass die Ergebnisse imBereich der Natürlichen Zahlen sind und damit besser greifbar als ein Wert von0,05.

3. Begri�sklarheit: Selbst einfache Begri�e können verschieden interpretiert wer-den und somit zu Missverständnissen führen. Auÿerdem werden in verschiedenenFirmen dieselben Begri�e unterschiedlich verwendet. Es hat sich gezeigt, dass imLaufe der Entwicklung häu�g Rückfragen zu kundenspezi�schen Begri�ichkeit-en gestellt werden. Mehrfach wurde nach Nachfragen ein Glossar angelegt, umKlarheit zu scha�en. Die doppelte Verneinung ist absichtlich gewählt. Beim erstenLesen kann die Formulierung missverstanden werden. Aber die Mitarbeiter werdenregelmäÿig mit dem Fragekatalog arbeiten und dann die Formulierung verinner-licht haben. Die Perspektive ändert sich, wenn man nur eindeutige Begri�e oderkeine uneindeutigen Begri�e zu vermeiden sucht.Eine automatische Messung ähnlich der Lösung unter Punkt 2 ist denkbar. Beibestimmten Begri�en wird von einer Nutzung abgeraten. Die Liste wird adap-tiv erweitert, sobald Wörter Unklarheiten und Nachfragen hervorgerufen haben.Es muss eine Möglichkeit geben, kritische Wörter explizit zu bestätigen um falsepositives zu vermeiden, da manchmal eine Umschreibung nicht zielführend ist. Indiesem Fall wäre der Grenzwert 0. Gewissen Wörter können genutzt werden, derAutor soll sich nur über ihre Zweideutigkeit im Klaren sein und gegebenenfalls einGlossar erstellen. Im Sinne einer e�zienten Arbeit, emp�ehlt es sich, dass Glossarparallel zur Anforderungsdokumentation zu erstellen und nicht erst im Nachhinein.

Anzahl_fehlerhinweisender_Woerter ≤ Grenzwert (5.3)

4. Sonderfälle und Alternativstränge Der Hauptstrang wird in den meistenFällen gut und klar beschrieben. Nachfragen gibt es hingegen häu�g mit fehlen-den Alternativen, unvollständig beschriebenen Alternativen oder Fällen, bei denennicht eindeutig ist, welche Alternative gewählt werden muss. Oft fehlt eine Behand-lung, wie mit Fehlern und Ausnahmen umzugehen ist. Damit ist die Anforderungnicht vollständig beschrieben und lässt Raum für Fehlentscheidungen durch denEntwickler. Entwickler tre�en keine Entscheidungen über die Funktionalität, siesetzten die Anforderungen �nur � um. Die Gefahrenquelle darf nicht unterschätztwerden, da Fehler im Programm beim Kunden eventuell erst nach langer Zeitbemerkt werden. Eventuell handelt es sich um ein Verhalten in einer Gefahrensi-tuation: ein falsches Verhalten kann zur Katastrophe führen.Diese Frage ist nur manuell messbar.

Anzahl_fehlender_Alternativen+Anzahl_Luecken_im_Programmfluss

≤ Grenzwert(5.4)

36


Das QG ist nicht bestanden, sobald ein Fehler gefunden wird, d.h. der Grenzwertist Null.

5. Sprachlichen Korrektheit: Eine fehlerfreie Grammatik und Rechtschreibung istwünschenswert, hat allerdings keine direkte Auswirkung auf das Endprodukt. InZeiten der automatischen Rechtschreibprüfung sind diese Fehler im Kontakt mitKunden besonders peinlich und können die Kompetenz des Entwicklerteams inFrage stellen. Eine fehlerfreie Grammatik beugt Missverständnissen vor. Sprach-liche Richtlinien verbieten z.B. unerwünschte Konstruktionen wie Passivsätze. Be-grüdnung: dort treten häu�ger Unklarheiten als in Aktivsätzen auf. Oder die Be-nutzung von �den Meisten�, �vielen� oder �einigen� wird verboten, um logischeLücken zu vermeiden.Textbasierte Metriken sind automatisch erhebbar. Auf Grund der Fülle der The-matik erfolgt eine gesonderte Betrachtung in Kapitel 5.3.

6. Redundanz, Vollständigkeit undWiderspruchsfreiheit:Dokumente müssenvollständig sein. Redundanz schadet allerdings, da eventuell der Kernpunkt derAussage nicht mehr erkennbar ist und Unübersichtlichkeit droht, Mehraufwandentsteht und die Wahrscheinlichkeit für Inkonsistenzen steigt. Widersprüche undfehlende Angaben müssen behoben werden, da sonst keine Weiterverarbeitungmöglich ist.Diese Fehler sind nur manuell festgestellbar. Sobald eine Information fehlt, ist dasQG nicht bestanden. Ebenso wird bei einem Widerspruch verfahren. Redundanzensollen vermieden werden, sind aber kein KO-Kriterium.

Anzahl_fehlende_Angaben+Anzahl_Widersprueche ≤ Grenzwert (5.5)

Der Grenzwert ist Null.

7. Testfälle: Die Produktabnahme durch den Kunden erfolgt auf Grundlage von er-folgreichen Testfällen. Das Verständnis von Kunden und Entwicklern, wann einegewünschte Funktionalität umgesetzt ist, unterscheidet sich oft. Zur rechtlichenAbsicherung und Kon�iktvermeidung werden Abnahmetests vereinbart. Im ak-tuellen FeatureSpeci�cation-Template ist eine Au�istung von Testfällen vorgese-hen. Allerdings wird das Template nicht korrekt genutzt (siehe Kapitel 3.3.2: eswerden keine Testfälle eingetragen). Durch eine regelkonforme Nutzung kann hierschnell und einfach Abhilfe gescha�en werden.Jeder Aspekte einer Anforderung muss durch einen Testfall abgedeckt werden. Nurein manuelles Review kann dies feststellen. Hinweise auf fehlende Testfälle kannfolgende Metrik geben:

Anzahl_Testfaelle

Anzahl_Absaetze_des_ersten_Kapitels> 1 (5.6)

Für jeden Absatz muss mindestens ein Testfall vorhanden sein. Grundlage derMetrik ist die Annahme, dass in jedem Absatz ein Aspekt der Anforderung beschrie-ben wird. Ein Grenzwert deutlich gröÿer als 1 ist möglich: eine groÿe Anzahl anTestfällen ist vorteilhaft. Wobei es auch Absätze geben wird, die eine nähere Erk-lärung bereits beschriebener Sachverhalte enthalten und damit keine neuen Test-fälle erfordern. Die Werte sind automatisch erhebbar. Dies ist ein Beispiel für eine

37


verwaltungsbasierte Metrik im Gegensatz zu den textbasierten Metriken aus Frage5. Wichtig ist, dass es für jeden Testfall einen quanti�zierten SOLL-Werte gibt.Nur so kann der Tester entscheiden, ob der Testfall erfolgreich durchlaufen wurde.

8. Prozesseinbettung: Start- und Endbedingungen einer Aktion müssen angegebenwerden. Es gab vermehrt Nachfragen zu den Zielobjekten und -daten, sowie dennotwendigen Randbedingungen und dem Work�ow beim Abbruch der Aktion.Meist wird die (unbeliebte) Aufgabe des FeatureSpeci�cationschreibens so schnellwie möglich abgeschlossen. Daher fehlen Angaben, was nach dem Ende der Aktionpassieren soll (z.B. welche gra�sche Ober�äche angezeigt wird).Eine automatische Prüfung auf Stichwörter wie �Vorbedingung�, �Auslöser� oder�Folgesetting� ist möglich. Fehlen diese, könnte es ein Hinweis auf mangelndeAngaben sein. Eine zusätzliche manuelle Prüfung bei Dokumenten, die als poten-tial fehlerhaft von der automatischen Prüfung eingestuft wurden, kann die nötigeKlarheit bringen. Stellt die manuelle Prüfung fehlende Angaben zur Prozessein-bettung fest, ist das QG negativ beendet. Dokumenten, die mindestens 5 derStichwörter enthalten, werden nicht manuell nachgeprüft.

Anzahl_benutzter_Stichwort > Grenzwert (5.7)

Problematisch sind Situationen wie diese: Ein Autor schreibt zwar �Vorbedingung�,macht aber keine weiteren Angaben. Die autmoatische Prüfung ist bestanden,obwohl das Dokument Mängel enthält. Im praktischen Umgang greift nun Punkt6: das Dokument ist unvollständig.

9. Beispieldaten: Im Gespräch mit TOUCCEA-Mitarbeitern wurde deutlich, dasssehr häu�g Beispieldaten und -szenarios erfragt werden, um bei den komplexenPlattform-Prozessen die Anforderung richtig zu verstehen.Eine automatische Prüfung kann ermitteln, ob es Beispieldaten gibt. Die An-forderungsbeschreibung wird auf das Wort �Beispiel� ge�ltert (Vergleiche Punkt2). Es ist möglich die Anhänge einer Anforderung auf dem Team Foundation Serv-er auf Beispieldaten zu überprüfen. Ob die angegeben Daten ausreichend sind, istnur manuell prüfbar und wird selbst dort von Tester zu Tester variieren. Be�ndetein Reviewer die Daten für ausreichend ist das QG bestanden.

10. Detaillierungsgrad: Im Vordergrund hierbei geht es um die Kommunikation mitden Kunden. Diese ist nicht e�ektiv möglich, wenn der Detaillierung zu fein ist.Daher steht der Punkt im Zusammenhang mit der zweiten Frage (keine Entwurfs-,Architektur, Design- und Implementierungsentscheidungen). Ein weiterer Faktorist die Übersichtlichkeit und Lesbarkeit des Dokuments. Der doch sehr sperrigeund allgemein gehaltene Punkt wurde von Mitarbeitern vielfach als sehr wichtigbezeichnet, obwohl keine passende De�nition für �angemessener Detaillierungs-grad� angegeben wurde. Eine allgemeine, nicht zu umfangreiche Lösung scheintnicht in Sicht, da die Anforderungen ein sehr groÿes Spektrum abdecken.Dieser Punkt soll auch verhindern, dass die Anforderungsbeschreibung eine kom-plette Dokumentation im Sinne eines Handbuchs ist. Das wird von einer eige-nen Abteilung erstellt. Ob ein angemessener Detaillierungsgrad verwendet wurde,kann über die Anzahl der Wörter der Spezi�kation im Verhältnis zum geschätzten

38


Implementierungsaufwand in PersonenTagen abgeschätzt werden. Nachdem diePersonentage geschätzt wurden, kann der Werte automatisch erhoben werden.

Grenzwert_A ≤ Anzahl_Woerter

geschaetzte_PersonenTage≤ Grenzwert_B (5.8)

Dabei sollte der Wert sich zwischen zwei Grenzwerten A und B bewegen: Esgibt Anforderungen, die sehr kurz formuliert sind und viel Zeit in der Umset-zung brauchen. Der Quotient wird also aus einem kleinen und einen groÿen Wertgebildet. Es ergibt sich ein kleiner Wert für A. Der Wert sollte allerdings nicht zuklein sein, da dies ein Hinweis auf eine zu kurze Anforderungsbeschreibung mitzu groben Detailierungsgrad ist. Andererseits sollte der Quotient nicht zu groÿwerden (Grenzwert B), da dann von einem zu feinen Detaillierungsgrad ausge-gangen werden kann: für eine feingranulare Beschreibung sind sehr viele Wörternotwendig.

Wie man sieht ist die automatische Messbarkeit eingeschränkt. Viele Werte können nurvon geschultem Personal erhoben werden und sind damit teuer und zeitintensiv. Deshalbnoch einmal der Hinweis auf die gra�schen Darstellung (z.B. Sequenzdiagramme). Frage7 ist dort leicht automatisch messbar: z.B. Anfangs- und Endbedingungen müssen miteiner bestimmten syntaktischen Konstruktion deklariert werden. Wenn diese Deklarationfehlt, fehlen Anfangs- und Endbedingung, das QG ist nicht bestanden.

Die folgende Tabelle zeigt mit welcher Frage der jeweiligen Qualitätsaspekte erreichtwerden soll. Gekennzeichnet wird dies durch ein �X�.

Qualitätsaspekt

Frage

1.Dopplungen

2.Abw

esenheitvonEnt...

3.Begri�sklarheit

4.Sonderfälle

undAlter...

5.Sprachliche

Korrektheit

6.Redundanzen

7.Testbarkeit

8.Prozesseinbettung

9.Beispieldaten

10.Detailierungsgrad

vollständig X X Xkorrekt X X X

klassi�zierbarkonsistent Xprüfbar Xeindeutig X X X X Xverstehbar X X X X X X

gültig und aktuell Xrealisierbarnotwendig Xverfolgbarbewertet

39


Einige Bemerkungen zu obiger Tabelle. Insbesondere soll begründet werden, warum vierZeilen kein Kreuz enthalten. Es fällt auf, dass jede Spalte mindestens ein Kreuz enthält.Damit wird jede Frage zur Abdeckung der Qualitätskriterien benötigt.

• Vollständigkeit: Eine Betrachtung der Vollständigkeit muss hier nur untergeordneterfolgen. Im Requirements Engineering wird damit das Au�nden aller Anforderun-gen bezeichnet. Im Fall von TOUCCEA handelt es sich bei den Anforderungenum Erweiterungen einer laufenden Software. Der Work�ow des Kunden soll mitder Plattform abgebildet werden, wo dies nicht möglich ist, ergibt sich eine neueAnforderung. Man kann davon ausgehen, dass der Kundenprojektleiter alle An-forderungen im Team Foundation Server einträgt. Die Vollständigkeitsde�nitionvon Chris Rupp ist etwas anders gelagert: ist eine Anforderung mit allen Aspektenbeschrieben.

• Korrekt: Der Kunde soll die FeatureSpeci�cation unterschreiben und hat damitdie Möglichkeit fehlerhafte Darstellungen zu korrigieren.

• Klassi�zierbarkeit: rechtliche Aspekte werden auf Grund fehlendem juristischenWissen nicht betrachtet.

• Konsistenz: Die Frage bzgl. der Konsitenz gegenüber allen anderen Dokumentenhat i.A. groÿe Bedeutung. Für das 1. Kapitel ist sie allerdings nicht relevant, dabei der Existenz von nur einem Dokument keine Inkonsistenzen möglich sind.

• Realisierbar: diese Forderung lässt sich auf den TOUCCEA-Prozess nicht abbilden.Die Autoren sind Techniker mit Domänenwissen des Kunden. Sie kennen nur grobdie technische Aspekte der Plattform und können daher die Realisierbarkeit nichteinschätzen. Es ist die Aufgabe des Programm Manager nicht realisierbare An-forderungen zu entfernen. Der Product Manager erledigt selbiges für Anforderun-gen, die aus strategischer Sicht nicht realisiert werden.

• Verfolgbarkeit: wer was an welchem Dokument gemacht hat, ist durch den TeamFoundation Server einsehbar. Eine ID enthält nur eine Anforderung.

• Bewertet: da in einem Dokument nur eine Anforderung beschrieben wird, gibtes keine Priorisierung innerhalb eines Dokuments. Die Priorisierung verschiedenerDokumente miteinander ist nicht Aufgabe der Autoren, sondern des Produktman-agements.

40

5.3. Bestimmung und Verbesserung der Qualität natürlichsprachlicher Dokumente

5.3. Bestimmung und Verbesserung der Qualität

natürlichsprachlicher Dokumente

Im Folgenden werden vier verschiedene Ansätze beschrieben.

5.3.1. ... mit MS Word

MS Word kann für ein Dokument eine Lesbarkeitsstatistik erstellen. Es wird die durch-schnittliche Anzahl von Wörter pro Satz und Sätze pro Absatz ermittelt. Für Englis-che Texte gibt es weitere Messungen wie die Anzahl der Passivsätze. Diese sollen ver-mieden werden, da oft der Auslöser einer Aktion nicht benannt wird und damit wichtigeInformationen fehlen. Der überwiegende Anteil der Dokumente von TOUCCEA ist inDeutsch, es gibt aber auch englische Dokumente.Die Erhebung der Werte ist sehr einfach: man startet die Rechtschreib- und Gram-matikprüfung. Sobald diese beendet ist, wird die Lesbarkeitsstatistik angezeigt. LangeSätze und wenig Absätze erschweren die Verständlichkeit und führen zu Verwirrun-gen. Daher ideal gilt eine durchschnittliche Satzlänge von 10 - 15 Wörter als ideal.Bei der Analyse einiger FeatureSpeci�cations, gab es Doumente mit durchschnittlich 5Wörtern pro Satz, welche mit 10-15 und welche mit 20 Wörter pro Satz. Damit gibt esVerbesserungspotential.

5.3.2. ... mit einem Lesbarkeitsindex

Es gibt verschiedene Formeln zur Berechnung der Lesbarkeit eines Textes. Lesbarkeitbezieht sich hier nicht auf Typogra�e, also Schriftart und -gröÿe, sondern ausschlieÿlichauf den Satzbau und den Sprachstil. Eine angemessene Schriftart und -gröÿe werden vomFeatureSpeci�cations-Template vorgegeben. In dem Maÿe in dem ein Text lesbar ist, ister auch verständlich und nachvollziehbar. Die Erhebung der Werte ist aufwändiger unddie Ergebnisse aussagekräftiger, da als Grundlage zusätzlich zu der Anzahl der Wörterund Sätze, die Anzahl der Silben pro Wort in die Berechnung einbezogen wird.Ein Beispiel ist der Lesbarkeitsindex Flesch Reading Ease.

FRE =206, 835− (1, 012 · durchschnittliche_Satzlaenge)

− (84, 6 · durchschnittliche_Silbenanzahl

Diese Metrik bezieht sich auf die englische Sprache. Folgende Formel bietet vergleichbareAussagen für deutschsprachige Texte (hier sind die Wörter länger als im Englischen, aberdie Sätze ungefähr gleichlang):

FREDeutsch =180− durchschnittliche_Satzlaenge)

− 58, 5 · durchschnittliche_Silbenanzahl

Je gröÿer die Zahl, destso leichter ist der Text lesbar. Gut verständliche Texte habeneinen Wert von 60 bis 70. Eine akademische Abhandlung liegt zwischen 0 und 30, also

41


deutlich tiefer. Der Abschnitt 5.3.1 über MS Word hat einen Lesbarkeitsindex von 501.Für verschiedene TOUCCEA-Dokumente wurde ein Flesch-Wert von 18 bis 71 gemessen.Teilweise gibt es also deutliches Verbesserungspotential. Es gibt mehrere kostenlose On-linetools, die einen Lesbarkeitsindex nach Flesch Reading Ease berechnen:

• Der bereits erwähnte www.leichtlesbar.ch

• www.presseanzeiger.de/service/textanalyse/presse.php

• www.zudila.ch/beispiel/lesbarkeit.php

• www.it-agile.de/stil/bericht.html

Au�ällig ist, dass jedes Programm einen geringfügig anderen Wert berechnet. Über diegenauen Gründe und Folgen könnte hier nur spekuliert werden.

Weitere und sehr ähnliche Verfahren dieser Art sind GFI (Gunning Fog Index), Coleman-Liau oder das Flesch-Kincaid Grade Level.

5.3.3. ... mit einer lexikalischen, syntaktischen und semantischenTextanalyse

Ein Text kann unter verschiedenen Gesichtspunkten betrachtet werden: man untersuchtdie Wortwahl (lexikalische Analyse), die Art und Weise Wörter zu Sätzen zusammen-zusetzen (syntaktische Analyse) und die Bedeutung der Sätze (semantische Analyse).Diese Methoden stammen aus der Linguistik.

[Lam05] stellt folgendes Qualitätsmodell für Anforderungen auf:

• Ein Text soll hohe Aussagekraft haben, d.h. er ist gut verständlich.

• Ein Text sollKonsistenz haben, d.h. es gibt keine in sich widersprüchlichen Sätzebzw. keine Widerspüche zu andern Sätzen.

• Ein Text soll Vollständigkeit haben, d.h. es fehlen keine Informationen.

Diesen Zielen stehen Defekte lexikalischer, syntaktischer und/oder semantischer Naturentgegen. Nach der Analyse und Fehler�ndung (Defekt�ndung), können sie behobenwerden und damit die Qualität des Texts gesteigert werden.

Tabelle 5.1 zeigt, welche lexikalische Schwachstellen können auftreten.

Defekt Beispiel Begründung

vage Wörter einfach, schwer, gutkeine hohe Aussagekraft, weilentsprechende Sachverhalte nichtquanti�zierbar sind

subjektive Wörter ähnlichkeine hohe Aussagekraft, da persön-liche Meinungen oder Gefühle aus-gedrückt werden

optionale Wörtern eventuell, wenn möglichkeine hohe Aussagekraft, da Inter-pretationsspielräume entstehen

1berechnet nach www.leichtlesbar.ch

42


Defekt Beispiel Begründung

Demonstrativpronomen dieseroft ist nicht klar, welches dasBezugswort ist

schwache Verben kann, darfkeine hohe Aussagekraft, da Inter-pretationsspielräume entstehen

Verallgemeinerungen

Flüsse, unklar bleibt obDaten-, Kontroll- oderMaterial�üsse gemeintsind

Aussage bleibt unvollständig

Universallquantoren alle, keineMeist unüberlegt eingesetzt, sodassSonderfälle übergangen werden

Tabelle 5.1.: Lexikalische Schwachstellen

Folgende syntaktischen Schwachstellen können auftreten:

• Grammatikfehler

• [Lam05] ordnet Verallgemeinerungen und Demonstrativpronomen den syntaktis-chen Schwachstellen zu. Es handelt sich um einzelne Wörter, deren fehlerhafteNutzung nur durch Analyse der Syntax gefunden werden kann. Beispiel: �EinePerformanceerhöhung ist kein Teil dieser Anforderung.� Hier ist klar, worauf sichdas �dieser� bezieht, weil es durch �Anforderung� näher erläutert wurde. Dafürmuss der gesamte Satz betrachtet werden. Das Demonstrativpronomen ist kritischzu sehen, da eine Weiterverarbeitung des Textes zu einer geänderten und damituneindeutigen Wortreihenfolge führen kann.

• Die Existenz zweier Vollverben oder mehrerer Subjekte in einem Satz erhöht dieKomplexität und senkt die Verständlichkeit und Aussagekraft.

• Bei der Nutzung von Passivsätzen wird meist der Auslöser der Handlung nichtbenannt. Damit ist die Anforderung nicht vollständig beschrieben.

• Unvollständig spezi�erte Verben, d.h. bei einem Verb fehlen Objekte, die notwendigsind um den Sachverhalt lückenlos zu beschreiben. Beispiel: �Eine Abbruchbestä-tigung wird gesendet�. Es stellt sich die Frage wer dies tut und wer der Empfängerist.

• Unvollständige Vergleiche und Steigerungen, d.h. es fehlen Vergleichsobjekte.Beispiel: �Es muss schneller gehen.� Es stellt sich die Frage �Schneller als was?�.Mängel dieser Art haben Auswirkung auf die Testbarkeit einer Anforderung.

Eine geringe Lesbarkeit ist eine semantische Schwachstelle. Siehe dazu Kapitel 5.3.2.

Allgemein kann festgestellt werden, dass lexikalische Fehler am leichtesten zu �ndensind. Da nur einzelne Wörter betrachtet werden müssen. Von syntaktischen zu seman-tischen Fehlern ergibt sich eine Steigerung der Schwierigkeit im Au�nden, da komplexereStrukturen betrachtet werden müssen.

43


Werkzeuge zur lexikalischen Textanalyse

• QuARS2 (Quality Analyzer for Requirements Speci�cations) wird von [Lam05]als Werkzeug für automatische Qualitätstests vorgestellt. Als Input wird eine eng-lischsprachige Textdatei (.txt, .dat) gefordert und eine Liste domänenspezi�scherWörter. Standardmäÿig sind Listen für schwache Verben, vage Wörter, subjektiveWörter und optionale Wörter aktiviert. Es ist möglich neue Listen anzulegen. DieErgebnisse werden u.a gra�sch dargestellt. Die Autoren belegen ihren Erfolg an-hand einer Studien über zwei Praxiseinsätze.QuARS ist ein Forschungsprojekt des Software Engineering Institute (SEI), demUS-Verteidigungsministerium und der Universität Pittsburgh. Leider sind die Er-werbsmöglichkeiten ungeklärt.

• ADMIRE3: In seiner Dissertation beschreibt Ralf Melchisedech dieses kostenloseTool. Es arbeitet auf UNIX-Systemen und mit deutschen Texten. Da TOUCCEAmit Microsoftprodukten arbeitet ist eine Nutzung fraglich.

• DESIRe4: Ein sehr vielversprechendes Produkt der deutschen Hood-Group. Eshandelt sich um ein kostenp�ichtiges Word Add-On für deutsche und englischeTexte.

• LEXIOR5: Diese Firma bietet ihren Kunden eine Kombination aus manuellen undautomatischen Reviews englischer Dokumente an.

• Pixref6: Diese Firma ist spezialisiert für den Automobilbau, allerdings kann Pixretauch in anderen Bereichen eingesetzt werden. Entwickelt wurde es für englischeTexte und akzeptiert u.a. Word als Eingabeformat.

• RATSY (Requirements Analysis Tool)7: Diese kostenlose Software arbeitet nur aufdem Betriebssystem Linux. Der zu überprüfende Text muss in englischer Spracheverfasst sein.

• Raven8: Hierbei handelt es sich um das erste kommerzielle Werkzeug dieser Art.Es unterstützt die englische Sprache.

• RequirementsAssistant9: Ein weiteres Produkt für englische Texte.

• RQA10: Diese Firma arbeitet mit DOORS, IRQA oder Excel. Da TOUCCEAWord nutzt, ist es z.Z. nicht attraktiv.

• SAT Cassbeth Inc.11 bietet eine Kombination aus automatischen und manuellenReviews englischer Texte innerhalb von 1-3 Tagen an.

2http://www.sei.cmu.edu/library/abstracts/reports/05tr014.cfm3www.melchisedech.net4http://www.hood-group.com/en/products/tools/requirements-engineering/desirer/5http://www.cortim.com/pageLibre0001010b.html6http://www.pi-innovo.com/products/pixref7www.rat.fbk.eu8http://www.raven�ow.com/product9http://www.requirementsassistant.nl

10http://reusecompany.com11http://www.cassbeth.com/sat/index.html

44


• Smartcheck12: Ebenfalls ein vielversprechendes Werkzeug für englischsprachigeDokumente.

• TigerPro13 Dieses Tool konnte als Probeversion bezogen und getestet werden. DieAnforderungen müssen strikten Strukturvorgaben entsprechen (z.B. ist das erstenZeichen die ID). Dadurch ergeben sich viele Einschränkungen. Alte FeatureSpec-i�cations konnten nicht getestet werden, ohne gravierende Veränderungen an denDatein vorzunehmen um sie den Sturkuturvorgaben anzupassen. Englische Texteim .txt-Format dienen als Arbeitsgrundlage.

Fazit: Die groÿe Anzahl der Werkzeuge ist für englische Texte und nur wenige unter-stützen die deutsche Sprache. Oft müssen strikte Strukturvorgaben eingehalten werdenum Texte überprüfen zu können. Dies würde eine grundlegende Umstrukturierung derAnforderungsdokumente erfordern. Das zur Zeit am besten geeignete Werkzeug ist De-sire: deutschsprachig und kompatibel mit Word.

5.3.4. ...über ein Template

Ein Template verringert die Anzahl der Freiheitsgrade für die Autoren. Dies mag derSchönheit der Texte abträglich sein und mancher Mitarbeiter wird sich gegängelt fühlen,wichtiger ist aber eine Verbesserung der Dokumente durch klare Regeln.

Viele Templates zur Anforderungsdokumentation sind nicht geeignet, da sie Informatio-nen einfordern, die für TOUCCEA nicht relevant sind. Beispiel: Geben Sie die Menge derpotentiellen Leser des Dokuments an! Der Prozess von TOUCCEA gibt aber eindeutigvor, wer die Feature Speci�cations liest. Ein solches Template ist Volere14. Eine An-passung eines Templates ist möglich, allerdings wird der Anteil vom Ausgangstemplateim Endtemplate sehr klein sein. Die Templates sind für Neuentwicklungen konzipiert.Bei TOUCCEA wird kein neues Produkt beschrieben, sondern Weiterentwicklungen derPlattform. Dadurch entfallen viele Kapitel der Templates.

Im Folgenden wird das Vorgehen zur Anforderungsdokumentation von Chris Rupp([Rup04]) beschrieben. Dabei wird die Syntax der Sätze einer Anforderungsbeschreibungvorgegeben (syntaktische Anforderungsschablone). Es gibt 3 Schablonen, was sehr wenigist, angesichts der Vielfalt einer Sprache. Diese geringe Zahl hat sich laut Rupp in Pro-jekten bewährt. Für jede Sprache gibt es eigene Schablonen. Wobei die englische Sprachebesser geeignet ist als Deutsch, weil es in der deutschen Sprache mehr Satzbauarten gibt.So müssen im Deutschen entweder mehr Regeln aufgestellt werden, um alle Konstruk-tionen abzudecken oder man schränkt den Autor stärker ein, indem nur noch wenigeAusdrucksmöglichkeiten erlaubt sind.

12http://www.smartwaretechnologies.com/smartcheck.htm13http://www.therightrequirement.com/TigerPro/TigerPro.html14http://www.volere.co.uk/template.htm

45


5.3.5. Sechs Schritte für gute Anforderungsbeschreibungen

Schritt 1: Am Anfang steht der Prozess

Grundlage einer Anforderung ist eine gewünschte Funktionalität. Funktionalitäten wer-den durch Prozesse (z.B. speichern, senden, berechnen, anzeigen) realisiert.

Machen Sie sich den Prozess klar und wie er durch ein Verben (dem

Prozessverb) beschrieben werden kann!

Die 6 Schritte werden an folgendem Beispiel aus dem TOUCCEA-Alltag verdeutlicht:Eine Anforderung soll beschreiben, dass ein Add-In Attribute einer Funktion speichert,wenn kein Draht angeschlossen ist. Das Prozesswort ist in diesem Fall speichern.

Schritt 2: Charakterisieren der Aktivität des Systems

�Das System� ist im Falle TOUCCEA die Plattform. Eventuell kann es mit Makro, Add-In oder dem Funktionsnamen näher beschrieben werden. Nun werden die drei bereitserwähnten Schablonen relevant: die gewünschte Funktionalität des Systems kann einervon drei Arten zugeordnet werden. Für jede Art gibt es eine Schablone.

1. Selbstständige Systemaktivität: Das System führt den Prozess selbstständig durch.

2. Benutzerinteraktion: Das System stellt dem Nutzer die Prozessfunktionalität zurVerfügung.

3. Schnittstellenanforderung: Das System führt einen Prozess in Abhängigkeit voneinem Dritten (zum Beispiel einem Fremdsystem) aus, ist an sich passiv und wartetauf ein externes Ereignis.

Wählen Sie genau eine der drei vorgestellten Arten aus!

Die drei Anforderungsschablonen haben folgende Struktur:

Abbildung 5.1.: Schablone nach dem 2. Schritt (Quelle: [Rup04], S. 244)

Die Pünktchen im 2. Kasten werden in Schritt 3 ersetzt. Die Abb. 5.1 kann folgender-maÿen gelesen werden:

1. Selbstständige Systemaktivität

46


• Der Benutzer tritt bei diesem Typen nicht auf.

• Anforderungsgerippe: DAS SYSTEM ... <Prozesswort>

• Mit dem <Prozesswort> ist das Verb aus Schritt 1 gemeint.

2. Benutzeraktion

• Ein Nutzer tritt in Interaktion mit dem System.

• Anforderungsgerippe: DAS SYSTEM ... <wem?> DIEMÖGLICHKEIT BIE-TEN <Prozesswort>

• <wem?> bezeichnet welcher Nutzer (z.B. ein Administrator, alle) gemeint ist.Wenn eindeutig ist, wem das System die Funktionalität liefert, kann dieserTeil weggelassen werden. Das <Prozesswort> ist das Verb aus Schritt 1.

3. Schnittstellenanforderung

• Die gewünschte Funktionalität ist von Dritten abhängig (z.B. ein Nachbarsys-tem schickt Daten, die das System ausdrucken soll). In gewissen Situationenkann die Verständlichkeit und Lesbarkeit erhöht werden, wenn die Wortstel-lung in Schritt 3-6 �exibel gehandhabt wird.

• Anforderungsgerippe: DAS SYSTEM ... FÄHIG SEIN <Prozesswort>

• Das <Prozesswort> ist das Verb aus Schritt 1.

Beispiel: Es handelt sich um eine Systemaktivität. Schablone 1 wird genutzt. Das Systemkann näher beschrieben werden durch das Add-In.

Schritt 3: Festlegen der rechtlichen Verbindlichkeit

Zur Festlegung der juristischen Relevanz, wird in der Anforderungsbeschreibung zwis-chenmuss, soll oder wird unterschieden. Diese Modalverben stehen für rechtlich bindend,dringend empfohlen und zukünftige Anforderungen. Bisher wurden bei TOUCCEAsollen und müssen synonym verwendet. Eine Anforderung wird rechtlich bindend, sobaldsie priorisiert wurde. Folglich sollte nur noch müssen verwendet werden. Wichtig istdieser Schritt in Prozessen, bei denen Dokumente mehrere Anforderungen enthalten,die unabhängig voneinander sind. Damit werden die 3 Pünktchen aus Abbildung 5.1ersetzt.

Legen Sie die rechtliche Verbindlichkeit Ihrer Anforderung fest!

Beispiel: die rechtliche Verbindlichkeit ist müssen, weil immer müssen gewählt werdenmuss.

Schritt 4: Feinschli� für den Prozess: Objekte und Ergänzungen

Bisher wurde der Kern einer Anforderung formuliert, es fehlen noch nähere Bestim-mungen (Objekte). Bei dem Prozesswort �senden�, stellt sich beispielsweise die Frage

47


wem was wann gesendet werden soll. Berücksichtigen Sie die vorgegebene Syntax nachAbb. 5.2!

Fügen Sie fehlende Objekte und Ergänzungen hinzu!

Abbildung 5.2.: Schablone nach dem 4. Schritt (Quelle: [Rup04], S. 247)

Beispiel: Was wird gespeichert? - das Attribut x

Schritt 5: Formulierung von logischen und zeitlichen Bedingungen

Viele Funktionalitäten hängen von Bedingungen ab. Diese können zeitlicher oder kondi-tionaler Natur sein. Im Folgenden soll immer wenn für zeitliche und falls für konditionaleBedingungen gewählt werden.

Ergänzen Sie Randbedingungen durch Nebensätze, die an den Anfang der

Anforderungsbeschreibung gesetzt werden.

Beispiel: falls kein Drah angeschlossen ist

Schritt 6: Anwendung des Regelwerks für natürlichsprachliche Dokumente:Prüfung der bisherigen Ergebnisse

Wenden Sie das Regelwerk auf Ihre Anforderung an!

Wurden die Sätze mit der Schablone konstruiert, handelt es sich bei Schritt 6 um Fein-heiten. Hauptsächlich zielt dieser Punkt auf die Objekte. Da diese vom Autor freiangegeben werden können, müssen Unvollständigkeiten und Inkonsistenzen noch aus-geschlossen werden.

48


Abbildung 5.3.: Die vollständige Anforderungsschablone (Quelle: [Rup04], S. 248, leicht

bearbeitet)

Beispiel: Die konstruierte Anforderung wird aus den Teilen zusammengesetzt: Falls keinDraht angeschlossen ist, muss das Add-In das Attribut x speichern.

Beispiel für Schablone 2: Falls der Benutzer die Revisionsverwaltung kon�guriert, mussdas System dem Benutzer die Möglichkeit bieten die Highlighting-Farben einzustellen.Beispiel für Schablone 3: Wenn das Makro gestartet wird, muss das Makro fähig sein,seine Kon�guration zu speichern und und diese Kon�guration beim Start verwenden.

5.3.6. Erweiterung der Schablone

Die Qualitätsverbesserung kann durch eine Erweiterung der Schablone noch weitergesteigert werden. Folgende Erweiterungen gibt es:

• Semantische De�nitionen

• Strukturierung der Vorbedingungen

Semantische De�nitionen

Ziel ist es, dass unterschiedliche Personen, bei der Formulierung eines Sachverhalts aufden gleichen Satz kommen. Praktisch werden keine identischen Sätze entstehen, abersie sollen sich soweit wie möglich ähneln. Oft kommt es vor, dass Menschen beim Leseneines Satzes verschiedene Sachverhalte verstehen.Beispiel: Person A sagt: �Ich war gestern abend bei strahlendem Sonnenschein im Bier-garten ein herrlich kühles Bier trinken.�Person B versteht: �Oh wie toll war das Wetter bei Person A, er/sie hatten Sonnen-schein.�Person A wollte ausdrücken, dass er/sie nach 7 Wochen Fastenzeit endlich wieder Biertrinken durfte.Solche Missverständniss beim Plausch sind ärgerlich, aber harmlos. Versteht der Ent-wickler die Anforderungen des Kunden falsch, kann dies hingegen zu teuren Vertragsver-letzungen führen. Deshalb soll sichergestellt werden, dass jeder Mitarbeiter den selbenSachverhalt als Grundlage eines geschriebenen Satzes erkennen. Wenn nun Mitarbeiterzur Abbildung eines Sachverhalts den gleichen Satz schreiben, besteht die Ho�nung, dass

49


andere Mitarbeiter beim Lesen des Satzes den korrekten Sachverhalt verstehen, weil siewissen, ob aus dem erkannten Sachverhalt dieser Satz abgeleitet werden kann. Kannder Satz nicht aus dem Sachverhalten abgeleitet werden, wurde der Sachverhalt falschverstanden. Der Entwickler muss ein neues Verständnis für den Satz ableiten. Wenndie Mitarbeiter einen gleichen Wissen-Schreiben-Prozess haben, kann es einen gleichenLesen-Verstehen-Prozess geben. Und damit zieht der Leser genau die Schlussfolgerungenaus einem Text, die der Autor weitergeben wollte.

Dafür wird der zur Verfügung stehende Wortschatz begrenzt und die Bedeutung derWörter eindeutig de�niert. Es kann eine Liste mit möglichen Prozessverben geben.Wird eine Funktionalität beschrieben, wird nur dieses Wort verwendet! Zum Beispielwird im Zusammenhang mit Warntönen erklingen verwendet. Dann ist es verboten �einWarnsignal muss ertönen� zu schreiben. So entstehen keine literarisch hochwertigenTexte, aber das ist nicht das Ziel. Die Lesbarkeit wird nicht eingeschränkt. Für jedesProzesswort kann angegeben werden, welcher Schablone sie zugeordnet werden können.Dadurch sollen Dokumente schlanker werden, wobei die TOUCCEA-Dokumente bereitsverhältnismäÿig kurz sind (1-3 Seiten im Vergleich zu einem Spezi�kation eines komplettneuen Systems). Der Mehrwert für die Firma ist also fraglich. TOUCCEA kann aucheine Liste mit Wörtern anlegen, die in das Schema <wem?> passen.

Die Mitarbeiter müssen die Tabellen kennen. Diese sind für alle bindend. Für eine opti-malen Nutzung werden die Listen adaptiv erweitert. Man kann wenige, oft fehleranfälligeWörter au�isten. Diese dürfen, dann nur in einer festgelegten Bedeutung benutzt wer-den. Es ist nicht zwingend dieses Wort zu verwenden. Eine leichte Realisierung kannüber ein Word-Add-On gelingen: sobald ein de�niertes Wort verwendet wird, erscheintein gelber Balken mit einem Hinweis über dem Cursor (ähnlich der Worddatumsvervoll-ständigung).

Denkbar ist auch eine Autovervollständigung wie sie z.B. der Texteditor Kile für LATEX-Befehle anbietet: optionale Übergabeparameter stehen in eckigen Klammern([]) undbenötigte Übergabeparameter in geschweiften Klammern ({}). Der Autor muss wissen,welche Attribute ergänzt werden müssen und welche können. Mit etwas Übung erleich-tert das die Arbeit sehr. Für die Speci�cation ist die gleiche Vorgehensweise möglich,wobei statt Übergabeparameter Objekte ergänzt werden.

Strukturierung der Vorbedingungen

Die ausschlieÿliche Verwendung von wenn und falls ist sehr einschränkend. Die Möglichkeit-en können um nachdem, während und sobald erweitert werden. So können zeitliche Be-dingungen näher untergliedert werden.Vorsicht ist bei und, oder und nicht notwendig. Beispiel: A und B oder C. Es sind zweiLesarten denkbar: erstens (A und B) oder C und zweitens A und (B oder C).Beispiel: Tim und Nina oder Luise gehen tanzen. Da Tanzen ein Paarsport ist, wird hierTim und Nina oder Tim und Luise gemeint sein (Version 2). Denkbar ist auch, dassLuise Nina nicht mag und deshalb nur zum Tanz geht, wenn Tim und Nina nicht anwe-send sind (Version 1). Beide Varianten sind möglich, damit gibt es einen unerwünschtenInterpretationsspielraum.

50


Hier sieht man den Unterschied zwischen dem mathematischen ODER und dem um-gangssprachlichen ODER, dass meist als XOR (entweder... oder) verstanden wird. [Rup04]schlägt vor die mathematischen Bezeichner zu verwenden (XOR, NOR, OR etc.). Sokann es zu keinen Missverständnissen kommen. Allerdings verringert dies die Lesbarkeitentscheidend und sollte daher vermieden werden. Eine bessere Darstellungsform für ver-schachtelte Anforderungen sind Entscheidungstabellen oder Zustandsautomaten.

5.3.7. Das SOPHIST REgelwerk

Dieses Regelwerk ist Bestandteil der Schablone. Es kann aber auch angewendet werden,wenn die Schablone nicht zum Einsatz kommt. Im Folgenden wird es vorgestellt. Einausführliches TOUCCEA-Beispiel zur Verdeutlichung der Vorteile der beschriebenenVorschläge wird in Kapitel 5.4 gegeben.

Grundlage des Regelwerks sind Erkenntnisse aus der Linguistik, Informatik, Psycholo-gie und Psychotherapie. Um die ankommende Informations�ut beherrschen zu können,führt das Gehirn eine Reduktion der Datenmenge durch. Dabei ist der Verlust fürdie Anforderungserhebung wichtiger Informationen zu vermeiden. Folgende konkretenPhänomene treten auf:

Phänomen Beschreibung BeispielTilgung Der Mensch reduziert die Ein-

drücke auf verarbeitbare Aus-maÿe. Manche Gegebenheitennehmen wir war, andere überse-hen wir.

An der Kühltheke sehen wirWurst, Käse und Joghurt. InWirklichkeit stehen vor uns 20verschiedene Sorten Wurst, Käseund Joghurt. Dies ist irrelevant,wenn wir die Butter suchen.

Generalisierung Dies ist der Schritt aus einemkonkreten Objekt Eigenschaftenfür eine gesamten Kategorie zuziehen.

Die heiÿe Herdplatte: hat maneinmal sich an einer verbrannt,weiss man, dass eingeschalteteHerdplatten zu meiden sind. Vo-rausgesetzt man besitzt keinenHerd mit Induktionsfeldern.

Verzerrung Bei diesem Prozess werdenEinzelheiten von Erfahrungenumgestaltet (möglicherweiseauch verfälscht).

Der Ausschalten des Computers:hier wird ein komplexer Prozess,der eine gewisse Zeitspanne ein-nimmt, verkürzt zu einer punk-tuellen kurzen Aktion

Tabelle 5.2.: Phänomene der menschlichen Informationsverarbeitung

Die dararaus resultierenden Probleme wurden in Abschnitt 5.3.3 erläutert. Hier sollder Schwerpunkt nicht auf der automatischen Fehlersuche liegen, sondern auf manuellerSelbstkontrolle der Autoren. Dafür werden die Regeln des SOPHIST-REgelwerks (gekürzt)dargestellt. Teile der Begründung können sich mit bereits vorgestellten Begründen dop-peln. Sie werden hier erneut beschrieben, damit der geneigte Leser nicht wiederholt hin-

51


und herblättern muss.

Die Au�orderungen 1-9 vermeiden Symptome von Tilgungen. Es folgen Au�orderungengegen Generalisierungen (Nr. 10-17) und abschlieÿend Methoden gegen Verzerrungen(Nr. 18-26).

1. Formulieren Sie jede Anforderung im Aktiv!Begründung: In Passivsätzen wird häu�g der Auslöser nicht angegeben. Damit istdas Prozessverb nicht vollständig spezi�ziert.Bsp: Das Passwort wird überprüft. - Von wem?

2. Drücken Sie Prozesse durch Vollverben aus!Begründung: Komplizierte Satzkonstrukte und Adjektive trüben den Blick für dieHauptaussage eines Satzes.Bsp: Zwischen den Nutzern muss eine Unterscheidung vorgenommen werden. - Inder einfachen Konstruktion �Die Nutzer müssen unterschieden werden� fällt gleichauf, dass die Unterscheidungskriterien fehlen.

3. Decken Sie unvollständig spezi�zierte Prozesswörter auf!Begründung: Wurden nicht alle möglichen Objekte angegeben, fehlen eventuellwichtige Angaben.Bsp: Selbes Beispiel wie eben. Die Angabe aller möglichen Objekte ist manchmalnicht zielführend, da die Lesbarkeit eingeschränkt werden kann. Ziel ist es, dassder Autor sich bewusst macht, welche Objekte (Angaben) fehlen und prüft, dassdiese nicht wichtig sind.

4. Ermitteln Sie unvollständige Vergleiche und Steigerungen!Begründung: In diesen Fällen sind häu�g keine Abnahmetests möglich. BesondersAussagen wie �leicht durchführbar� oder �schnell� sind sehr subjektiv. Wenn derKunde keine präzisen Angaben machen kann, ist ihm eventuell noch nicht klar,wie sein Produkt aussehen sollBsp: Die Zugri�srechte des Nutzers sollen vom Administrator leicht erweitert wer-den können. - leicht verglichen womit?

5. Klären Sie Mögliches und Unmögliches!Begründung: Bei negativ formulierten Anforderungen (d.h. es darf <Aktion> nichtpassieren) muss angegeben sein, wer die <Aktion> verhindert. Es handelt sichnicht um Funktionalitäten, sondern um Details. Damit ist im Sinne der Lesbarkeitsparsam umzugehen. Die Au�orderung zielt auch auf die Realisierbarkeit einerAnforderung ab. Um die Au�orderung nicht zu überfrachten, sollte dieser Aspektals untergeordnet betrachtet werden.Bsp: Hilfsarbeiter können keine Veränderungen an den Druckereinstellungen vor-nehmen. - Hier fehlt eine Angabe wer Hilfsarbeiter von weiteren Angestellten un-terscheidet.

6. Prüfen Sie die Modaloperatoren der Notwendigkeit (z.B. müssen, sollen) auf benötig-te Ergänzungen!Begründung: Dit dieser Au�orderung sollen Ausnahmefälle abgedeckt werden: Waspassiert, wenn eine Funktionalität nicht gewährleistet werden kann? Das Systemsoll wahrscheinlich nicht abstürzen. Werden diese Sonderfälle intensiv betrachtet,

52


wird das System gegenüber kleinen Störungen der Umgebung resistent.Bsp: Die Freischaltung der erweiterten Nutzungsrechte soll nicht länger als 5Minuten dauern. - Und was passiert, nach 5:01 Minuten?

7. Finden Sie implizite Annahmen!Begründung: Implizite Annahmen sind Fakten, die ein Experte als bekannt vo-raussetzt. Der Kunde ist hier der Experte. Es ist fraglich, ob der Entwickler diesesWissen auch hat (bei einem Produkt wie die Plattform mit ihren mannigfalti-gen Einsatzmöglichkeiten ist dies meist nicht gegeben). Implizite Annahmen sindschwer au�ndbar und ein fachfremder Reviewer hat dazu die besten Chancen. Hil-freich sind auch Informationen aus Bemerkungen: unbewusst und in entspannterAtmosphäre werden Annahmen erwähnt. So emp�ehlt Rupp Zigaretten- und Kaf-feepausen. Desweiteren gilt besondere Aufmerksamkeit den Beziehungen zwischenObjekten. Ein mögliches Vorgehen, um die Annahmen herauszu�ltern, ist es, denSatz negativ zu formulieren. Dadurch ergibt sich eine neue Sicht auf die Sachlage.Bsp: Der Benutzter druckt die Seite. => Der Benutzer druckt die Seite nicht.Manfragt sich, warum die Seite nicht gedruckt werden kann. Es wurde die implizite An-nahme getätigt, dass ein Drucker existiert.

8. Formulieren Sie eine neue Anforderung, falls das Verhältnis zwischen mehrerenObjekten etwas Wesentliches darstellt.Begründung: Damit sollen implizite Angaben ergänzt werden.Bsp: Nach dem Einloggen kann der Hilfsarbeiter eine Übersicht aller gearbeite-ten Stunden ansehen. - Hier ist die implizite Annahme, dass solch eine Übersichtexistiert. Das Problem lässt sich lösen, indem eine neue Anforderung formuliertwird: Das System bietet dem Hilfsarbeiter die Möglichkeit eine Übersicht über allegearbeiteten Stunden einzusehen.

9. De�nieren Sie einen neuen Begri�, falls das Verhältnis zwischen mehreren Objek-ten etwas Wesentliches darstellt. Vergessen Sie nicht einen neuen Glossareintraganzulegen.Begründung: Hat dieses Wesentliche einen Namen lässt es sich besser handhaben.Bsp: Selbes Beispiel wie eben- Die Übersicht über alle gearbeiteten Stunden wirdals eine Leistungau�istung deklariert.

10. Bestimmen Sie die Universalquantoren! Diese sind nie, immer, kein, jeder, alle,nichts.Begründung: Fragen Sie sich, ob der Universalquantor wirklich passend ist. Gibtes keine Ausnahmen, die einer separaten Spezi�zierung bedürfen? Gibt es zu je-dem Verhalten eine klar beschriebene Menge von Objekten, die betro�en sind?Universalquantoren sind nicht per se schlecht, der Autor soll nur die Verwendungüberprüfen und bewusst beschlieÿen.Bsp: Der Nutzer hat die Möglichkeit alle geö�neten Dateien auszudrucken. - Wärees nicht sinnvoll eine Bestätigung des Nutzers zu fordern für Dateien mit mehr als20 Seiten?

11. Verwenden Sie nur de�nierte quantitative Angaben. Fehlen solche Angaben, kanndies ein Hinweis auf implizite Annahmen sein.

53


Begründung: Möglichkeiten sind: jeder, entweder, immer, oder, kein, alle. Es wirdde�niert, was diese Wörter bedeuten - falls es diesbezüglich Unklarheiten gibtDamit soll nicht der Autor eingeschränkt werden, sondern die Eindeutigkeit derAussagen gewährleistet werden.Bsp: Das System soll durch den Benutzer ... Wer ist hier der Benutzer? Wennjeder Benutzer die Aktion auslösen darf, ist das Wort �alle� passend.

12. Ermitteln Sie unvollständig spezi�zierte Bedingungen: gibt es zu jedem wenn-dannein sonst? Wurde alle möglichen Bedingungen genannt? Ist jeweils das gewünschteVerhalten beschrieben?Begründung: Durch diesen Punkt sollen Generalisierungen gefunden und behobenwerden. Eventuell sind weitere Angaben nicht notwendig und zielführend, wichtigist wiederum, dass sich der Autor der möglichen Lücken bewusst ist und sich aktivfür keine Satzerweiterung entschieden hat.Bsp: Wenn der Kunde eine goldene Mitgliedskarte besitzt, muss seine Reservierunginnerhalb fünf Stunden bearbeitet werden. - Gibt es für andere Kunden auch einemaximale Bearbeitungszeit, was passiert also im sonst-Zweig.

13. Hinterfragen Sie Substantive ohne Bezugsindex!Begründung: Ist bei jedem Substantiv genau klar worum es sich handelt? Hilfreichist eine Frage mit �Wer ... genau?�. Eine mögliche Fehlerquelle sind Wörter wie�das System�, �die Daten� oder �die Meldung�.Bsp: Der Hilfsarbeiter kann die Daten ausdrucken. - Und welche Daten darf erbekommen?

14. Verwenden Sie Substantive stets in der Einzahl, auÿer Sie meinen explizit dieMehrzahl.Begründung: Dies dient der Vermeidung von Unklarheiten.Bsp: Die Möbelpacker tranken einen Ka�ee. - Vermutlich hat jeder Möbelpackereinen Ka�ee getrunken.ABER: Die Möbelpacker trugen ein Klavier. - Vermutlich tragen alle Möbelpackerein Klavier.

15. Quanti�zieren Sie die Substantive!Begründung: Dieser Punkt ist eng verwandt mit dem letzten. Eine erhöhte Klarheitlässt sich durch den Gebrauch von � jeder�, �alle� oder �genau ein� erreichen.Bsp: Eine Grünp�anze soll ohne abgebrochene Blüten ankommen. - Ho�entlichscha�t das Unternehmen es genau eine P�anze umsichtig zu handhaben. Odermöchte der Kunde etwa alle P�anzen unversehrt empfangen?

16. Verwenden Sie die unbestimmten Artikel (ein und eine) nur in einer De�nition!Begründung: Welche Verwirrung eine fehlerhafte Nutzung nach sich zieht, kanndem Beispiel der letzten Regel entnommen werden.Bsp: Eine Bücherkiste ist eine Kiste, die mit �Büchern� beschriftet ist.

17. Verwenden Sie den bestimmten Artikel vor einem Substantiv, das schon de�niert ist!Begründung: Statt einer Mengenangabe, kann der bestimmte Artikel verwendetwerden, wenn klar ist, was bezeichnet wird.Bsp: Das Klavier darf nicht länger als 30 Minuten in einer Umgebung von 15◦ C

54


oder weniger stehen. - Es gibt nur ein Klavier.

18. Hinterfragen Sie Nominalisierungen! Dabei handelt es sich um Substantive, dieeinen Vorgang beschreiben. Stellen Sie sich die Frage, ob Ihr Substantiv in �ein(e)andauernde(r)/kontinuierliche(r) ... � passt. Beschreibt Ihr Substantiv etwas, dassnicht anfassbar ist?Begründung: Bei einer Nominalisierung werden meist zeitlich längere Prozessezu einem Ereignis verkürzt. Dadurch können Informationen des Prozesses ver-loren gehen. Im Allgemeinen sind Nominalisierungen als Abkürzung für komplexeEreignisse nützlich, wenn allen Stakeholdern die De�nition klar ist. Es darf keineInterpretationsspielräume geben. Eine De�nition kann im Anforderungsdokumenthinterlegt werden oder einen Eintrag im Glossar bekommen.Bsp: Eine kontinuierliche �Erstellung�. �Statistik� oder �Meldung�sind nicht anfass-bar.

19. Ersetzen Sie Funktionsverbgefüge durch Vollverben!Begründung: Ein Funktionsverbgefüge ist ein inhaltsarmes Verb(haben, können,haben, sein, machen) in Kombination mit einem Substantiv. Häu�g treten dieseFormulierungen mit Passivkonstruktionen auf. Letztere sind aber zu vermeiden.Auÿerdem leidet die Lesbarkeit unter diesen Konstruktionen.Bsp: Bei der Berechnung des Preises muss die Verwaltung einen Entscheidunganhand der Entfernung zum neuen Wohnort machen. - Hier wird die Konstruktioneine Unterscheidung machen verwendet. Besser wäre unterscheiden. Der neue Satzlautet damit: Die Verwaltung entscheidet bei der Preisberechnung auf Grundlageder Entfernung zum neuen Wohnort.Die folgende Tabelle15 enthält Beispiele für Funktionsverbgefüge.

Funktionsverbgefüge Passivkonstruktion Aktivkonstruktionin Betrieb sein betrieben werden betreibenim Bau sein gebaut werden bauenzu Ende sein beendet sein enden

zu Ende bringen zu Ende gebracht werden beendensich in Anwendung be�nden angewendet werden anwendenBerechnungen anstellen berechnet werden berechneneinen Unterschied machen unterschieden werden unterscheideneine Veränderung erfahren verändert werden verändern

Tabelle 5.3.: Funktionsverbgefüge

20. Entfernen Sie Redundanzen! Das heiÿt Dopplungen und Satzteile ohne Bedeutung.Begründung: Bei verbaler Kommunikation ist Redundanz normal. Im geschriebe-nen Dokument leidet die Übersicht.Bsp: Der Kunde muss jede Kiste, die leicht zerbrechliche Gegenstände enthält, miteinem Aufkleber in gelber Farbe markieren. - Besser wäre: ... mit einem gelbenAufkleber. Gelb ist per De�nition eine Farbe, dies muss nicht doppelt festgehalten

15Quelle: [Rup04], Seite 223

55


werden.

21. Streichen Sie �oskelhafte Wörter und Wendungen.Begründung: Auch hier wird Redundanz abgebaut.Bsp: Es kommt darauf an, dass ... Wenn ... dann.Oder Je nach dem ... Wenn.. dann.

22. Entfernen Sie Nebensätze, die Begründungen, Folgen oder Absichten enthalten!Begründung: Wichtige Informationen sind in einem Hauptsatz zu benennen. JedeAnforderung wird in einem neuen Satz festgehalten. Begründungen können moti-vierend und sinnvoll sein, allerdings sollten sie als Kommentar gekennzeichnet wer-den, da sie kein relevanter Teil einer Anforderung sind. Fehlerhinweisende Wörtersind weil, damit, um und deshalb.Bsp: Alle Gegenstände sind in Bananenkisten zu verstauen! Kommentar: Ziel isteine gute Platzausnutzung auf dem LKW.

23. Nebensätze in einem zeitlichen Verhältnis zum Hauptsatz sollen als Wenn-dann-oder Falls-dann-Satz formuliert werden.Begründung: Wichtige Teile des Satzes sollen schnell erkannt werden. Aus dieserStrukturierung lassen sich leichter Testfälle ableiten. Fehlerhinweisende Wörtersind bevor, während, nachdem, solange, bis und unterdessen.Bsp: Das Klavier darf während des Umzugs maximal 30 Minuten in einer Umge-bung von 15◦ C oder weniger stehen.- Leichter lesbar wäre: Während des Umzugs,darf das Klavier maximal 30 Minuten in einer Umgebung von 15◦ C oder wenigerstehen.

24. De�nieren Sie Substantive nach dem folgenden Schema: Subjekt (=zu de�nieren-der Begri�) + Verb + Objekt(e) + ErgänzungenBsp: Eine Bücherkiste ist eine Kiste, die mit �Büchern� beschriftet ist.

25. De�nieren Sie Adjektive nach dem folgenden Schema: Adjektiv + Hilfssubstantiv+ �ist�+ Hilfssubstantiv + ErgänzungenBsp: Ein zerbrechlicher Gegenstand ist ein Gegenstand, der bei einem Fall aus 1mauf eine Steinplatte irreparabel beschädigt wird.

26. De�nieren Sie Adjektive nach dem folgenden Schema: Verb im In�nitiv + �ist derProzess� + Ergänzungen.Bsp: Ausweisen ist der Prozess bei dem eine Person ihren Personalausweis oderFührerschein vorzeigt.Bemerkung: Häu�g reden verschiedene Stakeholder in gleichen Wörtern, meinenaber verschiedene Dinge. Dieses Problem kann mit der De�nition der häu�gstenbenutzten Wörter vermieden werden.

Verständliche Kommentare können ergänzt werden - mit allen erdenklichen sprachlichenFormen, da sie keine rechtliche Relevanz haben. So können sie einen Einblick in dieEinsatzrealität vermitteln, Beispiele geben oder Sinn und Zweck einer Anforderung er-läutern. Kein Kommentar darf eine unverzichtbare Information enthalten. Es könnenBilder, Gra�ken, Skizzen, Tabellen oder Screenshots eingefügt werden. Meist werdenbeschreibende Informationen benötigt, um die Bilder etc. korrekt zu verstehen. Dierechtliche Relevanz ist mit dem Kunden im Einzelfall zu klären.

56


Nutzung des REgelwerksMan kann in mehreren Iterationen alle sprachlichen Defekte eliminieren. Dazu wird imAlltag die Zeit fehlen, ein gewisser Qualitätsstand ist ausreichend. Dafür wird jederSatz unter jeder Regel betrachtet. Ein rekursives Vorgehen ist empfehlenswert, damitveränderte Sätze auch geprüft werden.Die Fragen können nacheinander oder in beliebiger Reihenfolge bearbeitet werden. Infolgender Häu�gkeit treten Fehler auf:

1. Nominalisierungen

2. Unvollständig spezi�zierte Prozesswörter

3. Substantive ohne Bezugsindex

4. Unvollständig spezi�zierte Bedingungen

5. Modaloperatoren der Notwendigkeit

6. Implizite Annahmen

Daher hat sich folgende Reihenfolge der Fragen laut Rupp bewährt:Block 1: Frage 1,2,3, 7,5,6,19Block 2: Frage 10,11,13,14,15,16,17,18Block 3: Frage 4,8Block 4: Frage 9,20,21,12,22,23

57


5.4. Negativbeispiel

Im folgenden werden die Vorschläge auf eine konkrete Speci�cation angewendet.

Bei einemmanuellen Review auf Grundlage des Fragenkatalogs wären u.a. folgendeSchwachpunkte aufgefallen:

Abbildung 5.4.: Analyse einer FeatureSpeci�cation

Fazit: Die gezeigte FeatureSpeci�cation hat viele Schwachstellen. Hätte sich der Autordie Fragen des Fragekatalogs gestellt, wäre ihm aufgefallen, dass sein Dokument nichtfertig ist. Es hätte in diesem Zustand nicht an den nächsten Mitarbeiter abgegebenwerden dürfen: Anzahl_fehlender_Alternativen = 1 < 0 Widerspruch! Punkt 4 istverletzt.

Bei einer automatischen Überprüfung auf Grundlage des Fragenkatalogs wäre derRechtschreibfehler in der ersten Zeile und der Grammatikfehler in der dritten Zeile aufge-fallen. Weiterhin hätte eine Untersuchung der Links des Features im Team FoundationServer ergeben, dass keine Beispieldaten und keine Testfälle vorliegen. Die automatischeÜberprüfung hätte bemerkt, dass die Prozesseinbettung wahrscheinlich fehlt, da keinesder Stichwörter im Text vorkommt.

58

5.4. Negativbeispiel

Die Lesbarkeitsstatistik von MS Word

Abbildung 5.5.: Lesbarkeitsstatistik

Laut a enthält ein guter Text einenDurchschnittswert 10- 15 Wörterpro Satz. Das erfüllt der Text mitdurchschnittlich 10,3 Wörtern proSatz.ahttp://www.xing.com/net/o�ce-productivity/word-539876/verwenden-der-lesbarkeitsstatistik-fur-bessere-texte-37691109/, Stand:26.3.2012

Weitere Lesbarkeitsstatistikenwww.leichtlesbar.ch ermittelt einen Flesch-Wert von 50. Dies liegt leicht unter denangestrebten 60 - 70. An dieser Stelle wird die Aussagekraft von Statistiken dieser Artsichtbar: der Text hat inhaltlich o�ensichtliche Mängel. Bei einem inhaltlich guten Textkann die sprachliche Prüfung �die letzten 10 Prozent� herausholen. Es ist also eine Kom-bination von Qualitätssicherungsmaÿnahmen notwendig.

Eine automatische lexikalische, syntaktische und semantische Textanalyse kannan diesem Beispiel nicht durchgeführt werden, da kein kostenloses Werkzeug für deutscheTexte zur Verfügung steht.

Im folgenden wird die Anforderungsschablone für den ersten Satz angewandt.Im Schritt 1 wird das Prozessverb festgelegt: übertragen.Es handelt sich um eine Schnittstellenanforderung (Schritt 2).Die Vorgabe ist, dass als rechtliche Relevanz immer müssen gewählt wird (Schritt 3).Als Objekte für übertragen kann ergänzt werden: wer- die Funktion, von wem - demTAD, zu wem - der Plattform, was - angelegte Objekte, wie - als .xml-Datei (Schritt 4).Die logischen und/oder zeitlichen Bedingung fehlen in dem Teil der FeatureSpeci�cation!Hätte der Autor die Schablone verwendet, wäre ihm dies aufgefallen (Schritt 5).Damit ergibt sich folgende Formulierung (Schritt 6): <fehlende Bedingung>, muss dieFunktion fähig sein, angelegte Objekte aus dem TAD an die Plattform als .xml-Dateizu übertragen.Der restliche Text sollte auch nach dem vorgestellten Verfahren überarbeitet werden.

Folgende Regeln des SOPHIST REgelwerks werden missachtet:

• Regel 1 (keine Passivsätze): der Satz �Hierzu wird ... angestoÿen�.

• Regel 7 (implizite Annahme): wenn das Objekt nicht bereits vorhanden ist, wirdes neu angelegt.

• Regel 9 (De�nition von Wesentlichem): genaue Beschreibung des Abnahmepro-

59


tokolls fehlt.

• Regel 11 (quantitative Angaben): häu�g wird von den Daten gesprochen - ohneBeschreibung welche dies sind.

• Regel 12 (unvollständige Bedingungen): es fehlt eine Angabe, was passiert, wenndas Objekt nicht bereits vorhanden ist.

• Regel 16 (unbestimmte Artikel): eine Mappingtabelle, ein Abgleich-Protokoll. DieDe�nitionen fehlen.

• Regel 23 (zeitliche Verhältnisse): es ist nicht klar, wann die Mappingtabelle oderdas Abgleich-Protokoll erstellt werden soll.

5.5. Evaluation des Fragekatalogs

Der Fragenkatalog wurde durch eine Umfrage evaluiert. Dabei gibt es zwei verschiedeneFragebögen: einen für die Entwickler - also die Nutzer der FeatureSpeci�cation - undeinen für die KundenPL - also die Ersteller der FeatureSpeci�cation. Als dritte Perso-nengruppe wurde das Product Management einbezogen. Diese erhielten den KundenPL-Fragebogen, da sie nicht nur Dokumente lesen, sondern selbst welche verfassen.

5.5.1. Aufbau und Inhalt der Evaluation

Ein kompletter Bogen ist im Anhang unter B zu �nden.Nach einer einleitenden Beschreibung zum Ziel, Inhalt und Dauer der Umfrage, folgendie zehn Fragen des Fragekatalogs. Jede Frage wird auf zwei bzw. drei Aspekte un-tersucht: �Wie wichtig ist Ihnen dieser Aspekt für ein gutes 1.Kapitel?� und �Wie oftstellen Sie Rückfragen zu diesem Thema?�. Bei der Umfrage für die KundenPL wurdendie Fragen angepasst: �Wie schwierig und aufwändig ist es für Sie das 1. Kapitel der Fea-tureSpeci�cations so zu schreiben, dass Sie die Frage mit � ja� beantworten zu können?�,�Wie wichtig ist Ihnen dieser Aspekt für ein gutes 1.Kapitel?� und �Wie oft bekommenSie Rückfragen zu diesem Thema?�

Ziel ist es Unterschiede zwischen dem Product Management, den KundenPLs (Erstellerder FeatureSpeci�cations) und den Entwicklern (Empfängern) festzustellen. Gibt es As-pekte, die die Entwickler regelmäÿig nachfragen und die die KundenPLs als unwichtigemp�nden? Wo investieren die KundenPLs mehr Zeit als nötig, weil die Entwickler demThema nur geringe Aufmerksamkeit widmen?

Bei den Antwortmöglichkeiten wurde eine Likert-Skala16 verwendet: Es gibt die zweiExtremen und dazwischen vier Stufen. Beispiel: Zur Häu�gkeit der Rückfragen gibt esden Punkt Zu 100% der Anforderungen und Zu 0% der Anforderungen. Die vier Punktedazwischen sind nicht näher beschrieben. Man könnte sie mit 80%, 60%,40% und 20%beschriften. Aus Gründen der Übersichtlichkeit wurde darauf verzichtet. Es ergibt sicheine gerade Anzahl an Wahlmöglichkeiten. Auf Grund der fehlenden Mitte sind die

16http://de.statista.com/statistik/lexikon/de�nition/82/likert-skala

60


Teilnehmer gezwungen, eine eindeutige Tendenz anzugeben. Es ist beabsichtigt, dass eskeine neutrale Antwort gibt.

5.5.2. Ergebnisse

Die Umfrage wurde zunächst an drei Personen getestet: einem KundenPL, einem Ent-wickler und einem ProductManager. Der Testlauf hat keine groÿen Probleme am Frage-bogen selbst o�enbart. Änderungswünsche der Umfrageteilnehmer wurden durch redak-tionelle Änderungen am einleitenden Teil realisiert. So wurde z.B. die Dauer der Umfragezu kurz geschätzt.Diese stichprobenartige Auswahl lässt auf Grund der kleine Menge keine belastbarenErgebnisse zu. Erste Erkenntnisse konnten trotzdem gewonnen werden:

• Frage 1 (Dopplungen) ist laut KundenPL �unmöglich� (Anmerkung des Teilnehmers).Das Thema sehr wichtig und es gibt zu 80% aller Anforderungen Rückfragen. DerEntwicklern stellt nur zu 20% Rückfragen. Die Di�erenz läÿt sich folgendermaÿenerklären: die Fragen an den KundenPL kommen vom Programm Manager, wenner den Projektplan erstellt.

• Frage 2 (Abwesenheit von Entwurfs-, Architektur- und Implementierungsentschei-dungen): der Entwickler stellt zu 80% der Anforderungen Rückfragen. Dies decktsich nicht mit der Angabe des KundenPL, die bei 20% liegt.

• Bei Frage 4 (Sonderfälle und Alternativstränge) zeigt sich, dass die KundenPL vielZeit (2.Kreis gewählt) und Priorität (sehr wichtig) auf eine vollständige Beschrei-bung der Haupt- und Alternativstränge legen. Dies wird belohnt mit wenig Rück-fragen.

• Zum Umfragebogen wurde keine Begründung der Fragen oder eventuelle Metrikengereicht. Das Ergebnis der 4. Frage ist mit Vorsicht zu betrachten, da den Mitar-beitern nicht bekannt sein dürfte, welche sprachlichen Feinheiten (siehe 5.3) zubeachten sind. Der KundenPL legt keine hohe Priorität auf diesen Aspekt(vorletzterKreis gewählt). So gibt es seitens des Entwicklers zu 40% der Anforderungenzu diesem Thema Rückfragen. Es muss wahrscheinlich viel Mühe und Überzeu-gungsarbeit geleistet werden um eine Einhaltung des REgelwerks zu etablieren.

• Bei Frage 6 (Redundanz, Vollständigkeit und Widerspruchsfreiheit) und 7 (Test-fälle) gibt es quasi keine Unterschiede in den Antworten. Die Personen haben eingleiches Bewusstsein für die Aspekte.

• Frage 8 (Prozesseinbettung) zeigt groÿe Unterschiede: laut KundenPL gibt es nurzu 20% der Anforderungen Rückfragen, laut Product Manager 40% und laut Ent-wickler sind es 80%.

• Frage 10: Im persönlichen Gespräch wurde diese Frage mehrfach als sehr, sehrwichtig bezeichnet. Dies spiegelt die Umfrage nicht wider, wo die Priorität füreinen angemessenen Detailierungsgrad bei Kreis 2-3 liegt, also �nur� in der oberenHälfte.

61


In einer zweiten Umfragerunde wurden 7 weitere Mitarbeiter befragt. Um eine automa-tische Datenverarbeitung zu ermöglichen, wurden die Antworten der Umfrageteilnehmermittels Zahlen codiert. Die Kreise wurden von links nach rechts mit 1 bis 6 durch-nummeriert. Beispiel: die Antwort �zu 80% aller Anforderungen stelle ich Rückfragen�entspricht einer 2. Der komplette Datensatz be�ndet sich im Anhang unter C.

Folgende Ergebnisse lieferte die erweiterte Befragung:

• Die Antworten schwanken sehr stark selbst innerhalb der Entwickler bzw. Kunden-PL. Beispielsweise gab ein Entwickler an zu 100% aller Anforderungen Rückfragenbzgl. der Prozesseinbettung zu stellen, während ein zweiter Entwickler dies mit 0%beantwortete.

• Die gröÿte Di�erenz zwischen den Gruppen gibt es bei der Priorität einer lücken-losen Haupt- und Alternativstrangbeschreibung: die Entwickler setzten sie deut-lich niedriger an als die KundenPL und Product Manager. Die durchschnittlicheAntwort der Entwickler liegt um 2 Kreise unter der durchschnittlichen Antwortder KundenPL.

• Eine Di�erenz von 1.9 ergibt sich bei der Anzahl der Rückfragen bzgl. der Prozes-seinbettung: die Entwickler stellen mehr Fragen als die KundenPL bekommen.Trotz dessen, dass dieser aufwändige (4,3) Aspekt bei den KundenPL bereits hohePriorität (2,3) hat, gibt es zahllose Nachfragen.

• Zum Detailierungsgrad bekommen die KundenPL mehr Rückfragen als die En-twickler stellen. Hier ist zu bedenken, dass die Zuordnung einer Frage zu einemThemenfeld nicht eindeutig ist.

• Die kleinsten Di�erenzen treten bei der Priorität von Frage 2 (Abwesenheit vonEntwurfs-, Architektur- und Implementierungsentscheidungen) und 10 (Detail-lierungsgrad) auf.

• Au�ällig ist ein KundenPL. Er gibt an, dass es sehr leicht und wenig aufwändig istnur eindeutige Begri�e zu verwenden(6). Er legt höchste Priorität (1) auf diesenPunkt. Trotzdem bekommt er zu 80% der Anforderungen Rückfragen. Er kannalso nicht nur eindeutige Begri�e verwendet haben. Die Aussage ist in sich wider-sprüchlich. Wurde die Umfrage nicht ersthaft ausgefüllt? Hat sich der Mitarbeitereventuell �verkreuzt�?

• Zu durchschnittlich 65% aller Anforderungen wird ein Aspekt nachgefragt. Damitergibt sich bei 10 Aspekten 6,5 Fragen pro Anforderung!

62


Abbildung 5.6 und 5.7 enthalten gra�sche Darstellungen der Umfrageergebnisse. Wieman sieht, ist die Di�erenz zwischen Entwicklern und KundenPL teilweise sehr groÿ.Besonders Frage 7 und Frage 8 werden sehr unterschiedlich eingeschätzt.

Abbildung 5.6.: �Wie wichtig ist Ihnen dieser Aspekt für ein gutes 1.Kapitel?�

Abbildung 5.7.: �Wie oft bekommen Sie Rückfragen zu diesem Thema?�

Fazit: man sieht, dass KundenPL und Entwickler viele Aspekte unterschiedlich ein-schätzen. Eine Angleichung der Sichtweise, sollte die Anzahl der Rückfragen minimierenund unnötig intensive Arbeit vermeiden.

63


64

6. Strukturierung der Anforderungen

untereinander

Im Folgenden wird analysiert wie die groÿe Menge an Anforderungen bei TOUCCEAnach heutigem Stand verwaltet wird. Es werden Vorschläge zur Behebung der darausresultierenden Probleme diskutiert. Folgende Verbesserungen sollen erreicht werden: Ab-hängigkeiten zwischen Anforderungen sind besser nachvollziehbar, eine bessere Projekt-planung ermöglichen und die Suchfunktion innerhalb aller Anforderungen verbessern, so-dass es nicht mehr zu Mehrfacheintragungen ein und desselben Kundenwunschs kommt.

Literatur zu diesem Thema konnte bis auf die microsofteigene Produktdokumentationüber den Team Foundation Server keine gefunden werden. Dies kann mit die Aktualitätdes Themas begründet werden, da ältere Versionen des Team Foundation Servers dieStrukturierungsmöglichkeiten nicht bieten. Die Möglichkeit Beziehungen zwischen An-forderungen toolbasiert zu modellieren, gibt es auch bei aqual - ein Produkt der Firmaandagon- und Doors. Allerdings sind die Möglichkeiten dort sehr beschränkt und dienennur der Verfolgbarkeit einer Anforderung innerhalb eines Projekts.Die Zahl der Forenbeiträge und Blogs zu diesem Thema steigt täglich, beschäftigtsich (noch) mit Beschreibungen der technischen Möglichkeiten. Empfehlungen oder Er-fahrungen im Umgang mit den Möglichkeiten konnten keine gefunden werden. Die hierdiskutierten Vorschläge stammen daher vom Autor der Arbeit. Eine Evaluation derRegeln zur Strukurierung konnte aus Zeitgründen nicht durchgeführt werden.

6.1. Bisherige Strukturierung

Während dieser Arbeit wechselte die Firma von Approach DB/Share Point Server zumTeam Foundation Server. Der Umgang mit beiden Werkzeugen wird beleuchtet.

6.1.1. WAR-Zustand: Approach DB

Situation: Es gab keine Möglichkeit mehrere Anforderungen als Einheit zu kennzeich-nen. Wenn der KundenPL eine Anforderung aus mehreren Teilen in der Approach DBanlegen will, gab es zwei Möglichkeiten: entweder für jeden Teil eine neue Anforderungangelegen oder unter einer ID mehrere verschiedene Anforderungen beschreiben.

Es ergeben sich folgende Probleme: Im ersten Fall muss gewährleistet werden, dass alleAnforderungen umgesetzt werden, da ein Kundenwunsch nur zufriedenstellend erfülltist, wenn alle Teile beendet sind. Dies bedarf vielfältiger Kommunikation: ein Hinweisan den Product Manager, dass alle Teile priorisiert werden müssen oder/und an denProgramm Manager, dass alle Teile in den Projektplan aufgenommen werden. Arbeiten

65

6. Strukturierung der Anforderungen untereinander

dann verschiedene Mitarbeiter an den Teilen, müssen sie untereinander Absprachen tref-fen. Die Gefahr, dass ein Teil fehlt, ist sehr groÿ.Im 2.Fall beschreibt der KundenPL unter einer ID zwei (oder mehr) Anforderungen.Es kam vor, dass eine Teilanforderung fertig war und der Status der Anforderung aufclosed gesetzt wird. Damit ist der zweite Teil verloren, weil er in keiner Liste o�enerPunkte mehr vermerkt ist (auÿer der KundenPL fragt gezielt nach).Wird andererseits eine Anforderung aus dem Anforderungsbündelt umsetzt und einge-checkt ohne die ID auf closed zu setzten, �ndet keine Übergabe an den Test statt.Ungetestete Funktionen werden an die Kunden ausgeliefert. Nur fertige (closed) IDswerden in die Versionsdokumentation aufgenommen, sodass der Anforderungsteil nichtin der Liste der Änderungen, die mit der neuen Version einhergehen, verö�entlicht wird.Auÿerdem kommt es zu Unstimmigkeiten beim Tracking: die ID ist nicht abgeschlossen,aber Mitarbeiterzeiten wurden verbraucht.

Fazit: Mit einem manuellen Mehraufwand kann ein zufriedenstellendes Ergebnis er-reicht werden. Allerdings ist dieses Vorgehen sehr umständlich und fehleranfällig. Mitden gegebenen technischen Möglichkeiten konnte die Realität nicht abgebildet werden.Deshalb musste getrickst werden.

Lösung: Die Approach DB wurde durch den Team Foundation Server ersetzt. Letztererbietet andere Möglichkeiten zur Anforderungsverwaltung, sodass die Probleme nichtmehr auftreten. Eine Lösungsstrategie wird folglich nicht erarbeitet.

6.1.2. IST-Zustand: Team Foundation Server

Der TFS bietet die Möglichkeit die Menge der Anforderungen zu strukturieren. Sokönnen zwei Anforderungen mit einer Verlinkung versehen werden, sodass Hierarchien,Ketten oder Kreise entstehen. Es können neben Anforderungen auch andere Einträgewie Fehler, Tasks, Change Requests oder Hot�xes in die Struktur einbezogen werden.Thema diese Arbeit ist die Strukturierung von Anforderungen, daher werden die anderenWork-Item-Typen nicht betrachtet.

Folgende Verlinkungstypen bietet der Team Foundation Server standardmäÿig:

Verlinkungstyp Beschreibung Kardinalität Besonderheit

Parent/ChildZur Abbildung vonHierarchien (Bäume)

Anzahl der Kinder: 0oder mehr.Anzahl der Elternpro Kind: 1.

Kreise sind nichtmöglich.

Tests/tested byZuordnung von Test-fällen zu Anforderun-gen oder Tasks

Anzahl Testfälle 0oder mehr.Anzahl getesteterAnforderungen: 0oder mehr Work-Items veri�zieren.

Keine weitere Betra-chtung, da nur An-forderungen verlinktwerden sollen

66

6.1. Bisherige Strukturierung

Verlinkungstyp Beschreibung Kardinalität Besonderheit

Successor/ Pre-decessor (Nach-fahre/Vorgänger)

Modellierung chro-nologischer Ab-hängigkeiten vonAnforderungen

frei wählbar

Schleifenkonstruk-tionen möglich(keine semantischePrüfung auf diesenWiderspruch)

Related

1.) Verlinkungenaus älteren TFS-Versionen2.) Verlinkungohne weiter Ein-schränkungen

frei wählbarrichtungsloseBeziehung

Tabelle 6.1.: Verlinkungstypen nach [Bla2011]

Neben den von [Bla2011] beschriebenen Typen, gibt es einen weiteren Standardver-linkungstyp A�ects/A�ected By. Die Abgrenzung zu Related ist nicht klar de�niert.Primär dient er der Modellierung von Beziehungen zwischen Bug und Anforderung (re-lated verbindet üblicherweise zwei Anforderungen).

Situation: Folgende Linktypen werden in folgendem Ausmaÿ verwendet (Stand 5.3.12):

• A�ects/A�ected By: 203 Work-Items haben eine Markierung, davon sind 15 An-forderungen, der Rest Tasks und BugsBeispiel: �Erweiterung der Revisionsverwaltung� und �Gra�sche Anzeige der Re-visionen�

• Parent: Es gibt 84 Elternanforderungen, Child: Es gibt 215 Kinderanforderun-gen. 17 Kinderanforderungen haben selbst Kinder. Mehr als eine zweistu�ge Ver-schachtelung kommt nicht vor. Dabei sind Bug, Requirement sowohl Eltern wieauch Kinder. Zusätzlich gibt es Tasks als Kinder. Es gibt sogar Bug-Requirementund Bug-Bug Eltern-Kind-Beziehungen. In einzelnen Fällen gibt es auchRequirement-Change Request oder Hot�x-Bug-Beziehungen, d.h. nicht nur An-forderungen werden verlinkt. Die Durchschnittliche Anzahl Kinder pro Eltern ist3,2. Allerdings liegt eine breite Streuung vor: Die Anzahl an Children geht bis 15,meist ist nur ein Kind vorhanden.Beispiel: �Das Attribut Letzte Änderung` sollte an sämtlichen Objekten aktuali-siert werden� und �Attribut Letzte Änderung` am Blattobjekt automatisch aus-füllen

• Predecessor: 0 Verwendungen

• Successor: 0 Verwendungen

• Related: 423 Markierungen dieser Art. Verschiedene Work-Item-Types werden ver-wendet: Requirement, Bug, Task und Change Request werden beliebig miteinanderverbunden.Beispiel: �Einstellungen übernehmen bei der Installation einer neuen Version� und

67


�Einstellungen sollen in neue Version übernommen werden�

• Tests/Tested By: 0 Verwendungen

Fazit: von 9417 eingetragenenWork-Items sind 1847 untereinander verlinkt, das entsprichteinem Anteil von 19,6% (Stand:3.5.2012)

Folgende weitere Begebenheiten können beobachtet werden:

• Es gibt Anforderungen, die zu mehreren Anforderungen verlinkt sind: über relatedoder a�ected By.

• In nur 9 von 67 Fällen ist die ID des Parent gröÿer als der Kinder, d.h. in denmeisten fällen werden erst die Eltern erstellt und später Kinder abgespalten. DieID spiegelt die Reihenfolge der Erstellung wider, da sie fortlaufend vergeben wird.

• Jedes Child-Anforderung hat eine eigene ID und wird separat priorisiert.

• Häu�g treten Einheiten von Anforderungen auf, bei denen jeder mit jedem relat-ed ist. Diese Verlinkungen herzustellen ist sehr aufwändig, wenn eine Einheit ausmehr als 3 Anforderungen besteht, da manuell alle related-ID's herausgesucht wer-den müssen. Bei TOUCCEA wurden maximal Einheiten von vier Anforderungengebildet. Dafür müssen sechs Verlinkungen gesetzt werden. Das Verlinken erfolgtparallel zum Erstellen der Requirements.

• Es gibt keine Regeln wie mit den Zuständen verfahren wird. Zum Beispiel gibtclosed Parent-Anforderung und planning Child-Anforderung . Damit ist diegröÿere Einheit beendet, obwohl noch nicht alle Teile fertig sind. Dies birgt dieGefahr, dass die Parent-Anforderung wieder geö�net werden muss, wenn sich beider Umsetzung der Child-Anforderung Probleme ergeben.

Rollen und Stati im Zusammenhang mit Verlinkungen: Abb. 6.1 zeigt die Rollen,die Verlinkungen vornehmen. Weiterhin ist der Status, in dem Anforderungen verlinktwerden, ersichtlich.Die Gra�ken wurden manuell erstellt. Grundlage sind alle Parent-Child-Verlinkungenzwischen abgeschlossenen Work-Items der aktuell bearbeiteten Plattformversion (Stand4.April 2012).

Abbildung 6.1.: Rollenverteilung bei Parent-Child-Verlinkungen

68

6.2. Regeln zur Strukturierung

Beachte mögliche Rollendopplungen: �Michel�übernimmt Aufgaben als Programm Man-ager und als KundenPL. Welche Verlinkung zu welcher Rolle gehört, ist nicht ersichtlich.Andererseits gibt es pro Rolle mehrere verschiedene Personen, die verschieden Verlinkun-gen anlegen. Beispielsweise hat ein Product Manager fast nur Parent-Child-Verlinkungenvorgenommen, ein anderer Product Manager bevorzugt related-Verlinkungen.

Man sieht, dass verschiedene Rollen Verlinkungen vornehmen. Die meisten Parent-Child-Verlinkungen werden zwischen Anforderungen gebildet. Ausnahme ist die Dokumenta-tion. Analysiert man nun noch die Phasen in den Verlinkungen vorgenommen werden,fällt auch hier auf, dass verschiedene Phasen genutzt werden (Abb. 6.2).

Abbildung 6.2.: Anzahl der Parent-Child-Verlinkungen pro Status

Daraus resultierendes Problem/Fazit: uneinheitliches Vorgehen ohne Regeln. AkuteProbleme haben sich bisher nicht ergeben, aber das Potential des Team FoundationServers wird nicht ausgenutzt.

Lösung: ein einheitliches Vorgehen nach festgelegten Regeln, wie sie im nächsten Ab-schnitt dargestellt werden.


Für jede Verlinkung müsen folgende Aspekte berücksichtigt werden:

• Welchen Nutzen bringt diese Verlinkung?

• Wie aufwändig ist es die Verlinkung vorzunehmen? Es solte möglichst wenigaufwändig sein und schnell gehen. Manchmal sind aber eventuell Informationenfür eine eindeutige Zuordnung nötig. Diese zu bescha�en, könnte lange dauern.

• Welche Konsequenzen hat diese Verlinkung? Zum Beispiel eine Änderung derWork�ows.

Die Nutzungsmöglichkeiten und Vorschläge unterscheiden sich grundlegend durch denverwendeten Linktypen. So werden diese einzeln betrachtet. Im Folgenden wird imZusammenhang mit Dokumenten nur allgemein von �Spezi�kation� gesprochen.

69


Zuerst soll noch erwähnt werden, dass es möglich ist, verschiedenen Teamprojektsamm-lungen anzulegen. [Puf2010]schlägt vor für jedes Produkt ein neues Teamprojekt anzule-gen. Dies bietet sich auch hier an, da die Altlasten (RUPLAN, ELCAD) auch im TFS ineinem Teamprojekt gemanagt werden. Die Zuordnung der Anforderung zu einem Team-projekt dauert nicht lange und ist eindeutig. Die groÿe Menge an Anforderungen wirdaufgeteilt und damit übersichtlicher. Konsequenzen in den Arbeitsabläufen gibt es nicht.

6.2.1. Parent-Child-Hierarchien

Das Wort Hierarchie kommt aus dem Griechischen und bezeichnet eine Menge vonObjekten, die durch eine Unter- und Überordnung gekennzeichnet ist. Einem über-geordneten Objekt sind meiste mehrere Objekte untergeordnet. Gra�sche Darstellun-gen von Hierarchien sind Pyramiden oder Bäume. In Bezug auf Anforderungen solleine Hierarchie die Möglichkeit bieten, groÿe Anforderungen in mehrere kleinere An-forderungen aufzuteilen. Kleinere Objekte können von Menschen besser überblickt undgehandhabt werden. Allerdings steigt die Anzahl der Anforderungen und damit wirdder Gesamtüberblick erschwert.

�Groÿe�, übergeordnete Anforderungen werden Parent-Anforderung und �kleine�, unter-geordnete Anforderungen Child-Anforderungen genannt.

Verhältnis Parent/ChildDie Child-Anforderungen sind so zu formulieren, dass sie paarweise disjunkt sind. AlleChild-Anforderungen zusammen decken die Parent-Anforderung komplett ab. Mathe-matisch geschrieben: ⋃

Child∈I= ParentAnforderung

undChildi

⋂Childj = ∅, ∀i, j ∈ I, i 6= j

wobei I die Menge aller Child-Anforderungen ist.

Damit ist es möglich, dass die Child-Anforderungen von verschiedenen Mitarbeiter zeit-gleich bearbeiten werden können. Die einzelnen Child-Anforderungen können zu ver-schiedenen Zeitpunkten freigegeben werden. Der Aufwand zur Aufteilung der Parent-Anforderung rechtfertigt sich durch eine Verringerung der Zeit bis zur Fertigstellung,wenn parallel gearbeitet wird.

TOUCCEA-Beispiel :Parent-Anforderung : Branchenlösung Instrumentation erstellenChild-Anforderung 1: Messstellenassistenten entwickelnChild-Anforderung 2: SPS-IO-Wizard entwickelnChild-Anforderung 3: Unterstützung von Lie-Styles bereitstellen

Die Parent-Anforderung ist eine Hülle ohne konkrete Anforderung. Eine eigene Imple-mentation �ndet nicht statt, es muss eine Spezi�kation geschrieben werden, sowie eineAutteilung in Child-Anforderungen . Deshalb wird ein neuer und kürzerer Work�owvorgeschlagen.

70


Work�owSowohl die Parent-Anforderung als auch die Child-Anforderung haben einen vorgegebe-nenWork�ow -den Anforderungswork�ow. Es fehlt eine De�nition wie diese zu verbindensind. Dabei treten Fragen auf wie: Darf eine Parent-Anforderung beendet sein, bevoralle Child-Anforderungen beednet sind? Werden die Child-Anforderungen unabhängigvoneinander oder parallel bearbeitet?

Abbildung 6.3.: Neuer Status mit neuem Ablauf

In Abbildung 6.3 wird ein Vorgehen vorgeschlagen.Konsequenz dieser Verlinkung: ein Parent-Anforderung wird erst verö�entlicht, wenn alleChild-Anforderungen beendet sind. Dabei können die Child-Anforderungen unabhängigvoneinander bearbeitet werden. Es ist möglich, dass eine Child-Anforderung beendet ist,eine wird gerade implementiert und eine Dritte wurde noch nicht spezi�ziert. Es muss einneuer Status für Requirements eingeführt werden waiting. Dieser ersetzt die Planung-und Implementierungsphase. Jede Anforderung, die Children hat, wartet darauf, dassdie Children fertig sind. Sind alle Children beendet (d.h. der Status ist closed), wirddie Parent-Anforderung auf den Status closed gesetzt.

Eine 2-stu�ge-Schachtelungen ist möglich: sobald eine Anforderung Children hat, läuftsie nach dem neuen Work�ow ab: Specification, Waiting, Ready for QM, Test

und Closed.[Lef00] emp�ehlt eine Strukturierung aus maximal 3 Ebenen aufzubauen: Patent-, Child-und Grandchildebene. Danach wird die Übersicht stärker getrübt ist als der Gewinn. Inseltenen Fällen eine dritte Substruktur.Es ist möglich, die Kinder als Vorfahren und Nachfahren voneinander zu de�nieren. Sokann es eine Child-Anforderung geben mit dem Inhalt, alle Kinder zusammenzuführen.

71


Aktuell hat eine Parent-Anforderung oft nur einen Child, dieses Vorgehen ist nach demneuen Leitfaden nicht mehr möglich. Wenn alle Anforderungen zusammen die Elternan-forderung ergeben und nur eine Child-Anforderung vorhanden ist, folgt, dass er identischdas Elternteil ist.

PriorisierungEs ist technisch möglich, sowohl die Child-Anforderungen wie die Parent-Anforderungzu priorisieren. Dies wird aktuell praktiziert. Eine Anforderung ist nur fertig, wenn alleKinder relisiert wurden, deshalb sollten Kinder nicht verschieden priorisiert werden. Fürden Fall, dass Child-Anforderungen verschieden priorisiert werden sollen, enthält Kapitel6.2.5 Vorschläge für ein andere Vorgehensweise. Werden die Child-Anforderungen nichtgesondert priorisiert, wird viel Aufwand und Zeit eingespart.

Art und Anzahl der DokumenteEs gibt mehrere Möglichkeiten im Umgang mit der Dokumentation.Version 1: jede Anforderung bekommt eine Spezi�kation (Parent-Anforderung und Child-Anforderungen ). Die Spezi�kation für das Parent-Anforderung enthält eine Beschrei-bung wie die einzelnen Child-Anforderungen zusammenhängen und jeder Child-Spezi�kationenthält die eigentliche Beschreibung. Idealerweise ist die Child-Spezi�kation ohne Parent-Spezi�kation verständlich! Es gibt am Ende kein ImplementationConcept zur Parent-Anforderung .Version 2: Eine Spezi�kation für die Parent-Anforderung , die den Zusammenhang derChild-Anforderung und die Funktion jedes Child-Anforderung beschreibt.

Der Vorteil von Version 2 ist eine geringe Anzahl an Dokumenten. Schwierig wird es,wenn verschiedene Personen verschiedenen Kinder bearbeiten. Sie müssen zusammenein Dokument schreiben. Bei Version 1 gibt es mehr Dokumente, damit sinkt die Über-sichtlichkeit. Jedes Kind kann separat bearbeitet werden, daher überwiegen die Vorteilevon Version 1.

TestfälleWie aus Abb. 6.3 ersichtlich, wird jede Child-Anforderung und die Parent-Anforderunggetestet. Für jeden Teil sind eigenständige Testfälle anzugeben. Der Kunde nimmt einneues Feature (eine Parent-Anforderung ) ab, daher werden Akzeptanztests auf dieserdurchgeführt. Einzelne fertige Child-Anforderungen sollten also nicht verö�entlicht wer-den, wenn die Parent-Anforderung nicht fertig ist.

Benennung[Lef00] emp�ehtl eine logische Benennung der zusammengehörigen Anforderungen umeinen schnellen Überblick zu gewährleisten.Beispiel: Eine Anforderung hat die ID 63. Dann sollen die Child-Anforderungen 63.1und 63.2 heiÿen und die Anforderungen auf Grandchildebene 63.1.1, 63.1.2. Dies kannmit den technischen Gegebenheiten von TOUCCEA nicht realisisert werden, da die IDsautomatisch fortlaufend vom Team Foundation Server vergeben werden. Eine manuelleBenennung dieser Art ist nicht zu empfehlen, da der Team Foundation Server zu einerAnforderung alle verlinkten Work-Items anzeigen kann.

72


Anforderungen innerhalb einer Parent-Child-Strukturierung sind stark aneinander gebun-den, da es viele Einschränkungen in der Abarbeitung gibt. Die Zahl der Einschränkungenund damit die Stärke der Bindung ist in den folgenden Verlinkungen abnehmend.

6.2.2. Nachfolger/Vorfahren

Diese Verlinkung impliziert eine Reihenfolge zur Bearbeitung von Anforderungen: erstder Vorfahre, dann der Nachfolger. Damit ist die Verlinkung unsymmetrisch - ebensowie Parent/Child. Bisher wird dieser Verlinkungstyp bei TOUCCEA nicht verwendet.

Beispiel:Vorfahre: Auf einem Arbeitsblatt können bis zu 20 Maschinen platziert und miteinanderverbinden werden.Nachfolger: Beim Kopieren einer Menge von Maschinen auf ein neues Arbeitsblatt wer-den die Verbindungen unter den Maschinen übernommen.

Die Frage ist, wann mit einem Nachfolger begonnen werden kann. Eine Möglichkeit ist eszu fordern, dass der Vorfahre closed ist. Das bremst die Geschwindigkeit der Entwick-lung ab. Hochpriorisierte Nachfolger müssen bei niedrig priorisierten Vorfahren ruhen.Schneller, aber risikobehafteter, ist eine zweite Möglichkeit: Sobald der Vorfahre vonStatus x zu Status y übergeht, darf der Nachfolger in den Status x übergehen. Prob-lematisch hierbei: wenn erst beim Test au�ällt, dass eine Anforderung nicht korrektumgesetzt wurde und eventuell sogar die Spezi�kation überarbeitet werden muss, dannmuss wahrscheinlich auch die Spezi�kation des Nachfolgers überarbeitet werden. Dieseerneute Bearbeitung kostet Zeit und damit Geld. Da die intere Firmendevise �Qual-ität vor Termineinhaltung�ist, wird die sichere Variant1 empfohlen. Der Work�ow derAnforderungen ist unverändert wie in Abb. 4.1.

6.2.3. A�ects/A�ected By

Diese Verlinkung bietet die Möglichkeit, Anforderungen als einander beein�ussend zukennzeichnen (symmetrische Verlinkung). In frühen Projektphasen reicht diese ungenaueBeschreibung. Sie kann z.B. in ein Vorgänger/Nachfolger oder ein Parent/Child umge-wandelt werden, um klar zu machen, wie mit der gegenseitigen Beein�ussung umzugehenist. Der KundenPL kann dies noch nicht wissen und trägt A�ected By ein. Der ProductManager (oder der Programm Manager) muss den potentiellen Kon�ikt lösen. Ab demStatus Planning ist kein A�ects/A�ected By mehr zugelassen.

Beispiel:Anforderung 1: Kunde A fordert, dass der Druck von 10 Arbeitsblättern maximal 3Minuten dauert.Anforderung 2: Kunde B fordert, dass der Druck von 100 Arbeitsblättern maximal 5Minuten dauert.Diese beiden Anforderungen sind sich sehr ähnlich und sollten nicht unabhängig voneinan-der bearbeitet werden. Denkbar wäre ein Deklarierung als Vorgänger und Nachfolger.Sobald Anforderung 2 umgesetzt ist, sollte auch Anforderung 1 fertig sein. Dies ist nicht

73


zwingend der Fall, sodass Anforderung 1 nicht gelöscht werden kann.

Diese A�ects/A�ected By wird auch verwendet, um Anforderungen Bugs zuzuordnen.Dies ist auch weiterhin möglich.Beispiel:Anforderung: Es ist möglich, 10 Arbeitsblätter auszudrucken.Bug: Die Software stürzt ab, nachdem die 10 Blätter gedruckt wurden.

Bei dieser Art der Verbindung wird jedes Feature eigenständig behandelt (Priorisierung,Dokumente). Es gibt keine Änderungen am jeweiligen Work�ow. Es dient als Merkhilfe�Achtung hier könnte es Probleme geben� oder �Achtung doppelte Arbeit vermeiden�.

6.2.4. Related

Die Related-Beziehung ist noch weniger einschränkend als A�ects/A�ected By. Sie kannangewendet werden, wenn ein neues Feature einem bereits realisierten ähnelt.Beispiel:fertige Anforderung 1: Für jede Maschinen wird ein Attribut Standort durch die entsprechen-den GPS-Koordinaten in der Plattform hinterlegt. Kunde A kann mit seinem Smart-phone erfragen, vor welcher Maschine er gerade steht.o�ene Anforderung 2: Alle Arbeitsblätter, in denen eine vom Benutzer ausgewählte Mas-chine vorkommt, können mit dem Smartphone geö�net werden. So können die Folgeneines Maschinenausfalls schnell überblickt werden.Die o�ene Anforderung kann die bereits realisierte Schnittstelle zwischen Plattform undSmartphone nutzen.

Bisher wurde diese symmetrische, unpräzise Beschreibung genutzt um Gruppen sichbeein�ussender Anforderungen zu dokumentieren. Dabei muss jede Anforderung manuellmit jeder Anforderung der Gruppe verbunden werden. Das ist sehr zeitaufwändig. Dahersoll diese Verlinkung nicht mehr benutzt werden. Eine Alternative wird im nächstenAbschnitt vorgestellt.

6.2.5. Einführung des Verlinkungstypen Themenkomplex/Anforderung

Es wird ein neuer Work-Item-Typ eingeführt: der Themenkomplex. Einem Themenkom-plex sollen Anforderungen aus dem jeweiligen Bereich zugeordnet werden. Themenkom-plexe können z.B. �Areas� der Appoach DB sein: Installation, Licensing, Look and Feel,Online Help.

Beispiel:Abstrakte Anforderung: Verbesserung der Performancekonkrete Anforderung 1: Hundert Arbeitsblätter ausdrucken dauert maximal 10

Minuten.konkrete Anforderung 2: Zehn Arbeitsblätter kopieren dauert maximal 15

Minuten.

Die Verlinkung zwischen Themenkomplex und Anforderung ist unsymmetrisch. Ein The-menkomplex wird von einer Anforderung konkretisiert. Eine Anforderung gehört zu

74


einem Themenkomplex. Die Idee ist der objektorientierten Programmierung entlehnt:ein Themenkomplex entspricht einer abstrakten Klasse, die nicht selbst instanziiert wer-den kann.

Einen Work�ow mit Zustandübergängen gibt es nicht. Ein Themenkomplex wird erstelltund existiert dann. Eventuell wird er gelöscht, sobald alle Anforderungen realisiert sind.Es ist möglich eine Parent/Child-Strukturierung aus Themenkomplexen aufzubauen.Beispiel:Parent-Themenkomplex: PerformancesteigerungChild-Themenkomplex: Performancesteigerung bei KopiervorgängenChild-Themenkomplex: Performancesteigerung bei InstallationenEine Anforderung wird entweder dem Parent- oder einem Child-Themenkomplex zuge-ordnet. Es ist nicht möglich einer Anforderung einen Themenkomplex zuzuweisen.

Vergleich related-Verlinkung und Themenkomplex.

Abbildung 6.4.: Gra�sche Darstellung related-Verlinkung (links) und Themenkomplex(rechts)

Für die Anzahl der Work-Item ergibt sich: Eine Realisierung mit Themenkomplexenbenötigt mehr Work-Items (Abbildung 6.4 zeigt links 4, rechts 5 Work-Items). Dafürsinkt die Anzahl der Verlinkungen: links sind es 6, rechts nur 4. Bei gröÿeren Gruppenwächst die Di�erenz sprunghaft und damit der Vorteil der Themenkomplex/Anforderung-Verlinkung.

Primär soll die Suchfunktion verbessert werden, sodass eine Anforderung nicht mehrfacheingetragen wird. Sucht ein KundenPL, ob seine Anforderung bereits von einem anderenKundenPL eingetragen wurde, muss er nur die zu seinem Themenkomplex gehörendenAnforderungen durchsehen. Wenn es viele Themenkomplexe gibt, gibt es jeweils wenigeAnforderungen, sodass eine Suche schneller geht. Allerdings ist dann die Zuordnungzu einem Themenkomplex nicht mehr eindeutig. Der KundenPL muss mehrere Kom-plexe durchsehen. Wenn es nur wenige Themenkomplexe gibt, ist die Einordnung einerAnforderung eindeutig. Dafür sind ihm viele Anforderungen zugeordnet. Es ist wün-schenswert, dass die Zuordnung eindeutig ist. Eine andere Person wird dann an derrichtigen Stelle suchen. Eine praktikable Menge an Themenfeldern kann mittels Praxis-erfahrung gefunden werden.

75


Kardinalität: per De�nition gehöhren zu einem Themenfeld mehrere Anforderungen.Aus Sicht der Anforderung kann es verschiedene Kardinalitäten geben:

Kardinalität eine Anforderung wird genaueinem Themenkomplex zuge-ordnet

eine Anforderung kannmehrern Themenkomplexenzugeordnet werden

Bezeichnung 1:1 1: nKonsequenz Reduktion der Anforderung

auf einen AspektBerücksichtigung aller Aspek-te der Anforderung

zeitlicherAufwand

schnell umsetzbar (nur einLink angeben)

mehrere Links setzen dauertlänger

Übersichtlichkeit groÿ - Baum wird aufgebaut(gut gra�sch darstellbar)

geringer - ein �ächiges Netzwird aufgebaut

Tabelle 6.2.: Vergleich möglicher Kardinalitäten

Es muss gefordert werden, dass die Themenkomplexe paarweise disjunkt sind, damiteine auf einen Aspekt reduzierte Anforderung eindeutig zugeordnet werden kann. Sollenein neuer Themenkomplexe eingeführt werden, muss dieser auf Überschneidungen zuallen bereits existierenden geprüft werden. Die Kardinalität von 1:n ist zu bevorzugen,da Anforderungen fast immer mehrere Aspekte beinhalten.Für die Kardinalität 1:n gibt es zwei Möglichkeiten:

• Die Themenkomplexe sind nicht disjunkt. Ist die Zuordnung nicht eindeutig, wirddie Anforderungen mehrmals verlinkt. Beispiel: Es gibt die Themenkomplexe Smart-phonekompatibilität und Kopieren. Die folgende Anforderung kann beiden zuge-ordnet werden: �Das Kopieren von zehn Arbeitsblättern mit dem Smartphonedauert maximal 15 Minuten.�Es ist leicht möglich neue Themenkomplexe zu ergänzen, da keine Überschneidun-gen zu bereits existierenden überprüft werden müssen.

• Es gibt Gruppen von Themenkomplexen. Die Elemente einer Gruppe sind paar-weise disjunkt. Eine Anforderung kann maximal einem Themenkomplex pro Gruppezugeordnet werden.Beispiel: in Gruppe 1 erfolgt eine Klassi�zierung anhand der Quelle: ist es ein Kun-denwunsch oder eine zukunftsorientierte Vision des Produkt Management. Einezweite Gruppe besteht aus den Areas der ehemaligen Approach DB: Performance,Look and Feel. Die Anforderung �Das Kopieren von zehn Arbeitsblättern mit demSmartphone dauert maximal 15 Minuten.� gehört zu zukunftsorientierte Vision

des Produkt Management (Gruppe 1) und zu Performance(Gruppe 2). Eine An-forderung kann nicht sowohl Kundenwunsch und zukunftsorientierte Vision sein,da dies beides Themenkomplexe aus Gruppe 1 sind. Eine Anforderung kann aberweder Perfomance noch Look and Feel sein. Sie wird keinem Themenfeld ausGruppe 2 zugeordnet.Eine übersichtliche Darstellung im Team Foundation Server kann über zwei Ra-diobuttons erfolgen.

76


Bei der 1:n-Verlinkung mit Gruppen von Themenkomplexen verbinden sich die Vorteileder 1:1-Verlinkung (wenig Anforderungen pro Themenfeld) mit den Vorteilen der 1:n-Verlinkung (mehrere Aspekte einer Anforderung können berücksichtigt werden).

Allgemein soll nicht gefordert werden, dass eine Anforderung zu mindestens einem The-menfeld gehört. Das dies vorraussetzt, dass jede Anforderung einem Themenkomplex zu-geordnet werden kann. Dies ist eventuell nicht möglich, wenn die Zahl der Themenkom-plexe gering gehalten werden soll.

Konsequenzen für den Work�ow einer Anforderung gibt nicht.

6.2.6. Kombination verschiedener Linktypen

Es ist möglich verschiedene Linktypen zu kombinieren.TOUCCEA-Beispiel :Anforderung: � Open form shape` must be disabled in Visio for normal user�. Hat eineChild-Anforderung (� Dialog de�nieren` über Benutzerverwaltung steuern�) und ist re-lated zu � Replace form shape` must be disabled in Visio for normal user�.

Es gibt auch Fälle in denen Verlinkungen über�üssig sind: die Kennzeichnung zweierChild-Anforderungen einer Parent-Anforderung als related. Sie sind per De�nition derParent/Child-Verlinkung zusammengehörig. Es ist sogar kontraproduktiv, da das Netz-werk aus Verlinkungen zu dicht wird und damit die Übersichtlichkeit leidet.

Werden Anforderungen einer Parent/Child-Strukturierung mit weiteren Anforderun-gen verlinkt, so gibt es die höchste Übersicht, wenn nur Verlinkungen zwischen Ele-menten der gleichen Ebene gebildet werden: zwischen zwei Child-Anforderungen vonzwei Parent-Anforderungen oder zwischen zwei Parent-Anforderungen, nicht jedoch zwi-schen einer Child-Anforderung einer Parent-Anforderung 1 und einer anderen Parent-Anforderung.

6.2.7. De�nition neuer Verlinkungstypen

Der praktische Einsatz wird zeigen, wo die Realität noch nicht abgebildet werden kann.Abhilfe kann die Einführung neuer Verlinkungstypen scha�en. Ein Linktyp besteht auseinem Namen, einem Vorgänger, einem Nachfolger und einer Topologie. Für unsym-metrische Beziehungen wie Parent/Child muss de�niert werden, welche AnforderungParent und welche Child ist. Dies geschieht über den Vorgänger und Nachfolger. Es gibtvier Topologien:

77


Topologie Beschreibung schematische Darstellung1

Netzwerk

Zur Modellierung grundle-gender Zusammenhänge. DieVerbindung ist symmetrischund lässt Kreise zu. Bsp.:Menge von Anforderungen,die auf dieselbe Ressourcezugreifen; oder der related-Verlinkungstyp

Gerichtetes Netzwerk

Netzwerk mit einer unsym-metrischen Verbindung: eineVerlinkung hat einen Anfangund ein Ende. Schleifen sindmöglich und zulässig.

Abhängigkeit

Ein gerichtetes Netzwerk ohneSchleifen. Bsp.: De�nition einerzeitlichen Abfolge (Vorgängerund Nachfolger)

Baum

Ein gerichtetes Netzwerk ohneSchleifen, jedes Element darfnur Anfang einer Verbindungsein, aber jedes Elementkann Endpunkt mehrererVerbindungen sein. Bsp.:Parent-Child-Verlinkungstyp

Tabelle 6.3.: Topologien für Verlinkungen

Denkbar ist eine Möglichkeit sich widersprechende Anforderungen zu kennzeichnen.Diese Verlinkung ist symmetrisch und damit ist eine Netzwerktopologie zu verwenden.Möglich ist auch ein Verlinkungstyp um Verbindung zwischen verschiedenen Ebenen ein-er Hierarchiestruktur zu kennzeichnen. Diese Möglichkeit wurde im letzten Absatz ausGründen der Übersichtlichkeit nicht zugelassen. Gibt es einen eigenen Verlinkungstyp,kann dieser wenn nötig herausge�ltert werden. In einer Übersicht erscheinen Verlinkun-gen dieser Art nicht.

78

7. Zusammenfassung und Ausblick

Im Rahmen dieser Arbeit wurden folgende Punkte realisiert:

• Analyse und Dokumentation des Requirements Engineering Prozesses der FirmaTOUCCEA

• Analyse der Änderungen des Prozesses durch die Einführung des Team FoundationServers

• Sammlung von Abweichungen zwischen SOLL- und IST-Prozess

• Sammlung von Schwachstellen im Prozess. Diskussion von Lösungsmöglichkeiten

• Vorstellung eines Qualitätsmodells für Anforderungen.

• Diskussion verschiedener Möglichkeiten zur Verbesserung der Anforderungsdoku-mentation: das REgelwerk und die Anforderungsschablone nach [Rup04]. Entwick-lung eines Fragenkatalogs. Aus dieser Sammlung von 10 häu�gen Fehler wurdeein Quality Gate abgeleitet. Ein Schwerpunkt liegt auf der automatischen Durch-führbarkeit dieser Kontrolle.

• Evaluierung des Fragenkatalogs durch eine Umfrage unter den Mitarbeitern vonTOUCCEA.

• Vorstellung der Möglichkeiten des Team Foundation Servers zur Verlinkung vonAnforderungen untereinander.

• Erarbeitung eines Konzepts zur Nutzung dieser Möglichkeiten.

Folgende Ansatzpunkte für weitere Betrachtungen gibt es:

• Umsetzung der Vorschläge und Überprüfung des jeweiligen Nutzens. InsbesondereAnwendung der vorgestellten Tools zur automatischen Überprüfung von natürlichsprachlichen Texten.

• Aufbereitung der Vorschläge zur Verbesserung der FeatureSpeci�cation für Kun-denPL (Übersichten, Schulungen).

• Erweiterung der automatischen Überprüfung von natürlich sprachlichen Textenauf die Dokumentation. Maÿnahmen dieser Art haben kaum Ein�uss auf die Qual-ität der Software von TOUCCEA, verbessern dafür den Einsatz der Produkte. Dieheutigen Anleitungen sind häu�g für Kunden schwer verständlich, sodass diese dieFunktionsweise der Plattform und die Vorteile nicht erkennen und nutzen kann.Eine Verbesserung der Dokumentation führt zu einer geringeren Anzahl an Nach-fragen beim Support.

• Es fehlen Richtlinien wie mit �späten Änderungswünschen� der Kunden umzuge-hen ist bzw. welche Maÿnahmen die Anzahl dieser Wünsche reduzieren. Ändert

79

7. Zusammenfassung und Ausblick

sich z.B. in der Implementierungsphase die Anforderung, muss die Speci�cation,das RealisationConcept und das ImplementationConcept überarbeitet werden.Dies kostet Geld und Zeit.

• Zur weiteren Verbesserung der Suchfunktion innerhalb aller Anforderungen, kön-nen Richtlinien für den Titel einer Anforderungen hilfreich sein. Diese sind aufzustellen.

• Analyse und Einführung von Maÿnahmen zur Verbesserung der Realisation Con-cepts.

• Die Prozessde�nition kann um Abkürzungsmöglichkeiten erweitert werden: oft gibtes triviale Anforderungen, die direkt realisiert werden. Dann gibt es keine Doku-mentation. Für Makros werden häu�g keine ImplementationConcepte geschrieben.

• Erarbeitung einer Vorgehensbeschreibung ausgehend von einer Anforderung, diein die bestehenden Strukturen aus Anforderungen eingliedert werden soll. Diegegebene Beschreibung analysiert die Möglichkeiten des Team Foundation Servers.

• Betrachtung weitere Verbesserungmöglichkeiten für die Dokumente, zum Beispielüber Documentation Standards.

80

A. Glossar

Approach DB: Hier wird eine erste, sehr kurze Anforderungsbeschreibung festgehalten. Mannennt die Einträge Tickets.

Bug: Bezeichnung für einen Fehler

Child-Anforderung: Eine paarweise disjunkte Menge von Child-Anforderungen bildet eineParent-Anforderung.Customizing: Damit wird der Vorgang bezeichnet indem die Plattform für den Kunden kon-�guriert wird. Dies �ndet einmalig bei der Installation statt.

Entwicklung: Eine der drei Phasen pro Quartal. In dieser Zeit werden Anforderungen imple-mentiert.

FeatureLead: siehe FeatureverantwortlicherFeatureSpeci�cation: 1.)Dokument zur Beschreibung des gewünschten Features. Es enthältdie Inhalte des Lasten- und P�ichtenhefts.Im Alltagsgeschäft wird sie noch mit den veralteten Begri�e FuncSpec und Speci�cation be-zeichnet. 2.) Das erste Kapitel der FeatureSpeci�cation. Damit besteht die F. aus dem F. unddem RealisationConcept. Da dies zu Verwirrungen führt wird in dieser Arbeit nur die ersteBedeutung verwendet. Für die zweite Bedeutung wird der Begri� Speci�cation verwendet.Featureverantwortlicher: Vom Programm Manager eingeteilter Entwickler als Hauptver-antwortlicher für ein FeatureFunSpec: Veralteter Begri� für ein abgescha�tes Dokument ähnlich der FeatureSpeci�cation

ImplementationConcept: Dokumentation der Entwickler über die technische Umsetzungeines Features

Kundenprojektleiter: Auch KundenPL, Kollege aus der Technik oder Cust-PM. Mitarbei-ter, der die Kunden im direkten Kontakt betreut. Interner als Kunde betrachtet und damit derAnsprechpartner bei Rückfragen.

Parent-Anforderung: Der Wurzelknoten in einem Baum von Anforderungen.Plattform: Das Hauptprodukt von TOUCCEA.Presales: Mitarbeiter der gleichnamigen Abteilung. Der Presales wird nach den Sales aktiv,sobald es zu technischen Fragen kommt, auch Vertriebler, Kollege aus der Technik.Product Manager (PM): Die drei Product Manager sind für die konzeptionelle Weiterent-

81

A. Glossar

wicklung der Plattform verantwortlich.Professional Service (P.S.): Abteilung aus der Kundenprojektleiter kommen.Programm Manager (PGM): Er verwaltet den Projektplan.Project Manager: Eine andere Bezeichnung für den KundenPL.Projekt: Abkürzung für Kundenprojekt. Alle Aufgaben um die Plattform bei dem Kundenzum Laufen zu bringen.Projektplan: Übersicht für die Entwickler über o�ene Features. Er wird vom ProgrammManager gepfegt.

RealisationConcept: 2.Kapitel der FeatureSpeci�cation. Entspricht einem P�ichtenheft.

Sales: Mitarbeiter, die den ersten Kundenkontakt herstellenShare Point Server: Werkzeug zur internen DokumentationsverwaltungSigni�kanz: Wert anhand dessen die Prioritätsreihenfolge der Features bestimmt wird. Erwird aus den Einträgen in der Bewertungs- und Gewichtungsmatrix berechnet.Source Safe: Ort, an dem fertiger Code hinterlegt wirdSpeci�cation: 1.) Das erste Kapitel der FeatureSpeci�cation. Früher ein separates Dokument.2.) Status einer Anforderung, während derer die Speci�cation geschrieben wird.Stabilizing: Eine der drei Phasen pro Quartal. In dieser Zeit werden Bugs behoben.

Team Foundation Server: Software zum Management von Work-Items (besonders An-forderungen und Bugs)Test: Eine der drei Phasen pro Quartal. In dieser Zeit wird die komplette neue Version geprüft.TestDocument: Dokument mit Notizen der Tester über den Test, nicht zwingend, sondernals Merkhilfe bei komplexen FeaturesTestManual: veralteter Begri� für TestDocumentTicket: Bezeichnung eines Eintrags in der Approach DB. Wird auch Anforderung, Featureoder Wunsch genannt.

Übergabedokument: Das Ü. wird von den Entwicklern über ein implementiertes Featureverfasst und persönlich der Testabteilung übergeben.

Work-Item: Eintrag im Team Foundation Server. Mögliche Work-Item-Typen sind Require-ment, Bug, Change Request.

82

B. Umfragebogen zum Fragenkatalog für

KundenPL

Zur Verbesserung der Qualität der FeatureSpeci�cation wurde der Fragenkatalog ent-wickelt. Diese 10 Fragen/Au�orderungen sollen nach der Erstellung durchgegangenwerden und auf mögliche Fehlerquellen (wie z.B. fehlende Alternativstränge, sprach-liche Mängel) aufmerksam machen. Bei guten Dokumenten sollten Sie jede Frage/Auf-forderung mit � ja �beantworten können!

Diese Fragen/Au�orderungen sollen hiermit evaluiert werden. Die Umfrage dauert ca.15 Minuten.

1. Werden keine Entwurfs-, Architektur-, Test- und Implemen-tierungsentscheidungen behandelt? Gefragt sind Problembeschreibungenund keine Lösungsansätze.

• Wie schwierig und aufwändig ist es für Sie das 1. Kapitel der FeatureSpeci�cationsso zu schreiben, dass Sie diese Frage mit � ja�beantworten können?

• Wie wichtig ist Ihnen dieser Aspekt für ein gutes 1.Kapitel?

• Wie oft bekommen Sie Rückfragen zu diesem Thema?

2. Ist der Text eindeutig: gibt es keine uneindeutigen Begri�e? Werden For-mulierungen beim Kunden anders verstanden und verwendet als aucotecin-tern? Legen Sie gegebenenfalls ein Glossar mit strittigen Begri�en an.



83

B. Umfragebogen zum Fragenkatalog für KundenPL


3. Wurden Haupt- und Alternativstränge identi�ziert und in logischer Ab-folge korrekt beschrieben? Haben Sie mögliche Fehlerfälle und Ausnahmenerläutert?




4. Ist Ihr Dokument sprachlich korrekt? Dies betri�t Rechtschreibung,Grammatik, Lesbarkeit und die Vermeidung von Interpretationsspielräumen.




84

5. Enthält Ihr Dokument weder Redundanz noch fehlen nötige Angaben? IstIhr Dokument widerspruchsfrei?




6. Haben Sie Testfälle angegeben, die die Erfüllung der Abnahmekriterienbelegen? Gibt es zu jedem Testfall einen Sollwert?




85


7. Ist Ihre Anforderung klar in den Prozess eingebettet, d.h. sind Vorbe-dingungen, auslösendes Ereignis, eine Startsituation und Nachbedingungengegeben?




8. Haben Sie Beispieldaten angegeben?




86

9. Ist Ihre Anforderung nicht bereits im TFS vorhanden?




10. Haben Sie einen angemessenen Detaillierungsgrad verwendet?




Vielen Dank für die Teilnahme an der Umfrage! Hier können Kritik, Lobund andere Kommentare hinterlassen werden.

87


88

C. Datensatz zur Umfrage

Die Antworten der Umfrageteilnehmer wurden mittels Zahlen codiert. Die Kreise desUmfragebogens wurden von links nach rechts mit 1 bis 6 durchnummeriert. Beispiel: dieAntwort �zu 80% aller Anforderungen stelle ich Rückfragen� entspricht einer 2.

89

C. Datensatz zur Umfrage

90

Literaturverzeichnis

[Ale2009] Ian Alexander, Ljerka Beus-Dukic, Discovering Requirements, Wiley, 2009

[Bla2011] Ed Blankenship, Martin Woodward, Grant Holliday, Brian Keller, Profes-sional Team Foundation Server 2010 Wiley Publishing, Inc., 2011

[Bou08] Christian El Boustani Quantitative und qualitative Messung von Software-Anforderungen Bacheloarbeit, Leibnizuniversität Hannover 2008);http://www.se.uni-hannover.de/pub/File/pdfpapers/Boustani2008.pdf

[Kne09] Ralf Kneuper, Ernest Wallmüller (Hrsg.), CMMI in der Praxis- Fallstudi-en zur Verbesserung der Entwicklungsprozesse mit CMMI, dpunkt.verlag,2009

[Lam05] Giuseppe Lami, QuARS: A Tool for Analyzing Requirementshttp://www.sei.cmu.edu/reports/05tr014.pdf, 2005

[Lef00] Dean Le�ngwell, DonWidrig,Managing Software Requirements: A Uni�edApproach Addison Wesley Longman, Inc., 2000

[Mor10] Robert Mory, Metrikbasierte Qualitätsmodellierung von Use-Case-basierten Anforderungsspezifkationen (Diplomarbeit, RWTH Aachen,2010); https://af3.fortiss.org/attachments/19/Morys2010.pdf

[Puf2010] Roland Pu�er, Markus Wippel, Arbeiten mit Team Foundation Server2010, O`Reilly Verlag GmbH & Co.KG, 2010

[Rup04] Chris Rupp/SOPHIST GROUP, Requirements-Engineering und -Management, Carl Hanser Verlag München Wien, 2004

Auÿerdem wurden folgende Webseiten verwendet:

(a) www.aucotec.com; Stand: 19.11.2011

(b) http://www.bsozd.com/?p=17842; Stand: 22.11.2011

(c) http://www.daswirtschaftslexikon.com/d/hierarchie/hierarchie.htm; Stand:12.3.2012

(d) http://easyweb.easynet.co.uk/iany/other/vendors.ht#ARM; Stand: 16.2.2012

(e) www.haz.de/Nachrichten/Wirtschaft/Deutschlang-Welt/Softwarehaus-aus-Hannover-steht-vor-Umsatzsprung; Stand: 1.12. 2012

(f) http://it-republik.de/dotnet/artikel/Team-gewinnt-%96-das-Work-Item-Tracking-1625.html;Stand 22.11.2011

(g) http://msdn.microsoft.com/de-de/library bzw. http://msdn.microsoft.com/en-us/libraryStand: 15.3.2012

(h) http://www.microsoft.com/germany/visualstudio/products/team/visual-studio-team-

91

Literaturverzeichnis

foundation-server.aspx; Stand: 22.11.2011

(i) http://publib.boulder.ibm.com/infocenter/rsdp/v1r0m0/topic/com.ibm.help.download.doors.doc/pdf92/managing_doors_de.pdf; Stand:20.3.2012

(j) http://de.wikipedia.org/wiki/Capability_Maturity_Model_Integration; Stand: 4.1.2012

(k) http://de.wikipedia.org/wiki/Lesbarkeitsindex; Stand: 13.2.2012

(l) www.de.wikipedia.org/wiki/Likert-Skala; Stand: 29.3.2012

Weiterhin Eingang in diese Arbeit fanden diverse interne und nicht ö�entlich zugänglicheDokumente der Firma.

92

Erklärung der Selbstständigkeit

Hiermit versichere ich, dass ich die vorliegende Diplomarbeit selbständig und ohnefremde Hilfe verfasst und keine anderen als die in der Arbeit angegebenen Quellen undHilfsmittel verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form noch keinemanderen Prüfungsamt vorgelegen.

Hannover, den 10. Mai 2012

Konstanze Krüger

93

analyse und bewertung eines requirements engineering ... · zusammenfassung ein lokales unternehmen...

Documents