RE-Praxis-Schatztruhe: Begriffsdefinitionen

Man könnte die Definitionen als das Skelett einer Spezifikation betrachten. Zwar lassen sich Anforderungen auch wunderbar erheben und dokumentieren ohne einen einzigen Begriff eindeutig festgelegt zu haben, aber die Gefahr, dass diese dann völlig unzusammenhängend im Raum schweben, ist groß. Definitionen legen das fest, was verantwortlich für die meisten Kommunikations- und damit Verständnisprobleme ist: die Bedeutung von Begriffen.
Das ist soweit nichts Neues – aber im Spezifikations-Alltag ergeben sich dann doch immer wieder Probleme mit Definitionen, wenn jeder Requirements Engineer sie so schreibt, wie es ihm gerade in den Sinn kommt. Lesen Sie weiter, um eine Reihe von Faustregeln kennenzulernen, die sich in unseren Projekten bewährt haben.

1. Was muss definiert werden? Ganz kurz formuliert: Alles, was missverstanden werden könnte.In der Praxis sind das neben den Projektspezifischen Begriffen (z.B. „Zwischenziel“, „Zwischenstop“, „Fahrspur“) auch alltägliche Begriffe, die im Kontext des Systems eine ganz spezifische Bedeutung haben (z.B. Adresse). Manche Kombinationen aus Eigenschaftswort und Begriff haben eine eigene Bedeutung, die gesondert definiert werden sollte (z.B. „empfohlene Fahrspur“) Weiterhin sollten alle verwendeten Prozesswörter – also Verben, die einen Vorgang, den ein Benutzer oder System durchführen soll, beschreiben – definiert sein (z.B. speichern, anzeigen, ausgeben, auswählen).

2. Was muss eine Definition enthalten?

Neben dem zu definierenden Begriff selbst und dem Definitionstext ist ein Hinweis auf die rechtliche Verbindlichkeit der Definition notwendig. Zwar handelt es sich bei einer Definition nicht um eine Eigenschaft des Systems, die der Auftragnehmer zwingend umsetzen muss, aber da die falsche Auslegung eines Begriffes die rechtliche Verbindlichkeit einer Anforderung ad absurdum führen kann, ist es sinnvoll, Definitionen mit einem Hinweis auf deren Verbindlichkeit einzuleiten:

Beispielschablonen (Deutsch / English)

<Begriff> muss definiert sein als: <Definitionstext>.

<Concept> shall be defined as: <Definition text>.

Je nach Bedarf sollten Sie nach dem Definitionstext in strukturierter Form zusätzliche Informationen auflisten:

Beispiel(e) oder Negativbeispiel(e): Ergänzen Sie hier Begriffe, die eine allgemeine Definition mit praktischen Beispielen untermauern oder abgrenzen (z.B. „Wechselmedium“ -> Beispiele: USB-Stick, SD-Card, externe Festplatte, NICHT: CD, DVD).

Verwandte Begriffe: Listen Sie hier ebenfalls definiert Begriffe auf, deren Bedeutung zum Verständnis dieses Begriffes beitragen (z.B. gegenteilige, ähnliche oder übergeordnete Begriffe).

Abkürzungen und Synonyme: im Rahmen einer Spezifikation sollte ein Begriff immer homogen verwendet werden. Verwenden Sie nicht in einer Anforderung einen Begriff und in einer anderen einen anderen, der die selbe Bedeutung hat – also ein Synonym ist – oder eine Abkürzung für diesen Begriff. Denn auch wenn all diese Varianten definiert sind, sorgt eine solch heterogene Verwendung häufig für Verwirrung, ob sich denn all diese Anforderungen auch wirklich auf den selben Sachverhalt beziehen.
Da im Projektalltag (z.B. in Telefonaten, E-Mails und Besprechungen) aber immer wieder mal Abkürzungen und Synonyme für die in der Spezifikation stehenden Begriffe verwendet werden, ist es sinnvoll, übliche Abkürzungen und Synonyme unter dem Definitionstext aufzulisten (z.B. „Fahrspurassistent“ -> Abkürzungen und Synonyme: FSA, Spuranzeige, Spurführung, Spurassistent). Die hier gelisteten Wörter sollten möglichst an keiner anderen Stelle der Spezifikation auftauchen.

Anmerkungen: Ergänzende Erläuterungen, Verweise auf weiterführende Kapitel in der Spezifikation und alles, was nicht Teil der bisher genannten Elemente einer Definition war, sollte nur in einem durch ein vorangestelltes „Anmerkung:“ markierten Abschnitt beschrieben werden.

Vollständige Beispielschablonen (Deutsch / English)

<Begriff> muss definiert sein als: <Definitionstext>.
[Beispiel(e): <Beispieltext>]
[Verwandt: <Verwandter Begriff A>, <Verwandter Begriff B>, …]
[Abkürzung: <Abkürzung des Begriffes>]
[Synonym(e): <Synonym A>, <Synonym B>, …]
[Anmerkung: <Zusätzliche informationen>]

<Concept> shall be defined as: <Definition text>.
[Example(s): <Example text>]
[Related: <Related concept A>, <Related concept B>, …]
[Abreviation: <Abreviation of concept>]
[Synonym(s): <Synonym A>, <Synonym B>, …]
[Remark: <further information>]

Noch ein kurzer Rat in Bezug auf den Definitionstext: Vermeiden Sie, an dieser Stelle ein Verhalten zu beschreiben, das besser in Form von Anforderungen erläutert wird (z.B. „Routenführung muss definiert sein als: Der Vorgang, der automatisch nach erfolgter Routenberechnung eingeleitet wird.“). Beschränken Sie sich hier auf die Bedeutung des Begriffes (z.B. Routenführung muss definiert sein als: Die automatische Empfehlung von Fahrmanövern mit dem Zweck, vom aktuellen Standort aus ein definiertes Ziel zu erreichen.“).

3. Wie geht man mit wichtigen Abkürzungen um?

Zwar habe ich mich weiter oben schon zu Abkürzungen geäußert, aber im Projektalltag gibt es dann doch immer mal wieder Abkürzungen, die sich entweder Projekt intern oder sogar in der Umgangssprache zu stehenden Begriffen gemausert haben (z.B. „USB“ für „Universal Serial Bus“). Solche Akürzungen können selbstverständlich auch innerhalb der Anforderungstexte verwendet werden. Allerdings kann man man nicht bei jedem solchen Begriff immer davon ausgehen, dass jeder Stakeholder (am Projekt beteiligte Person) die Bedeutung jeder dieser Abkürzungen genau kennt. Von daher kann es sinnvoll sein, auch solche Abkürzungen in die Liste der Definitionen aufzunehmen.

Verwenden Sie dafür möglichst immer die selbe Formulierung, um deutlich zu machen, dass es sich bei dieser Definition um eine Abkürzung handelt, die auch im Rahmen der Anforderungstexte verwendet wird.

Beispielschablonen (Deutsch / Englisch) für verwendete Abkürzungen

<Abkürzung> muss definiert sein als: Eine verwendete Abkürzung für <Ausgeschriebener Begriff>.

<Abbreviation> shall be defined as: A used abbreviation of <Written out concept>

Der ausgeschriebene Begriff sollte dann natürlich als eigene Definition vorliegen.

4. Was ist mit nicht Projektspezifischen Begriffen?

Manche Begriffe möchte man erklären aber nicht definieren, da der Begriff außerhalb des Projektkontextes bereits feststeht (z.B. „RDS“ -> „Radio Data System“) oder die Definition von einer anderen Institution schon vorgenommen wurde.
In solchen Fällen möchte man es sich nicht anmaßen, eine eigene Definition zu formulieren, es kann aber sinnvoll sein, den Begriff hier in einem Satz zu erklären und einen Verweis auf eine offizielle Quelle (z.B. einen ISO-Standard, eine DIN-Norm oder einfach eine URL) einzufügen.

Solche Definitionen müssen deutlich von selbst definierten unterscheidbar sein. Eine einfache Möglichkeit dafür bietet das Weglassen der juristischen Verbindlichkeit.

Beispielschablonen (Deutsch / Englisch) für nicht selbst definierte Definitionen

<Begriff> ist definiert als: <Definitionstext>
Anmerkung: <Verweis auf Quelle>

<Concept> is defined as: <Definition text>
Remark: <Reference to Source>

Schlusswort
Eines sollte man angesichts der vielen Regeln und Fallstricke beim Definieren nicht aus den Augen verlieren: das eigentliche Ziel von Definitionen. Sie haben den einfachen Zweck, Missverständnisse und Fehlinterpretationen Angesichts der verwendeten Begriffe zu vermeiden. Es ist nicht der Zweck von Definitionen, Funktionen präzise zu beschreiben und damit Anforderungen überflüssig zu machen.

Ich hoffe, dass Sie in dieser Schatztruhe unserer praktischen Erfahrungen ein oder zwei Perlen gefunden haben und wünsche Ihnen viel Erfolg beim Definieren.

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert