Was sind die Best Practices/Methoden/Tools/Techniken zur Konfliktidentifikation in Anforderungen?

Für diese Diskussion Anforderungen = User-Stories (da ich per se keinen Prozess unterscheide und Unklarheiten beseitigen möchte).

Es ist durchaus üblich, einen Satz von etwa 100-500 Anforderungen für kleine bis mittlere Systeme zu haben. Es ist aber natürlich, dass es eine Weile dauert, bis man herausfindet, welche Anforderungen widersprüchlich sind (um so mehr, wenn >1 Stakeholder beteiligt ist). Entweder werden sie mit Excel oder Karteikarten/Post-its oder vielleicht in einem Projektmanagement-Tool erfasst.

Wie also geht man bei der Identifizierung von Konflikten innerhalb von Anforderungen vor? Welche Praktiken haben Sie angewendet und für nützlich befunden (in Bezug auf aufgewendete Zeit/Aufwand und identifizierte Konflikte).

Lohnt sich die Konfliktidentifikation überhaupt, oder ist es besser, sie zu lösen, „wenn Sie dort ankommen“, da dies zu einem Missmanagement der Erwartungen führen könnte, wenn sie später gelöst würden?

Ich spreche NICHT von -ilitätskonflikten. Diese sind aber offensichtlich und sollten meiner Meinung nach früher geklärt werden. Ich spreche von Konflikten zwischen verschiedenen funktionalen Anforderungen zusammen mit funktionalen vs. nicht-funktionalen Konflikten.

Einige Beispiele sind:

  • Terminologiekonflikte - dh unterschiedliche Begriffe, die verwendet werden, um sich auf dasselbe Konzept zu beziehen
  • Strukturkonflikte – klassischerweise „Datum“ – werden als MM/TT/JJ und an anderer Stelle als TT/MM/JJJJ bezeichnet
  • Direkte Konflikte – die Angabe einer Anforderung erfüllt bekanntermaßen eine andere nicht, z. B. sind die Zeitfenster der Teilnehmer einer Kalender-App privat , während der Organisator des Meetings in der Lage sein sollte, die Meeting-Zeit aller Teilnehmer zu sehen, bevor er sich für ein Meeting-Slot entscheidet

Letzteres (direktes) kann verhandelbar sein oder nicht, aber es lohnt sich meiner Meinung nach, es frühzeitig zu erkennen.

Es ist ziemlich umständlich, jede Anforderung einzeln durchzugehen, um Konflikte zu identifizieren. Das Beste ist, den Aufwand aufzuteilen und zu beschleunigen. Eine andere Strategie besteht darin, die Anforderungen hierarchisch zu analysieren, aber das kann bestimmte Konflikte verbergen, die in den unteren "Knoten" auftreten würden (und das sind diejenigen, die Sie meiner Meinung nach später beißen werden :)

Mir sind keine Tools/Techniken/Best Practices bekannt, die helfen würden, Konflikte mit minimalem Zeit-/Aufwandsaufwand zu identifizieren, und daher die Frage. Der obige manuelle Schritt ist der beste, den ich kenne. Ja, in einer idealen Welt wäre es großartig, wenn das Tool potenzielle Konflikte ausspucken würde, aber ich weiß nicht, ob ein Tool dies tut (oder sogar einen halbwegs guten Job macht. Hilfe?)

Was ist also in einer idealen Welt (ohne Maschinen, die natürliche Sprache beherrschen :) die beste Technik, um Konflikte zu identifizieren (vorausgesetzt, es ist menschenintensiv) und welche Erfahrungen haben Sie damit gemacht? Wenn es sich nicht lohnt, erkläre das bitte auch.

Antworten (3)

Widersprüchliche oder widersprüchliche Anforderungen sind nicht nur Teil eines IT-Projekts, sondern erstrecken sich über alle Arten von Projekten. Sie können sicher sein, dass Sie eine Anforderungsbaseline mit einer Vielzahl inkonsistenter oder widersprüchlicher Anforderungen erstellen werden, egal wie sehr Sie sich auch bemühen, dies zu vermeiden. Darüber hinaus könnte die zur Erfüllung einer Anforderung abgeleitete Lösung eine andere Lösung für eine andere Anforderung brechen oder eine dritte Anforderung unmöglich machen.

Ich finde keinen Wert, dh Geld, das nicht gut angelegt ist, um zu versuchen, dieses Phänomen zu minimieren oder zu beseitigen. Der Grund? Denn wenn Sie einen Satz von Anforderungen aufheben, führen Sie andere Konflikte oder Inkonsistenzen in einem anderen Satz von Kategorien und Klassen von Anforderungen ein.

Anforderungskonflikte sind gewiss, ebenso Änderungen. Aus diesem Grund muss jedes Projekt einen Änderungsmanagementprozess haben, damit bei Konflikten und wenn das Team klüger wird, eine Änderung verarbeitet und genehmigt werden kann. Durch Iterationen und fortschreitende Planung werden Anforderungen entzerrt, konsistent gemacht oder entfernt und ersetzt.

Anstatt also zu versuchen, eine Fähigkeit aufzubauen, um diese Konflikte zu vermeiden, bauen Sie eine starke Fähigkeit auf, mit ihnen umzugehen, wenn sie sich materialisieren.

Ich stimme zu - ich persönlich hatte Zweifel, sie auf einer so feinkörnigen Ebene zu behandeln.
Ich stimme zu, möchte aber hinzufügen, dass für die einfachsten in der Frage beschriebenen Fälle (wie Datumsformate und Terminologie) Entscheidungen getroffen werden sollten, die einen Standard festlegen. Dieser Standard sollte dann dokumentiert, veröffentlicht und durchgesetzt werden. Der Wert eines gemeinsamen Lexikons für die Diskussion komplizierter Dinge kann nicht genug betont werden, und die Kosteneinsparungen durch das einmalige Treffen einer Entscheidung und das Einsparen der Mühe, es ständig neu aufbereiten zu müssen, integrieren sich über den Produktlebenszyklus.

Sie können diese Art von Situationen wie folgt angehen:

  • Konflikte im Zusammenhang mit Prozessen wie der Fähigkeit, eine Aktion im System auszuführen. Sie müssen Ihre Anforderungen oder Stories logisch strukturieren und gruppieren.

    => Sie können Ihre Storys auf mehreren Ebenen strukturieren: zB nach Funktionsbereichen (zB Kalenderfunktion) und Prozessbereichen (zB Termine & Meetings erstellen). Auf diese Weise können Sie Ihre Geschichten aufteilen und würfeln, um Konflikte zu identifizieren.

    => Sie sollten auch Ihre Prozesse abbilden, da Sie so Ihre Geschichte End-to-End durchgehen können: Auf diese Weise können Sie Konflikte erkennen, aber auch Geschichten verfeinern/klären. In Ihrem Beispiel könnte „ Teilnehmer-Zeitfenster werden privat sein“ stattdessen „ Meine Zeit wird anderen nur als verfügbar oder nicht verfügbar angezeigt, mit Details zu meinen privaten Terminen und Meetings “ und für „ Der Meeting-Organisator sollte in der Lage sein, das zu sehen Meeting-Zeit aller Teilnehmer vor der Entscheidung für einen Meeting-Slot "könnte statt dessen sein " als Meeting-Organisator kann ich die Verfügbarkeit der Teilnehmer einsehen "). Dies wird auch dazu beitragen, Entscheidungen über Geschäftsregeln zu erleichtern, wenn solche Konflikte auftreten (ist hier die Verfügbarkeit von Personen öffentlich oder nicht?).

  • Konflikte in Bezug auf Referenzinformationen oder Daten wie Begriffe & Definitionen, Datenformate (z. B. Zahlen, Währungen, Datumsangaben, Telefonnummern usw.) oder Wertelisten (z. B. Dropdown-Listen, Standardwerte usw.): Erstellen Sie ein Referenzdatenwörterbuch (RDD), das als zentralisiertes Dokument fungiert, und teilen Sie es Ihrem Team mit. Immer wenn eine neue Anforderung/Story identifiziert wird und es sich dabei um Referenzdaten handelt, ist das RDD Ihr Kontrollpunkt, um sicherzustellen, dass es keine Konflikte von einer Story zur anderen gibt (wie z. B. die von Ihnen erwähnte). Denken Sie daran, dass das RDD ein sich entwickelndes Dokument ist, also aktualisieren und vervollständigen Sie es, während Sie die Geschichten erstellen. Es ist auch ein sehr wichtiges Dokument für Entwickler beim Programmieren des Systems und für Benutzerschulungen.
  • Hinweis : Sie werden wahrscheinlich immer noch Konflikte haben, die bestehen bleiben und erst beim Codieren oder Testen des Systems sichtbar werden, aber das Obige würde die meisten davon ansprechen, und vor allem die großen Konflikte, die gelöst werden müssen, bevor Sie mit dem Codieren der Geschichte beginnen.
Mir ist immer noch nicht klar, wie eine hierarchische Strukturierung helfen würde, wenn Konflikte über Hierarchien hinweg auftreten (dh sozusagen auf derselben Ebene, aber unterschiedlichen Unterbäumen)? Wir strukturieren unsere Anforderungen zwar auf diese Weise, aber manchmal wird es problematisch, Konflikte über Teilbäume hinweg zu identifizieren
Könnten Sie bitte näher auf die Strukturierung der Geschichten eingehen? Sie haben ein Beispiel für die Strukturierung nach Funktions- und Prozessbereich gegeben - meinen Sie beides? Ich bin mir nicht sicher, ob ich den von Ihnen vorgeschlagenen Ansatz zur Versöhnung verstanden habe. Kannst du das bitte klären?
  • Terminologiekonflikte – diese können gelöst werden, indem ein Wörterbuch für das Projekt erstellt wird. Machen Sie es für alle Beteiligten verfügbar.
  • Strukturkonflikte (Datumsangaben) – Ignorieren Sie die Anforderungen aus Systemperspektive und/oder fügen Sie eine Anforderung hinzu, damit Daten konfigurierbar sind. Dem Benutzer unterschiedliche Datumsformate anzuzeigen, ist wirklich keine große Sache ... was eine große Sache sein könnte, ist, mehrere Formate im Backend Ihres Systems zu haben. Implementierungsdetails sollten nicht in den Anforderungen enthalten sein, machen Sie die Dinge also in den Bereichen des Systems sinnvoll, in denen Sie die Kontrolle haben
  • Direkte Konflikte – Die Hauptannahme bei dieser Frage scheint zu sein, dass alle Anforderungen bekannt und von vornherein korrekt sein müssen. Die Realität ist, dass einige 500 Anforderungen aus verschiedenen Gründen im Laufe der Zeit verfeinert werden müssen. Möglicherweise werden Sie einige dieser Funktionen, die möglicherweise in Konflikt geraten, nicht einmal implementieren. Ist es also wirklich sinnvoll, sich jetzt darüber Sorgen zu machen? Das schrittweise „Fixieren“ von Anforderungen erleichtert nicht nur deren Analyse, sondern zieht auch einen Schlussstrich und schafft einen Bezugspunkt für die Verfeinerung zukünftiger Anforderungen. Wählen Sie zuerst die hochwertigen Anforderungen aus und entwerfen Sie das System unter Berücksichtigung der Modifizierbarkeit für Funktionen, bei denen ein hohes Risiko für Anforderungskonflikte/-überlastung besteht (gutes Risikomanagement spielt hier eine Schlüsselrolle). Versuchen Sie, mit der Anforderungsanalyse eine Iteration voraus zu sein,
Nur woher wissen Sie, bei welchen Anforderungen ein hohes Konfliktrisiko besteht? Sie wissen einfach nicht, welche zukünftige Anforderung mit welcher Anforderung kollidieren wird? Alles könnte sozusagen riskant sein – was das Risikomanagement faktisch trivial oder überflüssig macht. Ich bin mir nicht sicher, was Sie vorschlagen. Können Sie bitte ein Beispiel geben?
@Nupul, schau, du kannst die Zukunft nicht vorhersagen, also schwitze nicht so sehr. Ihr Fokus sollte heute darauf liegen, Ihren Kunden einen Mehrwert zu bieten. Zukünftige Anforderungen müssen bei ihrer Einführung überprüft werden. Darauf gibt es keine Patentrezepte – jemand in Ihrem Team muss die Verantwortung dafür übernehmen, die Anforderungen zu „besitzen“, sie in- und auswendig zu kennen. In Bezug auf das Risikomanagement „könnte alles riskant sein“, ist es aber nicht. Sehen Sie sich einen Risikomanagement-Ansatz wie das kontinuierliche Software-Risikomanagement-Paradigma des SEI an, um weitere Hintergrundinformationen zum Identifizieren und Risikomanagement von Risiken zu erhalten.
Was sind die Best Practices/Methoden/Tools/Techniken zur Konfliktidentifikation in Anforderungen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v