Welcher Standard hat 830-1998 abgelöst?

17

Ich habe mich mit der formaleren Dokumentation von Softwareprojekten befasst und IEEE 830-1998: Empfohlene Vorgehensweise für Softwareanforderungsspezifikationen kennengelernt . Wie Sie diesem Link entnehmen können, wurde er jedoch ersetzt.

Ich weiß, dass 830-1998 und wahrscheinlich sogar 830-1993 für die Verwendung wahrscheinlich in Ordnung sind. Ich würde jedoch gerne wissen, welcher Standard ihn abgelöst hat. In diesem Fall spielt es vielleicht keine Rolle, aber wenn andere Standards durch technischere ersetzt werden, ist es meiner Meinung nach eine gute Idee, irgendwo zu verlinken, welcher Standard einen anderen ersetzt (wenn es sich nicht um einen anderen in derselben Zeile handelt (830, in diesem Beispiel) Fall)).

Es lohnt sich das zu erwähnen:

  1. Der neueste Standard für die Suche nach "Software Requirements Specifications" oder "Software Requirements" auf der Website der IEEE Standards Association ist 830-1993.
  2. Die (aktuelle) Version von SWEBOK aus dem Jahr 2004 verweist auf 830-1993 ( Absatz 2.5 ).
  3. Der Wikipedia-Artikel des Dokuments erwähnt nicht, dass der Standard ersetzt wurde.

TLDR: Wie finden Sie, welche Norm eine andere ersetzte und welche 830-1998 einnahm?

user1564158
quelle

Antworten:

23

Kurze Antwort : 830-1998 ist kein Standard, es wird empfohlen, SRS im Stil von 1998 zu schreiben.

Ich kann nicht finden, wie es ersetzt wurde (auch mit der erweiterten Suche von IEEE :()

Aber ich denke, das liegt daran, dass sich die gesamte Methode zur Festlegung der Anforderungen in den letzten Jahren drastisch geändert hat.

Von nun an versuche ich, ein bisschen modifizierte Fragen zu beantworten:

Was ist die Best Practice für die Industrie / Was sind die empfohlenen Best Practices für das Schreiben von SRS im Stil von 2012?

Zu klassischen Methoden:

Normalerweise verwende ich IEEE 1471-Empfehlungen für die Softwaredokumentation, obwohl dies kürzlich auch von ISO / IEC 42010 abgelöst wurde. Dies ist eine sehr komplexe Art von Dokumentation, die hauptsächlich für Übergaben verwendet wird, obwohl sie meistens die Anforderungen enthält (es ist Kapitel 7 im neues ISO-Dokument)

Ein mäßig gutes Buch über formale Dokumentation ist Documenting Software Architectures , ein überraschend gutes Buch ist das alte Iconix-Buch , und ein alter Klassiker ist Cockburns Writing Effective Use Cases .

Wie es heute in der Branche tatsächlich gemacht wird:

Um ehrlich zu sein, wurden formale Projektdokumentationen, insbesondere Anforderungsdokumentationen, größtenteils im Zeitalter von Agile abgeschafft , da das Agile Manifest von formalen Dokumentationen abgeraten hat. Es gibt keine einzige, große formale Spezifikation, sondern sogenannte User Stories , Product Backlogs und dergleichen. Dies ist auf die iterative Entwicklung zurückzuführen, bei der nur eine Handvoll Features informell für jeden Zyklus von 2 bis 4 Wochen angegeben werden. Ein bekanntes Buch ist User Stories Applied .

Es gibt sogenannte "ausführbare" Spezifikationen, die formal sind , da es sich im Wesentlichen um domänenspezifische Sprachen (DSLs) zum Testen handelt. Sie sind nicht besser oder schlechter als die OCL von UML , aber sie sind vielleicht leichter zu verstehen, aber auch weniger wissenschaftlich. Die meisten von ihnen heißen BDD-Frameworks. Beispiele hierfür sind FitNesse , Cucumber und Jasmine . Es gibt auch renommierte Bücher zu BDD und TDD im Allgemeinen.

Darüber hinaus wurde die Spezifikation durch Softwareentwickler von UX-Design abgelöst , einschließlich der Informationsarchitektur und des Interaktionsdesigns. Daher wird sie heutzutage nicht von Personen ausgeführt, die tatsächlich programmieren können, was manchmal zu Konflikten führen kann. Dies ist ein nicht so schlechtes Beispiel dafür, wie man aussieht (es ist kein Standard!), Aber Sie werden viel mehr in der UX / Interaction-Community finden, aber es gibt sogar eine ganze separate Stack-Exchange- Site für sie. Sie haben ihre eigenen Standards, empfohlene Best Practices usw.

Aber was ist, wenn Sie bei den alten Methoden bleiben wollen, z. für die universitäre Arbeit?

Versuchen Sie im Allgemeinen, sich an die IEEE 830 zu halten (auf der Webseite ist nicht zu finden, womit sie überschrieben wurde, obwohl IEEE damit nie gut war, ich denke, es ist, weil es leider nicht mehr wichtig ist), und stellen Sie sicher, dass Sie es versuchen zur Aufzeichnung nützliche Informationen (zB, ich glaube nicht , dass ein einzelner Schauspieler Strichmännchen -> einzelne Blase mit einem verb-Subjekt nützlich betrachtet) , aus denen die Gesamtziele der Nutzer, die gesamte Palette der Benutzer und die Gesamt- Methoden von Nutzung kann jederzeit rekonstruiert werden.

Warum empfehlen Sie Bücher? Warum zeigst du mir nicht stattdessen Standards?

Ich denke, dieses Dokument wurde "überholt", weil wir heute ein bisschen Chaos in Bezug auf die Anforderungsspezifikation haben: Es gibt viele Gesichtspunkte, wie es gemacht werden sollte.

Es gibt keine einzige Behörde, die Ihnen sagen kann: "So sollten Spezifikationen erstellt werden" . Es gibt Best Practices , und ich habe versucht, Ihnen eine repräsentative Liste von Dokumenten und Anweisungen zur Verfügung zu stellen , wenn auch keineswegs vollständig und vielleicht persönlich voreingenommen.

Letztendlich kommt es darauf an, ob das von Ihnen erstellte Dokument alle Ziele erfüllt, die alle Menschen, die es jemals gelesen haben, damit erreichen können : Was die Menschen sehen wollen, was die Menschen wissen müssen, um die Anforderungen zu verstehen sind in diesen Büchern ziemlich gut beschrieben, und dies sind Best Practices für sich, wenn auch in viel kleineren Communities als einer einzelnen, ungeteilten IT-Community, die wir vielleicht 1998 hatten.

Aadaam
quelle
Einige Links sind kaputt ...
Tanmay Patil
9

Ich habe dies auf der IEEE-Website gefunden: http://standards.ieee.org/findstds/standard/29148-2011.html

Die Norm 29148: 2011 ersetzt die Norm IEEE 830: 1998.

Diese Norm ersetzt IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

ISO / IEC / IEEE 29148: 2011 enthält Bestimmungen für Prozesse und Produkte im Zusammenhang mit dem Engineering von Anforderungen an Systeme und Softwareprodukte und -dienstleistungen während des gesamten Lebenszyklus.

Es definiert das Konstrukt einer guten Anforderung, stellt Attribute und Merkmale von Anforderungen bereit und erörtert die iterative und rekursive Anwendung von Anforderungsprozessen über den gesamten Lebenszyklus.

Fabricio
quelle
2
Versuchen Sie, Ihre Antwort mit einigen Details darüber zu erweitern, was in Ihrem Link enthalten ist.
Es sollte beachtet werden, dass IEEE-Standards NICHT KOSTENLOS sind, wie in Sprache ODER in Bier. Ich kann Ihnen nicht sagen, wie viel sie verlangen, da die neue Unternehmens-Firewall nicht zulässt, dass ihre Kaufseite funktioniert.
John R. Strohm
Abhängig von Ihrem Abonnement-Level kann es zwischen 175 und 205 US-Dollar kosten. Ich habe eine Kopie davon auf der internen Seite unserer Uni gefunden. Zeit, etwas Schlaf zu verlieren ...
Gerrie