# Lasten-/ Pflichtenheft erstellen



## SY50 (29 August 2017)

Hallo,
Hat jemand Erfahrung, wie man am besten ein Pflichtenheft für eine Softwaredienstleistung erzeugt?
Habe im Netz etwas von V-Model XT gelesen.
Gibt es hier im Idealfall Experten?


----------



## hapr (30 August 2017)

Wenn Du die Anforderungen kennst, dann kannst Du ein Pflichtenheft erstellen. Die Anforderungen sollten eigentlich im Lastenheft definiert sein, das meistens nicht existiert. Das Lastenheft definiert, was zu tun ist, das Pflichtenheft, wie es realisiert wird. Und das bedeutet dann, dass für das Pflichtenheft der größte Teil der Arbeit (Definitionsphase) schon gemacht werden muss.

So bleibt es meistens beim Pflichtenheft mit folgendem Inhalt:
Auflistung der Anforderungen (Funktion, Leistung, Ausschlüsse, Randbedingungen...)
Spezifikation (Funktionsmodule, Zusammenwirken)
Design (Blockschaltbild, Architektur, Systemaufbau, Datenverarbeitung, Moduldesign)
Beschreibung (Funktionsmodule, Funktionen, eventuell Testanforderungen für Testplan)

So etwa im Groben.
Viel Spaß, Harald.


----------



## Larry Laffer (30 August 2017)

@Harald:
*ACK*

Das kann man auch sehr schön machen, wenn es das, um das es geht schon einmal gibt (ich halte das hier mal bewußt allgemein).
Ist es aber etwas Neues so kann daraus auch schnell ein Boomerang entstehen - soll heißen : man sollte sich schon gut und genau überlegen, was man so schreibt. Die kleinen Nickerigkeiten, die man selber gar nicht wahrnimmt, sehen die Anderen sofort ...

Gruß
Larry


----------



## marlob (30 August 2017)

Larry Laffer schrieb:


> @Harald:
> 
> 
> Das kann man auch sehr schön machen, wenn es das, um das es geht schon einmal gibt (ich halte das hier mal bewußt allgemein).
> ...


Dazu finde ich folgendes Dokument interessant
http://reqexperts.com/wp-content/uploads/2015/07/why_johnny_cant_write_good_requirements.pdf


----------



## Blockmove (30 August 2017)

Mir hat mal ein Programmierer eines unserer Lieferanten gesagt:
"Manche kann am meisten bestrafen indem man genau liefert was sie bestellen."

Gruß
Blockmove


----------



## hapr (30 August 2017)

> Das kann man auch sehr schön machen, wenn es das, um das es geht schon einmal gibt (ich halte das hier mal bewußt allgemein).
> Ist es aber etwas Neues so kann daraus auch schnell ein Boomerang entstehen - soll heißen : man sollte sich schon gut und genau überlegen, was man so schreibt. Die kleinen Nickerigkeiten, die man selber gar nicht wahrnimmt, sehen die Anderen sofort ...


Tja Ralf, da kommt dann Theorie und Praxis, meistens Marx und Murcks.
Die einen können oder wollen nicht beschreiben, um was es geht. Wegen Unwissenheit wird etwas falsch interpretiert, und dann will man sich das Korrekturlesen der entgegengebrachten Dokumente sparen. Damit beginnt dann der Spaß...
Ich habe es erlebt, dass wir nach zwei Jahren verstanden haben, wie der Kunde tickt und wie er es gemeint hat.
LG, Harald.


----------



## hapr (30 August 2017)

Noch so eine Phrase:
Sinnvoll ist es die technische Dokumentation (Betriebsanleitung, Montageanweisung, Servicehandbuch, Anwendungshandbuch...) als erstes zu erstellen, damit die Anforderungen möglichst umfassend und besser verständlich erstellt werden können.
Macht natürlich keiner, funktioniert bei uns auch nicht ;-)


----------



## Larry Laffer (30 August 2017)

Naja ... das könnte man dann auch "Lieferanten-Entwicklung" nennen ... das trifft es m.E. am Besten. Man "schiesst" sich aufeinander ein und so weiß man dann "irgendwann" ziemlich genau, was der Kunde eigentlich haben will und wie er es haben will. Aber so etwas funktioniert dann auch eher über Zeit und ein vernünftiges Miteinander als über Aufgeschriebenes. 
Sehr gut festlegen kann man solche Dinge wie Farben und Dimensionen ... bei Funktionen wird das schon sehr viel problematischer. Ich würde es als Kunde immer MIT dem Lieferanten zusammen entwickeln (Stichwort "mitnehmen") - das beugt vielfach Mißverständnissen vor ...

Gruß
Larry


----------



## SY50 (30 August 2017)

Danke für die Reaktionen, aber hat jemand Erfahrungen mit Programmen. Wie beistpielsweise das erwähnte V-Modell XT?


----------



## Larry Laffer (30 August 2017)

Bevor du den Begriff hier erwähnt hast kannte ich den gar nicht.
Wie meinst du denn, dass dir das für ein Lasten-/Pflichtenheft mehr hilft als das schon genannte ...?

Gruß
Larry


----------



## dingo (31 August 2017)

Ist schon ein paar Tage her, wo ich mal mit V-Modell XT mit der Bundeswehr zu tun hatte.
Entwicklungen nach V- Modell haben genauso Vor- & Nachteile, wie andere Methoden (Wasserfall, Top/Down, Scrum usw.)

-Meist werden ohne hin Mischformen dieser klangvollen Entwicklungsmodelle genutzt...

Die Software V- XT soll alle Beteiligten ansprechen, ist für Komplexe Entwicklungen mit mehreren Ebenen sehr gut geeignet( z.B. Raketenbasis mit Radarstation- als Gesamtprojekt.)

Leider setzen solche Tools zur effektiven Benutzung an alle Beteiligten eine Fachkompetenz auf gleichwertigen Niveau vorraus.

Wenn ein Kunde diese Tools Richtig benutzen kann, ist dieser meist selbst in der Lage die Software für eine Anwendung zu entwickeln.


----------



## SY50 (1 September 2017)

Also wäre es auch vollkommen ok, wenn ich In Word einfach diverse Beschreibungen mache und dann ein Visio flußdiagramm einfüge? Reicht das?


----------



## hapr (2 September 2017)

So mache ich es auch. Statt Visio nehme ich DigrammDesigner. Für Flussdiagramme geht auch yEd. Excel hilft mir bei Tabellen und Verwaltungen weiter. Bei einigen Abläufen erstelle ich Struktogramme statt Flussdiagramme. Dann hilft mir ein StruktogrammEditor.

Ob das reicht? Hängt vom Auftraggeber oder der Zertifizierungsstelle ab, wie detailreich es sein soll.


----------



## Tommi (2 September 2017)

Hallo zusammen,

V-Modell heißt aus meiner Sicht, daß man ein Projekt oder auch eine Software
von grob nach fein plant (V-Schenkel links abwärts) und nach dem Umsetzen von
fein nach grob prüft (V-Schenkel rechts aufwärts).
Eigentlich nichts anderes, als strukturiert zu arbeiten. Und das macht ja denn
doch auch Sinn.


----------



## hapr (2 September 2017)

Wobei es da nicht nur eine Richtung gibt. Bei Bedarf muss man links ein oder mehrere Blöcke höher, um die neuen Aspekte zu berücksichtigen. Und das wird dann in der Dokumentation interessant...


----------



## Tommi (3 September 2017)

Hallo Harald,

genau, auch bei der Verwendung des V-Modells gibt es mal neue Aspekte oder
man vergisst einfach was.
Wie meinst Du das mit der Dokumentation?


----------



## hapr (3 September 2017)

Hallo Tommi,
es sind die Aspekte Modifikation und Modifikationsverfahren:
Anforderungen zur Modifikation
Welche Funktionsmodule werden geändert
Welche Funktionsmodule sind betroffen (FMEA)
Welche Funktionsmodule müssen neu verifiziert werden
Welche Aspekte müssen bei der Validierung berücksichtigt werden
Freigabe der Modifikation
Ergebnis der Neuverifikation
Ergebnis der Neuvalidierung
Ergebnisbericht der Modifikationsdurchführung

Das ist, was ich jetzt so aus dem Kopf heraus zusammenkriege.
LG, Harald.


----------



## Tommi (3 September 2017)

Hallo Harald,

hört sich gewaltig an, da haben wir schon ein Thema am 13.10.


----------

