User Stories der Spezifikation zuordnen [geschlossen]

Ich erinnere mich, dass ich mir für diese Art von Tracking ein Produkt namens Telelogic DOORS angeschaut habe. Es schien perfekt, aber ich war damals nicht in der Lage, es zu empfehlen.

Das Produkt ist jetzt Teil von IBMs Rational-Tool-Suite, und ich würde davon ausgehen, dass es einen hohen Preis hat.

IBM Rational Doors

Leider ist dies ein gut verstandenes Problem und ein kolossales Kopfzerbrechen, egal wie Sie es angehen. Wenn Sie ein „vollständiges, nachvollziehbares und überprüfbares Mapping“ benötigen, sollten Sie die Spezifikation und die User Storys in dasselbe Tool ziehen.

Diese Tools ermöglichen es Ihnen, eine erste Zuordnung von der Spezifikation zu den Anforderungen/User Stories vorzunehmen und Ihnen dann Änderungen, Diskrepanzen, Lücken usw. aufzuzeigen. Sie erfordern normalerweise eine erhebliche Investition im Voraus, um eine erste Spezifikation einzuholen und dann die User Stories zu erstellen. Sie helfen auch überhaupt nicht, wenn Sie einen Teil der Spezifikation einmal erstellen, ihn als vollständig bezeichnen und der Kunde diesen Teil der Spezifikation dann ändert.

Am besten arbeiten Sie mit dem Kunden zusammen, um Teile der Spezifikation zu liefern und sie so schnell wie möglich „fertig und nicht änderbar“ zu machen. Arbeiten Sie in Versionsversionen (z. B. der Build im Januar wird 0.6 sein, der im Februar wird 0.6 sein usw.) und bauen Sie mit Ihrem Kunden auf 1.0. Scheuen Sie sich nicht, Dinge aus dem aktuellen Bereich/Projekt herauszuschieben und in "1.1"

Einige Tools, die ich verwendet habe, haben geholfen

• Kaliber RM von Borland - Gebraucht von 2003-2005. Wir hatten 1200 Anforderungen und eine "lockere Spezifikation". Mir gefielen die Mapping-Tools und die Import/Export-Funktionen. Es hat gute Arbeit geleistet, um die Anforderungen zu verfolgen, und die Spezifikation war anständig genug.
• Erstellen Sie Ihr eigenes SGML-Dokumentenformat – Dies wurde in den späten 90ern verwendet. Im Grunde haben wir unsere Dokumente „kompiliert“, und der Compiler hat sich beschwert, wenn es kein Mapping-Anforderungs-Tag gab. Es erforderte eine große Hingabe, die Struktur zu definieren und die Verbindungen aufrechtzuerhalten. (Es war ein sicherheitsrelevantes Produkt, also machte es irgendwie Sinn)

Wirklich, das ist ein riesiges Kopfzerbrechen. Wenn ich noch einmal damit konfrontiert würde, würde ich wie folgt vorgehen:

• Für weniger als 750 Anforderungen oder weniger als eine Spezifikation mit weniger als 80 Seiten würde ich eine Tabellenkalkulationszuordnung behalten und sie selbst pflegen
• Bei mehr als 750 Anforderungen oder mehr als 80 Seitenspezifikationen würde ich mit dem Kunden zusammenarbeiten, um sie aufzuteilen, bis sie klein genug sind, um damit in einer Spreadshhet zu arbeiten
• Abgesehen davon würde ich meine Anforderungen dafür aufzeigen, 3-4 Wochen damit verbringen, das richtige Tool auszuwählen, und meinen gesamten Projektentwicklungsprozess um dieses Tool herum strukturieren.

hth
und sorry die antwort ist so lang :-(

DOORS (Dynamic Object-Oriented Requirements System) ist ein Anforderungsdatenbank-Tool, das speziell für die Verwaltung von Anforderungsspezifikationen entwickelt wurde. Es wird von IBM verkauft (von Telelogic, bevor sie von IBM gekauft wurden) und wird in der US-Verteidigungsindustrie stark genutzt (und oft sogar vertraglich vorgeschrieben).

Ein kleiner Hintergrund zur Funktionsweise von DOORS ist aufschlussreich, um zu verstehen, wie es zum Verlinken von User Stories verwendet werden kann:

• Die Anforderungen aus einer bestimmten Spezifikation befinden sich in einem einzigen Modul, wobei jede Anforderung und die zugehörigen Metadaten in einem separaten Objekt gespeichert sind.
• Eine Gruppe von Modulen bildet somit den Satz von Spezifikationen für ein kompliziertes System wie einen Satelliten - beginnend mit der Prime Item Development Specification (PIDS) der obersten Ebene und durchgängig durch die Spezifikationen auf niedrigerer Ebene bis hin zu den Software Requirement Specs ( SRS) und die Hardware-Äquivalente.
• Der Zusammenhang zwischen Anforderungen auf diesen verschiedenen Ebenen wird dokumentiert und mit Verknüpfungen verwaltet. Verknüpfungen sind Verbindungen zwischen Anforderungen (dh Objekten), die sich (typischerweise) in verschiedenen Spezifikationen (dh Modellen) befinden.

Über Links ordnen Sie Ihre Mercurial-Spezifikation Ihrem Backlog zu.

Verknüpfungen zeigen Eltern-Kind-Anforderungsbeziehungen. In Ihrem Fall sieht es so aus, als hätten Sie eine Spezifikation von Ihrem Kunden erhalten und möchten die User Stories auf seine Anforderungen zurückführen können. Unter der Annahme, dass Ihre User Storys tatsächlich eine ziemlich einfache Zuordnung zu übergeordneten Anforderungen haben, sollte dies einfach zu bewerkstelligen sein. Jede User Story kann ein Objekt in einem Story-Modul sein, das mit einer Anforderung verknüpft ist.

Diese Verknüpfungen werden dann während des Design- und Entwicklungsprozesses verwendet, um zu verstehen, wie Anforderungsänderungen auf einer Ebene der Hierarchie durch das gesamte System fließen.

Wenn beispielsweise eine übergeordnete Leistungsanforderung geändert wird, ermöglicht ein einfacher Bericht, der für einen ordnungsgemäß verknüpften Satz von Spezifikationen ausgeführt wird, den Systemingenieuren, den umfassenden Satz untergeordneter Anforderungen zu bestimmen, die nun auf Auswirkungen bewertet werden müssen. Oder in Ihrem Fall kann eine Anforderungsänderung sofort zu den User Storys zurückverfolgt werden, auf die sich die Änderung auswirkt .

DOORS ermöglicht es Ihnen dann, Audits durchzuführen, um zu sehen, ob es Anforderungen gibt, die keiner User Story zugeordnet sind, User Storys, die nicht mit einer Anforderung verknüpft sind, und jede andere Kombination, die Ihnen einfällt (z. B. Anforderungen, die von mehreren User Storys erfüllt werden, obwohl dies deutet wahrscheinlich darauf hin, dass die Anforderung nicht ausreichend zerlegt ist).

Sobald der Code vollständig und freigegeben ist, können die Metadaten für die User Story und die Spezifikation aktualisiert werden, um zu zeigen, dass die Anforderung erfüllt wurde, und Berichte können generiert werden, um den Gesamtfortschritt und herausragende Funktionen anzuzeigen.

Ich bin mir sicher, dass es andere Tools (wahrscheinlich weniger teure) mit ähnlicher Funktionalität gibt, aber DOORS ist bei weitem das allgegenwärtigste – zumindest in der Luft- und Raumfahrt- und Verteidigungsindustrie.

Ich bin mir bei der „Zuordnung zu einer Spezifikation“ nicht sicher, aber in der Lage zu sein, einzelne Benutzergeschichten wieder dem „großen Ganzen“ zuzuordnen, ist definitiv etwas, mit dem ich auch zu kämpfen habe. Ich habe keine Software gefunden, die darin großartig war, obwohl ich auch nicht sehr genau gesucht habe. Ich wäre nicht überrascht, wenn einige der größeren ALM-Suiten dies hätten. Ich persönlich verwalte gerade eine „Story Map“, die es uns ermöglicht zu sehen, wie sich einzelne User Stories in das große Ganze einfügen. Die Verwaltung ist jedoch ein manueller Prozess, also nichts Automatisiertes. Wenn Sie an Story Maps interessiert sind, können Sie sich Material von Jeff Patton dazu ansehen (http://www.agileproductdesign.com/blog/the_new_backlog.html).

Es gibt ein wirklich gutes Jira User Story Mapping Plugin, das Sie verwenden können

https://marketplace.atlassian.com/plugins/com.bit.agile.bit-storymap/cloud/overview