Abschnitt 12.3 - 12.3 Pflichtenheft erstellen
Wer eine Software komplett neu erstellen oder eine vorhandene Software ändern lassen will, sollte auf der Grundlage des Lastenheftes mit dem Auftragnehmer/Lieferanten gemeinsam ein Pflichtenheft erstellen und vereinbaren. Das Pflichtenheft spezifiziert unter Berücksichtigung der betrieblichen Zielsetzungen die Inhalte des Lastenheftes, zu deren Umsetzung sich der Auftragnehmer verpflichtet.
Das Pflichtenheft sollte ein wesentlicher Vertragsbestandteil bei der Beauftragung zur Erstellung der Software sein. Es dient bei der Abnahme der Software zur Bewertung, ob die gestellten Anforderungen tatsächlich erfüllt bzw. welche Nacharbeiten notwendig sind. Die zentrale Bedeutung des Pflichtenheftes im Prozess der Beschaffung von Arbeitsmitteln wie Software verdeutlicht die Tabelle 5.
Tabelle 5 Prozessphasen und Aufgaben bei der Beschaffung von Individualsoftware
| Prozessphase | Aufgaben | Informationen über |
|---|---|---|
| Situation analysieren |
| Arbeitsaufgaben, Zusammenhänge von Arbeitsaufgaben, vor- und nachgelagerte Arbeitsaufgaben, bisherige Probleme der Aufgabenbearbeitung, bisherige Lösungswege usw. |
| Ziele und Lösungen spezifizieren |
| Funktionsteilung Mensch/Arbeitsmittel, Zuschneiden von Arbeitsaufgaben, Zusammenhänge von Arbeitsaufgaben, vor- und nachgelagerte Aufgaben, Flexibilität der Aufgabenbearbeitung, Qualifikationsanforderungen an Beschäftigte, Arbeitsergebnisse usw. |
| Ausschreibung vorbereiten |
| Bestandteile/Gliederung des Lastenheftes, Bedeutung von Anforderungen (Basis-, Detail-Anforderungen), Aufgaben als Anforderungen, ergonomische Gestaltung als Anforderungen, Bestimmung der Überprüfung und der Bewertungskriterien usw. |
| Angebote einholen |
| Anbieterinnen und Anbieter, Erfahrungen von bekannten Unternehmen, Kammern, Verbände, Unfallversicherungsträger, Referenzen usw. |
| Angebote prüfen und bewerten (Evaluation) |
| Bedeutung und Kategorisierung der Bewertung, Lastenheft, Pflichtenheft, Anforderungskatalog usw. |
| Vertrag abschließen |
| |
| Projektumsetzung planen und realisieren |
| Auswirkungen auf Tagesgeschäft, betroffene Arbeitsplätze, betroffene Beschäftigte usw. |
| Arbeitsmittel prüfen und bewerten |
| Bedeutung und Kategorisierung der Bewertung, Pflichtenheft, Anforderungskatalog, Prüfprotokoll usw. Grad der Zielerreichung anhand des Pflichtenheftes |
| Arbeitsmittel bereitstellen und abnehmen |
| Zuverlässigkeit und Zweckmäßigkeit des Arbeitsmittels, Pflichtenheft, Anforderungskatalog; Prüfprotokoll, Gewährleistung usw. |
| Beschäftigte informieren und schulen |
|
12.3.1 Struktur und Inhalte eines Pflichtenheftes
Der inhaltliche Aufbau eines Pflichtenheftes muss in seinen Bestandteilen den Zielen entsprechen, die mit dem Softwarekauf verfolgt werden (siehe Tabelle 6).
Da jeder Beschaffungsprozess andere Anforderungen an ein Arbeitsmittel stellt, gibt es nicht das allgemeingültige Standard-Pflichtenheft.
Tabelle 6 Gliederung eines Pflichtenheftes - Beispiel
| Inhalt | Informationen |
|---|---|
| Ausgangslage | bezogen auf das Unternehmen: Charakteristik des Unternehmens, Organisation, Struktur und Umfang des EDV-Einsatzes, Anstoß für die Beschaffung, Projektorganisation usw. |
| IST-Zustand | bezogen auf den Einsatzbereich des zukünftigen Arbeitsmittels: Aufbau der Organisation (Zuständigkeiten, Kompetenzen, Funktionen usw.), Arbeitsabläufe (Welche Aufgaben gehören zusammen oder folgen aufeinander?) und Arbeitsgegenstände, Aufteilung der Arbeitsaufgaben auf die Beschäftigten und auf die Arbeitsmittel, Qualifikation der Beschäftigten, Güte und Menge der Arbeitsmittel usw. |
| Ziele | Beschreibung der Ziele, die durch den Einsatz eines (geänderten/neuen) Arbeitsmittels erreicht werden sollen, jeweils bezogen auf das Beschaffungsprojekt insgesamt und bezogen auf die einzelnen Aufgaben, die im betroffenen Unternehmensbereich von den Beschäftigten bearbeitet werden; für Ziele können bereits Kriterien und Gewichtungen gesetzt werden (Muss-Kriterien, Kann-Kriterien) |
| Anforderungen | Dieser Teil des Pflichtenheftes ist der Wichtigste. Hier kann die Liste des Anhang 5 (Analyse der Aufgaben und Anforderungen) helfen. Eine präzise Beschreibung der Anforderungen, die durch die Software unterstützt werden sollen, ist notwendig (Aufgabenziele und Aufgabenteile). Die Anforderungen sind für beide Zielebenen (Beschaffungsprojekt und Einzelaufgaben im Unternehmensbereich) ausführlich zu dokumentieren. Zusätzliche Hinweise bzgl. Aufgabeninhalt, benötigter Eingaben und Ausgaben, Datenbasis, Schnittstellen und Barrierefreiheit sollten geliefert werden. Bereits hier müssen allgemeine Basis- und Detail-Anforderungen an eine ergonomische Gestaltung der Software formuliert werden. |
| Daten-Mengengerüst | Menge eingehender und weitergegebener Daten, Umfang des Datenbestandes, Menge anzuzeigender und einzugebender Daten und Abfragen usw.. Hier kann die Liste des Anhang 5 (Analyse der Aufgaben und Anforderungen) helfen. |
| Qualitäts- und Zielbestimmung | Festlegung von Qualitätsmerkmalen mit zugehörigen Qualitätsgraden der Software. Die Qualitätsmerkmale müssen messbar sein und die Form ihrer Überprüfung muss festgelegt werden. Qualitätsmerkmale und Prüfkriterien (bisher dokumentierte Anforderungen) sind detailliert und vollständig anzugeben und es ist auf allgemeine Richtlinien (Standards, Werksnormen, insbesondere Prüfprotokolle) zu verweisen. Ein Qualitätsgrad beschreibt den Erfüllungsgrad eines Qualitätsmerkmals (z. B. Bewertung 1...10). Die Überprüfung bildet die Grundlage zur Entscheidung, ob sich mit der Software die formulierten Ziele erreichen lassen. Hier kann die Liste des Anhang 5 (Analyse der Aufgaben und Anforderungen) helfen. |
| Test-Aufgaben | Zusammenstellung benutzerbezogener Testfälle, die sich auf umfangreiche Arbeiten mit der Software am Arbeitsplatz unter realen Arbeitsbedingungen mit realen Aufgaben beziehen. |
| Ergänzungen | Beschreibung von Ergänzungen oder speziellen Anforderungen und weiterer Leistungen (z. B. Datenschutz, Barrierefreiheit, Installation, Wartung, Garantie, bauliche und räumliche Voraussetzungen, Testdaten, Aushilfen, Normen, Lizenzen, Glossar, Dokumentationen zum Arbeitsmittel, Einführung und Schulung der Beschäftigten) Beschreibung von Anforderungen an anbietende Unternehmen/Entwicklerinnen bzw. Entwickler (z. B. generelle Anbietermerkmale, Referenzen, Projektorganisation, Unterstützung vor, während, nach Projektrealisierung, technischer Support, Leistungsabsicherung, Gewährleistung). |
| Angebots-Aufbau | Vorgaben zur Selbstdarstellung der Lieferanten, Stellungnahme zum Lastenheft (z. B. Nennung vernachlässigter Anforderungen) sowie zur detaillierten Projektumsetzung, zum Zeitplan, zu den Kosten, dem Supports und der Leistungsabsicherung. |
| Administratives | Vorgaben zur Vertraulichkeit, Informationen zur Bewertung des Angebotes und der Projektrealisierung, Rückfragen, Termine usw. |
| Anhang | Anlagen zum Pflichtenheft wie Vorgaben zur Qualitätsbestimmung, Prüfung und Bewertung der Software |
Die Softwareergonomie muss sich möglichst in allen Gliederungsabschnitten des Pflichtenheftes, wie auch bereits im Lastenheft, widerspiegeln. Eine ergonomische Gestaltung trägt dazu bei, dass die Beschäftigten an ihrem Arbeitsplatz die anstehenden Arbeitsaufgaben effektiv, effizient und zufriedenstellend bearbeiten können. Ein Software-Anbieter sollte auf diese Anforderungen eingehen, um eine qualitativ hochwertige Arbeit abzuliefern. Diese Anforderungen können als Aussagesatz (z. B. "Die Software muss Hilfefunktionen zur Verfügung stellen.") oder als Frage (z. B. "Stellt die Software Hilfefunktionen immer zur Verfügung?") formuliert werden, wobei die betroffene Arbeitsaufgabe genannt sein sollte.
Die Basis-Anforderungen aus den Kriterien zur Prüfung und Bewertung von Softwareergonomie sind wichtige Mindestkriterien der software-ergonomischen Gestaltung. Eine Software sollte diese Basis-Anforderungen erfüllen, um wesentliche Aspekte der ergonomischen Gestaltung zu berücksichtigen (siehe Kapitel 11 "Nutzungsqualität und Prüfung").
12.3.2 Prüfung und Bewertung von Software
Das Pflichtenheft dient als Bewertungs- und Entscheidungsgrundlage zur Prüfung und Bewertung. Das Projektteam der Beschaffung und das der Programmierung sollten sehr früh und mehrmals wiederholt überprüfen, welche der im Pflichtenheft dokumentierten Anforderungen an die Software bereits erfüllt sind. Dabei sollten die im Folgenden beschriebenen "Tipps zur Prüfung und Bewertung von Software" beachtet werden.
Die Abnahme der Software erfolgt erst dann, wenn Benutzerinnen und Benutzer und Projektteam die neue Software nach den Anforderungen des Pflichtenheftes bewertet haben. Das Ergebnis muss zeigen, dass alle dokumentierten Anforderungen an die Software erfüllt sind und die Software so eingesetzt werden kann, dass die anfangs formulierten Zielsetzungen effektiv, effizient und zufriedenstellend erfüllt werden.
Grundsätzlich gilt: Eine systematische und sorgfältige Herangehensweise bei der Beschaffung von Software trägt zu guten Arbeitsbedingungen bei und vermeidet mittel- und langfristig überflüssige Kosten.
 | Tipps zur Prüfung und Bewertung von Software |
|---|---|
| Bei jeder Prüfung muss jede einzelne Aufgabe mit der Software von den zukünftigen Benutzerinnen und Benutzern so weit wie möglich ausgeführt werden. Die Prüfung darf nicht nach der ersten Abweichung von einer Muss-Anforderung abgebrochen werden, da das Ziel einer Prüfung immer eine möglichst umfassende Dokumentation aller aktuellen Mängel einer Software-Version sein sollte. Bei der softwareergonomischen Prüfung sind unter anderem folgende Methoden üblich: lautes Denken der Benutzerinnen oder Benutzer, Videoaufzeichnung aus verschiedenen Blickwinkeln, Usability-Labs. Im Verlauf der Prüfung darf die Software nicht verändert werden. Erst nach dem Abschluss der vollständigen Prüfung darf auch "experimentiert" werden (z. B. Suche nach (Um-)Wegen, wie es vielleicht doch gehen könnte, Ausprobieren nach Veränderungen von Einstellungen). Das Ergebnis einer Prüfung ist ein Prüfprotokoll, in dem die Prüferinnen und Prüfer und weitere anwesende Personen die Prüfbedingungen, das Prüfverfahren und die entdeckten Mängel (z. B. Bug-Liste) dokumentieren müssen. Für die Prüfung kann folgende Liste verwendet werden:
| |