Lasten-/ Pflichtenheft erstellen

SY50

Level-1
Beiträge
271
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
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?
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@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
 
@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).
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
Dazu finde ich folgendes Dokument interessant
http://reqexperts.com/wp-content/uploads/2015/07/why_johnny_cant_write_good_requirements.pdf
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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 ;-)
 
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
 
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
 
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.
 
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.
 
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. ;)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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...
 
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?
 
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.
 
Zurück
Oben