Wie können Anforderungsdokumente ordnungsgemäß erstellt werden?

Im Moment erstellt mein Vorgesetzter mit Hilfe von Bugtracking-Software Anforderungsdokumentationen / -spezifikationen für mich. Dies scheint mir eine schreckliche Idee zu sein, alle Anforderungen sind an diese kleinen Tickets gestellt und ich muss mich auf diesem blöden Webformular umsehen, um die Anforderungen zu erfüllen. Was ist eine vernünftige Softwarelösung für Anforderungen / Softwarespezifikationen?

Um es klar zu sagen, ich erstelle diese große Softwarekomponente mit einigen Funktionen, und diese Funktionen werden in dieser Bugtracking-Software beschrieben.

Ich bin ziemlich überrascht, dass bisher niemand die Verwendung eines Wikis zur Nachverfolgung von Anforderungen empfohlen hat .

Ich habe festgestellt, dass es ein nahezu perfektes System ist, weil:

• Sie ermöglicht es den Mitarbeitern, an den Anforderungen zusammenzuarbeiten, und macht diesen Aspekt in hohem Maße sichtbar.
• Es ermöglicht Ihnen, die Anforderungen während des Projektfortschritts auf einfache Weise auf dem neuesten Stand zu halten.
• Sie können jederzeit in die Geschichte schauen, falls es sich um einen Streit handelt, dem wir nicht zugestimmt haben.
• Die meisten modernen Wikis verfügen über angemessene Formatierungsfunktionen, sodass sie fast so gut aussehen wie ein Word-Dokument.
• Sie können direkt von Ihren Anforderungen in die eigentliche Dokumentation verlinken.
• Sie müssen sich nie Sorgen machen, dass andere / überholte Kopien erstellt werden.
• Anforderungen können wie Design / Implementierung als iterativer Prozess behandelt werden.
• Wenn die Anforderungen sehr umfangreich / kompliziert werden, können sie leicht auf mehrere Seiten / Themen aufgeteilt werden.
• Die meisten Wikis akzeptieren HTML. Wenn Sie also eine erweiterte Formatierung benötigen, können Sie wahrscheinlich ein Tool wie Windows Live Writer verwenden .

Wenn ich die Wahl habe, wähle ich heutzutage fast immer die Wiki-Methode. Im Vergleich zu den altmodischen Word-Dokumenten oder dem Versuch, alles in einen Bug-Tracker zu packen, ist das ziemlich schmerzlos.

Ich verwende immer IEEE Std 830-1998 (IEEE Recommended Practice für Software Requirements Specifcations) als Vorlage für mein SRS-Dokument. Siehe http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html

Das endgültige SRS-Dokument selbst ist normalerweise ein einzelnes OpenOffice.org-Dokument, es enthält jedoch normalerweise viele Bestandteile, einschließlich Tabellenkalkulationen und Diagrammen.

Normalerweise füge ich all diese Dokumente in einem Repository zusammen, das ich in ein Revisionskontrollsystem wie SVN oder CVS einbaue. Alle anderen Geschäftsanalysten, Designer, Entwickler, Tester, Projektmanager und Kunden haben Zugriff auf dieses Repository, damit sie es lesen und bearbeiten können.

Denken Sie daran, das SRS ist ein lebendiges, sich entwickelndes Dokument. Es wird sich für einige Zeit weiter verändern und wachsen. Es ist nicht nur wichtig, dass alle Stakeholder Zugriff auf den SRS haben, sondern auch, dass ein vollständiger Verlauf der Änderungen vorliegt und dass diese Änderungen bei Bedarf auch rückgängig gemacht werden können. Daher eignet sich ein Revisionskontrollsystem hervorragend für diesen Zweck. Viel Glück!

Die Verwendung des Bug-Trackers für das Anforderungsmanagement hat die Tendenz, die mangelnde Zusammenarbeit und Kommunikation innerhalb des Unternehmens zu verbergen .

Ohne eine bestimmte Methode zu beurteilen:

• Wenn Sie Wasserfall verwenden möchten, benötigen Sie gut strukturierte, genaue, mehrseitige Dokumente (nicht einen Absatz, den viele Leute normalerweise als Fehlerbeschreibung eingeben). Es ist auch unmöglich, diese Dokumente zu verfassen und auf einem angemessenen Qualitätsniveau zu halten, wenn Marketing- / Vertriebsmitarbeiter (die die Anforderungen erstellen) nicht gut mit dem technischen Personal zusammenarbeiten.
• Wenn Sie eine der agilen Methoden verwenden, ist eine der Anforderungen eine User Story, die durch eine Story Card dargestellt wird. Die Karte selbst ist keine Voraussetzung, nur ein Ausgangspunkt des Gesprächs.

Eine (kurze) Erfahrung meines früheren Arbeitgebers mit der Verwendung eines Bug-Trackers für Anforderungen war, dass es vielen Menschen sehr leicht fiel, die Kommunikation vollständig zu beenden. Die Leute würden einfach einen Wunsch schreiben, ihn in den Bug-Tracker werfen und annehmen, dass er irgendwann in Erfüllung gehen würde.

Natürlich taten sie dies ohne Rücksicht auf:

• ihre eigenen Qualifikationen
• ihre Beteiligung an dem Projekt
• kollidiert mit anderen Anforderungen
• Lücken in den Anforderungen
• Kosten
• irgendwelche technischen Überlegungen
• etc.

Ich glaube, dass "Word" -Dokumente aus den folgenden Gründen die falsche Vorgehensweise für Anforderungen sind:

1. Es ist nicht möglich, zwei Dokumente zu "unterscheiden", um zu sehen, was sich geändert hat.
2. Die Benutzeroberfläche rät davon ab, durchgehend einen einheitlichen Stil zu verwenden. Ja, Stile können verwendet werden, aber die meisten Leute können sich wegen der Schwierigkeit nicht darum kümmern.
3. Das Dokumentformat ist im Wesentlichen verborgen. Sicher, es gibt eine Spezifikation für OLE-Dateien, die meiner Meinung nach "Word" -Dokumente sind, aber Microsoft hat alles Nützliche unter Tonnen von Blather verborgen, sodass niemand wirklich Bescheid weiß. Früher oder später öffnet Ihr glänzendes, neues "Word" das Dokument nicht.
4. Spielt nicht gut mit anderen Formaten. Das heißt, wenn Sie nicht Windows und IE verwenden, haben Sie Pech, wenn jemand die Dokumente eines Projekts in HTML-Dateien mit Links zu Dateien im "Word" -Format organisiert. Klicken Sie auf den falschen Link, und Sie müssen eine lange Lade- und Startphase von Word durchstehen, um den Gedankenfluss zu unterbrechen. Hyperlinks von "Word" -Dokumenten zu anderen funktionieren möglicherweise nicht.
5. "Word" ist im Grunde genommen zum Schreiben von Dokumenten gedacht, die auf Papier erscheinen sollen. Ein bewundernswertes Ziel, das jedoch für die Online-Anzeige weniger als nützlich ist.

Ich habe keinen alternativen Vorschlag, mit dem ich Erfahrung habe, aber ich habe über Pythons reStructured Text oder Markdown als Alternativen nachgedacht.

Wir verwenden im Allgemeinen Word, aber in Wirklichkeit ist es weniger wichtig, wie Sie sie in Software erstellen, als wie Sie die Daten sammeln, um sie zu erstellen, und ob die Person, die die Informationen sammelt, genug weiß, um zu wissen, wann eine Anforderung übermäßig kompliziert und weitaus teurer ist als Eine einfachere Anforderung bietet noch keinen wirklichen Mehrwert für jemanden (z. B. wenn ID-Nummern immer in der Reihenfolge zugewiesen werden sollen, in der keine übersprungen wird) oder wenn ein Konflikt mit einer vorhandenen Anforderung oder einer anderen geplanten Funktion auftritt. Oft werden die tatsächlichen Benutzer nie angesprochen, und es gibt viele Überraschungen, wenn ihre Manager nichts wussten, was unbedingt getan werden musste, und es sich nicht um die neue Version der Software handelt.

Wir können auch verschiedene PDF-, Excel- oder Visio-Dateien verwenden. Sie werden alle für das Projekt aus SharePoint gesammelt und bearbeitet, sodass wir bei Bedarf frühere Versionen sehen können.

Ich führe ein Produkt-Backlog (eines pro Projekt oder Produkt), das User Stories enthält . Sie können in einer Bug-Tracking-Software wie der von Ihnen verwendeten gespeichert werden. Ich persönlich verwende Excel für das Backlog und Trac für das Sprint-Backlog (wahrscheinlich verwenden Sie ein Tool wie dieses).

Nur bei Bedarf erstelle ich ein Word-Dokument , das die User Story ausführlicher beschreibt, und hänge es an die User Story an. Aber ich versuche dies zu vermeiden, indem ich die User Story in kleinere aufspalte.

Kleine User Stories sind einfacher zu verwalten (einschließlich Schätzungen)

Ich mag das Word-Dokument, weil es mir erlaubt, Links zu platzieren, Texte zu formatieren, Tabellen, Screenshots und mehr zu platzieren, und jeder kann es lesen.

Natürlich wird jede User Story in der Schätzungssitzung und in der Sprint-Planung ausführlich erklärt, und ich stehe jederzeit für weitere Fragen zur Verfügung, wenn sich der Entwickler entscheidet, daran zu arbeiten. Häufige Rückmeldungen mit der Sprint-Überprüfung verhindern, dass Entwickler etwas anderes tun, als vom Produktbesitzer gewünscht.

Persönlich habe ich in der Vergangenheit Word-Dokumente verwendet, mich aber entschlossen, in Zukunft ein Tool zu finden, um dies für mich zu verwalten ... insbesondere mit der Fähigkeit, Fehler an die Anforderungen anzupassen, da dies häufig der Fall ist Bei den Anforderungen nicht die Abweichung zwischen Spezifikation und Implementierung.

Es ist mir noch nie in den Sinn gekommen, ein Bug-Tracking-Tool zu verwenden, aber es ist absolut sinnvoll.

Was gefällt dir aus Neugier nicht?

EDIT: eine Einschränkung; Weisen Sie Ihren Manager an, die Fehlerverfolgungssoftware umzubenennen. Ansonsten wird davon ausgegangen, dass alles ein Fehler ist. Ich hatte dieses politische Problem bei meinem letzten Kunden, wo ich Aufgaben in den Bug Tracker gestellt habe. Nicht gut.

Ich habe vor 6 oder 7 Jahren eine Anforderungsdatenbank geschrieben, um damit umzugehen. Jeder Anforderungsdatensatz enthält eine kurze Beschreibung, ein "Definitions" -Notizbuch und ein "Notizen" -Notizbuch (beide Rich-Text-Dateien, in die Screenshots usw. eingebettet werden können). Es gibt auch andere Felder für das Projekt, die Lieferbarkeit, die Sequenznummer (damit sie logisch bestellt werden können), den Anwendungsfall / die zugehörige Funktion, die Zeitschätzung, ein Feld für die Person, die es bearbeitet, falls jemand es zur Implementierung ausgewählt hat. etc.

Es gibt auch ein "Status" - "Eingegeben", während wir die Funktionen entwerfen; "Genehmigt": Wird festgelegt, sobald eine Gruppe von Anforderungen überprüft und als umsetzungsbereit eingestuft wurde. "Implementiert", vom Programmierer festgelegt, sobald die Anforderung erfüllt ist, und "Validiert", sobald der QA-Techniker mit dem Programmierer einverstanden ist. (Wenn der QA-Techniker nicht einverstanden ist, kann er ihn auf "Genehmigt" zurücksetzen, damit der Programmierer ihn zurückerhält.) Die Anforderungen können auch "Zurückgestellt", "Abgelehnt" oder "Befragt" sein (dh, die Änderungskontrollbehörde muss dies prüfen) .)

Der Trick, dies gut zu machen, ist eine vernünftige Granularität. Es kann manchmal sinnvoll sein, Anforderungen mit einem Satz zu haben (z. B. "Das in Problem 12345 beschriebene Problem ist behoben"), aber im Allgemeinen sollten Anforderungen alle wichtigen Aspekte eines ganzen Features (oder einen großen Teil von einem) beschreiben. Für eine typische Funktion "Neuer Bericht" ist beispielsweise ein Berichtsformat (wie die Ausgabe aussieht) und ein Optionsdialog (Erklären der Felder, Validierung usw.) erforderlich. Es kann sogar ein dritter vorhanden sein, wenn Es gibt einen komplexen Generator, der die Daten zerquetscht, anstatt nur eine einfache Abfrage oder so. Außerdem erstellen wir eine "Hilfe" -Anforderung für das entsprechende Hilfethema.

Es hat enorme Vorteile, dieses Zeug in Datenbankaufzeichnungen anstatt in einem großen Dokument zu speichern. Mehrere Programmierer können gleichzeitig an Anforderungen arbeiten. Einzelne Datensätze sind gesperrt, sodass jeweils nur eine Person sie bearbeiten kann. Sie können jedoch geöffnet und gelesen werden, während eine andere Person sie bearbeitet. Der größte Vorteil ist jedoch, dass die Dokumentation sowohl zu den Anforderungen als auch zu den Hinweisen zu deren Implementierung auf einfache Weise durchsucht werden kann. Wir haben jetzt über 25.000 Anforderungen und können alle Anforderungen mit bestimmten Wörtern in allen Feldern oder der Definition oder Notizen oder was auch immer in weniger als 10 Sekunden leicht finden. (Versuchen Sie das mit Word-Dokumenten im Wert von mehr als 6 Jahren.)

Ich kann verstehen, warum Leute sagen, dass es eine schlechte Idee ist, Anforderungen in einem "Bug-Tracker" zu erstellen, aber ich vermute, das liegt daran, dass die Tools nicht funktionieren, und nicht daran, dass das Speichern von Anforderungen in einer durchsuchbaren Datenbank eine schlechte Idee ist.

Ich habe einmal http://www.pivotaltracker.com/ verwendet, aber in meinem derzeitigen Unternehmen verwenden wir .doc als Kernspezifikationsquelle und Lighthouse als kombinierte Merkmalsliste und Problemverfolgung. Für mich ist es schwierig, andere Teammitglieder dazu zu bringen, andere Tools zu verwenden, wenn sie so sehr an Word gewöhnt sind.

Wenn Sie der Agile-Methodik folgen können, können Sie mithilfe der folgenden Links ein gutes Agile-Projektmanagement-Tool auswählen:

• Agile Projektmanagement-Tools
• Vergleich verschiedener Agile Project Management Tools

Und im Ernst, probieren Sie die Agile-Methode aus - sie predigt einen einfachen, eleganten, sachlichen, nicht jazzigen und sinnlichen Ansatz, sodass jedes Teammitglied die Rolle und den Einsatz jedes anderen Mitglieds versteht und schätzt.

Viel Glück!