Funktionale Anforderungen und Artefakte dokumentieren

  • 8 Minuten

Beim Erfassen der Anforderungen werden sie im Allgemeinen entweder als funktional oder als nicht funktional eingestuft. Funktionelle Anforderungen beschreiben, was die Lösung tun muss bzw. ihr Verhalten. Nicht-funktionelle Anforderungen beschreiben im Allgemeinen verhaltensunabhängige Aspekte der Lösung, z. B. Leistungsanforderungen. In dieser Lerneinheit behandeln wir einige Dinge, die bei funktionalen Anforderungen zu beachten sind.

Jede funktionale Anforderung sollte eindeutig das „Wer“, „Was“ und „Warum“ der Anforderung erfassen. Wenn die Anforderung zu groß ist, sollte sie in kleinere Teile aufgeteilt werden.

Funktionelle Anforderungen

Die folgenden finden Sie einige einfache Beispiele für funktionale Anforderungen:

  • Als Vertriebsbenutzer muss ich in der Lage sein, eine Verkaufschance als „Verloren“ zu schließen und zu erfassen, warum sie verloren ist, damit wir in Zukunft unsere Verkaufstaktiken verbessern können.
  • Als Vertriebsleiter muss ich dazu in der Lage sein, einen Rabatt für ein Angebot zu genehmigen, damit ich den Gesamtpreis senken und dem Kunden einen Rabatt gewähren kann.
  • Als Buchhalter möchte ich daran gehindert werden, einen Batch mit ausstehenden Elementen zu schließen, damit ich ihn später nicht erneut öffnen muss.

Diese Beispiele kommunizieren: wer, was und warum.

Die folgenden Beispiele stellen einige schlecht strukturierte Anforderungen dar:

  • Verkaufschancen können gewonnen oder verloren werden.
  • Der Preis sollte Rabatte widerspiegeln.
  • Wählen Sie in der Batch-Artikelliste die dritte Schaltfläche von links Batch schließen aus. Dadurch sollte das Batch geschlossen werden, wenn keine Artikel vorhanden sind, die dies verhindern würden.

Wenn Sie Anforderungen jeglicher Art erfassen, ist es sehr hilfreich, die Zuordnung zum Prozess oder zum Kundenkontaktverlauf vorzunehmen, anstatt nur die Merkmale und Funktionen aufzulisten. Erstellen Sie eine Story für einen Benutzer und beschreiben Sie, wie dieser das von Ihnen entworfene System erfolgreich einsetzen wird. Sie können auf einem Whiteboard schreiben oder zeichnen, mit einem Tool einen Prozess grafisch darstellen oder jede andere Methode verwenden, die für Ihr Team in der Planungsphase, in der Sie sich gerade befinden, funktioniert. Ihr Team zerlegt die Teile später in kleinere verwertbare Elemente.

Akzeptanzkriterium

Es ist wichtig, ein klares Verständnis dafür zu haben, wann eine Anforderung als erfüllt angesehen wird. Oft hilft es, diese Anforderung zu dokumentieren, um festzustellen, ob die Anforderung detailliert genug ist und die richtige Größe hat. Diese Dokumentation ist auch für Testteams zum Bewerten der Implementierung der Anforderung hilfreich. Schließlich sollte sie mit dem Stakeholder überprüft werden, um sicherzustellen, dass sie korrekt ist, da sie dazu verwendet werden kann, den Umfangszuwachs zu verhindern. Es ist wichtig, nach Akzeptanzkriterien zu suchen, die möglicherweise nicht erfüllt werden können, und dann zu verhandeln, um einen erreichbaren Kompromiss zu erzielen.

Ausnahmen erfassen

Normalerweise hat eine einfache Anforderung wie das Schließen einer Transaktion einen einfachen Pfad und nur wenige Ausnahmepfade. Es ist wichtig, diese Ausnahmen zu überprüfen und zu identifizieren, wenn Sie den Happy Path erfassen. Wenn Sie beginnen, sich mit dem Design zu befassen, möchten Sie sich nicht in erster Linie auf Ausnahmen konzentrieren. Sie sollten als solche behandelt werden. Wissen Sie jedoch nicht, dass sie vorhanden sind, müssen Sie dies später überarbeiten. Es ist ideal, zu erfassen, wie häufig die Ausnahme auftritt. Einige Ausnahmen werden am besten durch Verfahren/Prozesse und nicht durch Softwareanpassungen behandelt.

Umfangszuwachs vermeiden

Wenn das Kontrollkästchen nicht aktiviert ist, würde jedes Projekt den ursprünglichen Planungs‑ und Budgetumfang erweitern. Der Projektgovernanceprozess sollte verwendet werden, um zu bewerten, wie mit diesen umgegangen werden soll, sobald sie identifiziert wurden. Abhängig von der Vertragsstruktur des Projekts kann es häufig vorkommen, dass Anforderungen, die für die Aufnahme akzeptiert werden, zu einer Änderungsreihenfolge führen. Diesen Umfang zu ignorieren, kann leicht zum Scheitern des Projekts führen.

Internationalisierung

Microsoft Power Platform bietet Herstellern viele Möglichkeiten zu Internationalisierung der Apps. Sowohl modellgesteuerte Apps als auch Portal-Apps bieten Internationalisierungsoptionen, einschließlich Sprachpaketen und mehreren Währungen. Für die Benutzerakzeptanz ist die genaue Dokumentation dieser Anforderungen unerlässlich. Die Dokumentation der Internationalisierung sollte mit den Anforderungen starten und in die Qualitätssicherungstestpläne, Benutzerakzeptanztests und die Systemdokumentation aufgenommen werden. Stellen Sie sicher, dass Sie die hier aufgeführten bewährten Methoden befolgen, um auch umsetzbare, testbare Anforderungen für Internationalisierungsanforderungen zu dokumentieren.

Lösungsartefakte

Es wird als bewährte Methode angesehen, Lösungskomponenten logische Namen zu geben, und während Sie die Dokumentation solcher logischen Namen vorbereiten, werden Sie den Wert sicherlich sehen. Die Dokumentation dieser Elemente kann sich in jedem Projekt ein wenig voneinander unterscheiden.

Ziel dieser Dokumentation sollte es sein, eine konsistente Fortführung der Lösungen im Laufe der Zeit zu gewährleisten und das Projektteam auf dem Laufenden zu halten. Dies ist insbesondere hilfreich, wenn Sie Teil eines Entwicklerteams sind und jedes Mitglied des Teams an einem anderen Funktionssatz arbeitet. Es wird viel einfacher, die wichtigen Dinge zu dokumentieren, wenn vorhersehbare Namen und eine konsistente Dokumentation von Namen und erwarteten Verhaltensweisen vorhanden ist.

Projektplanungselemente wie User Stories oder Backlog-Elemente können gute Ressourcen sein, um Ihnen mit Ihrer Dokumentation einen schnellen Einstieg zu ermöglichen. So verlockend es auch sein mag, mit der Erstellung dieser Dokumentation bis zum Abschluss des Projekts zu warten, es handelt sich um eine hilfreichere laufende Ressource, wenn sie zumindest bei jedem Projektmeilenstein abgeschlossen ist. Sie können Inkonsistenzen und Fehler erkennen und beheben, bevor sie sich zu größeren Problemen entwickeln.

Ziehen Sie beim Dokumentieren von Tabellen (entweder in einer modellgesteuerten App oder mit einer Dataverse-Datenquelle) in Erwägung, eine Tabellenbeschreibung wie den vorgesehenen Verwendungszweck aufzunehmen. Fügen Sie die Spalten aus jeder Tabelle sowie deren Datentyp und die Beschreibung hinzu. Dokumentieren Sie die Beziehungen zwischen Tabellen und die definierten Verhaltensweisen, wie z. B. das Verhalten beim Löschen von Zeilen. Alle Überlegungen zu Sicherheitsrollen und Sicherheit auf Spaltenebene sollten ebenfalls berücksichtigt werden. Dokumentansichten und ihre Abfragen; Formulare und ihre Zielgruppen/Verwendungen; Berichterstellung und Dashboards.

Die Automatisierung umfasst Geschäftsprozessabläufe, Power Automate Flows, Geschäftsregeln und klassische Workflows. Sie sollten nicht nur jede dieser eigenständigen Automatisierungen dokumentieren, sondern auch, wie sie zusammenarbeiten. Auch verwendete Konnektoren und deren Anforderungen können hier dokumentiert werden.

Zu den zu dokumentierenden Canvas-App-Komponenten gehören bestimmte Bildschirme und deren Navigation, verwendete Datenquellen, Formeln und Trigger für die Automatisierung. Power Apps-Portale haben ähnliche Dokumentationsanforderungen wie Canvas-Apps, unterscheiden aber auch zwischen authentifizierten Benutzern und anonymen Benutzern.

Schließen Sie beim Dokumentieren von Power Virtual Agents den Konversationsfluss auf Themenebene, gezielte Datenquellen und Eskalationspläne mit ein.

Neben spezifischen technischen Details kann es hilfreich sein, Erzählungen über die Benutzerreise zu schreiben. Dies ist mehr als „Benutzer klickt hier“ und mehr von der erwarteten Erfahrung in ihrem vollen Umfang. Betrachten Sie es als die tägliche Interaktion des Benutzers mit der Lösung. Berücksichtigen Sie in Anbetracht der Zielgruppe dieser Dokumentation Überlegungen wie die Zugänglichkeit in der Dokumentation und bieten Sie sowohl Wörter als auch Grafiken als Erklärungen an. Diese Dokumentation kann hilfreich sein, um neue Teammitglieder aufzunehmen, Benutzerakzeptanzkriterien zu erstellen und das Projekt nach Abschluss an den Kunden zu übergeben.

Dokumentdaten für Migration und Integration

Selten lässt sich ein Projekt ohne Altlasten starten. Benutzer haben ineffiziente Apps, die sie verwenden, voller Geschäftsdaten, die sie bereits verstehen. Je nach den Umständen können Sie sich mit den Daten verbinden oder sie migrieren. Für jede dieser Möglichkeiten sind Planung und Dokumentation erforderlich.

Die Qualität der Daten ist sehr wichtig, unabhängig von Migration oder Integration. Sind die Daten zutreffend? Gibt es alte Daten, die nicht mehr relevant sind? Gibt es Duplikate, deren Auswirkungen minimiert werden müssen? Können wir Duplikate vor der Migration beseitigen?

Das Erstellen einer Checkliste (und deren Befolgung) ist hilfreich, um die Auswirkungen der Übernahme der alten Daten in die neue Lösung zu minimieren.

Dokumentdatenquellen: Identifizieren Sie die Datenquelle und die genutzten Verbindungen. Identifizieren Sie die Qualität der Quelldaten. Identifizieren Sie Spalten, die migriert werden, und bedenken sie, dass nicht alle Quelldaten in das neue System übernommen werden.

Dokumentdatentypen: Vergleichen Sie die Quelldaten mit dem Zielschema. Identifizieren Sie mögliche Transformationsprobleme, bevor Sie mit der Übertragung der Daten beginnen.

Dokumentdatenzuordnung: Führen Sie spaltenweise eine Überprüfung der in das System eingehenden Daten durch und stellen Sie sicher, dass sie korrekt zugeordnet sind. Stimmen Sie Unterschiede in den Metadaten der Quell‑ und Zieldatenspalten ab.

Fehlerbehandlung bei Dokumenten: Machen Sie einen Plan, um Fehler beim Import oder bei der Integration zu beheben.

Platz für Ausreißer: Nicht alles wird ist eine exakte Eins-zu-Eins-Abbildung der Daten von der Quelle in die neue Umgebung. Ermitteln Sie diese Ausreißer und erstellen Sie einen Plan.

Kontinuierliche Bewertung der Datenqualität dokumentieren: Überprüfen, melden und reparieren Sie die Datenqualität.