Vorgehensweise bei der Erstellung von Pflichtenheften
Werbung
Team-HDvO www.hdvo.de Das Pflichtenheft Version 0.93 Vorgehensweisen zur Erstellung von Programmiervorgaben zur Entwicklung von Individualsoftware Diese Ausarbeitung ist noch nicht vollständig! Bitte beachten Sie den Hinweis in den noch unvollständigen Kapiteln. (Diese Kapitel sind auch noch nicht ON-LINE verfügbar!) Für Hinweise auf Tipp- oder Formulierungsfehler wären wir dankbar. erstellt von: erreichbar unter: Stand: Bernd Hilgenberg [email protected] 14.05.2016 © 1999-2001 Bernd Hilgenberg - Team-HDvO- Alle Rechte vorbehalten Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Inhaltsverzeichnis Copyright __________________________________________________________________ 4 1 Allgemeines zum Thema Pflichtenheft _______________________________________ 5 1.1 1.2 1.3 1.4 1.5 Zielsetzung _________________________________________________________________________ Begriffsdefinition _____________________________________________________________________ Inhalt eines Pflichtenheftes ____________________________________________________________ Grundstruktur eines Pflichtenheftes ______________________________________________________ Zielgruppenorientierte Beschreibung _____________________________________________________ 5 5 6 6 8 2 Zur Organisation eines Pflichtenheftes ______________________________________ 11 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 Deckblatt__________________________________________________________________________ Inhaltsverzeichnis ___________________________________________________________________ Sitzungen zu diesem Thema __________________________________________________________ Offene Punkte______________________________________________________________________ Glossar ___________________________________________________________________________ Ausgangssituation __________________________________________________________________ Aufgabenstellung und Zielsetzung ______________________________________________________ Auflistung betroffener Bereiche ________________________________________________________ 11 11 12 12 14 15 15 16 3 Fachliche Inhalte beschreiben _____________________________________________ 18 3.1 Objekte identifizieren ________________________________________________________________ 3.2 Menüs ____________________________________________________________________________ 3.3 Dialoge ___________________________________________________________________________ 3.3.1 Dialoge beschreiben __________________________________________________________ 3.3.2 Feldbeschreibungen __________________________________________________________ 3.3.3 Funktionstasten und Buttons ____________________________________________________ 3.3.4 Rechte Maustaste ____________________________________________________________ 3.3.5 Controls und sonstige Dialogelemente ____________________________________________ 3.3.6 Möglichkeiten der Detaillierung __________________________________________________ 3.3.7 Beispiel ____________________________________________________________________ 3.4 Vorgänge _________________________________________________________________________ 3.4.1 Textuelle Beschreibung von Vorgängen ___________________________________________ 3.4.2 Die grafische Darstellung von Vorgängen __________________________________________ 3.4.3 Beschriftung der Elemente _____________________________________________________ 3.4.4 Die maximale Anzahl von Elementen festlegen _____________________________________ 3.4.5 Komplexe Vorgänge darstellen __________________________________________________ 3.5 Ereignisse _________________________________________________________________________ 3.6 Ausgabeobjekte ____________________________________________________________________ 3.6.1 Verschiedene Bereiche in Ausgabeobjekten _______________________________________ 3.6.2 Verschiedene Arten von Feldern in Ausgabeobjekten ________________________________ 3.6.3 Die Darstellung von Feldern ____________________________________________________ 3.6.4 Sortierungen innerhalb von Ausgabeobjekten ______________________________________ 3.6.5 Listen ______________________________________________________________________ 3.6.6 Kopfinformationen von Listen ___________________________________________________ 3.6.7 Beispiel für die Beschreibung einer Liste __________________________________________ 3.6.8 Belege _____________________________________________________________________ 3.6.9 Beispiel für einen Beleg ________________________________________________________ 3.6.10 Etiketten____________________________________________________________________ 3.6.11 Beispiel für die Beschreibung eines Etiketts ________________________________________ 3.7 Dateien ___________________________________________________________________________ Stand: 14.05.2016 Version 0.93 18 22 24 24 27 28 29 30 31 33 35 36 38 40 42 43 45 49 51 51 52 54 55 57 59 61 62 64 66 67 Seite -2- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 4 Möglichkeiten der Visualisierung von Abläufen _______________________________ 70 4.1 4.2 4.3 4.4 4.5 Brainstorming-Ergebnisse darstellen ____________________________________________________ Kommunikationsbeziehungen darstellen _________________________________________________ Zeitliche Abläufe von Kommunikationen darstellen _________________________________________ Beleg- und Warenfluss darstellen ______________________________________________________ Aktivitäten und Abhängigkeiten darstellen ________________________________________________ 72 73 74 75 76 5 Besprechungen organisieren ______________________________________________ 77 5.1 Die Agenda ________________________________________________________________________ 5.1.1 Inhalt einer Agenda erarbeiten __________________________________________________ 5.1.2 Aufbau einer Agenda __________________________________________________________ 5.1.3 Beispiel für eine Agenda _______________________________________________________ 5.2 Das Protokoll ______________________________________________________________________ 5.2.1 Effiziente Protokollierung _______________________________________________________ 5.2.2 Schlechte Protokollierung erkennen ______________________________________________ 5.2.3 Inhalt eines Protokolls erarbeiten ________________________________________________ 5.2.4 Protokollvorlagen nutzen _______________________________________________________ 5.2.5 Aufbau eines Ergebnis-Protokolls ________________________________________________ 5.2.6 Struktur des Inhaltes __________________________________________________________ 5.2.7 Beispiel für ein Ergebnis-Protokoll _______________________________________________ 77 79 82 84 85 86 87 88 89 90 91 93 6 Projektablauf der Pflichtenhefterstellung ____________________________________ 95 6.1 Der Auftrag zur Erstellung eines Pflichtenheftes ___________________________________________ 96 6.1.1 Die Struktur des Auftrages _____________________________________________________ 98 6.1.2 Beispiel für einen Auftrag _____________________________________________________ 104 6.2 Die Kick-Off-Veranstaltung ___________________________________________________________ 105 6.3 Erste Sitzung mit der Fachabteilung ___________________________________________________ 105 6.4 Erste Arbeitsunterlage ______________________________________________________________ 105 6.5 Das Pflichtenheft erarbeiten __________________________________________________________ 105 6.6 Die Präsentation des Pflichtenheftes ___________________________________________________ 105 6.7 Die Abnahme des Pflichtenheftes _____________________________________________________ 106 6.7.1 Beispiel für eine Abnahme ____________________________________________________ 107 7 Technische Anmerkungen _______________________________________________ 108 7.1 7.2 7.3 7.4 7.5 7.6 Visualisierung von offenen Fragen usw. ________________________________________________ Änderungen im Pflichtenheft _________________________________________________________ Welches Seitenlayout soll gewählt werden? _____________________________________________ Was gehört in die Kopf- und Fußzeile? _________________________________________________ Welche Tools sollen genutzt werden? __________________________________________________ Der Umgang mit vertraulichen Informationen ____________________________________________ Stand: 14.05.2016 Version 0.93 108 109 109 110 112 113 Seite -3- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Copyright Die in dieser Ausarbeitung enthaltenen Angaben können ohne vorherige Ankündigung geändert werden. Die in den Beispielen gemachten Angaben sind frei erfunden, soweit nicht anders vermerkt. Ohne schriftliche Genehmigung des Team-HDvO darf kein Teil dieser Ausarbeitung vervielfältigt oder publiziert werden. © Bernd Hilgenberg – Team-HDvO http://www.hdvo.de Alle Rechte vorbehalten Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in dieser Ausarbeitung berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Für die vorliegende Ausarbeitung wird keine Gewähr übernommen. Insbesondere nicht für aus deren Gebrauch resultierende Folgeschäden. Werbung SPIRALGUARD ist als Spiral-Schlauch ein neues hochfestes Schutzelement besonders für Hydraulik-/Pneumatikschläuche. Dieser Schlauchschutz, in Australien für den Bergbau-Einsatz entwickelt, ist aus HDPE und ist außerordentlich beständig gegen Schlag, Quetschung und Verschleiß bei guter Elastizität. http://www.spiralguard.de/ Stand: 14.05.2016 Version 0.93 Seite -4- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 1 Allgemeines zum Thema Pflichtenheft 1.1 Zielsetzung In diese Ausarbeitung über die Erstellung von Pflichtenheften sind unsere Erfahrung bei der Arbeit mit Pflichtenheften und Konzepten eingeflossen. Daher basieren alle Vorschläge nicht auf dem Studium von einschlägiger Fachliteratur und deren Zusammenfassung. Die vorliegende Ausarbeitung ist vielmehr aus der Praxis heraus entstanden. Alle Strukturen, Vorgehensweisen, Formulare usw. haben sich im praktischen Einsatz bewährt und sind von uns in verschiedenen Projekten erfolgreich eingesetzt worden. Wir möchten dies als Informationsaustausch von Praktiker zu Praktiker verstehen. Aus diesem Grunde haben wir versucht, alle Informationen leicht umsetzbar aufzubereiten. Wenn möglich, liefern wir entsprechende Vorlagen, die Sie für Ihre Arbeit anpassen und direkt einsetzen können. Innerhalb der Ausführungen kann es hin und wieder zu doppelten Beschreibungen einzelner Bereiche kommen. Dies ist beabsichtigt und soll ein Hin- und her zwischen verschiedenen Verweisen und Definitionen verhindern. Da wir nicht unmittelbar miteinander in Kommunikation treten können, haben wir versucht, einige Fragen vorweg zu nehmen. Hierfür sind zu den meisten Punkten die nachfolgenden Fragen gestellt und hoffentlich auch für Sie ausführlich genug beantwortet worden: Worum geht es? Was bringt es? Wie wird es gemacht? Sollten Sie Fragen oder Ergänzungen zu den vorliegenden Informationen haben, sprechen Sie uns einfach an. Dies gilt auch dann, wenn Ihnen eine vordefinierte Vorlage fehlt. Die technische Umsetzung aller von uns beschriebenen Verfahren bezieht sich auf WinWord97. Die gesamte Ausarbeitung liegt auch als WinWord97-Datei in unserem Downloadbereich für Sie bereit! 1.2 Begriffsdefinition Worum geht es? Das Verständnis über Aufbau und Inhalt eines Pflichtenheftes orientiert sich daran, vor welchem Hintergrund ein Pflichtenheft betrachtet wird. Für diese Art von Ausarbeitung gibt es verschiedenste Definitionen. Dies liegt daran, dass der Begriff Pflichtenheft mehrfach belegt ist. So wird ein Pflichtenheft nicht nur zur Erstellung von Software geschrieben. Auch in anderen Bereichen wie z. B. im Maschinenbau und der Fertigung gibt es die Form des Pflichtenheftes als Vorgabe für bestimmte Arbeiten. Unsere nachfolgenden Betrachtungen zum Thema Pflichtenheft orientieren sich an der von uns formulierten Definition: Ein Pflichtenheft ist die organisatorische und/oder technische Vorgabe zur Erstellung von Software. Stand: 14.05.2016 Version 0.93 Seite -5- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Was bringt es? Mit Hilfe dieser eindeutigen Definition möchten wir das Umfeld dessen, was wir zu diesem Thema zu berichten haben, eindeutig abgrenzen. Es hilft auch Ihnen - dem Leser - die von uns gemachten Vorschläge vor dem richtigen Hintergrund einzuordnen. 1.3 Inhalt eines Pflichtenheftes Worum geht es? Bevor ein Pflichtenheft geschrieben wird, muss festgelegt werden, welche Informationen Gegenstand des Pflichtenheftes sein sollen. Gemäß unserer Definition ist der zukünftige Sollzustand ein wesentlicher Bestandteil des Pflichtenheftes. Der Ist-Zustand soll nur dann in das Pflichtenheft mit aufgenommen werden, wenn er zur Verdeutlichung des zukünftigen Sollzustandes beiträgt. Was bringt es? Das Pflichtenheft ist ein Dokument, mit dem die Realisierung von Software vorgenommen wird. Vorgelagert vor dem Pflichtenheft sind Vorstudien und Analysen. Um zu verhindern, daß ein Pflichtenheft ein Mischmasch aus Vorstudie, Analyse und Sollkonzept wird, ist es von großer Wichtigkeit, diese Abgrenzung vorzunehmen. Das Pflichtenheft ist die Basis für eine technische Realisierung. Aus diesem Grunde sollten bei der Verfassung folgende Fragen gestellt werden: Hilft diese Information dem Kunden das Pflichtenheft besser zu verstehen? Ist diese Information für den Entwickler hilfreich? Vom Grundsatz her sind diese Fragen in jeder Phase der Pflichtenhefterstellung zu stellen. Jedoch ist die Gefahr unterschiedliche Informationsinhalte zu vermischen, geringer, wenn das Pflichtenheft vor dem Hintergrund dieser Fragen erarbeitet wird. Alle vorgelagerten Analysearbeiten sollten nicht Gegenstand eines Pflichtenheftes werden. 1.4 Grundstruktur eines Pflichtenheftes Worum geht es? Zur Vereinheitlichung und besseren Organisation der Dokumentationen sollten alle Pflichtenhefte den gleichen Aufbau besitzen. Folgender Aufbau hat sich in unserer Arbeit bewährt: Deckblatt Inhaltsverzeichnis Sitzungen zu diesem Thema Offene Punkte Glossar Ausgangssituation Zielsetzung Anforderungen Dieser Gliederungsvorschlag kann noch erweitert werden. So ist es bei verschiedenen Unternehmen üblich, den Projektplan als Teil des Pflichtenheftes zu verstehen. Dies gilt in Stand: 14.05.2016 Version 0.93 Seite -6- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc manchen Fällen auch für das Datenmodell. Sollten Sie Vorschläge für Erweiterungen haben oder die Notwendigkeit sehen, zusätzliche Punkte mit aufzunehmen - schreiben Sie uns! Was bringt es? Sollten im Laufe der Zeit verschiedene Pflichtenhefte erstellt werden, hilft eine einheitliche Struktur der Pflichtenhefte in verschiedenen Situationen weiter. Der Kunde erkennt beim zweiten Projekt die Struktur des ersten Pflichtenheftes wieder und findet sich im Dokument schneller zurecht. Der Autor des Pflichtenheftes hat die Möglichkeit, bei neuen Projekten schnell auf Informationen alter Projekte zurückzugreifen. Hierdurch kann bei ähnlichen Problemstellungen der Arbeitsaufwand zur Erarbeitung von Lösungen vielfach stark vermindert werden. Die Einarbeitung neuer Mitarbeiter fällt sowohl auf Kunden- als auch auf Beraterseite wesentlich leichter. Bei umfangreichen Projekten wie z. B. einem Warenwirtschaftssystem werden für viele Teilprojekte Pflichtenhefte geschrieben. Jeder, der sich neu mit einem Thema beschäftigt, kann sich mit Hilfe eines einheitlichen Aufbaus der Unterlagen schnell das nötige Wissen erarbeiten. Daher sollte bei der Erstellung von Pflichtenheften folgender Leitsatz gelten Vereinfachung durch Vereinheitlichung! Werbung Der beste Datenbankbrowser für die AS/400! http://www.online-club.de/m3/Thomas.Raddatz/pk400dnl.html Stand: 14.05.2016 Version 0.93 Seite -7- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 1.5 Zielgruppenorientierte Beschreibung Worum geht es? Wir sehen die Erstellung von Pflichtenheften als eine Dienstleistung an. Mit dieser Dienstleistung sollen Informationen übermittelt bzw. verkauft werden. Der Kunde hat daher Anspruch darauf, dass die zu übermittelnden Informationen für ihn so leicht wie möglich konsumierbar sind. Neben einer gut strukturierten textlichen Aufbereitung der Informationen zeichnet sich ein gutes Pflichtenheft auch durch eine gute Visualisierung der beschriebenen Vorgänge aus. Zudem sollte eine Sprache gewählt werden, die der Zielgruppe gerecht wird (kein EDV-Chinesisch usw.). In diesem Zusammenhang sei darauf hingewiesen, dass weniger meistens mehr ist. Kunden lassen sich zwar von der Dicke eines Pflichtenheftes beeindrucken. Jedoch weicht dieser Eindruck spätestens dann reinem Entsetzen, wenn die ganze Dokumentation gelesen und bewertet werden muss. Daher können wir nur anraten, komplexe Themenbereiche auf separate Dokumente zu verteilen. Unsere Erfahrung hat gezeigt, dass ca. 60-80 Seiten die psychologische Grenze dessen sind, was ein Mitarbeiter der Fachabteilung (der, der alles lesen muss) noch als überschaubar ansieht. Dem gegenüber sieht die Geschäftsleitung gerne viel Papier (die müssen es ja meistens nicht lesen). Dieses Spannungsverhältnis lässt sich durch verschiedene Dokumente leicht lösen. Eine Möglichkeit, ein Pflichtenheft einer breiten Leserschaft präsentieren zu können, ist die Beschreibung zielgruppenorientiert aufzubauen. Was bringt es? Mit dieser Form der Dokumentenorganisation besteht die Möglichkeit, vom Anwender bis hin zur Geschäftsführung über alle Hierarchiestufen hinweg mit einem Dokument zu arbeiten. Dies hat den Vorteil, dass nicht unterschiedliche Dokumente gepflegt und administriert werden müssen. Um jeder Zielgruppe gerecht zu werden, hat sich folgende Grundstruktur bewährt: Stand: 14.05.2016 Version 0.93 Seite -8- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Grobablauf Worum geht es? Darstellung des Gesamtumfangs des im Pflichtenheft abzuhandelnden Themas. Was bringt es? Jeder Leser hat so die Möglichkeit, sich in knapper Form über das Thema der Dokumentation zu informieren. So soll verhindert werden, dass erst viele Seiten durchgelesen werden müssen, um dann festzustellen, dass das Thema für ihn leider nicht interessant ist. Zielgruppe: Geschäftsleitung, Abteilungsleitung, Fachabteilung Das Verhältnis zwischen Text und Grafik sollte ungefähr 90% Grafik und 10% Text betragen. Am besten ganz auf Text verzichten. Hierbei sollte, wenn möglich folgendes beherzigt werden: Manager haben keine Daumen. Wer keine Daumen hat, kann nicht blättern. Aus diesem Grunde nicht mehr als eine Seite für den Grobablauf. Stand: 14.05.2016 Version 0.93 Seite -9- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Überblick Teilablauf Worum geht es? Detailliertere Darstellung der im Grobablauf dargestellten Informationen. Was bringt es? Der Grobablauf macht nur sehr oberflächliche Aussagen zu den einzelnen Teilabläufen. Aus diesem Grunde muss in der Darstellung der Teilabläufe eine detailliertere Sichtweise gegeben werden. Wichtig ist hierbei, den Bezug zum Grobablauf zu erhalten. Jeder Teilablauf muss eindeutig dem Grobablauf zugeordnet werden können. Zielgruppe: Abteilungsleitung, Fachabteilung Detailbeschreibung Worum geht es? Detaillierte Darstellung der im Pflichtenheft abzuhandelnden Vorgänge bzw. Abläufe. Was bringt es? Die Detailbeschreibung ist das "Fleisch" im Pflichtenheft. Während der Grob- und Teilablauf nur einen Überblick über die Abläufe geben. Die Ausarbeitung des Detailablaufs hat maßgeblichen Anteil daran, wie die Qualität der programmtechnischen Umsetzung wird. Zielgruppe: Fachabteilung Die zielgruppenorientierte Beschreibung als Gliederungshilfe im gesamten Pflichtenheft: Stand: 14.05.2016 Version 0.93 Seite -10- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 2 Zur Organisation eines Pflichtenheftes 2.1 Deckblatt Worum geht es? Das Deckblatt hat die Aufgabe, den Ursprung und die Inhalte des Pflichtenheftes auf einen Blick zu vermitteln. Was bringt es? Das Deckblatt eines Pflichtenheftes ist quasi der erste Teil der Visitenkarte des Unternehmens, das diese Unterlage erstellt hat. Ein guter Eindruck bereits auf der ersten Seite kann nie schaden. Folgende Informationen sollten auf dem Deckblatt enthalten sein: Logo: Firma: Name des Projektes: Version <Nr.>: Kurzbeschreibung: erstellt von: erreichbar unter: Stand: Copyrightvermerk: Wenn die Firma ein Logo hat, dann sollte es hier auch erscheinen. Name und ggf. Anschrift der Firma. Die Beschreibung des Projektes in kurzer und bündiger Form. Es genügen zwei, drei Worte. Version des Pflichtenheftes. evtl. ein kurzer Satz zur Erläuterung des Projekttitels. Name des Autors bzw. der Autoren des Pflichtenheftes. Telefon und/oder email-Adresse. letztes Speicherdatum des Dokumentes. © <Jahr> <Firma> Alle Rechte vorbehalten. Das Layout des Deckblattes kann frei gestaltet werden. In der WinWord-Dokumentation finden Sie unseren Vorschlag als Deckblatt für diese Ausarbeitung. 2.2 Inhaltsverzeichnis Worum geht es? Das Inhaltsverzeichnis soll eine kurze Übersicht über die im Dokument angesprochenen Bereiche geben. Was bringt es? Dem Leser hilft das Inhaltsverzeichnis schnell den entsprechenden Bereich zu finden. Aus diesem Grunde sollte jedes Pflichtenheft ein Inhaltsverzeichnis haben. Nutzen Sie hierzu die Gliederungsfunktion Ihrer Textverarbeitung. Zu beachten ist hierbei, dass die Schachtelung der Gliederung innerhalb des Inhaltsverzeichnisses nicht zu tief wird. Ein Inhaltsverzeichnis mit maximal drei bis vier Gliederungsebenen sollte auch bei umfangreichen Projekten ausreichen. Innerhalb des Dokumentes können dann weitere Gliederungsstufen eingebaut werden. Auch hier sollte die weitere Verschachtelung nicht zu weit getrieben werden. Lieber auf eine Gliederungsebene verzichten und Unterpunkte mit Aufzählungszeichen kennzeichnen. Das Layout des Inhaltsverzeichnisses ist u. E. eine reine Geschmacksfrage. Wir bevorzugen bei WinWord die Variante "Elegant". Stand: 14.05.2016 Version 0.93 Seite -11- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 2.3 Sitzungen zu diesem Thema Worum geht es? Ein Pflichtenheft ist über eine gewisse Zeit ein lebendes Gebilde. Es werden daher verschiedene Sitzungen notwendig sein, um alle Aspekte der/des zu behandelnden Bereiche/s zu erarbeiten. In der nachfolgenden Tabelle wird festgehalten, welche Sitzungen zur Erarbeitung dieses Pflichtenheftes abgehalten wurden. Was bringt es? Das Aufführen aller Sitzungen dient dazu, festzuhalten, wie häufig Sitzungen zu diesem Pflichtenheft gelaufen sind. Zudem kann anhand der Termine festgehalten werden, in welchem Turnus die Sitzungen stattfanden und wer daran teilgenommen hat. Es ist hilfreich, wenn unter jedem Datum ein Highlight steht, dass an diesem Tag besprochen worden ist (hilft bei der Erinnerung - Was war noch am...?). Unser Vorschlag: Besprechung am Zeit 13.03.1999 10:00-13:00 Kick-OffVeranstaltung Raum S10 Teilnehmer Herr Schneider Muster GmbH Herr Lehmann Muster GmbH Herr Hilgenberg Team-HDvO (*zeitweise) Frau Zimmermann Team-HDvO ... * Mitarbeiter, die nicht die gesamte Sitzung über anwesend waren, sollten in der Tabelle mit dem Zusatz "zeitweise" gekennzeichnet werden. So kann später Missverständnissen vorgebeugt werden, wenn Entscheidungen getroffen werden, die diesem Mitarbeiter nicht bekannt sind. 2.4 Offene Punkte Worum geht es? Während der Arbeiten an einem Pflichtenheft kommen u. U. Dinge zum Vorschein, die erst zu einem späteren Zeitpunkt detailliert angesprochen werden sollten. Damit diese Punkte nicht verloren gehen, sollte während der gesamten Arbeit an dem Pflichtenheft eine Liste mit den noch offenen Punkten geführt werden. Was bringt es? Das Führen einer offenen-Punkte-Liste hat sich bei der Erstellung von Pflichtenheften aus verschiedenen Gesichtspunkten bewährt. Zum einen dient sie als Gedankenstütze. Während der Fertigstellung können so die noch zu klärenden Themen aufgeführt werden. Dies können z. B. Dinge sein, über die die Gruppe nicht entscheiden kann, weil dies den Entscheidungsspielraum der Beteiligten übersteigt. Es können konzeptionelle Gedanken sein, die zu einem Zeitpunkt aufgekommen sind, zu dem dieser Punkt noch nicht zu bearbeiten ist. Zum anderen hilft die offene-Punkte-Liste auch einem externen Berater, klärungsbedürftige Themen als solche zu identifizieren und zu belegen. In der nachfolgenden Liste wird festgehalten, welche offenen Punkte es aktuell noch zum Thema des Pflichtenheftes gibt. Stand: 14.05.2016 Version 0.93 Seite -12- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Beispiel einer offenen-Punkte-Liste aus einem Pflichtenheft: Abwicklung Fremdgeschäfte Unser Mandant möchte zukünftig, um große Spitzen abfangen zu können, bestimmte Aufträge über externe Dienstleister abwickeln. Es müssen Funktionalitäten geschaffen werden, Ware direkt von den Lieferanten an den externen Dienstleister zu schicken. Gesamtübersicht offene Sendungen Zur besseren Übersicht aller bereits in Arbeit befindlichen Sendungen und aller noch auslösbaren Aufträge soll eine Übersicht geschaffen werden, in der beide Datenquellen zusammengeführt werden. Die Struktur der offenen Punkte zeigt, dass es eine Überschrift und eine kurze Beschreibung gibt. Diese Struktur erlaubt es, sich schnell in den offenen Punkten zurecht zu finden. Werden keine Überschriften gemacht, muss man erst den gesamten Text lesen, bis man das Richtige gefunden hat. Sollte die offene-Punkte-Liste nur aus Überschriften bestehen, fällt es u. U. schwer nach einer gewissen Zeit den Gesamtumfang bzw. den Inhalt eines offenen Punktes zu erkennen. Aus diesem Grunde sollte eine offene-Punkte-Liste immer aus beiden Elementen bestehen. Nutzen Sie zur besseren visuellen Abgrenzung der einzelnen Überschriften Aufzählungszeichen. Nutzen Sie hier nicht die Gliederungsfunktion Ihrer Textverarbeitung! Es kann sonst der Fall auftreten, dass die Auflistung der offenen Punkte einen wesentlichen Teil des Inhaltsverzeichnisses einnimmt. Damit ist die Übersichtlichkeit des Inhaltsverzeichnisses gefährdet. Die Beispiele spiegeln zwei Extreme wider. Der erste offene Punkt ist vom Arbeitsumfang her wesentlich umfangreicher als der zweite Punkt. Damit soll verdeutlicht werden, dass offene Punkte nicht einem bestimmten Detaillierungsgrad zugeordnet sein müssen. Schreiben Sie einfach alles auf, was im Laufe der Arbeit an dem Pflichtenheft beachtet werden muss. Ist ein Punkt erledigt, so kann er aus der Liste gelöscht werden. Nutzen Sie dazu während der Arbeit am Pflichtenheft die Änderungsverfolgung Ihrer Textverarbeitung. (siehe hierzu auch Kapitel „Änderungen verfolgen“) Stand: 14.05.2016 Version 0.93 Seite -13- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 2.5 Glossar Worum geht es? Pflichtenhefte behandeln meist sehr fachspezifische Dinge. Aus diesem Grunde muss für ein gemeinsames Verständnis aller Projektmitglieder für die im Pflichtenheft benutzten Begrifflichkeiten ein Glossar erstellt werden. Es ist von großer Wichtigkeit, innerhalb eines Projektes, dass alle Projektmitglieder das gleiche Verständnis für die im Projekt verwendeten Begriffe haben. Was bringt es? Das Glossar hilft, Missverständnisse zu vermeiden. Es sollte am Anfang und nicht am Ende des Pflichtenheftes stehen. So kann jeder, der nicht bei der Erarbeitung der Informationen dabei gewesen ist sofort feststellen, dass bestimmte Begriffe mit bestimmten Inhalten belegt sind. Dies hilft die Beschreibungen auf den nachfolgenden Seiten richtig zu interpretieren. Steht das Glossar am Ende des Dokumentes, werden Nicht-Projektmitglieder zumeist direkt mit dem Lesen der Ausarbeitung beginnen. Es wird kein Blick auf die gemeinsamen Definitionen geworfen. Dies führt im ersten Moment u. U. zu Missverständnissen beim Verständnis der Ausarbeitung. Probieren Sie es einmal aus! In der nachfolgenden Tabelle werden alle Begriffe festgehalten, die innerhalb des Projektes verwendet werden. Unser Vorschlag: Begriff Versandadresse Kundenartikelnummer Erklärung Die Adresse, an die die Ware geschickt wird. Eine individuelle Artikelnummer, unter der der Kunde seine Ware verkauft. ... Begriff Die Bezeichnung, die im gesamten Pflichtenheft einheitlich genutzt wird. Erklärung Die genaue Definition des Begriffs. Sollte es im Laufe der Arbeit an dem Pflichtenheft zur Erweiterung der Definition kommen, muss die Erklärung angepasst werden. Stand: 14.05.2016 Version 0.93 Seite -14- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 2.6 Ausgangssituation Worum geht es? Zu Beginn eines jeden Pflichtenheftes sollte eine kurze Beschreibung der Ausgangssituation stehen. Hierunter ist der Ausgangspunkt der Überlegungen zu verstehen, unter dem die Erstellung des Pflichtenheftes angegangen werden soll. Es ist eine kurze Darstellung der aktuellen Situation mit Hinblick auf die zukünftig gewünschte Situation. Die Beschreibung der Ausgangssituation beantwortet folgende Fragen: Wie stellt sich die Situation heute dar? Was ist der Auslöser für die Erstellung des Pflichtenheftes? Was bringt es? Die Beschreibung der Ausgangssituation hilft den/die Auslöser zu begreifen, unter dem/denen das Pflichtenheft erarbeitet worden ist. Zudem ergibt sich mit der Darstellung der Ausgangssituation ein geschlossenes Bild für das gesamte Pflichtenheft. Es müssen nicht noch zusätzlich Dokumente herangezogen werden, um den gesamten Zusammenhang zu überblicken. Um ein Vermischen zwischen Vorstudie bzw. Analyse und Pflichtenheft zu verhindern, sollte die Darstellung der Ausgangssituation nur so detailliert und umfangreich gehalten werden, wie es für das Verständnis des Pflichtenheftes notwendig ist. Versuchen Sie diese Darstellung auf eine maximal zwei Seiten zu begrenzen. Die Highlights reichen meist völlig aus um das Pflichtenheft in den richtigen Gesamtzusammenhang einzuordnen. 2.7 Aufgabenstellung und Zielsetzung Worum geht es? Während bei der Beschreibung der Ausgangssituation die Frage gestellt worden ist: "Was war der Auslöser für diese Aktivität". Stellt sich bei der Formulierung von Aufgabenstellung und Zielsetzung die Frage: Wie soll was erreicht werden? Ausgangsbasis für diesen Teil des Pflichtenheftes ist der Auftrag. (siehe Kapitel 6.1 Der Auftrag zur Erstellung eines Pflichtenheftes, Seite 96) Mit Hilfe des Auftrages hat der Autor des Pflichtenheftes feste Rahmenbedingungen, die für die weitere Erstellung am Pflichtenheft bindend sind. Die Beantwortung obiger Frage kann so einfach aus dem Inhalt des Auftrages abgeleitet werden. Was bringt es? Mit der Ausformulierung von Aufgabenstellung und Zielsetzung aus dem Auftrag hat der Autor des Pflichtenheftes die Möglichkeit, den Rahmen festlegen innerhalb dessen das Pflichtenheft erstellt wird. Während beim Auftrag alle Punkte nur in Stichworten niedergelegt worden sind, kann an dieser Stelle im Pflichtenheft eine umfassende Beschreibung der einzelnen Punkte erfolgen. Auf diese Weise wird auch Personen, die nicht am Prozess der Pflichtenhefterstellung beteiligt waren, die Möglichkeit gegeben, sich ohne Probleme einzuarbeiten. Zudem ermöglicht die genaue Erklärung von Aufgabenstellung und Zielsetzung fortwährende eine Überprüfung des Pflichtenheftes. Der Autor kann so zum einen jederzeit feststellen, ob die Stand: 14.05.2016 Version 0.93 Seite -15- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc erarbeiteten Ergebnisse mit den ursprünglich formulierten Zielen übereinstimmen. Zum anderen kann er anhand der Aufgabenstellung prüfen, ob er richtig vorgegangen ist. 2.8 Auflistung betroffener Bereiche Worum geht es? Pflichtenhefte werden heute zumeist nicht mehr „auf der grünen Wiese“ geschrieben. D. h. die Beschreibung neuer Programmfunktionalitäten muss in einen bereits bestehenden Kontext eingepasst werden. Dies betrifft zum einen die Einbettung von neuen Anwendungen in einen Systemverbund über diverse Schnittstellen. Diese Schnittstellen bilden die Trennlinie zwischen den verschiedenen Systemen. Zum anderen betrifft die Pflichtenhefterstellung die Erweiterung von integrierten Softwaresystemen. Die meisten dieser Softwaresysteme sind komplexe Gebilde. Aus diesem Grunde kann es vorkommen, dass die innerhalb eines Pflichtenheftes definierten Änderungen/Ergänzungen an verschiedenen Stellen im System Auswirkungen haben. Dies bezieht sich u. U. auch auf Bereiche, die nicht unmittelbar Gegenstand des im Pflichtenheft zu behandelnden Themas sind. Im Pflichtenheft liegt der primäre Fokus auf den Kernbereichen der Problemstellung. Die betroffenen Bereiche stellen die sekundär zu behandelnden Teile dar. Hiermit ist jedoch keine Wertung verbunden. Die Beschreibung der Auswirkungen von Änderungen außerhalb der Kernbereiche ist von gleichrangiger Wichtigkeit, wie die Beschreibung der Kernbereiche selber. Aus diesem Grunde ist es sinnvoll bereits zu Beginn alle betroffenen Bereiche aufzulisten. Die Liste kann während der Arbeit am Pflichtenheft ergänzt werden. Diese Ergänzungen werden meistens dann vorgenommen, wenn technisch bedingt Erweiterungen bzw. Ergänzungen in Bereichen vorgenommen werden müssen, die zu Beginn der Pflichtenhefterstellung nicht bekannt waren bzw. nicht berücksichtigt wurden/werden konnten. Was bringt es? Die Auflistung der betroffenen Bereiche hilft zum einen, den Gesamtüberblick über die Auswirkungen der geplanten Änderungen außerhalb der Kernbereiche zu bekommen. Zum anderen kann während der ganzen Arbeit an dem Pflichtenheft eine Vollständigkeitskontrolle über die sekundär betroffenen Bereiche durchgeführt werden. Im Gegensatz zu der offenenPunkte-Liste sollte die Auflistung der betroffenen Bereiche nicht sukzessive gelöscht werden. Sie ist als permanenter Teil des Pflichtenheftes gedacht. Sie beinhaltet keine offenen Fragen, sondern Informationen über absehbare Änderungen in sekundären Bereichen. Demgegenüber wird sich eine offene-Punkte-Liste primär mit den noch zu klärenden Arbeiten in den Kernbereichen des Pflichtenheftes beschäftigen. Beispiel aus einem Pflichtenheft: Kundenstammdaten Die Kundenstammdaten müssen um die zusätzlichen Informationen der Logistik erweitert werden. Wegen der umfangreichen Erweiterungen müssen dort separate Erfassungsmasken erstellt werden. Änderungen im Versand Die Aufkleber im Versand müssen um die zusätzlichen Informationen erweitert werden. Hierbei ist zu beachten, dass sich auch das Layout der Aufkleber verändern wird. Stand: 14.05.2016 Version 0.93 Seite -16- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Die Struktur der Auflistung zeigt, dass es eine Überschrift und eine kurze Beschreibung gibt. Diese Struktur erlaubt es, sich schnell in den betroffenen Bereichen zurecht zu finden. Werden keine Überschriften gemacht, muss man erst den gesamten Text lesen, bis man das Richtige gefunden hat. Sollten die betroffenen Bereiche nur aus Überschriften bestehen, fällt es u. U. schwer, nach einer gewissen Zeit den Gesamtumfang bzw. den Inhalt der betroffenen Bereiche zu erkennen. Aus diesem Grunde sollte diese Liste immer aus beiden Elementen bestehen. Nutzen Sie zur besseren visuellen Abgrenzung der einzelnen Überschriften Aufzählungszeichen. Nutzen Sie hier nicht die Gliederungsfunktion Ihrer Textverarbeitung! Es kann sonst der Fall auftreten, dass die Auflistung der betroffenen Bereiche einen wesentlichen Teil des Inhaltsverzeichnisses einnimmt. Damit ist die Übersichtlichkeit des Inhaltsverzeichnisses gefährdet! Werbung Seit Februar 2000 gibt es ein interaktives Online-Magazin! Projekt Magazin bietet unter http://www.projektmagazin.de/ praxisbezogene Unterstützung für Projektmitarbeiter, Projektleiter, Berater sowie für alle Personen, die sich mit den Themen Projektmanagement, persönliche Weiterentwicklung und Software-Qualitätsanforderungen beruflich auseinandersetzen. Das finden Sie im Projekt Magazin: Für Einsteiger und Profis: Praxisbezogene Fachartikel von Experten aus der IT-Branche Checklisten, Tipps, Übungen zum Umsetzen in die Praxis Informationen über Tools, Bücher, Veranstaltungen Leserempfehlungen von Schulungsunternehmen und Büchern Ausgesuchte Links zu interessanten Internet-Adressen Für Interessierte: Den kostenlosen Newsletter mit Hinweisen auf die aktuelle Ausgabe, News und Tipps. Ständig aktualisiertes Glossar Abonnieren Sie noch heute unseren kostenlosen Newsletter und Sie erhalten alle zwei Wochen Hinweise zur aktuellen Ausgabe, garniert mit praktischen Tipps für Ihren Projektalltag. Unter http://www.projektmagazin.de/ informieren Sie Experten! Kommen Sie vorbei, wir freuen uns auf Sie. Petra Berleb Ihre Herausgeberin [email protected] (c) Projekt Magazin 2000 Stand: 14.05.2016 Version 0.93 Seite -17- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3 Fachliche Inhalte beschreiben Die nachfolgenden Beschreibungen der fachlichen Inhalte basieren auf der von uns entwickelten Methode HDvO. Hierarchische Dokumentation von Objekten Diese softwaregestützte Methode zur Erstellung von Pflichtenheften ist eine Möglichkeit eine solche Dokumentation zu erstellen. Falls Sie an dieser Stelle eine andere/eigene Methode nutzen wollen, ersetzen Sie bitte alle Abschnitte mit dem HDvO-Symbol durch die jeweilige Vorgehensweise. Sollten Sie die von uns vorgeschlagene Methode HDvO nutzen, teilen Sie uns bitte Ihre Erfahrungen mit. Wir werden versuchen, Ihre Anmerkungen mit in diese Ausarbeitung einfließen zu lassen. 3.1 Objekte identifizieren Worum geht es? Die Grundidee, der Methode HDvO ist die Annahme, dass sich jede Software als AktionErgebnis-Beziehung beschreiben lässt. Dabei wird immer von folgender Frage ausgegangen: "Eine Aktion wird ausgeführt - welche Ergebnisse werden produziert?" Bei der Beschreibung eines Programms kann man genauso vorgehen. Jedes Programm, das man aufruft bzw. jede Funktion die ausgeführt wird, produziert ein oder mehrere Ergebnisse. (Auch wenn eine Aktion nichts bewirkt, ist dies als Ergebnis der Aktion anzusehen.) Aktion Ergebnis Programm läuft ab Programm wird ausgeführt Aktion Der Punkt, von dem aus eine Aktivität gestartet wird. Ergebnis Das Resultat einer Aktion. Stand: 14.05.2016 Version 0.93 Seite -18- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Zur genaueren Spezifizierung können die Ergebnisse einer Aktion in verschiedene Objekte eingeteilt werden. Aktion Programm wird ausgeführt. Objekt Beleg wird gedruckt. Objekt Jedes Ergebnis wird als Objekt beschrieben. Innerhalb von HDvO wird jedes Objekt als eine in sich abgeschlossene funktionale Einheit angesehen. Dies kann z. B. ein Ausdruck oder eine Bildschirmmaske sein. Mit Hilfe dieser Objekte ist es auf einfache Weise möglich, alle Ergebnisse einer Aktion zu klassifizieren. Eine Aktion kann dabei nicht nur ein Ergebnis, sondern eine Summe von Ergebnissen produzieren. Alles das, was als Summe von Ergebnissen nach dem Auslösen einer Aktion vorliegt, kann in einer Hierarchie dargestellt werden. Aktion Ergebnisse/ Objekte ... So könnte z. B. beim Start einer Adressverwaltung zuerst geprüft werden, ob alle notwendigen Datenbanken vorhanden sind. Erst danach erscheint der Arbeitsbildschirm und es werden die verschiedenen Menüpunkte zur Verfügung gestellt. Jedes Ergebnis wiederum kann Ausgangspunkt einer neuen Aktion sein. Sollte nach dem Start der Anwendung z. B. der Menüpunkt Neuanlage gewählt werden, so wird aus dem Ergebnis Neuanlage (als Ergebnis des Programmstarts) die Aktion Neuanlage. Diese Aktion wiederum liefert ein Ergebnis – z. B. einen Eingabedialog. So kann eine zu beschreibende bzw. eine nachzudokumentierende Anwendung als strukturierte Ansammlung von Einzelobjekten in einer Hierarchie niedergelegt werden. Ausgehend von einem Hauptobjekt, das nämlich, von dem aus die erste Aktion ausgeführt wurde, werden alle Ergebnisse auf der darunter liegenden Hierarchieebene eingehängt. Stand: 14.05.2016 Version 0.93 Seite -19- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Das Hauptobjekt ist bei dieser Betrachtungsweise unspezifiziert. D. h. normalerweise wird innerhalb von HDvO jedes Ergebnis einer Aktion einem oder mehreren Objekten zugeordnet. Das Hauptobjekt hingegen hat eine solche Zuordnung nicht. Es dient lediglich als Startpunkt der Beschreibung. Ausführen einer Funktion Aufruf eines Programms Aktion 1 Programm wurde aufgerufen Programm wird aufgerufen Aus einem Ergebnis wird eine Aktion Bildschirmmaske (z. B. Hauptmaske) Bildschirmmaske (z. B. Hauptmaske) Aktion 2 Menüpunkt 1 (z. B. Neuanlage) Menüpunkt "Neuanlage" wird aufgerufen Menüpunkt 2 (z. B. Speichern) Bildschirmmaske (z. B. Neuanlage) Menüpunkt 3 (z. B. Drucken) Menüpunkt 2 (z. B. Speichern) Menüpunkt 3 (z. B. Drucken) Diese Darstellung zeigt schematisch einen Teil einer Anwendung. Dabei wird hier bewusst der Begriff Ablauf vermieden. Die Hierarchie in HDvO ist nicht als neue Form des Ablauf- oder Flussdiagramms anzusehen. Innerhalb der Hierarchie wird lediglich ein Funktionsbaukasten beschrieben, der in einer Struktur niedergelegt ist, die der Sichtweise von der Funktion eines Programms nahe kommt. Eine 100%ige Entsprechung der Verarbeitungen innerhalb eines Programms kann diese Darstellungsform nicht leisten, da die Hierarchie nicht in der Lage ist, Abhängigkeiten und Abläufe korrekt wiederzugeben. Die Hierarchie dient dazu, Ergebnisse in Form von Objekten niederzulegen. Diese Darstellungsweise unterstützt dabei eine Sichtweise, mit der auch Anwender ohne Programmierkenntnisse den Ablauf eines Programms verstehen bzw. beschreiben können. Was bringt es ? Ziel dieser Vorgehensweise ist: a) b) Klassifizierung Alle Ergebnisse, die eine Aktion produziert werden eindeutig Objekten zugeordnet. Strukturierung Alle zusammengehörigen Ergebnisse werden übersichtlich auf einer Hierarchieebene zusammengefasst. Die Beschreibung einer Anwendung lässt sich mit Hilfe dieser Vorgehensweise effektiv und vollständig durchführen. Eine umfassende Einteilung aller Ergebnisse einer Aktion in Objekte stellt sicher, dass der Leistungsumfang der Anwendung möglichst vollständig beschrieben wird. Stand: 14.05.2016 Version 0.93 Seite -20- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Als Ergebnis der Hierarchischen Dokumentation von Objekten soll eine Gliederung entstehen, anhand der sich ein Anwender durch die Funktion einer Anwendung navigieren kann. Die Beschreibung der Objekte muss so ausgelegt sein, das zu jedem Zeitpunkt die notwendigen Informationen für das Verständnis der Anwendung vorhanden sind. Stand: 14.05.2016 Version 0.93 Seite -21- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.2 Menüs Hierarchische Dokumentation von Objekten Worum geht es? Mit dem Menü werden alle Auswahlmöglichkeiten innerhalb eines Programms beschrieben. Hierzu gehören neben den Menüpunkten bei grafischen Oberflächen auch die Buttonleisten (Toolbars). Sie stehen zumeist als Ersatz bzw. Ergänzung für diese Menüpunkte innerhalb einer Anwendung zur Verfügung. Bei zeichenorientierten Oberflächen können anstelle von Symbolleisten Funktionstasten bzw. Tastenkombinationen (Hot-Keys) die Aufgabe der Buttons in den Symbolleisten übernehmen. Menüs sind losgelöst von Dialogen zu sehen. So werden Buttons bzw. Tastenkombinationen, die nur innerhalb von Dialogen zur Verfügung gestellt werden nicht als eigenständige Menüs beschrieben. Der Grund für diese Teilung ist, dass mit Hilfe von Menüs die Funktionalität der gesamten Anwendung gesteuert werden. Die Buttons/Tasten innerhalb von Dialogen steuern jedoch nur die Funktionalität des Dialogs. Aus diesem Grunde werden sie innerhalb des Dialogs beschrieben. Was bringt es? Menüs bieten eine gute Möglichkeit bei einem Pflichtenheft als Gliederungshilfe zu dienen. Dies hat zum einen den Vorteil, dass man nicht (irgend)eine Gliederungsform suchen muss. Zum anderen kann sich die Fachabteilung an der technischen Umsetzung der zu entwickelnden Software orientieren. Wie wird es gemacht? Nachfolgend wird das Hauptmenü unserer Software HDvO gezeigt. Entsprechend dieser Menüstruktur sieht eine Gliederung, die eine Menüstruktur als Vorlage nimmt wie folgt aus: 1. 2. 3. 4. 5. 6. Projekt Bearbeiten Objekt Ansicht Fenster Hilfe Die Unterpunkte unter dem jeweiligen Hauptmenüpunkt bilden dann die nächst niedrigere Gliederungsstufe. Ein Menüpunkt kann nicht nur weitere Untermenüpunkte aufrufen. Sobald Funktionen ausgeführt werden, beginnt die Leistungsbeschreibung des Programms. Die Beschreibung von Menüpunkten ist erfreulich kurz. Im obigen Beispiel würde sie für den ersten Punkt lauten: Stand: 14.05.2016 Version 0.93 Seite -22- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Projekt Unter den Menüpunkt Projekt sind alle Funktionen zusammenfasst, die die Bearbeitung von HDvO-Projekten betreffen. Dieser Menüpunkt ist immer verfügbar. Name des Menüpunktes Exakte Beschreibung des Menüpunktes, wie er später im Programm auftauchen wird. Bei grafischen Oberflächen, wie z. B. Windows gibt es Konventionen zur Beschriftung von Menüpunkten. (z. B. „->“ hinter Menübeschriftungen, wenn ein Menüpunkt ein Untermenü aufruft.) Diese Konventionen sollten Bestandteil des Menünamens sein. Beschreibung Die Beschreibung eines Menüeintrages entspricht im wesentlichen dem Hilfetext, der bei vielen Windowsanwendungen in der Statuszeile des jeweiligen Programms angezeigt wird. Zusätzliche Informationen zur Beschreibung eines Menüpunktes Zusätzlich zu dieser Beschreibung kann eine Bedingung hinzugefügt werden. Zum einen kann ein Menüpunkt nur innerhalb eines bestimmten Kontextes verfügbar sein. (z. B. ist der Menüpunkt „Drucken“ nur dann verfügbar, wenn auch ein Dokument geladen worden ist) Zum anderen kann der Aufruf eines bestimmten Menüpunktes an Berechtigungen geknüpft sein. (z. B. Der Menüpunkt „User löschen“ ist nur dann verfügbar, wenn der Anwender die Rechte des Administrators hat.) Falls die Verfügbarkeit des Menüpunktes an mehreren Bedingungen hängt, sollte die textuelle Beschreibung durch eine Tabelle ersetzt werden. Unser Vorschlag Aktiv Bedingung JA Der Anwender muss die Rechte des Administrators haben JA Es muss mindestens ein User eingetragen worden sein. NEIN In allen anderen Fällen ist der Menüpunkt inaktiv. Meldung "Es konnte kein User gefunden werden." "Diese Funktion kann zur Zeit nicht genutzt werden." Aktiv Ist der Menüpunkt bei der nachstehenden Bedingung aktiv? Bedingung Welche Bedingung wirkt auf den Menüpunkt ein? (Prüfen Sie, ob es u. U. verknüpfte Bedingungen gibt. Z. B. kann der Menüpunkt "Ware ausliefern" immer dann gesperrt sein, wenn ein Kunde noch offene Rechnungen hat. Sollte er aber diesen Auftrag per Vorkasse bezahlt haben, wird die Ware dennoch ausgeliefert.) Meldung In bestimmten Systemen werden Menüpunkte nicht inaktiviert, sondern es erfolgt bei Auswahl eine Meldung, warum dieser Punkt nicht ausgeführt werden kann. In diesem Fall kann hinter der Bedingung der Meldungstext eingetragen werden, der dem Anwender angezeigt wird, wenn er den Menüpunkt aufruft. Rechte Maustaste Bei vielen grafischen Benutzeroberflächen besteht die Möglichkeit, die rechte Maustaste zu nutzen um ein kontextsensitives Menü aufzurufen. Die Beschreibung einer solchen Funktion sollte nicht an dieser Stelle erfolgen. Die Funktion der rechten Maustaste wird innerhalb eines bestimmten Kontextes genutzt. Aus diesem Grunde sollte die Beschreibung Stand: 14.05.2016 Version 0.93 Seite -23- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc dieser Funktionen auch an der Stelle des jeweiligen Kontextes erfolgen. Unseren Vorschlag finden Sie unter dem Punkt "Dialoge beschreiben". Detaillierungsmöglichkeiten der Beschreibung In verschiedenen anderen Bereichen der Dokumentation von Programmfunktionen besteht die Möglichkeit, bei der Beschreibung verschiedene Arten der Detaillierung zu wählen. Wir haben sie mit klein, mittel und groß bezeichnet. (In Anlehnung an den zu treibenden Arbeitsaufwand, diese Informationen niederzulegen.) Hier an dieser Stelle sehen wir keine Möglichkeit/Notwendigkeit, diese Varianten anzubieten. Die Substanz der Beschreibung von Menüs ist zu gering, als dass sich die Differenzierung des Detaillierungsgrades bei der Beschreibung lohnen würde. 3.3 Dialoge Hierarchische Dokumentation von Objekten 3.3.1 Dialoge beschreiben Worum geht es? Als Dialog werden die Ausgaben von Programmen auf dem Bildschirm angesehen. Der Begriff Dialog darf hierbei jedoch nicht so umfassend wie im Sinne der Programmierung interpretiert werden. Für den Programmierer kann u. U. jede Bildschirmausgabe als Dialog gelten. Innerhalb unserer Methode HDvO wird zwischen Dialogen und Meldungen unterschieden. Während bei Dialogen differenzierte Möglichkeiten vorhanden sind, unterschiedliche Daten zu erfassen, ist bei Meldungen nur die Reaktion auf Verarbeitungen innerhalb des Programms möglich. Als typische Beispiele für Meldungen gelten Fehler- oder Informationsmeldungen. Wir sind in der Vergangenheit immer wieder mit der Diskussion konfrontiert worden, ob die Abbildung eines Dialoges zwingender Bestandteil eines Pflichtenheftes ist. Wir können diese Frage mit einem klaren Ja beantworten. Die Erfahrung hat gezeigt, dass das Abstraktionsniveau vieler Anwender nicht ausreicht, die Funktionalität einer Maske nur durch das Aufzählen der Felder zu erfassen. Frei nach dem Motto "Ein Bild sagt mehr als tausend Worte" hat sich die Abbildung von Dialogen im Pflichtenheft immer bewährt. Zudem kann anhand einer Abbildung das Verhalten des Dialoges besser dargestellt werden, als wenn es dazu nur eine abstrakte Textbeschreibung gibt. Was bringt es? Bei der Darstellung von Dialogen sollte versucht werden, eine möglichst hohe Übereinstimmung mit der zukünftigen Dialogführung zu bekommen. Eine zeichenorientierte Darstellung grafischer Dialoge z. B. macht es der Fachabteilung nicht leichter, sich die zukünftige Anwendung vorzustellen. Nutzen Sie, wenn möglich den Maskendesigner der Anwendungsentwicklungsumgebung, mit der die Software erstellt wird. Sollte dies nicht möglich sein, nutzen Sie Werkzeuge wie z. B. HDvO. Grundsätzlich gilt, je exakter die Darstellung der Dialoge im Pflichtenheft der zukünftigen Anwendung entsprechen, desto geringer werden Diskussionen über evtl. Nacharbeiten sein. Stand: 14.05.2016 Version 0.93 Seite -24- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Die Beschreibung eines Dialoges teilt sich immer in zwei Teile. Dem Abbild des Dialogs selber und der Feld- und Funktionsbeschreibung. Sollte das Abbild des Dialoges aus einem Screenshot bestehen, achten Sie hierbei auf die aktuell im System eingestellte Farbtiefe. Diese Farbtiefe wird bei der Erstellung von Schnappschüssen meist übernommen. Sollte die aktuelle Farbeinstellung unter Windows "Truecolor" sein, so wird diese auch beim Bildschirmschnappschuss übernommen. 256 Farben reichen jedoch für die Darstellung von Dialogen aus. Die Dateigröße des Pflichtenheftes reduziert sich dadurch erheblich. Die Systematik der Beschreibung im Bereich der Feld- und Funktionsbeschreibungen von Dialogen ist unabhängig von der Art der Oberfläche und dem zugrundeliegenden Betriebssystem zu sehen. D. h. für die Beschreibung von Dialogen muss keine betriebssystemspezifische Form der Beschreibung erstellt werden. Im Umkehrschluss bedeutet das, dass z. B die Beschreibung eines Dialoges unter UNIX ohne weiteres auch für Windows übernommen werden kann. Hierzu muss dann nur die Abbildung der Maske gegen die aktuelle Aufbereitung unter Windows ausgetauscht werden. (Hiermit ist natürlich nicht gemeint, dass eine detaillierte Softwarebeschreibung grundsätzlich betriebssystemunabhängig gemacht werden kann. Dazu müssen bei der Programmentwicklung meistens zu viele systemspezifische Funktionen des aktuellen Zielsystems genutzt werden. Die Oberfläche ist davon jedoch häufig nicht betroffen). Wenn ein Dialog beschrieben wird, beginnt man mit einem einleitenden Satz. Es hilft innerhalb des Pflichtenheftes festzustellen, von wo der Dialog aufgerufen worden ist. Der Kontext ist so einfacher ersichtlich. Der einleitende Satz ist hierbei als Minimalanforderung an den Einstieg in eine Dialogbeschreibung zu sehen. Wenn zusätzliche Erklärungen sinnvoll sind, sollten Sie hier an dieser Stelle gemacht werden. Der einleitende Satz könnte lauten: "Nach Aufruf des Menüpunktes <Menüpunkt> erscheint der folgende Dialog <Name des Dialoges>. Stand: 14.05.2016 Version 0.93 Seite -25- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Beispiel für einen Dialog: Nach der Abbildung des Dialoges wird seine Funktionalität beschrieben. Hierunter fallen: - Feldbeschreibung Funktionstasten Buttons Rechte Maustaste Controls und sonstige Dialogelemente ... Bei der Beschreibung von Dialogen sollte eine Durchgängigkeit eingehalten werden, was die Reihenfolge der Beschreibungen angeht. Die obige Auflistung der zu beschreibenden Teilbereiche für einen Dialog kann als Anhaltspunkt dafür dienen, wie diese Durchgängigkeit gewährleistet werden kann. Sollten verschiedene Teilbereiche bei einem Dialog nicht vorkommen. (z. B. keine Funktionstasten) Lassen Sie keine leeren Tabellen als Platzhalter dort. Dies produziert bei den Fachabteilungen nur unnötigen Diskussionsbedarf. Stand: 14.05.2016 Version 0.93 Seite -26- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.3.2 Feldbeschreibungen Wie wird es gemacht? Die wichtigste Information zu einem Dialog ist die Beschreibung der dargestellten Felder. Die Form der Beschreibung sollte nicht in Prosa erfolgen. Eine tabellarische Form ist übersichtlich und bietet flexible Erweiterungsmöglichkeiten. Die Auflistung der Felder sollte hierbei in der Reihenfolge erfolgen, in der die Eingabe gemacht wird. Unser Vorschlag: Feld Art Bemerkung Feld Name des Feldes in der Maske. Art Zur Beschreibung eines Feldes gehört auch seine Eigenschaft. Hierunter ist die Art und Weise zu verstehen, wie sich das Feld im Dialog verhält. Folgende grundlegenden Arten können vorkommen: Anzeige: Mussfeld: Kannfeld: Auswahlfeld: Feld wird vom Programm aus gefüllt. Feld darf nicht leer bleiben Feld muss nicht unbedingt ausgefüllt sein. Es kann eine Auswahl aus einer definierten Menge getroffen werden. Weitere Arten sind je nach Betriebssystem bzw. Anwendungsentwicklungsumgebung möglich. Bemerkung Hier gehört eine kurze Beschreibung des jeweiligen Feldes hin. Es können auch Bedingungen bzw. Plausibilitäten niedergelegt werden. Prüfen Sie auch bei augenscheinlich profanen Feldern wie z. B. Kundennummer oder Adresse, ob nicht eine Beschreibung notwendig ist. (So ist es z. B. für das Schreiben einer Rechnung schon wichtig, ob die Adresse im Dialog die Versandadresse oder die Rechnungsanschrift des Kunden ist.) Bei Feldern, deren Inhalte mit Hilfe einer Formel errechnet werden, muss die Formel Teil der Bemerkung werden. Stand: 14.05.2016 Version 0.93 Seite -27- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.3.3 Funktionstasten und Buttons Wie wird es gemacht? Innerhalb eines Dialoges besteht u. U. die Möglichkeit, Buttons und/oder Funktionstasten zu benutzen. Auch diese Funktionen müssen ausreichend beschrieben werden. Hierzu eignet sich die nachfolgende Tabelle. Unser Vorschlag: Button Aktiv Bedingung/Beschreibung Button (alternativ kann hier auch die Beschriftung einer Funktionstaste hin) Hier wird die Beschriftung des Buttons bzw. der Funktionstaste eingetragen. Sollte ein Button ohne Beschriftung in einer Toolbar verfügbar sein, kann auch das Icon in der Tabelle stehen. Aktiv Ist der Button/die Funktionstaste in diesem Kontext aktiv. Bedingung/Beschreibung Kurze Beschreibung der Funktion des Buttons Beispiel: Button OK Abbruch Hilfe F-Taste F6 Neu Aktiv Ja Ja Ja Bemerkung Errechnet die Datensatzlänge auf Basis der gewählten Zählerbasis. Schließt den Dialog und springt zurück in die Tabelle. Zeigt ein Hilfefenster zu diesem Dialog an. Aktiv Bemerkung Ja Legt einen neuen Kunden im Kundenstamm an. (Siehe hierzu Kapitel 1.2.3 Neuanlage von Kunden Seite: 45)* ... Die Steuerung innerhalb eines Dialoges kann so gewünscht sein, dass andere Funktionen aus dem Dialog aufgerufen werden, die wiederum Dialoge zur Folge haben. Beschreiben Sie diese Funktion nicht hier! *Wie oben gezeigt, reicht ein Verweis auf die entsprechende Stelle im Dokument aus. Sollte eine Funktion mehrmals innerhalb eines Pflichtenheftes genutzt werden, können so Abweichungen vermieden werden. Stand: 14.05.2016 Version 0.93 Seite -28- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.3.4 Rechte Maustaste Wie wird es gemacht? Bei verschiedenen Benutzeroberflächen besteht die Möglichkeit, die rechte Maustaste zu benutzen, um ein kontextsensitives Menü aufzublenden. Nachfolgend finden Sie eine Tabelle, in der Sie die im Menü zur Verfügung gestellten Auswahlen beschreiben können. Unser Vorschlag: Aufruf Menü Focus bei Aufruf: Menüpunkt Aktiv Bedingung/Beschreibung Aufruf Menü Hier wird eingetragen, wie das Menü aufgerufen wird. (Kann bei anderen Systemen auch über eine spezielle Tastenkombination erfolgen.) Focus bei Aufruf Kontextsensitive Systeme bieten immer dann eine Menüauswahl, wenn ein bestimmter Bereich aktiv bzw. ausgewählt worden ist. In dieses Feld kann der Bereich eingetragen werden, der aktiv sein muss, damit das Kontextmenü erscheint. Menüpunkt Der Menüpunkt, der dem Benutzer zur Auswahl angeboten wird. Aktiv Ist der Menüpunkt in diesem Kontext aktiv? Bedingung/Beschreibung Kurze Beschreibung der Funktion des Menüpunktes. Die Tabelle ist nicht dafür gedacht, umfangreiche Beschreibungen einzelner Menüpunkte aufzunehmen. Damit die Beschreibung übersichtlich bleibt, sollte in der Tabelle nur sehr kurz auf die Menüpunkte eingegangen werden. Bei ausführlicheren Beschreibungen empfiehlt es sich, für die Beschreibung einzelner Menüpunkte unter der Tabelle einen separaten Text zu schreiben. Hierbei sollte die Überschrift des Textes identisch mit dem in der Tabelle beschriebenen Menüpunkt sein. Beispiel: Aufruf Menü Menüpunkt Bearbeiten* Spalte einfügen Spalte löschen Rechte Maustaste Focus bei Aufruf: Komplette markierte Spalte Aktiv Bedingung/Beschreibung Nein Ändert die Spalteneinstellungen (erst ab der 5 Spalte verfügbar) Ja Fügt eine Spalte an der aktuellen Position ein. Nein Löscht die aktuell gewählte Spalte. (Die ersten drei Spalten können nicht gelöscht werden.) *Bearbeiten In der Tabelle sind die ersten 5 Spalten fix definiert. Aus diesem Grunde ist es hier nicht möglich die Spaltentitel zu bearbeiten . . . Stand: 14.05.2016 Version 0.93 Seite -29- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.3.5 Controls und sonstige Dialogelemente Wie wird es gemacht? Bei den grafischen Benutzeroberflächen gibt es zu den normalen Anzeige- und Eingabefeldern noch eine Vielzahl von sog. Controls. Dies sind spezielle Funktionen, die innerhalb von Dialogen genutzt werden können. Hierzu gehören z. B. Regler, Drop-Downlisten, Comboboxen usw. Bei der Vielzahl der existierenden Möglichkeiten ist es müßig, jedes einzelne Control zu beschreiben. Es ist vielmehr sinnvoll eine einheitliche Vorgehensweise zu definieren, mit der jedes Control beschrieben werden kann. Folgende Schritte können hier hilfreich sein: 1. Spalten der Tabelle definieren Zur Definition einer Tabelle für ein Control, werden zuerst die Spalten der Tabelle definiert. Diese Tabelle ist der Rahmen, in dem das Control vollständig beschrieben wird. Die drei Spalten Control, Status und Beschreibung/Bedingung reichen meistens dafür aus. Beispiel: 2. Checkbox Die Spalten zur Beschreibung von Checkboxen lauten: Control=Checkbox Status=Selektion Beschreibung/Bedingung=Beschreibung/Bedingung Attribute der Felder festlegen Nachdem die Spalten definiert worden sind, müssen die Attribute festgelegt werden, die jedes Feld in der Spalte haben kann. Beispiel: Beispiel: Control Checkbox Checkbox: Hier wird der Text der Checkbox erfasst. Selektion: Welche Checkbox ist per Voreinstellung selektiert? Beschreibung/Bedingung: Welche Auswirkung hat die Selektion bzw. keine Selektion der Checkbox? Selektion Bedingung/Beschreibung Sollte eine Tabelle öfter genutzt werden, kann diese als Textbaustein im Pflichtenheft abgelegt werden. So kann ohne viel Aufwand der gleiche Aufbau an verschiedenen Stellen immer wieder genutzt werden. Einfach leere Tabelle markieren Einfügen - Autotext Neu wählen - Namen vergeben - fertig. Stand: 14.05.2016 Version 0.93 Seite -30- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.3.6 Möglichkeiten der Detaillierung Unsere Erfahrungen haben gezeigt, dass je tiefer die Fachabteilung selbst in der EDV steckt, desto detaillierter können die erwarteten Vorgaben sein. Dem entgegen stehen natürlich Zeit und Geld. Aus diesem Grunde ist es wichtig vor der Erstellung des Pflichtenheftes den Detaillierungsgrad der Dialogbeschreibung festzulegen. Die Festlegung des Detaillierungsgrades der Beschreibung erfolgt anhand eines Beispieldialoges. Mit diesem werden die verschiedenen Möglichkeiten der Beschreibung vorgestellt. Gemeinsam mit der Fachabteilung wird dann entschieden, in welcher Form die Beschreibung vorgenommen wird. Während der Festlegung der Form der Detaillierung müssen folgende Fragen gestellt werden: Ist die gewählte Form der Detaillierung sinnvoll ? (Für Entwicklung oder Anwender) Enthält die gewählte Form der Detaillierung den notwendigen Informationsgehalt ? Ist die gewünschte Form der Detaillierung unter den zeitlichen und ökonomischen Rahmenbedingungen möglich ? Erst wenn alle diese Fragen befriedigend beantwortet werden konnten, kann mit der eigentlichen Beschreibung der Dialoge begonnen werden. Varianten der Beschreibung von Dialogen Anbei finden Sie Beispiele, wie man einen Dialog beschreiben kann. Als Vorlage für diese Beispiele dient der zu Beginn des Kapitels dargestellte Dialog. Wir haben bisher zumeist die Variante "klein" eingesetzt. Die anderen Varianten der Dokumentation haben sich in unserer Arbeit oft als zu zeitaufwendig und zu teuer erwiesen. Beschreibung von Dialogen - Variante "klein" Feld Art Bemerkung Beispiel: Feld Firma Art Bemerkung Mussfeld Firmenbezeichnung des registrierten Anwenders. Dieses Feld wird bei Firmenkunden im "About-Dialog" angezeigt. Stand: 14.05.2016 Version 0.93 Seite -31- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Beschreibung von Dialogen - Variante "mittel" Feld Art Länge Bemerkung Beispiel: Feld Firma Art Länge Mussfeld 40 Zeichen Bemerkung Firmenbezeichnung des registrierten Anwenders. Dieses Feld wird bei Firmenkunden im "About-Dialog" angezeigt. Beschreibung von Dialogen - Variante "groß" Feld Art Typ Länge Default Bemerkung Beispiel: Feld Firma Art Typ Länge Mussfeld CHR 40 Default Bemerkung <leer> Firmenbezeichnung des registrierten Anwenders. Dieses Feld wird bei Firmenkunden im "AboutDialog" angezeigt. Die dargestellten Varianten sind als Vorschlag zu verstehen und erheben nicht den Anspruch auf Vollständigkeit. Entscheiden Sie selbst welche dieser Varianten Sie nutzen wollen. Sollte eine Nachdokumentation einer bereits bestehenden Anwendung durchgeführt werden müssen, so hat sich folgende Form der Dialogbeschreibung bewährt: Beschreibung von Dialogen - Variante "Nachdokumentation" Feld Art Bemerkung Herkunft Beschreibung Weiterverwendung Beispiel: Feld Art Bemerkung Firma Mussfeld Herkunft Manuelle Erfassung Beschreibung Firmenbezeichnung des registrierten Anwenders. Weiterverwendung Dieses Feld wird bei Firmenkunden im "AboutDialog" angezeigt. Zusätzlich wird es auf dem Registrierungsanschreiben mit ausgegeben. Die Felder Herkunft und Weiterverwendung helfen in diesem Falle die Zusammenhänge innerhalb der Applikation auf der kleinsten Ebene darzustellen. Auf diese Weise kann schrittweise eine Anwendung nachdokumentiert werden. Stand: 14.05.2016 Version 0.93 Seite -32- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.3.7 Beispiel Nachfolgend finden Sie ein vollständig ausformuliertes Beispiel in der Variante "klein": Registrierung Nach Aufruf des Menüpunktes Registrierung erscheint der folgende Dialog Anschrift. Er stellt den Beginn des Registrierungsassistenten dar, der den Anwender durch den gesamten Prozess der Registrierung leitet. Checkboxen Default Firma Selektiert Herr Frau Feld Firma Vorname Name Strasse PLZ Ort Telefon Stand: 14.05.2016 Bemerkung Schaltet bei Auswahl das Feld "Firma" zum Mussfeld. Schaltet bei Auswahl das Feld "Firma" inaktiv. Schaltet bei Auswahl das Feld "Firma" inaktiv Art Bemerkung Mussfeld Firmenbezeichnung des registrierten Anwenders. Dieses Feld wird bei Firmenkunden im "About-Dialog" angezeigt. Mussfeld Vorname des registrierten Anwenders. Dieses Feld wird bei Privatkunden im "About-Dialog" angezeigt. Mussfeld Nachname des registrierten Anwenders. Dieses Feld wird bei Privatkunden im "About-Dialog" angezeigt. Mussfeld Strasse des registrierten Anwenders. Mussfeld Plz des registrierten Anwenders. Mussfeld Ort des registrierten Anwenders. Kannfeld Sollte in der vorherigen Maske die Lieferung per "Telefon" Version 0.93 Seite -33- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Feld Fax Email Button < Zurück Weiter > Abbrechen Stand: 14.05.2016 Art Bemerkung gewünscht werden, so wird aus diesem Feld ein Mussfeld. Kannfeld Sollte in der vorherigen Maske die Lieferung per "Fax" gewünscht werden, so wird aus diesem Feld ein Mussfeld. Kannfeld Sollte in der vorherigen Maske die Lieferung per "Email" gewünscht werden, so wird aus diesem Feld ein Mussfeld. Aktiv Nein Nein Ja Bemerkung In dieser ersten Maske deaktiviert. Springt in die Maske " Nutzernamen für Mehrbenutzerlizenzen" Der Button wir erst dann aktiv, wenn alle Mussfelder ausgefüllt worden sind. Bricht den gesamten Vorgang ohne Speicherung von Informationen nach folgender Meldung ab: "Möchten Sie den Assistenten abbrechen?" Ja = Abbruch der Verarbeitung Nein = Rücksprung in die letzte Maske Version 0.93 Seite -34- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.4 Vorgänge Hierarchische Dokumentation von Objekten Worum geht es? Der Vorgang ist für die Beschreibung programminterner Verarbeitungen vorgesehen. Hierunter fällt alles das, was innerhalb einer Anwendung passiert, wenn bestimmte Aktionen ausgeführt werden. Jeder Vorgang hat einen Anfang und ein Ende. Zwischen diesen Punkten gibt es verschiedene Verarbeitungsschritte. In Anlehnung an das EVA-Prinzip könnte der Vorgang auch als Verarbeitung bezeichnet werden. Ziel der Beschreibung von Vorgängen ist es, der Fachabteilung relevante programminterne Verfahren nahe zu bringen. Optimal ist solch eine Beschreibung dann, wenn die Darstellung eines relevanten Vorgangs alle für die Fachabteilung notwendigen Informationen auch ohne tiefere EDV-Kenntnisse liefert. Zudem sollte die Beschreibung des Vorgangs auch als Ausgangspunkt für die Programmierung bei der Erstellung des technischen Konzeptes dienen. Was bringt es? Diese Vorgehensweise hat den Vorteil, dass zum einen die Fachabteilung programminterne Vorgänge qualifiziert bewerten kann. Zum anderen kann die Programmierung direkt auf diesen Informationen aufsetzen. Sie kann dann die vorliegenden Informationen im technischen Konzept weiterverwenden. Vorgänge können entweder in textueller Form und/oder mit Hilfe von Grafiken beschrieben werden. Bei beiden Vorgehensweisen sollte jeder relevante Schritt separat ausgewiesen werden. Die Zerlegung eines Vorgangs in mehrere Verarbeitungsschritte macht nur Sinn, wenn dadurch zusätzliche Informationen gewonnen werden können. Als relevant sind hierbei alle Schritte zu sehen, die die jeweilige Zielgruppe für das Verständnis des Vorgangs benötigt. Stand: 14.05.2016 Version 0.93 Seite -35- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.4.1 Textuelle Beschreibung von Vorgängen Wie wird es gemacht? Wenn ein Vorgang beschrieben wird, beginnt man mit einem einleitenden Satz. Er hilft innerhalb des Pflichtenheftes festzustellen, von wo der Vorgang aufgerufen bzw. wo er ausgelöst worden ist. Der Kontext ist so einfacher ersichtlich. Der einleitende Satz ist hierbei als Minimalanforderung an den Einstieg in eine Vorgangsbeschreibung zu sehen. Wenn zusätzliche Erklärungen sinnvoll sind, sollten Sie hier an dieser Stelle gemacht werden. Der einleitende Satz könnte lauten: "Nach Aufruf des Menüpunktes <Menüpunkt> / der Funktion <Funktion > wird der folgende Vorgang <Name des Vorgangs> abgearbeitet: Beispiel: Durchführen der Preisermittlung bei der Auftragserfassung Währung feststellen Im Auftragskopf kann pro Auftrag individuell eine Währung hinterlegt werden. Voreingestellt ist die Währung aus dem Kundenstamm. Zur Ermittlung der korrekten Preisliste wird die Währung aus dem Auftragskopf herangezogen. Preisliste feststellen Im Kundenstamm sind die Preislisten des Kunden hinterlegt. Für den aktuellen Zeitraum wird die gültige Preisliste unter Berücksichtigung des Währungskennzeichens ermittelt. Preisliste konnte nicht ermittelt werden In diesem Falle werden bei den Artikeln keine Preise vorgeblendet. Sie müssen manuell erfasst werden. Ende der Preisermittlung (Manuelle Preise) Preisliste konnte ermittelt werden Abhängig von der erfassten Menge wird der Preis aus der Preisliste vorgeblendet. Bei Einzelbestellung greift der Stückpreis. Bei Bestellungen von mehr als einem Stück wird die Mengenstaffel bei der Preisermittlung berücksichtigt. Ende der Preisermittlung (Preise gemäß Preisliste) Die Struktur der Auflistung zeigt, dass es eine Überschrift und eine kurze Beschreibung gibt. Diese Struktur erlaubt es, sich schnell in den jeweiligen Schritten der Verarbeitung zurecht zu finden. Werden keine Überschriften gemacht, muss man erst den gesamten Text lesen, bis man das Richtige gefunden hat. Sollten die Verarbeitungsschritte des Vorgangs nur aus Überschriften bestehen, fällt es u. U. schwer nach einer gewissen Zeit den Gesamtumfang bzw. den Inhalt des Vorgangs zu erkennen. Aus diesem Grunde sollte die Darstellung der Verarbeitungsschritte immer aus beiden Elementen bestehen. Nutzen Sie zur besseren visuellen Abgrenzung der einzelnen Überschriften Aufzählungszeichen. Stand: 14.05.2016 Version 0.93 Seite -36- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Bei der Textdarstellung von Vorgängen mit Abfragen sollten die zusammengehörigen Schritte einer Abfrage auf einer Ebene zusammengefasst werden. Beispiel: Start Verarbeitungsschritt 1 Verarbeitungsschritt 1a Verarbeitungsschritt 1b Verarbeitungsschritt 2 Abfrage 1 Verarbeitungsschritt 3 Ende Verarbeitungsschritt 4 Verarbeitungsschritt 5 Ende Die Darstellung der Gliederung zeigt, dass die rein textuelle Darstellung nur bedingt geeignet ist, komplexe Vorgänge zu beschreiben. Ein Bild sagt in diesen Fällen doch mehr als tausend Worte. Stand: 14.05.2016 Version 0.93 Seite -37- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.4.2 Die grafische Darstellung von Vorgängen Wie wird es gemacht? Für die grafische Darstellung von Vorgängen möchten wir eine einfache und effektive Form der Visualisierung vorstellen. Sie lehnt sich in Teilen an DIN 66001 an (Richtlinien zur Gestaltung von Programmablaufplänen). In ihrer Notation ist sie jedoch wesentlich reduziert und an einigen Stellen modifiziert worden. Mit diesen Änderungen soll erreicht werden, dass eine Überprüfung der Arbeitsergebnisse auch ohne tiefere EDV-Kenntnisse möglich wird. Die Darstellung eines Vorgangs ist so gewählt, dass der gesamte Vorgang einen definierten Anfang und ein definiertes Ende hat. Die Elemente sind in ihrer Darstellung einheitlich gehalten. Es wurde bewusst auf allen grafischen Schnickschnack verzichtet. Auf dieser Weise ist es ohne Probleme möglich, bei einer Besprechung z. B. an einem Flipchart die gleiche Art und Weise der Darstellung zu wählen. Das vergrößert bei der Arbeit mit der Fachabteilung den Wiedererkennungswert. Bei Präsentationen vor Geschäftsleitung o. ä. können die Arbeitsergebnisse immer noch nachgebessert werden. Unser Vorschlag: Start Verarbeitungsschritt JA/Nein Nein Verzweigung Ja Alternativpfad Alternative 1 Alternative 2 Alternative 3 Ende Start von Vorgängen Ein Vorgang beginnt immer mit einem deutlich sichtbaren Startpunkt. Auf dieser Weise wird sichergestellt, dass jeder Leser des Pflichtenheftes bei der richtigen Stelle beginnt, den Vorgang nachzuvollziehen. Stand: 14.05.2016 Version 0.93 Seite -38- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Ende von Vorgängen Beendet wird ein Vorgang immer mit einem deutlich erkennbaren Endpunkt. Die Darstellung von Anfang und Ende von Vorgängen sind wichtig, um den Umfang eines Vorgangs genau abzubilden. (Wo fängt was an? / Wo hört was auf?) Es gibt zwei Möglichkeiten, die Definition der Anfangs- und Endpunkte von Vorgängen durchzuführen. Zum einen könnten bestimmte Aktionen bzw. bestimmte Ergebnisse als Anfang und Ende von Vorgängen definiert werden. Zum anderen können Anfang und Ende innerhalb eines Vorgangs durch eigenständige Symbole dargestellt werden. Wir empfehlen die zweite Möglichkeit zur Darstellung der Vorgänge. Die separate Darstellung von Anfang und Ende ist u. E. leichter zu verstehen. Verarbeitungsschritte Jeder einzelne Verarbeitungsschritt innerhalb eines Vorgangs sollte separat visualisiert werden. Die Art der Detaillierung hängt davon ab, wem der Vorgang verdeutlicht werden soll. Hierbei ist jedoch folgendes zu beachten: Eine sehr detaillierte Darstellung von Vorgängen muss sich rechnen! Die Fachabteilung sollte nur mit den für sie notwendigen Informationen versorgt werden. Die Form der Darstellung stellt immer einen Kompromiss zwischen der Genauigkeit und dem dafür notwendigen Arbeitsaufwand dar. Bei der Beschreibung von Vorgängen sollte nur darauf geachtet werden, dass sachlich unterschiedliche Aktionen in separaten Verarbeitungsschritten dargestellt werden. Ja/Nein Verzweigung Bei Ja/Nein Abfragen sollte immer versucht werden, eine einheitliche Struktur einzuhalten. Das erleichtert den Lesefluss. Wir verwenden immer folgende Struktur: Abfrage? [Nein] [Ja] Die [Ja]-Ausgänge gehen immer senkrecht aus der Abfrage heraus. Die [Nein]-Ausgänge immer seitlich. Damit diese Struktur eingehalten werden kann muss die Fragestellung so gewählt werden, dass eine eindeutige Artwort auf die Ja/Nein-Abfrage gegeben werden kann. Unbedingt sollten doppelte Verneinungen in der Ja/Nein-Abfrage vermieden werden. (z. B. Prüfung nicht durchführen Ja/Nein ???) Stand: 14.05.2016 Version 0.93 Seite -39- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Alternativpfade Alternativpfade stellen eine Erweiterung von Ja/Nein-Abfragen dar. Während bei Ja/NeinAbfragen nur zwei definitive Antworten erhalten werden, sind bei Alternativpfaden mehrere Antworten möglich. Diese Form der Darstellung bietet sich immer dann an, wenn Ja/NeinAbfragen die Struktur des Vorgangs unnötig aufblähen würden. Diagramtitel Beispiel: Farbe der Ampel? rot. gelb. grün. Versuchen Sie bei der Beschreibung von Vorgängen nicht die Funktionen von WinWord zu nutzen! Das sieht nur auf den ersten Blick ähnlich wie die hier aufgeführten Beispiele aus. Jedoch ist es z. B. bei WinWord recht schwierig, die Pfeile bei nachträglichen Änderungen von Abläufen wieder genau an die richtigen Stellen zu positionieren. Spezielle Tools wie z. B. der Flowcharter bieten hierzu vielfältige Hilfestellungen. Damit ist eine effektive und schnelle Änderungen ohne großen manuellen Aufwand möglich. Nutzen Sie daher zur grafischen Darstellung von Vorgängen die Tools der Spezialisten! Eine kleine Auswahl finden Sie auf bei dem Kapitel 7.5 Welche Tools sollen genutzt werden? Seite: -112- 3.4.3 Beschriftung der Elemente Wie wird es gemacht? Für die Beschriftung der grafischen Elemente von Vorgängen gibt es mehrere Möglichkeiten: a) b) Innerhalb der Elemente Bei wenig umfangreichen Beschreibungen ist es sinnvoll den Text innerhalb der Elemente unterzubringen. Sollte mehr Text notwendig sein, als die Elemente aufnehmen können, so muss die Größe der Elemente angepasst werden. Dies kann u. U. die Lesbarkeit des Diagramms nachteilig beeinflussen. Unterhalb der Elemente Unterhalb der Elemente kann nur ein kurzer Text erfasst werden. Hier ergibt sich zudem der Nachteil, dass viele Flowcharter die Verbindungslinien durch den Text zeichnen und damit die Lesbarkeit des Diagramms nachteilig beeinflussen. Stand: 14.05.2016 Version 0.93 Seite -40- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Beispiel: hier steht ein kurzer Text c) Verweise Bei der Dokumentation von Vorgängen mit Hilfe von Verweisen wird in den Ablaufplan kein Text zu den Symbolen geschrieben. Statt dessen bekommt jedes Element eine Nummer. Auf diese Nummer wird in einer nebenstehenden Tabelle verwiesen. Dort wird dann die Erklärung der einzelnen Symbole niedergelegt. Beispiel: Start 1: Verarbeitungsschritt 1 2: Abfrage 1 3: Verarbeitungsschritt 2 4: Verarbeitungsschritt 4 1 2 3 4 Ende Mit Hilfe dieser Methode ist es möglich, sehr kleine Symbole zu nutzen. Somit können viele Informationen auf einer Seite untergebracht werden. Bei komplexen Abläufen kann diese Form der Visualisierung eingesetzt werden, um zu Beginn einen Überblick über die Anzahl der Verarbeitungsschritte zu bekommen. Für die Präsentation bei der Fachabteilung ist diese Darstellungsform u. E. allerdings nicht geeignet. Stand: 14.05.2016 Version 0.93 Seite -41- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.4.4 Die maximale Anzahl von Elementen festlegen Wie wird es gemacht? Wie auch bei vielen anderen Bereichen gilt hier die 7+2 Regel. Wenn mehr als 9 Elemente in einem Vorgang vorkommen, sollte versucht werden, Verarbeitungsschritte in separate Grafiken auszulagern. Zur Unterscheidung innerhalb des Vorgangs sollte für zusammengefasste Verarbeitungsschritte ein separates Symbol gewählt werden. So kann einfach zwischen Einzelschritten und Zusammenfassungen unterschieden werden. Beispiel: In dieser Grafik wird schematisch verdeutlicht, wie die Auslagerung von Teilvorgängen hilft, den Gesamtüberblick über den Vorgang zu behalten. Die nachfolgende Grafik stellt zwar alles auf einen Blick dar, jedoch macht die Fülle der einzelnen Symbole die Übersicht recht schwer. So sollte ein Vorgang nicht visualisiert werden! Stand: 14.05.2016 Version 0.93 Seite -42- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.4.5 Komplexe Vorgänge darstellen Wie wird es gemacht? Es kommt immer wieder vor, dass ein Vorgang so viele Einzelschritte enthält, dass die Vielzahl der Einzelschritte einen Gesamtüberblick verwehren. In diesem Fall muss vor der detaillierten Darstellung der einzelnen Verarbeitungsschritte eine Blockbildung vorgenommen werden. Diese Blöcke werden mit der folgenden Fragestellung gebildet: Aus welchen groben Teilschritten besteht der Vorgang? Diese "Besteht-aus-Beziehung" hilft, komplexe Vorgänge in überschaubare Blöcke zu unterteilen. Die richtige Anzahl der Blöcke ist dann erreicht, wenn ihre Anzahl eine Handvoll nicht überschreitet. Dieser Fall tritt immer dann auf, wenn umfangreiche Hintergrundarbeiten durchgeführt werden. (z. B. Bestandsprüfungen in einem Lager) Beispiel: Die Prüfungen innerhalb der Auftragserfassung bestehen aus: Preisermittlung Bestandsprüfung Bonitätsprüfung Diese Untergliederung der Prüfungen in der Auftragserfassung ermöglicht folgende Gliederung: 1. Prüfungen Auftragserfassung 1.1 Preisermittlung 1.2 Bestandsprüfung 1.3 Bonitätsprüfung Auf diese Art und Weise erhält man eine Hierarchie von Verarbeitungen, die in sich geschlossene Einheiten bilden. Diese "Besteht-aus-Strukturen" können auch grafisch dargestellt werden. Diagramtitel Unser Vorschlag: Prüf ungen Auf tragserf assung Preisermittlung Bestandsprüfung Bonitätsprüfung Die Blöcke dieser Struktur können jetzt einzeln beschrieben werden. Das erhöht den Überblick und lässt bei Veränderungen eine einfachere Pflege zu. Stand: 14.05.2016 Version 0.93 Seite -43- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Eine andere Möglichkeit ist die Blockdarstellung im Ablauf. Die hierarchische Darstellung von Verarbeitungsblöcken kann lediglich eine "Besteht-aus-Beziehung" abbilden. Die Blockdarstellung im Ablauf bietet die Möglichkeit, zusätzliche Abhängigkeiten und Verknüpfungen darzustellen. Stand: 14.05.2016 Version 0.93 Seite -44- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.5 Ereignisse Hierarchische Dokumentation von Objekten Worum geht es? Ein Ereignis nimmt bei der Beschreibung von Programmfunktionalitäten eine Sonderstellung ein. Während z. B. Menüs und Dialoge direkt im Zusammenhang mit der Funktionalität innerhalb eines Programms stehen, beschreibt ein Ereignis Einflüsse, die von außen auf die Anwendung einwirken, um danach eine Reaktion innerhalb dieser Anwendung hervorzurufen. Dies können z. B. Nachrichten sein, die von einem Kommunikationsprogramm an die Anwendung geschickt werden. Ein Ereignis ist nicht mit der Definition von Ereignis zu verwechseln, wie sie bei der objektorientierten Programmierung verwendet wird. Aus der Sicht eines Programmierers ist es ein Ereignis, wenn eine bestimmte Aktion innerhalb seiner Anwendung ausgeführt wird. Für den, der die Funktionalitäten einer Anwendung beschreibt, ist das nichts anderes als die Auswahl von vorher zur Verfügung gestellten Möglichkeiten. Auch ist das Ereignis nicht mit Ereignissen zu verwechseln, die von der Anwendung selbst hervorgerufen werden (z. B. während des Speicherns stellt das Programm fest, dass der Speicherplatz erschöpft ist.) Bei der Beschreibung eines Ereignisses wird nur das Ereignis selber, nicht jedoch die daraus resultierenden Ergebnisse beschrieben. Die aus dem Ereignis folgenden Ergebnisse werden wieder separat Objekten zugeordnet und damit auch separat dokumentiert. Was bringt es? Moderne Anwendungen haben immer mehr aktive Schnittstellen, die von außen angesteuert werden. Mit Hilfe von Ereignissen können so alle Möglichkeiten definiert werden, die von außen auf die Anwendung einwirken. Damit besteht die Gelegenheit, alle Schnittstellen zu identifizieren, die einen Automatismus innerhalb der Anwendung in Gang setzen. Wie wird es gemacht? Ereignisse setzen immer dann Automatismen innerhalb einer Anwendung in Gang, wenn die Anwendung selbst einen permanent verfügbaren Mechanismus zur Verfügung stellt, der auf das Eintreffen eines Ereignisses wartet. Dies können z. B. Hintergrundprogramme oder Jobs sein, die Reaktionen innerhalb des Systems hervorrufen. Die nachfolgende Grafik verdeutlicht dies. Stand: 14.05.2016 Version 0.93 Seite -45- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Hier wird ersichtlich, dass ein Ereignis niemals losgelöst innerhalb einer Anwendung beschrieben werden kann. Das Ereignis ist immer mit dem überwachenden Mechanismus im Zielsystem verknüpft. Zur Beschreibung dieser Funktionalitäten ergibt sich innerhalb des Pflichtenheftes daraus folgende Hierarchie: 1. Überwachungsprogramm (permanent verfügbarer Mechanismus) 1.1 Ereignis 1.1.1. Reaktion (Ergebnis) Das Überwachungsprogramm stellt Methoden zur Verfügung, auf bestimmte Ereignisse zu reagieren (1). Tritt das Ereignis ein (1.1), werden Reaktionen (1.1.1) innerhalb der Anwendung erzeugt. Beispiel 1: prüfe auf eingehende Nachrichten Hintergrundprogramm (z. B. von Typ "Vorgang") Nachricht wird von externen email-Client verschickt Ereignis Die neue Mail wird automatisch angezeigt. Stand: 14.05.2016 Version 0.93 Ergebnis (z. B. vom Typ "Dialog") Seite -46- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Beispiel 2: prüfe auf eingehende Dateien Hintergrundprogramm (z. B. von Typ "Vorgang") Eine Datei wird von einem EDIFAKTKonverter gesendet Ereignis Die Datei wird gelesen und weiterverarbeitet Ergebnis & neue Aktion (z. B. vom Typ "Vorgang") Neue Datei wird erstellt Ergebnis (z. B. vom Typ "Datei") Informationen zu den Übertragungsdaten werden angezeigt. Ergebnis (z. B. vom Typ "Dialog") Für die Beschreibung eines Ereignisses sollten Antworten auf folgende Fragen gefunden werden: Wie heißt das Ereignis? Wer ist der Auslöser des Ereignisses? Was ist die Quelle des Ereignisses? Wer ist das Ziel des Ereignisses? Welcher Art ist das Ereignis (Datei, Nachricht usw.)? Wie oft wird das Ereignis ausgelöst (Frequenz)? Die obige Liste ist als Minimalanforderung zu sehen, die jedes Ereignis als Beschreibung haben sollte. Wenn zusätzliche Erklärungen sinnvoll sind, sollten Sie hier an dieser Stelle gemacht werden. Erläuterungen zum generellen Ablauf sollten jedoch nicht hier niedergelegt werden. Diese Informationen gehören zur Beschreibung des überwachenden Mechanismus. Dort könnte z. B. die grafische Darstellung des generellen Ablaufs der Kommunikation dargestellt werden. Als Visualisierungsmöglichkeit einer solchen Kommunikation bietet sich eine Systematik an, wie sie die oberste Grafik zeigt. Unser Vorschlag: Auslöser Art * Stand: 14.05.2016 Quelle Ziel Häufigkeit Version 0.93 Seite -47- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Auslöser Hier wird derjenige erfasst, der das Ereignis auslöst. Die kann z. B. ein Mensch sein. Es gibt jedoch auch Ereignisse, die von anderen Systemen z. B. zeitgesteuert angestoßen werden. Quelle Die Quelle bezeichnet den Ursprung des Ereignisses. Wie genau die Quelle spezifiziert werden muss, hängt von der Anwendung bzw. der Zielgruppe des Pflichtenheftes ab. Ziel Das Zielsystem, für das das Ereignis bestimmt ist. Hier muss jeweils individuell geprüft werden, wie genau das Ziel beschrieben wird. Die Nennung des Zielsystems alleine kann u. U. nicht ausreichen, wenn das Ereignis z. B. eine Datei ist, die in einem bestimmten Verzeichnis auf dem Zielsystem abgelegt werden muss. Art Ein Ereignis kann auf unterschiedlichste Arten auf das Zielsystem einwirken. So können Ereignisse z. B. in Form von Nachrichten an das Zielsystem geschickt werden. Sollte die Art des Ereignisses z. B. eine Datei sein, bietet es sich an, diese Datei mit dem Objekt Datei zu beschreiben. Häufigkeit Die Häufigkeit gibt Aufschluss darüber, ob der überwachende Mechanismus permanent verfügbar sein muss. Sollte z. B. ein Ereignis nur während des Tagesabschluss erwartet werden, muss der überwachende Mechanismus nicht ganztägig verfügbar sein. Beispiel für die Beschreibung eines Ereignisses: EDIFAKT Nachrichten verarbeiten (NewOrder) Auslöser Quelle Ziel Ein Mitarbeiter im Rechenzen- EDIFAKT-Konverter Warenwirtschaftssystem trum löst manuell die Übertragung der Daten aus. Art Häufigkeit EDIFAKT-Datei vom Typ XYZ Täglich (in unregelmäßigen Abständen) Stand: 14.05.2016 Version 0.93 Seite -48- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.6 Ausgabeobjekte Hierarchische Dokumentation von Objekten Worum geht es? Jede Anwendung, die Daten in Form von Belegen herausgibt, kann diese Belege mit Hilfe des Objektes Ausgabe beschreiben. Das Objekt Ausgabe ist zur Beschreibung von Listen und Formularen vorgesehen. Hierbei beschränkt sich die Ausgabe nicht alleine auf Text. Neben der textuellen Ausgabe können hier auch Grafiken beschrieben werden. Außer der Ausgabe von Belegen kann eine Anwendung natürlich noch Ausgaben in Form von Filmen und Tönen ermöglichen. Die Pflichtenhefterstellung erfolgt jedoch zumeist in Form von Textdokumenten. Durch die Unterstützung von OLE ist es natürlich möglich, solche Elemente mit in die Beschreibung aufzunehmen. Allerdings wird es in diesen Fällen mit dem Ausdruck etwas schwierig. Damit die Möglichkeit besteht, alle Ausgabemöglichkeiten einer Software unter einem einheitlichen Begriff zu beschreiben, werden alle Ausgaben global als Ausgabeobjekte bezeichnet. Speziell bei den Anforderungen an den Aufbau und den Informationsgehalt der Ausgabeobjekte herrscht bei den Anwendern vielfach die Meinung vor, dass ein Beleg „unendlich“ viele Informationen aufnehmen kann. Diese Erkenntnis ist um so ärgerlicher, wenn erst bei der Programmierung festgestellt wird, dass der Beleg nicht in der angedachten Form umgesetzt werden kann. Als Grund für solch eine Situation ist zumeist das fehlende Design während der Pflichtenhefterstellung anzuführen. Vielfach werden als Realisierungsinformation nur die Felder aufgeschrieben, die der Beleg enthalten soll. (Alles andere soll sich dann schon während der Programmierung von selber regeln....) Für eine kostengünstige Realisierung von Ausgabeobjekten ist das Design der Belege bei der Erstellung des Pflichtenheftes unerlässlich! Die einfachste Möglichkeit, das Design eines Ausgabeobjektes zu prüfen, ist die Erstellung einer 1:1 Abbildung. Als Werkzeug für diese Aufgabe hat WinWord in der Vergangenheit gute Dienste geleistet. Zentrales Kriterium für das erfolgreiche Design von Belegen ist die Beantwortung folgender Frage: „Können alle gewünschten Informationen in der vorgesehenen Form auf dem Beleg ausgegeben werden?“ Wie die Datei wird auch das Ausgabeobjekt als Endpunkt einer Funktion bzw. eines Ablaufs angesehen. Aus diesem Grunde kann das Ausgabeobjekt auch keine untergeordneten Objekte haben. Für die Beschreibung im Pflichtenheft bedeute dies, dass es unter dem Kapitel zur Beschreibung eines Ausgabebeleges keine weiteren Kapitel geben kann, die mit dem Ablauf des Programms zu tun haben. (Die genaue Erläuterung dieser Sichtweise finden Sie im Handbuch von HDvO) Stand: 14.05.2016 Version 0.93 Seite -49- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Was bringt es? Die meisten Softwaresysteme produzieren Belege in der einen oder anderen Form. Aus diesem Grunde ist es notwendig, Inhalt und Aufbau dieser Belege vollständig zu beschreiben. Erst mit der vollständigen Beschreibung aller von der Software getätigten Ausgaben ist das Pflichtenheft komplett. Zudem wird beim Design von Belegen schnell festgestellt, ob sich die gewünschten Informationen in der gewünschten Form auf dem jeweiligen Beleg unterbringen lassen. Sollte das Design der Belege unterlassen werden, kann der Fall auftreten, dass die später produzierte Form in Gestaltung und Informationsgehalt nicht die gewünschten Ergebnisse liefert. In vielen Fällen wird erst mit der Erstellung des Beleges festgestellt, welche Informationen insgesamt auf dem Beleg ausgegeben werden müssen. Damit dieser Effekt erzielt wird, sollte der zukünftig vom System erstellte Beleg dem Originalbeleg so nahe wie möglich kommen. Beim Design von Belegen gilt folgende Regel: Kosten sparen – Standards nutzen! Dieser Grundsatz lässt sich auch auf alle anderen Bereiche bei der Softwareentwicklung anwenden. Doch gerade bei diesem Thema gibt es ein großes Einsparungspotential, wenn hier auf unnötige Individualität beim Drucklayout verzichtet wird. Gerade Belege, die das Unternehmen verlassen, sollten ein einheitliches Erscheinungsbild vorweisen. Aus diesem Grunde sollte die Gestaltung dieser Belege auch nicht an die Entwicklung delegiert werden. Wie bei der Diskussion um die Abbildung eines Dialoges in einem Pflichtenheft sind wir auch bei der Beschreibung der Ausgabebelege der Meinung, dass die Abbildung des Belegs in einem Pflichtenheft unverzichtbar ist. Neben der Möglichkeit, über Belegdesigner oder Grafikprogramme einen Ausgabebeleg darzustellen, besteht auch die Möglichkeit, bereits existierende oder extern erstellte Ausgabebelege einzuscannen. Grundsätzlich gilt, je exakter die Darstellung der Belege im Pflichtenheft den zukünftigen Ausgaben entsprechen, desto geringer werden Diskussionen über evtl. Nacharbeiten sein. Die Beschreibung eines Beleges teilt sich immer in zwei Teile. Der Abbildung des Beleges und der Feld- und Layoutbeschreibung. Sollte das Abbild des Beleges eingescannt sein, achten Sie darauf, das durch eine zu hoch gewählte Farbtiefe die Dokumentation nicht über Gebühr aufgebläht wird. Wie bei der Beschreibung von Dialogen ist die Systematik der Beschreibung im Bereich der Feld- und Layoutbeschreibungen von Ausgabebelegen unabhängig von der Art der Anwendung und dem zugrundeliegenden Betriebssystem zu sehen. D. h. für die Beschreibung von Belegen muss keine betriebssystemspezifische Form der Beschreibung erstellt werden. Wenn ein Ausgabeobjekt beschrieben wird, beginnt man mit einem einleitenden Satz. Es hilft innerhalb des Pflichtenheftes festzustellen, von wo das Ausgabeobjekt aufgerufen worden ist. Der Kontext ist so einfacher ersichtlich. Der einleitende Satz ist hierbei als Minimalanforderung an den Einstieg in eine Beschreibung zu sehen. Wenn zusätzliche Erklärungen sinnvoll sind, sollten Sie hier an dieser Stelle gemacht werden. Stand: 14.05.2016 Version 0.93 Seite -50- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Der einleitende Satz könnte lauten: "Nach Aufruf des Menüpunktes <Menüpunkt> wird die <Name des Ausgabeobjektes> ausgedruckt.“ Bei Listen, die automatisch z. B. im Tagesabschluss gedruckt werden könnte der Satz lauten: "Im Tagesabschluss wird die nachfolgende <Name der Ausgabeobjektes> ausgedruckt.“ 3.6.1 Verschiedene Bereiche in Ausgabeobjekten Worum geht es? Zur vollständigen Beschreibung eines Ausgabeobjektes sollten auch die Layoutinformationen mit aufgeführt werden. Im Bereich der Textverarbeitung ist es üblich, eine Seiteneinrichtung zur optimalen Ausnutzung des zur Verfügung stehenden Raumes vorzunehmen. Bei der Beschreibung von Belegen werden diese Maße leicht vergessen. Wie wird es gemacht? Unser Vorschlag: Ränder in cm Oben Unten Rechts Links Oben Abstand zwischen oberem Seitenrand und dem ersten Text. Unten Abstand zwischen unterem Seitenrand und dem letzten Text. rechts Abstand zwischen rechten Seitenrand und dem Text. Links Abstand zwischen linken Seitenrand und dem Text. Informationen wie DIN-Größe sowie Hoch- oder Querdruck können weg gelassen werden, wenn diese Informationen aus dem Layout hervorgehen. 3.6.2 Verschiedene Arten von Feldern in Ausgabeobjekten Wie wird es gemacht? Auf den unterschiedlichen Ausgabeobjekten gibt es verschiedene Arten von Feldern, die von unterschiedlicher Herkunft sind. Für eine ausreichende Beschreibung ist es sinnvoll, zwischen den verschiedenen Wegen der Herkunft der Daten zu unterscheiden. Innerhalb von HDvO sind dazu drei Arten Feldinformationen definiert worden: automatische Felder (Z. B. Datum/Seiten-Nr.) Diese Felder werden nicht abgespeichert. Sie haben lediglich die Aufgabe organisatorische Informationen zu liefern. Datenfelder (z. B. Kunden-Nr./Name) Als Datenfelder werden die Felder bezeichnet, die aus gespeicherten Daten heraus ausgegeben werden. Stand: 14.05.2016 Version 0.93 Seite -51- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Rechenfelder (z. B. Summe=Menge*Preis) Rechenfelder sind Felder, die aus vorhandenen Informationen (Daten- und/oder automatischen Feldern) berechnet werden. Ein Rechenfeld kann in den Daten abgespeichert oder wie ein automatisches Feld zur Laufzeit errechnet werden. Ziel des Rechenfelds ist es, aus vorhandenen Informationen neue zu generieren. Grafik (z. B. Firmenlogo) Grafiken werden zumeist als Datei der Entwicklung zur Verfügung gestellt. Sollte dies nicht der Fall sein, besteht zudem die Möglichkeit, die Grafik als Druckermakro für einen Ausdruck bereitzustellen. In beiden Fällen ist eine genauere Beschreibung der Grafik nicht notwendig. Alle notwendigen Informationen enthält die Grafik selber. Diese Klassifizierung der Felder hilft: a) Dem Autor des Pflichtenheftes Er kann bei der Fertigstellung der Beschreibungen die einzelnen Felder überprüfen. (z. B. sollten Rechenfelder immer eine Formel enthalten.) b) Dem Anwender Der Anwender hat mit Hilfe dieser Informationen die Möglichkeit, den Inhalt und die Herkunft der Felder in den Ausgabeobjekten umfassender zu prüfen. (z. B. woher werden die einzelnen Felder herangezogen?) c) Dem Entwickler Die Klassifizierung der Felder hilft dem Entwickler bei der Umsetzung des technischen Konzeptes. (z. B. welche Formel für welches Feld verwandt wird.) 3.6.3 Die Darstellung von Feldern Worum geht es? Beim Design von Ausgabeobjekten ist es sinnvoll, einen genauen Überblick darüber zu erhalten, ob die gewünschten Informationen auch darstellbar sind. In der Praxis stellt sich nämlich immer wieder heraus, dass sich alle geforderten Informationen nicht in der gewünschten Form darstellen lassen. Hierzu ist es notwendig, alle Felder neben ihrer evtl. vorhandenen Beschreibung auch in ihrer maximalen Länge auf dem Ausgabeobjekt darzustellen. Dies verhindert, dass z. B. bei einer Liste zu viele Felder nebeneinander gepackt werden. Wie wird es gemacht? Für die korrekte Darstellung der Felder sollten Platzhalter genutzt werden. Diese Platzhalter haben die Aufgabe, den maximal benötigten Raum der Felder auf dem Ausgabeobjekt darzustellen. Für die unterschiedlichen Feldarten können verschiedene Arten von Platzhaltern genutzt werden. Unser Vorschlag: Numerische Felder: Alphanumerische Felder: Datumsfelder: Uhrzeiten: Fortlaufende Felder: Stand: 14.05.2016 66666666606666666660 XXXXXXXXXOXXXXXXXXXO TT.MM.JJJJ HH:MM:SS N Version 0.93 Seite -52- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Die obige Liste stellt alle für einen Ausdruck benötigen Felder dar. Zur Erleichterung für den Anwender und die Entwicklung ist alle 10 Zeichen ein Trennungszeichen dargestellt. Auf diese Art und Weise kann speziell bei längeren Feldern die Feldlänge schnell ermittelt werden, ohne dass man mühselig erst jedes einzelne Zeichen zählen muss. Sicherlich kann diese Darstellung noch wesentlich ausgefeilt werden, jedoch hat die Praxis gezeigt, dass diese Form der Darstellung völlig ausreicht. Felder ohne Feldbeschreibung Bei den meisten Ausgabeobjekten kommt es vor, dass bei einigen Feldern nur der Feldinhalt und nicht die Feldbeschreibung im Layout ausgegeben wird. Die ist z. B. fast immer bei Adressen so. Für diesen Fall hilft bei der Feldbeschreibung die abstrakte Darstellung der Feldlänge im Beleg nur unzureichend weiter. Alternativ kann daher innerhalb der Feldlänge der Name des Feldes mit ausgegeben werden. Beispiel: NAME1XXXXOXXXXXXXXXO NAME2XXXXOXXXXXXXXXO STRASSEXXOXXXXXXXXXO PLZ6666660 ORTXXXXXXOXXXXXXXXXOXXXXX In diesem Fall wird der Feldname mit zum Teil der Feldlängendarstellung! Sonst kann die eigentliche Feldlänge nicht mehr richtig dargestellt werden. Kleine Felder ohne Feldbeschreibung Sollte die im Ausgabebeleg dargestellte Feldlänge kürzer sein als die Feldbeschreibung kann ein Verweis im Beleg gemacht werden. Beispiel: 6666(1) (1): Kunden-Artikel-Nummer Proportionale Schriftarten Bei der Verwendung von Textverarbeitungen haben sich proportionale Schriftarten wie z. B. Arial und Times Roman weitgehend durchgesetzt. (Bei diesen Schriften nehmen Buchstaben wie z. B. ein „I“ weniger Platz ein als z. B. ein „X“.) Bei der Gestaltung von Ausgabeobjekten kann die Verwendung von proportionalen Schriftarten böse Überraschungen nach sich ziehen! Dies ist immer dann der Fall, wenn Referenzwerte, anstatt Platzhalter für die Feldlängenbestimmung herangezogen werden. Das nachfolgende Beispiel zeigt deutlich, das ein Referenzwert bei einer proportionalen Schriftart nicht die „echte“ maximale Länge des Feldes wiedergibt. Beispiel: Referenzwert: Platzhalter: Filiale Wiesbaden (17 Zeichen) XXXXXXXXXOXXXXXXX (17 Zeichen) Aus diesem Grunde sollten unbedingt Platzhalter und keine Referenzwerte genutzt werden, wenn in Ausgabeobjekten mit proportionalen Schriftarten gearbeitet wird. Auch bei der Verwendung von Schriftarten mit gleicher Zeichenbreite bieten Platzhalter die bessere Übersicht, wenn es darum geht, dass Layout eines Ausgabeobjektes zu prüfen. Stand: 14.05.2016 Version 0.93 Seite -53- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.6.4 Sortierungen innerhalb von Ausgabeobjekten Wie wird es gemacht? Eine wichtige Information bei der Beschreibung von Ausgabeobjekten ist die Art und Weise der Sortierung. Es gibt zwei Arten von Sortierungen einstufige und mehrstufige. Bei einer einstufigen Sortierung wird das Ausgabeobjekt nur nach einem Kriterium sortiert. Bei mehrstufigen Sortierungen wird nach einem Hauptkriterium sortiert und innerhalb des Hauptkriteriums nach Unterkriterien. Zur vollständigen Beschreibung einer Sortierung muss als zusätzliche Information bei jedem Kriterium mit angegeben werden, ob die Sortierung aufsteigend oder absteigend ist. Unser Vorschlag: Sortierung nach: Art der Sortierung Sortierung nach Hier wird das Feld angegeben, nach dem sortiert werden soll. Art der Sortierung Die Art der Sortierung gibt Auskunft darüber, ob aufsteigend oder absteigend nach dem vorher benannten Feld sortiert wird. Der obige Vorschlag zeigt die Darstellung einer einstufigen Sortierung. In manchen Fällen reicht eine solche Sortierung nicht aus. In diesen Fällen muss eine mehrstufige Sortierung definiert werden. Mehrstufige Sortierungen werden immer dann benötigt, wenn nach der Sortierung nach dem Hauptkriterium weitere Kriterien notwendig sind, um eine aussagekräftige Darstellung der Daten zu erhalten. Beispiel für die Sortierung nach einem einstufigen Kriterium: Sortierung nach: Art der Sortierung Kunden-Nr Aufsteigend Beispiel für die Sortierung nach einem mehrstufigen Kriterium: Sortierung nach: Dann nach Dann nach Art der Sortierung Kunden-Nr aufsteigend Postleitzahl aufsteigend Umsatz absteigend Bei der Definition der Sortierkriterien sollte unbedingt darauf geachtet werden, dass keine Felder als Sortierkriterium definiert werden, die nicht Bestandteil des Ausgabeobjektes sind. Ansonsten ist die Sortierung auf dem Ausgabeobjekt für nicht Eingeweihte nicht nachvollziehbar. Stand: 14.05.2016 Version 0.93 Seite -54- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Gruppenwechsel Bei Ausgabeobjekten, die Zwischensummen aufweisen sollen, muss als Kriterium für die Zwischensumme ein Gruppenwechsel definiert werden. Dies muss ein Feld des Ausgabeobjektes sein, das als Kriterium für die Zwischensumme dient. Unser Vorschlag: Gruppenwechsel Gruppenwechsel Feld, nach dem der Gruppenwechsel durchgeführt wird. Bei der Definition der Gruppenwechsel sollte unbedingt darauf geachtet werden, dass keine Felder als Kriterium für einen Gruppenwechsel definiert werden, die nicht Bestandteil des Ausgabeobjektes sind. Ansonsten sind die Gruppenwechsel auf dem Ausgabeobjekt für nicht Eingeweihte nicht nachvollziehbar. 3.6.5 Listen Worum geht es? Das Thema Listen ist auch im Zeitalter des papierlosen Büros leider immer noch aktuell. Die Anzahl von Ausdrucken hat sich im Laufe unsere Projektarbeit nur unwesentlich vermindert. Die Gründe für solche eine Situation sind vielschichtig und werden hier nicht weiter thematisiert. Der Grundaufbau einer Liste teilt sich grob in zwei Bereiche auf: Kopfinformationen Dort werden Informationen über die Liste wie z. B. der Name und die Seitennummer ausgegeben. Listenteil Der Listenteil bildet den Körper der Liste. Hier werden die inhaltlich relevanten Informationen der Liste ausgegeben. Bereits während der Erstellung eines Pflichtenheftes kann es zu einem Wust an Anforderungen kommen, die dann als Listen realisiert werden sollen. Damit diese Anforderungen etwas kanalisiert werden können, ist es sinnvoll neben dem Namen der Liste auch eine Kurzbeschreibung der Liste vorzunehmen. Inhalt der Kurzbeschreibung ist die Antwort auf die Frage: „Wozu wird diese Liste benötigt?“ Wenn die Fachabteilung den Sinn einer Liste als definieren soll, ist die Gefahr „in Listen zu ertrinken“, etwas geringer Unser Vorschlag: Name der Liste Kurzbeschreibung der Liste Name der Liste Die Bezeichnung, unter dem die Liste bei der Fachabteilung zukünftig geführt wird. Kurzbeschreibung der Liste Kurze Darstellung von Einsatzgebiet und Zweck der Liste. Stand: 14.05.2016 Version 0.93 Seite -55- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Listen mit Deckblättern Verschiedene Listen werden auch heute noch mit einem Deckblatt gedruckt. Die Deckblätter dienen dann als Trennblätter, um die unterschiedlichen Ausdrucke in dem dann erzeugten Papierstapel leichter von einander zu trennen. Diese Ordnungshilfe ist meist dann notwendig, wenn viele Listen nachts im Batch auf einem Drucker ausgedruckt werden. Im Zuge der immer weiter fortschreitenden Tendenz hin zur dezentralen Datenverarbeitung sollte diese Organisationsform immer seltener werden. Da die Deckblätter zumeist automatisch von den jeweiligen Systemen erstellt werden, haben wir an dieser Stelle auf einen Layoutvorschlag verzichtet. Das Ende der Liste Bei einer Liste, die sich über mehr als eine Seite erstreckt, ist es schwierig abzuschätzen, wann die Liste beendet ist. Summen am Ende einer Liste sind nur für Fachkundige ein Indiz für die Vollständigkeit des Ausdrucks. Mitarbeiter, die eine Liste nicht genau kennen, können die Vollständigkeit auf diese Weise nicht abschätzen. Aus diesem Grunde ist es sinnvoll am Ende jeder Liste einen Vollständigkeitsvermerk auszudrucken. Unser Vorschlag: * * * * * * * * * * * * * ** * * * * * * Ende der Liste * * * * * * * * * * * * * ** * * * * * * Dieser Vollständigkeitsvermerk kann Bestandteil des Listenlayouts sein. Abbruchvermerke wie „Druck abgebrochen“ helfen nur bedingt weiter. Dieser Vermerk kann immer nur dann erzeugt werden, wenn das System einen Abbruchbefehl für den Ausdruck einer Liste erhält. Abgebrochene Ausdrucke durch Papierstau, Programmierfehler u. ä. werden auf diese Weise nicht abgefangen. Die „Listen aller Listen“ Bei Pflichtenheften von komplexen Projekten sammelt sich im Laufe der Zeit eine Vielzahl von Listen an. Hier den Überblick zu behalten ist zumeist nur wenigen vergönnt. Damit im Laufe der Projektarbeit nicht von verschiedenen Teams ähnliche Listen realisiert werden ist eine Gesamtübersicht über den aktuellen bzw. zukünftigen Realisierungsstand unerlässlich. Als einfaches organisatorisches Mittel hat sich hier die „Liste aller Listen“ bewährt. Dies ist ein Ordner, in dem alle Liste mit Namen, Nummer und Kurzbeschreibung aufgelistet sind. Zusätzlich ist von jeder Liste ein Probeausdruck beigelegt. Der Ordner ist meist nach Abteilungen (Einkauf, Vertrieb usw.) sortiert. Vor der Konzeption jeder neuen Liste sollte dann vorher in diesem Ordner nachgeschaut werden, ob nicht so etwas Ähnliches bereits existiert. Es ist zumeist effektiver und schneller, eine bestehende Liste um ein paar Felder zu erweitern, als eine komplett neue Liste zu programmieren. Stand: 14.05.2016 Version 0.93 Seite -56- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.6.6 Kopfinformationen von Listen Worum geht es? Festlegen der Inhalte der Kopfzeilen einer Liste. Innerhalb von Listen sind die Kopfzeilen mit denen in einem Textdokument gleichzusetzen. Dieser Teil der Liste wird auf jeder Seite gedruckt. Was bringt es? Der Umfang von EDV-Listen ist zumeist größer als nur eine Seite. Aus diesem Gunde ist es sinnvoll, auf jedem Blatt einer Liste Informationen darüber auszugeben, wie die Liste heißt und welche Informationen auf der Liste ausgegeben werden. Die nachfolgenden Informationen stellen das Minimum an Kopfinformationen dar, die auf einer Liste ausgegeben werden sollen: Firma Worum geht es? Nicht nur bei mandantenfähigen Systemen sollte der Firmenname auf jeder Liste ausgegeben werden. Was bringt es? Eindeutige Zuordnung der Liste zur jeweiligen Firma. Liste Worum geht es? Bei der Vielzahl von Listen innerhalb von komplexen Systemen ist eine eindeutige Identifizierung der Liste anhand einer Nummer unabdingbar. Was bringt es? Sowohl bei der Pflichtenhefterstellung als auch später im laufenden Betrieb kann anhand der eindeutigen Nummer eine Liste eindeutig identifiziert werden. Gerade dann, wenn alte Systeme abgelöst und durch neue ersetzt werden, neigen die Fachabteilungen dazu, neue Listen mit Begriffen zu bezeichnen, die noch aus dem alten System herrühren. Die eindeutige Nummerierung kann sowohl bei der Erstellung des Pflichtenheftes als auch später helfen, Missverständnisse zu vermeiden. Name Worum geht es? Die Bezeichnung der Liste. Die Bezeichnung kann auch zweizeilig oder mehrzeilig sein. Was bringt es? Die eindeutige Nummer kann zwar helfen, eine Liste zu identifizieren, jedoch ist ein Titel notwendig, um die aufgelisteten Informationen schnell einen Sachverhalt zuordnen zu können. Dies ist umso wichtiger, wenn viele ähnliche Listen erstellt werden sollen. Stand: 14.05.2016 Version 0.93 Seite -57- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Datum Worum geht es? Das Druckdatum der Liste. Worum geht es? Das Druckdatum gibt Information über den Grad der Aktualität der Liste. In verschiedenen Situationen (z. B. Ausdruck von Börsenkursen) sollte zusätzlich die Uhrzeit mit ausgegeben werden. Seite Worum geht es? Ausgabe der aktuellen Seitennummer der Liste. Was bringt es? Die Information welche Seite der Liste man gerade in Händen hält. Sortierung Worum geht es? Eine Liste kann nach unterschiedlichen Kriterien sortiert werden. Damit der Leser der Liste direkt sehen kann, welche der möglichen Sortierungen gewählt worden ist, sollte die Sortierung immer mit auf der Liste stehen. Was bringt es? Sollte eine Liste nach mehreren Kriterien sortiert werden können, gibt die Anzeige der Sortierung direkt eine Information darüber, in welcher Reihenfolge das Zahlenmaterial aufbereitet ist. Gerade bei neuen Mitarbeitern führt das Fehlen von Sortierkriterien auf Listen mit mehreren möglichen Sortierungen dazu, dass die benötigen Informationen u. U. nicht gefunden werden, weil die falsche Liste zu Rate gezogen worden ist. Selektion Worum geht es? Damit der Umfang bzw. die Übersichtlichkeit einer Liste optimiert werden kann, besteht vielfach der Wunsch, vor dem Auslösen einer Liste ein Selektionskriterium mit anzugeben. Dies soll helfen, den Umfang der Liste einzugrenzen. Was bringt es? Bei umfangreicheren Listen kann jedoch auch von Fachleuten zumeist nicht mehr abgeschätzt werden, ob eine Liste mit oder ohne Selektionskriterium ausgelöst worden ist. Die Anzeige des gewählten Selektionskriteriums gibt dem Leser die Information, dass der Umfang der Liste nicht das gesamte Datenmaterial wider gibt. So kann eine aufwändige Sucherei vermieden werden, wenn von vornherein erkannt werden kann, nach welchem Kriterium das Datenmaterial gefiltert worden ist. Stand: 14.05.2016 Version 0.93 Seite -58- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.6.7 Beispiel für die Beschreibung einer Liste Die nachfolgende Roherlösstatistik wird im Monatsabschluss ausgedruckt. Firma: AAAAAAAAAOAAAAAAAAAO Liste: 52109PR Roherlösstatistik Datum: TT.MM.JJJJJ Sortierung: Selektion: Artikel-Nummer Monat: AAAAAAAAAO Warengruppe: AAAAAAAAAOAAAAA Artikel-Nr. Beschreibung 9999999 9999999 9999999 9999999 9999999 ... Warengruppe Seite: -nnn- AAAAAAAAAOAAAAA AAAAAAAAAOAAAAA AAAAAAAAAOAAAAA AAAAAAAAAOAAAAA AAAAAAAAAOAAAAA ... AAAAAAAAAOAAAAA Umsatz Stück DM 999.999.999 999.999.999 999.999.999 999.999.999 999.999.999 999.999.999 999.999.999 999.999.999 999.999.999 999.999.999 ... ... 999.999.999 EK-Wert DM 999.999.999 999.999.999 999.999.999 999.999.999 999.999.999 ... 999.999.999 Roherlös DM Prozent 999.999.999 999,99 999.999.999 999,99 999.999.999 999,99 999.999.999 999,99 999.999.999 999,99 ... ... 999.999.999 999,99 Warengruppe: AAAAAAAAAOAAAAA Artikel-Nr. Beschreibung Umsatz EK-Wert Roherlös DM Stück DM DM Prozent 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 ... ... ... ... ... ... ... Warengruppe AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999,99 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Warengruppe: AAAAAAAAAOAAAAA Artikel-Nr. Beschreibung Umsatz EK-Wert Roherlös DM Stück DM DM Prozent 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 9999999 AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999.999.999 999,99 ... ... ... ... ... ... ... Warengruppe AAAAAAAAAOAAAAA 999.999.999 999.999.999 999.999.999 999,99 * * * * * * * * * * * * * ** * * * * * * Ende der Liste * * * * * * * * * * * * * ** * * * * * * Stand: 14.05.2016 Version 0.93 Seite -59- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Name der Liste Kurzbeschreibung der Liste Roherlösstatistik (52109PR) Diese Liste soll auf der Ebene Artikel-Warengruppe die Roherlöse für den ausgewählten Monat ausweisen. Oben 1,5 Ränder in cm Unten Rechts 1,5 1 Sortierung nach: Artikel-Nr Art der Sortierung aufsteigend links 2 Gruppenwechsel Warengruppe Kopfzeile Feld Firma Liste Datum Seite Art Datenfeld Datenfeld Automatisch Automatisch Listenteil Feld Artikelnummer Beschreibung Umsatz Stück Umsatz DM Art Datenfeld Datenfeld Rechenfeld Rechenfeld EK-Wert DM Rechenfeld Roherlös DM Rechenfeld Roherlös Prozent Rechenfeld Warengruppe Beschreibung Datenfeld Umsatz DM Ek-Wert DM Roherlös DM Roherlös Prozent Stand: 14.05.2016 Rechenfeld Rechenfeld Rechenfeld Rechenfeld Bemerkung Name der Firma, der im Mandantenstamm hinterlegt ist. Nummer der Liste für die spätere eindeutige Identifizierung (52109PR als Nummer für die Roherlösstatistik) Datum des Ausdrucks der Liste. Seitennummer der Liste. Bemerkung Eigene Nummer des Artikels aus dem Artikelstamm. Kurzbeschreibung des Artikels aus dem Artikelstamm. Summe aller Abverkäufe diesen Monats aus den Auftragsdateien. Summe aller Abverkäufe diesen Monat. (Basis = Netto-Warenwert im Auftrag) Fremdwährungen müssen zum aktuellen Kurs umgerechnet worden. Alle Eurolandwährungen müssen trianguliert werden! (z. B. US$ -> EURO -> DM – statt US$ -> DM) Durchschnittlich gewichteter EK-Wert in DM. Alle Eurolandwährungen müssen trianguliert werden! (z. B. US$ -> EURO -> DM - statt US$ -> DM) Umsatz DM – EK-Wert DM 100 * Roherlös in DM / Umsatz DM Kurzbezeichnung der Warengruppe aus dem Artikelstamm, zu der der jeweilige Artikel gehört. Umsatz DM Ek-Wert DM Roherlös DM 100 * Roherlös DM / Umsatz DM Version 0.93 Seite -60- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.6.8 Belege Worum geht es? Im Gegensatz zu Listen haben Belege keine Struktur, die in ein einheitliches Schema gebracht werden können. So können die nachfolgend aufgeführten Vorschläge nur als grobe Richtlinie dienen, wie eine vollständige Beschreibung eines Beleges vorgenommen wird. Komplexe Belege Manche Belege entpuppen sich im Laufe der Zeit als eine immer komplexere Ansammlung von Zahlen und anderen Informationen. Rechnungen sind hierfür prädestiniert. In der späteren Praxis sowie bei der Entwicklung und dem Test hat sich immer wieder das Problem der Nachvollziehbarkeit errechneter Werte herausgestellt. Diese Situation tritt z. B. dann auf, wenn nicht alle Positionen einer längeren Rechnung skontoabzugsfähig sind. Somit kann aus dem Warenwert der Rechnung nicht einfach der Skontobetrag errechnet werden. Um eine einfache Form der Überprüfung solcher Rechnungen zu gewährleisten hat es sich bewährt, die Rechenregeln komplexer Belege in einer Tabellenkalkulation (z. B. Excel) abzubilden. So kann schon vor der Programmierung eines solchen Beleges das Verhalten der Formeln bei bestimmten Konstellationen überprüft werden. Stand: 14.05.2016 Version 0.93 Seite -61- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.6.9 Beispiel für einen Beleg Die nachfolgende Rechnung ist das Fragment einer Warenrechnung. Sie soll nur die Vorgehensweise verdeutlichen und erhebt nicht den Anspruch auf Vollständigkeit. „Echte“ Rechnungen weisen in der Praxis einen ungleich höheren Grad an Komplexität auf. Nachdem der Lieferschein gedruckt worden ist, wird die nachfolgende Rechnung ausgegeben. Die Anzahl der Rechnungskopien ist pro Kunde im Kundenstamm hinterlegt. TEAM HDvO Teststr. 23 123456 Testhausen RECHNUNG 999999(1) TT.MM.JJJJ(2 Kunden-Nr. 99999-99999 Seite -nnnBEI ZAHLUNGEN UND RÜCKFRAGEN BITTE ANGEBEN! KOPIE Team HdvO – Teststr. 23 – 123456 Testhausen Versandanschrift XXXXXXXXXOXXXXXXXXXO(3) XXXXXXXXXOXXXXXXXXXO(4) XXXXXXXXXOXXXXXXXXXO(5) XXXXXXXXXOXXXXXXXXXO(8) XXXXXXXXXOXXXXXXXXXO(9) XXXXXXXXXOXXXXXXXXXO(10) XXXXXXXXXOXXXXXXXXXO(6) XXXXXXXXXOXXXXXXXXXO(7) XXXXXXXXXOXXXXXXXXXO(11) XXXXXXXXXOXXXXXXXXXO(12) Menge in Stk. Artikel Nr. Bezeichnung Kunden Art.-Nr. unverb. Preisempf. Einzelpreis Rabatt Positionsin % summe 99999 9999999990 9999999990 999.999.,99 99,99 99,99 99.999.999,99 XXXXXXXXXOXXXXXXXXXO 99999 9999999990 9999999990 999.999.,99 99,99 99,99 99.999.999,99 XXXXXXXXXOXXXXXXXXXO 99999 9999999990 9999999990 999.999.,99 99,99 99,99 99.999.999,99 XXXXXXXXXOXXXXXXXXXO 99999 9999999990 9999999990 999.999.,99 99,99 99,99 99.999.999,99 XXXXXXXXXOXXXXXXXXXO ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 99999 9999999990 9999999990 999.999.,99 99,99 99,99 99.999.999,99 XXXXXXXXXOXXXXXXXXXO 99999 9999999990 9999999990 999.999.,99 99,99 99,99 99.999.999,99 XXXXXXXXXOXXXXXXXXXO Warenwert Versandkosten Rechnungsnettobetrag MWSt 66,66% Rechnungsendbetrag 99.999.999,99 99.999.999,99 99.999.999,99 99.999.999,99 99.999.999,99 Bei Zahlung bis zum TT.TT.JJJ unter Abzug von 66,66% Skonto 99.999.999,99 Stand: 14.05.2016 Version 0.93 (13) Seite -62- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Sortierung nach: a) Artikel-Nr b) Kunden-Artikel-Nr (falls Kennzeichen „Sortierung“ im Kundenstamm gesetzt worden ist) Feld (1) (2) Kunden-Nr. Seite -nKOPIE (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) Menge in Stk. Artikel Nr. Bezeichnung Kunden Art.-Nr. unverb. Preisempf. EinzelPreis Rabatt Art Datenfeld Datenfeld Datenfeld Automatisches Feld Automatisches Feld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Datenfeld Bemerkung Fortlaufende Rechnungsnummer (n=n+1) Datum der Rechnungserstellung Nummer des Kunden aus dem Kundenstamm „n“ = Aktuelle Seitennummer Dieser Text wird bei jeder Kopie ausgedruckt. Beim Original wird dieser Text unterdrückt. Name 1 der Rechnungsadresse des Kunden Name 2 der Rechnungsadresse des Kunden Strasse der Rechnungsadresse des Kunden PLZ und Ort der Rechnungsadresse des Kunden Land der Rechnungsadresse des Kunden Name 1 der Versandadresse des Kunden Name 2 der Versandadresse des Kunden Strasse der Versandadresse des Kunden PLZ und Ort der Versandadresse des Kunden Land der Versandadresse des Kunden Kommissionierte Menge Nummer des Artikels Kurzbezeichnung des Artikels Artikel-Nummer des Kunden Datenfeld Unverb. Preisempf. des Kunden Datenfeld Einzel-Abgabepreis des Artikels in Stück Datenfeld Positionsrabatt des Artikels. (Entweder individuell aus dem Auftrag übernommen oder aus dem Kundenstamm) Menge * Einzelpreis * Rabatt in % Summe aller Positionssummen Wenn Warenwert > 1000,- DM -> 2% von Warenwert - sonst kostenlos Warenwert+Versandkosten Positionssumme Warenwert Versandkosten Rechnungsnetto betrag MWSt 66,66% Rechenfeld Rechenfeld Rechenfeld Rechenfeld Rechnungsendbetrag Bei Zahlung bis zum TT.TT:JJJ unter Abzug von 66,66% Skonto Rechenfeld (13) Rechenfeld Stand: 14.05.2016 Art der Sortierung Aufsteigend (Voreinstellung) Aufsteigend Rechenfeld Datenfeld Rechnungsnettobetrag * 66,66% (Bei Kunden außerhalb von Deutschland wird in Abhängigkeit von der Existenz der MWST-ID-Nr im Kundenstamm die MWST erhoben) Rechnungsnetto + MWST Abhängig von der Einstellung im Kundestamm wird die jeweils gültige Zahlungsbedingung gezogen. TT.MM.JJJJ= Druckdatum der Rechnung + Anzahl der Tage aus dem Kundenstamm 66,66%= Skontosatz für diesen Kunden aus dem Kundenstamm (Rechnungsendbetrag * Tage * %-Satz) / (100 * 360) Version 0.93 Seite -63- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.6.10 Etiketten Wie wird es gemacht? Im Gegensatz zu Listen und Belegen sind Etiketten zumeist etwas einfacher strukturiert. Die gebräuchlichste Form eines Etikettes ist das Adress-Etikett. An dieser Standardverwendung lassen sich die meisten Spielarten bei Etiketten einfach darstellen. Unser Vorschlag: Medium Sortierung Feld Länge Layout Breite Artikel-Nr Bemerkung Medium Bei Listen und Belegen ist die Frage des zu verwendenden Mediums noch nicht aufgetaucht. Bei Etiketten gibt es zwei unterschiedliche Möglichkeiten der Ausgabe. Zum einen können die Etiketten auf einer Rolle angebracht sein. Diese Form wird zumeist bei der Verwendung von Nadel- oder Etikettendruckern eingesetzt; während Bögen zumeist beim Einsatz von Laserdruckern verwendet werden. Sortierung Diese Sortierung bezieht sich nicht auf die Reihenfolge im Ausdruck. Dieses Feld ist nur dann notwendig, wenn die Etiketten auf Bögen ausgegeben werden. Bei Bögen aber sind u. U. mehrere Etiketten nebeneinander angebracht. Hier ergibt sich Frage der Sortierung der Etiketten auf dem Bogen. Mögliche Sortierungen: zeilenweise spaltenweise Layout Bei Etiketten, die nicht standardisiert sind, sollten die Länge und Breite eines Etiketts mit angegeben werden. Tipp: Beim Einsatz von standardisierten Etiketten einfach die Artikel-Nr. einer der bekannten Anbietern wie z. B. Zweckform mit angeben. Dann ist die Angabe der Größe und weitere evtl. notwendige Informationen nicht mehr notwendig. Feld Text oder Platzhalter für einen Feldinhalt. Bemerkung Hier gehört eine kurze Beschreibung des jeweiligen Feldes hin. Prüfen Sie auch bei augenscheinlich profanen Feldern wie z. B. Kundennummer oder Adresse, ob nicht eine Beschreibung notwendig ist. (So ist es z. B. für das Schreiben einer Rechnung schon wichtig, ob die Adresse im Dialog die Versandadresse oder die Rechnungsanschrift des Kunden ist.) Bei Feldern, deren Inhalte mit Hilfe einer Formel errechnet werden, muss die Formel Teil der Bemerkung werden. Stand: 14.05.2016 Version 0.93 Seite -64- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Barcodes auf Etiketten Falls ein Barcode auf dem Etikett angebracht werden soll, muss unbedingt die Art des Barcodes mit beschrieben werden. Es gibt unterschiedliche Verschlüsselungsformen, die hier nicht weiter ausgeführt werden. Zudem müssen die Scanner den verwendeten Barcode lesen können. Bekannte Barcodes sind z. B. EAN13, CODE128 usw. Spezielle Informationen zum Etikett bzw. Etikettendruck Sicher gibt es noch viele weitere Informationen, die speziell zum Etikettendruck mit erfasst werden können. So kann z. B. das Druckverfahren (Thermotransfer oder Thermosublimation) oder die Papiergüte für spezielle Formen der Anwendung eine wichtige Rolle spielen. Hier ist es dem jeweiligen Autor vorbehalten, diese evtl. notwendigen Informationen mit bei der Beschreibung des Etiketts zu hinterlegen. Stand: 14.05.2016 Version 0.93 Seite -65- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.6.11 Beispiel für die Beschreibung eines Etiketts Sortierung Sortierung nach: ID-Nr: Art der Sortierung Aufsteigend Medium Sortierung auf Bogen/Rolle Bogen A4 Zeilenweise Feld ID-Nr: 9999 TT.MM.JJJJ Team HDvO, Teststr. 23, 123456 Testhausen Name1AAAAOAAAAAAAAAO Name2AAAAOAAAAAAAAAO StrasseAAOAAAAAAAAAO PLZ999 OrtAAAAAAOAAAAAAAAAO Stand: 14.05.2016 Länge - Layout Breite Artikel-Nr Zweckform 6012 Bemerkung Fortlaufende ID-Nr. der Sendung Druckdatum des Aufklebers Falls die Sendung den Status „Eilig“ hat, wird dieser farbige Ausdruck zusätzlich ausgegeben. Sonst bleibt diese Stelle leer. Kundennummer des Kunden Barcodetyp: EAN8 mit Prüfziffer (Im Bedarfsfall können noch Länge und Breite des Barcodes mit angegeben werden.) Anschrift des Absenders Name1 der Versandanschrift des Kunden Name2 der Versandanschrift des Kunden Strasse der Versandanschrift des Kunden PLZ der Versandanschrift des Kunden Ort der Versandanschrift des Kunden Firmenlogo. Hierzu liegt eine Bitmap im Verzeichnis XYZ bereit. Diese Grafik muss in jedem Drucker zur Verfügung stehen. Version 0.93 Seite -66- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 3.7 Dateien Hierarchische Dokumentation von Objekten Worum geht es? Das Objekt Datei dient zur Beschreibung von Dateistrukturen. Es wird immer dann benötigt, wenn Daten von außen in die Anwendung hinein laufen bzw. aus ihr heraus erzeugt werden sollen. In beiden Fällen hilft dieses Objekt, eine genaue Tabellen- bzw. Datensatzbeschreibung zu erstellen. Die Beschreibung ist in diesem Zusammenhang als Beschreibung einer Tabelle zu verstehen, sie ersetzt kein Datenmodell. Innerhalb der Methode HDvO wird das Objekt Datei als Endpunkt einer Funktion bzw. eines Ablaufs angesehen. Aus diesem Grunde kann dieses Objekt keine untergeordneten Objekte haben. (Die genaue Erläuterung dieser Sichtweise finden Sie im Handbuch von HDvO) Was bringt es? Wenn Pflichtenhefte für Softwaresysteme geschrieben werden, die Daten mit anderen Systemen austauschen, dann ist die eindeutige Beschreibungen der Schnittstellen (Ein- und Ausgabedateien) eine elementare Voraussetzung für eine funktionsfähige Software. Wie wird es gemacht? Zur Beschreibung von Dateistrukturen haben sich Tabellen bewährt. Rein textuelle Beschreibungen lassen zuviel Raum für Interpretationen. Sie sind in der Programmierung unter ökonomischen Gesichtspunkten u. E. nicht einsetzbar. Die hier vorgestellte Tabellenstruktur ist als minimale Anforderung an die Beschreibung einer Datei zu sehen. Wenn eine Datei beschrieben wird, beginnt man mit einem einleitenden Satz. Es hilft innerhalb des Pflichtenheftes festzustellen, von wo die Datei kommt bzw. wohin sie geht. Der Kontext ist so einfacher ersichtlich. Der einleitende Satz ist hierbei als Minimalanforderung an den Einsteig in eine Dateibeschreibung zu sehen. Wenn zusätzliche Erklärungen sinnvoll sind, sollten Sie hier an dieser Stelle gemacht werden. Der einleitende Satz für eine Ausgabedatei könnte lauten: "Nach Aufruf des Menüpunktes <Menüpunkt> wird die Datei <Name der Datei> ausgegeben. Unser Vorschlag: Nr. Von-bis Typ Länge Dezimale Name Beschreibung Nr Fortlaufende Nummer des Tabelleneintrags. Von-bis Länge des Datensatzes (Achten Sie darauf, dass die verschiedenen EDV-Systeme eine unterschiedliche Basis für die Bestimmung der Länge eines Datensatzes verwenden. Einige Systeme beginnen bei 0 andere bei 1 zu zählen.) Stand: 14.05.2016 Version 0.93 Seite -67- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Typ Typ des übergebenen Datenfeldes. (Character, Num, Integer usw.) Wegen der Vielfalt der Möglichkeiten einen Datentyp zu beschreiben, haben wir auf eine Auflistung verzichtet. Nutzen Sie zur Beschreibung Ihrer Dateien, die Notation Ihres Quell- bzw. Zielsystems. Länge Die Länge des Feldes. (z. B. 40) (Bitte informieren Sie sich vor der Beschreibung von Dateien genau über die Arbeitsweise der beteiligten Datenbanken. Die Zählweise für die Datensatzlänge ist u. U. unterschiedlich. Einmal ist die Länge eines Feldes incl. Dezimalstellen zu verstehen, ein anderes Mal wird sogar der Dezimalpunkt mit als Stelle gezählt. Wieder andere Systeme zählen die Dezimalstellen bei der Bestimmung der Gesamtlänge des Feldes nicht separat.) Dezimale Anzahl der Nachkommastellen bei numerischen Feldern. Name Technischer Name des Feldes. (z. B. KDNR für Kundennummer) Beschreibung Eine kurze Beschreibung des Feldes. (Hier kann neben der Beschreibung auch der fachliche Namen des Feldes stehen) Beispiel: Nr. Von-bis Typ Länge Dezimale Name 1 1-10 NU 5 0 KDNR M 2 11-60 CHR 50 0 KDNAM1 3 61-110 CHR 50 0 KDNAM2 4 111-160 CHR 50 0 KDSTR Beschreibung Kundennummer Name1 des Kunden (Rechnungsadresse) Name2 des Kunden (Rechnungsadresse) Straße des Kunden (Rechnungsadresse) ... Bei solch einer Tabelle bietet es sich an, diese Beschreibungen in Excel zu verwalten. Sinnvollerweise würde die Excel-Tabelle dann als OLE-Objekt mit dem Pflichtenheft verknüpft. Damit wäre eine automatische Aktualisierung sichergestellt, wenn sich die Excel-Tabelle ändert. Es hat sich allerdings bei unserer Arbeit gezeigt, dass ab einer gewissen Größe die Bearbeitung eines Pflichtenheftes zur Qual wird, wenn zu viele verknüpfte OLE-Objekte im Dokument vorhanden sind. Das Dokument wird beim Öffnen und Abspeichern sehr träge. Wählen Sie daher für das Arbeiten mit Excel-Tabellen die Option "Einfügen" aus. Damit ist zwar keine automatische Aktualisierung der Objekte bei Änderungen der Tabellenstrukturen gegeben, jedoch gestaltet sich das Arbeiten mit dem Pflichtenheft angenehmer. Um Probleme mit OLE-Verknüpfungen zur vermeiden, können wir nur raten: "Halten Sie immer von jedem OLE-Objekt eine separate Kopie bereit!" So können Sie bei fehlerhaften Verknüpfungen bzw. beschädigten Objekten immer noch über Excel auf Ihre Arbeitsergebnisse zurückgreifen. Dieser Rat gilt übrigens auch für alle anderen Anwendungen, die OLE-Objekte innerhalb von Word abspeichern können. Stand: 14.05.2016 Version 0.93 Seite -68- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Beschriftung der Dateibeschreibung Die Dateibeschreibung sollte als eigener Gliederungspunkt im Pflichtenheft erscheinen. So können die Verantwortlichen für die Schnittstellenprogrammierung schnell auf die für sie notwendigen Informationen zugreifen. Verwenden Sie als Überschrift neben dem technischen Namen der Tabelle auch eine textuelle Umschreibung (statt einfach nur "KDSERTAT" zu schreiben sollte die Überschrift der Tabelle mit "Serientextdatei Kundenstamm (KDSERTAT)" beschriftet werden. Besonderheiten bei Datenbanksystemen Manche Datenbanken haben zusätzliche Besonderheiten, die bei der Beschreibung von Dateien beachtet werden müssen. So kann z. B. die Datenbank der AS/400 nur feste Satzlängen verarbeiten. Bei der Generierung von Ausgabedateien, die solch einer Datenbank zur Verfügung gestellt werden, müssen alle Felder auf die maximale Länge aufgefüllt werden. Diese und andere Informationen müssen vor der Beschreibung der Dateien aufgeführt werden. Objektorientierte Datenbanken Die Systematik Daten zu speichern, ist bei objektorientierten Datenbanken anders als bei relationalen Datenbanksystemen. Bei Beschreibung von Tabellen objektorientierter Datenbanken muss anders vorgegangen werden. Hier müssen u. a. zusätzlich noch die Methoden des Objekts beschrieben werden, die mit in der Datenbank abgelegt werden. In unserer Arbeit mit kaufmännischen Applikationen ist uns diese Formen der Datenbank bisher noch nicht begegnet. Wir werden bei Bedarf diese Beschreibung nachreichen. Stand: 14.05.2016 Version 0.93 Seite -69- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 4 Möglichkeiten der Visualisierung von Abläufen Worum geht es? Jeder, der Software erstellt, muss sich mit der Frage auseinandersetzen, wie die zu klärenden Sachverhalte möglichst schnell und verlustfrei zwischen den unterschiedlichsten Partnern kommuniziert werden. Neben einer rein textuellen Beschreibung bzw. der verbalen Erläuterung eines Sachverhaltes wird meist die Möglichkeit genutzt, Zusammenhänge mit Hilfe von Grafiken zu verdeutlichen. Problematisch ist es jedoch, bei der Vielfalt der zu klärenden bzw. erklärenden Sachverhalte die richtige Darstellungsform zu finden. Dem Anspruch an eine kundenorientierte Beratung kann nicht gerecht werden, wenn versucht wird, dem Kunden Formen der Visualisierung aufzuzwingen, deren Informationsgehalte nicht einfach für ihn verständlich und damit konsumierbar sind. In der Praxis haben sich hier zwei Arten gezeigt, mit denen versucht wird, den Fachabteilungen einzelne Sachverhalte zu verdeutlichen. Zum einen gibt es die methodische Vorgehensweise im Sinne eines case-Tools. Hier haben die Berater eine Vorgehensweise gelernt und versuchen die Kommunikation mit der Fachabteilung mit Hilfe ihrer Methode durchzuführen. Dies ist immer dann erfolgreich, wenn der Berater zum einen die Methode sehr gut beherrscht und zum anderen in der Lage ist, die manchmal recht abstrakten Darstellungsformen bzw. Methodennotationen dem Kunden nahe zu bringen. Hierzu ist sehr viel Erfahrung im Umgang mit der Methode im Speziellen und den Kunden im Allgemeinen notwendig. Sollte die Methode vom Berater nicht perfekt beherrscht werden, kann es ganz schnell passieren, dass sich Diskussionen mit der Fachabteilung entweder um die methodisch korrekte Darstellung eines Sachverhaltes drehen. Oder der Berater kann mit der Art der Visualisierung einen Sachverhalt nicht korrekt bzw. nicht verständlich darlegen. In beiden Fällen entsteht die Situation, dass nicht mehr an der eigentlichen Problemlösung gearbeitet wird, sondern dass über Arten der Darstellung bzw. Methoden gesprochen wird. Im schlimmsten Fall schalten die Leute ab und es ist nicht mehr möglich, die Kommunikation fortzuführen. Zum anderen gibt es die "Meister der Improvisation". Hier wird durch den Berater versucht, ad hoc ein Sachverhalt durch Visualisierung zu verdeutlichen. (Jemand springt mal eben an die Tafel und fängt an zu malen.) Auch hier ist es wieder dem Geschick und der Erfahrung des Einzelnen überlassen, wie erfolgreich diese Form der Zusammenarbeit mit dem Kunden ist. In diesem Falle besteht die Gefahr, dass durch eine falsche bzw. unzureichende Form der Visualisierung Information falsch verstanden bzw. unvollständig erklärt werden. Was bringt es? Sollten Sie zu keiner der obigen Gruppen gehören, möchten wir mit dem nachfolgenden Angebot eine Auswahl von Visualisierungsmöglichkeiten geben. Sie haben sich bereits bei der täglichen Arbeit bewährt. Die dargestellten Visualisierungsmöglichkeiten sind einfach zu kommunizieren, und können sofort effizient bei der Arbeit mit der Fachabteilung eingesetzt werden. Sie sollen als Leitfaden bei der Frage dienen: "Welche Form der Darstellung wähle ich bei welchem Problem bzw. welchem Sachverhalt?" Es wird hier bewusst keine der heute populären Vorgehensweisen wie z. B. die der OOA oder der UML beschrieben. Hier haben die Spezialisten die eindeutig besseren Verfahren und die umfangreicheren Möglichkeiten. An dieser Stelle soll vielmehr eine Auswahl an Beispielen Stand: 14.05.2016 Version 0.93 Seite -70- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Hilfestellungen bieten, wie bestimmte, immer wieder auftauchende Sachverhalte einfach visualisiert werden können. Die nachfolgend dargestellten Beispiele orientieren sich daher nicht an einer bestimmten Methode. Es wurde bei der Auswahl der verschiedenen Darstellungsmöglichkeiten jedoch darauf geachtet, dass alle Grafiken per Hand an einer Tafel, einem Flipchart o. ä. umgesetzt werden können. Die gewählte Reihenfolge der dargestellten Visualisierungsmöglichkeiten geht vom Groben ins Feine. Es wird mit Vorschlägen begonnen, die helfen, grobe Sachverhalte darzustellen. Die dann folgenden Vorschläge bieten Vorschläge für immer detailliertere Möglichkeiten Sachverhalte zu visualisieren. Wir sind uns durchaus bewusst, dass es zu diesem Thema ganz andere Sichtweisen geben kann. Auch soll mit diesem Angebot nicht eine nicht methodische Vorgehensweise propagiert werden. Vielmehr sollen Wege aufgezeigt werden, wie ohne das Aufkommen großer semantischer Lücken gemeinsam mit der Fachabteilung Ergebnisse erarbeitet werden können. Sollten Sie Ergänzungen, Anmerkungen oder eigene Erfahrungen zu diesem Thema haben, schreiben Sie uns! Stand: 14.05.2016 Version 0.93 Seite -71- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 4.1 Brainstorming-Ergebnisse darstellen Worum geht es? Viele Teilbereiche bei der Pflichtenhefterstellung beginnen mit einer Informationssammlung. Eine der effektivsten Formen eine Informationssammlung vorzunehmen ist das Brainstorming. Hier werden alle Gedanken zu einem Sachverhalt zu Papier gebracht. Zumeist erfolgt die Ergebnissammlung in Form von Listen, die von einem Moderator auf einem Flipchart aufgeschrieben werden. Eine wesentlich bessere Form Ideensammlungen als in Listenform aufzuschreiben ist die Visualisierung in Form eines Mindmaps. Was bringt es? Die Visualisierung von Ideen in Form eines Mindmaps ist eine leicht verständliche und universal einsetzbare Methode unstrukturierte Informationen zu sammeln und zu ordnen. Durch die schnell erzielbaren Arbeitsergebnisse macht jedem die Methode Spaß. Die Methode ist sowohl manuell als auch per Software nutzbar. (siehe hierzu Kapitel 7.5 Welche Tools sollen genutzt werden?) Wie wird es gemacht? Die zu bearbeitende Problemstellung wird in die Mitte einer Tafel/eines Blattes geschrieben. Um die Problemstellung wird ein Kasten/Kringel/Wolke o. ä. gezeichnet. Jeder Gedanke zu der Problemstellung wird wie ein Ast an die Problemstellung gezeichnet. Jeder neue Gedanke ergibt einen neuen Haupt-Ast. Themen, die zu einem Haupt-Ast gehören werden unter dem jeweiligen Haupt-Ast als Neben-Ast geschrieben. Die grobe Darstellung des Mindmappings wird dieser lange bewährten Methode nicht gerecht. Nutzen Sie bitte daher den nachfolgenden Link, um das Thema weiter zu vertiefen. Es lohnt sich sicher für Sie! http://www.mindmanager.com: Auf dieser Seite finden Sie neben weiteren Informationen auch die Software, mit der das nachfolgende Beispiel erstellt wurde. Beispiel: Stand: 14.05.2016 Version 0.93 Seite -72- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 4.2 Kommunikationsbeziehungen darstellen Worum geht es? Für die grobe Darstellung eines Prozesses kann eine Darstellung gewählt werden, bei der alle beteiligten Stellen in Ihren Kommunikationsbeziehungen untereinander dargestellt werden. Diese Form der Darstellung auch dann sinnvoll, wenn aufgezeigt werden soll, wie viel Kommunikation zwischen verschiedenen Bereichen bei einem bestimmten Prozess abläuft. Was bringt es? Eine solche Visualisierungsmöglichkeit wird zumeist bei neuen Sachverhalten gewählt, um einen Gesamtüberblick zu erlangen. Diese sehr reduzierte Form der Darstellung hilft zudem bei der Identifizierung von beteiligten Stellen innerhalb eines Prozesses. Aus dieser Darstellung lässt sich jedoch nur schwer ein zeitlicher Ablauf der Kommunikation ableiten. Zudem ist sich wegen der fehlenden Anfangs- und Endpunkte bei dieser Form der Darstellung nicht zur Modellierung von Abläufen geeignet. Wie wird es gemacht? Die einzelnen Bereiche werden als Kreise dargestellt. Pfeile zwischen diesen Kreisen stellen die Kommunikationsbeziehungen untereinander dar. Die Pfeilspitzen zeigen die Richtung auf in der die Kommunikation läuft. Beispiel: Stand: 14.05.2016 Lieferant Bestellung Rechnung bestellte Ware Informationen über die Lieferung Wareneingang einlagern Ware Version 0.93 Einkauf Lager Seite -73- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 4.3 Zeitliche Abläufe von Kommunikationen darstellen Worum geht es? Es gibt verschiedene Kommunikationsbeziehungen bei denn der zeitliche Ablauf der Kommunikation verschiedener Systeme untereinander dargestellt werden soll. Dies ist z. B. immer dann wichtig, wenn EDV-Systeme Daten mit einander austauschen. Was bringt es? Diese Visualisierungsmöglichkeit wird zumeist bei neuen Sachverhalten gewählt, um einen Überblick über den zeitlichen Ablauf der Kommunikation zu erlangen. Diese sehr reduzierte Form der Darstellung hilft zudem bei der Identifizierung von beteiligten Stellen innerhalb eines Prozesses. Wie wird es gemacht? Bei dieser Darstellung sind die jeweiligen Systeme als Kästchen mit einer länglichen Linie dargestellt. Die Pfeile zeigen die Richtung des Informationsflusses an. (Der Sender schickt eine Nachricht an den Empfänger) Der Ablauf der Pfeile entspricht dem zeitlichen Ablauf. Zur genaueren Erklärung kann die Beschriftung der Pfeile auf umfangreichere Erklärungen im Text verweisen. Beispiel: System A System B Nachricht wird gesendet Rückmeldung wird gesendet Stand: 14.05.2016 Version 0.93 Nachricht wird verarbeitet Seite -74- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 4.4 Beleg- und Warenfluss darstellen Worum geht es? Bei Abläufen wie z. B. in der Logistik muss der Fluss von Informationen und Material zwischen Personen und Bereichen dargestellt werden. Diese Anforderung beinhaltet neben einer zeitlichen auch noch eine räumliche Komponente. Aus diesem Grunde muss eine Darstellung gewählt werden, bei der die Abläufe den jeweils verantwortlichen Bereichen zugeordnet werden können. Was bringt es? Vor der Festlegung einer neuen edv-technischen Unterstützung können Prozesse in dieser Form dokumentiert werden, um dann im nächsten Schritt die genaue Anbindung an die zu programmierenden Systeme festzulegen. Bereits existierende Abläufe können so dokumentiert noch einmal zu einer Verdeutlichung der aktuellen Vorgehensweise beitragen. Diese Form der Darstellung ermöglicht einen sehr detaillierten Grad der Darstellung eines Ablaufs. Aus diesem Grunde sollte darauf geachtet werden, dass nur die Aspekte dargestellt werden, die für die Darstellung des jeweiligen Sachverhaltes notwendig sind. Wie wird es gemacht? Bei dieser Form der Darstellung werden die Bereiche und Personen als Blöcke dargestellt. Innerhalb der Blöcke laufen dann die jeweiligen Aktivitäten ab. Hieraus lässt sich genau erkennen, wer welche Aktivitäten innerhalb eines Prozesses durchführt. Zwischen den Blöcken werden dann Daten, Belege, Ware usw. weitergeleitet bzw. ausgetauscht. Beispiel: Spediteur Wareneingangsbüro Prüfung der Avisierung des Spediteurs Meldet sich im Wareneingangsbüro Übergibt Frachtbrief Frachtbrief Avisierung OK ? Wareneingangstor Paletten abladen [NEIN] Anlieferung abweisen ... [JA] Bestellung mit Anlieferung verknüpfen LKW an zugewiesenes Tor stellen Stand: 14.05.2016 Wareneingangstor zuweisen Version 0.93 Seite -75- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 4.5 Aktivitäten und Abhängigkeiten darstellen Worum geht es? Neben dem Fluss von Ware und Informationen ist es sinnvoll, eine Verbindung zwischen Aktivitäten, der dabei genutzten EDV-Unterstützung und den genutzten Belegen herzustellen. Auf diese Art und Weise kann leicht der Zusammenhang zwischen Tätigkeiten und der dazu benötigten Ressourcen dargestellt werden. Was bringt es? Wie wird es gemacht? Auf der einen Seite werden die Akteure mit Ihren Aktivitäten dargestellt. Jeder Ablauf beginnt an einem Punkt und endet an einem oder mehreren Punkten. Aktivitäten, die nicht manuell durchgeführt werden (wie z. B. das Abladen eines LKW´s) werden jeweils einzelnen Belegen oder Bildschirmmasken zugeordnet. Start Kunde FAXAuftrag Auftrag erteilen Sachbearbeiter Maske Auftragerfassung Auftrag prüfen Bonität OK? [NEIN] Kundeninformier. Auftragsbestätigung [JA] Maske Auftragsabschluss Auftrag freigeben Ende Sicher gibt es noch viel mehr mögliche Formen der Visualisierung von Sachverhalten. Sollte Sie Ergänzungen, Anmerkungen oder eigene Erfahrungen zu diesem Thema haben, schreiben Sie uns! Stand: 14.05.2016 Version 0.93 Seite -76- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 5 Besprechungen organisieren Worum geht es? Die Arbeit an einem Pflichtenheft wird in der Regel von einem Team durchgeführt. Neben dem Autor des Pflichtenheftes besteht dieses Team aus Mitarbeitern verschiedenen Fachabteilungen, die bei der Umsetzung ihrer fachlichen Anforderungen mitarbeiten. Der Prozess der Erstellung eines Pflichtenheftes besteht neben dem eigentlichen Schreiben des Pflichtenheftes aus vielen Besprechungen. Damit diese Besprechungen effizient durchgeführt werden haben sich zwei organisatorische Hilfsmittel bewährt. Zu einem das Erstellen einer Agenda als Vorbereitung auf eine Besprechung. Zum anderen das Anfertigen eines Protokolls als Nachbereitung einer Besprechung. 5.1 Die Agenda Worum geht es? Viele Besprechungen werden ohne einen festen Rahmen durchgeführt. Das führt dazu, dass man sich zusammensetzt, über ein Thema spricht und die Besprechung dann ohne konkrete Ergebnisse wieder verlässt. Durch diesen Zustand herrscht dann nach der Besprechung zumeist große Unzufriedenheit. (Aussagen wie: „Diese Besprechung hätte ich mir sparen können.“ oder „Es wurde wieder ohne Hand und Fuß über wichtige Themen gesprochen...“ sind Ihnen sicher bekannt.) Der Grund für diese Unzufriedenheit liegt oft auf der Hand. Ohne eine klare Linie schweifen Diskussionen immer wieder zu Punkten ab, die nicht der eigentliche Gegenstand der Besprechung sind. Gerade im Bereich der EDV ist der Faktor Zeit mit besonderer Aufmerksamkeit belegt. Aus diesem Grunde ist es bei der Pflichtenhefterstellung wichtig, Ergebnisse möglichst schnell und rationell zu erarbeiten. Eine einfache und effektive Art eine Besprechung zu strukturieren, ist die Erarbeitung einer Agenda. Diese an sich selbstverständliche Vorarbeit als Vorbereitung auf eine Besprechung fehlt in der Praxis immer noch sehr häufig. Als Grund für die fehlende Vorbereitung wird zumeist mangelnde Zeit angeführt. Eigentlich eine paradoxe Argumentation. Auf der einen Seite wird die Zeit gespart, die zur Ausarbeitung einer Agenda benötigt wird. Auf der anderen Seite wird wesentlich mehr Zeit in dieser nicht vorbereiteten Besprechung durch eine unstrukturierte Vorgehensweise verschwendet. Die Agenda ist eine der Grundvoraussetzungen für eine erfolgreiche Besprechung! Was bringt es? Besprechungen, die mit Hilfe einer aussagekräftigen Agenda vorbereitet werden bieten viele Vorteile. Dem Kunden wird es durch eine vorgegebene Struktur erleichtert, sich auf die wesentlichen Punkte des Themas zu beschränken. Gerade im Zusammenspiel zwischen Fachabteilung und EDV kommt es durch die unterschiedlichen Sichtweisen der Dinge oft genug zu den sogenannten „Grundsatzdiskussionen“. Im Verlauf der Pflichtenhefterstellung wird durch diese Form der Vorbereitung von Besprechungen die Qualität der Arbeitsergebnisse steigen. Zudem wird durch die Vorbereitung der Teilnehmer der Aufwand an Besprechungszeit deutlich verringert. Stand: 14.05.2016 Version 0.93 Seite -77- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Dem Autor des Pflichtenheftes wird es durch effektive Sitzungen erleichtert, die erarbeiteten Ergebnisse in seiner Ausarbeitung umzusetzen. Zudem wird es dem Moderator der Sitzung durch die Struktur der Agenda leichter fallen, den vorgegebenen Rahmen der Besprechung nicht aus den Augen zu verlieren. Eine strukturiert durchgeführte Besprechung erzeugt auch zumeist strukturierte Ergebnisse. Diese Situation erleichtert es dem Protokollanten die Ergebnisse der Besprechung in einem Protokoll schnell zusammenzufassen. Damit eine Agenda den notwendigen Nutzen bringt sollten die nachfolgenden Punkte beachtet werden. Allen Teilnehmern einer Besprechung ermöglicht eine Agenda sich auf den Termin vorzubereiten. Stellen Sie die Agenda für eine Besprechung daher den Teilnehmern frühzeitig zur Verfügung. Es bringt überhaupt nichts, wenn erst zu Beginn einer Besprechung die Teilnehmer mit der Agenda „überrascht“ werden. Die Effektivität der Besprechung ist damit massiv gefährdet. Ein Hauptteil der Zeit wird dann damit verschwendet, dass sich die Teilnehmer während der Sitzung erst einmal konsolidieren müssen. Eine Agenda ist keine detaillierte Ausarbeitung! Eine Agenda soll bei einer Besprechung als roter Faden dienen. Aus diesem Grunde sollten die angesprochenen Themen und die zu erreichenden Ziele nur als Überschriften und nicht als ausformulierte Sätze dargestellt werden. Vor diesem Hintergrund sollte auch der Umfang einer Agenda nur eine Seite umfassen. Stand: 14.05.2016 Version 0.93 Seite -78- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Wie wird es gemacht? Eine Agenda wird in zwei Schritten erstellt. Im ersten Schritt wird der inhaltliche Teil erarbeitet. Im zweiten Schritt werden dann die Inhalte formal aufbereitet. Neben der Struktur der Agenda müssen auch hier die Gestaltungsrichtlinien, die für die gesamten Unterlagen des Pflichtenheftes festgelegt worden sind, beachtet werden. Aus diesem Grunde wird in der weiteren Beschreibung auch nicht mehr auf die Seitenformatierung bzw. die Inhalte der Kopfund Fußzeilen eingegangen. Schlagen Sie hierzu bitte im Kapitel 7 Technische Anmerkungen nach. Nachfolgend eine schematische Darstellung der beiden Schritte. Situation zu lösende Aufgaben Agenda daraus abgeleitete Ziele Organisatorisches Themenliste daraus abgeleitete Themen Ziele daraus abgeleiteter Teilnehmerkreis 5.1.1 Inhalt einer Agenda erarbeiten Wie wird es gemacht? Die Inhalte einer Agenda werden mit Hilfe eines einfachen Schemas erarbeitet. Nachfolgend sind die einzelnen Schritte aufgeführt. Aufgabe oder Problemstellung definieren Bevor eine gemeinsame Besprechung zusammengerufen wird, muss als erste Maßnahme die zu diskutierende Aufgabe genau definiert werden. Dazu sind Antworten auf die folgenden Fragen notwendig: Stand: 14.05.2016 Version 0.93 Seite -79- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Was ist genau das Problem? Welche Aufgabe muss gelöst werden? Diese beiden Fragen bilden den Ausgangspunkt für die Erstellung einer Agenda. Es ist daher unerlässliche diesen Punkt sehr sorgfältig zu bearbeiten, da alle weiteren Schritte hierauf aufbauen. Beispiel: Situation Das Team hat in einer der letzten Sitzungen die Anforderungen an eine neue Wareneingangsabwicklung in dem bestehenden Warenwirtschaftssystem definiert. Der Autor des Pflichtenheftes hat hierfür jetzt ein Grobkonzept entwickelt. Zu lösende Aufgabe Das neue Konzept liegt in einer ersten Grobfassung vor und muss vor der weiteren Verfeinerung mit den Teammitgliedern diskutiert werden. Zudem müssen in verschiedenen Teilbereichen nun weitere Entscheidungen getroffen werden. Dieser Bedarf an weiteren Entscheidungen ist bei der Erarbeitung des Grobkonzeptes aufgekommen. Ziele definieren Aus der Aufgabenstellung leiten sich nun die Ziele ab, die in der kommenden Besprechung erreicht werden sollen. Die Definition von Zielen ist notwendig, um den Erfolg einer Besprechung beurteilen zu können. Ohne definierte Ziele ist der Erfolg einer Besprechung gefährdet! Zur Definition dieser Ziele wird nach Antworten auf die folgende Frage gesucht: Was soll nach Beendigung der Besprechung erreicht worden sein? Auf Basis der zu lösenden Aufgabenstellung werden die Ziele definiert, die eine weitere Ausarbeitung des Pflichtenheftes ermöglichen. Beispiel: Zu lösende Aufgabe Das neue Konzept liegt in einer ersten Grobfassung vor und muss vor der weiteren Verfeinerung mit den Teammitgliedern diskutiert werden. Daraus abgeleitete Ziele Gemeinsame Verabschiedung des Konzeptes für die Realisierung des neuen Wareneingangs Zu lösende Aufgabe Zudem müssen in verschiedenen Teilbereichen nun weitere Entscheidungen getroffen werden. Dieser Bedarf an weiteren Entscheidungen ist bei der Erarbeitung des Grobkonzeptes aufgekommen. Speziell bei dem Ablauf der neuen Mengenkontrolle und der Anbindung an das bestehende Lagerverwaltungssystem sind noch Fragen offen. Daraus abgeleitete Ziele Abstimmung über Leistungsumfang und Zielsetzung der neuen Mengenkontrolle Definition des Integrationsgrades zwischen Mengenkontrolle und Lagersteuerung Stand: 14.05.2016 Version 0.93 Seite -80- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Themenliste erstellen Zur Erreichung der definierten Ziele müssen bestimmte Punkte besprochen werden. Hier werden Antworten auf die folgende Frage definiert: Welche Themen müssen besprochen werden, damit die gesetzten Ziele erreicht werden können? Beispiel: Definierte Ziele Gemeinsame Verabschiedung des Konzeptes für die Realisierung des neuen Wareneingangs Daraus abgeleitete zu besprechende Themen Vorstellung des neuen Gesamtkonzeptes Wareneingang Klärung der offenen Fragen Grundsätzliche Fragen zum Konzept/Ablauf Besprechung der offenen Fragen im Konzept Definierte Ziele Abstimmung über Leistungsumfang und Zielsetzung der neuen Mengenkontrolle Definition des Integrationsgrades zwischen Mengenkontrolle und Lagersteuerung Daraus abgeleitete zu besprechende Themen Die neue Mengenkontrolle im Wareneingang Vorstellung eines ersten Grobkonzeptes Möglichkeiten der Integration in die jetzige Lagersteuerung Teilnehmer festlegen Für eine erfolgreiche Besprechung ist neben einer guten thematischen Strukturierung der richtige Teilnehmerkreis wichtig. Hierbei handelt es u. U. nicht nur die direkt betroffenen Mitglieder des Teams, die bei der Pflichtenhefterstellung direkt mitarbeiten. Wer referiert über die zu behandelnden Themen? Wer kann helfen, die gesteckten Ziele zu erreichen? Wer muss zusätzlich informiert werden? Beispiel: zu besprechende Themen Vorstellung des neuen Gesamtkonzeptes Wareneingang Klärung der offenen Fragen Grundsätzliche Fragen zum Konzept/Ablauf Besprechung der offenen Fragen im Konzept daraus abgeleiteter Teilnehmerkreis Wer referiert? Herr Mahr (Er hat das Grobkonzept geschrieben.) Wer soll mitarbeiten? Herr Zulauf (Er hat die Grobkonzeption aus dem Bereich Organisation mit begleitet.) Stand: 14.05.2016 Version 0.93 Seite -81- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Frau Keil (Sie hat den fachlichen Input für die Grobkonzeption aus dem Bereich Logistik gegeben.) Wer muss informiert werden? (Oder dabei sein, um evtl. Entscheidungen zu treffen?) Herr Braun (Er ist für den Bereich der Entwicklung innerhalb der Warenwirtschaft zuständig.) Herr Klein (Er ist der Gesamtverantwortliche für den Bereich Logistik.) zu besprechende Themen Die neue Mengenkontrolle im Wareneingang Vorstellung eines ersten Grobkonzeptes Möglichkeiten der Integration in die jetzige Lagersteuerung daraus abgeleiteter Teilnehmerkreis Wer referiert? Herr Mahr (Er hat das Grobkonzept geschrieben.) Wer soll mitarbeiten? Herr Zulauf (Er hat die Grobkonzeption aus dem Bereich Organisation mit begleitet.) Frau Keil (Sie hat den fachlichen Input für die Grobkonzeption aus dem Bereich Logistik gegeben.) Wer muss informiert werden? (Oder dabei sein, um evtl. Entscheidungen zu treffen?) Herr Klein (Er ist der Gesamtverantwortliche für den Bereich Logistik) Herr Zulauf (Seine Firma YXZ GmbH betreut das aktuelle eingesetzte Lagersteuerungssystem.) 5.1.2 Aufbau einer Agenda Wie wird es gemacht? Nachdem alle notwendigen Inhalte der Agenda erarbeitet worden sind, muss der Inhalt noch in eine Struktur gebracht werden. Eine Agenda kann den folgenden Aufbau haben: Aufbau einer Agenda Agenda Organisatorisches Themenliste Ziele Stand: 14.05.2016 Version 0.93 Seite -82- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Folgende Informationen sollten auf einer Agenda mindestens enthalten sein: Organisatorisches Datum Zeit Ort Teilnehmer Firma / Abteilung Themenliste Thema Referent Zeit Ziele Ziele Stand: 14.05.2016 Das Datum, an dem die Besprechung stattfinden wird. Der Zeitraum, in dem diese Besprechung stattfinden wird. (von-bis) Der Ort an dem die Besprechung stattfinden wird. Der Name der Teilnehmer der Besprechung. Damit ein einheitliches Bild nach außen geboten wird, sollte bei der Agenda darauf geachtet werden, dass die Teilnehmer mit "Herr" oder "Frau" oder mit Vor- und Nachname genannt werden. Um zu vermeiden, dass sich keiner zurückgesetzt fühlt, sollten die Namen nach dem Alphabet geordnet werden. Für den Protokollanten ist es hilfreich, vor jedem Namen auf der Agenda ein „“ zu setzen. So kann zu Beginn der Besprechung dort schnell vermerkt werden, wer tatsächlich gekommen ist. Die Firma des Teilnehmers. Diese Information ist nur dann sinnvoll, wenn die Besprechungen mit externen Mitarbeitern bzw. mit Mitarbeitern unterschiedlicher Firmen durchgeführt werden. Anstelle der Firma kann bei einer internen Agenda auch die Abteilung genannt werden. Eine kurze Beschreibung welches Thema besprochen werden soll. Sollten zu einem Thema mehrere Punkte besprochen werden, kann für jeden Punkt eine separate Überschrift eingefügt werden. Hier den Teilnehmer eintragen, der dieses Thema vortragen wird. Sollten Themen in der Gruppe diskutiert werden, kann als Referent auch „Teilnehmer“ oder „Gruppe“ oder „Team“ eingetragen werden. Hier die vorgesehene Zeit für die Behandlung dieses Themas eintragen. Setzen Sie sich als Ziel diese Vorgabe zu erreichen. Im Laufe der Zeit wird dann durch die Erfahrung im Umgang mit den zu behandelnden Themen und Teilnehmern diese Schätzung immer genauer. Hier sollten die gewünschten Arbeitsergebnisse für das Ende der Besprechung eingetragen werden. Es können hierbei mehrere Ziele in einer Besprechung erreicht werden. Version 0.93 Seite -83- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 5.1.3 Beispiel für eine Agenda Auf Basis der Beispiele ist die nachfolgende Agenda entstanden. AGENDA – Neue Wareneingangssteuerung Datum Zeit Ort 03.12.1999 10:00 – 12:30 C 12.03 Teilnehmer Herr Braun Frau Keil Herr Klein Herr Mahr Herr Zulauf Teilnehmer Abt. IV Abt. Logistik Logistikleitung Abt. Orga Yxz GmbH Themen Themen Vorstellung des neuen Gesamtkonzeptes Wareneingang Klärung der offenen Fragen Referent Zeit Herr Mahr 30 Min. Herr Mahr 1 Std. Herr Zulauf Frau Keil 1 Std. Grundsätzliche Fragen zum Konzept/Ablauf Besprechung der offenen Fragen im Konzept Die neue Mengenkontrolle im Wareneingang Vorstellung eines ersten Grobkonzeptes Möglichkeiten der Integration in die jetzige Lagersteuerung Ziele Gemeinsame Verabschiedung des Konzeptes für die Realisierung des neuen Wareneingangs Abstimmung über Leistungsumfang und Zielsetzung der neuen Mengenkontrolle Definition des Integrationsgrades zwischen Mengenkontrolle und Lagersteuerung Eine direkt verwendbare Vorlage für eine Agenda finden Sie in unserem Downloadbereich. Sollten Sie Vorschläge für Erweiterungen der Agenda haben - schreiben Sie uns! Stand: 14.05.2016 Version 0.93 Seite -84- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 5.2 Das Protokoll Worum geht es? Ein altes Sprichwort sagt: „Wer schreibt der bleibt.“ Diese „Weisheit“ ist gerade im Bereich der Softwareentwicklung ein nicht zu vernachlässigender Sachverhalt. Vielfach werden Gelder verschwendet, weil Vereinbarungen oder Arbeitsergebnisse nicht schriftlich fixiert wurden und jeder mit seiner Interpretation eines Sachverhaltes im Projektverlauf arbeitet. Die von vielen als lästig angesehene schriftliche Fixierung von Sachverhalten und Besprechungsergebnissen ist für eine professionelle und effiziente Arbeit unabdingbar! Aus diesem Grunde ist notwendig schon zu Beginn der Arbeit an einem Pflichtenheft die Protokollierung von Sitzungen konsequent durchzuführen. Der Protokollant hat hier eine wichtige Aufgabe. Sie besteht in der vollständigen und wahrheitsgemäßen Aufzeichnung des Gespräches. Diese Aufgabe ist jedoch nicht immer einfach zu erfüllen. Es ist mitunter schwierig, einem Gesprächsverlauf über längere Strecken zu folgen und nur die wirklich wichtigen Stellen niederzulegen. Um diese Aufgabe richtig zu erfüllen hilft eine Agenda die im Vorfeld der Sitzung verteilt worden ist gut weiter. (siehe Kapitel 5.1 Die Agenda, Seite 77) Sie dient den Teilnehmern der Sitzung als Fahrplan und hilft dem Protokollanten beim Protokollieren weiter. Aus diesem Fahrplan geht zudem hervor, welcher Art das Protokoll der Sitzung sein wird. Es werden zwei Arten von Protokollen unterschieden. Ergebnisprotokolle Werden immer dann geschrieben, wenn Sachverhalte mit Terminen und Verantwortlichkeiten festgehalten werden sollen. Bei der Pflichtenhefterstellung werden diese Protokolle genutzt, wenn in einer Sitzung „Arbeit verteilt wird“. Diese Form der Protokollierung hat sich bei der Pflichtenhefterstellung gut bewährt. Sitzungsprotokolle Werden immer dann geschrieben, wenn Arbeitsergebnisse aus einer Sitzung niedergelegt werden sollen. Dies ist immer dann der Fall, wenn gemeinsam ein neues Thema erarbeitet wird. Falls diese Form der Protokollierung genutzt wird, sind diese Protokolle bei der Pflichtenhefterstellung meist die Vorstufe zur konzeptionellen Arbeit. Ein effizienterer Weg ist jedoch, Arbeitsergebnisse direkt in der Form eines Pflichtenheftes niederzulegen. Auf diese Weise wird die Übertragung der Inhalte des Sitzungsprotokolls in das Pflichtenheft gespart. Was bringt es? Protokolle schaffen Sicherheit und Verbindlichkeit. D. h. mit der schriftlichen Fixierung einer Sitzung werden die dort erarbeiteten Ergebnisse festgeschrieben. Diese ist insbesondere immer dann wichtig, wenn es gilt Vereinbarungen, die in einer Sitzung getroffen worden sind umzusetzen oder einfach nur nachzuhalten. Gerade im Bereich der Softwareentwicklung können Entscheidungen der Geschäftsleitung und der Fachabteilungen grundlegenden Einfluss auf die Gestaltung des Pflichtenheftes haben. Aus diesem Grunde sind neben einem eindeutig formulierten Projektauftrag die Protokolle von Sitzungen eine wichtige Informationsquelle für die Pflichtenhefterstellung. Stand: 14.05.2016 Version 0.93 Seite -85- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Zudem besteht z. B. mit einem Ergebnisprotokoll die Möglichkeit, eine definitive Zuordnung von Terminen und Verantwortlichkeiten zu Aktivitäten vorzunehmen. Diese schriftliche Festlegung hilft neben der Kontrolle der Umsetzung auch dabei, dass jeder Empfänger des Protokolls, die ihm zugeordneten Aktivitäten auch bearbeitet. Spätestens bei der nächsten Sitzung wird mit der Besprechung des Protokolls der Status seiner Aktivität abgefragt. Auf diese Weise lassen sich auch nicht so hoch motivierte Mitarbeiter zur Zusammenarbeit bewegen. Nichts ist peinlicher, als bei einer Protokollbesprechung zum wiederholten Male keinen Vollzug bei seinen Aktivitäten vermelden zu können. Gerade bei Sitzungen, die sich ständig wiederholen trägt eine Protokollierung sehr zur Steigerung der Effizienz bei. Zum einen ist ein bereits vorliegendes Protokoll aus der letzten Sitzung eine gute Informationsquelle, um eine Agenda für die nächste Sitzung zu erstellen. Zum anderen wird die Disziplin bei einer Sitzung durch die strukturelle Vorgabe des Protokolls gut unterstützt. Die einzelnen Themen werden Punkt für Punkt durchgegangen und bearbeitet. Auf diese Weise kann jeder Teilnehmer den Fortschritt der Besprechung nachvollziehen. Das schafft auch Motivation bei den Teilnehmern, weil die Gefahr abzuschweifen deutlich vermindert wird. Im Laufe der Erstellung eines Pflichtenheftes müssen bestimmte Entscheidungen getroffen werden. Leider kommt es immer wieder vor, das bei „unglücklichen“ Entscheidungen keiner der Teammitglieder Verantwortung mit übernehmen will. So kann die Situation entstehen, das der Autor des Pflichtenheftes u. U. allein da steht. Mit Hilfe einer fortlaufenden Protokollierung kann leicht nachgewiesen werden, welche Mitarbeiter mit in die Entscheidung der Pflichtenhefterstellung eingebunden gewesen sind. Auf diese Wiese wird sichergestellt, das die gemeinschaftlich getroffenen Entscheidungen auch gemeinschaftlich getragen werden. Protokolle sind auch eine gute Möglichkeit festzustellen, wie effektiv das Team arbeitet. Anhand von Protokollen lässt sich eine Projektentwicklung gut nachvollziehen. Voraussetzung ist natürlich die kontinuierliche Protokollierung von Besprechungen. Die Effizienz bei der Erstellung eines Pflichtenheftes lässt sich z. B daraus ableiten, wie häufig gleichartige Probleme in den Protokollen immer wieder auftauchen. Dies können z. B. Probleme fachlicher Natur sein. Zudem zeigt eine Protokollierung auf, wenn bestimmte Entscheidung nicht bzw. im Laufe der Pflichtenhefterstellung immer wieder anders getroffen werden. Mit solchen Informationen bieten Protokolle gute Ansatzpunkte, die Pflichtenhefterstellung effektiver zu gestalten. 5.2.1 Effiziente Protokollierung Wie wird es gemacht? Jeder, der sich in der Situation befindet, Protokolle schreiben zu müssen, wird früher oder später darüber nachdenken, die Protokollierung während der Sitzung direkt am Laptop vorzunehmen. Der Wunsch ist es, auf diese Weise Zeit zu sparen. Die Erfahrung hat aber gezeigt, dass von dieser Form der Protokollierung nur abzuraten ist. Die Gründe hierfür liegen einerseits im Erfassungsmedium. Die meisten Protokollanten besitzen keine ausreichenden Schreibmaschinenkenntnisse. Aus diesem Grunde ist die Geschwindigkeit der Protokollierung damit unzureichend. D. h. der Protokollant hat keine Möglichkeit, die zur Protokollierung bestimmten Informationen in der notwendigen Geschwindigkeit aufzunehmen. Dies hat gravierende Auswirkungen auf den Inhalt des Protokolls. Während der Protokollant noch mit der Textverarbeitung oder seiner Formulierung Stand: 14.05.2016 Version 0.93 Seite -86- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc kämpft, geht das Gespräch weiter. So besteht die Gefahr, dass weitere wichtige Informationen nicht aufgenommen werden. Andererseits wird in einem Gespräch häufig zwischen verschiedenen Themen gesprungen. Bei einem handschriftlich verfassten Protokoll können schnell Anmerkungen zu den bereits besprochenen Themen hinzugefügt werden. Bei längeren Sitzungen, bei denen sich das Protokoll über mehrere Seiten erstreckt, sucht der Protokollant in seinem Laptop zumeist sehr viel länger die richtige Stelle. Die Gefahr besteht auch hier, dass wichtige Teile des Gesprächs beim Kampf mit der Technik verpasst werden. Der vielleicht wichtigste Grund für eine nachträgliche Protokollierung eines handschriftlich verfassten Protokolls ist, das der Protokollant die einzelnen Themen bei der Eingabe ins Laptop noch einmal Revue passieren lassen kann. Auf diese Weise hat er die Möglichkeit, nicht niedergelegte Informationen nach zu erfassen bzw. eindeutigere Formulierung für die niedergeschriebenen Sachverhalte zu finden. Es besteht so für ihn die Möglichkeit, über die Sitzung noch einmal nachzudenken. Bei einem während einer Sitzung verfassten Protokoll mit Hilfe eines Laptops, besteht diese Möglichkeit nur zu einem sehr geringen Teil. Der Grund liegt darin, dass die Konzentration des Protokollanten bei dieser Vorgehensweise dreigeteilt ist. Neben dem Verfolgen des Gesprächsverlaufs muss er sich um sein Laptop und um die Formulierung der Sachverhalte kümmern. Die hat maßgebliche Auswirkungen auf Struktur und Inhalt des Protokolls. Wohlmöglich soll dann das Protokoll dann auch noch direkt am Ende der Sitzung an die Teilnehmer überreicht werden. Damit ist das Protokoll nicht nur unvollständig, sondern zumeist auch noch fehlerhaft. Viele wertvolle Informationen gehen so verloren. Auch die Teilnehmer der Sitzung haben keine Zeit die Sitzung noch einmal selber innerlich durchzugehen. Als Folge werden solche Protokoll gar nicht oder nur oberflächlich gelesen. Der Sinn einer Protokollierung ist somit nicht erreicht worden. 5.2.2 Schlechte Protokollierung erkennen Wie wird es gemacht? Ein gutes von einem schlechten Protokoll zu unterscheiden ist nicht sehr schwer. Es gibt verschiedene Anzeichen, die eindeutig für eine schlechte Protokollierung sprechen: Die Informationen zu den einzelnen Punkten sind spärlich. Die Sätze haben keine Überleitungen und wirken unzusammenhängend. Sie wirken daher eher wie Aufzählungen, anstatt wie Beschreibungen. Komplexe Sachverhalte werden nur in Stichworten wiedergegeben. Nur Teilnehmer der Sitzung können verstehen, was die Inhalte des Protokolls genau wiederzugeben versuchen. Nach einiger Zeit ist das Protokoll nicht mehr zu verwerten, weil man aus den bruchstückhaften Informationen den ursprünglichen Zusammenhang nicht mehr herleiten kann. Stand: 14.05.2016 Version 0.93 Seite -87- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Neben diesen inhaltlichen Aspekten gibt es auch formale Aspekte, die auf eine schlechte Protokollierung hinweisen. Es fehlt die Auflistung der Teilnehmer der Sitzung oder sie ist unvollständig. Ein Verteiler wird nicht erwähnt, obwohl es einen gibt. Zeit, Ort und Dauer der Sitzung sind nicht vermerkt. Es wird keine einheitliche Protokollvorlage genutzt. Das Protokoll wird formlos z. B. per Email versendet. Ein weiterer Punkt, der für eine schlechte Protokollierung spricht, ist ein großer Zeitversatz zwischen der Verteilung des Protokolls und dem Datum der protokollierten Sitzung. Hier gilt als Faustregel: Die Protokollierung einer Sitzung sollte nicht später als 2 Werktage durchgeführt werden. Ist zwischen Sitzung und Protokollierung noch ein Wochenende können aus den 2 Werktagen leicht 4 Zeittage werden. Mit jedem Tag, der zwischen der Protokollierung einer Sitzung und der Aufbereitung in Form eines Protokolls verstreicht, sinkt die Qualität des Protokolls. Der Protokollant vergisst Dinge, die nicht aufgeschrieben wurden, andere können aus den handschriftlichen Unterlagen nicht mehr genau hergeleitet werden. Alle diese Punkte zeigen, dass sich ein professionell erstelltes Protokoll einfach von einem schlechten unterscheiden lässt. 5.2.3 Inhalt eines Protokolls erarbeiten Wie wird es gemacht? Protokolle schreiben ist keine angeborene Begabung. Man benötigt zur effizienten Erstellung eines Protokolls Erfahrung und eine Menge Übung. Anfänger neigen dazu, Gespräche Wort für Wort mitzuschreiben. Dies mag bei Gericht sinnvoll sein, für die Pflichtenhefterstellung ist diese Form der Dokumentation eher hinderlich. Das Protokoll sollte weder aus einer Menge Prosa noch aus der Ansammlung von Stichworten bestehen. Es gilt einen Mittelweg zwischen den beiden Extremen zu finden. Hierzu ist es hilfreich als Protokollant eine feste Struktur bei der Protokollierung der besprochenen Themen einzuhalten. Folgende Fragen müssen jedem zu protokollierenden Punkt gestellt werden: WAS – (Thema) Damit der protokollierte Sachverhalt im Protokoll einfach wiedergefunden werden kann, sollte jedem Sachverhalt ein Thema oder Stichwort zugeordnet werden. Die Betonung liegt hierbei auf Stichwort. Beispiele aus einem Protokoll: Avisierung Importabwicklung Installation Terminalemulation Schnittstellen I Schnittstellen II (Diese Unterteilung ist z. B. dann sinnvoll, wenn das gleiche Thema aus verschiedenen Blickwinkeln betrachtet wird.) MACHT GENAU – (Beschreibung) Stand: 14.05.2016 Version 0.93 Seite -88- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Zu jedem Thema oder Stichwort gehört eine ausreichende Beschreibung. Diese zunächst recht schwammig erscheinende Definition lässt sich leicht konkretisieren. Bei einer Beschreibung in einem Ergebnisprotokoll ist es wie mit einem guten Whiskey –2 Fingerbreit sind ausreichend– mehr sind zuviel. Erstreckt sich also die Beschreibung eines Themas über mehr als diese Größe, sollte das Thema aufgeteilt werden. Meist stellt sich bei genauerer Betrachtung sowieso heraus, dass eine umfangreiche Beschreibung mehrere Sachverhalte eines Themas umfasst. In diesem Fall kann das Thema mit einem zusätzlichen Stichwort oder einer Nummerierung versehen werden. WER – (Zuständigkeit) Für jedes Thema sollte eine Zuständigkeit definiert werden. Diese Vorgehensweise ist sinnvoll um Verbindlichkeit zu schaffen. Zuständigkeiten sind allerdings nur dann sinnvoll, wenn zu dem protokollierten Thema auch weitere Aktivitäten folgen. Themen die abgeschlossen sind und deren Abschluss protokolliert wird, sollten nicht mit einer Zuständigkeit versehen werden. Sollte mehr als eine Person für Aktivitäten eines Themas zuständig sein, kann auch dies als Hinweis dienen, das Thema auf Aktivitäten hin zu untersuchen und evtl. aufzuteilen. BIS WANN – (Termin) Wie bei den Zuständigkeiten gilt auch für Termine – kein Thema ohne Termin! Einzige Ausnahme bilden die abgeschlossenen Themen. Häufig kommt es in Sitzungen vor, das man Themen zwar genau bespricht, jedoch nach der Zuteilung der Verantwortlichkeit die Definition eines Termins vergisst. Sollte in einer Sitzung zu einem Thema kein Termin vereinbart sein, jedoch dort Aktivitäten folgen, so sollte die mit dem Vermerk „Termin offen“ gekennzeichnet werden. Dieser Entrag misst auch die Effizienz der Besprechung! Sind alle Teilnehmer auf die Sitzung gründlich vorbereitet, dann dürfte es kaum offene Termine geben. Je mehr offene Termine es gibt, desto unbefriedigender war die Sitzung. Denn zur Festlegung der Termine wird mindestens ein weiteres Zusammentreffen der Teilnehmer notwendig sein. Bis dahin sind aber meist dann keine Aktivitäten gestartet worden um das Thema abzuarbeiten. 5.2.4 Protokollvorlagen nutzen Wie wird es gemacht? Damit die Protokollierung leichter fällt, sollte während der Sitzung bereits eine BlankoProtokollvorlage für die manuelle Erfassung des Protokolls genutzt werden. Auf diese Weise hat der Protokollant die Möglichkeit, schon während der Protokollierung die spätere Struktur des Protokolls einzuhalten. Zudem unterstützt eine Protokollvorlage die systematische Protokollierung einer Sitzung. Die wichtigsten Punkte werden so nicht vergessen. Ein weißes Blatt Papier ist für eine Protokollierung eher ungeeignet. Es hat den Nachteil, das die fehlende Strukturierung des Blattes dazu verleitet „einfach loszulegen“. Diese Vorgehensweise hat zum Ergebnis, dass die spätere Struktur und Systematik des Protokolls aus den dann meist unstrukturierten Notizen - erst wieder extrahiert werden muss. Mit Hilfe einer Protokollvorlage lässt sich dieser unnötige Zusatzaufwand vermeiden. Eine BlankoProtokollvorlage finden Sie in unserem Downloadbereich. Stand: 14.05.2016 Version 0.93 Seite -89- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 5.2.5 Aufbau eines Ergebnis-Protokolls Wie wird es gemacht? Ein Protokoll hat eine genau definierte Struktur. Es besteht aus einem organisatorischen und einem inhaltlichen Teil. Der organisatorische Teil des Protokolls ist hierbei zweigeteilt. Der erste Teil befasst sich mit der protokollierten Sitzung. Dort werden u. a. Teilnehmer, Datum, Raum usw. definiert. Der zweite Teil umfasst Dinge, die sich mit der Erstellung des Protokolls und der darauffolgenden Sitzung beschäftigen. Im inhaltlichen Teil werden die Dinge niedergelegt, die während der Sitzung besprochen worden sind. Aufbau eines Protokolls Organisatorisches Inhalt Organisatorisches Folgende Informationen sollten im Protokoll enthalten sein: Organisatorisches I Teilnehmer Die Namen der Teilnehmer, die an der Besprechung teilgenommen haben. Damit ein einheitliches Bild nach außen geboten wird, sollte beim Protokoll darauf geachtet werden, dass die Teilnehmer mit "Herr" oder "Frau" oder mit Vor- und Nachname genannt werden. Um zu vermeiden, dass sich keiner zurückgesetzt fühlt, sollten die Namen nach dem Alphabet geordnet werden. Verteiler Hier werden die Mitarbeiter genannt, die an der Sitzung nicht teilgenommen haben, jedoch Kenntnis von den niedergelegten Ergebnissen erhalten sollen. Projekt Bei Projektsitzungen sollte der Titel des Projektes aus jedem Protokoll ersichtlich sein. Damit kann ein Protokoll einem Projekt eindeutig zugeordnet werden. Bei der Pflichtenhefterstellung können Sie z. B. den Titel des Pflichtenheftes als Referenz benutzen. Anlass Jede Sitzung hat einen bestimmten Anlass. Der jeweilige Anlass einer Sitzung hilft bei einer umfangreichen Protokollierung, die einzelnen Sitzungen später besser zuzuordnen. Dies ist immer dann wichtige, wenn bestimmte Entscheidungen nachgeschlagen werden müssen. Hier einige Beispiele: Abstimmung mit der Fachabteilung Vorstellung erster Konzepte Abstimmung weiterer Vorgehensweise Statusmeeting Stand: 14.05.2016 Version 0.93 Seite -90- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Organisatorisches I Datum Zeit Ort Organisatorisches 2 Datum Zeit Ort Protokolliert von Protokolliert am Der Tag an dem die Sitzung stattgefunden hat. Der Zeitraum, innerhalb dessen die Sitzung abgehalten worden ist. (von – bis) Der Ort, an dem die Sitzung stattgefunden hat. (z. B. Raum M12) Das Datum, an dem die nächste Sitzung stattfinden soll. Die Uhrzeit, an dem die nächste Sitzung stattfinden soll Der Ort bzw. Raum in dem die nächste Sitzung stattfinden soll. Name desjenigen, der das Protokoll erstellt hat. Datum an dem das Protokoll geschrieben worden ist. Hiermit kann dokumentiert werden, wie zeitnah nach Ende der Sitzung die Protokollierung vorgenommen worden ist. 5.2.6 Struktur des Inhaltes Wie wird es gemacht? Struktur Strukturdes desInhaltes Inhaltes Thema Beschreibung Was? Macht genau? Zuständig Wer? Termin Wann? Inhalt Thema Beschreibung des Themas zuständig Ein Stichwort, welches das protokollierte Thema treffend beschreibt. Eine kurze Beschreibung was zu dem Thema besprochen worden ist. Sollten zu einem Thema mehrere Punkte zu besprechen sein, kann in der Beschreibung zu dem Thema für jeden Punkt eine separate Überschrift in der Beschreibung eingefügt werden. Für die niedergelegten Punkte müssen Mitarbeiter bestimmt werden, die für die Lösung der Aufgabe zuständig sind oder hierfür als Ansprechpartner dienen. In der Vorlage ist der eigentliche Inhalt des Ergebnisprotokolls als Tabelle definiert worden. Sollten die Themen zu umfassend dokumentiert sein, wird ein sehr zerklüftetes Erscheinungsbild des Protokolls die Folge sein. Themen, die mehr als eine Seite umfassen, können in einer Tabelle nicht korrekt dargestellt werden. Diese Beschränkung ist bewusst in diese Protokollvorlagen eingebaut worden. Sie soll helfen, die Dimensionierung bei Beschreibung der einzelnen Themen richtig vorzunehmen. Stand: 14.05.2016 Version 0.93 Seite -91- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Die nachfolgenden Grafiken zeigen, wie abhängig das Layout des Ergebnis-Protokolls von der Aufteilung der einzelnen Themen ist. Falsche Aufteilung der Themen Zu große Themenblöcke definiert. Platzverschwendung durch falsche Formatierung Die einzelnen Blöcke sind zu groß definiert. Die Tabellenfunktion von Word sorgt auf diese Weise für ein sehr unregelmäßiges Seitenlayout. Richtige Aufteilung der Themen Die Aufteilung der Themen in kleinere Einheiten sorgt dafür, dass das Protokoll kein zerklüftetes Seitenlayout aufweist. Stand: 14.05.2016 Version 0.93 Seite -92- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 5.2.7 Beispiel für ein Ergebnis-Protokoll Wie bereits beschrieben, basiert ein Protokoll auf einer Sitzung. Die dort diskutierten Sachverhalte werden im Protokoll niedergeschrieben. Somit ist für das volle Verständnis des Protokolls eigentlich auch die Teilnahme an dieser Sitzung notwendig. Das ist in diesem Fall nicht möglich. Es besteht nur die Möglichkeit, die Rolle eines Mitarbeiters einzunehmen, der auf dem Verteiler steht und so versucht, die Sitzung anhand des Protokolls nachzuvollziehen. Um die einzelnen Punkte verständlicher zu machen, ist jedem Thema eine kurze Information „“ hinzugefügt worden. Der nachfolgende Auszug des Ergebnis-Protokolls ist auf Basis der Beispiel-Agenda (siehe Kapitel 5.1.3 Beispiel für eine Agenda, Seite 84) entstanden. Teilnehmer Herr Braun Frau Keil Herr Klein Herr Mahr Herr Zulauf Verteiler Herr Meier Abt. IV Abt. Logistik Logistikleitung Abt. Orga Yxz GmbH Abt. Systeme Ergebnis-Protokoll Projekt Neue Wareneingangssteuerung Anlass Vorstellung Grobkonzept/Klärung offener Fragen Datum 06.11.2000 Zeit 10:00 – 12:30 Ort Raum C 12.03 THEMA Grobkonzept neuer WE BESCHREIBUNG DES THEMAS ZUSTÄNDIG Das Grobkonzept ist von Herrn Mahr vorgestellt worden. Die Team beschriebenen Abläufe wurden diskutiert und vom Team befürwortet. Die weitere Arbeit an dem Pflichtenheft wird die Grobkonzeption als Vorlage dienen. Festschreibung einer Entscheidung, die in dieser Sitzung vom Team getroffen wurde und maßgeblichen Einfluss auf das weitere Projekt haben wird. EntwickAktuell wird in der Entwicklung die Version „1“ eingesetzt. Für Team die Entwicklung des neuen Wareneingangs (WE) soll die lungsumgebung aktuelle Version der Entwicklungsumgebung „3.3“ genutzt werden. Gemeinsam getroffene Entscheidung des Teams. Diese Entscheidung hat Auswirkungen auf die technische Integration der neuen Anwendung in die bestehende Landschaft. Stand: 14.05.2016 Version 0.93 Seite -93- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc THEMA Neuer Server BESCHREIBUNG DES THEMAS ZUSTÄNDIG Für die Installation der neuen Entwicklungsumgebung muss ein Herr Meyer neuer Server installiert werden. Termin: Ende 46. KW Delegation einer Aufgabe an einen Mitarbeiter, der nicht Teilnehmer der Sitzung war. Aus diesem Grund ist sein Name mit in den Verteiler aufgenommen worden. Grafische Das jetzige Warenwirtschaftssystem läuft in einer 3270- Team Benutzer- Terminalemulation. Die neue WE-Abwicklung soll als erster oberfläche Teilbereich unter einer grafischen Benutzeroberfläche laufen. Gemeinsam getroffene Entscheidung des Teams. Diese Entscheidung hat Auswirkungen auf die Gestaltung der Benutzeroberfläche im Pflichtenheft. Funkscanner Die Mengenkontrolle soll zukünftig mit Funkscannern Herr Mahr ausgestattet werden. Um das richtige Gerät auszuwählen werden die verschiedenen Hersteller angeschrieben und zu Präsentationen eingeladen. Termin 17.11.2000 Diese Entscheidung mit Termin ist an einen Teilnehmer der Sitzung delegiert worden. In der nächsten Sitzung müsste Herr Mahr bereits Vollzug melden können. Neue Schnittstelle LVS Das Lagerverwaltungssystem (LVS) nutzt z. Z. eine Herr Zulauf Individualschnittstelle zur bestehenden WE-Abwicklung. Die neue WE-Abwicklung soll die Standardschnittstelle an das LVS nutzen. Hierzu wird die Schnittstellenbeschreibung an Herrn Mahr übergeben. Termin: 10.11.2000 Diese Aktivität mit Termin ist an einen Teilnehmer der Sitzung delegiert worden. In der nächsten Sitzung müsste Herr Zulauf bereits Vollzug melden können. Mitarbeiter Wareneingang bestimmen ... Für die weiteren konzeptionellen Arbeiten benötigt Herrn Mahr Herr Klein einen Mitarbeiter aus der Mengenkontrolle. Dieser Mitarbeiter soll Herrn Mahr bei der Erstellung der Benutzeroberfläche unterstützen. Frau Keil kann diese Aufgabe nicht wahrnehmen, da Sie aktuell mit Inventurvorbereitungen beschäftigt ist. Termin: 10.11.2000 Diese Aktivität mit Termin ist an einen Teilnehmer der Sitzung delegiert worden In der nächsten Sitzung müsste Herr Klein bereits Vollzug melden können. Weitere Themen, die in dieser Sitzung besprochen worden sind. Nächste Sitzung Datum 20.11.2000 Zeit 10:00-13:00 Ort Raum C 12.03 Protokolliert am: 07.11.2000 Peter Braun Abteilung IV Durchwahl 329 Stand: 14.05.2016 Version 0.93 Seite -94- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 6 Projektablauf der Pflichtenhefterstellung Worum geht es? Zur Erstellung eines Pflichtenheftes sind neben einer bewährten Methode zur Umsetzung von Anforderungen aus den Fachabeilungen zusätzliche organisatorische Maßnahmen notwendig. Diese Maßnahmen helfen, den Erfolg der Arbeit sicherzustellen und bilden die Grundlage für die Zusammenarbeit zwischen Berater und Fachabteilung. Viele solcher Maßnahmen sind in der einschlägigen Literatur zum Thema Projektmanagement ausführlich behandelt worden. Aus diesem Grunde beschränkt sich diese Ausarbeitung auf die für die Pflichtenhefterstellung wesentlichen Informationen und Verfahren. Wie jedes andere Projekt durchläuft das Pflichtenheft bei der Entstehung einen Lebenszyklus. (Mit Lebenszyklus ist allerdings nicht gemeint, dass nach der Fertigstellung das Pflichtenheft „tot“ ist. Es kann während der Realisierung angepasst bzw. für eine Weiterentwicklung erweitert werden.) Der Lebenszyklus eines Pflichtenheftes gliedert sich wie folgt: Stand: 14.05.2016 Version 0.93 Seite -95- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Was bringt es? Die Einteilung der Arbeit an einem Pflichtenheft in einzelne Abschnitte erleichtert die Organisation der gesamten Arbeit. Jeder Abschnitt hat einerseits bestimmte Tätigkeiten, die durchgeführt werden müssen. Andererseits müssen in jedem Teilabschnitt bestimmte Ziele erreicht werden, um den nächsten Schritt durchführen zu können. Die nachfolgende Beschreibung soll Anhaltspunkte für jeden Teilschritt geben. Diese Anhaltspunkte können dann in Form einer Checkliste angearbeitet werden. Auf diese Weise wird die Basis für eine effektive und qualitativ hochwertige Arbeit geschaffen. 6.1 Der Auftrag zur Erstellung eines Pflichtenheftes 1 Auftrag zur Pflichtenhefterstellung KickoffVeranstaltung Organisatorische Vorarbeiten Worum geht es? Die Erstellung eines Pflichtenheftes erfolgt immer in einem bestimmten Rahmen. Dies kann zum einen ein Projekt sein, bei dem das Pflichtenheft Teil einer umfassenderen Aufgabe ist. Zum anderem kann die Erstellung auch ein eigenes Projekt sein. Unabhängig von der Einbettung der Pflichtenhefterstellung in einen organisatorischen Rahmen, sollte der Autor des Pflichtenheftes seine Arbeit wie ein Projekt organisieren. Dies hat den Vorteil das ihm alle Mechanismen des Projektmanagements zur Verfügung stehen. Der Auftraggeber initiiert die Erstellung des Pflichtenheftes und stellt die notwendigen Mittel für die Umsetzung bereit. Der Autor des Pflichtenheftes ist in diesem Fall wie ein Projektleiter anzusehen. Er übernimmt die Rolle des Gesamtverantwortlichen. Beide Seiten haben während der Erstellung des Pflichtenheftes bestimmte Aufgaben und Erwartungen. Diese gilt es zu dokumentieren und fest zu schreiben. In der Projektarbeit wird dies mit Hilfe eines Projektauftrags getan. Bei der Pflichtenhefterstellung ist ein ähnliches Konstrukt hilfreich. Um eine Abgrenzung zu dem bereits belegten Begriff des Projektauftrages herbeizuführen, wird nachfolgend der Begriff Auftrag benutzt. Der Auftrag ist eine Vereinbarung zwischen dem Auftraggeber und dem Autor des Pflichtenheftes. Dort werden die Rahmenbedingungen definiert, unter denen das Pflichtenheft erstellt werden soll. Der Auftraggeber definiert seine Anforderungen an Inhalt des Pflichtenheftes. Der Autor definiert seine Anforderungen, damit er das Pflichtenheft erfolgreich erstellen kann. Der Auftrag dient für beide Seiten auch als Meßlatte für die erfolgreiche Erstellung des Pflichtenheftes. Allein die Fertigstellung des Pflichtenheftes innerhalb eines definierten Zeitraumes ist kein Indiz für die erfolgreiche Fertigstellung. Das Pflichtenheft ist erst dann fertig, wenn alle Ziele erreicht worden sind. Neben rein zeitlichen Aspekten kommen hier monetäre und funktionale Aspekte hinzu. Aus diesem Grunde müssen alle Kriterien, die an das Pflichtenheft bzw. dessen Erstellung gestellt werden, Teil des Auftrages sein. Stand: 14.05.2016 Version 0.93 Seite -96- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Häufig kommt es vor, dass der Auftraggeber nicht von selbst auf die Idee kommt, für die Erstellung eines Pflichtenheftes einen Auftrag zu definieren. In solch einem Fall sollte der Autor auf den Auftraggeber zukommen. Es kann allerdings passieren, dass der Auftraggeber mit Unverständnis reagiert. Es können Aussagen kommen, wie: "Wir haben doch alles besprochen, wozu noch einmal alles aufschreiben?" oder "Machen Sie doch nicht gleich alles so kompliziert!" Dies sind ganz natürliche Reaktionen aus Firmen, in denen sich eine projektorientierte Vorgehensweise noch nicht in aller Konsequenz durchgesetzt hat. In Situationen wie dieser muss dann Überzeugungsarbeit geleistet werden. Am einfachsten ist es, den Entwurf des Auftrages vorzubereiten. Dies hat zwei Vorteile. Zum einen hat der Autor des Pflichtenheftes so die Möglichkeit, seine Sicht der Dinge zu formulieren. Zum anderen spart sich der Auftraggeber die Mühe, selbst einen Auftrag zu schreiben. Externe Berater sollten jedes Ihrer Pflichtenhefte über einen Auftrag absichern. Nur so kann gewährleistet werden, dass die zu leistende Arbeit unter einem gemeinsamen Verständnis erfolgt. Bevor mit der Arbeit an dem Pflichtenheft begonnen wird, sollte der ausgearbeitete und unterschriebene Auftrag vorliegen. Was bringt es? Der Auftrag schafft Sicherheit auf beiden Seiten. Dem Auftraggeber ist es auf diese Weise möglich, alles das was er von dem Pflichtenheft wünscht, als Teil des Auftrages zu definieren. So ist schon vor Beginn der Arbeit klar festgelegt, was von dem Autor erwartet wird. Probleme mit Nachforderungen oder Unzufriedenheit nach oder während der Erstellung des Pflichtenheftes sollten so fast ausgeschlossen sein. Jeder der im Bereich der Softwareentwicklung tätig ist, kennt die Forderungen seiner Auftraggeber. Alles soll möglichst heute noch fertig werden. Es darf nichts kosten und wenn möglich soll alles ohne Mitarbeiter erledigt werden. Der Autor eines Pflichtenheftes hat mit Hilfe des Auftrages die Möglichkeit, die Rahmenbedingungen abzustecken, die als Voraussetzung für einen möglichst reibungslosen Verlauf aus seiner Sicht notwendig sind. Dem Autor eines Pflichtenheftes dient der Auftrag als Leitlinie während der gesamten Zeit der Pflichtenhefterstellung. Anhand des Auftrages kann der Autor zu jeder Zeit überprüfen, ob die vereinbarten Ziele erreicht werden. Während seiner Arbeit können immer wieder Situationen auftreten, welche größere Änderungen zur Folge haben. Diese Änderungen beziehen sich zumeist auf den ehemals festgelegten Leistungsumfang. Davon ist dann zumeist auch der Fertigstellungstermin betroffen. In letzter Konsequenz gibt es Veränderungen zu dem ursprünglichen formulierten Auftrag. In solch einer Situation muss genau die Verhältnismäßigkeit geprüft werden. Der Auftrag soll keinen zusätzlichen administrativen Overhead schaffen oder Verwaltung als Selbstzweck betreiben. Ziel des Auftrages ist es, Sicherheit zwischen den beiden Partnern schaffen. Immer dann, wenn diese Sicherheit nicht mehr gegeben ist, sollte der Auftrag geändert werden. Darunter fällt jedoch nicht jede Kleinigkeit. Stand: 14.05.2016 Version 0.93 Seite -97- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 6.1.1 Die Struktur des Auftrages Verantwortung Verantwortungund und Zuständigkeiten Zuständigkeiten beim Erstellen des beim Erstellen desAuftrages Auftrages Auftrag Auftraggeber Autor des Pflichtenheftes Organisatorisches Zielsetzung Aufgabenstellung Kritische Erfolgsfaktoren Termine Team Unterschriften Organisatorisches Wie wird es gemacht? Der Auftrag zur Erstellung eines Pflichtenheftes beginnt mit einem organisatorischen Teil. Wie bei anderen Arten von Verträgen wird zu Beginn der Gegenstand des Vertrages und die Vertragspartner genannt. Der Titel des Pflichtenheftes ist die Arbeitsbezeichnung unter der die gesamte Pflichtenhefterstellung durchgeführt wird. Er sollte den Gegenstand des Pflichtenheftes möglichst genau wiedergeben. Hierbei sollte der Titel nicht zu lang sein. Beispiele: Neue Wareneingangssteuerung Das Kundenbindungsprogramm Spesenabrechung für den Außendienst Automatische Rechnungsprüfung Neben dem Titel ist es sinnvoll für das Pflichtenheft ein Kürzel zu vergeben. Das Kürzel kann während der gesamten Arbeit am Pflichtenheft helfen, Dokumente, Verzeichnisse und andere mit dem Pflichtenheft im Zusammenhang stehende Informationen zu Kennzeichnen. Vielfach ist der Tilen des Pflichtenheftes zu lang um z. B. einen Aktenordner zu beschriften hier hilft ein Kürzel weiter. Neben dem Gegenstand des Pflichtenheftes müssen unbedingt die beiden Partner im Auftrag genannt werden. Durch die Definition von Auftraggeber und Autor sind die Stand: 14.05.2016 Version 0.93 Seite -98- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Ansprechpartner für beide Seiten definiert. Gerade, wenn ein Pflichtenheft durch einen externen Berater erstellt wird, können auf diese Weise die Zuständigkeiten genau bestimmt werden. Doch auch bei intern vergebenen Pflichtenheften ist die Nennung von Auftraggeber und Autor unabdingbar. Neben den beiden Partnern sind bei vielen Pflichtenheften zusätzliche Ressourcen notwendig. Dies immer dann der Fall, wenn der Auftraggeber selbst überhaupt nicht oder nur zum Teil an der Erstellung des Pflichtenheftes mitarbeiten kann. Als Team werden dann entweder eigene Mitarbeiter oder externe Berater benannt. In beiden Fällen ist die Festlegung des Teams, das bei der Erstellung des Pflichtenheftes mitarbeiten soll ein notwendiger Bestandteil des Auftrages. Nur auf diese Weise wird sichergestellt, dass zusätzlich benötige Ressourcen auch zur Verfügung stehen. Zielsetzung Wie wird es gemacht? In diesem Teil geht es um die Frage, was eigentlich mit dem Pflichtenheft erreicht werden soll. Da diese Frage im wesentlichen vom Auftraggeber beantwortet werden kann, muss er diesen Teil vollständig ausfüllen. Der Autor des Pflichtenheftes sollte diesen Teil genau beachten. Ergeben sich bei der Zielsetzung Verständnisprobleme, müssen diese gemeinsam mit dem Auftraggeber ausgeräumt werden. Zudem muss sichergestellt werden, dass die definierten Ziele bestimmten Anforderungen genügen. Der Erfolg oder das Scheitern eines Pflichtenheftes wird anhand dieser Kriterien bestimmt! Daher gilt auch für die Pflichtenhefterstellung: No Goals – No Glory Die Anforderungen an die formulierten Ziele: Erreichbarkeit Die formulierten Ziele müssen erreicht werden können. Dies sollte gemeinsam mit dem Auftraggeber abgeklärt werden. Vollständigkeit Alle zu erreichenden Ziele müssen niedergelegt werden. Es dürfen später im Pflichtenheft keine neuen Ziele mehr definiert werden, die nicht Teil des Auftrages sind. Verständlichkeit Eine klare und eindeutige Zielformulierung ist unabdingbar für die zielgerichtete Erstellung eines Pflichtenheftes. Nur wenn die zu erreichenden Ziele verständlich sind, können alle die mitarbeiten, auch helfen, diese zu erreichen. Messbarkeit Neben diesen Zielen können auch neue Funktionen als messbare Ziele definiert werden. Eine neue Funktion kann sein, dass z. B. zukünftig zur Steigerung der Kundenzufriedenheit die Bezahlung mit Kreditkarten möglich sein soll. Ziele dürfen nicht mit Begriffen wie z. B. "besser" oder "schneller" usw. beschrieben werden. In der Zielsetzung muss klar ausgedrückt werden, was z. B. mit "besser" gemeint ist. Die Verringerung der Fehlerquote in der Auftragserfassung um 10% ist ein klar messbares Ziel. Die Halbierung der Durchlaufzeiten im Lager kann ebenfalls gemessen werden. Erst mit der Messbarkeit eines definierten Ziels ist es möglich, den Erfüllungsgrad der im Pflichtenheft definierten Anforderungen zu überprüfen. Stand: 14.05.2016 Version 0.93 Seite -99- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Konsistenz Die definierten Ziele müssen widerspruchsfrei (konsistent) beschrieben werden. Erst mit sich ergänzenden Zielen ist es möglich, effektiv die Erstellung eines Pflichtenheftes anzugehen. Lösungsneutralität Bei den zu erreichenden Ziele muss das "Was", nicht das "Wie" beschrieben werden. Beispiel: Falsch - nicht überprüfbar Richtig – überprüfbar Verbesserung der Wareneingangssteuerung durch den Einsatz neuer Funktionen. Die neue Lagerverwaltungs-Software soll effektiv eingesetzt werden. Vollständige Ablösung aller Funktionen der alten Wareneingangssteuerung. Die neue Lagerverwaltungs-Software soll eine Reduzierung der Personalkapazität um 10% ermöglichen. Der gesamte Einkauf soll mit der neuen Der gesamte Einkauf soll mit der neuen Software rationalisiert werden. Software Einsparungen von mind. 5.000,-- DM pro Jahr realisieren. Die Erfassung von Aufträgen soll komfortabler Die Erfassung der Aufträge soll sich auf max. 2 werden. Min. pro Auftrag reduzieren. Das Erreichen bestimmter Fertigstellungstermine für die Einführung neuer Funktionalitäten ist kein Ziel bei der Pflichtenhefterstellung! Hier müssen die Ziele aus dem Bereich des Projektmanagements klar von denen der Pflichtenhefterstellung getrennt werden. Aufgabenstellung Wie wird es gemacht? Der nächste Teil des Auftrages beinhaltet eine Auflistung von Punkten in denen dargestellt wird, wie das Ziel erreicht werden soll. Gemeinsam mit dem Auftraggeber muss festgelegt werden, was alles im Pflichtenheft beschrieben werden soll. Hier geht es darum, die Mittel und Wege zu definieren, mit denen die festgelegten Ziele erreicht werden können. Neben den Zielen ist dieser Punkt im Auftrag ein wesentlicher Faktor für die Pflichtenhefterstellung. Vielfach fällt es jedoch schwer, einzelne Punkte richtig den Bereichen Aufgabenstellung bzw. Zielsetzung zuzuordnen. Eine Möglichkeit diese Zuordnung zu erleichtern ist das Bilden von Paaren. Hierbei wird jeder Zielsetzung eine Aufgabenstellung zugeordnet. (Jedem „Was“ wird ein „Wie“ zugeordnet.) Auf diese Weise wird außerdem sichergestellt, dass für jedes Ziel auch eine Aufgabe definiert worden ist. Am Ende entsteht eine Liste von Aufgabenstellungen, bei der jeder Punkt jeweils zu einem Ziel gehört. Dabei kann es vorkommen, dass unterschiedliche Zielsetzungen mit der gleichen Aufgabenstellung erreicht werden. In diesem Falle werden die Aufgaben zusammengefasst. Sollte es partout nicht möglich sein, einen Punkt richtig zuzuordnen. Sollte darauf keine unnötige Kraft verschwendet werden. Wichtiger als die vermeintlich korrekte Zuordnung eines relevanten Sachverhaltes ist, dass der Sachverhalt im Projektauftrag überhaupt genannt wird. Daher sollten Zuordnungsprobleme nicht dazu führen, dass knifflige Punkte aus dem Projektauftrag herausgenommen werden. Stand: 14.05.2016 Version 0.93 Seite -100- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Beispiele: Umstellung der Erstellung von manuellen Fahraufträgen auf eine automatische Staplersteuerung Ziel: Die neue Lagerverwaltungs-Software soll eine Reduzierung der Personalkapazität von 10% ermöglichen. Ablösung des manuellen Dispositionsverfahrens durch eine automatische Disposition Ziel: Der gesamte Einkauf soll mit der neuen Software Einsparungen von mind. 5.000,-- DM pro Jahr realisieren. Reduzierung der Anzahl der Mussfelder in allen Auftragsmasken auf ein Mindestmaß Ziel: Die Erfassung der Aufträge soll sich auf maximal 2 Min. pro Auftrag reduzieren. Kritische Erfolgsfaktoren Wie wird es gemacht? Dieser Punkt ist für den Autor eines Pflichtenheftes besonders wichtig. Der Erfolg hängt maßgeblich davon ab, wie mit den kritischen Erfolgsfaktoren umgegangen wird. Der Autor des Pflichtenheftes hat die Aufgabe, alle aus seiner Sicht erfolgskritischen Faktoren aufzuzählen. Auf diese Weise kann der Auftraggeber helfen, evtl. auftretende Probleme zu überwinden. Der Autor kann zudem diese Dinge –falls nötig- beim Auftraggeber einfordern. Dieser Punkt bietet die Möglichkeit, Risikomanagement bereits im Vorfeld zu betreiben. Anders als bei den Punkten Aufgabenstellung und Zielsetzung haben sich bei der Pflichtenhefterstellung einige kritische Erfolgsfaktoren herauskristallisiert, die fast immer berücksichtigt werden können. Beispiele: • termingerechte und ausreichende Mitarbeit der Fachabteilungen Dieser Punkt ist der Hauptgrund, warum die Erwartungen an ein Pflichtenheft häufig nicht erfüllt werden. Teammitglieder, die sich aus Mitarbeitern der Fachabteilungen zusammensetzen sind vielfach mit der zusätzlichen Arbeit an dem Pflichtenheft überlastet. Dies ist immer dann der Fall, wenn diese Arbeit neben dem eigentlichen Tagesgeschäft auf diese Mitarbeiter zukommt. Der Auftraggeber soll hier helfen, dass die benötigten Mitarbeiter entsprechend freigestellt werden. • ausreichende Ausstattung mit Arbeitsmitteln Während der Arbeit an einem Pflichtenheft werden permanent bestimmte Arbeitsmittel benötigt. Das fängt mit Besprechungsräumen an und hört mit einem Flipchart auf. Alle diese "Kleinigkeiten" können Terminverzögerungen mit sich bringen. So werden z. B. gemeinsame Besprechungen angesetzt und es ist kein Raum frei. Abläufe sollen der Fachabteilung präsentiert werden, jedoch fehlt leider der Projektor. Mit Hilfe des Auftrages wird sichergestellt, das der Autor Zugriff auf alle notwendigen Arbeitsmittel hat, bzw. das der Auftraggeber die Bereitstellung dieser Mittel sicherstellt. • Entscheidungen über Änderungen relevanter Geschäftsabläufe werden nur in Abstimmung mit dem Autor des Pflichtenheftes getroffen Häufig kommt es vor, dass während der Arbeit an einen Pflichtenheft, bestimmte bereits fertiggestellt Abläufe in ihrer Darstellung nicht den gewünschten Anforderungen entsprechen. In diesen Fällen stellt sich meist heraus, dass parallel zur Arbeit am Pflichtenheft betroffene Geschäftsabläufe geändert wurden. Eine solche Situation kann im Einzelfall zur kompletten Neukonzeption des Pflichtenheftes führen. Aus diesem Grunde sollten alle Entscheidungen, die Geschäftsabläufe des Pflichtenheftes betreffen, nur in Abstimmung mit dem Autor des Pflichtenheftes getroffen werden. Nur auf diese Wiese wird sichergestellt, dass die im Pflichtenheft geleistete Arbeit die zukünftig gewünschte Situation korrekt darstellt. Stand: 14.05.2016 Version 0.93 Seite -101- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Dies ist nur eine kleine Anzahl von Punkten, die als kritische Erfolgsfaktoren maßgeblichen Einfluss auf die Pflichtenhefterstellung nehmen können. Der Autor muss für seine Arbeit diese Liste um die Punkte erweitern, die seine spezielle Situation betreffen. Neben Erfahrungswerten aus früheren Kontakten mit dem Auftraggeber, hilft auch ein Gespräch mit der Fachabteilung. Termine Wie wird es gemacht? Die Terminplanung ist bei der Pflichtersterstellung ein schwieriges Thema. Nicht umsonst ist ein Festpreisangebot für eine Pflichtenhefterstellung kaum zu erhalten. Die Festpreise, die angeboten werden, sind meist mit umfangreichen Puffern ausgestattet. Der Grund liegt in der schlechten Abwägbarkeit der Aufwände bei der Pflichtenhefterstellung. Dieser Prozess wird zum einem von der Art der Zusammenarbeit zwischen Fachabteilung und Autor bestimmt wird. Zum anderen von der Komplexität des zu bearbeitenden Themas. Aus diesem Grunde ist eine exakte Terminplanung für eine Pflichtenhefterstellung nur in Spezialfällen möglich. Um überflüssige Diskussionen zu vermeiden, können Sie in diesem Teil folgende Struktur vorgeben: - Start der Pflichtenhefterstellung: TT.MM.JJJJ - Vorlage eines ersten Grobkonzeptes: TT.MM.JJJJ - geplante Abnahme durch . . . . . .: TT.MM.JJJJ Statt genauer Termine kann auch eine Kalenderwoche als Termin genannt werden. Der Auftrag darf auf keinen Fall eine zu detaillierte Zeitplanung enthalten! Der Zeitpunkt dafür ist bei Auftragserteilung noch viel zu früh. Lediglich relevante Ecktermine sollten ein Teil des Auftrages sein. Das Team Wie wird es gemacht? Neben dem Auftraggeber und dem Autor sind meistens bei der Erstellung eines Pflichtenheftes noch weitere Mitarbeiter tätig. Zur Absicherung dieser notwendigen Ressourcen sollten diese Mitarbeiter Teil des Auftrages sein. Auf diese Weise wird sichergestellt, dass alle gemeinsam mit dem Auftraggeber benannten Personen fester Bestandteil des Teams werden. So wird eine nachträgliche Interpretation über Anzahl und Personen bei den Teammitgliedern vermieden. Solche Diskussionen treten immer dann auf, wenn während der Pflichtenhefterstellung von diesen Personen Aufgaben erledigt sollen, die nichts mit dem Pflichtenheft zu tun haben. Gänzlich verhindert wird dadurch der Abzug von aber Ressourcen nicht. Der Autor des Pflichtenheftes hat jedoch die Möglichkeit, über den Auftrag auf die zugesagte Mitarbeit von definierten Personen hinzuweisen, falls sich daraus Verzögerungen bei der Fertigstellung ergeben. Stand: 14.05.2016 Version 0.93 Seite -102- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Unterschriften Wie wird es gemacht? Der Auftrag sollte auf jeden Fall eine Unterschrift enthalten. Ein einfaches OK reicht hierfür nicht aus. Erst mit den Unterschriften wird der Auftrag besiegelt. Die Unterschriften sollten daher möglichst zeitnah nach Fertigstellung des Auftrages. Durch die Unterzeichnung des Auftrages bekommt die Erstellung des Pflichtenheftes einen offiziellen Charakter. Damit hilft er Auftrag auch dem Autor die Wichtigkeit seiner Arbeit zu unterstreichen. Dieser Punkt ist bei der Zusammenarbeit mit der Fachabteilung ein positiv motivierendes Element, wenn es darum geht evtl. vorhandene Widerstände abzubauen. Sonstiges Wie wird es gemacht? Sollten noch weitere Dinge mit in den Auftrag aufgenommen werden, dient der Punkt Sonstiges als Sammelbecken für alle diese Punkte. Dort werden Dinge untergebracht, die sonst nirgendwo untergebracht werden konnten. So könnte z. B. die Berücksichtigung bestimmter Entwicklungsrichtlinien ein solcher Punkt sein. Mit Hilfe dieses Punktes kann der Auftrag „wasserdicht“ gemacht werden. Sind keine sonstigen Punkt im Auftrag notwendig, sollte dieser Teil nicht als leerer Platzhalter im Auftrag erscheinen. Auf diese Weise werden unnötige Diskussionen vermieden. Stand: 14.05.2016 Version 0.93 Seite -103- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 6.1.2 Beispiel für einen Auftrag Auftrag zur Erstellung eines Pflichtenheftes Titel des Pflichtenheftes Neue Wareneingangssteuerung Kürzel NWE Auftraggeber Autor des Pflichtenheftes Herr Schmidt Herr Klein Herr Mahr Projektteam Herr Braun Herr Mahr Frau Keil Herr Zulauf Zielsetzung Vollständige Ablösung aller Funktionen der alten Wareneingangssteuerung Verringerung der Anzahl der separat existierenden Anwendungen auf das zentrale WWS und das LVS Nutzung von Standards bei internen Schnittstellen und externem Datenaustausch Reduktion des Erfassungsaufwandes der Lieferscheine auf maximal 2 Minuten Aufgabenstellung Entwicklung einer neuen Wareneingangssteuerung mit moderner Oberfläche Integration der neuen WE-Steuerung in das bestehende Warenwirtschaftssystem Anbindung der neuen Wareneingangssteuerung an das bestehende LVS über die bereits existierende Standardschnittstelle Entwicklung eines schlanken Anwendungssystems mit schnellen Eingabemöglichkeiten und hohem Automatisierungsgrad Kritische Erfolgsfaktoren Freistellung aller Mitarbeiter des Teams für dieses Pflichtenheft in dem vom Autor geplanten Umfang Bedarfsorientierte Bereitstellung weiterer Mitarbeiter aus den Fachressorts aktive Mitarbeit der Anwender während der gesamten Laufzeit der Pflichtenhefterstellung Entscheidungen über Änderungen relevanter Geschäftsabläufe nur in Abstimmung mit dem Autor des Pflichtenheftes Zeitgerechte Ausstattung des Projektes mit den erforderlichen Arbeitsmitteln Termine, Meilensteine Start der Pflichtenhefterstellung 06.11.2000 Vorlage des ersten Grobkonzeptes 48. KW 2000 Geplante Abnahme durch Auftraggeber 09. KW 2001 Budget-Rahmen geplante Beratungskosten 45.000,-- DM Sonstiges Die Einführung der neuen Wareneingangssteuerung betrifft nicht das bestehende Lagerverwaltungssystem. Jede konzeptionelle Überlegung, die eine Modifikation an dieser Anwendung zu Folge hätte ist zu vermeiden. Unterschrift Auftraggeber Unterschrift Autor Pflichtenheft _________________ Fred Schmidt Stand: 14.05.2016 _____________ Hans Klein _________________ Peter Mahr Version 0.93 Seite -104- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 6.2 Die Kick-Off-Veranstaltung 1 Auftrag zur Pflichtenhefterstellung KickoffVeranstaltung Organisatorische Vorarbeiten Worum geht es? Festlegung der Projektgruppe/Leitung Definition des groben Leistungsumfangs Vereinbarung nächster Termin 6.3 Erste Sitzung mit der Fachabteilung 2 Erste Sitzung mit der Fachabteilung Erste Arbeitsunterlage Start der Arbeiten Erste Arbeitsunterlage Start der Arbeiten Worum geht es? 6.4 Erste Arbeitsunterlage 2 Erste Sitzung mit der Fachabteilung Worum geht es? 6.5 Das Pflichtenheft erarbeiten Worum geht es? 6.6 Die Präsentation des Pflichtenheftes Worum geht es? Nach Abschluss der Arbeiten am Pflichtenheft ist es zumeist üblich, die Arbeitsergebnisse in Form einer Präsentation vorzustellen. Der Kreis für solch eine Präsentation definiert sich je nach Wichtigkeit der zu entwickelnden Anwendung. Daher kann die Präsentation vor recht unterschiedlichem Publikum stattfinden. Projekt- oder Ableitungsleitung Stand: 14.05.2016 Version 0.93 Seite -105- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Die Abschlusspräsentation eines kleineren Projektes wird meist auch im „kleinen Kreis“ durchgeführt. Geschäftsleitung oder Vorstand Bei strategischen Projekten oder bei Projekten, die von Geschäftsleitung bzw. Vorstand initiiert worden sind ist es üblich, dass auch dort die Präsentation den Pflichtenheftes durchgeführt wird. Was bringt es? Die Präsentation eines Pflichtenheftes hat zwei Ziele: a) b) 6.7 Information über die beabsichtigte Realisierung Entscheidung für die Realisierung vorbereiten Mit der Präsentation des Pflichtenheftes Die Abnahme des Pflichtenheftes Worum geht es? Grundlage für jede Entwicklung sollte ein von der Fachabteilung bzw. anderen Verantwortlichen abgenommenes Pflichtenheft sein. Mit der schriftlichen Freigabe des gemeinsam erarbeiteten Pflichtenheftes bestätigen beide Seiten den definierten Leistungsumfang der niedergelegten Anforderungen. Was bringt es? Ein abgenommenes Pflichtenheft ist nicht nur bei der Zusammenarbeit mit externen Beratern die Grundvoraussetzung für die Messung des Realisierungsgrades. Mit der Unterschrift unter der Abnahme wird für alle Beteiligten eine Basis geschaffen auf der die gemeinsame Arbeit durchgeführt werden kann. Stand: 14.05.2016 Version 0.93 Seite -106- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 6.7.1 Beispiel für eine Abnahme Abnahme Pflichtenheft Titel des Pflichtenheftes [Hier klicken und Text eingeben] Version des Pflichtenheftes [Hier klicken und Text eingeben] Stand des Pflichtenheftes [Hier klicken und Text eingeben] Alle im Pflichtenheft niedergelegten Arbeitsergebnisse sind auf Vollständigkeit, sachliche und fachliche Richtigkeit geprüft worden. Datum:_______________ Unterschrift:_____________________ (Herr ..) Unterschrift:_____________________ (Herr ....) Stand: 14.05.2016 Version 0.93 Seite -107- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 7 Technische Anmerkungen 7.1 Visualisierung von offenen Fragen usw. Worum geht es? In der gemeinsamen Arbeit mit den Fachabteilungen hat es sich bewährt, bestimmte Dinge in den Pflichtenheften optisch hervorzuheben. Hierunter fallen z. B. offene Fragen, die während der Erarbeitung aufgekommen sind und beantwortet werden müssen. Was bringt es? Damit diese Punkte innerhalb der Dokumente besser gefunden werden, können sie speziell visualisiert werden. Wie wird es gemacht? Nachfolgend einige Vorschläge: Offene Frage [Autotextname = frage] Wichtige Information [Autotextname = info] Hier muss auf etwas bestimmtes besonders geachtet werden. [Autotextname = achtung] Bitte seien Sie sparsam mit dieser Form von Eyecatchern. Der Schuss kann aus zwei Dingen nach hinten losgehen. Diese optische Form der Aufbereitung kann die Fachabteilungen dazu verleiten, bei ausgearbeiteten Konzepten nur noch diese "Highlights" zu lesen. (Alles andere scheint ja in Ordnung zu sein...) Zudem kann eine zu große Vielfalt von Piktogrammen zu Verwirrungen und Fehlinterpretationen führen (Was war noch mit diesem Zeichen gemeint?) Weniger ist hier mehr! Wir haben bei unserer Arbeit außer den obigen Symbolen bisher keine weiteren benötigt. Technisch lässt sich die Sache ganz einfach mit Textbausteinen umsetzen. Bei WinWord wird aus unserer Vorlage ein Punkt markiert - Autotext wählen - Namen vergeben - fertig. Stand: 14.05.2016 Version 0.93 Seite -108- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 7.2 Änderungen im Pflichtenheft Worum geht es? Im Verlauf der Ausarbeitung eines Pflichtenheftes wird es verschiedene Versionen geben. Der Kunde muss jede Version durchsehen und die vorgenommenen Änderungen bewerten. Damit ersichtlich ist, welche Änderungen im Dokument vorgenommen worden sind, hat sich eine automatische Änderungsverfolgung bewährt. Was bringt es? Sollte das Pflichtenheft einen Stand haben, bei dem Korrekturen und keine grundlegenden Änderungen mehr gemacht werden, sollte die Möglichkeit einer automatischen Änderungsverfolgung genutzt werden. Zum einen bleibt es dem Kunden erspart, Seiten zu lesen, bei denen sich keine Änderungen ergeben haben. Zum anderen kann er durch die explizite Markierung der Änderungen seine ganze Aufmerksamkeit darauf lenken. Ob die Ausarbeitung des Pflichtenheftes einen Stand erreicht hat, der einen Änderungsmodus sinnvoll erscheinen lässt, kann man leicht erkennen. Sollten die Seiten vor lauter Änderungsmarkierungen nur noch schwer zu durchschauen sein, hat man diese Funktion zu früh angewandt. Wie bei allem sollte diese Funktion nicht überstrapaziert werden. Es reicht vollständig aus, die letzte Version einer Änderungskontrolle zu unterziehen. Das Dokument wird sehr unübersichtlich, wenn versucht wird eine Änderungshistorie auf dem Papier nachzuvollziehen, die über die letzte Version hinausgeht. Hierfür können unterschiedliche Versionen der Datei abgespeichert werden. 7.3 Welches Seitenlayout soll gewählt werden? Worum geht es? Die Ränder sind in vielen Textverarbeitungen recht großzügig eingestellt. (In WinWord 2,5 cm) so kommt man natürlich schnell auf ein paar Seiten. Was bringt es? Wenn dies nicht die Absicht ist, hier unser Vorschlag: Oben: Unten: Links: Rechts: 1,5 cm 2 cm 2 cm* 1 cm (*links haben wir etwas mehr Rand gelassen, damit beim Abheften des Pflichtenheftes nicht in den Text gelocht wird.) Die Lesbarkeit des Pflichtenheftes wird von Font und Schriftgröße maßgeblich bestimmt. Schriftgrößen unter 10 Punkt könnten als Körperverletzung ausgelegt werden ;-) Wir bevorzugen 12 Punkt Schriftgröße. Als Font haben sich serifenlose Fonts bewährt. (Arial ist auf jedem Rechner zu finden.) Bei manchen Firmen verlangt es die Corporate Identity, dass eine eigene Schriftart benutzt wird. Sollte dies bei Ihnen der Fall sein, denken Sie daran, den Font Ihren Kunden mitzuliefern. (Bei WinWord besteht außerdem die Möglichkeit, den Font in ein Dokument einzubetten. "Extras-Speichern-Truetypeschriften einbetten") Stand: 14.05.2016 Version 0.93 Seite -109- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 7.4 Was gehört in die Kopf- und Fußzeile? Worum geht es? Festlegen der Inhalte von Kopf- und Fußzeilen in einem Pflichtenheft. Was bringt es? Pflichtenhefte sind wie jede andere Art von Konzepten über einen langen Zeitraum lebende Gebilde. Kopf und Fußzeilen helfen die verschiedenen Realisierungsstände auseinander zu halten und einzelnen Seiten den jeweils richtigen Pflichtenheften zuzuordnen. Inhalte der Kopfzeile Firma Worum geht es? Wer hat das Pflichtenheft erstellt? Was bringt es? Der Urheber der Ausarbeitung sollte auf jeder Seite eindeutig zu identifizieren sein. Pfad und Dateiname Worum geht es? Die Identifizierung des Speicherortes der Datei. Was bringt es? Immer dann, wenn ein Ausdruck einer Datei gemacht werden soll, ist die Ausgabe des letzten Standortes sinnvoll. Bei umfangreichen Projekten oder verschiedenen parallel laufenden Arbeiten verliert man leicht den Überblick. Um die eigene Sucherei oder die der anderen zu verkürzen sollte auf jedem Blatt der Dokumentation der Speicherort ausgegeben werden. Es reicht nicht aus, nur den Dateinamen anzuzeigen. Auf jeden Fall sollte der Pfad mit ausgegeben werden. Bei WinWord besteht die Möglichkeit, den Pfad automatisch beim Einfügen mit auszugeben. Wählen Sie -Einfügen-Feld-DokumentenInformation-DateinameOptionen-SpezifischeSchalter-Hinzufügen. Inhalte der Fußzeile Stand Worum geht es? Die Darstellung des aktuellen Standes des Pflichtenheftes. Was bringt es? Damit wird festgelegt, auf welches Datum sich der vorliegende Ausdruck bezieht. Vielfach wird in die Fußzeile das aktuelle Datum bzw. das Druckdatum eingefügt. Das hat den Nachteil, dass der eigentliche Stand des Dokumentes nicht nachvollzogen werden kann. In diesen Fällen wird bei jedem Ausdruck das aktuelle Datum ausgegeben. Benutzen Sie daher unbedingt das Datum, an dem das Dokument abgespeichert worden ist. (Bei WinWord ist es das Feld " SPEICHERDAT") Alternativ zum Druckdatum kann auch Versionsnummer an dieser Stelle stehen. Stand: 14.05.2016 Version 0.93 Seite -110- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Titel Worum geht es? Ausgabe des Themas des Pflichtenheftes auf jeder Seite. Was bringt es? Die Information auf jeder Seite des Pflichtenheftes, zu welchem Bereich/ Projekt das Pflichtenheft gehört. Hier sollte idealerweise der Titel des Pflichtenheftes eingefügt werden. Sollte der zu lang sein, reicht auch eine Kurzform. Vielfach werden zu Besprechungen nur einzelne Blätter eines Pflichtenheftes mitgenommen. Mit dieser Information in der Fußzeile können nach der Besprechung die einzelnen Blätter wieder dem richtigen Dokument zugeordnet werden. Seite Worum geht es? Ausgabe der aktuellen Seitennummern des Pflichtenheftes. Was bringt es? Die Information, welche Seite des Pflichtenheftes man gerade in Händen hält. Über diesen Punkt sollte eigentlich nicht mehr gesprochen werden müssen. Die Praxis zeigt jedoch etwas anderes. Versuchen Sie bei der Ausgabe von Seitennummern eine fortlaufende Folge von Nummern einzuhalten. Vielfach wird bei einem Abschnittswechsel neu durchnumeriert und es existieren gleiche Seitenzahlen innerhalb eines Dokumentes. Ob die Gesamtanzahl der Seiten (n von n Seiten) zusätzlich mit angezeigt wird, ist u. E. eine reine Geschmacksfrage. Stand: 14.05.2016 Version 0.93 Seite -111- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 7.5 Welche Tools sollen genutzt werden? Worum geht es? Bei der Erstellung eines Pflichtenheftes ergibt sich grundsätzlich die Frage, welche zusätzliche Software eingesetzt werden soll. Diese Frage bestimmt, in welcher Form die niederzulegenden Informationen dargestellt werden. Was bringt es? Mit dem richtigen Werkzeug zur Hand erspart man sich eine Menge Arbeit. Aus diesem Grunde sollte man sich vor bzw. während der Arbeit an einem Pflichtenheft die richtigen Werkzeuge zusammensuchen. Die nachfolgende Auflistung erhebt nicht den Anspruch auf Vollständigkeit. Sie ist als subjektive Auflistung uns bekannter Werkzeuge zu sehen. Brainstorming Mind Manager Mit Hilfe dieser Software kann eine erste Informationssammlung für ein Pflichtenheft erfolgen. Die einfache Methode dieser Software macht sie zu einem absoluten muss! http://www.mindjet.de Visualisierung von Abläufen iGrafx Flow http://www.micrografx.com/germany/ Diese Software wird von uns mit großen Erfolg eingesetzt. Charter 2000 igrafx/flowcharter2000/default.asp Visio2000 allCLEAR Smartdraw http://www.microsoft.com/germany/ Eine sehr mächtige Software, die durch viele zusätzliche produkte/overview.asp?siteid=10428 Anwendungen hervorsticht. Dieser Flowcharter folgt einem interessanten Ansatz. Einfach http://www.proquis.com/allclear/ alles in eine Tabelle schreiben und der Flowchart wird mainmenu.asp automatisch gezeichnet. Ein kleines aber feines Programm. (Shareware http://www.smartdraw.com englisch/deutsch). Erstellen von Bildschirmfotos HyperSnapDX http://www.hyperionics.com Das leistungsfähigste Programm, was wir kennen. (Shareware englisch) Hardcopy http://www.hardcopy.de Eine tolle deutsche Shareware zum Preis eines Trinkgeldes. Komplette Erstellung von Pflichtenheften HDvO http://www.hdvo.de Stand: 14.05.2016 Unsere Software bringt die Ergebnisse aller vorgestellten Tools zusammen und macht eine Dokumentation daraus. Version 0.93 Seite -112- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc 7.6 Der Umgang mit vertraulichen Informationen Worum geht es? Die Erstellung von Software in Form eines Pflichtenheftes kann in verschiedenen Bereichen auf der Basis von vertraulichen Informationen erfolgen. Gerade in der Medizin oder der Entwicklung kann Software u. U. nur mit Informationen erstellt werden, die nicht jedermann frei zugänglich sein sollen. Dies gilt in machen Fällen auch für nicht betroffene Mitarbeiter im eigenen Unternehmen. Die Weitergabe oder das offene Herumliegen von Pflichtenheften bzw. Teilen davon kann dann in diesen Fällen zu Problemen mit dem Datenschutz bzw. rechtliche Probleme mit sich bringen. Für die Sicherung von Unterlagen in Form von Daten bzw. Dateien vorliegen gibt es bereits viele gute Lösungen. Hier wird auf die entsprechenden Anbieter von Zugangs- bzw. Verschlüsselungssoftware verwiesen. Es stellt sich jedoch die Frage, wie Unterlagen, die in ausgedruckter Form vorliegen, zuverlässig geschützt werden können. Dafür gibt es einen einfachen aber wirkungsvollen Mechanismus. Dabei wird jeder der betreffenden Mitarbeiter per Arbeitsanweisung dazu verpflichtet, diese Unterlagen unter Verschluss zu halten. Jedes Blatt der betreffenden Ausarbeitung wird dann beim Ausdruck deutlich mit dem Namen des Empfängers gekennzeichnet. Diese Möglichkeit kann nicht nur dazu genutzt werden, Pflichtenhefte, sondern auch Umsatzberichte u. ä. brisante Unterlagen vor einem allzu sorglosen Umgang im oder außerhalb des Unternehmens zu schützen. Hierbei sollte die Kennzeichnung nicht zu klein bzw. zu schwach vorgenommen werden. Was bringt es? Mit dieser Kennzeichnung des Empfängers auf den Unterlagen können z. B. herumfliegende einzelne Seiten direkt dem jeweiligen Empfänger zugeordnet werden. Fotokopierte Seiten sind damit auch jederzeit dem Empfänger der Unterlagen zuzuordnen. Jeder Mitarbeiter, der mit Unterlagen in dieser Form arbeiten muss, wird dann sehr genau darauf achten, dass diese Unterlage sorgfältig vor öffentlichem Zugriff geschützt sind. Sicher gibt auch diese Form des Dokumentenmanagements keine absolute Sicherheit. Wir haben jedoch mit dieser Vorgehensweise gute Erfahrungen gemacht. Zudem ist das Handling einfach und verursacht keine zusätzlichen Kosten. Wie wird es gemacht? Für die Kennzeichnung jeder Seite eines Dokumentes wird in die Kopfzeile des Dokumentes ein Textfeld eingefügt. Es gibt wie ein Wasserzeichen auf jeder Seite Informationen aus. Stand: 14.05.2016 Version 0.93 Seite -113- Das Pflichtenheft Team-HDvO http://www.hdvo.de Vorgehensweisen zur Erstellung von Programmiervorgaben für Individualsoftware PFAD=D:\75808787.doc Beispiel: Das obige Beispiel zeigt das Deckblatt dieser Ausarbeitung und ein leeres Blatt mit dem Namen des Empfängers. Folgende Arbeitsschritte sind unter WinWord auszuführen, um diesen Effekt zu erhalten: Menü Einfügen Textfeld Menü Reihenfolge (rechte Maustaste auf Textfeld) Hinter den Text bringen Menü Eigenschaften Textfeld (rechte Maustaste auf Textfeld) Farbe: kein Füllbereich Linie: keine Linie Menü Format Zeichen (Absatzmarke im Textfeld markieren) Farbe: Grau (25%) oder heller Menü Extras-Textrichtung Hochkant Textfeld über die ganze Seite vergrößern Schriftgrad im Textfeld auf die gewünschte Größe bringen (z. B. 100 Punkte) Textfeld ausschneiden und in die Kopfzeile kopieren Danach über die Serienbrieffunktion das Feld mit dem Namen oder der Personalnummer des Mitarbeiters in das Textfeld einfügen. Dann den Seriendruck starten. Fertig! Verschiedene Laserdrucker können beim Ausdruck keine Farben im Graustufen umsetzen. Aus diesem Grunde kann der Fall auftreten, dass die graue Schrift tiefschwarz auf der Seite ausgedruckt wird. Hier hilft nur der Ausdruck über einen Tintenstrahldrucker. Stand: 14.05.2016 Version 0.93 Seite -114-
