Spezifikation

Darüber hinaus wird die Spezifikation u.a. in Algebraischen Datenstrukturen¹, im Handelsrecht², im Zivilrecht³, in der Vergabe- und Vertragsordnung für Bauleistungen⁴, der Lebensmittelindustrie⁵ oder der Ökonometrie bei der Formulierung von Modellen⁶ genutzt.

Die Verwendung der Spezifikation in Standards

Es gibt verschiedene Standards im Projektmanagement, der Produktentwicklung oder Systemerstellung, die sehr aktiv den Begriff der Spezifikation verwenden. Hier finden Sie eine Auswahl:

• Die ISO/UEC/IEEE 24765:2017 verwendet den Begriff u.a. um die Gültigkeit einer Implementierung mathematisch zu beweisen, die Implementierung mathematisch abzuleiten oder als formale Notation für einen Korrektheitsnachweis.⁷
• Der “Allgemeine Umdruck 250” (AU 250) des V-Modell 97 fordert sowohl im Projekthandbuch als auch im QS-Plan die Festlegung von Standards oder Leitlinien für die Formate und Inhalte einer Spezifikation, sowie die offizielle Genehmigung von Software-Anforderungsspezifikationen von zuständigen Stellen.
• Für das V-Modell XT – dem Nachfolger des V-Modell 97 – bieten Spezifikationen den Überblick über Systemelemente mit deren funktionalen und nicht-funktionalen Anforderungen. Insgesamt wird der Begriff 700 Mal in dem deutschen Standard für die Planung und Durchführung von Systementwicklungsprojekten erwähnt.
• Der Guide to the Software Engineering Body of Knowledge (SWEBOK) erläutert, dass der Begriff in den meisten technischen Berufen die Zuweisung von numerischen Werten oder Grenzwerten für Konstruktionsziele von Produkten bezeichnet, im Software Engineering typischerweise jedoch als Dokumentation von  Anforderungen verstanden wird, die systematisch überprüft, bewertet und genehmigt werden kann.
• Das Project Management Body of Knowledge (PMBOK) erachtet Systeme, Komponenten, Produkte, Ergebnisse, Prozeduren oder auch Dienstleistungen als Gegenstände von Spezifikationen, deren Anforderungen, Design und Verhalten definiert wird.
• PRINCE2 definiert im Zuge der produktbasierten Planung die Spezifikation als Produktbeschreibung, die sämtliche Qualitätsaspekte wie z. B. Qualitätskriterien, Qualitätstoleranzen, Ersteller des Produktes, Prüfer, Abnahmeberechtigte und Prüfmethoden des Produkts enthält.⁸
• Der Business Analysis Body of Knowledge (BABOK) beschreibt eine Spezifikation von hoher Qualität als gut lesbar und für die vorgesehene Zielgruppe leicht verständlich.
• Und das International Requirements Engineering Board (IREB) empfiehlt, beim Spezifizieren von Anforderungen einer Funktion, diese Funktion zu verfeinern, sofern die Beschreibung mehr als eine halbe Seite Umfang einnimmt.

Arten und Beispiele von Spezifikationen

In der Praxis der System-, Produkt- oder Softwareentwicklung gibt es viele verschiedene Arten und Beispiele von Spezifikationsdokumenten:

• Ein Lastenheft ist ein Dokument eines Auftraggebers, das Anforderungen an ein System und erwartete Leistungen eines Auftragnehmers beschreibt. Für das Lastenheft gibt es einige alternative Bezeichnungen, u.a.  Anforderungs-, Anwender- oder Kundenspezifikation, sowie Anforderungskatalog.
• Auch wenn Anforderungskataloge und Lastenhefte synonym verwendet werden, korrekter wäre es, den Anforderungskatalog als Input für ein Lastenheft zu verstehen. Ein Anforderungskatalog ist eine Auflistung von Anforderungen, durch die ein angestrebtes Projektziel erreicht werden soll.
• Das Pflichtenheft basiert auf dem Lastenheft, wird allerdings aus Sicht des Auftragnehmers formuliert und beschreibt das “Wie” und somit den Plan zur Umsetzung des “Was” aus dem Lastenheft. Es bildet in zahlreichen Kooperationen die Grundlage für den Vertragsabschluss zwischen Auftraggeber und Auftragnehmer.
• In der Unternehmenspraxis werden Anforderungslisten und der Anforderungskataloge ebenfalls häufig synonym verwendet. Formal betrachtet entsteht eine Anforderungsliste erst zu Beginn der Entwicklungstätigkeit, basiert auf dem Pflichtenheft und ist ein Hilfsmittel zur Suche und Bewertung von Lösungen, mit denen Anforderungen erfüllt werden.
• Die Systems and Software Requirements Specification (SRS) ist ein IEEE Standard (IEEE 29148-2018) und umfasst sowohl Lastenheft als auch Pflichtenheft. Sie definiert neben den customer requirements – auch C-Requirements genannt – auch development requirements – entsprechend D-Requirements genannt.
• Das Use Case Konzept umfasst zwei Ansätze, die sich gemeinsam nutzen lassen: Use Case Spezifikationen enthalten natürlich-sprachliche Informationen zur Systematik der Interaktionen eines Anwendungsfalls (sogenannte “Narratives”). Use Case Diagramme visualisieren Anwendungsfälle und Akteure mit ihren jeweiligen Beziehungen. Sie liefern einen guten Überblick über das Gesamtsystem, beschreiben aber im Gegensatz zu den Spezifikationen keine Abläufe, sondern die Zusammenhänge zwischen einer Menge von Anwendungsfällen und den daran beteiligten Akteuren.
• Leistungsverzeichnisse beinhalten spezifizierte Leistungen von Anbietern, benötigte Leistungen von Auftraggebern (in Form von Ausschreibungen) oder die vereinbarten Leistungen bei Verträgen zwischen Auftraggeber und Auftragnehmer.

Die Meinungen variieren in der Praxis, ob auch Backlogs – bekannt und beliebt bei agilen Projekten und Entwicklungen – eine “moderne” Form einer Spezifikation darstellen, oder Lastenhefte ergänzen oder ersetzen. Gleiches gilt auch für Notationen wie UML, SysML oder BPMN, die mittels zahlreicher Diagramme das Spezifizieren von technischen Zusammenhängen, Anforderungen, Datenflüssen etc. unterstützen.

Fragen im Kontext von Spezifikationen

Es gibt eine lange Liste an Fragen im Kontext von Spezifikationen. Auf einige der Fragen finden Sie Antworten in unserem Blog:

• Wie lassen sich Anforderungen binnen 14 Tagen spezifizieren?
• Was ist ein guter Prozess im Anforderungsmanagement?
• Was tun, wenn der Berg an Anforderungen zu groß wird?
• Was sind typische Missverständnisse im Requirements Engineering?
• Wie lässt sich die Vollständigkeit von Spezifikationen sicherstellen?
• Wie lassen sich Anforderungen destruktiv erheben?
• Wie funktioniert die Anforderungsanalyse remote?
• Wie lassen sich Anforderungen verlustfrei austauschen?

Sicherlich fallen Ihnen noch weitere Fragen ein. Melden Sie sich gerne bei uns und wir versuchen Ihre Fragen zu beantworten oder entsprechende Beiträge zu publizieren.

In manchen Publikationen ist zu lesen, dass Spezifikationen informal, halbformal und formal definiert werden können. Beim informalen Spezifizieren erfolgt die Definition verbal, beim halbformalen Spezifizieren teilweise verbal und teilweise formalisiert. Wie wahrscheinlich ist es wohl in Ihrem Unternehmen, dass eine informale oder halbformale Spezifikation zu einer erfolgreichen Implementierung beiträgt?

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken.

[1] Algebraische Spezifikation von Datenstrukturen
[2] Spezifikationskauf bzw. Handelskauf
[3] Vereinbarte Beschaffenheit
[4] Technische Spezifikationen in der Vergabe- und Vertragsordnung für Bauleistungen
[5] Lebensmittelsicherheit – Vorschriften und Regelungen
[6] Ökonometrie
[7] ISO/IEC/IEEE 24765:2017
[8] PRINCE2

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.