要件を作成するとき、要件を詳細に説明する価値があるレベルと、システム分析の結果として表示されるアーティファクトについて疑問が生じることがよくあります。
私は、これは純粋に個人的であり、チームと誰が快適に作業できるかに依存するという立場を堅持しようとしています。開発者が設計を行うにはユースケースで十分であり、テスターはテストケースを作成するだけで十分です。したがって、要件を作成するときに発生する可能性があり、開発が完了するまでに正確に考慮する必要があるアーティファクトについて説明します。説明する価値がある場合は、チーム内で自分で決定して同意します。開発の終わりまでに、ドキュメントにさらに説明するすべてのものが含まれている必要があることは明白です。
実装にマイナーな改善が含まれる小さな機能を考慮しない場合は、既存の説明に変更を加えるだけで済みます。体系的に、システムアナリストの仕事に入る2つのタイプのタスクを区別することができ、それらは異なる方法で説明する必要があります。
他のシステムまたはコンポーネントに間接的にのみ影響を与える新しいサービスまたは新しい機能を開発するタスク
タスク。その実装にはプロセスごとの多数のシステムの改善が含まれます（ご存知のように、システムはプロセスごとにセグメント化されることが多く、ビジネス機能は通常パイプライン全体を通過するだけで、多数のシステムの改善が必要です）
最初のタイプのタスクを説明するために、次の構造と説明ブロックを特定しました。
一般的な要件
コンテキストの指定を想定したブロック。それはどのようなシステムであり、何のためにあり、どのオブジェクトが含まれ、どのような境界がありますか。
- 目標
-
, ,
-
, , . , Confluenc , , , ,
-
, . , .
, , .
, , , . , , .
, , ,
, ( ), , .
(Use case)
, . . , UML-
UML. .
, , / . .
ER-.
, . , , , . . , , , .
, , ( ). .
-
, , \ . , , , ( ).
-
, swagger ( ), ( ), ftp .
.
:
, , , , , . ( ).
:
, . , .
(Use-case)
.
実装のためにシステムの相互作用とデータフローを表示するのが最も簡単です。データ、呼び出し、トリガーの観点から、すべての機能をシステムに分解する必要があります。タスクのすべての関係と依存関係を示します。各システムのレベルで個別に詳細を説明します。