Prozesswörter eindeutig und vollständig spezifizieren (Teil 1)

Es war einmal die Sprache

Nicht erst seit der Arbeit mit Anforderungen wissen Sie, Sprache ist mehrdeutig, missverständlich und herausfordernd ist. Darum gibt es zwei Hilfsmittel, die Ihnen die Arbeit mit Anforderungen erleichtern sollen:

 

  • Mit dem SOPHIST REgelwerk unterziehen Sie Ihre Anforderungen einer Therapie[1].
  • Mit den MASTeR-Schablonen erhalten Sie einen Vorschlag für die Struktur Ihrer Anforderungen[2].

UnbenanntWir SOPHISTen unterstützen unsere Kunden also u.a. bei der Formulierung natürlichsprachlicher Anforderungen. Und genau diese sprachliche Kompetenz haben wir uns einmal genauer angesehen. Als eine unserer Kernkompetenzen sollte sie nach 20 Jahren auf gar keinen Fall in die Jahre kommen. So haben wir sie etwas aufpoliert.

In zwei Blogeinträgen stellen wir Ihnen das Ergebnis, das sagenumwobene „i-Tüpfelchen“ unserer Kernkompetenz vor. Genauer gesagt sind es zwei „i-Tüpfelchen“: Prozesswortdefinitionen für funktionale Systemanforderungen und Informationen zu Prozesswörtern (d. h., Valenz und weitere mögliche Angaben).

Weiterlesen lohnt sich, denn die Arbeit mit den „i-Tüpfelchen“ ist einfach. Sie setzt kein Tool oder Vorwissen voraus. Beide können typischerweise Anwendung in einem Requirements-Engineering-Leitfaden, in Wikieinträgen, in Coachings etc. Einsatz finden. Für weitere Einsatzgebiete wenden Sie sich gern jetzt oder nach der Lektüre der entsprechenden Blogeinträge an uns unter heureka@sophist.de.

Starten wir mit den Prozesswortdefinitionen für funktionale Systemanforderungen.

Prozesswortdefinitionen für funktionale Systemanforderungen

iStock_000015742269_1705x1126_blackboardseries_muharremÖner

Gesucht – Prozesswortdefinitionen für funktionale Systemanforderungen

Nehmen Sie Ihre funktionalen Anforderungssätze einmal unter die Lupe, erkennen Sie, dass sie eine Leistung, die ein System erbringen soll, beschreiben. Beispiele sind drucken, anzeigen, löschen oder allgemeiner ausgedrückt: Prozesse. Prozesse sind Vorgänge oder Tätigkeiten, die sich in Form von Vollverben in Anforderungssätzen wiederfinden. In der Verwendung dieser Vollverben liegt eine Herausforderung für das Requirements-Engineering begründet: Vollverben sind häufig nicht eindeutig und werden von Leuten, die mit Anforderungen arbeiten, unterschiedlich verstanden. Das kann zu unschönen Missverständnissen oder handfesten Konflikten führen. Um diese zu vermeiden, kann in der RE-Praxis mit einer Prozesswortliste gearbeitet werden.

Mögliche Bestandteile einer Prozesswortliste

Eine Prozesswortliste enthält die folgenden Bestandteile[3]:

 

  • Definition des Prozesswortes: Meint die Bestimmung der Bedeutung des Prozesswortes bzw. die Erklärung des Inhaltes des Prozesswortes. Ohne diese Bestimmung würde die konkret geforderte Funktionalität eines Systems verschleiert oder die Bedeutung Prozesswörter Interpretationsspielraum bieten.
  • Beispiel-Anforderungssatz: Zeigt eine mögliche Verwendung des Prozesswortes in einem Anforderungssatz.
  • verwandte Prozesswörter und Synonyme: Meint Prozesswörter mit ähnlicher / gleicher Bedeutung, um die Abgrenzung zu anderen Prozesswörter zu erleichtern und um die Verständlichkeit zu verbessern.

Aus unserer Erfahrung heraus lohnt sich die Erstellung einer Prozesswortliste mit den vorgestellten Bestandteilen, denn so können Unklarheiten hinsichtlich der Bedeutung von Prozesswörtern reduziert werden. Ein Beispiel ist das Prozesswort löschen. Hier gilt es zu klären, ob mit löschen

  1. ein endgültiges Verschwinden der Daten aus einem System oder
  2. ein Inaktiv-Setzen von Daten, die weiterhin aufgerufen werden können oder
  3. ein Inaktiv-Setzen von Daten, die nicht weiterhin aufgerufen werden können (d.h., die Daten können nicht mehr eingesehen werden) oder
  4. zunächst ein Inaktiv-Setzen von Daten und nach drei Wochen ein endgültiges Verschwinden aus dem System gemeint ist.

Ggf. könnten Sie diese Liste der Bedeutungen von löschen mit weiteren Bedeutungen, die aus Ihrer Arbeitspraxis resultieren, ergänzen. Die Klärung der Bedeutung ist sowohl für die schriftliche als auch mündliche Kommunikation über Anforderungen (z. B. Spezifikationen, Interviews, Reviews) relevant.

Des Weiteren kann Ihnen die Klärung der Bedeutung zeitraubende Diskussionen über die Bedeutung von Prozesswörtern in Anforderungen ersparen und somit Konflikten vorbeugen bzw. ihnen entgegenwirken.

Darüber hinaus ist es möglich, einmal definierte Prozesswörter 1 zu 1 wiederverwenden. Sollte eine andere Bedeutung eines Prozesswortes erkannt werden, zeigt unsere Erfahrung, dass dies einfacher ist, wenn sich RE-Beteiligte zunächst über eine bestehende Prozesswortliste austauschen können. So kann die relevante Bedeutung eines Prozesswortes schneller erfasst und die bestehende Definition überarbeitet werden. Ein lästiges „bei Null anfangen“ bleibt Ihnen erspart.

Zur Einordnung der hier vorgestellten Liste beachten Sie bitte folgendes: Die hier definierten Prozesswörter sind typischerweise in Anforderungen an funktionale Systemprozesse enthalten. D. h., die Auswahl der Prozesswörter bezieht sich ausschließlich auf funktionale Anforderungen und nicht auf nicht-funktionale Anforderungen. Außerdem ist zu beachten, dass sich die vorliegende Auswahl an Prozesswörtern sowohl auf fachlich orientierte Anforderungen als auch auf technisch orientierte Anforderungen beziehen kann.

Bei Fragen, Neugierde, Anmerkungen melden Sie sich gern bei uns: heureka@sophist.de oder 0911 40 900 0.

Wir werden uns auf alle Fälle mit einem weiteren Blogeintrag melden und gehen in diesem auf das zweite „i-Tüpfelchen“, die Informationen zu Prozesswörtern (d. h., Valenz und weitere mögliche Angaben)“ ein. Sie lernen ein weiteres Hilfsmittel kennen, mit dem Sie die Qualität Ihrer Anforderungen verbessern können.

[1] Sie überrascht diese Formulierung? Werfen Sie einen Blick in unser Buch „Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil“ (ISBN 978-3446438934; Kapitel 7) und erfahren Sie mehr über den Hintergrund dieser Wortwahl und die Möglichkeit, Ihre Anforderungen inhaltlich zu verbessern.

[2] Auch hier gibt es weiterführende Informationen in unserem Buch „Requirements-Engineering und -Management: Aus der Praxis von klassisch bis agil“ (ISBN 978-3446438934; Kapitel 10).

[3] Bitte beachten Sie, dass die hier vorgestellte Liste und deren Bestandteile ein Beispiel, das auf unseren Erfahrungen fußt. Andere Bestandteile und ein anderer Aufbau sind selbstverständlich

Bildquelle:

Titel: Blackboard Series
Quelle: iStockphoto
Autor: Muharrem Öner

Hinterlasse eine Antwort

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


2 + sieben =

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>