Einsatz von MatCal für mathematische und logische Berechnungen im modernen Anforderungsmanagement

Einsatz von MatCal für mathematische und logische Berechnungen im modernen Anforderungsmanagement

Was ist MatCal?

MatCal ist eine Funktion in Modern Requirement4DevOps, mit der mathematische und logische Ausdrücke auf Arbeitselemente angewendet werden können.

Warum wir MatCal im Anforderungsmanagement brauchen

Um die Beziehungen zwischen den Eigenschaften von Arbeitselementen intelligenter zu verwalten! Dadurch entfällt der manuelle Aufwand für Berechnungen außerhalb der Projektumgebung, und es wird das Risiko vermieden, dass fehlerhafte Berechnungsergebnisse in Ihre Projekte gelangen.

Betrachten wir hier ein einfaches Beispiel, um die Beziehung zwischen den Eigenschaften von Arbeitselementen zu veranschaulichen.

„Geschäftlicher Nutzen “ und „Priorität“ sind Eigenschaften des Workitem-Merkmals. Normalerweise führt ein hoher geschäftlicher Nutzen zu einer hohen Priorität.

Bei richtiger Konfiguration kann MatCal Sie bei der Verwaltung der Beziehung unterstützen, indem es automatisch einen Prioritätswert auf der Grundlage der eingegebenen Geschäftswerte zuweist.

Anwendungsszenarien in der Industrie

Szenario 1: Automotive Safety Integrity Level (ASIL) gemäß ISO 26262

Szenario 2: Die Risikoeinstufung wird automatisch anhand des Schweregrads und der Häufigkeit ermittelt

Szenario 3: Die Prioritätsbewertung wird automatisch anhand des Schweregrads und der Wahrscheinlichkeit zugewiesen

Schau dir das Video an, um weitere Anwendungsbeispiele und Anleitungen zu MatCal zu erhalten!

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:

  1. Anforderungen aus Microsoft Excel importieren
  2. Anforderungen für den Import aus Microsoft Word
  3. 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:

  1. Excel öffnen
  2. Leeres Blatt erstellen 
  3. Klicken Sie auf „Datei“
  4. Auf „Optionen“ klicken
  5. Klicken Sie auf „Add-Ins“
  6. Wählen Sie „COM-Add-Ins“ aus dem Dropdown-Menü am unteren Rand des Fensters
  7. 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!

Probier es doch mal aus!

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!

Moderne Anforderungen 2019: Update 2

Versionshinweise

Modern Requirements4DevOps 2019 – Update 2

Willkommen bei Modern Requirements4DevOps 2019 Update 2! Diese Version enthält zahlreiche Verbesserungen und Erweiterungen. Im Folgenden finden Sie eine kommentierte Version der Versionshinweise, die Ihnen als Leitfaden für das Update auf Modern Requirements4DevOps dienen soll. 

Allgemein

Modern Requirements wurde um ein völlig neues Tool erweitert, das Sie bei der Rückverfolgbarkeit und Verwaltung Ihrer Projekte unterstützt: das MR Artifact Tool!

Das MR-Artefakt-Tool ist über das Kontextmenü jedes Arbeitselements aufrufbar. Dieses Tool listet alle Modern-Requirements-Artefakte auf, mit denen das Arbeitselement verknüpft ist! So können Benutzer nun schnell erkennen, welche Modern-Requirements-Artefakte das ausgewählte Arbeitselement nutzen.  

Dieses Tool kann derzeit Arbeitselemente nachverfolgen, die in Smart Docs, Reviews und Baselines enthalten sind.

Das Vergleichstool, das für direkte Vergleiche zwischen verschiedenen Versionen von Arbeitselementen dient, wurde – mangels eines passenderen Begriffs – überarbeitet!

Revisions-IDs werden nun durch neue Eigenschaften weiter abgegrenzt. Die neuen Eigenschaften lauten „Zuletzt genehmigt “ und „Zuletzt geprüft“. Diese Eigenschaften gelten für Revisionen von Arbeitselementen, die im Laufe ihres Lebenszyklus einer Prüfung unterzogen wurden.

Diese Eigenschaften werden neben der Revisions-ID im Dropdown-Menü des Vergleichstools angezeigt.

Bei Verwendung des Vergleichstools wird im Dropdown-Menü automatisch eine Standardrevision angezeigt. Beim Öffnen des Dropdown-Menüs werden die Arbeitselemente „Zuletzt genehmigt“ und „Zuletzt geprüft“ jeweils ganz oben in der Liste angezeigt. Darauf folgen die übrigen Revisionen in absteigender Reihenfolge (von der neuesten zur ältesten). 

Wenn das Vergleichstool aufgerufen wird, wird im linken Dropdown-Menü stets die aktuelle Revision des Workitems angezeigt. Wird das Tool über das Backlog geöffnet, wird in diesem Feld die neueste Revision angezeigt. Wird es über eine Überprüfung aufgerufen, wird in diesem Feld standardmäßig die Revision des Workitems angezeigt, die in der Überprüfung enthalten war. Wird es über eine Baseline aufgerufen, wird in diesem Feld die Revision des Workitems angezeigt, wie sie zum Zeitpunkt der Erstellung der Baseline vorlag.

Das rechte Dropdown-Menü ist das Feld zum Vergleichen von Revisionen. Wenn das Workitem einer Überprüfung unterzogen wurde, wird in diesem Feld standardmäßig die zuletzt genehmigte Revision angezeigt.

Falls keine genehmigte Version vorliegt, wird in diesem Feld standardmäßig die zuletzt geprüfte Version angezeigt.

Wenn das linke Dropdown-Menü standardmäßig die zuletzt genehmigte Version eines Arbeitselements anzeigt, bleibt das rechte Dropdown-Menü leer.

Das Vergleichstool kann über ein neu erstelltes Arbeitselement aufgerufen werden. Solange jedoch keine Revisionen vorliegen, bleibt das rechte Dropdown-Menü leer.

Wenn das Vergleichstool über die Registerkarte „Baseline vergleichen“ aufgerufen wird, funktioniert es anders. Der Vergleich erfolgt nicht mehr automatisch, da der Benutzer das Arbeitselement zwischen zwei Baselines manuell vergleicht. Die Dropdown-Menüs im Tool zeigen stattdessen standardmäßig die Revision des Arbeitselements an, die in der jeweiligen verglichenen Baseline enthalten ist.

Bei der Verwendung des Vergleichstools kann der Benutzer mit beiden Dropdown-Menüs interagieren und beliebige Vergleiche zwischen den Versionen anstellen.

Intelligente Dokumente

Smart Docs wurde um drei neue Funktionen erweitert…

In Smart Docs erstellte untergeordnete Elemente können nun automatisch die Eigenschaften ihres übergeordneten Elements übernehmen!

Mit dem Meta Template Designer von Smart Docs können Benutzer nun Arbeitselemente mit vererbbaren Feldern konfigurieren. Wenn ein untergeordnetes Arbeitselement spontan aus einem übergeordneten Knoten erstellt wird, können Werte aus konfigurierten Feldern vom übergeordneten Element übernommen werden. Diese Regel gilt nicht beim Einfügen bestehender Arbeitselemente.  

Der Smart Editor hat außerdem eine neue Funktion mit schreibgeschützten Feldern eingeführt.

Einzelne Felder können in der Prozessvorlage als schreibgeschützt definiert werden. Der Smart Editor behandelt diese Felder ebenfalls als schreibgeschützt.

Aktuelle Anforderungen: Die Interaktion der Beteiligten mit Smart Docs wurde durch die Einführung der Option zum Öffnen von Arbeitselementen weiter verbessert. Bisher konnten die Beteiligten keine Arbeitselemente öffnen – jetzt ist dies möglich!

Wenn diese Option aktiviert ist, können zum Projekt eingeladene Stakeholder Elemente im Standard-Editor von Azure DevOps öffnen.

Die Beteiligten können diese Funktion sowohl über die Registerkarte „Dokument“ als auch über die Registerkarte „Vergleichen“ in Smart Docs aufrufen.

Die bestehenden Funktionen des Smart-Docs-Moduls wurden weiter verbessert.

Mit dem Meta-Vorlagendesigner können Benutzer nun gespeicherte Dokumentvorlagen aktualisieren. Bisher galt diese Funktion nur für Meta-Vorlagen; nun können auch Dokumentvorlagen aktualisiert werden!

Dadurch haben Benutzer die Möglichkeit, ihre Dokumentvorlagen jederzeit spontan anzupassen.

Zu den Funktionen gehören:

  • Arbeitselementhierarchie ändern
  • Vorlagen umbenennen
  • Vorlagen löschen
  • Vorlagen klonen; eine eigene Version der Vorlage erstellen, um sie zu bearbeiten

Änderungen an Dokumentvorlagen können auf alle Smart Docs angewendet werden, die diese Vorlage verwenden. Nach der Durchführung der Änderungen muss der Benutzer lediglich die Funktion „Alle Vorlagen aktualisieren“ in der Smart Docs-Symbolleiste nutzen.

Es wurde eine wesentliche Änderung an der optischen Gestaltung von Smart Docs vorgenommen.

Sowohl der Text- als auch der Bildumbruch wurden in Smart Docs verbessert, da alle enthaltenen Daten nun korrekt in die nächste Zeile umgebrochen werden.

Dies ist eine rein ästhetische Änderung. Diese Änderung dürfte jedoch die Lesbarkeit erheblich verbessern und dazu beitragen, dass das Ergebnisdokument für den Betrachter optisch ansprechender wirkt.

Von dieser Verbesserung profitieren die Titel, HTML-Felder, großen Bilder und Tabellen in Smart Docs.  

Bewertungsmanagement

Auch das Modul „Bewertungsmanagement“ wurde um einige sehr nützliche Funktionen erweitert.

Als Initiator einer Überprüfung können Sie nun Kommentare abgeben, ohne als Prüfer registriert sein zu müssen – ein Initiator einer Überprüfung gilt standardmäßig als Prüfer.

Dem Modul „Prüfungsmanagement“ wurden zwei neue Arten von Prüfungsberichten hinzugefügt.

Prüfbericht zur Genehmigung:

Der Bericht enthält alle Einzelheiten zu den Genehmigungsmaßnahmen, die auf die Arbeitselemente in der Überprüfung angewendet wurden

  • Zu den Details gehören Angaben dazu, ob ein Arbeitselement genehmigt oder abgelehnt wurde und durch welches Benutzerprofil, sowie Antwortkommentare, Überprüfungsmaßnahmen, zusätzliche Kommentare und hinzugefügte verknüpfte Arbeitselemente.

Bericht über die Prüfungsergebnisse:

Der Bericht enthält alle Einzelheiten zu den Prüfungsmaßnahmen, die auf die Arbeitselemente in der Prüfung angewendet wurden

  • Zu den Details gehören Angaben dazu, ob ein Arbeitselement geprüft wurde und durch welches Benutzerprofil, sowie Antwortkommentare, Prüfungsmaßnahmen, zusätzliche Kommentare und hinzugefügte verknüpfte Arbeitselemente.

Es sei darauf hingewiesen, dass der bestehende Prüfungsbericht künftig als „Legacy-Prüfungsbericht“ bezeichnet wird.

 Benutzer haben weiterhin Zugriff auf die Option „Legacy-Auditbericht“.

Das Modul „Review Management“ wurde in seinen Kernfunktionen um mehrere Verbesserungen erweitert.

Die Art und Weise, wie Modern Requirements mit Metadaten zu Reviews umgeht, wurde komplett überarbeitet. Wenn Sie einen Review erstellen, werden die entsprechenden Metadaten nun in Ihrem Repo (Versionskontrolle) gespeichert.

Die Metadaten der Bewertung wurden zuvor im HTML-Feld eines Arbeitselements vom Typ „Feedback-Anfrage“ gespeichert.

Update 2 hat auch Änderungen am Arbeitsablauf des Review-Managements mit sich gebracht.

Der bisherige Prozess zur Erstellung von Überprüfungen war langsam und mit vielen Links verbunden; für jedes in einer Überprüfung enthaltene Arbeitselement wurden drei Links erstellt.

In Update 2 werden beim Erstellen einer Überprüfung keine Links mehr zwischen den Feedback-Anfragen und den in der Überprüfung enthaltenen Arbeitselementen erstellt.  

Zudem wird vom System kein Arbeitselement für die Rückmeldung mehr erstellt, wenn ein Benutzer eine Rückmeldung abgibt (Genehmigung/Einreichen der Rückmeldung).

Der neue Prozess ist effizienter und kommt ohne Links aus, um die Beschränkung von Azure DevOps auf maximal 1000 Links pro Arbeitselement zu umgehen.  

Zudem wurde die Automatisierung bei der Ausführung gängiger Aktionen im Rahmen von Überprüfungen verbessert.

Wenn Sie die Funktion „Workitem verknüpfen“ verwenden, um ein Workitem mit einer Genehmigung oder Ablehnung zu verknüpfen, wird die Verknüpfung direkt zu dem Workitem hergestellt, das der Benutzer gerade prüft.

Kommentare, die auf der Registerkarte „Details“ abgegeben werden, werden automatisch zusammen mit den Profilinformationen des Verfassers zum Arbeitselement „Feedback-Anfrage“ hinzugefügt.

Nach Abschluss einer Überprüfung wird dem Arbeitselement „Feedback-Anfrage“ ein Kommentar sowie die Profilinformationen des Teilnehmers hinzugefügt.

Sobald Reviews geschlossen wurden, sind keine weiteren Aktionen zur Genehmigung oder Kommentierung mehr möglich. Dadurch wird verhindert, dass die an dem Review beteiligten Personen weitere Kommentare hinzufügen oder Arbeitselemente mit dem geschlossenen Review verknüpfen können.

Es wurden außerdem Änderungen vorgenommen, um die Benutzeroberfläche des Popup-Formulars für Überprüfungsanfragen zu aktualisieren.

  • Wenn Sie eine Überprüfung über Smart Docs starten, wird der Abschnitt „Arbeitsaufgaben“ nicht mehr angezeigt
  • Bei der Vorschau einer Überprüfung wird die Liste der ausgewählten Arbeitselemente nicht mehr angezeigt
  • Der Textkörper einer E-Mail, die während einer Überprüfung erstellt wird, enthält nicht mehr die Liste der ausgewählten Arbeitselemente

Ausgangsbasis

Das Baseline-Modul wurde um neue Funktionen erweitert, mit denen Sie Ihre Arbeitselemente besser nachverfolgen und verwalten können.

Beim Vergleich von Baselines können Benutzer nun festlegen, bei welchen einzelnen Link-Typen ein Änderungsindikator ausgelöst wird. Bisher hatten Benutzer nur die Möglichkeit, den Auslöser zu deaktivieren oder ihn auf alle Link-Typen anzuwenden. Diese Einstellung ist im Admin-Panel zu finden.

Die Differenzberichte wurden dahingehend verbessert, dass nun nur noch Felder angezeigt werden, die als Auslöser für Änderungskennzeichen konfiguriert wurden. Zuvor waren die Benutzeroberfläche des Vergleichstools und die Differenzberichte nicht synchronisiert.

Durch die Einbeziehung von Änderungen des Verknüpfungstyps zwischen Baselines werden Differenzberichte künftig die Möglichkeit bieten, über Änderungen des Verknüpfungstyps zu berichten. 

Auch das Tool „Copy/Reuse Baseline“ wurde funktional erweitert.

Das System kopiert automatisch den Bereichs-/Iterationspfad des Quellprojekts und weist ihn den kopierten Arbeitselementen zu, sofern im Zielprojekt identische Werte vorhanden sind.

Wie in diesem Beispiel zu sehen ist, wird beim Kopieren des Workitems dessen Iterationspfad aus dem Quellprojekt kopiert und im Zielprojekt festgelegt.

Intelligenter Bericht

Wie bereits bei früheren Versionen des Smart Report Tools können Benutzer Word-Vorlagen hochladen und auf ihre Berichte anwenden. Mit Update 2 wurde die Möglichkeit eingeführt, Word-Formatierungen zu übernehmen, wenn Smart Reports nach Microsoft Word exportiert und eine Word-Vorlage angewendet wird.

Smart Reports übernimmt aus der Vorlage die Formatierung für Überschriften, Schriftgröße, unterstrichenen oder fettgedruckten Text, Schriftfarbe, Einrückung und Ausrichtung.

Diese Option finden Sie im Dropdown-Menü „Stylesheet“.

Admin-Panel

Auch bei der Verarbeitung der Daten zu den aktuellen Anforderungen wurden Verbesserungen vorgenommen.

Die Daten zu den aktuellen Anforderungen werden nun automatisch mit der Quellcodeverwaltung von Azure DevOps Server (TFS) synchronisiert, um Build-Bereitstellungen mit Single-Sign-On zu ermöglichen.

Um diese Funktion zu nutzen, fügen Sie die Anmeldedaten eines Benutzers auf Sammlungsebene auf der Registerkarte „Allgemein“ des Modern Requirement4DevOps-Admin-Panels hinzu.

Wenn keine Anmeldedaten angegeben wurden, wird der Benutzer durch eine Benachrichtigung darauf hingewiesen.

Die Daten zu den aktuellen Anforderungen werden sowohl mit GIT als auch mit der Versionskontrolle von Team Foundation synchronisiert.

Skalierbarkeit

Modern Requirements ist sich bewusst, dass die Projekte unserer Kunden wachsen werden und dass ihre Anforderungsmanagement-Software mitwachsen muss.

Die Durchsatzleistung von Modern Requirements4DevOps wurde erheblich optimiert. Mit Update 2 wurde die Unterstützung großer Datenmengen in Modulen mit hohem Workitem-Aufkommen eingeführt. Die Unterstützung großer Datenmengen wurde in den Bereichen Review-Management, Baseline und Smart Report hinzugefügt.

Berichte und Smart Reports können nun mit maximal 10.000 Arbeitselementen erstellt werden.

Benutzer können nun Baselines erstellen, die bis zu 100.000 Arbeitselemente umfassen.  

Zu den weiteren Verbesserungen des Durchsatzes bei den Funktionen von Baseline gehören:

Arbeitsposten kopieren

  • 5.000 Arbeitselemente in Azure DevOps Server
  • 2.000 Arbeitselemente in Azure DevOps

Abweichungsberichte

  • 10.000 Arbeitselemente in Azure DevOps Server
  • 3.000 Arbeitselemente in Azure DevOps Service

Arbeitselemente zurücksetzen

  • Dieser Vorgang kann für 10.000 Arbeitselemente durchgeführt werden

Die Durchführung von Vorgängen mit großen Datenmengen kann mitunter zeitaufwendig sein. Modern Requirements ist sich bewusst, dass Ihre Zeit kostbar ist, und hat bereits Funktionen zur Steigerung der Effizienz implementiert.

Zeitaufwändige Vorgänge bremsen Sie nicht mehr aus. Diese Vorgänge werden nun im Hintergrund ausgeführt, und die Benutzer haben die Möglichkeit, sich per E-Mail benachrichtigen zu lassen, sobald sie abgeschlossen sind.

Diese Funktion wurde in das Modul „Review Management“ integriert und steht zur Verfügung, wenn die Funktion „Alle genehmigen/ablehnen“ auf große Mengen von Arbeitselementen angewendet wird. Das System erkennt automatisch, wenn der Vorgang länger als eine Minute dauern wird, und benachrichtigt den Benutzer.

Diese Funktion wird auch vom Smart Report unterstützt. Falls der Smart Report nicht sofort erstellt wird, wird ein Hintergrundprozess gestartet. Im Zusammenhang mit dem Smart Report enthalten die Benachrichtigungs-E-Mails Links, über die der Benutzer den erstellten Bericht im Word- oder PDF-Format speichern kann.

Fehlerbehebungen

Funktionalität und Benutzererfahrung sind zentrale Elemente der Designphilosophie von Modern Requirements.

Mit der Veröffentlichung von Update 2 wurden mehrere Fehler behoben. Eine vollständige Liste der Fehlerbehebungen sowie die Versionshinweise finden Sie hier.

Erstellen von Vorlagen für nicht-funktionale Anforderungen

Kundenfreigabe von Anforderungen in Azure DevOps

Erstellen von Vorlagen für nicht-funktionale Anforderungen

EErstellung, Verfassen und Verwalten nicht-funktionaler Anforderungen (NFR)) kann eine entmutigende und zeitaufwändige Aufgabe sein. Die meisten Leser des vorigen Satzes werden dem wahrscheinlich zustimmen 

Die Erstellung von NFRs kann eine schwierige Aufgabe sein, und die Erstellung nicht-funktionaler Anforderungen, die sowohl quantifizierbar als auch messbar sind, ist ein Problem, mit dem viele Teams zu kämpfen haben.  

Die Erstellung guter nicht-funktionaler Anforderungen ist jedoch die Mühe wert. 

Anpassbare Berichte in Azure DevOps

Nicht-funktionale Anforderungen bieten Teams eine Möglichkeit, den Erfolg eines Projekts, Prozesses oder Systems zu messen. Sie ermöglichen es Ihrem Team, messbare Methoden zu erfassen, mit denen Sie die verschiedenen Eigenschaften Ihres Projekts diskutieren, analysieren und bewerten können. 

Aufgrund des Wertes, den NFRs für ein Projekt bieten, beobachten wir oft, dass Teams lange und komplizierte Prozesse durchlaufen, um NFRs zu erstellen, die am Ende des Projekts kaum noch von Bedeutung oder Relevanz sind.  

Heute werden wir das ändern. 

In diesem Artikel behandeln wir sowohl den Wert der Erstellung von NFRs als auchwie Sie wie Sie einige einfache Werkzeuge und Techniken einsetzen können, um den Zeitaufwand für Qualität NFR-Erstellung zu reduzieren. 

Warum lohnt es sich, nicht-funktionale Anforderungen zu entwickeln?

Nicht-funktionale Anforderungen liefern Ihrem Team alle Erfolgskriterien für ein Produkt, ein Projekt, ein System, einen Prozess oder eine Anwendung. Wenn eine gute nicht-funktionale Anforderung erstellt wird, kann ein Team nicht nur feststellen, ob ein Projekt erfolgreich ist, sondern auch leicht erkennen, wie weit ein Projekt vom Erfolg entfernt ist.  

Gute nicht-funktionale Anforderungen können auf vielfältige Weise zum Erfolg eines Projekts beitragen, abgesehen davon, dass sie als Maßstab für den Erfolg dienen. NFRs können Teams dabei helfen, die übergeordneten Ziele eines Projekts zu verstehen, die Projektergebnisse mit den Geschäftszielen in Einklang zu bringen und vieles mehr.  

Es genügt zu sagen, dass hochwertige NFRs einen großen Beitrag zum Projekterfolg und zur Bewertung dieses Erfolgs leisten können. Das bedeutet jedoch nicht, dass sie einfach zu verwalten, zu ermitteln oder zu erstellen sind.  

Werfen wir einen Blick auf die wichtigste Technik, die Teams heute verwenden , um um nicht-funktionale Anforderungen schneller und besser zu erstellen.  

Die wichtigste Technik, um bessere nicht-funktionale Anforderungen schneller zu erstellen – Vorlagen

Bei der Erstellung nicht-funktionaler Anforderungen implementieren Teams Vorlagen, um diese Arbeitselemente schneller und mit größerer Konsistenz zu erstellen.

Per Definition, ist eine Vorlage alles, was als Modell dient, das andere kopieren und wiederverwenden können.  

In der Regel werden Vorlagen als voreingestelltes Format für ein Dokument, eine Datei oder einfach als Format erstellt, mit dem jede NFR erstellt werden kann. Nach der Implementierung muss das von einer Vorlage bereitgestellte Format nicht jedes Mal neu erstellt werden, wenn es benötigt wird. Benutzer können einfach eine Vorlage aufrufen und schnell loslegen.  

Thführt uns zum offensichtlichsten offensichtlichen Vorteils von Verwendung nicht-funktionaler Anforderungen Vorlagen 

Vorlagen sparen Zeit und erhöhen die Konsistenz! 

Wenn Teams anfangen mit dem Aufbau einen wiederholbaren Prozess aufzubauen beginnen, greifen sie häufig auf Vorlagen, um die Notwendigkeit, Dokumente oder Dateien ständig neu zu erstellen Dokumente oder Dateien FormularzuStattdessen sollten dieser Teile eines Dokuments, einer Datei oder einer Struktur als Vorlage wieder, kann Ihr Team Nacharbeiten reduzieren und von den Vorteilen einer größeren Konsistenz profitieren. 

Während Zeit  sparund und die Konsistenz wird erhöht sind großartig direkte Vorteile die Vorlagen bieten, gibt es gibt es viele nicht so offensichtliche indirekte Vorteile , die Vorlagen ebenfalls bieten 

Die indirekten Vorteile von Vorlagen für nicht-funktionale Anforderungen

Der größte indirekte Vorteil der Verwendung von Vorlagen besteht darin, dass sich ein einfach zu befolgender, strukturierter Ansatz für die Erstellung von Dateien, Dokumenten und Anforderungen entwickeln lässt.  

Durch die Bereitstellung einer vordefinierten Struktur können Benutzer, die mit einer bestimmten Datei oder einem bestimmten Dokument arbeiten, leichter erkennen, wo sie die einzelnen Informationen eingeben müssen und welches Format diese Informationen haben sollten.  

Diese Art der Anleitung verbessert nicht nur die Genauigkeit der bearbeiteten Inhalte, sondern reduziert auch den Zeitaufwand für die Erstellung von NFRs, die Überprüfung von Dokumenten und die Genehmigung von Anforderungen. Dies liegt zum Teil daran, dass die Bereitstellung einer Vorlage auch die Standardisierung und die Vertrautheit mit der zu erstellenden Ressource erhöht. 

Vorlagen vereinfachen die Arbeit mit NFR-Arbeitselementen in zweierlei Hinsicht. Die Erstellung des Arbeitselements wird vereinfacht, da die Daten lediglich in die richtigen Felder der Vorlage eingegeben werden müssen. Darüber hinaus präsentiert die Vorlage die Informationen nach der Erstellung des Arbeitselements in einer besser verwertbaren Form.

 Da der Prozess einfacher wird, wird er auch zugänglicher. Das bedeutet, dass Vorlagen auch die Erstellung von NFRs und deren Dokumentation für neue oder weniger erfahrene Business-Analysten vereinfachen. 

Diese Diskussion über Vorlagen könnte jedoch bereits zu einer gewissen Unklarheit geführt haben. 

Sprechen wir über die Verwendung von Vorlagen für Dokumente?  

Sprechen wir über die Verwendung von Vorlagen für die Erstellung von NFRs? 

Sprechen wir hier über die Verwendung von Vorlagen, die die Eigenschaften einer NFR beschreiben? 

Einfach gesagt: Ja. 

Eine Vorlage für nicht-funktionale Anforderungen kann in jedem dieser Bereiche verwendet werden, um die Erstellung, Ermittlung und Verwaltung Ihrer nicht-funktionalen Anforderungen zu unterstützen. 

 
Eine NFR-Vorlage kann zur Organisation und Verwaltung von NFRs, zur Unterstützung eines Teams bei der Dokumentenerstellung oder sogar bei der eigentlichen Erstellung von NFRs verwendet werden.  

 
Wenn Sie nach einer einfachen Methode suchen, um hochwertige NFRs zu erstellen, lesen Sie unseren Artikel „Zwei einfache Schritte zur Erstellung nicht-funktionaler Anforderungen“, den Sie hier finden! 

Unabhängig davon, wie Ihr Team Vorlagen zum Erstellen von NFRs verwendet, können Sie sicher sein, dass die Erstellung nicht-funktionaler Anforderungen einen unglaublichen Nutzen bringt und schneller und einfacher als je zuvor durchgeführt werden kann. 

Ausstattung Ihrer BA mit geeigneten Vorlagen zur Ermittlung von Anforderungen

Die Ermittlung von Anforderungen oder das Sammeln von Anforderungen war noch nie ein einfacher Prozess. Esistjedoch etwas, mit dem viele Menschentäglicham Arbeitsplatzkonfrontiert sind.

Wenn Sie beispielsweise gebeten werden, etwas zu erstellen oder fertigzustellen, stellen Sie möglicherweise einige Fragen. Was soll dieses Ding leisten (funktionale Anforderung) und wie soll es in Bezug auf Sicherheit, Benutzerfreundlichkeit oder Zugänglichkeit sein (nicht-funktionale Anforderung)?  

Ein gut ausgestatteter Business Analyst (BAwird ebenfalls Fragen stellen, die darauf abzielen, die notwendigen funktionalen und nicht-funktionalen Anforderungen eines Projekts, Prozesses oder Systems herauszuarbeiten. BAs nutzen Fragen in erster Linie als Mittel zur Interaktion mit Stakeholdern. Durch diese enge Zusammenarbeit mit Stakeholdern BAein ein Forum, das den Stakeholdern hilft, ihre Erwartungen an das Produkt zu formulieren.  

Während eines Gesprächs mit einem BA, einem SInteressengruppe wird , welche Funktionen er sich wünscht und was sein Produkt leisten soll (funktionale Anforderungen) sowie wie die Benutzererfahrung sein soll (nicht-funktionale Anforderungen).  

BA’s beschäftigen häufig mehrere bewährte Techniken , wenn sie mit Stakeholder. DWährend des Erhebungsprozesses könnten einige dieser Techniken umfassene: 

  • Fragebögen 
  • Mindmap Brainstorming  
  • Anwendungsfälle Erstellung 
  • Erstellung und Überprüfung von Dokumenten
  • und mehr… 

Jede dieser Techniken hat zwei Dinge gemeinsam.  

  1. Erstens werden sie alle zur Ermittlung von Anforderungen verwendet.  
  1. Zweitens kann jede dieser Techniken die Verwendung von Vorlagennutzen.

Lassen Sie uns darüber nachdenken, wie Fragebögen davon profitieren können, zu Vorlagen zu werden oder Vorlagen zu verwenden. 

Wir wissen, dassman die richtigen Fragen stellen muss,umdie richtigen Anforderungen zu ermitteln.
Hierkommtdas Wissen eineserfahrenen Business Analystenbesonders zum Tragen,daer den Erhebungsprozess schon unzählige Male durchlaufen hat. Er profitiert von seiner Erfahrung und weiß möglicherweisebesser,welcheFragen in Bezug auf bestimmte Branchen, Produkte oder Technologien zu stellen sind.  

Diese Erfahrungen und Kenntnisse lassen sich mit einer Vorlage für einen Fragebogen zu nicht-funktionalen Anforderungen leicht erfassen. Erfahrene BAs können gut durchdachte Fragenlisten oder Fragenvorlagen erstellen, die sich auf bestimmte Funktionen (FRs) oder Systemattribute (NFRs) konzentrieren, und passiv das Team Elicitation-Prozess , auch wenn sie nicht direkt beteiligt sind 

Diese Fragebogenvorlagen können dann für Struktur und Konsistenz für den Erhebungsprozess, sicherstellen, dass , dass die richtigen Fragen gestellt werdenund auch reduziertdie Wahrscheinlichkeit die Wahrscheinlichkeit, dass wichtige Fragen übersehen werden.   

Es gibt zahlreiche Beispiele dafür, wie Vorlagen Teams dabei helfen können, von dem Wissen zu profitieren, das sie bereits innerhalb ihres Teams haben. 

Sehen wir uns weitere Beispiele dafür an, wie Vorlagen heute verwendet werden in verschiedenen Aufgaben der Ermittlung und Erstellung ..  

Warum Teams in der Vergangenheit Tabellen als Anforderungsvorlagen verwendet haben

Viele Teams setzen implementieren nicht-funktionale Anforderungen Vorlagenin in Form einer Tabelle, um Anforderungen. 

Die Verwendung von Tabellen ergibt sich in der Regel aus dem Bedürfnis der Benutzer, ihre Anforderungen an einem Ort zu organisieren und zu verwalten.  Vor dem Einsatz expliziter Anforderungsmanagement-Tools wurden Tabellen verwendet, um die die Definition von Namens- und Nummerierungskonventionendie Nachverfolgung und Anforderungen, sowie durch Bereitstellung von Feldern für eine beliebige Anzahl von Eigenschaften. 

Tabellen haben historisch gesehen Arbeitund sowie Vorlagen , sie einfach zu organisieren und die Verwaltung Inhalt innerhalb der TabelleTabellen haben traditionell den zusätzlichen Vorteil, dass sie eine Möglichkeit bieten, Informationen exportieren aus einem Tabelle in anderen Bereichen wie der Dokumentenerstellung.  

Was ist das für ein Exportansatz? Kopieren und Einfügen.  

Für Teams, die Tabellen als Vorlagen verwenden, sind die AnforderungenAnforderungen werden in der Regel kopiert und eingefügt einer Tabelle kopiert und eingefügt werden dann in ein Dokument eingefügt. In der Regel werden die Felder einzeln kopiert und eingefügt einzelne in eine speziell für das Dokument entworfene Vorlage (ein weiteres Beispiel für die Verwendung von Vorlagen!) 

Während Tabellen früher eine robuste Lösung für die Verwaltung von Anforderungen , die eine Vielzahl von Feldern, haben sie in der heutigen Welt expliziter RM-Tools einige erhebliche Nachteile. 

Tabellen sind oft unzusammenhängende Zusammenstellungen wichtiger Informationen und können ooft  von anderen Tools und Prozessen isoliert. Ooft führt dies dazu, dass Tabellen werdenein zu einem zusätzlichen Schritt in Ihrem RM-Prozessund zu einer zusätzlichen Ressource, für deren Verwaltung, Aktualisierung und Pflege jemand verantwortlich sein muss.  

Das muss aber nicht so sein.  

Mit der Excel-Team-Registerkarten-Erweiterung von Microsoft können Teams die Tabellen, die sie in der Vergangenheit verwendet haben, ganz einfach mit ihrem Azure DevOps-Projekt verbinden. Sie können jedes Anforderungsfeld, jede Eigenschaft und jede Kennung ganz einfach dem Azure DevOps-Arbeitselement zuordnen, das in ihrem Projekt erstellt wird. 

Aber wie hilft Azure DevOps bei NFRs? 

Wie geht Azure DevOps mit nicht-funktionalen Anforderungen um?

Erstens ist Azure DevOps flexibel.  

Mit der ALM-Plattform von Microsoft können Sie ganz einfach alle Arten von Arbeitsaufgaben, die Ihr Team benötigt, zu einem Projekt hinzufügen.  

Nicht-funktionale Anforderungen sind nur eine der Arbeitsaufgabentypen, die Sie einem Projekt hinzufügen können.  

Was ist ein „Work Item“? Typ“?  

Arbeitselemente sind ADO-basierte Vorlagen für die Art von Anforderungen, die sie darstellen.  

Einige Beispiele sind funktionale Anforderungen, Übergangsanforderungen, User Stories oder sogar nicht-funktionale Anforderungen. Unabhängig davon, welche Taxonomie Ihr Projekt erfordert, Azure DevOps unterstützt sie, und jedes von Ihnen erstellte Arbeitselement verfügt über eigene Eigenschaften, Status und Beziehungen, die ausgewählt und angepasst werden können. 

Mit einer nicht-funktionalen Anforderung können Sie konfigurieren jeden Felder oder Eigenschaft , die Ihr Team benötigtbenötigt Verwaltung Ihrer Projekt. Wie bereits erwähnt, ist es mit der Excel-Erweiterung für Microsoft Teams [Link bereitstellen].  

Aber was können Sie mit NFRs tun, sobald sie in Azure DevOps (ADO) sind, und wie hilft die Migration der Erstellung von NFRs zu ADO Ihrem Team? 

Schauen wir uns die Werkzeuge an.  

Moderne Anforderungen für DevOps: Smart Docs – Anpassbare NFR-Dokumentvorlagen

Die Erstellung von Dokumenten hängt von den Richtlinien, Prozessen, Erwartungen und Anforderungen der Stakeholder einer Organisation abund kann sogar so gestaltet werden, dass sie Ihre nicht-funktionalen Anforderungen berücksichtigt. 

Dokumente bieten eine einfache Möglichkeit, Verantwortlichkeiten zu schaffen für die Einhaltung der vereinbarten Anforderungen für einem Projekt. Sie sich eine ein gewisses Maß Sicherheit für die Beteiligten, da Dokumente als als Checkliste für vereinbarte Anforderungen, die  leicht mit anderen Dokumenten abgeglichen werden kann, um festzustellen, ob die Beteiligten das bekommen, wofür sie bezahlt haben, oder ob die Arbeit nicht abgeschlossen wurde. 

Ein weiterer wichtiger Vorteil einer ordnungsgemäßen Dokumentation besteht darin, dass sich Anforderungen im Laufe eines Projekts häufig weiterentwickeln. Eine Anforderung kann im Laufe der Zeit klarer definiert werden oder sich einfach so weiterentwickeln, dass sie eine andere Erwartungen an Ihr Produkt  

Fügen Sie Ihrem Prozess die Hinzufügung von Dokumenten mit nicht-funktionalen Anforderungen hinzu. 

Mit der Weiterentwicklung der Anforderungen aucho auch die Erwartungen an Ihr Projekt. Das bedeutet, dass die Erfolgsindikatoren Ihres Projekts, auch bekannt als nicht-funktionale Anforderungen, überprüft und geändert werden müssen.  

Mit unserem Smart Docs-Modul der Modern Requirements4DevOps-Suite kann ein Benutzer direkt aus seinem Azure DevOps-Projekt heraus auf einfache Weise ein vollständig versionierbares Anforderungsdokument erstellen. Das bedeutet, dass Benutzer über eine benutzerfreundliche Dokumentenschnittstelle auf einfache Weise Änderungen an Anforderungen vornehmen und verfolgen können.  

Neue Anforderungen können ebenfalls einfach in Ihrem Projekt innerhalb einer Dokumentenschnittstelleoder Sie können sich dafür entscheiden, bestehende bestehende Anforderungen direkt ineinfügen. Das bedeutet, dass Sie Ihre nicht-funktionalen Anforderungen ganz einfach per Drag & Drop direkt in ein leicht exportierbares Dokument ziehen können, ohne Azure DevOps zu verlassen und ohne kopieren und einfügen zu müssen.  

Lassen Sie uns die Idee, Ihre bestehenden NFRs , die in Tabellen in Azure DevOps, und dann zu behandeln, wie Sie diese NFRs mit Modern Requirements in Dokumente umwandeln können.  

Zunächst importieren Sie Ihre nicht-funktionalen Anforderungen aus Ihrer Tabelle mithilfe der Microsoft Team-Tabellenerweiterung für Excel in Azure DevOps. Anschließend fragen Sie einfach alle nicht-funktionalen Anforderungen ab und ziehen sie per Drag & Drop in Ihr Dokument.  

So einfach ist das.  

Angenommen, Sie möchten nun einem Dokument eine Struktur hinzufügen, sodass nicht-funktionale Anforderungen nur in bestimmten Bereichen des Dokuments hinzugefügt werden können.  

Das unterstützen wir auch! 

Es gibt einen Template-Designer direkt in das Smart Docs-Modulintegriert, mit dem Sie festlegen können, welche Arten von Arbeitselementen an welcher Stelle in Ihren DokumentenDas bedeutet, dass jeder, der ein Dokument erstellt, egal ob NFR-basiert oder anderweitig, sich leicht an die Struktur Ihrer Vorlage halten und eine einheitliche Dokumentation erstellen kann. 

Moderne Anforderungen für DevOps: Intelligente Dokumente – Wiederverwendbare NFR-Dokumentvorlagen

Wiederverwendbare Dokumentvorlagen sind für jedes Team von großem Nutzen.  Wahrscheinlich nutzen Sie diese bereits heute.  

Eine wiederverwendbare Dokumentvorlage bietet Ihrem Team ein bereits ausgefülltes Dokument, das vorgibt, wie ein Dokument aussehen soll. Diese Art von Vorlage hilft Autoren dabei, leicht herauszufinden, wo bestimmte Informationen hingehören und welche kontextbezogenen Elemente das erstellte Dokument enthalten sollte.  

Denken Sie an das Word-Dokument, das Sie bereits auf Ihrem Desktop haben. Es enthält wahrscheinlich bereits Platzhalter für Dinge wie Einleitung, Umfang, Ziele sowie für bestimmte Anforderungen. Dies ist eine wiederverwendbare Dokumentvorlage.  

Der Hauptgrund, warum Dokumentvorlagen verwendet werden ist tdie die Effizienz zu steigern und Nacharbeiten bei der Dokumentenerstellung zu reduzieren Herstellungsprozess .  

Zum Glück für Teams, die derzeit mehrere Anwendungen für ihre RM- und Dokumentationsprozesse verwenden, gibt es eine Lösung, die für beides genutzt werden kann. Moderne Anforderungen mit Azure DevOps.  

Das wiederverwendbaren Dokumentvorlagen Vorlagen die Sie mit Modern Requirements + Azure DevOps erstellen, können so konfiguriert werden, dass sie alle Felder oder Eigenschaften enthalten,, die Sie in Ihrem Dokument anzeigen möchten. Sie können jedes Dokument als wiederverwendbare Dokumentvorlage speichern, die automatisch Felder wie Einführung, Ziele, NFR-Anforderungen und mehr automatisch ausfüllen. 

Mit nur wenigen Klicks können Sie Dokumente erstellen, die Ihrem Team helfen, schnell mit der Erstellung jeglicher Art von Dokumentation zu beginnen! Das bedeutet, dass Ihr Team nicht nur davon profitiert, dass Ihre Dokumente und Anforderungen an einem Ort gespeichert sind, sondern auch die Effizienz steigern, Strukturen schaffen, die Genauigkeit erhöhen und für Konsistenz sorgen Ihrem Dokumentenerstellungsprozess schaffen.   

Moderne Anforderungen für DevOps: FAQ-Modul – Anpassbare und wiederverwendbare Fragebogenvorlagen

Nicht-funktionale Anforderungen sind wesentlich abstrakter als ihre funktionalen Gegenstücke.  

Dadurch sie schwieriger zu entwerfen, da man nicht einfach auf das System zeigt und ihm sagt, was es tun soll, sondern Sie stellen Fragen dazu, wie das System sein soll, und verwenden NFRs, um dies darzustellen. 

Wie bereits zuvor in diesem Artikel erwähnt, ist der Aufbau starker NFRs basiert basiert auf der richtigen Fragestellung.  

Also, was ist, wenn Sie neu im Anforderungsmanagement sind oder wenig Erfahrung haben? Wo fangen Sie an? MR4DevOps begegnet dieser Situation mit unserem umfassenden FAQ-Modul.  

Das FAQ Modul besteht aus einer Reihe von gezielten Fragenvorlagen, die sich auf bestimmte Systemattribute beziehen und nach den drei Hauptaspekten des Produkts kategorisiert sind: Betrieb, Überarbeitung und Übergang.  

Darüber hinaus enthält das FAQ-Modul Fragenvorlagen zur Ermittlung von NFR für die Compliance und Risikomanagement basierte Entwicklung von Medizinprodukten. Als Benutzer die Fragen aus demVorlage erhalten automatisch erstellteine nicht-funktionale Anforderung direkt im Backlog. 

Der Fragebogen Vorlagen im FAQ-Modul sind für BAs von Vorteil mit aller Erfahrungsstufen Erfahrene BAs können bestehende Listen durch Hinzufügen eigener Fragen ändern oder eine eigene Fragenliste von Grund auf neu erstellenAuf diese Weise können BAs ihre Erfahrungen und ihr Wissen über den Erhebungsprozess festhalten und an andere Mitglieder des Teams weitergeben.  

Moderne Anforderungen für DevOps: Smart Report – Konfigurierbare Berichtsvorlagen

MR4DevOps bietet eine hervorragende Lösung für eines der größten Mängel von ADO: das Fehlen eines integrierten Berichterstellungstools.  

Wenn Sie Tools wie FAQ oder Smart Docs zum Erstellen und Verwalten Ihrer nicht-funktionalen Anforderungen verwenden, ist Smart Report das Tool, mit dem Sie Ihre Anforderungen ausgeben können. Mit Smart Report können Sie Anforderungen als PDF, HTML oder Microsoft Word ausgeben, wobei Sie Ihre eigenen vorgefertigte Kopf-/Fußzeilen und sogar ein Inhaltsverzeichnis oder eine Titelseite hinzufügen können.  

Möchten Sie einen Bericht für die NFRs Ihres Projekts erstellen?  

Das Smart Report-Tool ist mit einem fortschrittlichen Berichts Vorlagendesigner. Mit dem Vorlagendesigner können Sie und benutzerdefinierte Berichts vorlagenbasierend auf dem Workitem-Typ basierend auf dem Workitem-Typ. Auf diese Weise können Sie eine individuelle NFR-Vorlage erstellen, die alle Eigenschaften und Felder einer NFR anzeigt, die Sie in den Bericht aufnehmen möchten. Diese Informationen werden direkt aus dem Arbeitselement abgerufen! 

Diese Vorlage kann auf jede Gruppe ausgewählter oder abgefragter NFRs angewendet und jederzeit verwendet werden, wenn dies für Ihren Berichtsprozess erforderlich ist. Der Vorteil des Berichterstellungstools besteht darin, dass es Ihnen die Möglichkeit bietet, sofortige, strukturierteund konsistente Anforderungsberichte erstellen können. 

Möchten Sie sich selbst davon überzeugen?

Moderne Anforderungen4DevOps bietet mehrere Lösungen zur Unterstützung bei der Ermittlung, Erstellung und Verwaltungnicht-funktionaler Anforderungen nicht-funktionaler Anforderungen. 

Möchten Sie sich näher mit dem Entwerfen von Vorlagen mit Modern Requirements befassen oder herausfinden, welche anderen Tools Ihren Prozess verbessern können? Buchen Sie noch heute eine Produktdemonstration!

Erleben Sie selbst, wie unsere Modern Requirements-Toolbox die branchenführende Azure DevOps-Lösung von Microsoft zu einer einzigen Anwendung für das Anforderungsmanagement macht.

Besuchen Sie www.modernrequirements.com, um mehr über unser Unternehmen und unsere Produkte zu erfahren.

Fordern Sie eine Demo an!

Reduzieren Sie den Aufwand für UAT

50 % weniger Aufwand für UAT

Bewährte Zeitersparnis

80 % Zeitersparnis bei der Erstellung von Trace-Analysen

Genehmigungen optimieren

Deutliche Verringerung der Verzögerungen bei der Genehmigung

Leistung steigern

50 % Anforderungen Produktivitätssteigerung

Nacharbeit reduzieren

10-fache Reduzierung der Entwicklungsnacharbeiten

Vereinfachung der Compliance

40 % weniger Aufwand für die Compliance-Berichterstattung

Konfiguration 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. 

Anforderungen mit Modern Requirements4DevOps erstellen

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:

  1. Benutzerdefinierte ID
  2. Foul
  3. 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

  1. 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.
  2. 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.

  3. 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.

  4. 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:

  1. Geben Sie den folgenden Befehl in der Eingabeaufforderung ein: cd :\Programme\Modern Requirements\MR-Agent\bin

  2. Sobald Sie sich im Verzeichnis „bin“ befinden, geben Sie den folgenden Befehl ein: MRAgent

    Das Optionsmenü wird angezeigt.

  3. Typ 4 und drücken Sie die Eingabetaste.
  4. 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:

  1. Ein Ordner, der nach dem Namen des Azure DevOps (TFS)-Servers benannt ist (auf dem die benutzerdefinierte ID angewendet werden soll).
  2. 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.

  1. Erstellen Sie an diesem Speicherort einen Ordner, der den Namen des Azure DevOps-Servers trägt (auf den die Komponente angewendet werden soll).
  2. 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).
  3. 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

  1. Öffnen Sie die xml Datei im Notepad oder einem beliebigen Texteditor.
  2. 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.

  3. 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.
  4. 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.)
  5. 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.
  6. 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.
  7. 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.
    1. 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.
    2. 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
    3. 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.
  8. Nachdem Sie die Konfigurationsdatei erfolgreich fertiggestellt haben, speichern und schließen Sie die Datei.

Benutzerdefinierte ID auf vorhandene Arbeitselemente anwenden

  1. Geben Sie den folgenden Befehl in der Eingabeaufforderung ein: cd :\Program Files\Modern Requirements\MR-Agent\bin
  2. Sobald Sie sich im Verzeichnis „bin“ befinden, geben Sie den folgenden Befehl ein: MRAgent

     

    Das Optionsmenü wird angezeigt.

  3. Typ 1 und drücken Sie die Eingabetaste.
  4. Geben Sie die URL der Azure DevOps-Organisation (oder der TFS-Sammlung) ein.
  5. 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:

  1. Ein Ordner, der nach dem Namen des Azure DevOps (TFS)-Servers benannt ist (auf dem das „Dirty Flag“ angewendet werden soll).
  2. 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.

  1. 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).
  2. 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.
  3. 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

  1. Öffnen Sie die xml Datei im Notepad oder einem beliebigen Texteditor.
  2. 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.
  1. 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.
  2. Das Tag„FieldReferenceName“gibt an, welche Felder des Workitems (die Liste ist im Tag „WIType“ enthalten) überprüft werden sollen.
  3. 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.

  4. Der„WIType“des Zielabschnitts gibt den Typ der Workitems an, die als „dirty“ markiert werden, wenn die Bedingung im Quellabschnitt erfüllt ist.
  5. 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*:

  1. Konfigurieren der Konfigurationsdatei für den E-Mail-Monitor (die sich an einem bestimmten Speicherort befindet)
  2. 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:

  3. 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.

  4. Ä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.

  5. 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

  1. Funktioniert für alle Komponenten von MR Services
  2. Dient zur Überprüfung neuer Projekte/Sammlungen
  3. 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

  1. Funktioniert nur für benutzerdefinierte IDs
  2. Wird verwendet, um neu erstellten Arbeitselementen eine benutzerdefinierte ID zuzuweisen
  3. 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

  1. Gilt nur für den E-Mail-Monitor
  2. Wird verwendet, um zu prüfen, ob eine neue E-Mail eingegangen ist, aus der Arbeitsaufgaben erstellt oder aktualisiert werden könnten
  3. 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:

  1. 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 “.

  1. 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).
  2. 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.
  3. Diese Datei enthält die Vorlage für die gewünschte Konfiguration.

Konfigurieren der XML-Datei für den E-Mail-Monitor

  1. Öffnen Sie die xml Datei im Notepad oder einem beliebigen Texteditor.
  2. Bestimmen Sie den Wert des Server-URL Tag nach Bedarf, zum Beispiel:
  3. 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.
  4. 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.

  5. 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
    1. 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.

    2. 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.
    3. 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.
      1. OnCreate= ”true” means that the title would be set from the email’s subject only for new Work Items.
      2. OnUpdate=”false” bedeutet, dass bei bestehenden Workitems das Feld „Titel“ nicht aktualisiert würde.
    4. 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.
      1. 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.
      2. 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.
    5. Der zweite Teil dieses Feldes gibt Aufschluss über den Aufbau des Beschreibungsfeldes. Das Beschreibungsfeld würde sich aus den folgenden Informationen zusammensetzen:

      1. Sender Name shown inside <> e.g.
      2. Sender Email also shown inside <> e.g. <alice.ducas@steveandrews.com>
      3. Der E-Mail-Text wurde in einer neuen Zeile eingefügt
    6. 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.
    7. Nachdem Sie die Konfigurationsdatei erfolgreich fertiggestellt haben, speichern und schließen Sie die Datei.

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

Unterstützung bei Vorfällen

Erhalten Sie Live-Support per Telefon, E-Mail oder Webkonferenz. Jede Supportanfrage kann sich auf ein bestimmtes Problem beziehen.

Unterstützung bei Vorfällen

Los, geh jetzt!

E-Mail-Support

Schreiben Sie eine E-Mail an unser Support-Team, um schnellstmöglich eine Antwort zu erhalten. Wenn Sie uns eine E-Mail senden, wird automatisch ein Ticket für Sie erstellt!

E-Mail-Support

Los, geh jetzt!

Eine Idee einreichen

Möchten Sie mehr aus unseren Produkten herausholen? Ihre Vorschläge helfen uns, besser zu werden. Reichen Sie eine Idee ein, und wir prüfen, ob wir sie in unseren Backlog aufnehmen können!

Eine Idee einreichen

Los, geh jetzt!

Unterstützung durch die Community

Finden Sie Antworten auf häufig gestellte Fragen oder reichen Sie ein Ticket in unserem Community-Support-Portal ein.

Unterstützung durch die Community

Los, geh jetzt!

Fehler melden

Teilen Sie uns einen von Ihnen entdeckten Fehler mit, und wir werden dessen Behebung oberste Priorität einräumen. Niemand mag Fehler – und wir sind da keine Ausnahme.

Fehler melden

Los, geh jetzt!

Support kontaktieren

Unterstützung bei Vorfällen

Erhalten Sie Live-Support per Telefon, E-Mail oder Webkonferenz. Jede Supportanfrage kann sich auf ein bestimmtes Problem beziehen.

Unterstützung bei Vorfällen

Los, geh jetzt!

E-Mail-Support

Schreiben Sie eine E-Mail an unser Support-Team, um schnellstmöglich eine Antwort zu erhalten. Wenn Sie uns eine E-Mail senden, wird automatisch ein Ticket für Sie erstellt!

E-Mail-Support

Los, geh jetzt!

Eine Idee einreichen

Möchten Sie mehr aus unseren Produkten herausholen? Ihre Vorschläge helfen uns, besser zu werden. Reichen Sie eine Idee ein, und wir prüfen, ob wir sie in unseren Backlog aufnehmen können!

Eine Idee einreichen

Los, geh jetzt!

Unterstützung durch die Community

Finden Sie Antworten auf häufig gestellte Fragen oder reichen Sie ein Ticket in unserem Community-Support-Portal ein.

Unterstützung durch die Community

Los, geh jetzt!

Fehler melden

Teilen Sie uns einen von Ihnen entdeckten Fehler mit, und wir werden dessen Behebung oberste Priorität einräumen. Niemand mag Fehler – und wir sind da keine Ausnahme.

Fehler melden

Los, geh jetzt!