Erfahren Sie, wie Sie Anforderungen und Assets ganz einfach als HTML-, PDF- oder Microsoft Word-Dokumente ausgeben können.
WeiterlesenArbeitsaufträge melden
Modernes Admin-Panel
Erfahren Sie, wie Sie das Modern Requirements-Admin-Panel effektiv nutzen, um die volle Kontrolle über Ihr Projekt zu erlangen.
WeiterlesenWiederverwendung von Anforderungen
Wiederverwendung von Anforderungen
Erfahren Sie, wie Sie Anforderungen in Azure DevOps wiederverwenden können
Azure DevOps ist eine hervorragende Plattform, die eine zentrale Informationsquelle bietet.
Für viele Teams reicht diese Aussage allein schon aus, um den Einsatz der weltweit führenden ALM-Plattform für ihr Anforderungsmanagement in Betracht zu ziehen. Die Möglichkeit, Entwicklungsaufgaben mit Anforderungen und diese wiederum mit Testfällen zu verknüpfen, ist kaum zu übertreffen.
Was aber, wenn Sie nicht alle Funktionen einer vollständigen ALM-Plattform benötigen?
Was, wenn Sie lediglich eine Lösung für Ihr Anforderungsmanagement benötigen?
Sie können alle umfangreichen Funktionen von Modern Requirements4DevOps nutzen, um Ihr Azure DevOps-Projekt in eine vollwertige Lösung für das Anforderungsmanagement zu verwandeln. Eine dieser Funktionen ist die Möglichkeit, Anforderungen mithilfe des Modern Requirements4DevOps Reuse-Tools projekt-, sammlungs- und serverübergreifend wiederzuverwenden.
Möchten Sie Anforderungen wiederverwenden?
Dann sind Sie hier genau richtig.
Was Sie in diesem kurzen Artikel erfahren werden:
- Vorteile der Wiederverwendung von Anforderungen
- Die beiden Arten der Wiederverwendung von Anforderungen
- Wie sich die Wiederverwendung von Anforderungen effektiv nutzen lässt
Die Vorteile der Wiederverwendung von Anforderungen
Wenn wir über die Vorteile der Wiederverwendung von Anforderungen sprechen, muss zunächst ein Punkt angesprochen werden.
Die häufigste Frage, die mir Hardware-Teams stellen, lautet: „Inwiefern könnte das für Teams von Nutzen sein, die nichts mit Software zu tun haben?“
Bevor wir also beginnen: Die Wiederverwendung von Anforderungen ist nicht nur etwas für Software-Teams.
Die Wiederverwendung von Anforderungen ist ein Thema, das oft für Aufsehen sorgt.
Das liegt daran, dass sich Unternehmen in der Weltwirtschaft zunehmend auf bestimmte Bereiche oder Segmente innerhalb bestimmter Branchen konzentrieren. Dies führt dazu, dass Unternehmen Produkte in einem bestimmten Bereich oder rund um eine bestimmte Lösung entwickeln und sich wirklich auf die wenigen Dinge konzentrieren, in denen sie wirklich erfolgreich sein können.
Das bedeutet, dass ein Team bei der Entwicklung von Projekten, Lösungen oder Systemen häufig Elemente aus einem früheren Projekt wiederverwenden kann. Hier kommt die Wiederverwendung von Anforderungen ins Spiel.
Indem ein Team diese Anforderungen im nächsten Projekt wiederverwenden kann, lässt sich der Aufwand für den Start eines neuen Projekts reduzieren.
Für manche mag das vielleicht schon klar sein.
Was jedoch vielleicht nicht auf den ersten Blick ersichtlich ist: Die Wiederverwendung kann auch eine hervorragende Möglichkeit sein, Anforderungen zu handhaben, deren Geltungsbereich über die Projektebene hinausgeht. Dazu gehören nicht-funktionale Anforderungen oder Risiken, die als unternehmensweite Vorgabe berücksichtigt werden müssen. Dies würde sogar so weit gehen, dass Ihr Team Anforderungen wiederverwenden könnte, deren Zweck streng regulativ oder auf Compliance ausgerichtet ist. Diese Funktionalität lässt sich gleichermaßen auf Software- und Hardware-Teams ausweiten und kann sogar Produktteams unterstützen, die sich einer physischen Komponente oder einem physischen Ergebnis widmen.
Die zwei Arten der Wiederverwendung von Anforderungen
Wiederverwendung von Anforderungen durch Verweis
Die Wiederverwendung von Anforderungen durch Verweise ist eine schnelle Möglichkeit, bestehende Anforderungen in Ihr Projekt zu integrieren, indem Sie einfach Verknüpfungen zu ihnen erstellen. Auf diese Weise haben Sie direkten Zugriff auf diese Arbeitselemente und können alle zugehörigen Inhalte, Verknüpfungen und Anhänge überprüfen, ohne sie tatsächlich innerhalb oder zwischen Projekten kopieren zu müssen.
Anforderungen durch Kopieren wiederverwenden
In Azure DevOps sind die Möglichkeiten zum Kopieren von Anforderungen oder anderen Arbeitselementen von einem Projekt in ein anderes sehr begrenzt. Wenn Sie jedoch Modern Requirements4DevOps in Ihre Azure DevOps-Umgebung integrieren, kann die Wiederverwendung von Anforderungen ihr volles Potenzial entfalten.
Bei der Erörterung der Wiederverwendung von Anforderungen durch Kopieren sind drei wesentliche Ansätze zu berücksichtigen.
Wie man Anforderungen effektiv wiederverwendet
Nach dem Ansehen der oben genannten Videos wird deutlich, dass das Tool „Modern Requirements4DevOps Reuse“ für die Wiederverwendung von Anforderungen sehr effektiv ist.
Es bietet vollständige Kontrolle über die Anforderungen, die Sie wiederverwenden möchten, ermöglicht es Ihnen, diese Anforderungen anzupassen, und erlaubt es Ihnen, die Anforderungen mit dem ursprünglichen Workitem zu verknüpfen.
Das bedeutet, dass Sie Anforderungen mit dem Modern Requirements4DevOps Reuse-Tool an jeden beliebigen Ort senden können. Es gibt jedoch einige Möglichkeiten, wie Sie das Reuse-Tool noch effektiver nutzen können.
Als erstes ist die Kombination des Reuse-Tools mit dem „Modern Requirements4DevOps Baseline“-Tool zu nennen.
Was ist eine Baseline?
Viele Teams nutzen Baselines für Anforderungen, ohne sich dessen überhaupt bewusst zu sein.
Eine Baseline ist eine Momentaufnahme der Arbeitselemente zu einem bestimmten Zeitpunkt.
Viele Teams verwenden einfach die Versionen von Microsoft Word-Dokumenten als Baseline.
Wenn es darum geht, Anforderungen zu einem bestimmten Zeitpunkt zu erfassen, gibt es viele Gründe, warum die Funktion „Modern Requirements4DevOps“ dem herkömmlichen Microsoft Word-Ansatz überlegen ist. Mit den „Modern Requirements4DevOps Baselines“ können Sie eine Reihe von Arbeitsaufgaben so erfassen, wie sie zu einem beliebigen Zeitpunkt Ihrer Wahl vorlagen.
Das bedeutet: Wenn Sie Ihre Anforderungen so erfassen möchten, wie sie vor zwei Wochen waren, können Sie ganz einfach eine Baseline für diese Anforderungen zu diesem Datum erstellen. Dies führt direkt zu den Vorteilen des von Modern Requirements4DevOps hinzugefügten Reuse-Tools.
Durch die Kombination des Reuse-Tools mit unserer Baseline können Sie nicht nur die Anforderungen auswählen, die Sie wiederverwenden möchten, sondern auch die jeweilige Version dieser Anforderungen. So können Sie die beste und am besten geeignete Version Ihrer Anforderungen in Ihr nächstes Projekt übernehmen.
Als Nächstes ist zu erwähnen, dass man bei der Wiederverwendung von Anforderungen das Präfix, das Postfix und andere Operationen effektiv einsetzen sollte.
Bei der Wiederverwendung von Anforderungen können Sie mit dem Tool „Modern Requirements4DevOps Reuse“ festlegen, wie die wiederverwendeten Anforderungen im Zielprojekt dargestellt werden sollen.
Der Bildschirm, über den Sie dies tun können, ist unten zu sehen:
Mit dieser Funktion können Sie den Anforderungen ganz einfach ein Präfix oder Suffix hinzufügen, sobald sie das von Ihnen ausgewählte Zielprojekt erreichen. Wie oben gezeigt, können Sie diese Anforderungen auch an einen bestimmten Bereichspfad (wie beispielsweise „Hardware“ oder „Software“) oder sogar an eine bestimmte Iteration senden, sodass Sie entscheiden können, wann diese Anforderungen bearbeitet werden.
Die am häufigsten genutzte Funktion in den Feldoptionen ist jedoch die Möglichkeit, ein Tag hinzuzufügen.
Wenn Sie Anforderungen von einem Projekt in ein anderes übertragen, möchten Sie diese Anforderungen im Zielprojekt oft leicht identifizieren und nachverfolgen können. Durch das Hinzufügen eines Tags ist dies möglich.
Inwiefern hängt dies mit der Option „Source Work Item“ zusammen?
Mit dieser Option können Sie eine Verknüpfung zwischen dem Workitem, das Sie wiederverwenden, und dem Workitem herstellen, das Sie in Ihrem Zielprojekt anlegen.
Welchen Link erstellt das?
Es verknüpft Ihr neues Ziel-Workitem mit Ihrem ursprünglichen Workitem über den Link „Verwandt“ oder einen beliebigen anderen Linktyp, den Sie im Admin-Bereich konfiguriert haben.
In der folgenden Abbildung sehen Sie einen Testfall, den ich von einem Projekt in ein anderes kopiert habe, wobei sowohl das Präfix „CL- “ als auch die Option „Mit Quell-Workitem verknüpfen“ aktiviert waren.
Using the “Link to source work item” feature allows you to easily trace requirements back to where they were pulled from. While there are many use cases for this feature when moving requirements directly from project to project, this more advanced use cases are for when you are moving requirements from a library or repository into a project instead.
Wie fügt man kopierte Baselines zusammen?
Baseline ist ein sehr nützliches Werkzeug, ganz gleich, ob Sie ein einzelnes Arbeitselement oder eine lange Liste von Arbeitselementen aus Ihrem Quellprojekt bzw. Ihrer Quellbibliothek wiederverwenden möchten. In Modern Requirements können Sie Verknüpfungen zwischen Ihren Quell- und den kopierten Arbeitselementen erstellen, sodass Sie die Herkunft dieser kopierten Arbeitselemente zurückverfolgen können.
Obwohl Verbindungen zwischen ihnen bestehen, gelten die kopierten Arbeitselemente weiterhin als unabhängig von den Quell-Arbeitselementen, was bedeutet, dass Änderungen, die Sie entweder an den kopierten oder an den Quell-Arbeitselementen vornehmen, keine Auswirkungen auf das jeweils andere Element haben.
Vielleicht fragen Sie sich: Wie lassen sich die Änderungen bei Bedarf synchronisieren? Angenommen, Sie haben eine Bibliothek, in der alle Ihre Arbeitselemente für Designspezifikationen gespeichert sind, und Sie haben diese in 5 verschiedenen Projekten wiederverwendet. Wenn Sie nun einige Designs in der Bibliothek ändern müssen und möchten, dass alle kopierten Designspezifikationen synchronisiert werden, können Sie einfach die Merge-Funktion verwenden, die sich unter „Source Copied Baseline(s)“ oder „Target Copied Baseline(s)“ auf der Registerkarte „Details“ des Baseline-Moduls befindet.
Baseline ist ein sehr nützliches Werkzeug, ganz gleich, ob Sie ein einzelnes Arbeitselement oder eine lange Liste von Arbeitselementen aus Ihrem Quellprojekt bzw. Ihrer Quellbibliothek wiederverwenden möchten. In Modern Requirements können Sie Verknüpfungen zwischen Ihren Quell- und den kopierten Arbeitselementen erstellen, sodass Sie die Herkunft dieser kopierten Arbeitselemente zurückverfolgen können.
Obwohl Verbindungen zwischen ihnen bestehen, gelten die kopierten Arbeitselemente weiterhin als unabhängig von den Quell-Arbeitselementen, was bedeutet, dass Änderungen, die Sie entweder an den kopierten oder an den Quell-Arbeitselementen vornehmen, keine Auswirkungen auf das jeweils andere Element haben.
Vielleicht fragen Sie sich: Wie lassen sich die Änderungen bei Bedarf synchronisieren? Angenommen, Sie haben eine Bibliothek, in der alle Ihre Arbeitselemente für Designspezifikationen gespeichert sind, und Sie haben diese in 5 verschiedenen Projekten wiederverwendet. Wenn Sie nun einige Designs in der Bibliothek ändern müssen und möchten, dass alle kopierten Designspezifikationen synchronisiert werden, können Sie einfach die Merge-Funktion verwenden, die sich unter „Source Copied Baseline(s)“ oder „Target Copied Baseline(s)“ auf der Registerkarte „Details“ des Baseline-Moduls befindet.
Erinnern Sie sich noch an die Definition einer Baseline? Es handelt sich um eine Momentaufnahme ausgewählter Arbeitselemente zu einem bestimmten Zeitpunkt. Unabhängig davon, welche Änderungen wir an den in der Baseline enthaltenen Arbeitselementen vorgenommen haben, bleibt die gespeicherte Momentaufnahme unverändert. Selbst wenn wir die Baselines zusammengeführt haben, werden die Änderungen an den neuesten Versionen der Arbeitselemente vorgenommen, nicht an den Baselines selbst. Klingt das etwas schwer verständlich?
Bitte sehen Sie sich das 5-minütige Video zum Zusammenführen kopierter Baselines an.
Want to experience reuse’s full potential?
Testen Sie „Modern Requirements4DevOps“ noch heute kostenlos.
Wir bieten Ihnen die Möglichkeit, unsere Lösung für das Anforderungsmanagement in Ihrer eigenen Azure DevOps-Umgebung oder in einer von uns bereitgestellten Umgebung mit Beispieldaten zu testen.
Inhaltsverzeichnis
Aktuelle Artikel
Arbeitsaufträge melden
Learn how to easily output requirements and assets in either...
Modernes Admin-Panel
Learn how to effectively use the Modern Requirements admin panel...
Wiederverwendung von Anforderungen
Reusing Requirements January 2, 2020 Reading Time: 8 minutes Learn...
Anforderungen in Azure DevOps importieren
Anforderungen in Azure DevOps importieren
Erfahren Sie, wie Sie Anforderungen (und einige Assets) ganz einfach in Ihr ADO-Projekt importieren können
Wenn Sie zu Azure DevOps wechseln oder offline arbeiten und keinen Zugriff auf Ihr bestehendes Azure DevOps-Projekt haben, benötigen Sie eine Möglichkeit, Ihre neu erstellten Anforderungen in Azure DevOps zu übertragen.
Viele Teams stehen vor der Herausforderung, die Anforderungen, die sie in Excel, Word und anderen Programmen erstellt haben, in Azure DevOps zu übertragen. Glücklicherweise gibt es einige einfache Möglichkeiten, dies zu bewerkstelligen, ohne dass Sie Ihren Prozess um langwierige Kopier- und Einfügevorgänge erweitern müssen!
In diesem Artikel werden wir einige verschiedene Möglichkeiten zum Importieren von Anforderungen behandeln.
Eine dieser Optionen ist kostenlos, und einige Funktionen stehen zur Verfügung, wenn Sie „Modern Requirements4DevOps“ zu Ihrem Azure DevOps-Projekt hinzufügen.
Dieser Artikel behandelt folgende Themen:
- Anforderungen aus Microsoft Excel importieren
- Anforderungen für den Import aus Microsoft Word
- Diagramme und Mockups in Azure DevOps importieren
Anforderungen aus Microsoft Excel importieren
Ganz gleich, ob Sie alle oder nur einen Teil Ihrer bestehenden Anforderungen in Excel gespeichert haben oder ob Sie Anforderungen aus einem internen Tool in eine CSV-Datei exportieren möchten – es gibt eine kostenlose Möglichkeit, Ihre Anforderungen in Ihr Azure DevOps-Projekt zu importieren.
Dies ist eine kostenlose Lösung – vorausgesetzt, Sie verfügen bereits über Azure DevOps und Excel.
Als Erstes sollten Sie sicherstellen, dass Sie über das Microsoft Excel-Add-In „Team-Registerkarte“ verfügen .
Sie können dieses Add-in direkt hier herunterladen:
(Auf der oben genannten Seite ist „Azure DevOps Office® Integration 2019“ im Abschnitt „Sonstige Tools, Frameworks und Redistributables“aufgeführt.)
Wenn Sie auf den obigen Link geklickt haben, können Sie die Registerkarte „Team“ in Excel aktivieren.
Wenn diese Erweiterung aktiviert ist, können Sie eine Excel-Tabelle direkt mit einem bestimmten Projekt in Ihrer Azure DevOps-Organisation verknüpfen.
Wenn Sie diese Funktion aktivieren, stehen Ihnen zwei Hauptfunktionen zur Verfügung:
1) Sie können Anforderungen aus Excel inIhr Projekt übertragen
2) Sie können Anforderungen ausIhrem Projekt inExcel exportieren
Das bedeutet, dass Sie Ihre Anforderungen über beide Oberflächen bearbeiten und die Änderungen mit Ihrem Projekt synchronisieren können. Wenn Sie also Anforderungen in Excel importieren und dort Änderungen vornehmen, können Sie diese Änderungen wieder in die Anforderungen Ihres Projekts übertragen.
Nachdem Sie das heruntergeladene Installationsprogramm ausgeführt haben, können Sie die Erweiterung aktivieren.
So aktivieren Sie die Registerkarte „Team“in Excel:
- Excel öffnen
- Leeres Blatt erstellen
- Klicken Sie auf „Datei“
- Auf „Optionen“ klicken
- Klicken Sie auf „Add-Ins“
- Wählen Sie „COM-Add-Ins“ aus dem Dropdown-Menü am unteren Rand des Fensters
- Wählen Sie „Team Foundation Add-In“ und klicken Sie auf „OK“.
Sollten bei diesem Vorgang Probleme auftreten, folgen Sie bitte diesem Link.
Wenn Sie nun in Excel die Registerkarte „Team“ sehen, können Sie mit dem Importieren der Anforderungen beginnen!
Verwendung der Registerkarte „Team“ in Excel
In diesem Video zeigen wir Ihnen, wie Ihr Team die Importfunktionen nutzen kann, die das Add-In „Excel Team“ bietet.
Anforderungen für den Import aus Microsoft Word
Die zweite Möglichkeit, Anforderungen in Ihr Projekt zu importieren, ist über Microsoft Word.
Diese Funktion ist eine „Vorschau-Funktion“, die mit jeder Enterprise Plus Modern Requirements4DevOps-Lizenz verfügbar ist. Das bedeutet, dass jeder Benutzer in Ihrem Unternehmen, der über eine Enterprise Plus-Lizenz verfügt, auf die Word-Importfunktion zugreifen und diese nutzen kann.
Wenn Sie „Modern Requirements4DevOps“ derzeit noch nicht nutzen, können Sie diese Word-Importfunktion testen, indem Sie „Modern Requirements4DevOps“ noch heute ausprobieren!
Wie funktioniert der Word-Import?
Warnung: Da es sich um eine Vorschaufunktion handelt, solltest du damit rechnen, dass dies vielleicht nicht die eleganteste Lösung ist und in der Regel einige Programmierkenntnisse erfordert. Aber nicht viel – und wenn du dir für 20 Minuten einen Entwickler ausleihen kannst, der sich mit XML (oder einer anderen Skriptsprache) auskennt, sollte das kein Problem sein.
Für den Word-Import benötigen Sie ein gut formatiertes Word-Dokument, in dem die verschiedenen Arbeitselemente bzw. Anforderungen und deren Eigenschaften durch unterschiedliche Überschriften dargestellt werden.
Nehmen wir zum Beispiel ein BRD, das Sie vielleicht bereits im Word-Format haben.
Wahrscheinlich haben Sie Ihre Einleitung, den Überblick, den Umfang und andere kontextbezogene Elemente mit dem Stil „Überschrift 1“ formatiert.
Möglicherweise sind in diesem Dokument auch Ihre Epics, Features und User Stories enthalten.Ihr Dokument könnte dannetwa so aussehen:
Überschrift 1 – Einleitung
-> Absatz –Der gesamte Text der Einleitung kommt hierhin…
Überschrift 1 – Überblick
-> Absatz –Der gesamte Text für den Überblick kommt hierhin…
Überschrift 1 – Geltungsbereich
-> Absatz –Der gesamte Text für den Geltungsbereich kommt hierhin…
Überschrift 1 – Anforderungen
-> Überschrift 2 – Name des Epics
–> Überschrift 3 – Name der Funktion
—> Überschrift 4 – Name der User Story
—-> Absatz – Beschreibung der oben genannten User Story
Dein Dokument sieht vielleicht etwas anders aus, aber das macht nichts.Die Grundsätze, die du gleich kennenlernen wirst, sind dieselben.
Für den Word-Import sind ein Dokument (siehe oben) und ein Regelsatz (siehe unten) erforderlich.
In der Regel erstellt ein Administrator einen Regelsatz, den Ihr Team für den Import von Dokumenten verwendet, und dies muss nur einmal erfolgen.Wenn Sie also bereits ein Dokument erstellt haben und Ihr Administrator einen Regelsatz angelegt hat, können Sie loslegen.
Wenn Ihr Administrator einen Regelsatz erstellen muss, lesen Sie weiter.
Das Erstellen eines Regelsatzes ist unglaublich einfach und erfolgt durch Bearbeiten einer XML-Datei.
Die von Ihnen erstellte XML-Datei legt fest, wie das Word-Import-Tool Ihr Dokument analysiert, um Folgendes zu ermitteln:
1) Welche Teile des Dokuments sind Arbeitselemente?
2) Welche Teile des Dokuments sind Eigenschaften eines bestimmten Arbeitselements?
Wenn Sie diese Anleitung in Echtzeit durcharbeiten, könnte es hilfreich sein, diese Regelsatzdatei als Ausgangspunkt herunterzuladen und sich das folgende Video anzusehen:
Erste Schritte mit dem Beispiel-Regelsatz
In diesem Video zeigen wir Ihnen, wie Sie mithilfe der Beispiel-Regelsatzdatei ein einfaches Anforderungsdokument importieren können. Bitte beachten Sie, dass die Erstellung eines Regelsatzes in der Regel ein einmaliger Vorgang ist.
Diagramme und Mockups in Azure DevOps importieren
Diagramme, Mockups und Anwendungsfallmodelle können äußerst nützliche Hilfsmittel für die Erstellung und Ermittlung von Anforderungen sein.
Deshalb kann Ihr Team mit Modern Requirements4DevOps all diese Visualisierungen ganz einfach direkt aus Ihrem Projekt heraus erstellen. So profitieren Sie von einem Modell mit einer einzigen Datenquelle, bei dem alles in Ihr Projekt integriert ist.
Vielleicht verfügen Sie aber bereits über Diagramme und Mockups, die Sie Ihrem Azure DevOps-Projekt hinzufügen und mit Anforderungen verknüpfen möchten. Ist es möglich, diese Assets zu importieren?
Die Antwort lautet: Ja.
Sowohl mit unserem Mockup-Tool als auch mit unserem Diagramm-Tool können Sie vorhandene Mockups oder Diagramme ganz einfach in Ihr Azure DevOps-Projekt einbinden.
Speichern Sie dazu Ihr Element einfach als PNG- oder JPEG-Datei aus dem von Ihnen gewählten Mockup-/Diagramm-Tool.
Anschließend können Sie Ihr erstelltes Element entweder in das Modern Requirements4DevOp-Simulationstool (Mockups)oder indas Diagramm-Tool (Diagramme) hochladen.
Vielleicht fragst du dich: „Aber wenn wir die Dateien als .png oder .jpeg hochladen, wie können wir dann unsere Diagramme und Mockups bearbeiten?“ Nun, das geht nicht. Aber es gibt trotzdem einen Grund, warum du es trotzdem tun solltest.
Wenn Sie ein einzelnes Diagramm mit 25 Anforderungen verknüpfen möchten, ohne „Modern Requirements“ zu verwenden, müssen Sie alle 25 Anforderungen öffnen und sie jeweils einzeln mit dem Diagramm verknüpfen.
Wenn Sie Ihr Diagramm in Zukunft aktualisieren, müssen Sie alle 25 Anforderungen erneut öffnen und den Anhang ändern.
Mit Modern Requirements4DevOps können Sie jedoch ein Diagramm-Arbeitselement erstellen, mit dem Sie alle erforderlichen Anforderungen über das rechte Fenster direkt verknüpfen können. Das bedeutet, dass Sie Ihr Diagramm an einem einzigen Ort haben. Wenn dieses Diagramm aktualisiert werden muss, können Sie ganz einfach Ihr aktualisiertes Bild hinzufügen und Ihren Anhang mit diesem einen Arbeitselement verknüpfen.
Schlussfolgerung
In diesem Artikel haben wir drei verschiedene Möglichkeiten vorgestellt, wie Sie sowohl Anforderungen als auch die dazugehörigen Assets in Ihr Azure DevOps-Projekt importieren können.
Sie können Anforderungen über Excel oder Word importieren oder Ihre vorhandenen Diagramme und Mockups importieren.
Wenn Sie daran interessiert sind, Modern Requirements4DevOps zur Unterstützung Ihres Anforderungsmanagementprozesses einzusetzen, probieren Sie unser Produkt doch einfach hier aus!
Das FAQ-Modul
Das FAQ-Modul
Die Lösung für die Erfassung der Anforderungen im Vorfeld
In diesem Artikel behandeln wir die Funktionen und Vorteile des FAQ-Moduls.
Dieses Modul wurde entwickelt, um Teams zu unterstützen, die zu Beginn ihres Anforderungsmanagementprozesses Anforderungen erfassen. Durch die Erstellung von Fragenlisten können Teams ihr Wissen über den Erfassungsprozess leicht erfassen und wiederverwenden, um die richtigen Fragen zu stellen, die zu den besten Anforderungen führen.
Was ist das FAQ-Modul?
Das FAQ-Modul ist eine Sammlung von Fragenlisten, die Ihr Team erstellen, bearbeiten, ändern, als Vorlage verwenden und zur Ermittlung von Anforderungen nutzen kann. Durch die Verwendung des FAQ-Moduls zum Aufbau einer Wissensdatenbank für Ihr Team können Sie sicher sein, dass jedes Teammitglied effektiv mit den Stakeholdern kommunizieren kann.
Durch die Erstellung der besten Fragen zu diesem Bereich kann Ihr Team sicherstellen, dass es stets die bestmöglichen Anforderungen ermittelt.
Der Hauptvorteil dieses Moduls besteht darin, dass es Ihrem Team die Möglichkeit bietet, eine Wissensdatenbank aufzubauen, die sowohl von erfahrenen Business Analysten als auch von denen genutzt werden kann, die Anforderungen in einem ihnen unbekannten Bereich ermitteln müssen. Das FAQ-Modul enthält bereits über 3000 Fragen zu vielen verschiedenen Themen.
Zu diesen Themen gehören mehrere Vorlagen zur ISO-Konformität sowie Vorlagen zu nicht-funktionalen Anforderungen wie Skalierbarkeit, Wiederverwendbarkeit oder Bedienbarkeit, die für die Ermittlung verwendet werden können.
Für viele Teams wird dieses Modul die Excel-basierten Fragenlisten ersetzen, die sie möglicherweise in der Vergangenheit verwendet haben.
Um mit den anderen Modulen des Modern Requirements-Toolset im Einklang zu bleiben, verbindet das FAQ-Modul einen bisher getrennten Prozess direkt mit Ihrem Projekt. Das bedeutet, dass Ihre Teams ganz einfach Anforderungen zu Ihrem Projekt hinzufügen können, indem sie die Fragen in Ihrer FAQ-Fragenliste beantworten.
Welchen Mehrwert bietet das FAQ-Modul?
Der Wert unseres FAQ-Moduls lässt sich in zwei einfachen Punkten beschreiben.
- Das FAQ-Modul hilft dabei, bessere Anforderungen zu erstellen, indem es den Erhebungsprozess begleitet und so die Wahrscheinlichkeit eines erfolgreichen Projektabschlusses erhöht.
- Das FAQ-Modul reduziert den Zeitaufwand für die Ermittlung von Anforderungen während Ihres gesamten Projekts, sodass Ihr Team schneller mit der Entwicklung beginnen kann.
Durch die Nutzung des wertvollen Wissens erfahrener Business Analysten können Sie domänenspezifische Fragenvorlagen erstellen, die Ihnen dabei helfen, den Erhebungsprozess zu strukturieren. Das bedeutet, dass Sie jeden Business Analysten unabhängig von seiner Erfahrung in einen Raum mit einem Stakeholder schicken können und sicher sein können, dass er vollständige und umsetzbare Anforderungen erstellt.
Da Sie keine Fragenvorlagen mehr erstellen und die ermittelten Anforderungen anschließend in Ihr RM-Tool kopieren müssen, kann Ihr Team den Erfassungsprozess schneller durchlaufen. Das bedeutet, dass mehr Zeit für die Überarbeitung genauerer Anforderungen bleibt und weniger Zeit für das Kopieren und Einfügen von User Stories aufgewendet werden muss, die wahrscheinlich noch mehr Arbeit erfordern.
Was sind die Anwendungsfälle für das FAQ-Modul?
Wenn wir mit unserer Community über die Nutzung des FAQ-Moduls sprechen, beschreiben sie oft, wie dieses Modul ihre Prozesse optimiert und die Erhebungsphase von Projekten einfacher gestaltet hat.
Selbst Teams, die traditionell keine Fragenlisten verwenden, berichten uns nach ihrem Beitritt zu unserer Community, wie sehr sie es schätzen, das Wissen aller Teammitglieder in einer einheitlichen Liste zusammenfassen zu können.
Hier sind die Anwendungsfälle, die wir für das FAQ-Modul gesehen haben.
ANWENDUNGSFALL 1
Mein Team sammelt derzeit zunächst die Anforderungen und arbeitet anschließend iterativ an unserem Projekt. Derzeit verwenden wir Excel während der Phase der Anforderungserfassung, was jedoch bedeutet, dass wir die Anforderungen anschließend in das Tool unserer Wahl kopieren müssen.
Da wir als Team die Anforderungen im Voraus erfassen, bietet sich die perfekte Gelegenheit, eine für diesen Bereich entwickelte Fragenliste zu verwenden. Die Verwendung von Excel als Hilfsmittel für diese Fragenliste führt jedoch später zu einem langwierigen Kopier- und Einfügevorgang.
Kopieren/Einfügen-Prozesse sind in der Regel fehleranfällig und zeitaufwendig. Oftmals bemerkt ein Teammitglied gerade während dieser ohnehin schon langwierigen Kopier-/Einfügevorgänge, dass es eine Eigenschaft eines Arbeitselements übersehen hat, zu der es die Meinung eines Stakeholders einholen muss.
In diesem Fall bedeutet die Verwendung des FAQ-Moduls, dass Sie die Fragenliste bereits in Ihrem Azure DevOps-Projekt haben. Wenn Sie Ihren Stakeholdern Ihre Frage stellen, können Sie diese Frage in Ihrer FAQ-Fragenliste beantworten, woraufhin automatisch eine Anforderung für Sie erstellt wird.
Sie können diese Anforderung dann direkt öffnen und alle weiteren Fragen klären, die Sie möglicherweise haben, während Sie noch mit Ihrem Stakeholder zusammen sind. Das spart Zeit und macht den Erfassungsprozess gründlicher, während Ihr Team keine Gelegenheit verpasst, die richtigen Informationen zum richtigen Zeitpunkt zu erhalten.
ANWENDUNGSFALL 2
Mein Team arbeitet in einem konformen/regulierten Umfeld und wir müssen sicherstellen, dass wir alle Anforderungen erfüllen, um konform und auditierbar zu bleiben.
Eine der besten Funktionen des FAQ-Moduls ist, dass Sie viele unserer vorgefertigten Vorlagen zum Thema Compliance verwenden können, um Anforderungen zu ermitteln. Unsere vorgefertigten Vorlagen wurden in Zusammenarbeit mit vielen unserer bestehenden Kunden sowie durch Partnerschaften mit Vordenkern in diesen Bereichen erstellt.
In diesem Fall können Teams, die Zugriff auf das FAQ-Modul haben, mit Fachexperten und Beratern sprechen und eine Fragenliste erstellen, die ihnen dabei hilft, alle für die Einhaltung von Vorschriften und Bestimmungen erforderlichen Anforderungen zu formulieren. Nach ihrer Erstellung können diese Fragenlisten in mehreren Projekten wiederverwendet und immer wieder eingesetzt werden.
Wie nutze ich das FAQ-Modul effektiv?
Das FAQ-Modul bietet Teams in der Erhebungsphase ihres Projekts unglaubliche Vorteile. Hier sind einige Möglichkeiten, wie Sie das Modul nutzen können, um den Projekterfolg zu fördern.
Verwenden Sie die vorgefertigten Vorlagen für Fragenlisten.
Wenn Benutzer eine Vorlage zu nicht-funktionalen Anforderungen oder zu ISO-Themen benötigen, können sie mit einer unserer integrierten Vorlagen schnell loslegen. Diese Vorlagen enthalten bereits viele der wichtigsten Fragen zu diesen Themen. Benutzer können mit einer vorgefertigten Vorlage beginnen und nicht relevante Fragen entfernen und/oder neue Fragen hinzufügen, die erforderlich sind.
Erstellen Sie Ihre eigenen Vorlagen für Fragenlisten
Wenn eine unserer vorgefertigten Vorlagen Ihren Anforderungen nicht entspricht, können Teams ganz einfach eigene Fragenlisten von Grund auf erstellen. Ausgehend von einer leeren Vorlage kann Ihr Team ganz einfach einen umfassenden Fragenkatalog erstellen, der die Ermittlung von Anforderungen zu einem einfachen und effizienten Prozess macht.
Sobald eine Fragenliste erstellt wurde, kann sie projektübergreifend wiederverwendet werden, um Ihnen später in der Erhebungsphase zu helfen.
Erstellen Sie Fragenlisten für weniger erfahrene Mitglieder Ihres Teams.
Durch das Erstellen von Fragenlisten bieten Sie allen Mitgliedern, die mit einem Bereich, einer Lösung oder einem System weniger vertraut sind, eine effektive Orientierungshilfe. Diese Listen sind dann ein hervorragendes Hilfsmittel, um neue BAs oder erfahrene BAs aus einem anderen Bereich während der Erfassungsphase anzuleiten. Die Teams wissen, dass die Qualität der Fragen, die wir zu Beginn eines Projekts stellen, sich direkt auf die Qualität der Anforderungen auswirkt, die wir erfassen.
Durch die Erstellung von Fragenlisten mit unserem FAQ-Modul können Sie sicherstellen, dass Sie gleich beim ersten Mal die bestmöglichen Anforderungen erhalten.
MR-Dienste – E-Mail-Überwachung, benutzerdefinierte ID, Markierung als „Dirty“
In diesem Artikel stellen wir einige der zusätzlichen Funktionen vor, die in der Enterprise Plus-Edition von Modern Requirements4DevOps verfügbar sind. Diese Funktionen werden als MR Services bezeichnet.
WeiterlesenUsing Alice: BA Assistant
This module is an AI-inspired module built to help your team elicit requirements quickly.
WeiterlesenKonfiguration des MR-Agenten / Registerkarte „Dienste“
Konfigurieren von Modern Requirements4DevOps über die Registerkarte „MR Agent/Services“
In diesem Artikel erklären wir, wie man die Registerkarte „MR Agent / Services“ in MR4DevOps konfiguriert. Die Registerkarte „Services“ bietet Nutzern derzeit drei zusätzliche Funktionen für jedes Projekt, das den Azure DevOps-Dienst (ehemals VSTS) verwendet.
Konfiguration von „
“ über die Registerkarte „Dienste“ – Modern Requirements4DevOps
MR Services (früher MR Agent genannt) ist eine der Komponenten von Modern Requirements4DevOps, die automatisch zusammen mit der Hauptanwendung installiert wird. Es handelt sich um ein Framework, das Azure DevOps mithilfe von Triggern erweiterbar macht.
WICHTIG:
Bitte beachten Sie, dass MR-Dienste nur mit Azure DevOps-Diensten zugänglich sind, die über eine LIVE/ÖFFENTLICHE IP-Adresse mit VSTS (Azure DevOps-Diensten) kommunizieren. Wenn ein Rechner keinen öffentlichen Zugang hat, können die VSTS-Azure-DevOps-Dienste nicht genutzt werden (da sie für die Kommunikation mit dem Rechner einen öffentlichen Zugang benötigen). Benutzern wird empfohlen, sich an ihre Netzwerkadministratoren zu wenden, um den Wert auf die Live-IP-Adresse ihrer Rechner einschließlich des entsprechenden Ports zu ändern.
Derzeit umfasst MR Services (MR Agent) die folgenden drei Unterkomponenten:
- Benutzerdefinierte ID
- Foul
- E-Mail-Überwachung
Bevor eine dieser Komponenten konfiguriert werden kann, ist eine ordnungsgemäße Benutzerauthentifizierung erforderlich. Die Konfigurationsdateien der einzelnen Komponenten funktionieren nur, wenn die entsprechende Organisation (in Azure DevOps) oder Sammlung (in TFS) unter Verwendung der Authentifizierung registriert wurde.
Benutzerauthentifizierung bei MR Services
- Starten Sie die eingebettete Version der Anwendung und wählen Sie die Moderne Anforderungen für DevOps Option unter dem Registerkarte „Einstellungen“.
Das Admin-Panel wird angezeigt.
- Klicken Sie auf die Registerkarte „Dienste“.
Die Optionen der Registerkarte „Dienste“ werden angezeigt.
Auf der Unterregisterkarte „Einstellungen“ gibt es zwei Optionen:
- Zeitintervall festlegen, in dem die Azure DevOps-Organisation (oder TFS-Sammlung) nach neuen Projekten durchsucht wird
- Registrierung der aktuellen Organisation (Für diese Option sind die Anmeldedaten eines Administrators erforderlich)
Hinweis: Geben Sie die Werte für beide Einstellungen gleichzeitig ein. Es ist nicht möglich, nur eine der beiden Einstellungen zu konfigurieren und die andere offen zu lassen.
Geben Sie das Zeitintervall für den automatischen Scan ein (muss zwischen 1 und 60 liegen).
Dieser Wert legt fest, in welchen Zeitabständen (in Minuten) die registrierte Azure DevOps-Organisation auf neue Projekte überprüft wird.
- Geben Sie die Anmeldedaten eines autorisierten Benutzers ein (mit TFS-Administratorrechten).
Nach erfolgreicher Authentifizierung wird die aktuelle Organisation gespeichert und eine Bestätigungsmeldung angezeigt.
Ein neues Projekt in Ihrer Azure DevOps-Organisation manuell anlegen
Im vorangegangenen Abschnitt wurde beschrieben, wie man die automatische Scan-Intervallzeit für die Azure DevOps-Organisation anpassen kann. Der in der obigen Abbildung angezeigte Wert bedeutet, dass die Organisation alle 30 Minuten auf neue Projekte überprüft wird.
Wenn der Benutzer jedoch gerade ein neues Projekt erstellt hat und sofort damit arbeiten möchte, muss er es (das Projekt) manuell in der Azure DevOps-Organisation auswählen. Dazu sind folgende Schritte erforderlich:
- Geben Sie den folgenden Befehl in der Eingabeaufforderung ein: cd :\Programme\Modern Requirements\MR-Agent\bin
- Sobald Sie sich im Verzeichnis „bin“ befinden, geben Sie den folgenden Befehl ein: MRAgent
Das Optionsmenü wird angezeigt.
- Typ 4 und drücken Sie die Eingabetaste.
- Geben Sie den Namen der Azure DevOps-Organisation ein, um nach neuen Projekten zu suchen.
Wenn keine Fehlermeldung angezeigt wird, wurde der Vorgang zum Scannen neuer Projekte, die nach der Registrierung einer Azure DevOps-Organisation bzw. nach dem Anwenden ihrer Konfiguration erstellt wurden, erfolgreich durchgeführt.
Konfigurieren Sie die Funktion „Benutzerdefinierte ID“
„Custom ID“ ist eine Komponente von MR Services (MR Agent), die dazu dient, Arbeitselementen zusätzlich zu ihren Standard-ID-Nummern benutzerdefinierte ID-Nummern zuzuweisen. Die benutzerdefinierten ID-Nummern ersetzen die ursprünglichen ID-Nummern nicht, sondern ergänzen sie. Anhand der benutzerdefinierten ID-Nummern lässt sich die Herkunft der Arbeitselemente nachverfolgen (d. h., welches Team ein bestimmtes Arbeitselement erstellt hat).
Damit die benutzerdefinierte ID ordnungsgemäß funktioniert, müssen Benutzer die folgenden beiden Elemente manuell erstellen:
- Ein Ordner, der nach dem Namen des Azure DevOps (TFS)-Servers benannt ist (auf dem die benutzerdefinierte ID angewendet werden soll).
- Ein weiterer Ordner, der nach der Azure DevOps-Organisation oder der TFS-Sammlung benannt ist (für die die benutzerdefinierte ID erforderlich ist), unter dem Ordnernamen „Azure DevOps (TFS)“.
Der entsprechende Organisationsordner sollte außerdem die config.xml Datei, die alle Konfigurationen enthält. Die Datei- und Ordnerhierarchie sollte wie unten dargestellt aussehen, wobei das Textmuster und das entsprechende Bild verwendet werden:
Wie in der Abbildung oben dargestellt, ein Beispiel Config.xml Die Datei wird im Benutzerdefinierte ID Ordner.
- Erstellen Sie an diesem Speicherort einen Ordner, der den Namen des Azure DevOps-Servers trägt (auf den die Komponente angewendet werden soll).
- Wechseln Sie in den neu erstellten Ordner und erstellen Sie dort einen weiteren Ordner mit dem Namen der Azure DevOps-Organisation (auf die die Komponente angewendet werden soll).
- Kopieren Sie die xml Datei (wie zuvor beschrieben) in den neu erstellten Ordner, d. h. den Ordner mit dem Namen der Azure DevOps-Organisation.
Diese Datei enthält die Vorlage für die gewünschte Konfiguration.
Konfigurieren der XML-Datei für benutzerdefinierte IDs
- Öffnen Sie die xml Datei im Notepad oder einem beliebigen Texteditor.
- Bestimmen Sie den Wert des IDScope Tag nach Bedarf, zum Beispiel:
– Sammlung -> Zählbereich auf Sammlungsebene anwenden.
– Projekt -> Zählbereich auf Projektebene anwenden.
– Team -> Zählbereich auf Teamebene anwenden. - Das Tag„FieldReferenceName“mit dem Wert„Override“= „Yes“bedeutet, dass das benutzerdefinierte Feld (zwischen den Tags) für die benutzerdefinierte ID berücksichtigt wird. Der Wert„Override“= „No“bedeutet, dass das Standardfeld „MR.CID“ berücksichtigt und für die benutzerdefinierte ID verwendet wird. Das bedeutet, dass Benutzer dieses Feld in ihrer TFS-Vorlage mit demselben Referenznamen, d. h. MR.CID, definieren müssen.
- Das Tag„CollectionUrl“erfordert die URL der TFS-Sammlung, auf die die benutzerdefinierte ID angewendet werden soll. (Hinweis: Bitte stellen Sie sicher, dass die URL nicht mit einem „\“ endet.)
- “Projects DefaultNoOfChar” tag denotes the number of characters to pick up from the project name, if the project name is not defined in the tag<Project Name= “ ”>. By default its value is 5. Update the value if desired.
- Geben Sie den TFS-Projektnamen (z. B. Project Name=“GITNew“) und dessen benutzerdefinierten Namen (z. B. Prefix=“GTN“) an, die als Teil der benutzerdefinierten IDs verwendet werden sollen.
- „Sequenz-ID=“1“Der Wert des Tags „ID“ gibt die Anzahl der verschiedenen benutzerdefinierten ID-Gruppen an, die in der Konfigurationsdatei erstellt wurden, und dient zur Identifizierung und Unterscheidung der IDs. Es handelt sich dabei stets um ein rein numerisches Feld, dessen Werte eindeutig sein müssen. Das Tag „Sequence“ setzt sich aus einer Kombination aus dem WorkItem-Typ, der gewünschten Formatierung des ID-Feldes und dem Startwert des Zählers zusammen.
- Der Wert„WIType“gibt den Typ des Workitems an, auf das die benutzerdefinierte ID angewendet werden soll. Bei Bedarf können für dieselbe Konfiguration auch mehrere Workitems definiert werden, die als Gruppe gelten sollen.
- Das Tag„FieldFormat“dient dazu, die für die benutzerdefinierte ID erforderliche Formatierung festzulegen.
Beispiel: [PN] Req #####[PN] wird als Platzhalter für das oben definierte Präfix des Projektnamens verwendet.
Informationen zum numerischen Format finden Sie unter folgendem Link:
https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings - DasTag „FieldCounter“ ist erforderlich, um die Nummer oder die Reihe festzulegen, bei der der benutzerdefinierte ID-Zähler beginnen soll. Sobald der Zählerwert übernommen wurde (die Konfigurationsdatei wurde angewendet), kann er unter keinen Umständen mehr geändert werden.
- Nachdem Sie die Konfigurationsdatei erfolgreich fertiggestellt haben, speichern und schließen Sie die Datei.
Benutzerdefinierte ID auf vorhandene Arbeitselemente anwenden
- Geben Sie den folgenden Befehl in der Eingabeaufforderung ein: cd :\Program Files\Modern Requirements\MR-Agent\bin
- Sobald Sie sich im Verzeichnis „bin“ befinden, geben Sie den folgenden Befehl ein: MRAgent
Das Optionsmenü wird angezeigt.
- Typ 1 und drücken Sie die Eingabetaste.
- Geben Sie die URL der Azure DevOps-Organisation (oder der TFS-Sammlung) ein.
Wenn keine Fehlermeldung angezeigt wird, wurde die benutzerdefinierte ID erfolgreich auf die vorhandenen Workitems der Sammlung angewendet.
Konfigurieren Sie die Funktion „Dirty Flag“
„Dirty Flag“ ist eine Komponente von MR Services (MR Agent), mit der bestimmte Arbeitselemente als „dirty“ (aufgrund geänderter Anforderungen) markiert werden, damit die zuständigen Beteiligten diese Arbeitselemente einmalig überprüfen können, anstatt mit den veralteten Anforderungen fortzufahren.
Damit die Dirty-Flag ordnungsgemäß funktioniert, müssen Benutzer die folgenden beiden Elemente manuell erstellen:
- Ein Ordner, der nach dem Namen des Azure DevOps (TFS)-Servers benannt ist (auf dem das „Dirty Flag“ angewendet werden soll).
- Ein weiterer Ordner, der nach der Azure DevOps-Organisation oder der TFS-Sammlung (für die das „Dirty“-Flag erforderlich ist) benannt ist, unter dem Ordnernamen „Azure DevOps (TFS)“.
Der entsprechende Sammelordner sollte außerdem die config.xml Datei, die alle Konfigurationen enthält. Die Datei- und Ordnerhierarchie sollte wie unten dargestellt aussehen, wobei das Textmuster und das entsprechende Bild verwendet werden:
Wie in der Abbildung oben dargestellt, ein Beispiel Config.xml Die Datei wird im Foul Ordner.
- Erstellen Sie an diesem Speicherort einen Ordner, der nach dem Namen des Azure DevOps (TFS)-Servers benannt ist (auf dem die Komponente angewendet werden soll).
- Wechseln Sie in den neu erstellten Ordner und erstellen Sie dort erneut einen Ordner mit dem Namen der Azure DevOps-Organisation (oder der TFS-Sammlung), auf die die Komponente angewendet werden soll.
- Kopieren Sie die xml Datei (wie zuvor beschrieben) in den neu erstellten Ordner, d. h. den Ordner mit dem Namen der Azure DevOps-Organisation (oder TFS-Sammlung).
Diese Datei enthält die Vorlage für die gewünschte Konfiguration.
Konfigurieren der XML-Datei für das Dirty-Flag
- Öffnen Sie die xml Datei im Notepad oder einem beliebigen Texteditor.
- Legen Sie den Wert für die Sammlungs-URL mithilfe der URL der Sammlung
Jedes Aktions-Tag hat ein Quelle Teil und ein Ziel Teil. Der „Source“-Teil teilt MR Services (MR Agent) mit, wonach gesucht werden soll, um das „Dirty Flag“ auszulösen; der „Target“-Teil teilt MR Services (MR Agent) mit, welche Art von Arbeitselementen im Falle einer Auslösung als „dirty“ markiert werden.
- Im Abschnitt „Source“ gibt das Tag„WIType“den Typ der Workitems an, für die das Dirty-Flag verwendet wird. Es können mehrere Workitem-Typen angegeben werden, wobei diese durch ein Komma „,“ voneinander getrennt werden.
- Das Tag„FieldReferenceName“gibt an, welche Felder des Workitems (die Liste ist im Tag „WIType“ enthalten) überprüft werden sollen.
- Das „FeldwertDas Tag „“ gibt den genauen Wert des Feldreferenzname das löst das Dirty-Flag aus.
Wenn mehrere Felder markiert sind, wird das Dirty-Flag nur ausgelöst, wenn alle Feldwerte übereinstimmen, d. h. unter Anwendung der UND-Logik.
- Der„WIType“des Zielabschnitts gibt den Typ der Workitems an, die als „dirty“ markiert werden, wenn die Bedingung im Quellabschnitt erfüllt ist.
- Speichern und schließen Sie die Konfigurationsdatei nach erfolgreicher Fertigstellung.
Einrichten der E-Mail-Überwachungsfunktion
Der E-Mail-Monitor ist eine Komponente von MR Services (MR Agent), die dazu dient, aus E-Mails automatisch Arbeitselemente zu erstellen. Zu diesem Zweck wird eine bestimmte E-Mail-Adresse konfiguriert; nach erfolgreichem Abschluss des Konfigurationsprozesses führt jede an diese E-Mail-Adresse gesendete Nachricht zur Erstellung bzw. Aktualisierung von Arbeitselementen. Der Prozess umfasst die folgenden Schritte*:
- Konfigurieren der Konfigurationsdatei für den E-Mail-Monitor (die sich an einem bestimmten Speicherort befindet)
- E-Mail-Einstellungen eingeben und überprüfen
Jeder dieser Schritte wird im Folgenden näher erläutert.
*Bei lokalen Azure DevOps (TFS)-Servern fügt MR Services (MR Agent) den entsprechenden Speicherort automatisch in die Anwendungskonfigurationsdatei (AppSettings.config) ein. Sind jedoch Azure DevOps Services beteiligt, muss der Computer des Benutzers über eine aktive IP-Adresse verfügen, über die Azure DevOps Services auf das System zugreifen bzw. mit ihm kommunizieren können. Diese IP-Adresse sollte in die AppSettings-Konfigurationsdatei eingetragen werden. Die Vorgehensweise hierfür wird in den folgenden Schritten beschrieben:
- Wechseln Sie in den Installationsordner von MR Services (MR Agent) (in der Abbildung hervorgehoben) und öffnen Sie die AppSettings Konfigurationsdatei in einem Texteditor.
Die Anwendungs-URL wird automatisch auf den lokalen Rechner gesetzt.
Ändern Sie den Wert (nur für Azure DevOps Services) in die aktuelle IP-Adresse Ihres Computers einschließlich des entsprechenden Ports.
*Wenden Sie sich an Ihren Netzwerkadministrator, um die aktuelle IP-Adresse und die Port-Informationen zu erhalten.- Speichern und schließen Sie die Konfigurationsdatei.
Zeitkonfigurationen in der Datei „APPSETTING“
Am Ende der AppSettings Konfigurationsdatei stehen den Benutzern drei Zeitkonfigurationen zur Verfügung.
Abonnieren & Terminplan
- Funktioniert für alle Komponenten von MR Services
- Dient zur Überprüfung neuer Projekte/Sammlungen
- Der Standardwert „30“* gibt die Anzahl der Minuten an, nach deren Ablauf MR Services (MR Agent) nach neuen Projekten sucht. Benutzer können diesen Wert (in Minuten) entsprechend ihren Anforderungen anpassen.
*Dieser Wert kann auch über das Admin-Panel konfiguriert werden.
Alles anwenden und planen
- Funktioniert nur für benutzerdefinierte IDs
- Wird verwendet, um neu erstellten Arbeitselementen eine benutzerdefinierte ID zuzuweisen
- Der Standardwert „30“ gibt die Anzahl der Minuten an, nach deren Ablauf MR Services (MR Agent) nach neuen Arbeitselementen sucht und diesen benutzerdefinierte IDs zuweist. Benutzer können diesen Wert (in Minuten) entsprechend ihren Anforderungen konfigurieren.
E-Mail-Check-Zeitplan
- Gilt nur für den E-Mail-Monitor
- Wird verwendet, um zu prüfen, ob eine neue E-Mail eingegangen ist, aus der Arbeitsaufgaben erstellt oder aktualisiert werden könnten
- Der Standardwert „15“ gibt die Anzahl der Minuten an, nach deren Ablauf MR Services (MR Agent) nach E-Mails sucht. Benutzer können diesen Wert (in Minuten) entsprechend ihren Anforderungen anpassen.
Konfiguration des E-Mail-Monitors
Damit der E-Mail-Monitor ordnungsgemäß funktioniert, müssen Benutzer die folgenden Elemente manuell anlegen:
- Ein Ordner, der nach dem Namen des Azure DevOps (TFS)-Servers benannt ist (auf dem der E-Mail-Monitor angewendet werden soll).
Der entsprechende Serverordner sollte außerdem die Datei „config.xml“ enthalten, die alle Konfigurationsdaten enthält. Die Datei- und Ordnerhierarchie sollte wie unten dargestellt aussehen, wobei das Textmuster und das entsprechende Bild verwendet werden:
* Hinweis: Bei den aktuellen Versionen von Email Monitor endet die Hierarchie beim Serverordner, und die Datei wird in diesem Serverordner abgelegt. In zukünftigen Versionen wird die Hierarchie jedoch bis zum Organisationsordner reichen (wie bei anderen Komponenten von MR Services (MR Agent)). Bitte wenden Sie sich an Ihren Administrator oder kontaktieren Sie Modern Requirements, falls diesbezüglich noch Unklarheiten bestehen.
Wie in der Abbildung oben dargestellt, befindet sich eine Beispiel-Datei „Config.xml“ im Ordner „EmailMonitor “.
- Erstellen Sie an diesem Speicherort einen Ordner, der nach dem Namen des Azure DevOps (TFS)-Servers benannt ist (auf dem die Komponente angewendet werden soll).
- Wechseln Sie in den neu erstellten Ordner und kopieren Sie die xml Datei (wie zuvor beschrieben) in diesen Ordner, d. h. den Ordner mit dem Namen des Azure DevOps (TFS)-Servers.
- Diese Datei enthält die Vorlage für die gewünschte Konfiguration.
Konfigurieren der XML-Datei für den E-Mail-Monitor
- Öffnen Sie die xml Datei im Notepad oder einem beliebigen Texteditor.
- Bestimmen Sie den Wert des Server-URL Tag nach Bedarf, zum Beispiel:
- Definieren Sie den Wert für URL der Sammlung (einschließlich der Standardprojekt)
WICHTIG
– Die Werte für beide Server-URL und URL der Sammlung sollte der zuvor beschriebenen Ordnerstruktur entsprechen.
– Achten Sie darauf, dass die URL nicht mit einem Schrägstrich „/“ endet
– Der Benutzer kann in der Konfigurationsdatei mehrere Sammlungs-URLs festlegen. - Geben Sie den Wert für Admin-E-Mail. Diese E-Mail-Adresse dient als Ausweichlösung für den Fall, dass die gewünschte Funktionalität mit der in E-Mail Tag (wird im nächsten Schritt erläutert).
Hinweis: In der Konfigurationsdatei darf nur eine einzige Admin-E-Mail-Adresse angegeben sein.
- „E-MailDas „“-Tag ist das Haupt-Tag in dieser Datei, das festlegt, wohin die E-Mail gesendet wird. Die an diese Adresse gesendeten E-Mails werden verwendet, um die gewünschten Arten von Arbeitselementen zu erstellen. Konfigurieren Sie das E-Mail Tag nach Bedarf
- E-Mail: Geben Sie die Ziel-E-Mail-Adresse an, an die die E-Mail zur Erstellung/Aktualisierung von Arbeitsaufgaben gesendet werden soll. Falls bestimmte Kriterien nicht mit den gewünschten Werten übereinstimmen, wird die Warn-E-Mail an die E-Mail-Adresse des Administrators wie oben definiert.
Hinweis: In der Konfigurationsdatei können mehrere E-Mail-Adressen angegeben werden.
- Arbeitsaufwandsart: Legen Sie den gewünschten Typ des zu erstellenden Workitems fest. Im folgenden Beispiel Kategorie:Referenz bezeichnet den internen Kategorietyp von Arbeitselementen. Mehrere Werte in diesem Tag bedeuten, dass je nach Vorlage des Teamprojekts der entsprechende Typ des Arbeitselements erstellt wird. Wenn das Teamprojekt beispielsweise eine CMMI-Vorlage verwendet, würde die E-Mail ein Arbeitselement vom Typ „Anforderung“ erstellen. Ebenso würde für ein agiles Projekt eine User Story und für ein Scrum-basiertes Projekt ein Projekt-Backlog-Element erstellt werden.
- FieldReference=“System.Title“: Gibt an, wie der Titel des zu erstellenden Arbeitselements lauten soll. Das folgende Beispiel zeigt, dass der Betreff der E-Mail zum Titel des Arbeitselements wird.
- OnCreate= ”true” means that the title would be set from the email’s subject only for new Work Items.
- OnUpdate=”false” bedeutet, dass bei bestehenden Workitems das Feld „Titel“ nicht aktualisiert würde.
- FieldReference = „System.Description“: Geben Sie an, wo die Informationen aus den eingehenden E-Mails gespeichert werden sollen (d. h. in welcher Eigenschaft/welchem Feld des Workitems). Im folgenden Beispiel wird die Beschreibung Feld für diesen Zweck.
- OnCreate= ”true” means that for new Work Items, the content of the email (described next) would be used to populate the Description field of the work item.
- OnUpdate=”false” means that for existing Work Items, the Description field would not be overwritten. Instead the update would go to the comments/history section of the work item.
Der zweite Teil dieses Feldes gibt Aufschluss über den Aufbau des Beschreibungsfeldes. Das Beschreibungsfeld würde sich aus den folgenden Informationen zusammensetzen:
- Sender Name shown inside <> e.g.
- Sender Email also shown inside <> e.g. <alice.ducas@steveandrews.com>
- Der E-Mail-Text wurde in einer neuen Zeile eingefügt
- Das Finale FieldReference = „System.History“ wird für Diskussions-E-Mails verwendet, die nach der Erstellung eines Arbeitselements eingehen. Anstatt die Beschreibung Feld werden die nachfolgenden E-Mail-Informationen im Kommentare Feld (intern bezeichnet als Geschichte). Die Zusammensetzung der Geschichte Das Feld entspricht mehr oder weniger dem Stand vom Beschreibung das oben beschriebene Feld. Es wird empfohlen, die ursprünglichen Einstellungen für dieses Tag beizubehalten.
- Nachdem Sie die Konfigurationsdatei erfolgreich fertiggestellt haben, speichern und schließen Sie die Datei.
- E-Mail: Geben Sie die Ziel-E-Mail-Adresse an, an die die E-Mail zur Erstellung/Aktualisierung von Arbeitsaufgaben gesendet werden soll. Falls bestimmte Kriterien nicht mit den gewünschten Werten übereinstimmen, wird die Warn-E-Mail an die E-Mail-Adresse des Administrators wie oben definiert.
Einrichten des E-Mail-Monitors
Email Monitor lässt sich durch Konfigurieren der entsprechenden Einstellungen im Admin-Panel einrichten. Diese Einstellungen sind über die Registerkarte „Dienste“ zugänglich.
Der Bereich „Dienste“ im Admin-Panel verfügt derzeit über zwei Registerkarten: Einstellungen & E-Mail-Überwachung
Die Registerkarte „Einstellungen“ befasst sich mit 1) der Benutzerauthentifizierung/Organisationsregistrierung und 2) der Suche nach neuen Projekten.
„Email Monitor“ deckt alle zuvor im Abschnitt zur Befehlszeile behandelten E-Mail-bezogenen Optionen ab.
Optionen für den E-Mail-Monitor konfigurieren
- Über die Registerkarte „E-Mail-Monitor“ im Abschnitt „Dienste“ können die E-Mail-Einstellungen konfiguriert werden.
- Die Optionen können durch Klicken auf die Registerkarte „E-Mail-Monitor“ aufgerufen werden, wie in der folgenden Abbildung gezeigt.
- Wenn der Benutzer seine Organisation noch nicht registriert hat (indem er die erforderlichen Angaben auf der Unterregisterkarte „Einstellungen“ macht), wird er beim Klicken auf die Unterregisterkarte „E-Mail-Monitor“ zur Unterregisterkarte „Einstellungen“ zurückgeleitet, sofern die erforderlichen Informationen nicht eingegeben wurden.
- Die Einstellungen des E-Mail-Monitors sind in Abschnitte unterteilt, wobei jeder Abschnitt zur Konfiguration einer bestimmten Einstellung dient.
- Alle erforderlichen Einstellungen werden einmalig vorgenommen. Benutzer können nicht bestimmte Einstellungen vornehmen und andere offen lassen.
- Im ersten Abschnitt werden das Standardprojekt und die E-Mail-Adresse des Administrators konfiguriert.
- Im zweiten Abschnitt wird die E-Mail-Adresse konfiguriert, die für die E-Mail-Überwachung verwendet werden soll.
Wenn Sie auf E-Mail-Adresse registrieren würde ein Popup-Fenster öffnen, in dem die Netzwerkeinstellungen für die E-Mail (z. B. SSL, POP3, IMAP usw.) konfiguriert werden können.
- Der dritte Abschnitt dient zur Konfiguration der Einstellungen, mit denen der Inhalt von Workitems aus den an die registrierte E-Mail-Adresse gesendeten E-Mails extrahiert wird.
Wenn Sie nach der Konfiguration aller Einstellungen auf die Schaltfläche „Änderungen speichern“ klicken, wird der E-Mail-Monitor bereitgestellt.
Verwandte Artikel
Support kontaktieren
Support kontaktieren
Das Admin-Panel von Modern Requirements4DevOps
In diesem Artikel erklären wir, wie Sie über das Modern Requirements4DevOps-Admin-Panel bestimmte Funktionen in den einzelnen MR4DevOps-Modulen aktivieren und deaktivieren können.
WeiterlesenUmsetzung moderner Anforderungen für DevOps
In diesem Artikel beschreiben wir die einfachen Schritte, die Teams ausführen müssen, um Modern Requirements4DevOps sowohl in unserer Embedded- als auch in unserer Standalone-Version zu aktivieren.
Weiterlesen
