In diesem Blog stellen wir Ihnen einige der wichtigsten Neuerungen bei einigen unserer Module sowie einige Verbesserungen der Tools in Modern Requirements vor, damit Sie besser damit arbeiten können.
Weiterlesen
In diesem Beitrag zeigen wir Ihnen, wie einige Unternehmen alle Herausforderungen der Produktentwicklung mit einer einzigen, einfachen Lösung für das Anforderungsmanagement bewältigen: Modern Requirements4DevOps.
Weiterlesen
Als Administrator können Sie durch das Anwenden von Administratoreinstellungen steuern, wie Benutzer auf ihre Modern Requirements4DevOps-Projekte zugreifen und mit ihnen interagieren.
Weiterlesen
Als Administrator können Sie durch das Anwenden von Administratoreinstellungen steuern, wie Benutzer auf ihre Modern Requirements4DevOps-Projekte zugreifen und mit ihnen interagieren.
Weiterlesen
Als Administrator können Sie durch das Anwenden von Administratoreinstellungen steuern, wie Benutzer auf ihre Modern Requirements4DevOps-Projekte zugreifen und mit ihnen interagieren.
Weiterlesen
Die Funktion „E-Mail-Monitor“ ermöglicht es Ihnen, Workitems in Ihrem Azure DevOps-Projekt über ein Medium zu erstellen, das nicht nativ in Azure DevOps integriert ist. Das heißt, Sie können über E-Mail mit Ihrem Projekt kommunizieren. Teams sehen sich häufig mit Situationen konfrontiert, in denen sie per E-Mail über Anforderungen, Änderungsanfragen oder Fehler kommunizieren, die erfasst werden sollten, und oft gelingt es ihnen, mithilfe von E-Mails eine endgültige Anforderung zu formulieren, die in ihr Projekt aufgenommen werden sollte.
Mit der E-Mail-Monitor-Funktion kann Ihr Team diese externe Kommunikation nun direkt in ein Arbeitselement umwandeln.
Anwendungsbeispiele und Informationen zur Konfiguration von Email Monitor finden Sie im Video.
Sie gelangen zur Konfigurationsseite von „Email Monitor“, indem Sie zu „Collection/Admin-Einstellungen“ – „Modern Requirement4DevOps Extension“ – „Dienste“ – „Email Monitor“ navigieren .
Wenn Sie die Funktion „E-Mail-Monitor“ im Erweiterungsfenster von „Modern Requirements4DevOps“ aktivieren, können Sie eine Monitor-E-Mail-Adresse angeben, die alle an diese Adresse gesendeten Arbeitselemente abfängt und erstellt. Da das System versucht, jede an die Monitor-E-Mail-Adresse gesendete E-Mail zu erfassen, empfiehlt es sich, diese Adresse ausschließlich für den E-Mail-Monitor zu verwenden.
Sie müssen außerdem eine Administrator-E-Mail-Adresse angeben, für den Fall, dass das System die E-Mails nicht erkennen kann; in diesem Fall wird eine Benachrichtigungs-E-Mail an die Administrator-E-Mail-Adresse gesendet.
Sie können festlegen, welche WorkItem-Typen Sie in Ihrem Projekt aus diesen erfassten E-Mails erstellen möchten.
Die Betreffzeilen der an die Monitor-E-Mail-Adresse gesendeten E-Mails werden stets den Betreffzeilen der zu erstellenden Arbeitselemente zugeordnet.
Mit „Teamprojekt (Standard)“ können Sie ein Standardprojekt auswählen, dem Sie die Arbeitselemente hinzufügen möchten.
Mit den Funktionen „Add-on erstellen“ und „Add-on aktualisieren“ können Sie festlegen, wann die Anforderung zum Projekt hinzugefügt werden soll.
Für das Feld „Beschreibung“:
Wenn das Kontrollkästchen „Bei Erstellung hinzufügen“ aktiviert ist, bedeutet dies, dass das System anhand der ursprünglichen E-Mail ein neues Workitem erstellt und der E-Mail-Text als Beschreibung des erstellten Workitems übernommen wird.
Wenn das Kontrollkästchen „Bei Aktualisierung hinzufügen“ aktiviert ist, bedeutet dies, dass die bestehende Beschreibung des erstellten Workitems durch zukünftige Antworten zu diesem Workitem überschrieben wird.
Für den Bereich Geschichte：
Wenn das Kontrollkästchen „Bei Erstellung hinzufügen“ aktiviert ist, wird der Text der ursprünglichen E-Mail dem Abschnitt „Diskussion“ des erstellten Arbeitselements zugeordnet.
Wenn das Kontrollkästchen „Bei Aktualisierung hinzufügen“ aktiviert ist, werden alle hin- und hergehenden Antworten zu demselben Workitem dem Abschnitt „Diskussion“ hinzugefügt.
Über „Absendername“, „Absender-E-Mail“ und „E-Mail-Text“ können Sie festlegen, welche Inhalte Sie in die zugehörige Beschreibung oder den Diskussionsbereich einfügen möchten.
Der häufigste Anwendungsfall für die E-Mail-Monitor-Funktion ist folgender:
Ich leite eine große Organisation und möchte, dass alle Mitglieder meiner Organisation alle Fehler, die sie in meiner Software finden, in mein Azure DevOps-Projekt eintragen.
Sobald Email Monitor vollständig mit bugs@myorganization.com konfiguriert ist, können alle betroffenen Beteiligten einfach eine E-Mail an bugs@myorganization.com senden, und ich kann festlegen, dass in meinem Projekt ein Bug-Workitem angelegt werden soll.
Gleichzeitig wird die E-Mail, die zur Erstellung des Fehlers geführt hat, auch an die zuständigen Personen des Projekts gesendet. Die zuständigen Mitglieder können nun per E-Mail an der Diskussion zu diesem Arbeitselement teilnehmen, und die gesamte E-Mail-Kommunikation wird den Diskussionseigenschaften dieses Arbeitselements in Ihrem Projekt hinzugefügt.
Dank dieser einzigartigen Funktion können andere Personen zum Erfolg Ihres Projekts beitragen, ohne vollständigen Zugriff auf Ihr Azure DevOps-Projekt zu benötigen. Externe Personen können nun an der Diskussion zu einem Workitem teilnehmen, ohne dass Sie ihnen Zugriff auf Ihr Projekt gewähren müssen.
Hinzufügen von Arbeitselementen zu anderen Projekten als dem Standardprojekt
Wenn der Absender im E-Mail-Text keinen bestimmten Projektnamen angibt, wird die zugeordnete E-Mail dem Standardprojekt hinzugefügt. Wenn Absender die Anforderung einem anderen Projekt innerhalb derselben Sammlung hinzufügen möchten, müssen sie [ProjectName=GCD] in den E-Mail-Text einfügen (GCD ist ein Beispiel für einen Projektnamen).
Mehrere Arbeitsaufgabentypen
Wir wissen, dass die Projektbeteiligten möglicherweise mehr als einen Work-Item-Typ über den E-Mail-Monitor hinzufügen möchten. Auch das ist möglich! Sie können einfach mehrere Work-Item-Typen auswählen . Ich wähle beispielsweise zusätzlich zu „Bug“ auch „User Story“ aus. Wenn Ihr Team E-Mails an die Monitor-E-Mail-Adresse sendet, kann es im E-Mail-Text [WIT=bug] oder [WIT=user story] verwenden, um anzugeben, welchem Work-Item-Typ die erstellte Anforderung zugeordnet werden soll. Ohne Angabe des Work-Item-Typs im E-Mail-Text versucht das System, die E-Mail dem Work-Item-Typ zuzuordnen, der in die Work-Item-Kategorie fällt, die Sie im Abschnitt „WI-Kategorie“ ausgewählt haben.
Zusätzliche Inhalte zu einem bestehenden Arbeitselement hinzufügen
Nachdem die ursprüngliche E-Mail vom System erfasst wurde, können standardmäßig alle nachfolgenden Antworten als Diskussionen zum selben Work Item hinzugefügt werden. Darüber hinaus können Absender [wiid=1997] (1997 ist eine Beispiel-Work-Item-ID) in den E-Mail-Text einfügen, um neue Inhalte zu dem betreffenden bestehenden Work Item hinzuzufügen.
Natürlich können Sie je nach Bedarf mehrere dieser Sonderbefehle in einer E-Mail verwenden.
Mit dieser Funktion können Sie Workitems überwachen, die bestimmte Voraussetzungen erfüllen. Wenn sich diese Workitems ändern, markiert die Überwachungsfunktion alle damit verknüpften Workitems als verdächtig.
Die User Story 1 wurde soeben in den Status „Abgeschlossen“ versetzt. Kann der „Suspect Link“ so konfiguriert werden, dass er eine Warnmeldung auslöst, wenn Änderungen an User Stories im Status „Abgeschlossen“ vorgenommen werden (z. B. eine Änderung an einem Feld wie „Beschreibung“)?
Das bedeutet, dass, wenn das Feld „Beschreibung“ von User Story 1 in Zukunft geändert wird, alle damit verknüpften Anforderungen mit einem „Dirty Flag“ markiert werden.
Auf diese Weise kann Ihr Team leicht erkennen, ob sich eine Anforderung, die bestimmte (von Ihnen festgelegte) Kriterien erfüllt, geändert hat. Sobald dies festgestellt wird, werden die direkt verknüpften, konfigurierten Arbeitselemente mit dem Status „Dirty/Suspect“ gekennzeichnet.
Um bei unserem Beispiel zu bleiben: Wenn sich das Feld „Beschreibung“ in User Story 1 ändern würde, könnten wir alle direkt verknüpften Testfälle mit einem „Dirty Flag“ versehen, die möglicherweise angepasst werden müssen, um die neuen Kriterienänderungen zu testen.
Die „Dirty Flags“, die für diese Testfälle gesetzt werden, würden die Form eines Work-Item-Tags annehmen.
Tags werden im Standard-Workitem-Editor von Azure DevOps angezeigt. Sie können außerdem die Spaltenoptionen im Modul „Workitems und Backlogs“ anpassen, um eine Gruppe von Workitems anzuzeigen, von denen einige möglicherweise mit dem „Dirty Flag“ markiert sind.
Wenn bei Arbeitselementen das „Dirty Flag“-Tag gesetzt wird, enthält dieses Tag sowohl die ID des geänderten Arbeitselements als auch dessen Revisionsnummer, sodass Ihr Team leicht erkennen kann, welche Anforderung geändert wurde und die „Dirty Flag“- bzw. „Suspect Link“-Funktion ausgelöst hat.
„Dirty Flag“-Markierungen können manuell entfernt werden, sobald die zuständigen Beteiligten die Auswirkungen geprüft und die erforderlichen Aktualisierungen vorgenommen haben. Wir empfehlen, einen weiteren Kommentar hinzuzufügen, in dem erläutert wird, dass die „Dirty Flag“-Markierung nun entfernt wurde, da die erforderlichen Aktualisierungen vorgenommen wurden oder keine Aktualisierungen erforderlich sind.
Weitere Informationen sowie eine Anleitung zur Konfiguration von „Dirty Flag/Suspect Link“ finden Sie im Video.
Modern Requirements4DevOps bietet die Möglichkeit, Work Items mit benutzerdefinierten IDs zu versehen. Diese Funktion soll Work Item-Felder lesbarer und besser erkennbar machen. Beispiel: „PX-REQ-00001” für das erste Requirements Work Item in Projekt X.
Unsere Funktion „Benutzerdefinierte ID“ bietet dieselben Vorteile sowie zusätzliche Vorteile durch die Verwendung der benutzerdefinierten ID im Modul „Abfragen“.
Benutzerdefinierte IDs können als benutzerdefinierte Eigenschaft eingerichtet werden, die für jedes Ihrer Arbeitselemente vorhanden ist. Die benutzerdefinierten IDs sollen die Arbeitselement-ID nicht ersetzen, sondern ergänzen.
Die Eigenschaft „Benutzerdefinierte ID“ bietet eine einfache Methode, um mehrere erforderliche Informationen zu einem bestimmten Workitem in einem einzigen Feld zu identifizieren. Sie erweist sich auch als äußerst nützliches Werkzeug zur Identifizierung einer Anforderungsquelle in projektübergreifenden Abfragen.
Indem Sie die Informationen in einem Feld zusammenfassen, machen Sie ein Work Item für weniger involvierte Benutzer zugänglicher. Die Funktion „Benutzerdefinierte ID” entspricht den folgenden Richtlinien:
Work Items können je nach Art des Work Items einen eindeutigen Code zugewiesen bekommen. Beispielsweise könnte der Code für einen Requirement Work Item-Typ REQ lauten, der Code für einen User Story Work Item-Typ US und der Code für einen Bug Work Item-Typ BG.
Sie können die Startnummer festlegen, von der aus Ihre Workitem-Typen fortlaufend nummeriert werden. Sie können beispielsweise festlegen, dass die benutzerdefinierte ID-Nummerierung für User Stories bei 1 oder 10000 beginnen soll und dass die benutzerdefinierte ID jeder User Story fortlaufend erhöht wird.
Sie können auch ein optionales Projektpräfix für jede benutzerdefinierte ID hinzufügen. Beispielsweise könnte einem Projektnamen wie „Projekt X“ das Präfix PX zugewiesen werden.
Schließlich können Sie den Umfang eines Arbeitselements hinzufügen. Die ID-Nummer wird im Umfang nicht wiederholt; der Umfang kann „Team“, „Projekt“ oder „Sammlung“ sein. Der Umfang garantiert, dass die benutzerdefinierte ID innerhalb des Umfangs eindeutig ist.
Anhand des in der obigen Richtlinie behandelten Beispiels wäre eine benutzerdefinierte ID für das erste (00001) Anforderungs-Workitem in Projekt X „PX-REQ-00001“ – eine Verkettung aus Projektpräfix + Workitem-Typcode + Nummer.
Weitere Informationen und den Konfigurationsprozess für die benutzerdefinierte ID finden Sie im Video.
Schnellere Compliance, kürzere Entwicklungszyklen und schnellere Wertschöpfung erzielen
Weiterlesen
Was ist Modern Requirements4DevOps? Lesen Sie weiter und erfahren Sie, wie Modern Requirements4DevOps funktioniert – welche Probleme es lösen kann und wer es nutzt –, sowie einen Überblick über die Funktionen, Preise und Integrationsmöglichkeiten.
Außerdem werde ich erläutern, wie sich Modern Requirements4DevOps von ähnlichen Tools unterscheidet.
Lesen Sie den vollständigen Artikel auf Digital Project Manager.
End-to-end requirements management in Azure DevOps.
AI-powered assistance for DevOps workflows.
Autonomous AI agents for DevOps execution.
Real-time data sync across tools and systems.
Designed to work natively within Azure DevOps, Modern Requirements extends the platform with powerful capabilities that help teams capture, manage, and validate requirements more effectively.
