Wir schreiben immer Funktionen oder Klassen und ihre Logik ist sehr kompliziert. Wenn es keine Spezifikation für diese Strukturen gibt, wird es später schwierig für uns selbst, die Ideen zu erfassen.Wie schreibe ich eine funktionale Spezifikation?
Wie schreiben Sie Spezifikationen für komplizierte Funktionen und Klassen?
Bitte erzählen Sie mir etwas über Ihre eigene Erfahrung, aber nicht nur ein Link, danke.
Ich finde die größte Herausforderung mit funktionalen Spezifikationen ist nicht das Format direkt, aber sie mit Dingen, die sie (Anforderungen) und Dinge, die auf ihnen (Testfälle, Dokumentation) bauen sie synchron zu halten.
Aus diesem Grund bevorzuge ich dieses Problem eher mit einem modellgesteuerten Ansatz als mit einem papierbasierten Ansatz.
Ich benutze ein UML-Modellierungstool (Enterprise Architect von Sparx Systems, aber viele Tools funktionieren auch), um alle Artefakte des Projekts an einem Ort zu erfassen und Traceability zwischen ihnen zu erstellen. In Enterprise Architect kann ich die Nachverfolgbarkeit von einem Anforderungsartefakt zu einem Designartefakt (zum Beispiel) herstellen, indem ich sie beide in dasselbe Diagramm lege und durch Ziehen mit der Maus einen Konnektor von einem zum anderen erzeuge.
Meine "funktionale Spezifikation" ist eigentlich eine Sammlung von Aktivitätsdiagrammen, eine pro Anwendungsfall im System. Jeder Anwendungsfall knüpft an eine oder mehrere Anforderungen an, die diesen Anwendungsfall erforderlich machen. Selbst Endanwender finden es einfach genug, den Aktivitätsdiagrammen zu folgen und sie zu validieren (wie einfach ist es, Endbenutzer dazu zu bringen, traditionelle, papierbasierte Funktionsspezifikationen zu lesen, zu verstehen und zu validieren?)
In einer ähnlichen So kann ich die Rückverfolgbarkeit von meinen Aktivitätsdiagrammen (Anwendungsfällen) zu spezifischen Designartefakten wie Klassendiagrammen herstellen.
QA kann Testfälle modellieren und Rückverfolgbarkeit von ihren Testfällen zu den Anwendungsfällen erstellen. Auf diese Weise sehen wir, ob es Anwendungsfälle gibt, die keine Testfälle haben (oder nicht genug Testfälle haben). Die nette Sache an Enterprise Architect als Werkzeug ist, dass all diese Artefakte in einer SQL-Datenbank gespeichert werden, so dass ich nur einige Abfragen ausführen kann, die ich im Laufe der Zeit aufgebaut habe, um Artefakte zu finden, die nichts zu/von ihnen verfolgen .
"Wie einfach ist es, Endbenutzer dazu zu bringen, eine traditionelle, papierbasierte Funktionsspezifikation zu lesen, geschweige denn zu verstehen und zu validieren." Vielleicht nicht viel Unterschied in der Praxis, aber die Anzahl der Personen, die _admit_ werden wollten Klares technisches Englisch zu verstehen ist viel kleiner als die Anzahl von Leuten, die zugeben würden, ein Diagramm in einer bestimmten technischen Notation nicht lesen zu können. – soru
Wir überprüfen die Spezifikationen/Diagramme, indem wir uns einen Konferenzraum und einen Projektor nehmen und mit den entsprechenden Geschäftsleuten/Analysten durch jedes Diagramm gehen. Es ist erstaunlich, wie viele Missverständnisse und Missverständnisse wir vor dem Schreiben einer Codezeile aufdecken. –
Auschecken Joel on Software. Und here. Und here. Es gibt sogar eine reale Welt example.
Das Beispiel ist richtig auf das Geld. –
Ich bin nicht ganz sicher, dass dies das ist, was der OP sucht, aber sein Artikel ist ein großartiger Lese- und ein gutes Beispiel für das Schreiben von Benutzerfunktionsspezifikationen und Anwendungsfällen. –
Sie auf die Forschung zu folgenden Themen (nicht unbedingt in dieser Reihenfolge) machen sollte:
Dies sind die am häufigsten Ansätze für Softwareprojekte spezifisch Ion.
Ich sehe einige Beschwerden über Links zu Joels Sachen, anstatt Inline-Text, also hier ist meine Meinung zu dem, was er sagt.
Auf den höchsten Ebenen müssen funktionale Spezifikationen kommunizieren, was das Programm für den Verbraucher oder Kunden erreichen soll. Ich bin zu 100% mit Joel dabei: die englische (gut any!) Sprache, die mit Strenge verwendet wird, ist ein sehr leistungsfähiges Werkzeug, das alle Ihre Kunden Experten im Verdauen werden. Experten bei UML sind sie nicht.
Ein Top-Level-Funktionsspezifikationsdokument (FSD) kann einen logischen Rahmen bereitstellen, der die Anforderungen des Systems in einer Logik Modell erfasst, die die Leute leicht verstehen können.
Reine Anforderungsdokumente - etwas, das einem FSD vorausgeht - sind ein kniffliger Fisch. Sehr wenige Menschen sind in der Lage zu unterscheiden, was eine Anforderung und was Teil der Lösung ist. Am besten ist es, die Anforderungen auf einem sehr hohen Niveau zu halten und sich als Analytiker auf die FSD zu konzentrieren.
Der FSD sollte ein vollständiges Top-Level-Modell des Systems und ein nachfolgender Designprozess zur detaillierteren Modellierung einer Modellhierarchie sein. Die letzte Detailstufe ist echter Code.
Die FSD sollte eine Reihe von einfachen englischen Aussagen enden. Verwenden Sie eine einzelne Überschriftenebene in den Dokumenten, halten Sie paras auf maximal zwei Sätze und nummerieren Sie jedes para. Überprüfen Sie die Paras und stellen Sie sicher, dass jeder etwas Nützliches sagt. Wenn nicht, löschen Sie es. Kurz ist gut!
Denken Sie sehr intensiv über die Sprache in Ihrem FSD nach. Haben Sie strenge Definitionen von Schlüsselbegriffen in Ihren Absätzen. Diese Substantive werden zu deinen Klassen. Die verwendeten Verben werden zu Klassenmethoden. Es ist wirklich so einfach!
Wie Joel sagt, schreiben Sie Sätze, wie Sie sie kompilieren werden. Zum Beispiel schreiben Sie "Wenn stuff passiert dann mehr tun" anstatt "Wenn Sachen passiert, mehr tun" oder "mehr tun, wenn Sachen passiert".
Diese Arten von geschriebenen Modellen können von der Verwendung bestimmter Diagramme, wie z. B. endlicher Zustandsdiagramme, profitieren, aber denken Sie daran, dass Sie ein System mit einer Reihe von UML-Diagrammen erfassen können. Diese Dinge sind einfach nicht mächtig, flexibel oder streng genug, um selbst als vollständige Beschreibung zu dienen. Es ist viel effektiver, mit einem in strengem Englisch geschriebenen Entwurf zu beginnen und diesen bei Bedarf zu ergänzen.
Wie für die Probleme der Iteration, in einer idealen Welt sollten Sie nur die unteren Ebenen des Modells überarbeiten müssen. Wenn Sie die hohen Stufen ändern müssen, ist etwas Ernstes falsch. Wie für UML-Tools, die revising schneller - poppy-cock! Der Schlüssel ist, dass alle diese Beschreibungen KURZ und ÜBERLEGUNG sind. Englisch ist der Weg zu gehen, weil wir alle so lange geübt haben.
Ich habe Leute gesehen, die einen Nachmittag damit verbracht haben, Entity-Diagramme so aussehen zu lassen, dass sie sich in überlappenden Linien sehen lassen. Wie warum? Ist Ihre ultimative Lösung zweidimensionale Boxen und Linien? Nein! Und das ist das Problem mit UML: Die Diagramme werden für den Analytiker zum Selbstzweck und trennen Sie vom Kunden, anstatt die Kommunikation zu unterstützen.
Ich habe dein Englisch bearbeitet. Ich bin mir ziemlich sicher, dass ich weiß, was du meinst ... Ich werde nicht beleidigt sein, wenn du es zurück änderst. :-) –
Suchen Sie nach Tipps zum Schreiben von Spezifikationen für tatsächliche Codestrukturen oder für die rohen Benutzerfunktionen eines Programms? In meiner Firma werden tatsächliche Codestruktur-Spezifikationsdokumente als "Designspezifikationen" und Benutzerfunktionsbeschreibungen als "funktionale Spezifikationen" bezeichnet. Die Joel on Software-Antwort beschreibt die Benutzerfunktionsspezifikationen. –
Ich denke, ich brauche eine "Spec-Dokumente", Danke Paul Nathan – MemoryLeak