Lasten- und Pflichtenhefte - nik-nbg.de · Lastenheft Pflichtenheft AG Zwang zur Konkretisierung bei Entwicklungsvorhaben (neue Erkenntnisse durch Versprachlichung von Ideen) Matrix

Workshop Softwareentwicklung & IT-RechtNIK, 26.10.2011

Lasten- und Pflichtenhefte

26.10.2011 Lasten- und Pflichtenhefte | doctima | Johannes Dreikorn 2

Zur Person

Johannes DreikornBereichsleiter Technische Kommunikation

doctima GmbHStandort: Fürth

Angebot: Kunden- und Servicekommunikation

Branchen: Industrie: IT, Medizintechnik, Maschinenbau

Institutionen: Banken, Krankenkassen, Versicherungen

Mitarbeiter: zwischen 25 und 30 (feste Mitarbeiter)


Technische Kommunikation

Produktlebenszyklus: informierende und instruierende Texte, z. B.LastenheftePflichtenhefteAnwenderdokumentation…dazu jeweils: Seminare und Coachings


Hintergrund: Wovon reden wir eigentlich?


Begriffsklärung

Auftraggeber

AuftragnehmerLastenheft

Pflichtenheft

Was?Wofür?

RequirementAnforderung

FeatureLösung

Was?Womit?


Funktion und Nutzen

Lastenheft Pflichtenheft

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

fachliche Spiegelung eines Entwicklungsvorhabens (Sicherheit zu realistisch erreichbaren Entwicklungsergebnissen)Know-how-Gewinn durch lösungsbezogene StrukturierungEinblick in Leistungsfähigkeit des AN

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

Plattform zum Nachweis von Kompetenz und Leistungsfähigkeit(Marketingfunktion)teilweise einzige Möglichkeit, um Entwicklungsvorhaben zu akquirieren (Ausschreibungen).Vorlage für weitere Entwicklungs-schritte (je besser das Pflichtenheft, desto leichter die Umsetzung)EinnahmequelleRechtssicherheit


Lastenheft & Pflichtenheft: Der Schlüssel zum Erfolg?


Verortung

Requirement-orientierte SoftwareentwicklungHierarchisches Entwicklungsmodell im Hintergrund

Lasten- und Pflichtenhefte:Integraler Bestandteil des EntwicklungsmodellsSteuer- und Kristallisationspunkte


Verortung

„Gegenentwurf“: agile Software-Entwicklungpermanente 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 ProzessenLasten- 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?


Planen Sie Ihr Dokument sorgfältig

Wichtig ist das Spiel ohne Ball


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


Wählen Sie ... zielgruppengerechte Inhalte... und eine stimmige Gliederung


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?


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)


Inhalte:Was gehört in ein Pflichtenheft?

ErweiterungenReformulierung 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


Hilfsmittel I: Mustergliederungen


Hilfsmittel II: Anforderungs-Typologien


Praxis-Tipps

Mustergliederungen sind eine gute Einstiegshilfe.

Im Detail sind individuelle Anpassungen gefragt.

Eine gute Gliederung „erzählt eine Geschichte“.

Beispiel


Verzichten Sie auf Entwickler-Prosa


Beispiel

Thema Display

Vorschlag !?


Formulierung: Welche Fehler werden deutlich?

Basiskriterien Textverständlichkeitzu viel Fließtext

unverständliche Sprache

Basiskriterien ZielgruppenorientierungStakeholder nicht berücksichtigt (z. B. Manager)

Potenziale der Leseransprache nicht genutzt

Besondere QualitätskriterienAnforderungen nicht prüfbar

Anforderungen nicht vollständig

Falsche Darstellungstyp für Inhalte gewählt


Textstruktur: Detailinformationen

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

ProblemInformationen „verschwinden“ in den Sätzen

Leser kann Informationen kaum entnehmen

Ersteller können vorhandene Texte nicht ergänzen.


Detailinformationen: Listen & Tabellen

Unterschied: Listen und Tabellen schaffen eine Detail-“freundliche“Umgebung

Nutzen: Informationen sindschnell zu finden (Scannen möglich)

schnell zu lesen

gut zu merken

leicht zu ergänzen


Hüten Sie sich vor ...


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 ...


Schreiben Sie so konkret wie möglich


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 von

Personen ohne Vorkenntnisse und ohne eine umfassende Schulung benutzt werden können.

Das geplante System soll intuitiv benutzbar sein. Das geplante System soll intuitiv benutzbar

sein.

Hintergrund: 80% der Nutzer verwenden das System lediglich 2 bis 3 mal pro Jahr.


Zielorientierte Anforderungen

BeispieleDas 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.


Szenarien


Lösungsorientierte Anforderungen


Herzlichen Dank für Ihr Interesse!

Haben Sie…Fragen?

Anregungen?

Diskussionswünsche?

Gerne auch nach der Veranstaltung:doctima GmbHMelli-Beese-Straße 19, 90768 FürthFon: +49 911 975670-0Fax: +49 9131 975670-188E-Mail: [email protected]: http://www.doctima.de

http://www.doctima.de/Technische-Kommunikation.4.0.html

Documents

Lasten- und Pflichtenhefte - nik-nbg.de · Lastenheft Pflichtenheft AG Zwang zur Konkretisierung bei Entwicklungsvorhaben (neue Erkenntnisse durch Versprachlichung von Ideen) Matrix