Was ist der richtige Weg, um Anforderungsdokumente zu erstellen?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/9371

Frage

Derzeit erstellt mein Supervisor Anforderungen Dokumentation / Spezifikationen für mich mithilfe von Bugtracking -Software. Dies scheint mir eine schreckliche Idee zu sein, alle Anforderungen sind an diesen kleinen Tickets und ich muss auf diese dumme Webform klicken, um die Anforderungen zu erhalten. Was ist eine vernünftige Softwarelösung für Anforderungen / Software -Spezifikationen?

Um klar zu sein, baue ich diese große Softwarekomponente mit einigen Funktionen auf und diese Funktionen werden in dieser Bugtracking -Software festgelegt.

War es hilfreich?

Lösung

Ich bin ziemlich überrascht, dass bisher niemand die Verwendung von a empfohlen hat Wiki für die Verfolgung von Anforderungen.

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

  • Es ermöglicht den Menschen, an den Anforderungen zusammenzuarbeiten, und macht diesen Aspekt sehr sichtbar.
  • Es ermöglicht Ihnen, die Anforderungen im Laufe des Projekts auf dem neuesten Stand zu halten.
  • Sie können die Geschichte jederzeit betreten, wenn ein Streit "das ist nicht das, was wir zustimmten";
  • Die meisten modernen Wikis verfügen über anständige Formatierungsfunktionen, so dass es fast so gut aussieht wie ein Wort doc.
  • Sie können direkt von Ihren Anforderungen in die tatsächliche Dokumentation hyperlink werden.
  • Sie müssen sich nie darum kümmern, dass Menschen mit verschiedenen/veralteten Kopien arbeiten.
  • Die Anforderungen können als iterativer Prozess behandelt werden, genau wie Design/Implementierung.
  • Wenn die Anforderungen wirklich groß/kompliziert werden, ist es einfach, sie über Seiten/Themen aufzuteilen.
  • Die meisten Wikis akzeptieren HTML. Wenn Sie also wirklich erweiterte Formatierung benötigen, können Sie wahrscheinlich ein Tool wie verwenden Windows Live Writer.

Angesichts der Entscheidung wähle ich heutzutage fast immer die Wiki-Methode aus. Es ist im Vergleich zu den altmodischen Wortdokumenten oder dem Versuch, alles in einen Bug-Tracker zu packen, sehr schmerzlos.

Andere Tipps

Ich verwende IEEE STD 830-1998 (IEEE empfohlene Praxis für Softwareanforderungen) als Vorlage für mein SRS-Dokument. Sehen http://standards.ieee.org/reading/ieee/std_public/decription/se/830-1998_desc.html

Das endgültige SRS -Dokument selbst ist in der Regel ein einzelnes OpenOffice.org -Dokument, aber es gibt normalerweise viele Bestandteile, einschließlich Tabellenkalkulationen und Diagramme.

Normalerweise stelle ich all diese Dokumente in einem Repository zusammen, das ich in a eingebaut habe Revisionskontrollsystem, wie SVN oder CVS. Alle anderen Geschäftsanalysten, Designer, Entwickler, Tester, Projektmanager und Kunden Haben Sie Zugriff auf dieses Repository, damit sie es lesen und Änderungen vornehmen können.

Denken Sie daran, das SRS ist ein lebendiges, sich entwickeltes Dokument. Es wird sich weiter verändern und für einige Zeit wachsen. Es ist nicht nur für alle Beteiligten wichtig, Zugang zu den SRS zu haben, sondern es ist auch wichtig, eine vollständige Geschichte der Änderungen zu haben, und die Fähigkeit, diese Änderungen bei Bedarf zu rollen. Ein Revisionskontrollsystem funktioniert also für diesen Zweck hervorragend. Viel Glück!

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

Ohne ein Urteil über eine bestimmte Methode zu bestehen:

  • Wenn Sie Wasserfall verwenden, benötigen Sie gut strukturierte, genaue, mehrseitige Dokumente (nicht ein Absatz, den viele Personen normalerweise als Fehlerbeschreibung eingeben). Diese Dokumente sind auch unmöglich zu schreiben und auf einem angemessenen Qualitätsniveau zu warten, wenn Marketing/Verkäufer (die die Anforderungen stammen) nicht gut mit dem technischen Personal zusammenarbeiten.
  • Wenn Sie eine der agilen Methoden verwenden, ist eine Anforderungeneinheit eine Benutzergeschichte, die durch eine Story -Karte dargestellt wird. Die Karte selbst ist keine Voraussetzung, sondern nur ein Ausgangspunkt des Gesprächs.

Eine (kurze) Erfahrung eines meiner früheren Arbeitgeber mit einem Bug-Tracker für Anforderungen bestand darin, dass es vielen Menschen eine sehr einfache Möglichkeit gab, nicht mehr zu kommunizieren. Die Leute würden einfach einen Wunsch schreiben, ihn in den Bug-Tracker fallen lassen und annehmen, dass er irgendwann wahr werden würde.

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

  • ihre eigenen Qualifikationen
  • ihre Beteiligung an dem Projekt
  • Konflikte mit anderen Anforderungen
  • Anforderungen Lücken
  • Kosten
  • technische Überlegungen
  • usw.

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

  1. Keine Möglichkeit, zwei Dokumente zu "diff", um zu sehen, was sich geändert hat.
  2. Die Benutzeroberfläche nimmt durch, um einen konsistenten Stil durchgehend zu verwenden. Ja, Styles kann getan werden, aber die meisten Menschen können aufgrund der Schwierigkeit nicht gestört werden.
  3. Das Dokumentformat ist im Wesentlichen versteckt. Sicher, es gibt eine Spezifikation für OLE -Dateien, die "Wort" -Dokumente sind, aber Microsoft hat unter Tonnen von Blather alles begraben, was nützlich ist, also weiß niemand es wirklich. Früher oder später wird Ihr glänzendes, neues "Wort" das Dokument nicht öffnen.
  4. Spielt nicht gut mit anderen Formaten. Das heißt, es sei denn, Sie verwenden Windows und dh, haben kein Glück, wenn jemand die Dokumente eines Projekts in HTML -Dateien mit Links zu "Wort" -Formatdateien organisiert hat. Klicken Sie auf den falschen Link, und Sie müssen eine lange Download- und Start-Word-Periode durchsetzen, um den Gedankenfluss zu unterbrechen. Hyperlinks von "Wort" -Dokumenten zu anderen können funktionieren oder nicht.
  5. "Wort" ist im Grunde genommen zum Schreiben von Dokumenten, die auf Papier erscheinen sollen. Ein bewundernswertes Ziel, aber eines, das es für die Online-Anzeige weniger nützlich macht.

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

Wir verwenden im Allgemeinen Word, aber in Wirklichkeit, wie Sie sie in Software erstellen, ist weniger wichtig als wie Sie die Daten sammeln, um sie zu erstellen, und ob die Person, die die Informationen sammelt Eine einfachere Anforderung, aber niemandem zu einem wirklichen Wert hinzugefügt (z. B. wenn sie ID -Nummern immer in der Reihenfolge zugewiesen werden, ohne jemals übersprungen zu werden) oder wenn sie mit einer vorhandenen Anforderung oder einer anderen geplanten Funktion in Konflikt steht. Oft werden die tatsächlichen Benutzer nie gesprochen und es gibt viele Überraschungen, wenn ihre Manager nichts wussten, was absolut getan werden musste, und es ist nicht in der neuen Version der Software.

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

Ich unterhalte einen Produktrücken (eines pro Projekt oder Produkt), der enthält Benutzergeschichten. Sie können in Fehlerverfolgungssoftware wie die, die Sie verwenden, gespeichert werden. Ich benutze Personnaly Excel für den Rückstand und Trac Für den Sprint -Rückstand (Sie verwenden wahrscheinlich ein Tool wie dieses Tool).

Wenn nur erforderlich, erstelle ich eine Word-Datei Dadurch werden die Benutzergeschichte mit weiteren Details beschrieben und der Benutzergeschichte verbunden. Aber ich versuche dies zu vermeiden, indem ich die Benutzergeschichte in kleinere Aufteilungen aufteile.

Kleine Benutzergeschichten sind einfacher zu verwalten (einschließlich Schätzung)

Ich mag das Word -Dokument, weil ich es ermöglicht, Links, Formate von Texten, Tabellen, Screenshots und mehr zu setzen, und jeder kann es lesen.

Natürlich wird jede Benutzergeschichte in der Schätzungssitzung und in der Sprintplanung ausführlich erläutert, und ich bin immer für weitere Fragen verfügbar, wenn der Entwickler entscheidet, daran zu arbeiten. Häufige Feedbacks mit Sprint -Überprüfung verhindern Entwickler daran, etwas anders zu tun als vom Produktbesitzer angefordert.

Persönlich habe ich in der Vergangenheit Word -Dokumente verwendet, aber beschlossen, in Zukunft ein Tool zu finden, um dies für mich zu verwalten ... insbesondere mit der Möglichkeit, Fehler auf Anforderungen festzulegen, da der Fehler viel Zeit ist, ist der Fehler In den Anforderungen nicht die Abweichung zwischen Spezifikationen und Implementierung.

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

Was ist aus Neugier, was Ihnen nicht gefällt?

Bearbeiten: eine Einschränkung; Sagen Sie Ihrem Manager, er solle die Fehlerverfolgungssoftware für Fehler umbenennen. Ansonsten wird angenommen, dass alles darin ein Fehler ist. Ich hatte dieses politische Problem bei meinem letzten Klienten, bei dem ich Aufgaben in den Bug -Tracker einsetzte. Nicht gut.

Ich habe vor 6 oder 7 Jahren eine Anforderungsdatenbank geschrieben, um dies zu behandeln. Jedes Anforderungsprotokoll enthält eine kurze Beschreibung, ein "Definition" -Memo und ein "Notizen" -Memo (beide reichhaltiger Text mit Fähigkeit, Screenshots usw. einzubetten). Es gibt auch andere Felder, für Projekte, lieferbare Sequenznummer (damit sie logisch bestellt werden können), Anwendungsfall/Feature, mit der es in Bezug auf Zeitschätzung ein Feld für die Person bezieht, wenn jemand es zur Implementierung ausgewählt hat. usw.

Es gibt auch einen "Status" - "eingegeben", denn während wir die Funktionen entwerfen; "Genehmigt", festgelegt, sobald eine Gruppe von Anforderungen überprüft und entschlossen ist, umzusetzen. "Implementiert", vom Programmierer festgelegt, sobald er der Meinung ist, dass die Anforderungen erledigt sind, und "validiert", sobald die QA -Technologie dem Programmierer zustimmt. (Wenn die QA -Technologie nicht einverstanden ist, kann er es wieder auf "genehmigt" einstellen, damit der Programmierer es zurückholt.) Anforderungen können auch "verschoben", "abgelehnt" oder "befragt" werden (dh die Change Control Board muss es sich ansehen müssen .))

Der Trick, dies gut zu machen, ist eine vernünftige Granularität. Es kann manchmal sinnvoll sein, einen Satzanforderungen zu haben (z. "Das in Ausgabe 12345 beschriebene Problem ist festgelegt"), aber im Allgemeinen sollten die Anforderungen alle wichtigen Aspekte eines ganzen Merkmals (oder einen großen Teil von einem) beschreiben. Beispielsweise hat eine typische Funktion "neuer Bericht" eine Anforderung für ein Berichtsformat (wie die Ausgabe aussieht) und eine Anforderung für den Optionsdialog (Erläuterung der Felder, Validierung usw.). Es kann sogar eine dritte geben, wenn Es gibt einen komplexen Generator, der die Daten knirscht, anstatt nur eine einfache Abfrage oder so. Darüber hinaus erstellen wir eine "Hilfe" -Notwendigkeit für das entsprechende Hilfsthema.

Es gibt enorme Vorteile, dieses Zeug in Datenbankdatensätzen zu halten, anstatt in einem großen Dokument. Mehrere Programmierer können gleichzeitig an den Anforderungen arbeiten. Einzelne Datensätze sind gesperrt, sodass nur eine Person gleichzeitig bearbeiten kann, aber sie können geöffnet und gelesen werden, während jemand anderes bearbeitet. Der größte Vorteil ist jedoch, dass es eine einfache Suchdokumentation sowohl der Anforderungen als auch der Anmerkungen darüber bietet, wie sie implementiert wurden. Wir haben jetzt über 25.000 Anforderungen und können in weniger als 10 Sekunden leicht alle Anforderungen mit spezifischen Wörtern in allen Feldern oder in der Definition, oder in den Anmerkungen oder was auch immer finden. (Versuchen Sie das mit Wortdokumenten im Wert von mehr als 6 Jahren.)

Ich kann sehen, warum die Leute sagen könnten, dass es eine schlechte Idee ist, Anforderungen in einem "Bug -Tracker" zu erfüllen, aber ich vermute, dass die Tools saugen, nicht weil die Aufbewahrung der Anforderungen in einer durchsuchbaren Datenbank eine schlechte Idee ist.

Ich habe einmal benutzt http://www.pivotaltracker.com/ Aber in meinem aktuellen Unternehmen verwenden wir .doc als Kernspezifikationsquelle und Leuchtturm als Combined -Funktionen -Wunschliste und Ausgabeverfolgung. Für mich ist es schwierig, andere Leute im Team anfangen, andere Tools zu verwenden, wenn sie so sehr an Word gewöhnt sind.

Wenn Sie die agile Methodik befolgen können, können Sie die folgenden Links bei der Auswahl eines guten agilen Projektmanagement -Tools durchführen:

Und im Ernst, probieren Sie die agile Methodik aus-sie predigt einfache, elegante, sachliche, nicht jazzige, häufige, sensquer Ansatz bei allem, was Sie tun, so dass jedes Teammitglied die Rolle und Anstrengung jedes anderen Mitglieds versteht und schätzt.

Viel Glück!

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top