Beim Schreiben von Anforderungen stellt sich häufig die Frage, auf welcher Ebene es sich lohnt, die Anforderungen zu detaillieren und welche Artefakte als Ergebnis der Systemanalyse auftreten sollten.
Ich versuche, an der Position festzuhalten, dass dies rein individuell ist und vom Team abhängt und wer gut arbeitet. Es kommt vor, dass der Anwendungsfall für Entwickler ausreicht, um das Design zu erstellen, und für die Tester ausreicht, um Testfälle zu schreiben. Daher werde ich über jene Artefakte schreiben, die beim Schreiben von Anforderungen auftreten können und über die Sie bis zum Abschluss der Entwicklung genau nachdenken müssen, und Sie selbst entscheiden und stimmen im Team zu, wann es sich lohnt, sie zu beschreiben. Es ist nur eindeutig, dass die Dokumentation bis zum Ende der Entwicklung alles enthalten sollte, was weiter besprochen wird.
Wenn Sie kleine Funktionen nicht berücksichtigen, deren Implementierung geringfügige Verbesserungen beinhaltet, können Sie einfach Änderungen an den vorhandenen Beschreibungen vornehmen. Systematisch können wir zwei Arten von Aufgaben unterscheiden, die in die Arbeit eines Systemanalysten einfließen und die auf unterschiedliche Weise beschrieben werden müssen:
Die Aufgabe, einen neuen Dienst oder eine neue Funktionalität zu entwickeln, die nur indirekt andere Systeme oder Komponenten betrifft
Aufgaben, deren Implementierung Verbesserungen in einer Reihe von Systemen nach Prozessen beinhaltet (und wie Sie wissen, werden Systeme häufig nach Prozessen segmentiert, und eine Geschäftsfunktion durchläuft normalerweise nur die gesamte Pipeline und erfordert Verbesserungen in einer Reihe von Systemen).
Um die Aufgaben des ersten Typs zu beschreiben, habe ich die folgenden Struktur- und Beschreibungsblöcke identifiziert:
Allgemeine Anforderungen
Ein Block, der die Bezeichnung des Kontexts übernimmt. Was für ein System ist es, wofür ist es, welche Objekte enthält es, was sind seine Grenzen?
- Ziel
-
, ,
-
, , . , Confluenc , , , ,
-
, . , .
, , .
, , , . , , .
, , ,
, ( ), , .
(Use case)
, . . , UML-
UML. .
, , / . .
ER-.
, . , , , . . , , , .
, , ( ). .
-
, , \ . , , , ( ).
-
, swagger ( ), ( ), ftp .
.
:
, , , , , . ( ).
:
, . , .
(Use-case)
.
Es ist am einfachsten, Systeminteraktionen und Datenflüsse für die Implementierung anzuzeigen. Es ist notwendig, alle Funktionen in Bezug auf Daten, Anrufe und Trigger in Systeme zu zerlegen. Geben Sie alle Beziehungen und Abhängigkeiten von Aufgaben an. Weitere Details bereits auf der Ebene jedes Systems separat.