https://requirements.blogger.de/ Erfahrungen, Erkenntnisse und bewährte Methoden aus dem Requirements Engineering Blogger.de andreas lechner 2018-01-24T10:55:41Z en hourly 1 2000-01-01T00:00:00Z https://requirements.blogger.de/stories/1771381/ Requirements-Engineering-Literatur.

Nachdem ich in der Vergangenheit viele atomare Anforderungen geschrieben habe und vor einigen Jahren dann zu Use-Cases als Dokumentationswerkzeug übergegangen bin, möchte ich dem widersprechen.
Atomare Anforderungen mögen formal toll sein, nützlich sind sie nicht.

Mein Hauptkritikpunkt an atomaren Anforderungen ist die erschwerte Lesbarkeit. Dokumentation dient in erster Linie dazu, gelesen zu werden und sollte leicht lesbar und möglichst gut verständlich sein.
Insbesondere der Kontext einer Anforderung und die Zusammenhänge zwischen den einzelnen Anforderungen sollen IMHO leicht erfassbar sein können, um es dem Leser einfach zu machen, die Komplexität zu erfassen.
Aus einer Menge atomarer Anforderungen diese Komplexität zu erfassen, ist fast unmöglich für einen untrainierten Leser.

Lt. Wikipedia soll das Kriterium für ein "Atom" die Entscheidbarkeit einer Anforderung sein.
Formal gesehen muss also in einer Anforderung alle Information enthalten sein, um zu entscheiden ob sie erfüllt ist. Das heißt, der gesamte Kontext, insbesondere alle Vorbedingungen zum Erreichen der Anforderung, müssen in der Anforderung genannt sein!?

Da das viel zu aufwendig und nicht mehr lesbar ist, ergibt sich der Kontext meist aus den umstehenden Anforderungen. Oftmals gibt es für eine Handvoll zusammenhängender Anforderungen einen Übersichtsabschnitt, der den Kontext und den Zusammenhang der Anforderungen erklärt, bevor dann die einzelnen atomaren Anforderungen aufgezählt werden.
Dieser Übersichtsabschnitt ist demnach redundant zu den umstehenden Anforderungen, er bündelt nur die Einzelpunkte mit dem Ziel der Lesbarkeit. Manchmal nennt er auch ein übergeordnetes Ziel, die atomaren Anforderungen dann die Details.

Beiden Varianten würde ich die Integration der Informationen vorziehen. Ich lasse die Detailanforderungen weg und integriere sie in den Übersichtsabschnitt!

Alle potenziellen Leser profitieren von leichter Lesbarkeit. Selbst Tester, die atomar entscheiden sollen, ob eine Anforderung erfüllt ist, profitieren von den Zusammenhängen für ihre Testfälle.
Das einzige Szenario, das mir einfällt, in dem atomare Anforderungen notwendig sind, ist die Abnahme mit dem Anwalt – eine Situation, in die ich hoffentlich nicht kommen werde...]]> Blogger.de andreas lechner Anforderungen Copyright © 2011 andreas lechner 2011-02-06T21:25:39Z https://requirements.blogger.de/stories/1540801/ Ich habe die folgenden Erfahrungen mit diesen Dokumentationsmethoden gemacht:

Sammlung von Requirements a la "Das System muss ...", strukturiert nach Thema der Anforderung
Keine Unterstützung für die Analyse, da die Anforderungen keine Beziehung zueinander haben.
Ein weiterer Nachteil ist die schwere Lesbarkeit. Der Leser muss die Anforderungen in seinem eigenen mentalen Modell zusammen setzen.
Geeignet für sehr formale Rahmenbedingungen, da einzelne Anforderungen referenziert / abgenommen / etc. werden können.
Mein Tipp: Hierarchische Übersichtsabschnitte um den Zusammenhang und das Big Picture der Anforderungen zu bekommen.

Use-Case-Modellierung (in Text-Szenarien oder als Aktivitätsdiagramm)
Use-Cases erleichtern, sicherzustellen, dass das System dem Anwender ermöglicht, sein Ziel zu erreichen. Ausnahmen und Fehlerfälle können methodisch ermittelt werden.
Meine Lieblings-Dokumentation für alle Benutzerinteraktionen, insbesondere wegen der Zielorientierung.
Ein Nachteil ist die hohe Freiheit beim Dokumentieren. Use-Cases können auf unterschiedlicher Ebene modelliert werden - was bewusst geschehen muss.
Geeignet insbesondere für Systeme mit Benutzerinteraktion.
Mein Tipp: Ein gutes Buch zum Thema besorgen.

UML-Modell (insb. Zustandsdiagramme / Klassendiagramme)
OOA-Modelle unterstützen, das System vollständig zu analysieren inkl. aller Ausnahmen. Es fällt leicht, alle Systemaspekte auf einer Abstraktionsebene zu analysieren.
Großer Nachteil ist die hohe Einstiegshürde zum Lesen und Interpretieren der OO-Modelle. Der Leser benötigt Grundverständnis der (technischen) Sprache UML.
Geeignet falls alle Leser UML verstehen oder als Hilfsmittel für den Analytiker, Vollständigkeit zu erreichen.
Mein Tipp: Mit anderen Methoden mischen, ggf. Redundanz in Kauf nehmen zugunsten der leichteren Lesbarkeit.]]> Blogger.de andreas lechner Analyse Copyright © 2009 andreas lechner 2009-12-04T22:38:01Z https://requirements.blogger.de/stories/1268776/ Aber - wer kennt das nicht? Teilnehmer sind unvorbereitet, andere diskutieren über uninteressante Dinge, das Meeting hat kein Ergebnis und ein neues Meeting zu demselben Thema muss anberaumt werden?
Folgende Regeln für effektive Meetings haben sich sehr bewährt:

• Ziel formulieren
  Ein festgelegtes Ziel hilft den Teilnehmern, sich zu fokussieren und hilft dem Moderator, das Meeting zielgerichtet zu halten.
• Agenda verteilen
  Eine vorab verteilte Agenda, ggf. mit Zeitangaben, hilft ebenfalls, die Diskussion effektiv zu halten. Als Moderator zwingt mich das Formulieren der Agenda, mir Gedanken über den effektiven Ablauf des Meetings zu machen.
• Vorbereitung
  Eine gute Vorbereitung durch den Moderator mag selbstverständlich sein. Vorher an die Teilnehmer verteilte Aufgaben helfen, das Meeting frei von Vorträgen zu halten und sich auf die Entscheidungen zu konzentrieren.
• Ergebnisse
  Die Ergebnisse werden im Meeting zusammengefasst und ggf. per Protokoll verteilt. Aufgaben für die Teilnehmer werden definiert und namentlich an einzelne Personen vergeben.

Marissa Meyer von Google hat strenge Regeln aufgestellt und wendet diese für jedes 5-Minuten-Meeting an.
Die Regel "Demonstrate Respect for People's Time" gibt wie ich finde ein gutes Selbstverständnis eines Moderators wieder. Scott Sehlhorst formuliert diese als eine der Regeln um Meetings 60% effektiver zu machen. Er gibt außerdem Verhaltenstipps, wenn sich z. B. Teilnehmer nicht vorbereiten.

In die gleiche Richtung gehen die Top 7 Strategien für produktive Meetings von Kevin Kearns.
Für Meetings, die ich selbst veranstalte, wende ich diese Regeln konsequent an - und bin im Allgemeinen zufrieden mit der Meeting-Effizienz... Schwieriger ist es natürlich in Meetings als Teilnehmer. Hier hilft es, vorher ein Ziel und eine Agenda zu fordern. Ich frage meist auch, wie ich mich vorbereiten kann. Gelingen Meetings dennoch nicht nach meiner Zufriedenheit, hilft Feedback, ggf. mit Hinweis auf die Artikel oben...]]> Blogger.de andreas lechner Methoden Copyright © 2008 andreas lechner 2008-11-15T22:15:14Z https://requirements.blogger.de/stories/1260033/ Projektkontext
Seit ca. 2 Jahren hatten wir für einen Kunden ein System in enger Zusammenarbeit mit den Anwendern entwickelt. Eine spannende Erfahrung, weil das entstehende System trotz seiner hohen Komplexität in relativ kurzer Zeit entstand. Dem System zur Modellierung von maschinell ausgeführten Workflows lag wegen seiner Komplexität eine online/offline SOA-Architektur zugrunde.
Mit dem Rollout des Systems sollte die Weiterentwicklung formalisiert werden um eine hohe Sicherheit für ein sicheres System zu erreichen. Dazu wurde eine vollständige Spezifikation (inkl. Oberflächen-Dokumentation), automatische Tests und zur Unterstützung der Anwender ein Benutzerhandbuch (separat) erstellt.
Um folgende Ziele zu erreichen, wurden die entstehenden Artefakte verknüpft (Tracing):

• Vollständigkeit herstellen (Tests, Handbuch, Oberflächen)‏
• Vollständige Abdeckung durch Tests sicherstellen
• Änderungen konsistent dokumentieren

Lösung
Für das Tracing führten wir Verknüpfungen der Artefakte Tests, Handbuch und Oberflächen-Dokumentation auf die Anforderungen ein:

• Tests -> Anforderungen
• Handbuch -> Anforderungen
• Oberflächen-Dokumentation -> Anforderungen

Wichtig für das Tracing-Konzept waren die Ziele, auf Basis derer wir festlegten, welche Informationen verlinkt werden mussten. Wir entschieden uns z. B. gegen ein Tracing innerhalb der Anforderungen, weil der Aufwand im Verhältnis zum Nutzen "Änderungen konsistent dokumentieren" unter den gegebenen Rahmenbedingungen nicht gerechtfertigt war.
Dem Kunden stellten wir das Konzept zum Tracing vor, wobei er den zusätzlichen Aufwand (jetzt und bei jeder Änderung) in Kauf nahm, die Links zu erstellen und zu warten.

Tool
Eine wichtige Erfahrung war, dass ein Tool unbedingt erforderlich war, die Ziele zu erreichen. Wir erstellten bereits Anforderungen und Tests als das Tool noch nicht einsatzbereit war. Zu dieser Zeit war es z. B. unmöglich, den Fortschritt des Projekts zu kontrollieren (Testabdeckung). Ein Tool ermöglichte außerdem, zusammenhängende Bestandteile mit hoher Sicherheit zu erkennen.
Wir setzten Microsoft SharePoint mit Listen für jedes Artefakt ein. Auswertungen führten wir mithilfe von Excel durch.]]> Blogger.de andreas lechner Anforderungen Copyright © 2008 andreas lechner 2008-11-04T21:35:31Z https://requirements.blogger.de/stories/1254544/ Sprache, seine Welt, seine Durchdringung eines Sachverhalts und unterstütze z. B. mit visuellen Hilfsmitteln um mein Anliegen für ihn so möglichst einfach verständlich zu machen.

Aber: Ist das immer sinnvoll?

Vor ein paar Tagen hörte ich ein Gespräch, bei dem ein Kollege seinem Gegenüber einen unverständlichen Brocken hinwarf und dann erst einmal eine Pause machte. Der Gesprächspartner guckte verwirrt und fragte nach "Was bedeutet das?", worauf der Kollege nach und nach (immer wieder Fragen abwartend) mit der Wahrheit herausrückte.
Das Gegenüber war gezwungen, aufzupassen und immer wieder Fragen zu stellen um den Sachverhalt zu verstehen – er musste aktiv mitdenken.
Würde ich ihm den Sachverhalt leicht verdaulich servieren, würde er nach Ende meines Monologs im Halbschlaf "jaja" sagen und anschließend die Hälfte wieder vergessen!?]]> Blogger.de andreas lechner Kommunikation Copyright © 2008 andreas lechner 2008-10-29T20:51:44Z https://requirements.blogger.de/stories/1249270/ Projektkontext
In einem E-Learning-Projekt sollte ein Konzept für die Anforderung "Kopierschutz" erarbeitet werden. Das E-Learning sollte lt. Lastenheft einen "Kopierschutz" enthalten.
Für das Konzept musste zunächst die Anforderung geklärt werden (eine berühmte nicht-funktionale Anforderung, wie man sie oft findet). Viele Ansprechpartner mussten einbezogen werden, was Richtlinien für Verschlüsselung beim Unternehmen unseres Kunden sowie in den verschiedenen Ländern betraf (China, Frankreich).
Aus den zur Verfügung stehenden Alternativen konnten mit wachsender Erkenntnis die beste ausgewählt werden.

Lösung
Um die wachsenden Informationen zum Thema "Sicherheit" im Verlauf des Prozesses nicht zu vergessen, erstellte ich ein Konzept-Dokument, in dem alle Informationen von der Lastenheft-Anforderung bis zu den Begründungen für die Verwendung einer Alternative dokumentiert waren. Es enthielt die Anforderungen aller Ebenen (bis zu Umsetzungsdetails) zum Thema "Sicherheit".
Das entstehende Konzept-Dokument schrieb ich während der Erarbeitung fort und dokumentierte den jeweils aktuellen Wissensstand. Verworfene Alternativen kopierte ich mit Begründung in den Anhang.
Das Dokument diente zu jedem Zeitpunkt als Kommunikationsgrundlage mit den Stakeholdern (jeweils relevante Auszüge) sowie als Dokumentation der Entscheidungskriterien gegenüber unserem Kunden sowie der internen Entwicklung.
Nach dem Projekt diente das Konzept-Dokument in weiteren Projekten als Vorlage um das jeweilige Sicherheitskonzept zu erarbeiten. Das Dokument war sehr gut wiederverwendbar, da nicht nur das Konzept sondern der Weg dorthin dokumentiert war.

Aufbau
Das Dokument enthielt die folgenden Informationen:

• Lastenheft-Anforderung sowie Aussagen des Kunden
• Tiefer analysierte Anforderung: Was ist der Gegenstand des Schutzes und was ist sein Wert? Welche Gefahren-Szenarien gibt es? Welche (messbaren) Anforderungen an die Sicherheit ergeben sich daraus?
• Konzept mit verschiedenen Alternativen zu Algorithmus, Schlüsselhinterlegung und Zeitpunkt der Entschlüsselung
• Constraints durch die weltweite Verteilung (z. B. Roll-Out in Frankreich und China) und mögliche Umsetzungsvarianten

Nach und nach konkretisierten sich die Randbedingungen durch Gesprächen mit Stakeholdern, wodurch sich die Zahl der möglichen Alternativen reduzierten. Die verworfenen Alternativen verschob ich in den Anhang und dokumentierte den Grund.]]> Blogger.de andreas lechner Methoden Copyright © 2008 andreas lechner 2008-10-22T21:15:08Z https://requirements.blogger.de/stories/1244185/ Projektkontext
Ein bestehendes Portal zur Auslieferung von Dokumenten an Kunden sollte abgelöst werden. Im Vordergrund stand dabei eine vereinfachte Wartung und Pflege der Dokumente je Kunde. Das neue Portal sollte die spezifischen Eigenschaften des Kundenkreises berücksichtigen und so den Pflegeaufwand reduzieren, um identische Dokumente an verschiedene Kunden zu verteilen, die bisher für jeden Kunden separat eingestellt werden mussten. Die neue Lösung sollte diesen Schritt automatisieren.
Ein wichtiger Aspekt des Konzept war also, die Arbeitsweise effizienter zu gestalten.
Da ich zum Zeitpunkt der Konzeption erst kurz bei der GfK war, war es für mich außerdem wichtig, die Arbeitsweise der Kollegen kennen zu lernen.
Eine Herausforderung war, die Ausnahmen vollständig zu erfassen und Möglichkeiten zu deren Behandlung zur Verfügung zu stellen.

Lösung
Im Konzept fokussierte ich zunächst auf den Workflow um die zukünftige effiziente Arbeitsweise zu definieren. Sonderfälle und Ausnahmen konnten im Workflow dargestellt werden.
Zur Dokumentation nutzte ich klassische Use-Cases mit Diagramm zur Übersicht und Beschreibung für die Details des Workflows. Mithilfe der Beschreibung konnte ich den Workflow mit den Anwendern durchsprechen und Sonderfälle identifizieren sowie die Vereinfachung der Arbeitsweise deutlich machen. Unterstützend nutzte ich einfache Objektdiagramme (kein UML, sondern Powerpoint ;-)

Beispiele
Das Use-Case-Diagramm zeigt einen Überblick über die geplanten Erweiterungen. Die Use-Cases beschreiben die Workflows.


Häufig habe ich Use-Cases auf der Ebene einer Systemspezifikation eingesetzt.]]> Blogger.de andreas lechner Methoden Copyright © 2008 andreas lechner 2008-10-15T20:58:32Z Search this site: q https://requirements.blogger.de/search