Techniken
Projektteams können verschiedene Techniken verwenden, um Anforderungen zu erfassen und zu verwalten. Microsoft Azure DevOps-Arbeitselemente und GitHub-Issues werden häufig verwendet, um die Zusammenarbeit an den Anforderungen im Projektteam zu erleichtern. Darüber hinaus sind Tools verfügbar, die auf das Rückstandsprotokoll‑ und Roadmap-Management spezialisiert sind und von Teams genutzt werden können. Anforderungen werden in diesen Tools oder einem Anforderungsdokument im Format Narrativ oder User Story erfasst.
User Stories konzentrieren sich auf den Benutzer, was er will und warum er eine bestimmte Aktion vom System verlangt.
Zum Beispiel „Als Vertriebsbenutzer möchte ich meinem Debitor einen Kunden per E-Mail senden können.“
Anforderungen werden oft in einem Rückstandsprotokoll kategorisiert, bis sie in einen aktiven Projektsprint/eine Iteration zur Implementierung priorisiert werden. Betrachten Sie das Rückstandsprotokoll als eine Liste von Ideen, die nur darauf warten, umgesetzt zu werden. Stellen Sie sich einen Sprint oder eine Iteration als einen bestimmten Zeitraum oder eine Arbeit vor, die für das Projektteam zusammengefasst wurde, um sie in die Lösung zu implementieren.
Bei der Planung eines Sprints oder einer Iteration werden Sie möglicherweise gebeten, die Priorisierung und Schätzung des Arbeitsaufwands für ein Arbeitselement/Problem im Rückstandsprotokoll zu unterstützen. Verschiedene Teams verwenden unterschiedliche Ansätze zur Schätzung des Aufwands. Einige verwenden Stunden, während andere eine Referenz wie die T-Shirt-Größe verwenden. Um einen Artikel zu schätzen, können Sie ihn im Wesentlichen als klein, mittel oder groß kategorisieren. Anschließend verwenden die Teams die Größe, um Elemente in einen Sprint oder eine Iteration für die Implementierung zu gruppieren.
Anforderungen sollten realisierbar und nicht zu groß sein, um sie in einem einzigen Sprint oder einer Iteration abzuschließen. Sie können große Anforderungen in kleinere Anforderungen unterteilen, die möglicherweise einfacher zu erfüllen sind. Einige Methoden bezeichnen die große Anforderung als Epic, also die allgemeine Anforderung, bevor sie in kleinere Teile zerlegt wird.
Anforderungen werden oft in die Kategorien funktional oder nichtfunktional unterteilt. Funktionale Anforderungen beschreiben, welche Aktionen die Lösung ausführen muss, oder ihr Verhalten. Nichtfunktionale Anforderungen beschreiben verhaltensunabhängige Aspekte der Lösung, z. B. Leistungsanforderungen. Um detailliert zu beschreiben, was von einer neuen Lösung erwartet wird, benötigen Sie funktionale und nichtfunktionale Anforderungen.
Funktionale Anforderungen
Funktionale Anforderungen sollten sich auf das „Wer“, „Was“ und „Warum“ der Anforderung begrenzen. Zum Beispiel „Als Kundendienstmitarbeiter muss ich in der Lage sein, ähnliche gelöste Kundenprobleme nachzuschlagen, um eine Lösung für das aktuelle Kundenproblem zu finden“ beschreibt eine funktionale Anforderung des Microsoft Dynamics 365 Customer Service.
Die meisten Ihrer funktionalen Anforderungen werden von Benutzern der fertigen Lösung gestellt.
Sie können nichtfunktionale Anforderungen verwenden, um Themen aufzugreifen, die den Benutzern im Allgemeinen wichtig sind, aber für den Erfolg der Lösung entscheidend sind. Diese Arten von Anforderungen decken im allgemeinen Themen wie die Leistung der Lösung, Kapazität, Datenschutz, Sicherheit und Compliance ab.
Zum Beispiel „Das System muss bei Ausfällen 2.500 gleichzeitig eingehende Problemberichte verarbeiten“ beschreibt eine nichtfunktionale Anforderung von Dynamics 365 Customer Service.
Nichtfunktionale Anforderungen
Die meisten Ihrer nichtfunktionalen Anforderungen werden von IT‑ oder Compliance-Mitarbeitern des Unternehmens und nicht von Ihren Endbenutzern gestellt.
Nichtfunktionale Anforderungen müssen klar beschreiben, wie der Erfolg gemessen und bestimmt wird. Oft enthalten die Anforderungen keine klaren Start‑ und Endpunkte für Messungen, um den Erfolg genau zu messen. Es ist auch üblich, nichtfunktionale Anforderungen einzubeziehen, auf die Sie keinen Einfluss haben, und Sie müssen diese Anforderungen identifizieren und Risiken mit dem Debitor zu mindern. Ein Beispiel für dieses Szenario könnte die Anforderung einer Leistungsgeschwindigkeit von unter einer Sekunde auf mobilen Geräten sein.
Nichtfunktionale Anforderungen liegen in der Regel in der Verantwortung des Lösungsarchitekten. Er bestimmt, wie sie erfüllt werden. Allerdings sollte auch der Berater die nichtfunktionalen Anforderungen der Lösung kennen. In vielen Fällen werden Sie möglicherweise aufgefordert, eine Änderung zu implementieren, um das Ziel der nichtfunktionalen Anforderung zu unterstützen.
Es ist wichtig, dass Sie sich die nötige Zeit nehmen, damit Ihre Anforderungen von hoher Qualität sind und für das vereinbarte System stehen. In vielen Fällen kann diese Gewissheit entscheidend für den Erfolg der Dynamics 365-Bereitstellung sein, nachdem Sie die Anforderungen implementiert haben.