Pflichtenheft (Softwareentwicklung)

[trunks18]

Hallo Leute,

Wisst ihr was in son Heft rein kommt? :confused:

Wir sollen einen Parkautomaten programmieren und vorher ein sogenanntes Pflichtenheft erstellen. Kann mir jemand genau sagen was das ist und was rein kommt?

Danke und gruß


trunks

[noid]

in einem pflichtenheft steht was euer system alles kann.
da kommen rein:
- benutzerschnittstelle (zb oberflächen)
- allg schnittstellen nach außen (zb datenbankanbindungen, XML-files zur ablage
- beschreibung der funktion (zb use-cases + prozessschablonen)
- sicherheitskonzepte
- datensicherheitsdinger.
da kommt nicht rein:
- zu spezifische angaben, also keine details. die entwickler müssen das system gemäß diesem heft zum laufen bringen.

also eine klare beschreibung der funktion und interaktionen von/mit dem gerät.

edit: das hing mir gread noch im kopf, für genaueres müsste ich nochmal nachschauen was ich damals alles reingeballert hab. aber grob sollte das hinkommen. ich kann auch mal schauen ob ich dir ein muster zuschicken kann.

[Gast]

Wisst ihr was in son Heft rein kommt?Guckst du da:
http://wwwcs.upb.de/cs/ag-engels/ag_dt/Courses/Lehrveranstaltungen/WS0203/TSEI/Templates/Pflichtenheft-Template.pdf

Was steht denn im Lastenheft?

[mapel110]

*buddel*

Inhaltsverzeichnis

1. Einleitung
2. Zielbestimmung
Musskriterien
Wunschkriterien
Abgrenzungskriterien
3. Produkteinsatz
Anwendungsbereiche
Zielgruppe
Betriebsbedingungen
4. Produktfunktionen
Benutzeranmeldung
Suchkriterien eingeben
5. Produktdaten
6. Produktleistungen
Anmeldung
Akkumulation
Toleranz
7. Benutzeroberfläche
8. Qualitäts-Zielbestimmungen
Funktionalität
Bedienbarkeit
Änderbarkeit
9. Testszenarien
10. Nicht funktionale Forderungen, einzuhaltende Gesetze und Normen
11. Technische Produktumgebung
12. Anforderungen an die Entwicklungsumgebung
Hardware
Software
Orgware
Entwicklungsschnittstellen
13. Ergänzungen
14. Glossar

Ich schreib jetzt ja zum ersten Mal ein Pflichtenheft zu einem Projekt, was produktiv eingesetzt werden soll. Und naja, dann soll das auch was ordentliches werden.

Fehlt was wichtiges in der Gliederung?
Ist das zu aufgebläht?
Würdet ihr an der Struktur was ändern?
Habt ihr noch gute Links zu dem Thema? (Wikipedia und die ersten Google-Hits hab ich abgegrast)
Eigene Tipps sind natürlich auch willkommen. :)

[AtTheDriveIn]

http://www.indesign-berlin.de/Pflichtenheft.pdf

[mapel110]

http://www.indesign-berlin.de/Pflichtenheft.pdf
Genau das hab ich unter anderem als Vorlage genutzt. :D
Also ist das quasi schon okay so?!

Der Umfang eines Pflichtenhefts richtet sich wohl nur bedingt nach dem Projekt, sondern eher nach eigenen Wünschen, wie "dick" man es denn haben möchte?!

[AtTheDriveIn]

Genau das hab ich unter anderem als Vorlage genutzt. :D
Also ist das quasi schon okay so?!



Also das letzte Pflichtenhefte was ich fürs Studium schreiben musste sah vom Aufbau sehr ähnlich aus. Projekt gab eine 1.0, also scheint es nicht falsch gewesen zu sein. ;)

Hier ein weiteres Beispiel was wir im Rahmen der Vorlesung genutzt haben:
http://www.inf.fu-berlin.de/inst/ag-se/teaching/V-SWT-2003/12_LE_4_SemOrgPflichtenheft.pdf

[Monger]

Vielleicht sollte man erstmal klären, wozu ein Pflichtenheft überhaupt gut ist...

Ein Pflichtenheft dient dazu, dich daran zu erinnern was ursprünglich eigentlich dein Ziel war.
In aller Regel hast du einen Kunden den du glücklich machen willst (in deinem Fall der fingierte Parkautomat-Besitzer), und das Pflichtenheft ist die destillierte Form aus dem, was du glaubst was der Kunde wirklich braucht.

Erfahrungsgemäß sind Pflichtenhefte immer unheimlich detailliert, nur nicht an den Stellen wo es wichtig wäre. :ugly:

Wichtig ist, dass die Punkte angesprochen werden, die besonders kritisch für den Ausgang des Projektes sind. Wenn z.B. deinem Kunden Ausfallsicherheit ganz besonders wichtig ist, muss das schon ganz früh in die Architektur einfließen - und dann ist es unheimlich nützlich, wenn man den Entwicklern regelmäßig die passende Passage im Pflichtenheft um die Ohren hauen kann.

[mapel110]

Hier ein weiteres Beispiel was wir im Rahmen der Vorlesung genutzt haben:
http://www.inf.fu-berlin.de/inst/ag-se/teaching/V-SWT-2003/12_LE_4_SemOrgPflichtenheft.pdf
thx, sieht sehr schick aus. :)
- und dann ist es unheimlich nützlich, wenn man den Entwicklern regelmäßig die passende Passage im Pflichtenheft um die Ohren hauen kann.
hehe, ich hatte ja auch erst den Rohentwurf vom Pflichtenheft geschrieben, dann codiert und codiert und codiert und eh... ja, dann mal wieder einen Blick in den Rohentwuf getan und wieder bisschen was aus dem Code gelöscht und ausgebessert. ^^
Hab mir schon gedacht, dass ein Blick in die eigentliche Aufgabe zwischendurch nicht schaden kann.

/edit
Konkrete Frage: Thema Schnittstellen
Welche Schnittstellen sind denn zu nennen? TCP/IP wird natürlich verwendet zwischen SQL-Server und dem Client. Aber sonst?!
Gibts da was erwähnenswertes zwischen PHP4, MS-SQL-Server 2005 und IE, was im Pflichtenheft stehen sollte?

Ich kann zwar mit dem Begriff Schnittstelle durchaus was anfangen, aber nicht im Zusammenhang mit PHP und SQL.

[Monger]

/edit
Konkrete Frage: Thema Schnittstellen
Welche Schnittstellen sind denn zu nennen?

"Schnittstelle" muss man hier ganz abstrakt verstehen. Eine Schnittstelle ist im Endeffekt alles, worüber Kommunikation mit irgendwas anderem läuft - auch im Programm selbst.

Aber die Schnittstellen die mindestens mal irgendwo im Pflichtenheft erwähnt werden sollten, sind:

- Benutzerschnittstelle (sprich: wie sieht die Oberfläche aus? Keyboard Shortcuts? Welche Buttons gibt es, und wozu sind sie gut?)
- Schnittstelle zum Betriebssystem/andere Anwendungen (Copy&Paste in andere Anwendungen? Welche Dateiformate? Drucken? Irgendeine Form von Export/Import? Einfluss von Benutzerrechten?)

Wenn man beides konsequent macht, hat man schon eine ziemlich gute Vorstellung davon, was genau das Programm eigentlich tun soll, und daraus kann man dann Rückschlüsse auf die Architektur ziehen.
In aller Regel schmeißt man dann die grafische Oberfläche im laufenden Prozess noch mindestens dreimal um :D , aber wenigstens hatte man irgendwann mal ne Vorstellung davon, was der Benutzer eigentlich alles tun können soll.

[mapel110]

"Schnittstelle" muss man hier ganz abstrakt verstehen. Eine Schnittstelle ist im Endeffekt alles, worüber Kommunikation mit irgendwas anderem läuft - auch im Programm selbst.

Aber die Schnittstellen die mindestens mal irgendwo im Pflichtenheft erwähnt werden sollten, sind:

- Benutzerschnittstelle (sprich: wie sieht die Oberfläche aus? Keyboard Shortcuts? Welche Buttons gibt es, und wozu sind sie gut?)
- Schnittstelle zum Betriebssystem/andere Anwendungen (Copy&Paste in andere Anwendungen? Welche Dateiformate? Drucken? Irgendeine Form von Export/Import? Einfluss von Benutzerrechten?)

Wenn man beides konsequent macht, hat man schon eine ziemlich gute Vorstellung davon, was genau das Programm eigentlich tun soll, und daraus kann man dann Rückschlüsse auf die Architektur ziehen.
Die Punkte, die du aufzählst, hab ich zum größten Teil drin, denk ich mal, allerdings eben unter anderen Unterpunkten. Mir gehts konkret hierum:
Unterpunkt 12:

12. Anforderungen an die Entwicklungsumgebung
Hardware
Software
Orgware
Entwicklungsschnittstellen

Da wollt ich jetzt nur die technischen Schnittstellen nennen. Eben TCP/IP hab ich dort.
Aber zwischen PHP und SQL selbst gibts ja auch noch irgendwas. Entweder ODBC (das verwende ich schon mal nicht, das weiß ich) oder eben was anderes. Wie bekomme ich die Schnittstelle raus, die ich da verwende? Ist wohl irgendeine "Library" oder so, die in PHP eingebunden ist?

/edit
Ich liebe solche Antworten :ugly:
http://forum.de.selfhtml.org/my/?t=169287&m=1105446

[Monger]

Vielleicht bin ich da auch völlig auf dem Holzweg, aber unter "Entwicklerschnittstelle" verstehe ich eher die Projektstruktur, also wie die Entwicklerteams aufgebaut sind, und wo deren Berührungspunkte sind. Das ist ein gigantisches Feld, und eine Wissenschaft für sich.

Und was die Schnittstelle zwischen PHP und SQL angeht: nenn einfach das Paket bzw. die Klasse in PHP, die du zum ansprechen verwendest. Wobei ausgerechnet das in meinen Augen bereits Implementierungsdetails sind - es sei denn, du willst dir die Möglichkeit offen halten, dich an eben diese Kommunikation mit einem weiteren Client dranzuhängen.

[mapel110]

ehm, ich hab in der Gliederung wohl einen Fehler bzw. ich weiß gar nicht mehr, woher ich diesen Unterpunkt habe.

Ich glaub, ich baue das besser um. Die Info passt auch woanders besser hin, denke ich.

Danke soweit!

/edit
Ich hab hier eine phpinfo() Datei. Darin steht nur in einer der Tabellen "MSSQL Support enabled" und darunter u.a. "Library Version 7"
PHP-Version 4.4.7 ist das übrigens und IIS 5 iirc.

Wie kann man dann die Schnittstelle nennen? In meinen PHP-Dateien wird diese doch gar nicht genannt?! Da hab ich ja nur meine Connect-Anweisungen usw. Da steht nix von Protokoll.

[RMC]

Ein Pflichtenheft dient dazu, dich daran zu erinnern was ursprünglich eigentlich dein Ziel war.
In aller Regel hast du einen Kunden den du glücklich machen willst (in deinem Fall der fingierte Parkautomat-Besitzer), und das Pflichtenheft ist die destillierte Form aus dem, was du glaubst was der Kunde wirklich braucht.


Das Wichtigste wurde imho vergessen:

Ein Pflichtenheft ist eine rechtliche Absicherung (auf beiden Seiten). Es ist für die Abnahme genau vermerkt, was das Programm kann und für welche Systeme getestet wird.

Der Kunde kann also nicht herkommen und einfach behaupten "Es war für die Abnahme dieses und jenes Feature vereinbart...".

Dann kannst du sagen "Gerne, aber das kostet dann xy € zusätzlich, weil es im Pflichtenheft nicht vermerkt ist" ;)

Deswegen wird dieses Dokument auch vom Kunden durchgesehen und abgenommen, bevor das Projekt losgeht. So gibt es keine (naja..weniger) Probleme.

[Gnafoo]

War es nicht so, dass dafür das Lastenheft zuständig ist, welches das Produkt aus Kundensicht spezifiziert, während das Pflichtenheft genauer ist und zusätzlich die ganzen Entwicklungsdetails beinhaltet, welche den Kunden wiederrum nicht interessieren? (Achtung ich habe nur theoretisches Klausurwissen ;D.)

[AtTheDriveIn]

War es nicht so, dass dafür das Lastenheft zuständig ist, welches das Produkt aus Kundensicht spezifiziert, während das Pflichtenheft genauer ist und zusätzlich die ganzen Entwicklungsdetails beinhaltet, welche den Kunden wiederrum nicht interessieren? (Achtung ich habe nur theoretisches Klausurwissen ;D.)

Im Lastenheft notiert der Kunde erstmal seine Wünsche, das Pflichtenheft ist aber Vertragsgegenstand.

[Gnafoo]

Ah okay dankeschön. Dann ist das in der Tat ein wichtiger Punkt.