Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 161

7. Projektdokumentation

Dokumentenarten

Inhalte von Lasten- und Pflichtenheften im OO-Umeld

Technische Dokumentation

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 162

Grundstzliches

Die bentigte Dokumentation hngt stark von der Projektart ab, bei externen Kunden ist Lasten- oder Pflichtenheft oft Vertragsbestandteil Externer Kunde, groes Projekt: sehr viel

Aufwand notwendig ffentlicher Auftraggeber: hufig detaillierte

(nicht immer sinnvolle) Vorgaben (V-Modell) Internes Groprojekt: hnlich wie externer Kunde,

aber flexibler im Verlauf anpassbar Mittleres / kleines Projekt: genau notwendige

Dokumentation suchen

Generell Bedenken: Dokumentationserstellung kann langweilig sein, in Groprojekten als Erinnerung wichtig, fr Wartung zentraler Erfolgsaspekt

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 163

Arten von Dokumenten

Lastenheft / Pflichtenheft: zentrale Beschreibung, was gemacht werden soll

Technische Dokumentation, z. B.: Designmodell, Software-Architektur, Design-Entscheidungen

QS-Handbuch: was muss wann von wem wie geprft werden, wann ist Prfung erfolgreich

Werkzeughandbuch: wie, was nutzen, welche Einstellungen Projektdokumentation: Projektplne, Risikobehandlung,

Projektlogbuch Programmdokumentation (typisch mit Dokumentengenerator

aus Quellcode) Nutzungshandbuch / Installationshandbuch

projektabhngig festlegen, was noch/nicht bentigt wird

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 164

Lastenheft oder/und Pflichtenheft

Lastenheft: Auftraggeber beschreibt, was er wnschtDas System soll die Frage aller Fragen suchen

Pflichtenheft: Auftragnehmer beschreibt, was er machtDas System muss (oder wird) die Frage aller Fragen suchen

Frage: wer entwickelt Hefte Wenn Auftraggeber und Auftragnehmer feststehen,

kann Pflichtenheft inkrementell entwickelt werden Pflichtenheft teilweise mit UML fllbar Schwierig: Beim Auftraggeber keine Informatiker

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 165

Lastenheft / Pflichtenheft

Struktur [nur ein Vorschlag]0. Administrative Daten: von wem, wann genehmigt, ...1. Zielbestimmung und Zielgruppen

In welcher Umgebung soll das System eingesetzt werden?Was soll das System lsen, welche Stakeholder betroffen?

2. Funktionale AnforderungenProduktfunktionen (Anforderungen)Produktschnittstellen

3. Nichtfunktionale AnforderungenQualittsanforderungenweitere technische Anforderungen

4. Lieferumfang5. Abnahmekriterien6. Anhnge (insbesondere Glossar)

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 166

Beispielinhalte Pflichtenheft (0/5)

Versionshistorie: Dokumenten-ID + Bezeichnung Versionsnummer Grund der neuen Version Ersteller Zustand (z. B. in Bearbeitung, eingefroren zur

Prfung, freigegeben, veraltet) Bei Freigaben: von wem, evtl. mit rechtverbindlicher

Unterschrift

Versionsmanagement: technisch + Aktenschrank

0. Administrative Daten

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 167

Beispielinhalte Pflichtenheft (1/5)

Zentrale Aussage: In welcher Situation soll das neue System mit welchen Zielen entwickelt werden

Nennung der StakeholderDefinition: Jemand der Einfluss auf die Anforderungen hat, da er vom System betroffen ist (Systembetroffener)

Nennung der Ziele des Systems: Was soll fr welche Stakeholder erreicht werden

Beschreibung der funktionalen Ziele durch Use Cases (Diagramm + Dokumentation)

1. Zielbestimmung und Zielgruppen

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 168

Beispiel: Use Case-Diagramm

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 169

Beispielbeschreibung (1/2)

Handbuch zur Fhrung von Projekten des KundenReferenzen

Lisa Leitung (zentrale Ansprechpartnerin des Kunden)Fachverant-wortlicher

Projektbro (startet Use Case durch Auswahl der Funktionalitt im zu erstellenden System)

beteiligte Aktoren(Stakeholder)

Mitarbeiter des Projektbros haben die Mglichkeit, Projekte mit Teilprojekten anzulegen und zu bearbeiten.

Kurzbeschrei-bung

1.0, 30.01.2008, ErstellungVersion

Ali AnalytikerAutor

-Paket

U1Nummer

Projektstruktur bearbeitenName des Use Case

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 170

Beispielbeschreibung (2/2)

sehr hoch, System macht ohne Funktionalitt keinen Sinn

Kritikalitt

Nutzer kann existierendes Projekt auswhlen,Nutzer kann Daten eines Teilprojekts ndern

alternative Ablufe

1. Nutzer whlt Funktionalitt zur Bearbeitung von Projektstrukturen2. Nutzer legt Projekt mit Projektstandarddaten an3. Nutzer ergnzt neue Teilprojekte4. Nutzer verlsst Funktionalitt

typischer Ablauf

Neue Projekte und Teilprojekte sowie nderungen von Projekten und Teilprojekten wurden vom System bernommen.

Nachbedingun-gen

Die Software ist vollstndig installiert und wurde gestartet.

Vorbedingun-gen

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 171

Beispielinhalte Pflichtenheft (2/5)

Systematische Aufzhlung einzeln nachprfbarer Funktionen (jede Anforderung hat eigene ID, ist getrennt lesbar, berprfbar)

Ansatz: Verfeinerung der Use Cases durch Aktivittsdiagramme; Przisierung der Aktivittsdiagramme durch Text

Aktivittsdiagramme werden inkrementell entwickelt; erst typischer Ablauf, dann Alternativen ergnzen

In der Dokumentation steht nur Ergebnis Literatur: C. Rupp, SOPHIST GROUP, Requirements-

Engineering und Management, Hanser Fachbuchverlag, 2004

2. Funktionale Anforderungen

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 172

Beispiel: Aktivittsdiagramm mit typischen Ablauf

Anmerkung: typischer Ablauf ist immer einfache Sequenz von Aktionen, Ausnahme wie hier: einfache Schleifen

Use Case: Projektstruktur bearbeiten

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 173

Beispiel:Aktivittsdiagramm um Alternativen ergnzt

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 174

Rupp: Anforderungsformulierung

muss

soll

wird

das System

-

dieMglichkeitbieten

fhig sein

Typ 1

Typ 3

Typ 2

Typ 1: Selbstndige Systemaktivitt, System fhrt Prozess selbstndig durch, z. B. Berechnung des bisherigen Aufwandes eines Projekts durch Abfrage aller Teilprojekte und ErgebnisanzeigeTyp 2: Benutzerinteraktion, System stellt Nutzer die Prozessfunktionalitt zur Verfgung, z: B. Verfgbarkeit eines Eingabefeldes, um den Projektdaten einzugebenTyp 3: Schnittstellenanforderung, d. h. das System fhrt einen Prozess in Abhngigkeit von einem Dritten (zum Beispiel einem Fremdsystem) aus, ist an sich passiv und wartet auf ein externesEreignis, z. B. Anfrage einer anderen Brosoftware nach einer bersicht ber die laufenden Projekte annehmen

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 175

Beispielbersetzung

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 176

Beispielinhalte Pflichtenheft (3/5)

Vom System geforderte Eigenschaften, die fr Erfolg erfllt sein mssen

Achtung! Hier kann jede Anforderung ein KO-Kriterium fr das Projekt sein (z. B. Reaktionszeit, Ergonomie)

Achtung! Hier werden gerne Normen zitiert (z. B. wie in Anforderungen an die Dienstqualitt 8DIN EN ISO 66272) beschrieben); diese Normen sind damit vollstndig Vertragsgegenstand

Bei Erstellung hilft wieder Vorlagennutzung (z. B. aus V-Modell XT)

3. Nichtfunktionale Anforderungen

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 177

Definition: Anforderungen an die Dienstqualitt

Mit Anforderungen an die Dienstqualitt (quality of service) sind Anforderungen gemeint, die Angaben ber das Wie einer anderen, meist funktionalen Anforderung oder des gesamten Systems enthalten. Manchmal werden sie auch Dienstgte-Anforderungen oder Constraints genannt. Die DIN EN ISO 66272 unterteilt die Dienstgte in die fnf Merkmale Zuverlssigkeit. Benutzbarkeit, Effizienz, nderbarkeit und bertragbarkeit. Sie beschreibt alle mglichen Aspekte der Dienstqualitt von Systemen praxistauglich und ordnet sie berschneidungsfrei in einem hierarchischen Schema an.

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 178

Beispiele: Anforderungen an die Dienstqualitt

Das System muss sich im Falle des Auftretens eines Fehlers der Kategorie 1 innerhalb von 20 Stunden wieder auf vollem Leistungsniveau befinden.

Das System muss jede Einzelanfrage an den Bestand der Zentralbibliothek innerhalb von 30 Sekunden ausfhren.

Wenn ein Fehler der Kategorie 2 oder 3 auftritt, muss das System den Benutzer auf mgliche Ursachen hinweisen.

Das System muss die Hupe so verwenden, dass diese ihre volle Lautstrke von 112 Dezibel innerhalb von 30 Millisekunden erreicht (Attack-Time).

Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 179

Definition: Anforderungen an Benutzungsschnittstelle

Unter Anforderungen an die Benutzungsschnittstelle ist einerseits zu verstehen, was blicherweise unter Mensch-Maschine-Schnittstelle verstanden wird. Also Form und Funktion von Ein- und Ausgabe-Gerten, die dem menschlichen Benutzer die Interaktion mit dem System ermglichen. Andererseits knnen auch angrenzende Systeme ber eine Benutzungsschnittstelle mit dem zu entwickelnden System verbunden sein, wenn der Zweck diese zu Benutzern macht. Das ist zum Beispiel bei reinen Infrastruktur- oder Middleware-Systemen der Fall, bei denen das S