Lasten- und Pflichtenhefte

Transcription

Lasten- und Pflichtenhefte
Workshop Softwareentwicklung & IT-Recht
NIK, 26.10.2011
Zur Person

Johannes Dreikorn

Bereichsleiter Technische Kommunikation
doctima GmbH

Standort: Fürth

Angebot: Kunden- und Servicekommunikation

Branchen:

Industrie: IT, Medizintechnik, Maschinenbau

Institutionen: Banken, Krankenkassen, Versicherungen
Mitarbeiter: zwischen 25 und 30 (feste Mitarbeiter)
26.10.2011
Lasten- und Pflichtenhefte | doctima | Johannes Dreikorn
2
Technische Kommunikation
Produktlebenszyklus: informierende und instruierende Texte, z. B.

Lastenhefte

Pflichtenhefte

Anwenderdokumentation

…

dazu jeweils: Seminare und Coachings
26.10.2011
3
Hintergrund: Wovon reden wir eigentlich?
26.10.2011
4
Begriffsklärung
Lastenheft
Auftragnehmer
Auftraggeber
Was?
Wofür?
Requirement
Anforderung
26.10.2011
Feature
Lösung
Was?
Womit?
Pflichtenheft
5
Funktion und Nutzen
AG
Lastenheft
Pflichtenheft

Zwang zur Konkretisierung bei
Entwicklungsvorhaben (neue
Erkenntnisse durch
Versprachlichung von Ideen)
Matrix zur Auswahl von
Entwicklungspartnern
(Ausschreibungen)
Rechtssicherheit
Imageaspekt (Nachweis von
Professionalität)

Klarheit über Bedürfnisse des
Kunden
(Lastenheft = Festlegung)
Einblick in Strukturiertheit und
Professionalität des Kunden

AN

26.10.2011
fachliche Spiegelung eines
Entwicklungsvorhabens (Sicherheit
zu realistisch erreichbaren
Entwicklungsergebnissen)
Know-how-Gewinn durch
lösungsbezogene Strukturierung
Einblick in Leistungsfähigkeit des
AN
Plattform zum Nachweis von
Kompetenz und Leistungsfähigkeit
(Marketingfunktion)
teilweise einzige Möglichkeit, um
Entwicklungsvorhaben zu
akquirieren (Ausschreibungen).
Vorlage für weitere Entwicklungsschritte (je besser das Pflichtenheft,
desto leichter die Umsetzung)
Einnahmequelle
Rechtssicherheit
6
Lastenheft & Pflichtenheft: Der Schlüssel zum Erfolg?
26.10.2011
7
Verortung

Requirement-orientierte Softwareentwicklung

Hierarchisches Entwicklungsmodell im Hintergrund

Lasten- und Pflichtenhefte:

Integraler Bestandteil des Entwicklungsmodells

Steuer- und Kristallisationspunkte
26.10.2011
8
Verortung

„Gegenentwurf“: agile Software-Entwicklung

permanente Einbindung des Kunden über den ganzen Entwicklungsprozess
hinweg

evolutionärer Prozess, nicht hierarchisch

Plus: Flexibilität, gemeinsames Erarbeiten von Lösungen, schneller Einstieg
Dokumente in agilen Prozessen

Lasten- und Pflichtenhefte in herkömmlicher Form:
redundante, temporäre Dokumente (Computerwoche)

Dokumentation wird benötigt, muss aber grundlegend anders organisiert werden.
Literaturtipp:

computerwoche.de

Agiles V-Modell - ein Widerspruch?
26.10.2011
9
Wichtig ist das Spiel ohne Ball
Planen Sie Ihr Dokument sorgfältig
26.10.2011
10
Zwei grundlegende Fragen
(1) Was wollen Sie erreichen? (Ihre Ziele)
… steuern
… informieren (Reporting)
… anleiten
… (höflich) ablehnen
…
(2) Wen wollen/müssen Sie erreichen? (Ihre Zielgruppe/n)
Persönlichkeit, Qualifikation, Situation, Emotion, Position, Priorität
26.10.2011
11
Wählen Sie
... zielgruppengerechte Inhalte
... und eine stimmige Gliederung
26.10.2011
12
Inhalte: Was gehört in ein Lastenheft?
Zweck des Dokuments

Was & Warum darlegen
Wie viel Spielraum möchte ich lassen?

Wo reichen Ziele und Szenarien?
(offen in Umsetzung)

Wo verlange ich ganz
bestimmte technische Lösungen?
26.10.2011
13
Inhalte:
Was gehört in ein Pflichtenheft?
Muss

„Antwort“ auf alle Anforderungen des Lastenheftes.

Klares Bild der Lösung(en).

Was ich selbst unbedingt platzieren möchte.
(z. B. Abnahmekriterien/Testszenarien, Liste offener Punkte)

Was für die Zielgruppe wichtig ist.
(z. B. Management-Summary)

Identifikations-Daten
(Stand, Version, Änderungshistorie)
26.10.2011
14
Inhalte:
Was gehört in ein Pflichtenheft?
Erweiterungen

Reformulierung von Projektidee und Zielen
(z. B. Ist-Zustand und Soll-Zustand)

Organisatorisches
(z. B. Namen von Projekt-Beteiligten)

Wünsche/Vorschläge/Bedingungen für die Projektabwicklung:
(soweit nicht gefordert)

Zeitplan

Lieferbestandteile

Vertragliches
26.10.2011
15
Hilfsmittel I: Mustergliederungen
26.10.2011
16
Hilfsmittel II: Anforderungs-Typologien
26.10.2011
17
Praxis-Tipps

Mustergliederungen sind eine gute Einstiegshilfe.

Im Detail sind individuelle Anpassungen gefragt.

Eine gute Gliederung „erzählt eine Geschichte“.

Beispiel
26.10.2011
18
Verzichten Sie auf Entwickler-Prosa
26.10.2011
19
Beispiel

Thema Display

Vorschlag !?
26.10.2011
20
Formulierung:
Welche Fehler werden deutlich?

Basiskriterien Textverständlichkeit

zu viel Fließtext

unverständliche Sprache
Basiskriterien Zielgruppenorientierung

Stakeholder nicht berücksichtigt (z. B. Manager)

Potenziale der Leseransprache nicht genutzt
Besondere Qualitätskriterien

Anforderungen nicht prüfbar

Anforderungen nicht vollständig

Falsche Darstellungstyp für Inhalte gewählt
26.10.2011
21
Textstruktur: Detailinformationen
26.10.2011

häufige Praxis:
Fließtext über Fließtext

Problem

Informationen „verschwinden“ in
den Sätzen

Leser kann Informationen kaum
entnehmen

Ersteller können vorhandene Texte
nicht ergänzen.
22
Detailinformationen: Listen & Tabellen

26.10.2011
Unterschied:
Listen und Tabellen schaffen
eine Detail-“freundliche“
Umgebung
Nutzen: Informationen sind

schnell zu finden (Scannen
möglich)

schnell zu lesen

gut zu merken

leicht zu ergänzen
23
Hüten Sie sich vor ...
26.10.2011
24
Hüten Sie sich vor ...

... Mehrfachnennung von Detailinformationen.
(Fehlerquelle, widersprüchliche Aussagen)

... verklausulierter Sprache, wo Dinge (noch) unklar sind.

... sprachlicher Standardisierung, die Dokumente unlesbar
macht.
Die Software muss ...
Die Software kann ...
Die Software soll ...
26.10.2011
25
Schreiben Sie so konkret wie möglich
26.10.2011
26
Anforderungen unklar
Das geplante System soll besser sein
als das Vorgängersystem. Die Antwortzeiten des geplanten Systems
sollen um 20% kürzer sein als die
Antwortzeiten des Vorgängersystems.
Das geplante System soll
leicht benutzbar sein.
Das geplante System soll
intuitiv benutzbar sein.
Das geplante System soll von
Personen ohne Vorkenntnisse und
ohne eine umfassende Schulung
benutzt werden können.
Das geplante System soll intuitiv benutzbar
sein.
Hintergrund: 80% der Nutzer verwenden das
System lediglich 2 bis 3 mal pro Jahr.
26.10.2011
27
Zielorientierte Anforderungen
Beispiele

Das geplante System soll von Personen ohne eine
umfassende Schulung genutzt werden können.

Das System soll Quartalsberichte in der Hälfte der vom
Vorgängersystem benötigten Zeit erstellen.

Das geplante System soll intuitiv benutzbar sein.
Hintergrund: 80% der Nutzer verwenden das System lediglich
2 bis 3 mal pro Jahr.
26.10.2011
28
Szenarien
26.10.2011
29
Lösungsorientierte Anforderungen
26.10.2011
30
Herzlichen Dank für Ihr Interesse!
Haben Sie…

Fragen?

Anregungen?

Diskussionswünsche?
Gerne auch nach der Veranstaltung:
doctima GmbH
Melli-Beese-Straße 19, 90768 Fürth
Fon: +49 911 975670-0
Fax: +49 9131 975670-188
E-Mail: johannes.dreikorn@doctima.de
Web: http://www.doctima.de
26.10.2011
31