Wie können Anforderungsdokumente ordnungsgemäß erstellt werden?

23

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.

Patrick
quelle

Antworten:

17

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.

Aaronaught
quelle
Ich habe festgestellt, dass Sie relativ einfach Daten aus Ihrem Tracking-System in Ihr Wiki einbetten können. Wenn Sie hierarchische Fehler einrichten, können Sie diese in der Anforderung gruppieren. Die Projektmeilensteine ​​enthalten Wiki-Seiten, Projekte, Kunden und Es ist alles leicht, den Kopf herumzukriegen. Wikis sind der Leim, verwenden aber immer noch einen Bug-Tracker. Untersuchen Sie die Fähigkeit Ihres Bug-Trackers, auf eine Webseite im Wiki zu verweisen!
Tim Williscroft
Auf jeden Fall ist ein Wiki kein Ersatz für ein Bug-Tracking-System, sondern eine Ergänzung. Projektplanung und Zusammenarbeit erfolgen am besten im Wiki. Probleme müssen noch in einer IMS- oder Prioritätswarteschlange verfolgt werden.
Aaronaught
6

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!

Ein weiterer
quelle
5

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.
Azheglov
quelle
ABER ... sobald die unvollständige Anforderung eingegeben wurde, wird sie zugewiesen, und wer auch immer, dem sie zugewiesen wurde, muss unvollständige Informationen auflösen, oder? Ich meine, wenn es einmal im System ist, sollte es nicht gelöst werden, wenn die Leute keine Gegenstände fallen lassen? Ich schlage nicht vor, dass ein vollständiger Software-Laie Elemente eingeben sollte, aber selbst wenn dies der Fall ist, ist dies im System und sollte behandelt werden. Beispiel: Das Unternehmen fügt dem Bug-Tracker die Anforderung "Quittung drucken" hinzu und weist sie dem Busanalysten zu. Der Busanalyst verarbeitet sie, indem er die Lücken ausfüllt (ggf. über mehr Kommunikation), und der Entwickler erhält sie.
John MacIntyre
Wäre eine Kommunikationsstörung nicht ein Symptom für ein Prozessproblem? (Aufrichtigkeit beabsichtigt)
John MacIntyre
@JohnMacIntyre (1): Das Ergebnis ist Ping-Pong statt Zusammenarbeit. Der Bevollmächtigte ist nicht immer die richtige Person; seltene Probleme können nur von einer Person gelöst werden. Wenn mehr Personen benötigt werden, hat der Bevollmächtigte selten die Befugnis, sie anzuweisen, was zu tun ist, und sieht selten alle Abhängigkeiten (Anforderungen sind selten unabhängig). verloren sind die Vorteile der Selbstorganisation, Priorisierung nach ROI oder Kosten der Verzögerung, etc.
Azheglov
@JohnMacIntyre (2): Die Kommunikationsstörung ist natürlich ein Zeichen dafür, dass ihr Prozess nicht funktioniert oder dass sie keinen Prozess haben oder dass sie nur keine gesunde Kommunikations- und Kollaborationskultur in ihrem Unternehmen haben. Mein Standpunkt ist, dass sie diese Grundursachen angehen sollten.
Azheglov
@asheglov - Ich nehme an, dass dies ein Problem sein kann, wenn der Beauftragte der Implementierer ist und nicht berechtigt ist, jemanden neu zuzuweisen oder mit ihm zu sprechen. Aber meine Position ist, dass das nicht das Werkzeug ist und dass dies mit den besten Werkzeugen passieren würde, nicht wahr?
John MacIntyre
2

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.

Bruce Ediger
quelle
1
Ich denke, die meisten dieser Argumente klingen wie FUD. Word ist vielleicht nicht die beste Wahl, aber es ist nicht so schlimm: 1. Es verfügt über nette Revisions- / Kollaborationsfunktionen zum Nachverfolgen und Akzeptieren / Ablehnen von Änderungen, umso benutzerfreundlicher als alle vcs + diff-Tools. 2. Stile sind seit 2007 in der Multifunktionsleiste stärker vertreten. Es ist wahrscheinlich einfacher zu erklären, warum Stile verwendet werden sollten, als eine völlig neue Software zu erklären. 3. Das neueste Word kann Word 97-Dateien lesen / speichern, die vor 16 Jahren erstellt wurden. Word 2003 kann 2010-Dateien mithilfe von Kompatibilitätspaketen lesen und speichern. Ich bin mit 4. und 5. einverstanden, obwohl pdf eine Option für die Online-Anzeige sein kann.
Kapex
@kapep - meine Argumente sind nicht FUD im klassischen Sinne von "Fear, Uncertainty and Doubt", vielleicht verwenden Sie "FUD" auf eine andere Art und Weise. Jedes meiner Argumente kann beantwortet werden. Sie können beispielsweise im Menü "Einfügen" die Option "Strg-Umschalt-@ ausführen, um ein zeilenweises Vergleichen des aktuellen Dokuments mit einem anderen Dokument zu erhalten". Das geht nicht, weil Sie nur eine Gegenmeinung abgegeben haben. Microsoft hat in der Vergangenheit Dokumentformate aufgegeben oder es zumindest teuer oder schwierig gemacht, alte Formate zu verwenden, was meiner Meinung nach den Upgrade-Umsatz steigert.
Bruce Ediger
Ok, ich muss mich korrigieren, nur 3. scheint ein FUD-Argument zu sein, das oft verwendet wird, wenn es darum geht, Word / Doc als proprietär zu deklarieren. Sicher, Microsoft hat die Formate aufgegeben - aber Doc-Dateien gibt es schon seit sehr langer Zeit. Daher gilt "früher oder später" nur für archaische Versionen aus dem letzten Jahrhundert, wenn sie die Unterstützung für> 2016 einstellen oder wenn das nächste Wort veröffentlicht wird. Ich wollte auch nur darauf hinweisen, dass es eine einfache Möglichkeit gibt, Dokumente zu "unterscheiden". Natürlich wird nicht zeilenweise verglichen, was in einem nicht zeilenbasierten Format nicht viel Sinn macht. Es ist eher wie das Inline-Diff hier auf SE.
Kapex
2

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.

HLGEM
quelle
1

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.


quelle
1

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.

John MacIntyre
quelle
1

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.

SESummer
quelle
1
Es ist eine kommerzielle Anforderungsverfolgungssoftware verfügbar, wie z. B. DOORS.
M. Dudley
1

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.

Julia K Szopa
quelle
0

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

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!

Karthiks
quelle