Schreiben einer Softwareanforderungsspezifikation

Ich habe ein paar Fragen zum Schreiben einer Spezifikation und sie sind:

1. Wenn wir eine Software-Spezifikation schreiben, müssen wir unter dem Thema "Definition der Benutzeranforderungen" nur die "Funktionen" und "Einschränkungen" angeben.

2. Fällt "Benutzeroberfläche" unter "Funktionen" oder "Einschränkungen"?

3. Was sind die wichtigsten Schlüsselbereiche (Anforderungen), in die eine Software eingebrochen werden kann (z. B. Benutzeroberfläche)?

Ich bin kein großer Fan davon, alle Anforderungen im Vorfeld detailliert zu erfassen (da sie sich im Verlauf eines nicht trivialen Projekts so stark ändern), aber wenn Sie Anforderungsdokumente schreiben, ist die Volere-Anforderungsspezifikationsvorlage ein hervorragender Leitfaden .

Während es für einige Projekte übertrieben sein kann, bietet es eine große Checkliste von Dingen, über die man nachdenken muss, auch wenn es nur darum geht, die Liste zu deaktivieren, die Sie für diese Anforderung nicht benötigen.

Hier ist ein Link zu weiteren Informationen über die Vorlage:

http://www.volere.co.uk/template.htm

Die Vorlage selbst (und das Buch „ Den Anforderungsprozess meistern“ - das eigentlich etwas günstiger ist als die Vorlage und den vollständigen Vorlagentext enthält) enthält in den verschiedenen Abschnitten zahlreiche Informationen, Beispiele und Ratschläge, was in den einzelnen Abschnitten zu beachten ist.

Hier ist eine Zusammenfassung der darin enthaltenen Abschnitte (zitiert aus dem obigen Link):

1. Der Zweck des Projekts

2. Die Stakeholder

3. Mandated Constraints

4. Namenskonventionen und Definitionen

5. Relevante Fakten und Annahmen

6. Der Umfang der Arbeit

7. Geschäftsdatenmodell und Datenwörterbuch

8. Der Umfang des Produkts

9. Funktions- und Datenanforderungen

10. Look and Feel-Anforderungen

11. Usability- und Humanity-Anforderungen

12. Leistungsanforderungen

13. Betriebs- und Umweltanforderungen

14. Wartbarkeits- und Supportanforderungen

15. Sicherheitsanforderungen

16. Kulturelle und politische Anforderungen

17. Rechtliche Anforderungen

18. Offene Punkte

19. Lösungen von der Stange

20. Neue Probleme

21. Aufgaben

22. Migration zum neuen Produkt

23. Risiken

24. Kosten

25. Benutzerdokumentation und Schulung

26. Wartezimmer

27. Ideen für Lösungen

Ich empfehle Joel über Software zu lesen. Ich bin mir nicht sicher, ob es Ihre spezifischen Fragen beantwortet, aber er hat einen hervorragenden Überblick darüber, was es bedeutet, funktionale Spezifikationen zu schreiben :

Die wichtigste Funktion einer Spezifikation ist das Entwerfen des Programms . Selbst wenn Sie selbst an Code arbeiten und eine Spezifikation nur zu Ihrem eigenen Vorteil schreiben, werden Sie durch das Verfassen der Spezifikation, die die Funktionsweise des Programms detailliert beschreibt, gezwungen, das Programm tatsächlich zu entwerfen ...

... wenn Sie Ihr Produkt in einer menschlichen Sprache entwerfen, dauert es nur ein paar Minuten, um über verschiedene Möglichkeiten nachzudenken, Ihr Design zu überarbeiten und zu verbessern. Niemand fühlt sich schlecht, wenn er einen Absatz in einem Textverarbeitungsprogramm löscht. Wenn Sie Ihr Produkt jedoch in einer Programmiersprache entwerfen, dauert es Wochen , um iterative Entwürfe zu erstellen. Was noch schlimmer ist, ein Programmierer, der nur 2 Wochen damit verbringt, Code zu schreiben, wird an diesen Code gebunden sein, egal wie falsch er ist ...

... Wenn Sie eine spec schreiben, müssen Sie nur kommunizieren , wie das Programm funktionieren soll einmal . Jeder im Team kann einfach die Spezifikation lesen. Die QA-Mitarbeiter lesen es, damit sie wissen, wie das Programm funktionieren soll und worauf sie testen müssen. Die Marketingmitarbeiter verwenden es, um ihre vagen Vaporware-Whitepapers zu verfassen und sich auf der Website über Produkte zu werfen, die noch nicht erstellt wurden. Die Leute aus der Geschäftsentwicklung haben es falsch verstanden, um seltsame Fantasien darüber zu entwickeln, wie das Produkt Kahlheit, Warzen und ähnliches heilen kann, aber es bringt Investoren auf die Palme, also ist das in Ordnung. Die Entwickler lesen es, damit sie wissen, welchen Code sie schreiben sollen. Die Kunden lesen es, um sicherzustellen, dass die Entwickler ein Produkt entwickeln, für das sie bezahlen möchten. Die technischen Redakteure lesen es und schreiben ein schönes Handbuch ...

Wenn Sie keine Spezifikation haben, geschieht all diese Kommunikation immer noch, weil es sein muss , aber es geschieht ad hoc . Die QA-Leute blödeln wohl oder übel mit dem Programm herum, und wenn etwas seltsam aussieht, unterbrechen sie die Programmierer noch einmal , um ihnen eine weitere dumme Frage zu stellen, wie das Ding funktionieren soll ...

Ohne eine detaillierte Spezifikation ist es unmöglich, einen Zeitplan aufzustellen ... In zu vielen Programmierorganisationen gelingt es niemandem, eine Entscheidung zu treffen, wenn es zu einer Designdebatte kommt, normalerweise aus politischen Gründen. Die Programmierer arbeiten also nur an unumstrittenen Dingen. Im Laufe der Zeit werden alle schwierigen Entscheidungen zum Ende gedrängt. Das Schreiben einer Spezifikation ist eine großartige Möglichkeit, all die irritierenden Designentscheidungen zu treffen, die groß und klein sind und die vertuscht werden, wenn Sie keine Spezifikation haben. ..

Wenn wir eine Software-Spezifikation schreiben, müssen wir unter dem Thema "Definition der Benutzeranforderungen" nur die "Funktionen" und "Einschränkungen" angeben.

Eine Anforderung ist eine Kombination aus zwei Dingen ...

1. Was das Ding macht. Funktionale Anforderung.
2. Wie gut es das macht. Nicht funktionale Anforderung oder "Einschränkung"

Fällt "Benutzeroberfläche" unter "Funktionen" oder "Einschränkungen"?

Ich würde sagen, "Benutzeroberfläche" wäre eine Kategorie von Anforderungen, wie Sie in Ihrer letzten Frage identifiziert haben.

Was sind die wichtigsten Schlüsselbereiche (Anforderungen), in die eine Software eingebrochen werden kann (z. B. Benutzeroberfläche)?

Das hängt von der Software ab. Sie können Anforderungen basierend auf Teilen des Systems gruppieren oder sie basierend auf dem Anwendungsfall oder der Geschäftsanforderung, die die Funktionen erfüllen, gruppieren.

Dies alles ist natürlich sekundär zu Ihrem eigentlichen Ziel, nämlich eine klare, eindeutige und überprüfbare Beschreibung des Softwaresystems zu finden.

Die Hauptanforderung für eine Anforderung ist, dass sie prüfbar ist. Wenn Sie nicht herausfinden können, wie eine Anforderung getestet werden soll, besteht die Wahrscheinlichkeit, dass sie nicht so implementiert wird, wie es der Autor beabsichtigt hat.

Ich habe noch nie ein Anforderungsdokument gesehen, das nur auf Funktionen und Einschränkungen beschränkt ist, aber ich kann einen gewissen Wert in einer solchen Struktur sehen - es zwingt den Schreiber, die Anforderungen in "Dinge, die die Software tun muss" und "Regeln für die" zu kategorisieren Software muss folgen. "

Ich denke, dass eine Benutzeroberfläche Anforderungen in beiden Kategorien hat

Einschränkungen:

• "Auf dem Startbildschirm werden zwei Schaltflächen angezeigt:" Start "und" Stop ".
• "Die Anzeigeschrift darf nicht kleiner als 10 Punkte sein."

Funktionen:

• "Wenn die StartTaste gedrückt wird, stellt die Software eine TCP / IP-Verbindung zu WOPR her. "