In jedem Fall brauchen Sie solch einen Leitfaden, wenn verschiedene Mitarbeiter immer wieder Anforderungen aufnehmen und dokumentieren sollen. Aber wie sieht ein solcher Leitfaden aus, was sollte er enthalten und wie umfangreich sollte er sein, damit er nicht zum Leid-Faden wird, einer mächtigen Liste von Anweisungen die nur zur Freude von Bürokraten dient, die gern formale Fehler nachweisen und inhaltliche Prüfungen scheuen?

Der einfachste Leitfaden ist eine Dokumentvorlage, die die notwendigen Bestandteile der Dokumentation als Überschriften enthält und (am Besten in anderer Schriftfarbe) Hinweise dazu gibt, was in dem jeweiligen Abschnitt darzustellen ist.

Diese Vorlage wird am Besten durch ein weiteres Dokument (das auch als Kapitel 0 in den Leitfaden eingefügt sein kann) ergänzt, in dem allgemeine Hinweise zu Formulierungen, Satzbau, Schüsselwörtern enthalten sind. Während die Vorlage für jeden Dokumenttyp (Lastenheft, Pflichtenheft,…) gesondert erstellt werden muss, sind diese Hinweise dokumenttyp-unabhängig.

Ein richtiger, kompletter Leitfaden besteht außerdem aus Beispielen und Hinweisen zur Vorgehensweise bei der Erstellung der Spezifikationsteile und wird durch eine Checkliste zur Prüfung er Vollständigkeit ergänzt.

Ein Leitfaden sollte unbedingt in einer Kurzschulung erläutert werden, die Autoren sollten außerdem Gelegenheit haben, sich mit ihrem Feedback an der Weiterentwicklung zu beteiligen.

Letzter Tipp: Hüten Sie sich vor Leitfäden, die im Internet zu finden sind, die sind meist zu generisch und unspezifisch. Natürlich können Sie diese als Anregung benutzen. Am Besten, Sie schauen sich ein paar davon an und machen dann aus einigen gelungenen eigenen Spezifikationen einen eigenen Leitfaden, den Sie dann mit Ihren Experten diskutieren. natürlich können Sie auch externen Rat hinzuziehen, das versteht sich ja von selbst 😉 .

Der Beitrag Leitfaden oder Leid-Faden? erschien zuerst auf INDAL Software-Spezialist.

Sie könnten sich auf den Standpunkt stellen, dass die Projektsprache die Sprache des Auftraggebers ist und dass das eventuelle Risiko einer notwendigen Übersetzung vom Auftragnehmer zu tragen ist – so etwas kann man vertraglich vereinbaren. Gerade, wenn der Auftragnehmer eine starke deutsche Präsenz hat, wird auf Auftraggeberseite oft dieser Standpunkt vertreten.

Sie können auch den Standpunkt einnehmen, dass das Englische ohnehin die Sprache der IT-Welt ist und deshalb alle Spezifikationen in dieser Sprache abgefasst werden sollen.

Beide Standpunkte haben Nachteile.

Die vertragliche Vereinbarung, dass die Verantwortung für die richtige Übersetzung beim Lieferanten liegt, verhindert natürlich nicht, dass der Kunde ein Risiko trägt, das daraus resultiert, dass aufgrund von falschen Übersetzungen eine Software geliefert wird, die den Anforderungen nicht entspricht.

Andererseits ist es nun einmal Fakt, dass Deutsch-Muttersprachler Schwierigkeiten mit dem exakten und eindeutigen Schreiben und Lesen von englischen Texten haben, zumal es hier nicht darum geht, einen Zeitungsartikel oder einen Film-Dialog sinngemäß zu verstehen.

Welche Lösung optimal ist, hängt vom jeweiligen konkreten Projektdesign ab, vor allem davon, welche Spezifikationstypen von welcher Seite verantwortet werden und wer welche Vorgaben un Richtlinien bereitstellt. Als grundsätzliches Modell sollte jedoch angestrebt werden:

• Kein Dokument wird in zwei Sprachen gepflegt, es gibt, wenigstens als vertragsrelevanten Lieferbestandteil, kein zweisprachiges Dokument. Somit gibt es keine Diskussion darüber, ob das deutsche Dokument exakt die gleichen Inhalte hat wie das englische.
• An der Sprachgrenze sollte ein deutschsprachiger Spezifikations-Autor stehen, der zur “IT-Welt” gehört. Dieser Autor schreibt ein englischsprachiges Dokument, welches auf einer deutschsprachigen Quelle basiert.

Beispiel: Der Anforderungsanalyst (der vielleicht zur Fachseite gehört) schreibt ein deutschsprachiges Fachkonzept. Sein Kollege von der IT-Abteilung schreibt darauf basierend ein englischsprchiges DV-Konzept. Er ist in der Lage, die Inhalte dieses Dokuments seinem Kollegen auf der Fachseite zu erläutern und Unklarheiten zu präzisieren. Der englischsprachige Lieferant erstellt auf dieser Basis das englischsprachige Softwaredesign.

Natürlich ist die Entscheidung nicht immer so leicht, wie es nach diesem kleinen Beispiel den Anschein haben könnte. Unter Anderem ist auch zu berücksichtigen, wer für welche Testphase verantwortlich ist und in welcher Sprache somit die Testfälle zu dokumentieren sind. Die genannten regeln stellen nur einen Grundansatz dar, der im konkreten Umfeld auszugestalten ist.

Der Beitrag Die Sprache der Spezifikation erschien zuerst auf INDAL Software-Spezialist.

Zunächst einmal ist eine begriffliche Klärung notwendig. Viele Projektbeteiligte bezeichnen quasi alles, was in irgendeiner Form bereitgestellt wird, damit die Entwicklungs-Firma ihre Arbeit machen kann, als Spezifikation – oft als Anforderungs-Spezifikation, bezeichnet. Das erweckt den Eindruck, als ob in all diesen Dokumenten irgendwie das Gleiche stehen würde. Aber es gibt riesige Unterschiede.

Ein Beispiel aus einem ganz anderen Bereich soll das verdeutlichen:

Stellen Sie sich vor, Sie wollen ein Haus für Ihre Familie bauen. Sie gehen also zum Architekten, und der fragt Sie erst einmal aus:

• Wieviele Personen sollen in dem Haus wohnen, welches Alter haben diese Menschen (Kinder, Großeltern,…)?
• Welche Hobbies haben Sie, kochen Sie gern, sind Sie Handwerker,…?
• Was ist Ihnen sonst noch wichtig?

Das alles fasst der Architekt in einem Dokument zusammen und stimmt es mit Ihnen ab. Das ist das Anforderungsdokument.

Dann macht der Architekt Ansichten, Zeichnungen, Grundrisse, das alles sind Modelle, die Ihnen zeigen, wie Ihr Haus einmal aussehen wird, die Ihnen schon jetzt sichtbar machen, was Sie auch später einmal sehen werden. Diese Modelle bilden das, was wir im Software-Projekt das Fachkonzept nennen. Das Fachkonzept zeigt, wie das fertige System einmal für den Nutzer aussehen wird, wie es sich sozusagen an der Außen-Schnittstelle zeigt.

Dann kommen die Ingenieure ins Spiel. Sie entwerfen die eigentliche Struktur des Hauses:

• Wie sind die Wände und die Decken aufgebaut?
• Wie wird die Statik sicher gestellt?
• Woraus besteht das Dach?

Diesen Dokumenten entspricht das DV-Konzept im Softwareprojekt.

Es ist klar, dass Sie als Bauherr nicht an der Statik erkennen können, ob Ihre Kinder sich in dem Haus einmal wohl fühlen werden. Deshalb wird ein guter Architekt mit Ihnen zuerst Ihre Anforderungen aufschreiben, und Ihnen dann zeigen, wie diese Anforderungen in den Außenansichten und Grundrissen umgesetzt werden.

Damit ein gutes Ergebnis entsteht, sind also drei Schritte notwendig, und in jedem Schritt braucht man

• eine geeignete Sprache, in der die Beteiligten das Dokument verstehen,
• einen optimalen Detaillierungsgrad
• ein spezielles Know-How bei dem, der das jeweilige Dokument erstellt.

Genauso ist es beim Software-Projekt.

1. Der Business Analyst erfasst die Anforderungen und dokumentiert diese in einer strukturierten Form. Er stellt sicher, dass alle Anforderungs-Typen berücksichtigt werden und mögliche Wechselwirkungen zwischen Anforderungen bereits frühzeitig mit dem Nutzer erkannt werden.
2. Der Funktionale Analyst stellt dar, wie das System für externe Akteuer aussieht. Dabei kann es sich um Benutzer, aber auch um andere Systeme handeln.
3. Der System-Architekt konstruiert das eigentliche System, er entwirft Schichten und Module. Diese Arbeit kann in unterschiedlichem Detaillierungs-Grad erfolgen.

Wichtig ist, dass sich jeder Autor mit sowohl mit dem versteht, der ihm Informationen liefert, als auch mit demjenigen, der als Adressat seine Ergebnisse weiter verarbeitet.

Der Beitrag Der Sinn unterschiedlicher Spezifikationen erschien zuerst auf INDAL Software-Spezialist.