Mit diesem Beitrag schlieĂźen wir unsere Best-Practice-Trilogie ab und widmen uns heute der aktiven Sprache.
KĂĽrzlich ĂĽbernahm ich die Rolle des Lead Business Analyst in einem laufenden Projekt. Durch eine Umorganisation waren auch einige andere Teammitglieder, insbesondere Ansprechpartner aus den Fachbereichen, neu. Wir mussten uns daher oft auf die vorhandene Dokumentation verlassen.
In den End-to-End-Prozessbeschreibungen fanden wir folgende Sätze (aus Vertraulichkeitsgründen generalisiert):
Alle diese Sätze haben ein gemeinsames Problem: Sie lassen wesentliche Fragen offen, nämlich:
In diesem Fall gingen die neuen Fachbereichs-Stakeholder und auch ich davon aus, dass diese Prozesse automatisiert waren. Doch kurz vor dem Produktlaunch stellte sich heraus, dass AuszĂĽge und E-Mails im Testbetrieb manuell von einem Mitarbeiter erstellt worden waren, der inzwischen das Team verlassen hatte. Das fĂĽhrte, wie man sich vorstellen kann, zu erheblicher Aufregung.
Dieses Beispiel zeigt die zentrale Best Practice dieses Beitrags:
Verwende aktive Sprache in Anforderungen und Prozessen!
Ich kann diese Regel nicht genug betonen. Obwohl sie für mich offensichtlich ist, ertappe ich mich selbst immer wieder dabei, passive Sprache zu verwenden, z. B. „Der Blogbeitrag wird veröffentlicht“ statt „Ich veröffentliche den Blogbeitrag“. Auch andere tun das. Warum?
Warum greifen wir zur passiven Sprache?
Fokus auf das Objekt statt den Akteur
Passive Sprache verlagert die Aufmerksamkeit vom Handelnden („Wer tut etwas?“) auf die Handlung („Was wird getan?“). In technischen Dokumentationen scheint dies oft neutraler, z. B.: „Die Anforderungen werden dokumentiert“ statt „Der Business Analyst dokumentiert die Anforderungen“. Leider geht dabei die Information verloren, wer handelt.
Gewohnheit aus formellem Schreiben
In der Schule oder Ausbildung lernen viele, dass Passiv „seriöser“ wirkt. Dies führt dazu, dass Business Analysten Passiv wählen, um Texte „professioneller“ erscheinen zu lassen, z. B.: „Die Daten werden verarbeitet“ statt „Das System verarbeitet die Daten“. Doch Anforderungsdokumentationen sind keine wissenschaftlichen Arbeiten – sie brauchen Klarheit, nicht Formalität.
Unklarheit ĂĽber den Akteur
Wenn der Handelnde unklar oder absichtlich vage gehalten wird, greifen Autoren zum Passiv, z. B.: „Die Zahlung wird autorisiert“ (von wem?). Dies kaschiert Unsicherheiten, führt aber zu unvollständigen Anforderungen.
Vermeidung von Verantwortung
Passiv verschleiert Verantwortung, z. B.: „Ein Fehler wurde gemacht“ klingt weniger direkt als „Das Team machte einen Fehler“. In Projekten wird Passiv genutzt, um Konflikte zu vermeiden, doch klare Verantwortlichkeiten sind in Anforderungen essenziell.
Sprachliche Komplexität als Stilmerkmal
Manche wählen Passiv, um Texte „eleganter“ zu gestalten. Doch komplexe Sätze sind in Anforderungsdokumentationen oft weniger klar.
Kulturelle EinflĂĽsse
Im Deutschen ist Passiv in technischen Texten häufiger als im Englischen, wo aktive Sprache bevorzugt wird. Dies wird durch Ausbildung oder hierarchische Arbeitskulturen verstärkt, die Neutralität schätzen.
Warum aktive Sprache bevorzugen?
Passive Sprache ist problematisch, weil Anforderungen klare Verantwortlichkeiten und Aktionen definieren mĂĽssen. Wer oder was tut etwas? Diese Information ist entscheidend fĂĽr Systeme, Prozesse oder Kombinationen davon.
Aktive Sprache fördert:
Wie die Beispiele besser aussehen
Hier ist, wie ich die Eingangsbeispiele in aktiver Sprache formuliert hätte:
Passiv (alt) | Aktiv (neu) |
---|---|
Die eingegebenen Daten werden an das System X automatisch transportiert. | Der Nutzer gibt die Daten im Order Entry System ein. Das Order Entry System leitet sie via Schnittstelle XYZ an System X weiter. |
Aufgrund der eingegebenen E-Mail-Adresse wird ein Kunden-Admin angelegt und dem Kunden ein E-Mail-Link zugesendet. | System X legt nach Erhalt der Daten via Schnittstelle XYZ einen Kunden-Admin an und sendet dem Kunden einen E-Mail-Link. |
Einmal täglich wird ein Auszug mit den Anmeldungen vom Vortag erstellt. | Herr Müller erstellt täglich einen Auszug mit den Anmeldungen vom Vortag. |
Der Kunde bekommt ein E-Mail mit der Bitte um RĂĽckruf zur Terminvereinbarung. | Der Hotline-Mitarbeiter sendet neuen Kunden aus dem Auszug ein E-Mail mit der Bitte um RĂĽckruf zur Terminvereinbarung. |
Sind die neuen Sätze eleganter? Vielleicht nicht. Sind sie eindeutiger? Definitiv!
Meine Regel: Verwende immer aktive Sprache, wenn möglich!
Bleib dran!
Abonniere unseren Newsletterund folge uns auf LinkedIn, Facebook oder XING, um keine neuen Blogbeiträge oder Updates zu verpassen.
Möchtest du deine Fähigkeiten im Erheben und Dokumentieren von Anforderungen verbessern? Buche unseren Kurs „Business Analysis Essentials“ (25.–26.09.2025, Wien) bei der SkillsUpgrade Academy und sichere dir 20 % Frühbucherrabatt bis 15.08.2025!