Anforderungen verbessern
Im Idealfall sind alle Anforderungen perfekt und umsetzbar, aber die Realität ist, dass einige verfeinert, konsolidiert oder entfernt werden müssen, damit Sie einen soliden Satz von Anforderungen haben. Indem Sie jede Anforderung bewerten, können Sie nach Verbesserungsmöglichkeiten suchen.
Stellen Sie sich dabei die folgenden Schlüsselfragen:
Sind die Anforderungen klar und vollständig?
Gibt es Lücken, die behoben werden müssen, aber nicht in den Anforderungen erfasst sind?
Wurden alle regulatorischen und Compliance-Anforderungen berücksichtigt?
Ist diese Anforderung dupliziert, und sollte sie konsolidiert werden?
Enthält die Anforderung Komponenten, die außerhalb des Geltungsbereichs liegen?
Beinhaltet die Anforderung ein bestimmtes Design/eine spezifische Implementierung?
Wird in der Anforderung erklärt, wie das Altsystem mit dem Problem umgegangen ist, und nicht das eigentliche Geschäftsproblem?
Anforderungen dienen dazu, das zu lösende Problem und nicht seine Lösung zu erklären. Das Problem wird gelöst, indem alle Anforderungen untersucht und im Rahmen des Designprozesses einer Lösung zugeordnet werden. Die Benutzer, die die Anforderungen bereitstellen, müssen nicht wissen, wie das Problem gelöst wird, wenn sie Input zu einer Anforderung liefern.
Beispiel – enthält Designspezifikationen
Dieses Beispiel beschreibt eine Anforderung mit Designspezifikationen.
Der Kundenbetreuer wird per E-Mail von einem Microsoft Power Automate Flow benachrichtigt, der bei der Erstellung eines neuen Falls in Dynamics 365 ausgelöst wird, wenn er der Besitzer der Kontozeile in Microsoft Dataverse ist .
Diese Anforderung hätte einfacher formuliert werden können, und zwar: Als Kundenbetreuer möchte ich benachrichtigt werden, wenn mein Debitor einen neuen Fall eröffnet.
Versuchen Sie nach Möglichkeit, eine Anforderung auf das Was, Wer und Warum zu beschränken, und vermeiden Sie es, die Umsetzung in der neuen Lösung zu beschreiben. Indem Sie die Diskussion auf das Niveau der geschäftlichen Anforderungen heben, erhalten Sie ein besseres Verständnis des zu lösenden Problems. In vielen Fällen kann die Anforderung besser implementiert werden, als dies im Altsystem der Fall war.
Beispiel – fehlende Details
In diesem Beispiel wird eine Anforderung beschrieben, in der Details fehlen.
Der Debitor hat im ersten Jahr kein hohes Kreditlimit auf seinem Konto.
Wie beschrieben kann diese Anforderung nicht implementiert werden, weil Sie nicht wissen, wo das Limit liegt und was als hoch angesehen wird. Außerdem wäre die Anforderung aufgrund dieses Aspekts nicht testbar. Die Anforderung eines Limits könnte einfach mit einem harten Wert von $2 Millionen angegeben werden, oder sie könnte komplexer formuliert sein, z. B. mit einem Limit für jede Region. Letzteres Beispiel würde die Gesamtkomplexität der Anforderung erhöhen. Dies war ein einfaches Beispiel, aber stellen Sie sich einmal vor, wie mangelnde Klarheit sich bei einer komplexeren Anforderung auf den Projektumfang und die Ressourcen auswirken kann.