Pflichtenheft - DHBW Stuttgart

Download Report

Transcript Pflichtenheft - DHBW Stuttgart

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Übersicht

Inhalt:

  Einbettung in den Projektablauf 4 Teile eines Pflichtenhefts   Funktionale Anforderungen Nichtfunktionale (NF) Anforderungen     an die Verfügbarkeit an die Ergonomie an die Performance an die Wartbarkeit   Anforderungen an die technische Realisierung Anforderungen an den Projektablauf  Anforderungsmanagement

Datei: PHVorlesung.ppt

Nov 2010 Seite 1

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Einbettung in den Projektablauf (V-Modell)

Projektablauf beim Auftraggeber (AG) Projekt genehmigen Anforderungen festlegen Projekt ausschreiben Projekt beauftragen

Nov 2010

Realisierung begleiten Lieferung in Betrieb nehmen Ausschreibung incl.

Lastenheft Angebot Vertrag Pflichtenheft Status berichte Change Requests Lieferung Projektablauf beim Auftragnehmer (AN) Projekt genehmigen Angebot abgeben Projekt beauftragen System realisieren System ausliefern

Seite 2

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

Pflichtenheft

• • • • Das Pflichtenheft bildet die Grundlage für die

vertraglich

festgehaltenen Leistungen eines IT-Auftragnehmers. Im Pflichtenheft sind nach

DIN 69905

die vom "Auftragnehmer erarbeiteten Realisierungsvorgaben" niedergelegt. Sie beschreiben die "Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts". Im Pflichtenheft sind im wesentlichen die

Ergebnisse der Anforderungsanalyse

dokumentiert: •

WAS

muss wofür produziert werden?

• Für

WAS

wird das Endprodukt eingesetzt? • •

WAS WAS

muss das Endprodukt demnach beinhalten? müssen die Funktionen des Endprodukts bewerkstelligen? •

WAS

muss über kurz oder lang gespeichert werden?

Zusätzlich werden im Pflichtenheft noch Anforderungen an die Qualität, an die techn. Realisierung und an die Organisation des Projektablaufs formuliert.

Buchempfehlung:

Requirements-Engineering und -Management, C. Rupp, HANSER, 2009

Seite 3

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

4 Teile eines Pflichtenhefts Ein

Pflichtenheft

lässt sich auf verschiedene Weise gliedern (s.a. Beispiele im Anhang). Folgende Angaben sind jedoch obligatorisch:

Funktionale Anforderungen

(incl. Datendefinitionen) • •

Nichtfunktionale (NF) Anforderungen

(aus Qualitätsgründen) – Verfügbarkeit – Ergonomie (Benutzerschnittstelle) – – Performance Wartbarkeit (Architektur)

Anforderungen an die techn. Realisierung

(aus Kostengründen) – Programmiersprache, Entwicklungsumgebung – Standards bzgl. Einsatz von Systemkomponenten •

Anforderungen an den Projektablauf Seite 4

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

• • • •

Nov 2010

Pflichtenheft Funktionale Anforderungen

Funktionale Anforderungen (Funktionen

und

Daten) werden häufig aus der

Aufgabenbeschreibung

bzw. aus dem

Lastenheft

kopiert.

– Ziel: Jede funktionale Anforderung wird im Pflichtenheft als

Use case

(s. UML) spezifiziert mit folgenden Inhalten: Kurze Ablaufbeschreibung – – – Input und Output Auslösendes Ereignis Durchführender Bei komplexen Abläufen kommen zusätzliche Diagrammarten zum Einsatz: –

Ablauf-/Flussdiagramm

nach DIN 66001 –

Aktivitätsdiagramm

der UML Ist der Einsatz einer Datenbank gefordert, müssen die Daten in einem

Entity Relationship Diagramm

UML spezifiziert werden.

oder auch

Klassendiagramm

nach

Seite 5

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Funktionale Anforderungen

Beispiel für ein Use case

Use case Titel:

Auftrag ausführen Nummer:

FREQ 21

Kurzbeschreibung (Ziel):

Ware an Kunde geliefert

Akteure:

Kundensachbearbeiter, Lagersachbearbeiter, Buchhaltung

Auslösendes Ereignis:

Bestellung des Kunden liegt vor

Vorbedingung:

Bestellung

Nachbedingung (bei Erfolg):

Buchhaltung Ware ausgeliefert (auch Teillieferungen), Rechnungskopie bei

Nachbedingung (bei Fehlerfall): Standardablauf:

Mitteilung an Kunden, dass nicht lieferbar 1. Kundendaten abrufen 2. Lieferbarkeit prüfen 3. Rechnung erstellen 4. Auftrag vom Lager ausführen lassen

Erweiterungen: Alternativen:

5. Rechnungskopie an Buchhaltung geben 1a. Kundendaten aktualisieren 1a. Neukunden erfassen 3a. Rechnung mit Nachnahme erstellen 3b. Rechnung mit Bankeinzug erstellen

Nov 2010 Seite 6

• • •

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

Pflichtenheft NF Anforderungen an die Verfügbarkeit

Die Verfügbarkeitsanforderungen gelten für die Nutzung des

Gesamtsystems

(Hard- und Software) durch den Endanwender. Zur Vereinfachung der Spezifikation werden Leistungsanforderungen häufig kategorisiert und müssen dann nur noch projektspezifisch ausgewählt werden (Angaben beziehen sich auf einen Zeitmonat mit 30 Tagen/Monat und 24 Stunden/Tag): Kategorie A B C D Zeitl. Verfügbarkeit 99,75 % 99,5 % 99 % 98 % Max. Ausfalldauer 30 Min.

3,6 Std.

7 Std.

14 Std.

Max. Anzahl Ausfälle 4 4 10 10 Die Erfüllung der Verfügbarkeit wird im praktischen Betrieb über einen festgelegten Zeitraum (z.B. 2 Monate vor Ablauf der Gewährleistungszeit) ermittelt.

Seite 7

• • •

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

Pflichtenheft NF Anforderungen an die Ergonomie

Vorgabe eines Style-Guides, der verwendet werden muss.

Empfehlung: Grundsätze der Dialoggestaltung gemäß ISO 9241 sollen implementiert werden.

– –

Aufgabenangemessenheit:

vereinfachen? … Ist es möglich, wiederholtes Eingeben zu

Selbstbeschreibungsfähigkeit

: Sind alle Systemmeldungen verständlich? … – –

Steuerbarkeit:

Können Sie bei Bedarf eine Aufgabe unterbrechen? …

Erwartungskonformität

: Sind Sie bei Wartezeiten sicher, dass das Programm arbeitet? ...

Fehlertoleranz

: Bekommen Sie bei fehlerhaften Eingaben Korrekturhinweise?...

Individualisierbarkeit:

Können Sie das Programm so einstellen, dass das Arbeiten leichter fällt? … –

Lernförderlichkeit:

probieren? … Ermöglicht Ihnen das Programm, etwas gefahrlos aus zu Dazu existieren Checklisten, die beim Test eingesetzt werden können, z.B.

//www.gesuenderarbeiten.de/service/software/Software-Fragebogen.pdf

Seite 8

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

Pflichtenheft NF Anforderungen an die Performance

• • Das Antwortzeitverhalten eines Systems wird häufig in vier Kategorien eingeteilt. Eine projektspezifische Festlegung könnte dann folgendermaßen aussehen: Kategorie < 1,5 Sek < 2,5 Sek < 10 Sek Für häufig benötigte Dialoge (Rückmeldungen, Info-Funktionen) A B 98 % 85 % 100 % 95 % 100 % 99 % für Dialoge mit Transaktionen (Terminplanung, Stammdatenauskunft) C D für umfangreiche Transaktionen 60 % 50 % 85 % 70 % 98 % 90 % Die Erfüllung des Antwortzeitverhaltens wird im praktischen Betrieb über einen festgelegten Zeitraum (z.B. 2 Monate vor Ablauf der Gewährleistungszeit) ermittelt.

Seite 9

• • • • • •

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

Pflichtenheft NF Anforderungen an die Wartbarkeit

Welches Qualitätsmodell (Metriken) liegt zugrunde?

– – • Klassische Metriken: Kommentarverhältnis, McCabe-Komplexität, ..

Für die Objektorientierung existieren weitere Metriken:

DIT

: Je größer die

Vererbungstiefe

, desto größer die Fehlerwahrscheinlichkeit (FW) • •

NOC

: Je größer die

Anzahl Subklassen einer Klasse

, desto geringer die FW

WMC

: Je größer die

Anzahl Methoden und Operatoren einer Klasse

, desto größer die FW Welche Programmierrichtlinie ist zu verwenden?

– – Bei JAVA bieten sich die Code Conventions (Sep/97) von SUN an für C# bietet Microsoft entsprechende Richtlinie an Sind spezielle Entwurfsmuster oder getestete Komponenten (Reuse) aus anderen Systemen zu verwenden?

Welche Architektur-Standards sind einzusetzen, z.B. Vorgabe einer Referenzarchitektur oder eines Ebenenkonzept?

Welche Produkte sind vorgeschrieben für die Entwicklung?

Nachweis

checkstyle

durch den Einsatz eines Source Code Analyse Tools, z.B.

Seite 10

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Anforderungen an die techn. Realisierung

• • – – – Mindestens werden benötigt: Aussagen zur benötigten Hardware incl. Betriebssystem – – Aussagen zur verwendeten Programmiersprache Aussagen zum Einsatz von Fremdprodukten, Opensource-Produkten Aussagen zu den verwendeten Protokollen bei verteilten Subsystemen … Beachte auch die NF Anforderungen an die Wartbarkeit, die spezielle (innere) Qualitätseigenschaften wie Modularität, Änderbarkeit usw. betreffen

Nov 2010 Seite 11

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Anforderungen an den Projektablauf

• – – Mindestens werden benötigt: • • • Vorgehensmodell mit Meilensteinplan, z.B.

Reporting, Kommunikation zw. AG und AN Releasemanagement bei Weiterentwicklungen Risikomanagement Aufwandsplanung und -kontrolle – – • • • • • • Abnahmekriterien Lieferumfang: Funktionelle Spezifikation (Teil des Pflichtenhefts) Entwurfsdokumentation (kommentierter) Source Code Bedienungsanleitung Installationsanleitung Testdokumentation Analyse Ergebnis Design Ergebnis

Nov 2010

Implementierungs Ergebnis

Seite 12

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Anforderungsmanagement

Jede Anforderung hat folgende Gliederungspunkte: – – – – Ident-Nr Anforderungstyp (z.B. Performance, GUI, ..) Titel der Anforderung Beschreibung – – – Messkriterien zur Erfüllbarkeit Komplexität in der Realisierung/Abnahme Aufwand – – Priorität (hoch, mittel, klein) Realisierungstermin (ggfs. CR) Anforderung identifizieren [angenommen] Anforderung bewerten

Nov 2010

– – – Status (identifiziert, bewertet, …) Verantwortlicher (fürs Controlling zust.) Datum (der letzten Änderung) Anforderung priorisieren [abgelehnt] Anforderung löschen Neue Anforderungen

während

der Entwicklung heißen

Change Requests

(CR)

Seite 13

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

Pflichtenheft Anforderungsmanagement

Qualitätskriterien für Anforderungen

1) 2) 3) 4) 5) 6) 7) Atomar

: Die Anforderung lässt sich nicht sinnvoll in mehrere Anforderungen zerlegen.

Eindeutigkeit

: Die Anforderung lässt genau eine Interpretation durch den Adressaten zu.

Nachweisbarkeit:

Es gibt eine im Projektrahmen anwendbare Möglichkeit nachzuweisen, dass das System die Anforderung erfüllt.

Vollständigkeit:

Informationen.

Die Anforderung enthält alle für ein eindeutiges Verständnis relevanten

Widerspruchsfreiheit:

Es existieren keine Widersprüche innerhalb der Anforderung oder zwischen Anforderungen.

Redundanzfreiheit:

Aussagen werden innerhalb der Anforderungen oder der Anforderungsdokumente nur einmal gemacht.

Nachvollziehbarkeit (Traceability):

Traceability für Anforderungen ermöglicht die Beantwortung folgender Fragen: Auf welches Ziel ist die Anforderung zurückzuführen?

- Welche Anforderungen stammen von welchen Kunden?

Welche Entscheidung führt zur Ablehnung der Anforderungen?

- In welcher Komponente wurde die Anforderung umgesetzt?

- Welcher Test deckt die Realisierung der Anforderung ab?

- Gibt es Anforderungen, deren Realisierung die betrachtete Anforderung beeinflussen?

Seite 14

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Anforderungsmanagement

Übungen zum Thema „verbesserungswürdige/schlechte Anforderungen“:

Nov 2010

Beispiel 1:

Daten müssen übertragen werden.

Beispiel 2.

Der Motor C.3 muss auf Basis der neuesten Technologie gebaut werden und somit 15 Jahre fehlerfrei laufen.

Fragen: Welche Qualitätskriterien sind verletzt?

Wie kann eine verbesserte Anforderung lauten?

Tip: Anforderungen werden grundsätzlich im Aktiv formuliert!

Seite 15

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Anforderungsmanagement

• • Verletzte Qualitätskriterien zu Beispiel 1:

Eindeutigkeit

: Welche Daten genau?

Vollständigkeit

: Wer überträgt? An wen oder was wird übertragen? Woher wird übertragen?

• • • Verletzte Qualitätskriterien zu Beispiel 2:

Atomar

: Hier handelt es sich um zwei Anforderungen

Eindeutigkeit

: Welche Technologie ist gemeint, was bedeutet fehlerfrei?

Nachweisbarkeit

: Wie kann die Testabteilung „15 Jahre fehlerfrei“ testen?

Verbesserte Anforderung (Beispiel 1):

Das System RT4 muss die Adressdaten xyz vom Eingabefeld „Email-Adressen“ in den Speicherbereich Omega übertragen.

Nov 2010

Verbesserte Anforderung (Beispiel 2).

Der Motor C.3 muss vom Entwicklungsteam auf Basis der Technologiegeneration x.1/09 entwickelt werden.

Der Motor darf bei einem Test in der Lasttestklasse 10 eine Fehlerrate von xy nicht überschreiten.

Seite 16

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

Pflichtenheft Anforderungsmanagement

Anforderungen natürlichsprachlich dokumentieren:

Der Einsatz der natürlichen Sprache birgt die Gefahr von Missverständnissen. Wir kennen 5 grundlegende Ursachen für unterschiedliche Auslegungen und verschiedene Interpretationen:

1.

2.

3.

4.

5.

Nomalisierungen

nur dann verwenden, wenn der dahinter liegende Prozess vollständig definiert und bekannt ist.

Substantive

sollten nie

ohne ausreichenden Bezugsindex

verwendet werden.

Beim Verwendung von Verhalten wirklich für alle durch die Quantoren zusammengefassten Objekte gelten soll (Signalwörter sind:

Universalquantoren

nie

,

immer

,

kein

,

jeder

immer hinterfragen, ob das geforderte ,

alle

,

irgendeiner

,

nichts

).

Unvollständig spezifizierte Bedingungen

eintritt.

sollten ermieden werden, insbesondere sollte stets beschrieben werden, was passieren soll, wenn eine Bedingung nicht Manche Verben, wie z.B. der Begriff „übertragen“ zählen zu den

unvollständig spezifizierten Verben

. Diese benötigen zu ihrer vollständigen Erklärung zumindest die drei Ergänzungen,

was

übertragen,

von wo

übertragen und

wohin

übertragen wird.

Seite 17

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3 Nov 2010

Pflichtenheft Anforderungsmanagement

Anforderungen natürlichsprachlich dokumentieren:

Übung: Verbessern Sie die vorliegenden Anforderungen und ordnen sie den vorgestellten Problemursachen (1-5) zu:

Zur Anmeldung des Benutzers werden die Login-Daten eingegeben.

Das Restaurantsystem soll einem registrierten Gast bei einem Alter von über 17 Jahren alle im Lokal angebotenen Getränke anzeigen.

Bei einem Systemabsturz soll ein Neustart des Systems erfolgen.

Die Daten sollen dem Benutzer auf dem Terminal angezeigt werden.

Das System soll in jedem Untermenü alle Datensätze anzeigen Seite 18

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Anforderungsmanagement

Anforderungen natürlichsprachlich dokumentieren:

Lösung der Übung:

Verbesserte Anforderungen

oder

Hinweise auf Fehler

.

Das System soll dem Benutzer ermöglichen, seinen User-Namen und sein Passwort über die Tastatur am Terminal einzugeben (5, Aktiv-Formulierung).

Bei einem Systemabsturz soll ein Neustart des Systems erfolgen (1); die Begriffe

„Systemabsturz“ und „Neustart“ beschreiben jeweils einen Prozess, der genauer analysiert werden sollte.

Nov 2010 Das Restaurantsystem soll einem registrierten Gast

bei einem Alter von unter 16 Jahren ausschließlich alkoholfreie Getränke auzeigen;

bei einem Alter von 16 - 17 Jahren alkoholfreie und alkoholische Getränke ohne Branntwein anzeigen;

bei einem Alter von über 17 Jahren alle im Lokal angebotenen Getränke anzeigen (4).

Das System soll dem registrierten Benutzer seine Rechnungsdaten auf dem Terminal, an dem er angemeldet ist, anzeigen (2).

Das System soll in jedem Untermenü alle Datensätze anzeigen (3): wirklich

ALLE Datensätze, wirklich in JEDEM Untermenü?

Seite 19

DHBW Stuttgart, Informatik, SW-Engineering, Kapitel 3

Pflichtenheft Anhang: Beispiele

Beispiel nach Balzert (über Wikipedia)

1. Zielbestimmung 1.1 Grenzkriterien 1.2 Wunschkriterien 1.3 Abgrenzungskriterien 2. Produkteinsatz 2.1 Anwendungsbereiche 2.2 Zielgruppen 3. Produktkonfiguration Software, Hardware, Orgware 4. Produkt-Umgebung Schnittstellen, Betriebsbedingungen 5. Produkt-Funktionen 6. Produkt-Leistungen 7. Benutzerschnittstelle 8. Qualitäts-Zielbestimmung 9. Globale Testfälle 10. Entwicklungs-Konfiguration Software, Hardware, Orgware 11. Ergänzungen 6.

7.

8.

9.

Beispiel V-Modell (s. web)

1.

Ausgangssituation und Zielsetzung 2.

3.

Funktionale Anforderungen Nicht-funktionale Anforderungen 4.

5.

Risikoakzeptanz Lebenszyklusanalyse und Gesamtsystemarchitektur Schnittstellenübersicht 10.

Lieferumfang Abnahmekriterien Anforderungsverfolgung zu den Anforderungen (Lastenheft) Anforderungsverfolgung

Nov 2010 Seite 20