1.実現可能性調査
1.実現可能性調査の目的は何ですか？ターゲットシステムの実現可能性はどのような側面から研究する必要がありますか？
（1）目的：問題を解決する価値があるかどうかを判断します。問題を解決するのではなく、問題が解決可能で解決する価値があるかどうかを判断するためです。
（2）①技術的実現可能性；このシステムは既存の技術を使用して実現できるか？
②経済的実現可能性;このシステムの経済的利益はその開発コストを超えることができますか？
③運用の実現可能性;このユーザー組織でシステムの運用方法は実現可能か？
必要に応じて、各ソリューションの実現可能性を次のような幅広い観点から検討する必要があります
。①法的実現可能性、システムの機能が法律に準拠しているかどうか違反
②社会や市場における社会的実現可能性分析システムの認知度。
2.実現可能性調査プロセスにはどのようなステップが含まれますか？
①
システムの規模と目標を再検討する
②現在使用しているシステムを
調査する③新システムのハイレベルロジックモデルをエクスポートする
④問題をさらに明確化する⑤代替ソリューションを
エクスポートして評価する法律アクションガイドラインを
推奨する
⑧レビュー用のドキュメントを作成する
2、データフロー図（DFD）
データフロー図（DFD）は、ソフトウェアで入力から出力に移動する過程でデータが受ける変換（つまり処理）を示すグラフィカルツールです。
4つの成分：
- データソース/エンドポイント（長方形）
- 処理中（⚪または丸みを帯びた長方形）
- データストレージ（二重水平線）
- データフロー（矢印）
ステップ：
- まず、システムデータの入力ポイントと出力ポイントを見つけて、外部エンティティを描画します。
- 外部エンティティの入力および出力データフローを決定します。
- ソースポイントでの外部エンティティのデータフローから開始して、処理が徐々に実行され、データフロー図全体が完成します。
- 画像の処理が5〜9を超える場合は、最も基本的なシステム機能を第0層とし、第1層から始めて、各モジュールの機能を洗練するように階層化する必要があります。
ネーミング：
- データストリーム（またはデータストレージ）に
名前を付ける①名前は、コンポーネントの一部ではなく、データストリーム全体（またはデータストレージ）のコンテンツを表す必要が
あります
。②名前を付けるときは、できるだけ具体的にし、特定の意味のない空の名前を使用しないでください。③名前問題が発生した場合は、不適切な分解が原因である可能性があります。もう一度分解してみてください。 - 処理に名前を付ける①通常、
最初にデータストリームに
名前を付け、次にそれに関連する処理に名前を付けます。②名前は処理全体の機能を反映する必要があります。③名前
付け規則：可能な限り具体的な推移的な動詞+オブジェクト
。④通常は名前のみを含めます。動詞、そうでない場合は分解されます
。⑤命名に問題がある場合は、再分解を検討してください。 - データソース/エンドポイントに名前
を付ける問題のドメインで使用されている名前を使用します。
例：フレンチフライを作る
説明は次のとおりです。
家にポテトがいくつかあり、息子がディナーにフレンチフライを食べるように頼みます。ママがそれを始めます。掃除、皮むき、切断、沸騰、水切り、オイルの混合、ベーキング、そして最後に提供した後、トマトソースを添えてテーブルの上でお召し上がりいただけます。
- データソースポイントとエンドポイント
ママと息子
- 扱う
洗う、皮をむく、細片に切る、沸騰させる、水気を切る、油を混ぜる、焼く、出す
- データストレージ
調理されたポテトチップ
- データフロー
（1）ポテト;（2）皮をむいたポテト;（3）生のポテトチップ;（4）調理されたポテトチップ;（5）フレンチフライ
3、データ辞書（DD）
データフロー分析には、データディクショナリ（DD）の導入が必要です。
DDは、DFDでのデータフロー、データフローコンポーネント、データストレージ、および処理を正確かつ簡潔に説明します。
データディクショナリの機能：
1。データディクショナリは分析段階のツールです
。2。データディクショナリはアナリストとユーザー間の通信を改善するのに役立ちます
。3。データディクショナリは多くの厄介なインターフェイスの問題を回避できます
。4。データディクショナリで毎回各データ要素の制御情報は非常に貴重です
。5。データディクショナリはデータベース開発の最初のステップです。
4、システムフローチャート
