Sollten Pflichtenhefte aus der Auftragsentwicklung in Excel bleiben? — Das richtige Format für Liefergegenstände wählen

„Wir haben eine überarbeitete Spezifikation erhalten, wussten aber nicht, was sich eigentlich geändert hatte, und haben sie trotzdem als abgenommen abgestempelt.“

„Als wir eine Änderung beauftragen wollten, stellte sich heraus, dass die gelieferte Excel-Spezifikation mit den aktuellen Bildschirmen nichts mehr zu tun hatte.“

„Das Entwicklungsunternehmen hat uns eine Spezifikation im Excel-Millimeterpapier-Stil geschickt — ist das eigentlich normal?“

Wenn Sie Systementwicklung auslagern, werden Spezifikations- und Design-Dokumente zusammen mit dem Programm geliefert. In der japanischen Auftragsentwicklung werden diese Dokumente extrem häufig in Excel erstellt, oft im sogenannten „Excel-Millimeterpapier“-Stil — einem Stil, der Zellen in winzige Quadrate zerlegt und das Blatt wie Manuskriptpapier behandelt.

An Kritik am Excel-Millimeterpapier mangelt es im Internet nicht, doch die meiste davon dreht sich darum, wie unpraktisch es als internes Dokument innerhalb eines Entwicklungsteams ist. Dieser Artikel nimmt eine andere Perspektive ein: Er konzentriert sich speziell auf die an den Auftraggeber gelieferte Spezifikation in der Auftragsentwicklung und arbeitet auf, was daran problematisch ist und welches Format zu wählen ist — in der praktischen Vertragsmanagement-Sprache von Abnahmeprüfung, Spezifikationsänderungen und Wartung. Das Ziel sind Inhalte, die sowohl für den auftraggebenden Kunden als auch für das liefernde Entwicklungsunternehmen nützlich sind.

1. Das Ergebnis zuerst

Beginnen wir mit den wichtigsten Punkten.

• Wählen Sie das Format einer gelieferten Spezifikation nicht danach, ob es „während der Entwicklung leicht zu schreiben ist“, sondern danach, ob der Auftraggeber es prüfen kann, ob es die Abnahmeprüfung übersteht, ob sich Diffs bei Spezifikationsänderungen teilen lassen und ob es Jahre später in der Wartung noch nutzbar ist.
• Das Fazit lautet nicht „Excel abschaffen“ — sondern „Millimeterpapier abschaffen und jedes Format dort einsetzen, wo es hingehört“: Fließtext in Word, Tabellen in echten Excel-Tabellen, Diagramme in einem Diagrammwerkzeug und ein Nachweis der Einigung als PDF.
• Bevor über das Format diskutiert wird, klären Sie im Vertrag selbst (bei der Festlegung der Liefergegenstände in der Einzelvereinbarung), welche Dokumente überhaupt als Liefergegenstände zählen und ob Sie ein bearbeitbares Original erhalten.

Das empfohlene Format nach Dokumenttyp als Entscheidungstabelle sieht so aus.

Im Folgenden die Begründung, Punkt für Punkt.

2. Was an einer Excel-Millimeterpapier-Spezifikation als Liefergegenstand falsch ist

Vorab zur Klarstellung: Die Software Excel selbst ist hier nicht der Bösewicht. Als Werkzeug für Tabellenkalkulation und tabellarische Listen ist Excel hervorragend, und wie später behandelt, ist es die richtige Wahl für Dinge wie Felddefinitionsdokumente. Das Problem ist, Fließtext, Diagramme und Tabellen — Dinge mit grundlegend unterschiedlicher Natur — alle in „Millimeterpapier“ zu pressen.

Für ein internes Unternehmensdokument ist das ein Problem, das nur die Personen stört, die es geschrieben haben. Sobald es aber ein Liefergegenstand ist, ändert sich die Sache, denn eine Spezifikation ist ein Liefergegenstand, für den der Auftraggeber bezahlt, sie ist Gegenstand der Abnahmeprüfung, und sie ist ein Asset, das noch Jahre danach genutzt wird. Als Liefergegenstand betrachtet, hat Excel-Millimeterpapier folgende Probleme.

2.1 Es lässt sich bei der Abnahmeprüfung nicht vollständig überprüfen

Excel-Millimeterpapier hat nichts, was Words praktischem Änderungsverfolgungs-Mechanismus ähnelt. Genau genommen verfügt die Co-Autoring-Umgebung von Microsoft 365 zwar über einen Zelländerungsverlauf („Änderungen anzeigen“ bzw. Versionsverlauf), und Werkzeuge wie Spreadsheet Compare existieren zum Vergleich von Arbeitsmappen. Was diese nachverfolgen können, sind aber größtenteils Zellwerte und Formeln; sie erfassen nicht den Text in den Formen und Textfeldern, die Millimeterpapier-Dokumente stark nutzen, und in einem Lieferworkflow, der auf dem Hin- und Herschicken von Dateien per E-Mail aufbaut, funktioniert der Co-Autoring-Verlauf ohnehin überhaupt nicht.

Am Ende muss der Auftraggeber, wenn er eine Überarbeitung erhält, die seine Prüfkommentare berücksichtigt, mit bloßem Auge nach dem suchen, „was sich eigentlich geändert hat“. Dutzende Blätter jedes Mal vollständig neu zu lesen ist nicht realistisch, sodass in der Praxis der Abnahmestempel auf der Grundlage von „vermutlich wurde es korrigiert“ gedrückt wird.

Das ist Abnahmeprüfung nur dem Namen nach. Die Abnahmeprüfung ist das Verfahren, „zu bestätigen, dass ein Liefergegenstand dem vereinbarten Inhalt entspricht, und ihn abzunehmen“; sobald das zur Hohlform wird, verwandelt sich ein später entdecktes Problem in eine sinnlose Auseinandersetzung — „Sie haben die Abnahme doch schon unterschrieben“ gegen „Nein, es wurde nicht in einer Form geliefert, die wir tatsächlich prüfen konnten“.

2.2 Bei einer Spezifikationsänderung bleibt kein Nachweis der Einigung erhalten

Spezifikationen ändern sich immer im Laufe der Entwicklung. Ist das Dokument Excel-Millimeterpapier, neigt das Hin und Her um diese Änderungen dazu, sich in „einen Haufen Dateikopien“ zu verwandeln. Nicht wenige werden einen Dateinamen wie spezifikation_v2_final_überarbeitet(2).xlsx wiedererkennen.

Das Problem ist, dass sich später keine Möglichkeit findet, festzustellen, welche Version „beide Seiten tatsächlich vereinbart haben“. Bei einer Meinungsverschiedenheit über Mehrkosten oder einen Termin dient das vereinbarte Dokument als Grundlage für deren Klärung. Ist unklar, welches Dokument das überhaupt ist, wird daraus eine Aussage-gegen-Aussage-Pattsituation.

2.3 In der Wartung entfernt es sich von der Implementierung

Weil ein Millimeterpapier-Dokument teuer in der Pflege ist, wird es nach der Lieferung bei Änderungen allmählich nicht mehr aktualisiert. Niemand möchte es aus Angst anfassen, das Layout zu zerstören; Text in Formen taucht bei der Suche nicht auf, wodurch Korrekturen übersehen werden — häuft sich das an, steht man einige Jahre später vor der Lage: „Es gibt eine Spezifikation, aber niemand weiß mehr, ob sie noch der Realität entspricht.“

Die Rechnung für diesen Zustand wird bei der nächsten Änderung fällig. Kann dem Dokument nicht getraut werden, muss man von vorn beginnen, indem man das eigentliche System — das laufende System und den Quellcode — untersucht, und dieser Aufwand wird dem Kostenvoranschlag hinzugefügt. Ein Dokument ungepflegt zu lassen, rächt sich später als höhere Änderungskosten.

2.4 Der Auftraggeber kann es faktisch nicht nutzen

Ein für den Druck konzipiertes Layout ist am Bildschirm schwer lesbar. Und weil der Inhalt über eine große Zahl von Blättern und Formen verstreut ist, funktioniert die Volltextsuche schlecht, sodass es Zeit kostet, herauszufinden, „wo diese Anforderung eigentlich stand“. Auch für den Auftraggeber ist es schwer weiterzuverwenden — betriebliche Notizen anzuhängen, es für eine interne Präsentation umzunutzen —, sodass ein Dokument, für das gutes Geld bezahlt wurde, dazu neigt, nur noch „abgelegt“ zu werden.

3. Der vertragliche Blickwinkel — eine Spezifikation ist ein „Liefergegenstand“

Bevor wir zum Format kommen, gehen wir eine Ebene höher. Ein Spezifikations- oder Design-Dokument wird nur dadurch zum vertraglichen Liefergegenstand auf derselben Stufe wie das Programm selbst, dass es im Vertrag als Liefergegenstand definiert wird. Umgekehrt formuliert: Ein im Vertrag nicht festgelegtes Dokument ist nicht zwangsläufig etwas, auf dessen Erhalt Sie überhaupt Anspruch haben. Auch die von der IPA veröffentlichten Muster-Transaktionen und -Verträge für Informationssysteme sind entsprechend so aufgebaut, dass Liefergegenstände in der Einzelvereinbarung festgelegt und Methode sowie Frist der Abnahmeprüfung definiert werden. Die Gesamtstruktur dieses Mustervertrags wird in einem eigenen Artikel erklärt, Wie sollte ein Vertrag für Auftragsentwicklung und Betrieb & Wartung strukturiert sein — Die Wahl zwischen Geschäftsbesorgung und Werkvertrag anhand der IPA-„Muster-Transaktionen und -Verträge“ lernen.

Mit anderen Worten: Die Debatte Excel gegen Word ergibt erst dann einen Sinn, wenn folgendes Fundament geklärt ist.

• Welche Dokumente Liefergegenstände sind: auf der Ebene konkreter Dokumentnamen auflisten, nicht als „ein vollständiger Dokumentationssatz“.
• In welchem Format Sie sie erhalten: Ist ein bearbeitbares Original (eine Word- oder Excel-Datei) enthalten? Nur PDF verursacht in der Wartung Schwierigkeiten.
• Die Methode der Abnahmeprüfung: Was muss vor der Abnahme bestätigt werden? Wie werden Diffs in einer Überarbeitung angezeigt?
• Wie Urheberrecht und Weiterverwendung gehandhabt werden: Darf der Auftraggeber es intern kopieren oder ändern? Kann das Dokument übergeben werden, falls künftig ein anderes Unternehmen mit der Wartung beauftragt wird?

Ist das nicht im Vertrag geklärt, werden Sie sich, egal wie ausgefeilt das gewählte Format ist, darüber streiten, ob dieses Dokument überhaupt zum Lieferumfang gehörte. Wie Sie sich vor der Beauftragung organisieren, behandelt auch Worüber Sie sich vor der Auslagerung der Windows-App-Entwicklung Klarheit verschaffen sollten.

4. Optionen für das Lieferformat — Vergleich danach, „ob es als Liefergegenstand tatsächlich funktioniert“

Ist das Fundament geklärt, wählen Sie das Format. Wie eingangs erwähnt, gibt es vier Bewertungsachsen: wie lesbar es für den Auftraggeber ist, wie einfach es zu prüfen und abzunehmen ist, wie gut sich Diffs bei Spezifikationsänderungen verwalten lassen und wie gut es sich in der Wartungsphase bewährt.

Einige Anmerkungen zu jedem einzelnen.

4.1 Word — die erste Wahl für fließtextlastige Spezifikationen

Ein Dokument, das „in Fließtext spricht“ — ein Übersichts-Design-Dokument, eine Beschreibung eines Geschäftsablaufs — passt naturgemäß zu einer Textverarbeitung. Word bringt alles mit, was ein Liefergegenstand-Dokument braucht, direkt von Haus aus.

• Überschriftenformatvorlagen und ein automatisches Inhaltsverzeichnis: Die Struktur des Dokuments wird klar, und Sie können vom Inhaltsverzeichnis direkt zum gewünschten Abschnitt springen.
• Änderungsverfolgung (die Prüffunktion): Was sich in einer Überarbeitung geändert hat, erscheint rot, direkt auf der Seite. Das ist eine völlig andere Liga, was die tatsächliche Wirksamkeit von Prüfung und Abnahme angeht.
• Kommentare: Das Feedback des Auftraggebers und die Antworten darauf bleiben am Dokument selbst hängen.
• Dokumente vergleichen: Sie können den Diff zwischen zwei Versionen auch nachträglich noch anzeigen.

Der Auftraggeber braucht kein Spezialwerkzeug und keine Einarbeitung, und es besteht unverändert als Lieferformat — ein erheblicher praktischer Vorteil.

Der Haken ist, dass ein Dokument zu bauen, das nur ordentlich aussieht, ohne je echte Formatvorlagen zu nutzen, in dasselbe Loch fällt — man könnte es Word-Millimeterpapier nennen. Nutzen Sie Überschriftenformatvorlagen für Überschriften und Formatierungseinstellungen statt wiederholter Leerzeichen für das Layout. Und das Problem „welche Version ist die aktuelle“ kann auch bei Word noch auftreten — kombinieren Sie es daher mit der später behandelten Versionsverwaltungspraxis.

4.2 Excel wieder zu einer „echten Tabelle“ machen

Dokumente wie ein Bildschirmfeld-Definitionsblatt, eine Codeliste oder eine Berechtigungsmatrix sind von Natur aus Tabellen. Diese in Word zu schreiben ist eher unpraktisch — Excel ist hier die richtige Wahl. Nutzen Sie es aber als echte Tabelle, die Sie als Daten behandeln können, nicht als Millimeterpapier.

• Eine Zeile pro Datensatz, eine Spalte pro Attribut. Nur eine Tabelle pro Blatt.
• Kein Layout mit verbundenen Zellen bauen. Überschriften stehen in einer einzigen obersten Zeile.
• Die Datenstruktur nicht wegen der Druckoptik zerstören (Druckformatierung über einen anderen Weg handhaben).

So aufgebaut, lässt sich das Dokument in der Wartung maschinell verarbeiten. Weiterverwendungsfälle wie der Abgleich von Felddefinitionen mit dem tatsächlichen Datenbankschema oder die direkte Nutzung der Liste als Grundlage für Testfälle beginnen zu funktionieren, was wiederum die gesamte Aufgabe erleichtert, zu prüfen, ob sich das Dokument von der Implementierung entfernt hat.

4.3 PDF — das Format zum Einfrieren einer „vereinbarten Version“

Dass sich PDF nicht leicht bearbeiten lässt, ist zugleich Nachteil und Vorteil. Es disqualifiziert sich als Original einer Spezifikation, ist aber gut geeignet als Momentaufnahme der Version, die die Abnahmeprüfung bestanden hat, oder der bei einer Spezifikationsänderung vereinbarten Version. Weil es sich nicht versehentlich umschreiben lässt, funktioniert es als Nachweis von „das haben wir zu diesem Zeitpunkt vereinbart“.

Genau genommen lässt sich ein PDF aber trotzdem neu erstellen. Seine Kraft als Nachweis kommt nicht aus dem PDF-Format selbst, sondern daraus, dass beide Seiten dieselbe Datei aufbewahren — kombinieren Sie es also mit einer Praxis wie dem Versand per E-Mail unter Aufbewahrung des Versandnachweises, oder damit, dass beide Parteien es in ihrer eigenen Umgebung ablegen. Muss es in einem tatsächlichen Streitfall als Beweis standhalten, ist auch das Hinzufügen einer digitalen Signatur oder eines Zeitstempels eine Option.

Es gibt noch ein weiteres einfaches Prinzip: PDF sollte immer zusammen mit einem bearbeitbaren Original geliefert werden. Nur PDF zu liefern, schränkt die künftigen Optionen des Auftraggebers ein — die interne Nutzung oder die Beauftragung eines anderen Unternehmens mit der Wartung.

4.4 Die Quelle in Markdown + Git halten und generiertes Word / PDF liefern

Auf Seiten des Entwicklungsunternehmens ist es in den letzten Jahren zunehmend üblich geworden, Spezifikationen in Markdown zu schreiben und im selben Git-Repository wie den Quellcode zu versionieren. Das liefert zeilengenaue Diffs, erlaubt die Dokumentprüfung über denselben Mechanismus wie ein Code-Review und bewahrt den Verlauf jeder Änderung als Historie (das reicht für die alltägliche Dokumentation im Entwicklungsalltag völlig aus; muss es aber als Nachweis für ein Audit oder einen Streitfall standhalten, benötigen Sie zusätzlich eine Praxis, die das Umschreiben der Historie untersagt).

Nichts davon erfordert, den Auftraggeber zur Nutzung von Git zu zwingen. Verwalten Sie die Quelle in Markdown und generieren Sie zur Lieferung Word oder PDF mit einem Konvertierungswerkzeug wie Pandoc, und der Auftraggeber erhält einfach wie gewohnt Word/PDF — nichts anders als das, was er kennt. So lassen sich die Verwaltungseffizienz der Entwicklungsseite und die Lesbarkeit für den Auftraggeber zugleich erreichen.

Der Haken ist, im Vertrag ausdrücklich zu klären, „welche Seite die maßgebliche Quelle ist“. Bearbeitet der Auftraggeber die generierte Word-Datei direkt, weicht sie von der Quelle ab — Sie brauchen also eine betriebliche Vereinbarung, etwa Überarbeitungswünsche als Kommentare entgegenzunehmen und stattdessen in die Quelle zurückzuspiegeln.

4.5 Wiki / Online-Tools — eine „lebende Spezifikation“ unter laufender Wartung

Für ein System unter einem laufenden Wartungsvertrag mit häufigen Änderungen ist es auch eine starke Option, die Spezifikation fortlaufend in einem Online-Tool wie Notion oder Confluence aktuell zu halten. Es bietet gute Durchsuchbarkeit, hält den Änderungsverlauf automatisch fest und ist ein Format, das es leicht macht, ein „lebendes Dokument“ statt eines nur „gelieferten und abgeschlossenen“ zu pflegen.

Als Liefergegenstand betrachtet, müssen Sie jedoch vorab klären, was nach Vertragsende übrig bleibt: das Exportformat (lässt es sich nach Word oder PDF exportieren), wem der Arbeitsbereich gehört und wer dafür zahlt, und wie Betrachterkonten gehandhabt werden. Bleibt das vage, riskieren Sie, an ein bestimmtes Werkzeug gebunden zu bleiben und den Zugriff auf das Dokument in dem Moment zu verlieren, in dem der Vertrag endet.

5. Wie Sie das Hin und Her bei Spezifikationsänderungen abwickeln

Selbst mit einem passenden Format tritt das Problem „welche Version ist die aktuelle“ ohne einen betrieblichen Prozess erneut auf, weil sich Spezifikationen ständig ändern — während der Entwicklung ebenso wie in der Wartungsphase, nicht nur bis zur Lieferung. Hier die Grundform, die ich empfehlen würde.

1. Führen Sie ein einziges Änderungsmanagement-Register: eine Liste, die Änderungsnummer, Datum, Inhalt, Auswirkung (Kosten/Zeitplan) und wer sie abgezeichnet hat festhält, eine Zeile pro Eintrag. Eine schlichte Excel-Tabelle reicht dafür völlig aus. Bringen Sie das mit dem Änderungsmanagementverfahren des IPA-Mustervertrags in Einklang (siehe den zuvor genannten Artikel).
2. Schicken Sie Dokumentüberarbeitungen mit sichtbarem Diff hin und her: Aktivieren Sie bei Word vor dem Versand einer Überarbeitung die Änderungsverfolgung und lassen Sie den Auftraggeber seine Prüfung auf die roten Markierungen konzentrieren. Machen Sie sich Sorgen, dass eine Änderung unverfolgt durchrutscht, kann die empfangende Seite das mit Words „Vergleichen“-Funktion gegen die zuvor vereinbarte Version abfangen. Sobald Einigkeit besteht, nehmen Sie die verfolgten Änderungen an und finalisieren diese Version.
3. Legen Sie eine Versionsnummerierungsregel fest: Nennen Sie die abgenommene Version v1.0 und erhöhen Sie sie mit jeder vereinbarten Änderung auf v1.1, v1.2 und so weiter. Verwenden Sie niemals „final“, „überarbeitet“ oder „(2)“ in einem Dateinamen.
4. Frieren Sie jede vereinbarte Version als PDF ein, und lassen Sie beide Seiten eine Kopie aufbewahren: Stellen Sie sicher, dass jeder nachträglich genau feststellen kann, welche Version vereinbart wurde.

Unabhängig davon, welche Werkzeuge Sie nutzen — diese vier Punkte konsequent einzuhalten, verhindert fast die gesamten beiden großen Klassen von Ärger: „wir wissen nicht, was sich geändert hat“ und „wir wissen nicht, welches die vereinbarte Version ist“. Umgekehrt formuliert: Sich über die Betriebsregeln zu einigen, ist wichtiger als die Wahl des Werkzeugs.

6. Was der Auftraggeber vor Vertragsunterzeichnung prüfen sollte

Für die Seite des Auftraggebers folgt hier eine Checkliste dessen, was während der Angebots- und Vertragsphase zu klären ist.

• Enthält die Liste der Liefergegenstände die Spezifikations- und Design-Dokumente auf der Ebene konkreter Dokumentnamen (statt eines vagen „vollständigen Dokumentationssatzes“)?
• Erhalten Sie ein bearbeitbares Original (eine Word-/Excel-Datei o. Ä.)? Ist es nur PDF?
• Wird eine erhaltene Überarbeitung in einer Form präsentiert, die zeigt, was sich geändert hat (Änderungsverfolgung, eine Liste geänderter Abschnitte)?
• Umfasst der Wartungsvertrag die Aktualisierung der Dokumente bei einer Änderung? Falls nicht, sind Sie damit einverstanden, dass die Dokumente mit der Zeit veralten?
• Wie werden Urheberrecht und Weiterverwendung des Dokuments gehandhabt — kann es übergeben werden, falls künftig ein anderes Unternehmen mit der Wartung beauftragt wird?
• Ist das Verfahren für Spezifikationsänderungen festgelegt (ein Änderungsmanagement-Register, wie die Einigung festgehalten wird)?

Von der Seite des Auftragnehmers aus ist dieselbe Liste direkt nützlich, um ein Angebot zu strukturieren. Welches Dokument in welchem Detailgrad geschrieben wird, ist Aufwand — und Aufwand ist Geld. Übernehmen Sie ein Projekt mit vage belassenem Lieferumfang, treffen Sie kurz vor der Lieferung auf eine Diskrepanz — „wir sind davon ausgegangen, dass dieses Dokument selbstverständlich auch dazugehört“. Sich vorab über Liste und Format der Dokumente zu einigen, schützt beide Seiten.

7. FAQ

F1. Der Auftraggeber gibt eine Excel-Millimeterpapier-Vorlage vor. Müssen wir uns einfach daran halten?

Das vorgegebene Lieferformat einzuhalten, gehört tatsächlich zu den Aufgaben des Auftragnehmers. Es lohnt sich aber, den Zweck hinter dieser Anforderung zu klären. Geht es um einen internen Dokumentationsstandard oder um Audit-Konformität, gibt es oft Spielraum, dieselbe Anforderung stattdessen im Word-Format zu erfüllen — nicht selten ist die Vorlage schlicht aus alter Gewohnheit übrig geblieben. Selbst wenn sich die Vorgabe nicht ändern lässt, mildern operative Kniffe – etwa das Beifügen einer „Liste der geänderten Abschnitte“ bei jeder Überarbeitung oder das Einfrieren vereinbarter Versionen als PDF – die meisten Probleme, die dadurch entstehen, dass sich Unterschiede nicht erkennen lassen.

F2. Wir haben die Spezifikation nur als PDF erhalten. Ist das ein Problem?

Im Moment wirkt das nicht wie ein Problem, da es sich ja lesen lässt — Schwierigkeiten entstehen aber, sobald die Wartungs- oder Änderungsphase erreicht ist. Ein PDF mit Spezialwerkzeugen zu bearbeiten ist nicht unmöglich, aber es kontinuierlich unter Beibehaltung seiner Struktur zu pflegen, so wie man es mit einem Word- oder Excel-Original tun würde, ist nicht realistisch, und die Implementierung entfernt sich mit jeder Spezifikationsänderung weiter vom Dokument. Es erschwert außerdem die Übergabe, falls künftig ein anderes Unternehmen mit der Wartung beauftragt werden muss, da kein bearbeitbares Original existiert. Der zuverlässige Weg ist, bereits bei Vertragsabschluss ausdrücklich festzuhalten, dass „die Lieferung ein bearbeitbares Format einschließt“ — als Bedingung für die Liefergegenstände. Wenn Sie bereits nur ein PDF erhalten haben, fragen Sie beim Entwicklungsunternehmen nach dem Original.

F3. Wie detailliert sollten wir die Spezifikation anfordern?

„Je detaillierter, desto besser“ stimmt so nicht. Ein detaillierteres Dokument kostet mehr in der Pflege und entfernt sich leichter von der Implementierung. Der Maßstab ist, dass das Verhalten präzise genug spezifiziert ist, um als Grundlage für die Abnahmeprüfung zu dienen, und dass die Informationen erhalten bleiben, auf die bei Wartung und Änderung zurückgegriffen wird — Bildschirmfelder, Datenstrukturen, externe Integrationen, Geschäftsregeln. Eine zeilengenaue Beschreibung von Implementierungsdetails, die Sie ebenso gut durch Lesen des Codes erhalten könnten, entfernt sich weniger, wenn sie im Code und seinen Kommentaren lebt statt in einem Dokument. Der Detailgrad übersetzt sich direkt in Aufwand und Preis und ist daher etwas, das vor Vertragsunterzeichnung abgestimmt werden sollte.

F4. Wer ist nach der Lieferung dafür verantwortlich, die Spezifikation aktuell zu halten?

Das hängt vom Vertrag ab. Umfasst der Wartungsvertrag „die Aktualisierung von Design-Dokumenten bei Änderungen“, ist es Aufgabe des Auftragnehmers; ist das nicht der Fall, werden Dokumentaktualisierungen entweder bei jeder Änderung separat beauftragt, oder das Dokument wird als etwas behandelt, das schlicht veraltet. Am leichtesten zu einem Streitfall wird es, wenn keine Seite dies klärt und beide einfach annehmen, „das wird natürlich aktuell gehalten“. Beim Abschluss eines Wartungsvertrags lohnt es sich, auf der Ebene konkreter Dokumentnamen genau festzuhalten, welche Dokumente in den Wartungsumfang fallen.

Zusammenfassung

Hier eine Zusammenfassung der wichtigsten Punkte dieses Artikels zu Spezifikationen, die im Rahmen der Auftragsentwicklung geliefert werden.

• Wählen Sie das Format einer gelieferten Spezifikation anhand von Abnahmeprüfung, Spezifikationsänderungen und Wartung — nicht allein danach, ob es „während der Entwicklung leicht zu schreiben ist“.
• Die Kernprobleme von Excel-Millimeterpapier sind eine zur Hohlform werdende Abnahmeprüfung und der Verlust jedes Nachweises der Einigung, beide aus der Unfähigkeit, Diffs zu erkennen, plus die Entfernung von der Implementierung, angetrieben durch die hohen Pflegekosten.
• Das Fazit lautet nicht „Excel vollständig abschaffen“ — sondern zur richtigen Werkzeugwahl am richtigen Ort zurückzukehren: Fließtext in Word (Formatvorlagen + Änderungsverfolgung), Tabellen in echten Excel-Tabellen und ein als PDF eingefrorener Nachweis der Einigung.
• Die Quelle der Entwicklungsseite in Markdown + Git zu verwalten und als Liefergegenstand Word/PDF zu generieren, ist ein Aufbau, der die Vorteile beider Seiten zugleich erreicht.
• Klären Sie vor dem Format die Liste der Liefergegenstände, die Lieferung eines bearbeitbaren Originals und die Handhabung des Urheberrechts — im Vertrag. Sich über die Betriebsregeln zu einigen, ist wichtiger als das Werkzeug.

Am Rande: Das Lesen und Schreiben von Excel aus einem Programm heraus (Berichtsgenerierung) behandelt Excel-Berichtsausgabe erstellen - COM/Open XML/Vorlagen, und die Strukturierung des Vertrags selbst behandelt der Artikel, der den IPA-Mustervertrag erklärt. Lesenswert zusammen mit diesem Artikel.

Für alle, die eine Auslagerung von Entwicklung oder Wartung erwägen

Bei der KomuraSoft LLC (合同会社小村ソフト) gehört es zur Praxis, wenn wir die Auftragsentwicklung von Windows-Business-Apps übernehmen, Umfang, Format und Aktualisierungsprozess der Liefergegenstände-Dokumente vorab mit dem Auftraggeber abzustimmen — genau nach der in diesem Artikel vorgestellten Denkweise. Wir übernehmen auch Untersuchungen für Änderungen an bestehender Software, ausgehend von einem Zustand „es gibt eine Spezifikation, aber wir wissen nicht, ob sie der Realität entspricht“. Kontaktieren Sie uns gerne, auch für Arbeiten zur Bereinigung von Spezifikationen oder zur Überarbeitung des Lieferformats.

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Der Auftraggeber gibt eine Excel-Millimeterpapier-Vorlage vor. Müssen wir uns einfach daran halten?

Das vorgegebene Lieferformat einzuhalten, gehört tatsächlich zu den Aufgaben des Auftragnehmers. Es lohnt sich aber, den Zweck hinter dieser Anforderung zu klären. Geht es um einen internen Dokumentationsstandard oder um Audit-Konformität, gibt es oft Spielraum, dieselbe Anforderung stattdessen im Word-Format zu erfüllen — nicht selten ist die Vorlage schlicht aus alter Gewohnheit übrig geblieben. Selbst wenn sich die Vorgabe nicht ändern lässt, mildern operative Kniffe – etwa das Beifügen einer „Liste der geänderten Abschnitte“ bei jeder Überarbeitung oder das Einfrieren vereinbarter Versionen als PDF – die meisten Probleme, die dadurch entstehen, dass sich Unterschiede nicht erkennen lassen.

Wir haben die Spezifikation nur als PDF erhalten. Ist das ein Problem?

Im Moment wirkt das nicht wie ein Problem, da es sich ja lesen lässt — Schwierigkeiten entstehen aber, sobald die Wartungs- oder Änderungsphase erreicht ist. Ein PDF mit Spezialwerkzeugen zu bearbeiten ist nicht unmöglich, aber es kontinuierlich unter Beibehaltung seiner Struktur zu pflegen, so wie man es mit einem Word- oder Excel-Original tun würde, ist nicht realistisch, und die Implementierung entfernt sich mit jeder Spezifikationsänderung weiter vom Dokument. Es erschwert außerdem die Übergabe, falls künftig ein anderes Unternehmen mit der Wartung beauftragt werden soll, da kein bearbeitbares Original zur Übergabe existiert. Der zuverlässige Weg ist, bereits bei Vertragsabschluss ausdrücklich festzuhalten, dass „die Lieferung ein bearbeitbares Format (das Word- oder Excel-Original) einschließt“ — als Bedingung für die Liefergegenstände. Wenn Sie bereits nur ein PDF erhalten haben, fragen Sie beim Entwicklungsunternehmen nach dem Original.

Wie detailliert sollten wir die Spezifikation anfordern?

„Je detaillierter, desto besser“ stimmt so nicht. Ein detaillierteres Dokument kostet mehr in der Pflege und entfernt sich in der Wartungsphase leichter von der Implementierung. Der Maßstab ist, dass das Verhalten präzise genug spezifiziert ist, um als Grundlage für die Abnahmeprüfung zu dienen, und dass die Informationen erhalten bleiben, auf die bei Wartung und Änderung zurückgegriffen wird — Bildschirmfelder, Datenstrukturen, externe Integrationen, Geschäftsregeln. Umgekehrt entfernt sich eine zeilengenaue Beschreibung von Implementierungsdetails, die Sie ebenso gut durch Lesen des Codes erhalten könnten, weniger, wenn sie im Code und seinen Kommentaren lebt statt in einem Dokument. Wie viel Detail in welches Dokument einfließt, übersetzt sich direkt in Aufwand — also in den Angebotspreis — und ist daher etwas, das vor Vertragsunterzeichnung abgestimmt werden sollte.

Wer ist nach der Lieferung dafür verantwortlich, die Spezifikation aktuell zu halten?

Das hängt vom Vertrag ab. Umfasst der Wartungsvertrag „die Aktualisierung von Design-Dokumenten bei Änderungen“, ist es Aufgabe des Auftragnehmers; ist das nicht der Fall, werden Dokumentaktualisierungen entweder bei jeder Änderung separat beauftragt, oder das Dokument wird als etwas behandelt, das schlicht veraltet. Am leichtesten zu einem Streitfall wird es, wenn keine Seite dies klärt und beide einfach annehmen, „das wird natürlich aktuell gehalten“. Beim Abschluss eines Wartungsvertrags lohnt es sich, auf der Ebene konkreter Dokumentnamen genau festzuhalten, welche Dokumente in den Wartungsumfang fallen.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.