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
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.
Benutzerfreundlichkeit, kurze Zykluszeiten, die Möglichkeit, Anforderungen online zu erstellen, Compliance-Berichte und weniger Nacharbeiten in der Entwicklung. Dies sind nur einige der Begriffe, mit denen unsere Kunden die Leistungsfähigkeit verschiedener Module der Anwendung „Modern Requirements4DevOps“ beschrieben haben. Mit unserem Release 2020 wurden neue Funktionen und Verbesserungen an den Modulen vorgenommen.
Hier stellen wir Ihnen einige Highlights zu einigen unserer Module in Modern Requirements sowie einige Tool-Verbesserungen vor, die wir für Sie umgesetzt haben. Die Module, die wir Ihnen vorstellen werden, sind:
1. Rechteverwaltung: Sie haben gefragt, und wir haben zugehört. Sie können nun den Benutzerzugriff verwalten. Ein Benutzer (der über Administratorrechte für die Sammlung/das Projekt verfügen muss) kann nun den Benutzerzugriff auf beide Module von Modern Requirements4DevOps sowie auf die Funktionen innerhalb jedes Moduls verwalten. Das Einrichten dieser Berechtigungen ist kinderleicht… Schritte zum Einrichten der Berechtigungen:
Das wirst du sehen:
Auf diesem Bildschirm können Sie dieBerechtigungen für*Gruppen und/oder*Teams festlegen (im linken Bereich). Es gibt zwei Möglichkeiten, Berechtigungen festzulegen: Entweder in den „*Allgemeinen Einstellungen“ oder einzeln in den „*Modern Requirements4DevOps-Modulen“ (im rechten Bereich der Registerkarte „Berechtigungen“). Hier können Sie die Berechtigungen für die Funktionen der einzelnen Module festlegen.
Die folgenden Berechtigungsoptionen stehen zur Verfügung:
Derzeit wird die Rechteverwaltung für drei Module unterstützt: Smart Docs,Baseline undReporting.
Weitere Informationen zu den Neuerungen im Bereich Rechteverwaltung und deren Funktionen finden Sie im Video.
2. Verbesserungen am Review-Modul: Das Review-Modul ermöglicht es Ihnen, innerhalb der Projektumgebung zu kommunizieren, Inhalte zu prüfen und zu genehmigen sowie bei Bedarf Änderungen vorzunehmen. Das Review-Modul wurde verbessert. Hier finden Sie eine Liste einiger neuer Funktionen:
Lesezugriff für Nichtteilnehmer an der Überprüfung: Mit dieser Erweiterung können Sie nun Berechtigungen für Nichtteilnehmer festlegen, sodass diese die Details der Überprüfung im schreibgeschützten Modus einsehen können.
Nicht teilnehmende Benutzer:Benutzer, die weder Genehmiger noch Prüfer sind.
Automatische Massenerstellung von Prüfberichten: Mit dieser Erweiterung können Sie Prüfberichte für alle Überprüfungen eines Projekts auf einmal als Sammelbericht oder projektweise über das Admin-Panel erstellen.
Hier können Sie Projekte auswählen und Details angeben, um die Prüfberichte zu den bestehenden Überprüfungen automatisch zu erstellen
Format der Prüfberichte – Word/PDF: Das System bietet Ihnen nun die Möglichkeit, das Format auszuwählen, in dem die Prüfberichte erstellt werden sollen. Sie können zwischen einer Word- und einer PDF-Version wählen.
Der Zweck des Genehmigungsprüfungsberichts besteht darin, Einzelheiten zu allen Arbeitsaufgaben einer Überprüfung bereitzustellen. Er liefert einen vollständigen Überblick darüber, wer die Arbeitsaufgaben der Überprüfung genehmigt oder abgelehnt hat, sowie die entsprechenden Kommentare und Entscheidungen.
Weitere Informationen zu den Neuerungen im Bewertungsmanagement und dessen Funktionen finden Sie im Video.
3. Erweiterungen bei Smart Docs: Smart Docs ist ein Tool, das die Lücke zwischen Dokumenten- und Informationsmanagement schließt, indem es die Erstellung von Anforderungen in einer Online-Dokumentansicht ermöglicht. Smart Docs wurde um neue Funktionen erweitert; hier sind einige der wichtigsten Neuerungen:
Vollbildunterstützung: Für eine bessere Benutzererfahrung und eine größere Anzeige können Sie Smart Docs nun im Vollbildmodus anzeigen. Das bedeutet eine bessere Übersicht beim Erstellen Ihrer Online-Anforderungsdokumente.
Aktualisierung der Benutzeroberfläche im rechten Bereich:
Aktualisierung zur Übernahme von Eigenschaften des übergeordneten Workitems: Mit dieser Aktualisierung wird das Kontrollkästchen zur Übernahme der Eigenschaften des übergeordneten Workitems in das untergeordnete Workitem standardmäßig als „nicht aktiviert“ angezeigt.
Hinweis: Wenn in der Dropdown-Liste keine Eigenschaften ausgewählt werden, werden im untergeordneten Workitem keine Eigenschaften übernommen.
Weitere Informationen zu den Neuerungen in Smart Docs und dessen Funktionen finden Sie im Video.
4. Verbesserungen am Smart Report: Mit Smart Report können Benutzer ihre Berichte entsprechend der Struktur der Arbeitselemente formatieren. Das Modul ist aus vielen ADO- und Modern Requirements4DevOps-Modulen heraus zugänglich. Hier finden Sie eine Liste einiger Verbesserungen, die am Smart Report-Modul vorgenommen wurden:
Word-Vorlage mit Makros hochladen: Mit Smart Report können Sie nun über die Funktion „Word-Vorlage hochladen“ sowohl Word-Dokumente mit Makros (.docm) als auch Word-Vorlagen mit Makros (.dotm) in Smart Report hochladen und ausführen. Damit wird das Hochladen von Word-Vorlagen für Sie noch einfacher.
Auswahl der zuletzt hochgeladenen Word-Vorlage beibehalten: Ratet mal… Smart rReport ist jetzt noch smarter geworden und behält nun die Auswahl bei, die ihr beim Hochladen eurer Word-Vorlage getroffen habt.
Auswahl des letzten Smart-Teils beibehalten: Wir haben uns nicht damit begnügt, die letzte Auswahl für die Wortvorlage zu speichern … Es wurden Verbesserungen vorgenommen, sodass das System nun auch die Auswahl Ihres letzten Smart-Berichtsteils beibehält. Das ist ein voller Erfolg für alle, die Berichte erstellen.
Weitere Informationen zu den Neuerungen in Smart Reports und dessen Funktionen finden Sie im Video.
5. Verbesserungen bei „Baseline“: Mit „Baseline“ können Sie zu einem bestimmten Zeitpunkt eine Momentaufnahme Ihrer Anforderungen erstellen, um diese besser zu kontrollieren und Änderungen nachzuverfolgen. So wird Ihre Arbeitserfahrung dadurch noch besser:
Auswahl des Arbeitselements beim Wechseln zwischen Registerkarten beibehalten: Das System merkt sich nun die zuletzt ausgewählte Arbeitselement, wenn Sie innerhalb einer Baseline zwischen verschiedenen Registerkarten wechseln. Was bedeutet das? Nun, wenn Sie mit einer Baseline arbeiten (insbesondere mit einer großen) und zur Registerkarte „Vergleichen“ oder „Details“ wechseln und dann zurück zur Registerkarte „Ansicht“, falls Sie vergessen haben, mit welchem Arbeitselement Sie gerade gearbeitet haben … Machen Sie sich keine Sorgen mehr, denn das System merkt sich das für Sie.
Vergleichs-ID beim Baseline-Vergleich: Es wurden Verbesserungen vorgenommen, sodass Sie nun nur noch Revisionen von Arbeitselementen anzeigen können, die in beiden verglichenen Baselines vorhanden sind. Beispiel: Wenn ein Arbeitselement in einer der Baselines nicht vorhanden ist, wird keine Revisions-ID angezeigt; stattdessen erscheint in der Spalte „Rev.ID“ oder „Comp.Rev.ID“ ein „-“. Diese Regel gilt auch für den Differenzbericht.
Weitere Informationen zu den Neuerungen in Baseline und dessen Funktionen finden Sie im Video.
6. MatCal (Neu): In Modern Requirements wurde eine neue Funktion eingeführt, mit der mathematische und logische Ausdrücke berechnet werden können. Klingt spannend? Nun, wir sind jedenfalls begeistert davon. Und zwar aus folgenden Gründen:
So gehen Sie vor: Übermitteln Sie Ihre Formeln an einen Mitarbeiter des Modern Requirements Customer Success-Teams, und wir nehmen die Konfiguration gerne für Sie vor.
Weitere Informationen zu MatCal und seinen Funktionen finden Sie im Video.
Wir freuen uns, Ihnen mitteilen zu können, dass „Modern Requirements4DevOps 2020“ nun zum Download bereitsteht!
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:
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 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.
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.
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.
Mit der Funktion „Mit Quell-Workitem verknüpfen“ können Sie Anforderungen ganz einfach auf ihre ursprüngliche Quelle zurückverfolgen. Diese Funktion bietet zwar zahlreiche Anwendungsfälle für die direkte Übertragung von Anforderungen von einem Projekt in ein anderes, die hier beschriebenen fortgeschritteneren Anwendungsfälle kommen jedoch zum Tragen, wenn Sie Anforderungen stattdessen aus einer Bibliothek oder einem Repository in ein Projekt übertragen.
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.
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.
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.
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.
Der Wert unseres FAQ-Moduls lässt sich in zwei einfachen Punkten beschreiben.
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.
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.
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.
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.
Weiterlesen
In diesem Artikel befassen Sie sich mit der Dokumentation nicht-funktionaler Anforderungen, um ein Verständnis dafür zu entwickeln, was Dokumentation ist und warum wir Dokumente erstellen.
Die Dokumentation ist ein wichtiger Bestandteil des Anforderungsmanagementprozesses. Der Zweck eines Dokuments besteht darin, spezifische Informationen über ein Projekt zu liefern, die mit den Beteiligten geteilt werden sollen. Wie viele Aspekte des Anforderungsmanagements ist auch die Dokumentation kein standardisierter Prozess. Teams gehen die Dokumentation auf unterschiedliche Weise an. Wie, wann und welche Dokumente innerhalb eines Prozesses erstellt werden, variiert von Team zu Team. Wenn die Dokumentation jedoch Teil Ihres Prozesses ist, werden Sie im Laufe eines Projekts wahrscheinlich eine Vielzahl von Dokumenttypen und Überarbeitungen dieser Dokumente erstellen.
INHALTSVERZEICHNIS
Der Hauptzweck der Dokumentation besteht darin, zu informieren. Die Dokumentation bietet jedoch auch einige indirekte Vorteile. So sorgt sie beispielsweise für Nachvollziehbarkeit. Dokumente sind eine einfache Möglichkeit, sich selbst in die Pflicht zu nehmen, die vereinbarten Anforderungen zu erfüllen. Aus Sicht der Stakeholder sorgt die Dokumentation für zusätzliche Sicherheit, da diese Dokumente als Checkliste für die vereinbarten Anforderungen dienen. Anhand der Dokumentation lässt sich überprüfen, ob Arbeiten nicht abgeschlossen wurden oder ob das geliefert wird, wofür bezahlt wurde.
Ein weiterer Vorteil der Dokumentation besteht darin, dass Teams den Umfang der Anforderungen während der gesamten Projektlaufzeit überwachen können. Im Laufe eines Projekts entwickeln sich Anforderungen weiter. So kann beispielsweise eine einzelne Anforderung im späteren Verlauf genauer definiert werden. Da Dokumente im Laufe des Projekts neu erstellt oder aktualisiert werden, lassen sich die Anforderungen zwischen den verschiedenen Dokumentversionen vergleichen. Auf diese Weise können Teammitglieder Anforderungen identifizieren, die möglicherweise vom ursprünglichen Umfang abweichen.
Es gibt kein standardisiertes Dokument, das speziell für nicht-funktionale Anforderungen erstellt wurde. Das bedeutet jedoch nicht, dass Sie im Rahmen Ihres eigenen Prozesses keine spezifische Dokumentation für nicht-funktionale Anforderungen erstellen können. Stattdessen werden nicht-funktionale Anforderungen in der Regel in einen umfassenderen Dokumenttyp integriert.
Es gibt verschiedene Anforderungsdokumente, die dazu dienen, bestimmte Details eines Projekts hervorzuheben. So können beispielsweise Dokumente für geschäftliche Anforderungen (BRD), technische Anforderungen (TRD) und zahlreiche andere Aspekte des Anforderungsmanagements erstellt werden.
Im Zusammenhang mit dem Dokumentationsprozess werden nicht-funktionale Anforderungen in der Regel in Dokumenten zu funktionalen Anforderungen (FRD), Produktanforderungen (PRD) und Software-Anforderungsspezifikationen (SRS) aufgenommen.
Werfen wir einen kurzen Blick auf einige der oben aufgeführten Dokumenttypen, die nicht-funktionale Anforderungen enthalten, um besser zu verstehen, warum diese Dokumente erstellt werden.
Das Dokument zu den funktionalen Anforderungen ist eine formelle Darstellung der funktionalen Anforderungen einer Anwendung. Ein FRD wird in der Regel von einem Business-Analysten auf der Grundlage mehrerer Gespräche mit Kunden und Stakeholdern erstellt, um die Anforderungen zu ermitteln. Die Erstellung des FRD erfolgt unter der Aufsicht des Projektleiters.
Nicht-funktionale Anforderungen sind in einem FRD in der Regel in einem eigenen Abschnitt aufgeführt. Dieser Abschnitt folgt normalerweise auf die funktionalen Anforderungen und trägt die Überschrift „Nicht-funktionale Anforderungen“. In manchen Dokumenten können nicht-funktionale Anforderungen jedoch nach Systemattributen kategorisiert (z. B. als „Betriebsanforderungen“) oder unter Begriffen wie „Nicht-geschäftliche Anforderungen“ aufgeführt werden.
Das Produktanforderungsdokument wird in der Regel vom Projektleiter erstellt. Das PRD dient dazu, den Test- und Entwicklungsteams mitzuteilen, welche Funktionen in einer Produktversion enthalten sein müssen.
Beachten Sie die Unterschiede zwischen funktionalen und nicht-funktionalen Anforderungen. Nicht-funktionale Anforderungen geben keine direkten Vorgaben dazu, was ein Produkt leisten soll. Sie beziehen sich auf Produkteigenschaften, die bestimmen, wie sich ein Produkt anfühlt, sowie auf andere technische Spezifikationen, die zur Benutzererfahrung beitragen. Produktanforderungsdokumente sind detailliert. Der Zweck dieser Dokumente besteht darin, die allgemeine Ausrichtung des Produkts vorzugeben. Daher werden funktionale und nicht-funktionale Anforderungen in eigenen Abschnitten eines PRD behandelt.
Ein Dokument mit den Systemanforderungen (SRS) wird erstellt, um die Funktionen und das Verhalten einer Software oder eines Systems darzustellen und zu beschreiben. In den meisten Fällen werden SRS-Dokumente von Systemarchitekten oder Produktverantwortlichen verfasst, die Experten auf diesem Gebiet sind. Während der ersten Phase der Anforderungserfassung arbeiten die Produktverantwortlichen jedoch eng mit den Kunden zusammen.
Die nicht-funktionalen Anforderungen sind erneut in einem eigenen Abschnitt des Dokuments „Systemanforderungsspezifikationen“ zu finden.
Das eigentliche Problem beim Dokumentationsprozess im Anforderungsmanagement ist die mangelnde Standardisierung. Bestimmte Dokumenttypen sind häufiger anzutreffen als andere. Die Struktur und der Inhalt dieser Dokumente variieren jedoch von Team zu Team. Zudem haben Teams stets die Möglichkeit, die Dokumentation auf Ad-hoc-Basis anzugehen. Wie bereits erwähnt, könnte ein Team die Dokumentation nicht-funktionaler Anforderungen in einem eigenen, spezifischen Dokument vornehmen.
Die fehlende Standardisierung scheint ein Vorteil zu sein, der Flexibilität im Dokumentationsprozess bietet. Leider hat diese Flexibilität auch einige Nachteile. Eine fehlende Standardisierung kann dazu führen, dass Arbeitselemente nicht berücksichtigt werden. Im Hinblick auf nicht-funktionale Anforderungen kann dies dem Erfolg eines Produkts abträglich sein, da diese die Benutzererfahrung eines Produkts bestimmen.
Um dies zu veranschaulichen, stellen Sie sich eine Situation vor, in der Sie zwei ähnliche Produkte ausprobiert haben. Die Wahrscheinlichkeit ist groß, dass Ihnen eines der beiden Produkte besser gefallen hat, obwohl beide Produkte ihre beabsichtigten Funktionen erfüllt haben. Dies liegt höchstwahrscheinlich daran, dass das Produkt, für das Sie sich entschieden haben, eine bessere Benutzererfahrung bietet. Die Benutzererfahrung wird von nicht-funktionalen Anforderungen bestimmt. Durch die Festlegung klar definierter, messbarer und überprüfbarer nicht-funktionaler Anforderungen können Teams den Erfolg eines jeden Projekts schnell und eindeutig messen.
Durch die Aufnahme nicht-funktionaler Anforderungen in die Dokumentation werden diese Anforderungen besser sichtbar, sodass sie überprüft und verfeinert werden können. Diese Sichtbarkeit kann auch die Erstellung und Weiterentwicklung funktionaler Anforderungen in Ihrem Dokument beeinflussen.
Mit dem „Smart Docs“-Tool von Modern Requirements können Benutzer das Grundgerüst ihrer Anforderungsdokumente direkt in ihrer Azure DevOps-Umgebung erstellen. Beim Erstellen eines Smart Docs können Anforderungen – einschließlich nicht-funktionaler Anforderungen – direkt aus dem Projekt-Backlog in das Smart Doc eingefügt werden. Zudem können nicht-funktionale Anforderungen beim Erstellen eines Smart Docs spontan verfasst werden.
Smart Docs verfügt zudem über ein umfassendes Versionsverwaltungstool, mit dem Benutzer ihre Smart Docs jederzeit versionieren können. Mithilfe der Versionsverwaltung lassen sich Änderungen an Arbeitselementen wie nicht-funktionalen Anforderungen durch den Vergleich verschiedener Versionen nachverfolgen und als Änderungsformulare exportieren.
Das Review-Management ist ebenfalls in das Smart Docs-Tool integriert. Modern Requirements4DevOps bietet eine einheitliche Lösung für die Anwendungsprüfung, die die Zusammenarbeit im Team bei der Überprüfung und Überarbeitung von Arbeitsaufgaben fördert. Durch das Initiieren von Prüfungen können Teammitglieder und Stakeholder Arbeitsaufgaben kritisch begutachten. Insbesondere im Hinblick auf nicht-funktionale Anforderungen sind Prüfungen ein entscheidender Bestandteil des Managementprozesses, da diese Arbeitsaufgaben als Maßstab für den Erfolg eines Projekts dienen können. Die Möglichkeit, Prüfungen nahtlos parallel zur Dokumentenerstellung durchzuführen, fördert einen starken Workflow, der auf die Erstellung klar definierter Anforderungen ausgerichtet ist.
Ist die mangelnde Standardisierung in Ihrem eigenen Dokumentationsprozess ein Problem? Smart Docs bietet eine Lösung für dieses branchenweite Problem, indem es die Erstellung wiederverwendbarer Dokumentvorlagen ermöglicht. Mit dem Tool „Meta Template Designer“ können Smart-Docs-Nutzer die Struktur ihrer Dokumente individuell anpassen. Durch die Erstellung einer maßgeschneiderten Struktur für Ihr Dokument können Nutzer entscheiden, welche Arbeitselemente aufgenommen werden sollen und an welcher Stelle im Dokument diese erscheinen sollen. Strukturierte, wiederverwendbare Dokumentvorlagen sorgen für Konsistenz und fördern die Effizienz (weniger Nachbearbeitung von Dokumenten) im Dokumentationsprozess Ihres Teams.
Mit Modern Requirements4DevOps können Sie Anforderungsdokumente direkt aus Ihrer Azure DevOps-Umgebung heraus erstellen. Sehen Sie sich dieses mit Smart Docs erstellte Dokument mit funktionalen Anforderungen an!
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.
Testen Sie Modern Requirements hier in der Cloud.
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.
