Get best of the week

Anforderungen an die Fingersoftware

Ein Beitrag über die Grundlagen der Entwicklung von Anforderungen - ohne komplexe Diagramme, Begriffe und Tabellen, aber mit Gifs.

Bild

Kurz gesagt, die Hauptschritte bei der Entwicklung von Anforderungen sind:

  1. Warum müssen wir etwas tun? (Benötigen Sie mehr Gold)
  2. Was werden wir machen? (Alles ist wie die Leute, aber billiger)
  3. Wie machen wir das? (natürlich mit Blockchain und Datasientists)
  4. Wann werden wir das tun? (gestern und Refactor "später")

Und jetzt im Detail.

Wenn Sie jemals darum gebeten haben, etwas zu tun, bedeutet dies, dass Sie Anforderungen erstellt haben. Sie können in Form eines mündlichen Wunsches, eines Briefes, einer technischen Aufgabe, einer Aufgabe oder irgendetwas anderem vorliegen.
Die Anforderungen sind also überall.

Bild

Wenn nach Erfüllung der Anforderung ein Fehler aufgetreten ist, hat dies entweder den Ausführenden durcheinander gebracht
oder Sie haben die Aufgabe falsch eingestellt.

Wie Sie wissen, kann die falsche Aufgabe ziemlich teuer sein. Zum Beispiel, wenn ein Team von 5 Programmierern ein halbes Jahr lang ein System entwickelt hat, das niemand benötigt.

In diesem turbulenten Zeitalter werden agile Designanforderungen häufig vernachlässigt. Flexible Methoden ersparen Ihnen jedoch nicht immer große Verluste. Vergessen Sie daher auch dann nicht den gesunden Menschenverstand und nehmen Sie aus den Best Practices, was Sie im Moment benötigen, auch wenn Sie keinen Analysten für das Projekt haben, auch wenn Sie überhaupt keine IT sind.

Was sind Anforderungen und warum ist es wichtig, sie entwickeln zu können?

Wenden wir uns also den Quellen zu:

Bild

Das heißt, Sie können über Anforderungen und zukünftige Eigenschaften sprechen. Wie wäre es mit einem Produkt, das die Entwicklungsziele erfüllt?

Wo soll ich mit der Entwicklung von Anforderungen beginnen? In der Definition ist ein Hinweis verborgen: Sie müssen mit dem Ziel beginnen - warum müssen wir etwas tun?

1. Warum?


Bild

Wie "ASAP !!!!" Es war nicht nötig, etwas zu tun - es ist wichtig, Zeit und Energie zu finden, um herauszufinden, warum dies notwendig ist.

Denn oft ändert sich die Aufgabe nach Klärung des Ziels oder wird vollständig beseitigt.
Beispielsweise

zeigt ihm der Kunde umgehend alle Bestellungen an, die im System getätigt wurden. Nehmen wir an, wir haben eine Aufgabe mitten im Sprint angespannt und verschoben, um alle Befehle für den Administrator anzuzeigen. Danach fordert der Kunde auf, in einem separaten Fenster eine Liste aller Unternehmen anzuzeigen, deren Bestellungen er sieht. Sie haben es auch getan. Dann bittet der Kunde, zusätzlich alle Partnerunternehmen zurückzuziehen. Okay ... Nach einiger Zeit treffen wir uns mit dem Kunden und sehen, wie er beide Listen in Excel hochlädt, den Unterschied erkennt und Unternehmen anruft, die keine Bestellungen haben, um sie daran zu erinnern, Bestellungen über unser System aufzugeben.

Wenn wir den Kunden von Anfang an fragen würden, welches Ziel er mit der Betrachtung aller Bestellungen erreichen möchte, würden wir viel Zeit und Mühe sparen, indem wir Unternehmen, die bisher keine Bestellungen aufgegeben haben, sofort Bericht erstatten.
Sie können die "Five Why" -Methode oder eine andere verwenden. Aber normalerweise wehren sich die Menschen nicht: Wenn Sie Interesse an ihrer Arbeit zeigen, wird eine Lösung verfügbar.

Nachdem Sie sich für ein Ziel entschieden haben, müssen Sie es klar definieren und Kriterien festlegen, anhand derer Sie genau sagen können, dass das Ziel erreicht wurde.

Beispielsweise wird der

Prozess der Materialbestellung als automatisiert angesehen, wenn> 90% der Partnerunternehmen Bestellungen über das System aufgeben.

Dies erleichtert das Verständnis der Aufgaben und macht gleichzeitig die Hände frei bei der Auswahl der Mittel zur Erreichung des Ziels.

Und ja, vergessen Sie nicht, diese Schönheit mit den Kunden abzustimmen. Vergessen Sie im Allgemeinen nicht, die Anforderungen mit allen Interessenten abzustimmen.

2. Was?


Das Ziel wird auf unterschiedliche Weise erreicht. Und der zweite wichtige Schritt bei der Entwicklung von Anforderungen besteht darin, den Weg zu wählen - was genau werden wir tun, um das Ziel zu erreichen.

Bild



, :

. . . // .

. — , .

. . .

Um über alle Optionen nachzudenken, müssen Sie herausfinden - was passiert jetzt? Wie funktioniert der Prozess ohne Ihr System, wie arbeiten Benutzer und Kunden? Auch wenn es noch keinen Prozess gibt, sind detaillierte Informationen zum aktuellen Status sehr wichtig. Wir werden also verstehen, welche Lösung das Problem beheben wird, und keine andere erstellen.

Bild

Jede Implementierungsoption hat ihre Vor- und Nachteile, ihre erforderlichen Ressourcen und ihr Ergebnisniveau. Nachdem Sie alle Optionen modelliert, diese Informationen ausgearbeitet oder zumindest nur mit Interessenten gesprochen haben, können Sie eine ausgewogene und informierte Entscheidung treffen.

3. Wie?


Wir haben also unser Ziel verstanden und was wir tun werden, um es zu erreichen. Es bleibt abzuwarten, wie wir dies implementieren: Welche Seiten werden wir den Benutzern zeigen, in welcher Form werden wir den Bericht für den Kunden anzeigen, wie werden wir Daten von einem anderen System erhalten, wie werden wir sie speichern und so weiter.

Diese Phase ist eine Frage der Technologie. Und wenn Sie die beiden vorherigen erfolgreich abgeschlossen haben, wird es viel einfacher.
Obwohl die Technik vom Kontext abhängt, ist es nützlich, sich entlang der „Checkliste“ von Wigern und anderen klugen Leuten zu bewegen. Wenn für Sie eine Art von Anforderungen derzeit nicht relevant ist - okay, wir werden sie nicht beschreiben. Es ist jedoch wichtig, sich nicht zu vergessen und zu testen.

Bild

zum Beispiel

  • Der Fragebogen sollte eine Datei mit einem Foto enthalten, da bei der Verarbeitung von Dokumenten ein Foto erforderlich ist - dies ist eine geschäftliche Anforderung . Und vielleicht eine Geschäftsregel.
  • - , — . , .
  • , — , . , .
  • base64 . — .
  • , . : 10.

Für jede Geschäftsanforderung gibt es in der Regel mehrere Benutzeranforderungen. Eine Benutzeranforderung wird in eine Reihe von funktionalen Anforderungen zerlegt. Für jede funktionale Anforderung müssen nicht funktionale Anforderungen und Einschränkungen berücksichtigt werden.

Nicht funktionale Anforderungen und Einschränkungen können sich auch direkt aus Benutzeranforderungen und Geschäftsanforderungen und -regeln ergeben.
Auf diese Weise werden Bäume aus Anforderungen erhalten, an deren Spitze jeweils eine Geschäftsanforderung steht.

Bild

4. Wann?


Im „Wald“ Ihrer Anforderungen gibt es wahrscheinlich alle sich gegenseitig ausschließenden und sich wiederholenden. Daher ist es nützlich, all diese Schönheit in Form von Tabellen und Diagrammen zu dokumentieren und darzustellen.

Hier gibt es viele Tools: Zum Beispiel BPMN zur Beschreibung von Geschäftsprozessen und UML zum Erstellen von Interaktionsschemata zwischen Services und Komponenten.

Wenn Sie es schaffen, allen zu erklären, was und wie Sie mit dem System tun möchten, indem Sie eine Serviette und 3 Kaffeeflecken verwenden, dann sind Sie John Wick von Analytics und das ist erstaunlich.

Bild

In der Regel können Sie jedoch aufgrund der Detailgenauigkeit "Spot" nicht die Fallstricke erkennen und alle möglichen Szenarien durchdenken. Immerhin scheint alles klar zu sein, aber ich habe ein kleines Diagramm gezeichnet - und hier haben Sie eine endlose Herausforderung, einen vergessenen Prozesszweig und den kürzesten Weg zum Gold.
Daher ist es hilfreich zu wissen, welche Tools verfügbar sind, um das Chaos umzukehren.

In einer schematischen und strukturierten Form müssen die Anforderungen priorisiert werden - abhängig vom Dienstprogramm (der Kunde und die Benutzer werden Ihnen dies mitteilen) und der Komplexität (das Entwicklungsteam wird Ihnen dies mitteilen).

Bild

Und dann können Sie sich bereits auf Sprints / Entwicklungs- und Implementierungsphasen konzentrieren. Wiederholen Sie diese Übungen in jeder Iteration. Und Sie werden glücklich sein - keine Veränderungen, ein zufriedener Kunde, ein glückliches Team, ein Produkt, das funktioniert und Vorteile bringt. Die Elfen spielen die Harfe auf einem Regenbogenhintergrund.

Bild

Natürlich wird es immer Probleme geben. Es wird Änderungen, verbrannte Fristen und Fehler geben. Es wird nicht immer möglich sein, alle Phasen zu durchlaufen und normale Analysen durchzuführen, zuzustimmen oder sogar nur mit dem Kunden zu sprechen, die Anforderungen zu dokumentieren und zu verfolgen. In jeder Situation hilft das Verständnis, wie es sein sollte, das Produkt besser zu machen. Selbst wenn Sie im Moment „wie es sich herausstellt“ tun, sind Sie sich bewusst, dass Sie etwas verpassen, und Sie kennen die Risiken. Und wenn Sie die Risiken kennen, können Sie sie verwalten.

Ich empfehle, mehr über Anforderungen im Buch von Wigers und Beatty zu lesen: „Entwicklung von Softwareanforderungen“. Das Buch ist zwar nicht immer einfach, aber sehr nützlich. Das meiste andere Material zu diesem Thema ist eine Nacherzählung dieser Wahrheiten mit unterschiedlichen Freiheitsgraden.

Vielen Dank für Ihre Aufmerksamkeit und Ihr gutes Design.

More articles:


All Articles