Dokumentationsanforderungen: Kleinere Fehler, die große Probleme verursachen

Der Artikel richtet sich an Geschäfts- und Systemanalysten, die Anforderungen an Informationssysteme formulieren. Diese Informationen sind auch für Entwickler und andere Personen nützlich, die im Softwaregeschäft tätig sind. Der Artikel beschreibt die Bildung und Dokumentation von Anforderungen. Insbesondere wird der Fall berücksichtigt, wenn dem Analysten mitgeteilt wird: "Alle Ihre Anforderungen sind nutzlos, da sie dem Entwickler nicht erklären, was zu tun ist und vor allem warum . "

Wir werden den Prozess wie gewohnt analysieren. Der Analyst erhält eine Anfrage zur Änderung der Funktionalität in Form eines Tickets vom technischen Support, technischen Spezifikationen oder einer direkten Kundenbeschwerde. Das Wesentliche der Anfrage ist, dass dort etwas im System schlecht ist und Sie darüber nachdenken müssen, wie Sie es beheben können. Oder was hier auf diesem Bildschirm getan werden muss, ist eine weitere solche Möglichkeit. Oder die Notwendigkeit, „Anwender hat die Möglichkeit , es zu tun hier“ . Oft schreibt der Analyst die Anforderung einfach so in das Formular, wie es gekommen ist: In Form mehrerer Sätze oder einer User Story generiert er daraus eine Änderungsaufgabe (oder mehrere Aufgaben) und sendet sie an den Entwickler. Was dann passiert, wird im letzten Satz des vorherigen Absatzes beschrieben. Lassen Sie uns herausfinden, warum.


Problem Nummer 1. Was ist für den Entwickler unverständlich? Er versteht nicht, welche Bildschirme im System geändert werden müssen, welche Schaltflächen, Felder, Registerkarten und APIs usw. finalisiert / erstellt werden müssen, um die Kundenanforderungen zu erfüllen. Was vom Analysten kommt, sind die funktionalen Anforderungen , und der Entwickler benötigt eine funktionale Spezifikation (andere Namen: Implementierung, Design) mit einer detaillierten Beschreibung der erforderlichen Änderungen. Anstatt beispielsweise die Funktionalität mit Details der Ebene

„Wenn der Benutzer die Schaltfläche OK drückt, wird das Dialogfeld geschlossen und das Hauptfenster, das vor dem Erscheinen des Dialogfelds angezeigt wurde“ zu beschreiben, steht der Fokus im Fokus. (Funktionsspezifikation) Der

Entwickler erhält eine Beschreibung mit Leveldetails

„Der Benutzer sollte in der Lage sein, das Dialogfeld zu schließen und zum Hauptfenster zurückzukehren“ (Funktionsanforderung).

In der letzten Beschreibung gibt es keine 2 Implementierungsdetails:
* Das Fenster wird geschlossen, wenn Sie auf OK klicken.
* Der Fokus kehrt automatisch zum Hauptfenster zurück.


Selbst wenn der Entwickler diese fehlenden Details unabhängig überlegt, führt das Fehlen im Text der ursprünglichen Aufgabe zu Problemen. Beispielsweise versteht der Tester nicht, was im Rahmen dieser Aufgabe zu überprüfen ist. In solchen Fällen rufen die Tester in der Regel die Entwickler an und fragen, was genau getan wurde.als Teil dieser Aufgabe. Um das genaue Verhalten dieser Funktionalität in Zukunft zu bestimmen, z. B. wenn ein Defekt (Fehler) auftritt oder wenn Änderungen erforderlich sind, müssen Entwickler den Quellcode dieser Revision untersuchen, „ wo alles richtig funktioniert hat “, und Tester, um den geeigneten Testfall zu finden. All dies ist mit zusätzlichen Zeitkosten verbunden, verglichen mit einem einfachen Lesen der Funktionsspezifikation, die vom Analysten in der ursprünglichen Aufgabe festgelegt werden könnte.

Viele Analysten beschreiben die Funktionsspezifikation nicht wissentlich und sind nur durch die Anforderungen eingeschränkt, da sie dem Entwickler die Freiheit geben möchten, eine Lösung zu wählen. Und viele Entwickler verlangen sogar (!), Dass die Aufgabe keine Implementierungsdetails enthält und dass sie die Freiheit haben, genau zu wählen, wie die funktionale Anforderung implementiert werden soll. Dafür gibt es zwei Gründe: 1) den Wunsch des Entwicklers, zu wissen, warum überhaupt etwas geändert werden soll; 2) das Vorhandensein mehrerer Möglichkeiten zur Implementierung derselben funktionalen Anforderung im System, von denen der Analyst (aufgrund von reinem Pech) nicht die einfachste gewählt hat. Es gibt auch einen dritten Grund, das eigene Ego des Entwicklers, aber in diesem Artikel werden wir dies nicht diskutieren. Der erste Grund, der „Wunsch zu wissen warum“, wird unten diskutiert. Was ist mit der zweiten zu tun? Es wird empfohlen, die Hauptpunkte der Funktionsspezifikationen mit dem Entwickler zu besprechen. Und wenn möglich, korrigieren Sie die Spezifikation im Text der Aufgabe. Wenn keine Gelegenheit zur Diskussion besteht (z. B. wenn sich die Entwickler innerhalb von 10 Zeitzonen von Ihnen oder im Vertragsunternehmen befinden), müssen Sie die Spezifikation in der Aufgabe noch notieren und erst dann zur Genehmigung an den Entwickler senden. Die Effektivität dieses Ansatzes wird höher sein, da die Zeit, die der Analyst für das anschließende Umschreiben der Aufgabe benötigt, immer noch geringer ist als die Zeit, die mehrere Personen für das Herausfinden des genauen Verhaltens des Systems aufwenden, da die Spezifikation in der Aufgabe nicht spezifiziert ist. und erst dann zur Genehmigung an den Entwickler senden. Die Effektivität dieses Ansatzes wird höher sein, da die Zeit, die der Analyst für das anschließende Umschreiben der Aufgabe benötigt, immer noch geringer ist als die Zeit, die mehrere Personen für das Herausfinden des genauen Verhaltens des Systems aufwenden, da die Spezifikation in der Aufgabe nicht spezifiziert ist. und erst dann zur Genehmigung an den Entwickler senden. Die Effektivität dieses Ansatzes wird höher sein, da die Zeit, die der Analyst für das anschließende Umschreiben der Aufgabe benötigt, immer noch geringer ist als die Zeit, die mehrere Personen für das Herausfinden des genauen Verhaltens des Systems aufwenden, da die Spezifikation in der Aufgabe nicht spezifiziert ist.

Oft stellt sich die Frage, ob der Analyst die Datenbankanforderungen in der Aufgabe beschreiben soll, z. B. die Struktur von Tabellen, Feldnamen usw.? Die kurze Antwort lautet nein. Der Analyst sollte nur den Teil der Software angeben, der für den Benutzer sichtbar ist. Dies sind die Benutzeroberfläche, öffentliche APIs und sichtbare Hardwareparameter wie die Monitorgröße. Ja, in diesem Artikel geht es um Software, aber da fast niemand sie in ihrer „reinen“ Form verwendet und der Benutzer immer über eine Geräteebene mit dem Programm interagiert, müssen die akzeptablen Parameter dieser Ebene in der Anforderungsspezifikation angegeben werden.

Ein weiterer häufiger Fehler von Analysten und Entwicklern ist die Beschreibung der Implementierungsdetails (tatsächlich der Funktionsspezifikation) in Kommentaren zur Aufgabe. Darüber hinaus werden häufig mehrere Kommentare für dieselbe Funktionalität erstellt (dies wird als Diskussion bezeichnet). Sollte ich aus diesem Grund überhaupt keine Kommentare verwenden? Natürlich nicht, aber Zwischenvereinbarungen über Funktionsspezifikationen und insbesondere endgültige sollten genau im Text des Problems und nicht anderswo festgelegt werden. Und wieder erwähnen wir, dass der beste Weg, um zuzustimmen, darin besteht, den Entwickler weiterhin anzurufen und die wichtigsten Details mit einer Stimme zu besprechen und sie erst dann in der Aufgabe aufzuschreiben.

Problem Nummer 2. Warum ist dem Entwickler unklar, warum ? Weil das Problem fehlt, was heißtEine Geschäftsanforderung (andere Namen: Problem oder Problemstellung ) oder, noch häufiger, aus der Beschreibung der Geschäftsanforderung ist das anfängliche Problem des Benutzers immer noch nicht klar, da sich die Beschreibung selbst eher auf die Software selbst als auf das Geschäft oder die Situation des Benutzers bezieht. Ein Beispiel für eine unverständliche Beschreibung des Problems:

„In den Systemverzeichnissen ist das Feld„ Englischer Name “implementiert, das Feld wurde jedoch nie ausgefüllt. Das Vorhandensein von leeren Feldern in den Verzeichnissen passt nicht zum Kunden, weil zeigt die Irrelevanz von Nachschlagewerken an . "

Nun, irrelevante Verzeichnisse, na und? Wer leidet darunter? Nachdem Sie einige zusätzliche Informationen gesammelt haben, können Sie das Problem besser beschreiben:

„Client-Administratoren verbringen zusätzliche Zeit damit, die Relevanz von Klassifizierern zu überwachen, die in Form von Verzeichnissen dargestellt werden. Dies ist auf das Vorhandensein zusätzlicher Felder in der Liste der Verzeichniselemente zurückzuführen, über die nicht klar ist, ob sie ausgefüllt werden sollen oder nicht. “

Was hat sich geändert? Erstens wurde es offensichtlich, dass bestimmte Personen ein Problem haben (Administratoren). Zweitens wurde die Messung des Problems (aufgewendete Zeit) klar. Wenn Sie immer noch wissen, wie oft Klassifizierer überwacht werden (zusätzliche Zeit wird verschwendet), können Sie bereits die Priorität des Problems (und der Aufgabe) bestimmen. Und wenn Sie immer noch erklären, warum Klassifikatoren im Allgemeinen relevant sein sollten, erhalten Sie eine sehr perfekte Beschreibung.

Die Beschreibung des Problems wird auch als „Problemstellung“ bezeichnet (siehe den obigen Link), und obwohl Goldsmith bis zu 6 Schritte auflistet, um es zu bestimmen, ist es sinnvoll, es auf nur 3x zu vereinfachen:
Schritt 1. Beschreibung der Benutzerkategorie;
Schritt 2. Definition und Beschreibung der Geschäftsaufgabe des Benutzers, die entweder nicht gelöst werden kann oder zusätzliche Zeit / Geld erfordert oder eine Bestrafung für Gesetzesverstöße nach sich zieht;
Schritt 3. Beschreibung des Mangels an Software, mit der ein Geschäftsproblem nicht gelöst werden kann.

Genau dieses Verfahren zur Beschreibung des Problems wird empfohlen, da niemand zusätzliche Wörter lesen möchte - eine Beschreibung der Software.

Abschließend möchte ich diese Probleme zusammenfassen und darauf hinweisen, was der Analyst bei der Dokumentation der Anforderungen Zeit verbringen sollte und was nicht. Nur zwei Dinge sind entscheidend: Dokumentation des Benutzerproblems und Dokumentation der Funktionsspezifikation der Änderungen. Diese beiden Punkte sollten in jeder Aufgabe für Entwickler und Tester vorhanden sein. Dies löst garantiert das am Anfang des Artikels angesprochene Problem.

Für alle anderen Aktivitäten zum Verwalten und Dokumentieren von Anforderungen, wie z. B. funktionale und nicht funktionale Anforderungen, User Stories, Anwendungsfälle, muss die Zeit minimiert werden, da nichts davon die wichtigsten Dinge erklärt: 1) was genau zu entwickeln / zu testen ist, 2) welche von Benutzer werden von diesen Aktionen profitieren und was ist sein Problem im Moment. Funktionale Anforderungen sind erforderlich, wenn es gemäß der Beschreibung des Problems (gemäß den Geschäftsanforderungen) aufgrund seines Umfangs unmöglich ist, die funktionale Spezifikation zur Lösung des Problems abzudecken. Als Ergebnis wird eine dazwischenliegende, kompaktere Anforderungsschicht erstellt, die letztendlich zum Auftreten einer Spezifikation führt. Da diese Anforderungsschicht jedoch mittelschwer ist, ist es ratsam, sie zu überspringen - was Zeit spart.

PS Eine Vorlage zur Beschreibung einer Aufgabe in JIRA.Aufgaben (aber keine Fehler) werden gemäß den folgenden Vorlagen für die Felder Zusammenfassung , Problem , Beschreibung ausgegeben . Alle 3 Felder sind erforderlich.

Zusammenfassung :
<Der Name der Aufgabe. Anstelle der allgemeinen Wörter "Revision", "Ändern", "Aufgabe ein" wird empfohlen, die spezifische Aktion anzugeben, die in der Aufgabe ausgeführt wird, oder die wichtigste von mehreren Aktionen>

Problem :
<Beschreibung des Problems: Benutzer, Unmöglichkeit / Komplexität der Implementierung einer Geschäftsaufgabe / eines Geschäftsprozesses mittels Software oder Inkonsistenz zwischen einer Geschäftsaufgabe und Software>.

Beschreibung :
<optional> Wobei : <Eine genaue Beschreibung des Verfahrens, mit dem ein Benutzer auf den Softwarebildschirm zugreifen kann, auf dem Änderungen erforderlich sind>.

<Eine genaue Beschreibung aller Änderungen an der Software, die für den Benutzer sichtbar sind. Ohne die Details des Geschäftsprozesses und die Gründe zu erwähnen, warum Änderungen erforderlich sind>

<optional> Implementierungsaufgabe :
<Eine genaue Beschreibung aller Konfigurationseinstellungen in der Software, einschließlich der für den Benutzer unsichtbaren, die nach der Freigabe der Änderungen durchgeführt werden müssen. Zum Beispiel ein Skript ausführen oder Verzeichnisse einrichten>

Jetzt auch beliebt: