Erfassung von Anforderungen

Question

Wie gehen Sie in der Phase der Anforderungserfassung vor?Hat jemand gute Richtlinien oder Tipps, die man befolgen kann?Welche guten Fragen sollten Sie den Stakeholdern stellen?

Ich arbeite derzeit an einem neuen Projekt und es gibt viele Unbekannte.Ich bin gerade dabei, eine Liste mit Fragen zu erstellen, die ich den Stakeholdern stellen kann.Allerdings habe ich das Gefühl, dass mir etwas fehlt oder ich vergesse, eine kritische Frage zu stellen.

Answer 1

Sie verpassen mit ziemlicher Sicherheit etwas.Wahrscheinlich viele Dinge.Mach dir keine Sorgen, es ist in Ordnung.Selbst wenn Sie sich an alles erinnert und alle Grundlagen abgedeckt haben, werden die Beteiligten Ihnen keine sehr guten, klaren Anforderungen ohne Bezugspunkte geben können.Der beste Weg, so etwas zu tun, besteht darin, sofort von ihnen zu bekommen, was Sie können, und ihnen dann etwas zu geben, auf das sie reagieren können.Es kann ein Papierprototyp, ein Modell, Version 0.1 der Software oder was auch immer sein.Dann können sie anfangen, Ihnen zu sagen, was sie wirklich wollen.

Answer 2

Siehe obligatorischen Comic unten...

Im Allgemeinen versuche ich, ein Gefühl für das Geschäftsmodell zu bekommen, das mein Kunde/Kunde mit der von ihm erstellten Anwendung nachahmen möchte.Bauen wir einen verbesserten Formularprozessor?Rufen wir Daten aus mehreren Quellen in einer einzigen Anwendung ab, um Zeit zu sparen?Führen wir eine Art Integration durch?

Sobald das allgemeine Geschäftsmodell festgelegt ist, gehe ich zu den „Muss“- und „Darf Nicht“-Vorgaben für die Anwendung über, um zu bestimmen, welche Daten ich abrufen kann, wer welche Funktionen ausführen kann usw.

Wenn Sie den Kunden normalerweise dazu bringen können, sein Modell oder seinen Arbeitsablauf zu erklären, können Sie von dort aus weitere Schlüsselfragen finden.

Die eine Frage, die ich in der einen oder anderen Form immer stelle, ist: „Was ist das Kniffligste/nervigste, was man tun muss, wenn man X macht?“Normalerweise zeigt die Antwort darauf die verrückteste Geschäfts-/Datenregel, die Sie implementieren müssen.

Hoffe das hilft!

Answer 3

Steve Yegge Er redet zwar lustig, aber es lässt sich Geld verdienen, wenn man herausfindet, welche Anforderungen andere Leute haben, also würde ich seinen Artikel mit Vorsicht genießen.

Aufgrund der Art und Weise, wie die Kommunikation funktioniert, ist das Sammeln von Anforderungen äußerst schwierig.Es handelt sich um einen vierstufigen Prozess, der in jedem Schritt verlustbehaftet ist.

• Ich habe eine Idee im Kopf
• Ich verwandle dies in Worte und Bilder
• Sie interpretieren die Bilder und Wörter
• Sie zeichnen in Ihrem Kopf ein Bild davon, wie meine ursprüngliche Idee aussah

Und daran scheitern die Menschen mit besorgniserregender Häufigkeit aufgrund ihrer entzückenden Unvollkommenheiten.

Agile tut richtig, wenn es um die Förderung der iterativen Entwicklung geht.Es ist wichtig, dem Kunden frühe Versionen zur Verfügung zu stellen, um herauszufinden, welche Funktionen am wichtigsten sind (was in den Versionen 0,1 bis 0,5 ausgeliefert wird). Es hilft Ihnen dabei, auf dem richtigen Weg zu bleiben, was die Funktionsweise der Anwendung angeht, und identifiziert schnell die versteckten Funktionen, die darin enthalten sind Du Wille vermissen.

Die beiden Hauptproblemszenarien bilden die beiden Enden der Skala:

• Du hast keine Ahnung, was du tust - Holen Sie sich einige Domain-Experten
• Zu viele Anforderungen haben - Feature-Grube.- Funktionen hinterfragen, aussortieren (priorisieren ;)) und iterative Entwicklung nutzen

Yegge weist gut darauf hin, dass Domänenexperten für die Erstellung guter Anforderungen unerlässlich sind, da sie das Geschäft kennen und darin gearbeitet haben.Sie können dabei helfen, den Kernwunsch des Kunden zu erkennen und ihnen zu erklären, wie ihre Mitarbeiter das System nutzen werden und was ihnen wichtig ist.Zu den Alternativen und Ergänzungen gehören der Versuch, die Arbeit selbst zu erledigen, um sich in die Denkweise zu versetzen, oder die gelegentliche Anwesenheit eines Kundenmitarbeiters vor Ort, obwohl letzteres unwahrscheinlich ist.

Die Feature-Grube ist die andere Seite, meist voller gescheiterter staatlicher IT-Projekte.Zu viel, zu früh, zu wenig Nachdenken oder die Anwendung von Realismus (aber was erwarten Sie, wenn sie nur etwa vier Jahre Zeit haben, um sich wichtig zu fühlen?).Ziel ist es hier herauszufinden, was der Kunde erwartet Wirklich will.Solange Sie daran arbeiten, die Kernkomponenten korrekt zu machen, bleiben effiziente und fehlerfreie Clients in der Regel tolerant gegenüber fehlenden Funktionen, die in späteren Lieferungen eintreffen, solange diese schließlich eintreffen.Hier hilft die iterative Entwicklung wirklich.

Denken Sie daran, die Vorstellungen des Kunden davon, wie das Programm aussehen wird, und die Ziele, die er mit dem Programm erreichen möchte, zu trennen erreichen.Manche Kunden können Verwirrung stiften, wenn sie ihre Anforderungen in Form von Anwendungsfunktionen kommunizieren, die möglicherweise schlecht durchdacht sind oder durch viel einfachere Funktionen, als sie ihrer Meinung nach benötigen, überflüssig werden.Auch wenn ich nicht dafür plädiere, den Klienten einen Idioten zu nennen oder ihm nicht zuzuhören, bin ich doch der Meinung, dass es sich lohnt, ewig danach zu fragen Warum Sie möchten, dass eine bestimmte Funktion ihren eigentlichen Zweck erfüllt.

Denken Sie daran, dass es in jedem Szenario von entscheidender Bedeutung ist, den schnellsten Weg zur Kundenzufriedenheit zu finden Kern brauchen und Sie in ein Szenario versetzen, in dem Sie beide von der Beziehung profitieren.

Answer 4

Wow, wo soll ich anfangen?

Erstens gibt es eine Reihe von Kenntnissen, die jemand haben sollte, um bei manchen Projekten Analysen durchzuführen, aber es hängt wirklich davon ab, was Sie für wen bauen.Mit anderen Worten: Es macht einen großen Unterschied, ob Sie eine Unternehmensanwendung für ein Fortune-100-Unternehmen ändern, eine iPhone-App erstellen oder einer persönlichen Webseite Funktionen hinzufügen.

Zweitens gibt es unterschiedliche Arten von Anforderungen.

• Ziele:Was möchte der Benutzer erreichen?
• Funktionell:Was muss der Nutzer tun, um sein Ziel zu erreichen?(Überlegen Sie Schritte, um das Ziel/die Ziele zu erreichen)
• Nicht funktionsfähig:Welche Einschränkungen muss Ihr Programm erfüllen?(Denken Sie an 10 vs. 10.000 gleichzeitige Benutzer, Wachstum, Backup usw.)
• Geschäftsregeln:Welche dynamischen Randbedingungen müssen Sie erfüllen?(denken Sie an Berechnungen, Definitionen, rechtliche Bedenken usw.)

Drittens besteht die Möglichkeit, Anforderungen am effektivsten zu erfassen und dann Feedback dazu zu erhalten (was Sie tun werden, nicht wahr?), darin, Modelle zu verwenden.Benutzerfälle und Benutzergeschichten sind ein Modell dafür, was der Benutzer tun muss.Prozessmodelle sind eine andere Version dessen, was passieren muss.Systemdiagramme sind nur ein weiteres Modell dafür, wie verschiedene Teile des Programms bzw. der Programme interagieren.Eine gute Datenmodellierung definiert Geschäftskonzepte und zeigt Ihnen die Eingaben, Ausgaben und Änderungen, die innerhalb Ihres Programms auftreten.Modelle (und es gibt mehr als ich aufgelistet habe) sind wirklich der Schlüssel zu dem von Ihnen aufgeführten Anliegen.Ein paar gute Modelle erfassen die Bedürfnisse und anhand von Modellen können Sie Ihre Anforderungen ermitteln.

Viertens: Holen Sie Feedback ein.Ich weiß, dass ich das bereits erwähnt habe, aber Sie werden nicht auf Anhieb alles richtig machen, also holen Sie sich Antworten auf die Wünsche Ihres Kunden.

So sehr ich Anforderungen und die Modelle, die sie steuern, schätze, sind sich Benutzer in der Regel nicht der Auswirkungen all ihrer Anforderungen bewusst.Durch die ständige Kommunikation mit der Möglichkeit zur Überprüfung und zum Feedback erhalten Benutzer ein besseres Verständnis dafür, was Sie liefern.Darüber hinaus werden sie ihr Verständnis basierend auf dem, was sie sehen, verfeinern.Sofern Sie nicht für die Regierung arbeiten, sind Iterationen und/oder Prototypen hilfreich.

Answer 5

Sammeln Sie zunächst die Anforderungen Vor Sie beginnen mit dem Codieren.Abhängig von Ihrem Projektlebenszyklus können Sie mit dem Design beginnen, während Sie sie sammeln, aber Sie sollten nie ohne sie mit dem Codieren beginnen.

Anforderungen sind eine Reihe gut geschriebener Dokumente, die sowohl den Kunden als auch Sie selbst schützen.Vergiss das nie.Wenn keine Anforderung vorliegt, wurde nicht dafür bezahlt (und daher ist ein formeller Änderungsantrag erforderlich), wenn sie vorhanden ist, dann ist dies der Fall muss umgesetzt werden und korrekt funktionieren.

Anforderungen müssen testbar sein.Wenn eine Anforderung nicht getestet werden kann, ist sie keine Anforderung.Das bedeutet so viel wie „Das System“

Anforderungen müssen konkret sein.Das bedeutet, dass die Aussage „Die Benutzeroberfläche des Systems muss einfach zu bedienen sein“ keine korrekte Anforderung ist.

Um die Anforderungen tatsächlich zu „erfassen“, müssen Sie zunächst sicherstellen, dass Sie das Geschäftsmodell verstehen.Der Kunde wird Ihnen mit eigenen Worten sagen, was er möchte. Es ist Ihre Aufgabe, es zu verstehen und im richtigen Kontext zu interpretieren.

Treffen Sie sich mit dem Kunden, während Sie die Anforderungen entwickeln.Beschreiben Sie sie dem Kunden mit Ihren eigenen Worten und stellen Sie sicher, dass Sie und der Kunde in den Anforderungen dasselbe Konzept haben.

Anforderungen erfordern prägnante, überprüfbare Beispiele, aber behalten Sie den Überblick über alles andere, was in den Besprechungen, Diagrammen und Zweifeln auftaucht, und versuchen Sie, über jede Besprechung eine Aufzeichnung zu führen.

Wenn Sie einen inkrementellen Lebenszyklus verwenden können, haben Sie die Möglichkeit, einige schlecht erfasste Anforderungen zu verbessern.

Answer 6

Man kann nie zu viele oder „dumme“ Fragen stellen.Je mehr Fragen Sie stellen, desto mehr Antworten erhalten Sie.

Answer 7

Laut Steve Yegge ist das der Fall falsche Frage.Wenn Sie die Anforderungen zusammentragen, ist es bereits zu spät und Ihr Projekt ist zum Scheitern verurteilt.

Answer 8

1. Hochrangige Diskussionen über Zweck, Umfang, Einschränkungen der Betriebsumgebung, Größe usw

2. Hören Sie sich eine einzelne Absatzbeschreibung des Systems an und arbeiten Sie sie aus

3. Nachbildung der Benutzeroberfläche

4. Bekannte Anforderungen formalisieren

5. Nun iterieren Sie zwischen 3 und 4 mit immer mehr funktionalen Prototypen und mehr Spezifikationen mit mehr Details.Schreiben Sie unterwegs Tests.Tun Sie dies, bis Sie über eine funktionsfähige Software und eine vollständige, objektive und überprüfbare Anforderungsspezifikation verfügen.

Das ist der Traum.Die Realität sieht normalerweise so aus, dass nach ein paar Iterationen alle kopfüber programmieren, bis noch ein Monat Zeit zum Testen bleibt.

Answer 9

Das Sammeln von Geschäftsanforderungen ist Bullshit -Steve Yegge

Answer 10

• Lesen Sie das agile Manifest – funktionierende Software ist der einzige Maßstab für den Erfolg eines Softwareprojekts
• Machen Sie sich mit agilen Softwarepraktiken vertraut – studieren Sie Scrum, Lean Programming, XP usw. – das wird Ihnen enorm viel Zeit sparen, nicht nur für die Anforderungserfassung, sondern auch für den gesamten Softwareentwicklungslebenszyklus
• Führen Sie regelmäßige Gespräche mit Kunden und insbesondere mit den zukünftigen Benutzern und Schlüsselbenutzern
• Stellen Sie sicher, dass Sie mit den Personen sprechen, die den Problembereich verstehen – z.Spezialisten auf diesem Gebiet
• Machen Sie sich während der Gespräche kleine Notizen
• Schreiben Sie nach jedem GESPRÄCH eine offizielle Anforderungsliste und legen Sie diese zur Genehmigung vor.Später wäre es schwierig, gegen alle vereinbarten Unterlagen zu argumentieren
• Stellen Sie sicher, dass Ihre Kunden ungefähr wissen, wie hoch der ungefähre zeitliche und finanzielle Aufwand für die Umsetzung „nice to have“-Anforderungen ist
• Stellen Sie sicher, dass Sie die Anforderungen von Anfang an als „muss“, „sollte“ und „nice to have“ kennzeichnen. Stellen Sie sicher, dass Kunden auch die Unterschiede zwischen diesen Typen verstehen
• Integrieren Sie alle Dokumente in die neueste und endgültige Anforderungsanalyse (oder die aktuelle für die Iteration oder den von Ihnen verwendeten agilen Programmierzyklus ...))
• Denken Sie daran, dass sich Anforderungen im Laufe des Software-Lebenszyklus ändern. Das Sammeln ist also eine Sache, das Verwalten und Implementieren jedoch eine andere
• KISS – halte es so einfach wie möglich
• Studieren Sie auch die Umgebung, in der das zukünftige System angesiedelt sein wird – es gibt immer mehr technologische Einschränkungen durch Altsysteme oder umgebende Systeme, da die Unternehmen es nicht vorziehen, das Geld, das sie über Jahrzehnte investiert haben, in den Müll zu werfen, selbst wenn in unseren modernen Köpfen 20 Jahre vergangen sind Alter Code ist Müll ...

Answer 11

Wie in den meisten Phasen des Softwareentwicklungsprozesses funktioniert die Iteration am besten.

Finden Sie zunächst heraus, wer Ihre Benutzer sind – die XYZ-Abteilung,

Finden Sie dann heraus, wo sie in die Organisation passen – Teil der Z-Abteilung,

Finden Sie dann heraus, was sie im Allgemeinen tun: Bargeld verwalten

Dann konkret: Bargeld von den Kassen einsammeln und auf Kassenbetrug prüfen.

Dann können Sie anfangen, mit ihnen zu reden.

Fragen Sie, welches Problem Sie lösen möchten – Sie erhalten eine Antwort, als würden Sie ein verrücktes System mit OCR und Shark-Technologien schreiben.

Ignorieren Sie diese Antwort und stellen Sie weitere Fragen, um herauszufinden, was das eigentliche Problem ist – sie können die Kassenzettel nicht lesen, um den Bargeldabgleich abzugleichen.

Vereinbaren Sie mit den Benutzern eine echte Lösung – suchen Sie sich einen besseren Farbbandlieferanten – oder verbinden Sie die elektronischen Kassen mit dem Netzwerk und laden Sie die Protokolle auf einen zentralen Server hoch.

Anschließend vereinbaren Sie im Detail, wie sie den Erfolg des Projekts messen.

Dann und nur dann schlagen Sie einen detaillierten Anforderungskatalog vor und vereinbaren ihn.

Answer 12

Ich würde Ihnen empfehlen, es zu lesen Roger-Pressmans Softwareentwicklung:Der Ansatz eines Praktikers

Answer 13

Bevor Sie mit den Stakeholdern/Benutzern/jemandem sprechen, stellen Sie sicher, dass Sie in der Lage sind, die gesammelten Informationen nützlich und tagesaktuell festzuhalten.

• Verwenden Sie einen Tonrekorder, wenn dies für die andere Person in Ordnung ist und die Informationen umfangreich sind.
• Wenn Sie etwas Wichtiges gehört haben und etwas Zeit zum Aufschreiben benötigen, haben Sie zwei Möglichkeiten:Bitten Sie die andere Person, eine Sekunde zu warten, oder verabschieden Sie sich von dieser wertvollen Information.Sie werden sich nicht mehr richtig daran erinnern, fragen Sie einen Neurowissenschaftler.
• Wenn Sie feststellen, dass ein Punkt einer eingehenderen Überprüfung bedarf oder Sie ein Dokument benötigen, von dem Sie gerade gehört haben, vereinbaren Sie mit der anderen Person unbedingt, dass Sie dieses Dokument verschicken, oder vereinbaren Sie ein weiteres Treffen mit einem spezifischeren Zweck.Sagen Sie niemals: „Ich werde daran denken, nach der XLS-Datei zu fragen“, denn in den meisten Fällen ist dies nicht der Fall.
• Fassen Sie kurz nach dem Meeting alle Ihre Notizen, Aufzeichnungen und frischen Gedanken zusammen.Fassen Sie es einfach richtig zusammen.Erstellen Sie wirkungsvolle Erinnerungen für die Verpflichtungen.
• Auch hier ist direkt nach dem Meeting der perfekte Zeitpunkt, um zu verstehen, warum die Zusammenkunft, die Sie gerade durchgeführt haben, nicht so gut war, wie Sie am Ende des Meetings dachten.Dann können Sie viele wichtige Fragen für ein weiteres Treffen stellen.

Ich weiß, dass die Frage aus der Perspektive des Vortreffens gestellt wurde, aber bitte beachten Sie, dass Sie diese Angelegenheit vor dem Treffen bearbeiten können und am Ende eine sehr nützliche, vollständige und qualitativ hochwertige Zusammenkunft erhalten.

Answer 14

Ich habe Mind Mapping (wie einen Projektstrukturplan) verwendet, um Anforderungen zu erfassen und Unbekannte (den Projektkiller Nr. 1) zu definieren.Beginnen Sie auf einem hohen Niveau und arbeiten Sie sich nach unten vor.Sie müssen mit den Sponsoren, Benutzern und dem Entwicklungsteam zusammenarbeiten, um sicherzustellen, dass Sie alle Aspekte erfassen und nichts verpassen.Von Ihnen kann nicht erwartet werden, dass Sie ohne ihre Beteiligung den gesamten Umfang ihrer Wünsche kennen. Als Projektmanager/BA müssen Sie sie einbeziehen (wichtigster Teil der Arbeit).

Answer 15

Hier gibt es schon einige tolle Ideen.Hier sind einige Grundsätze zur Erfassung von Anforderungen, die ich immer im Hinterkopf behalten möchte:

Kennen Sie den Unterschied zwischen dem Benutzer und dem Kunden.Die Geschäftsinhaber, die das glänzende Projekt genehmigen, sind in der Regel die Kunden.Ein verheerender Fehler ist jedoch die Tendenz, sie als Benutzer zu verwirren.Der Kunde ist normalerweise die Person, die den Bedarf für Ihr Produkt erkennt, aber der Benutzer ist die Person, die die Lösung tatsächlich nutzt (und sich höchstwahrscheinlich später über eine Anforderung beschweren wird, die Ihr Produkt nicht erfüllt).Gehen Sie zu mehr als einer Person

Denn wir sind alle Menschen und neigen dazu, uns nicht an jedes quälende Detail zu erinnern.Sie erhöhen die Wahrscheinlichkeit, übersehene Anforderungen zu finden, wenn Sie mit mehr Personen sprechen und diese überprüfen.

Vermeiden Sie SonderangeboteSeien Sie vorsichtig, wenn ein Benutzer nach etwas ganz Bestimmtem fragt.Hinterfragen Sie immer die Vorurteile und prüfen Sie, ob Ihr Produkt dadurch wirklich besser wird.

PrototypWarten Sie nicht bis zum Start, um dem Benutzer zu zeigen, was Sie haben.Erstellen Sie regelmäßig Prototypen (Sie können sie sogar als Beta-Versionen bezeichnen) und erhalten Sie während des gesamten Entwicklungsprozesses ständig Feedback.Dabei werden Sie wahrscheinlich auf weitere Anforderungen stoßen.

Answer 16

Ich habe vor kurzem damit begonnen, die von der definierten Konzepte, Standards und Vorlagen zu verwenden Internationales Institut für Wirtschaftsanalysten Organisation (IIBA).

Sie haben ein ziemlich gutes BOK (Buch des Wissens), das von ihrer Website heruntergeladen werden kann.Sie haben auch ein Zertifikat.

Answer 17

Requirements Engineering ist eine Kunst, es gibt viele verschiedene Vorgehensweisen, man muss es wirklich auf Ihr Projekt und die beteiligten Stakeholder zuschneiden.Ein guter Ausgangspunkt ist das Requirements Engineering von Karl Wiegers:

http://www.amazon.com/Software-Requirements-Second-Pro-Best-Practices/dp/0735618798/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1234910330&sr=8-2

und ein Anforderungsentwicklungsprozess, der aus mehreren Schritten bestehen kann, z. B.:

• Erhebung – als Grundlage für die Diskussion mit dem Unternehmen
• Analyse und Beschreibung – eine technische Beschreibung für die Zwecke der Entwickler
• Ausarbeitung, Klärung, Verifizierung und Verhandlung – weitere Verfeinerung der Anforderungen

Darüber hinaus gibt es verschiedene Möglichkeiten, die Anforderungen zu dokumentieren (Use Cases, Prototypen, Spezifikationen, Modellierungssprachen).Jedes hat seine Vor- und Nachteile.Beispielsweise eignen sich Prototypen sehr gut, um Ideen aus dem Unternehmen herauszuholen und Ideen zu diskutieren.

Ich finde im Allgemeinen, dass das Schreiben einer Reihe von Anwendungsfällen und die Einbeziehung von Wireframe-Prototypen gut funktioniert, um einen ersten Satz von Anforderungen zu identifizieren.Von diesem Punkt an ist es ein kontinuierlicher Prozess der Zusammenarbeit mit Technikern und Geschäftsleuten, um die Anforderungen weiter zu klären und auszuarbeiten.Um eine Ausweitung des Umfangs zu vermeiden, ist es wichtig, den Überblick darüber zu behalten, was ursprünglich vereinbart wurde, und zusätzliche Anforderungen im Auge zu behalten.Auch hier spielen Verhandlungen zwischen den verschiedenen Parteien im Sinne des Broken Iron Triangle eine kleine Rolle (http://www.ambysoft.com/essays/brokenTriangle.html).

Answer 18

Meiner Meinung nach besteht der wichtigste erste Schritt darin, ein Wörterbuch domänenspezifischer Wörter einzurichten.Was meint Ihr Kunde, wenn er „Bestellen“ sagt?Etwas, das er von seinen Kunden erhält oder etwas, das er an seine Lieferanten sendet?Oder vielleicht beides?

Finden Sie die Schlüsselwörter im Unternehmen der Stakeholder und lassen Sie sie diese Wörter erklären, bis Sie ihre Bedeutung im Prozess verstehen.Ohne dies wird es Ihnen schwer fallen, die Anforderungen zu verstehen.

Answer 19

Ich habe einen Blogartikel über den von mir verwendeten Ansatz geschrieben:

http://pm4web.blogspot.com/2008/10/needs-analysis-for-business-websites.html

grundsätzlich:Fragen, die Sie Ihrem Kunden stellen sollten, bevor er seine Website erstellt.

Ich sollte hinzufügen, dass dieser Fragebogen nur auf einfache Website-Erstellung ausgerichtet ist – wie eine geschäftliche Webpräsenz.Eine völlig andere Geschichte, wenn es um webbasierte Software geht.obwohl einiges davon immer noch relevant ist (z.B.Fragen zum Look and Feel).

• LM

Answer 20

Ich bevorzuge es, meinen Anforderungserfassungsprozess so einfach, direkt und gründlich wie möglich zu halten.Ein Beispieldokument, das ich als Vorlage für meine Projekte verwende, können Sie in diesem Blogbeitrag herunterladen: http://allthingscs.blogspot.com/2011/03/documenting-software-architectural.html