ソフトウェアエンジニアリング——第 3 章 要件分析の知識ポイントの整理

このコラムはブロガーの個人的なメモであり、主な目的は、断片的な時間を利用してソフトエンジニアリングの知識ポイントを暗記することです、ここに宣言します!

記事ディレクトリ

1. ニーズ分析の基本的なタスクは何ですか?

2. システム アナリストは要件分析フェーズの最後に何をすべきですか?

3. ソフトウェア システムの包括的な要件は何ですか?

4. ニーズ分析のタスクは何ですか?

5. システムのデータ要件を分析するには通常どのような方法が使用されますか?

6. 要件を取得するためにユーザーとコミュニケーションをとる方法は何ですか?

7. ラピッドプロトタイピングの定義、要点、特徴は何ですか?

8. 要件分析プロセスで確立すべき 3 つのモデルはどれですか?

9. 要件分析段階で得られる最も重要な文書は何ですか?

10. データ モデルには、相互に関連する 3 種類の情報が含まれていますか?

11. ER 図のコンポーネントは何ですか?

12. ER図の利点は何ですか?

13. パラダイムとは何ですか? データ冗長性の最大および最小はどの正規形ですか?

14. 状態遷移図の役割は何ですか?

15. 状態とイベントの違いは何ですか?

16. 階層ブロック図はデータの階層構造を記述するためにどの構造を使用しますか?

17. ワーニエ図は情報を記述するためにどの構造を使用しますか? 階層ブロック図との主な違いは何ですか?

18. 要件分析フェーズでシステムの主なアルゴリズムを簡単に説明するために使用される図はどれですか?

19. IPOチャートの定義と機能は何ですか?

20. ソフトウェア要件の正確性をどのような側面から検証しますか?

21. プロトタイプを迅速に修正するには、どのような方法とツールが使用されますか?

22. なぜ分析が必要なのでしょうか? (ニーズ分析の重要性)

23. 要件分析手法が従わなければならない基準は何ですか?

章の最後にまとめ


1. ニーズ分析の基本的なタスクは何ですか?

        要件分析はソフトウェア定義期間の最終段階であり、その基本的なタスクは「システムが何をしなければならないか」という質問に正確に答えること、つまり、ターゲットシステムに対する完全、正確、明確かつ具体的な要件を提示することです。

2. システム アナリストは要件分析フェーズの最後に何をすべきですか?

システム アナリストは、ソフトウェア要件書面で正確に説明するソフトウェア要件仕様を作成する必要があります。

3. ソフトウェア システムの包括的な要件は何ですか?

  1. 機能要件
  2. パフォーマンス要件
  3. 信頼性可用性の要件
  4. エラー処理要件
  5. インターフェース要件
  6. 制約
  7. 需要
  8. 将来の可能性のある要件

4. ニーズ分析のタスクは何ですか?

  1. システムの包括的な要件を決定する
  2. 分析システムのデータ要件
  3. システムの論理モデルをエクスポートする
  4. システム開発計画の見直し

5. システムのデータ要件を分析するには通常どのような方法が使用されますか?

エンティティ関係図 (ER 図) などのデータ モデルを構築するためのメソッドを使用する

6. 要件を取得するためにユーザーとコミュニケーションをとる方法は何ですか?

  1. インタビュー:最も古く、最も広く使用されています。インタビューの2つの方法:アンケートの送信状況分析手法の使用
  2. データフローのトップダウン絞り込み(構造化分析手法):分析過程におけるデータ要素の情報をデータディクショナリに記録し、アルゴリズムをIPO図に記録する
  3. 簡単なアプリケーション仕様テクニック: このアプローチはユーザーと開発者を結び付け、インタビューや構造化された手法に存在するユーザーと開発者の分離を解決します。
  4. 迅速なソフトウェア プロトタイピング:最も正確、効果的、強力な要件分析手法

7. ラピッドプロトタイピングの定義、要点、特徴は何ですか?

定義: ラピッド プロトタイピングとは、ターゲット システムの主な機能をデモンストレーションするために迅速に確立される実行可能なプログラムを指します。

重要なポイント:ユーザーに見える関数を実装し、ターゲット システムに見えない関数を省略する

特徴: 高速、簡単に変更可能

8. 要件分析プロセスで確立すべき 3 つのモデルはどれですか?

  1. データモデル(エンティティ関係図を使用)
  2. 機能モデル(データフロー図を使用)
  3. 動作モデル(遷移図を使用)

9. 要件分析段階で得られる最も重要な文書は何ですか?

ソフトウェア要件仕様書(自然言語で書かれたもの)

10. データ モデルには、相互に関連する 3 種類の情報が含まれていますか?

データオブジェクト、プロパティ、リレーション

11. ER 図のコンポーネントは何ですか?

エンティティ (データ オブジェクト)、関係、属性

12. ER図の利点は何ですか?

ER モデルは人々の習慣的な考え方に近く、ユーザーアナリストの間の効果的なコミュニケーション ツールとして使用できます。

13. パラダイムとは何ですか? データ冗長性の最大および最小はどの正規形ですか?

正規形はデータ冗長性の除去の程度を定義します。最初の正規形は最大のデータ冗長性を持ち、5 番目の正規形は最も少ないデータ冗長性を持ちます。

[注]ほとんどの場合、第 3 正規形を選択する方が適切です。

14. 状態遷移図の役割は何ですか?

状態遷移図は、状態図        と呼ばれ、システムの状態と、システムの状態遷移を引き起こすイベントを記述することでシステムの動作を表現します。状態図は、システムがどのようなアクションを実行するかを示します。特定のイベントの結果。

15. 状態とイベントの違いは何ですか?

状態とは、観察可能なシステム動作パターンを指し、状態はシステムの動作パターンを表します。

イベントとは、特定の瞬間に発生するものであり、システムを動作させ、ある状態から別の状態に遷移させるイベントの抽象化です。

16. 階層ブロック図はデータの階層構造を記述するためにどの構造を使用しますか?

ツリー構造

17. ワーニエ図は情報を記述するためにどの構造を使用しますか? 階層ブロック図との主な違いは何ですか?

ワーニエ図はツリー構造を使用して情報を記述しますが、階層ボックス図よりも豊富な表現手段を提供します。

18. 要件分析フェーズでシステムの主なアルゴリズムを簡単に説明するために使用される図はどれですか?

        要件分析段階では、IPO 図を使用してシステムの主要なアルゴリズムを簡単に説明し、これらの図は詳細設計段階でさらに補足および修正されます。

19. IPOチャートの定義と機能は何ですか?

        IPO ダイアグラムは、入力、処理、および出力ダイアグラムの略で、入力データ、データ処理、および出力データの関係を簡単に表すことができます。

20. ソフトウェア要件の正確性をどのような側面から検証しますか?

  1. 一貫性: すべての要件は一貫している必要があり、互いに矛盾してはなりません。
  2. 完全性: 要件にはユーザーのニーズが完全に含まれている必要があります
  3. 現実的: 指定された要件は既存のテクノロジーで達成可能である必要があります
  4. 有効性: 要件は正確かつ効果的であり、ユーザーの問題を解決できる必要があります。

21. プロトタイプを迅速に修正するには、どのような方法とツールが使用されますか?

  1. 第四世代テクノロジー
  2. 再利用可能なソフトウェアコンポーネント
  3. 正式仕様書

22. なぜ分析が必要なのでしょうか? (ニーズ分析の重要性)

ユーザーのニーズに真に応えるソフトウェア製品        を開発するには、まずユーザーのニーズを知る必要があります。ソフトウェア要件を深く理解することは、
ソフトウェア開発を成功させるための前提条件です。どんなに設計やコーディング作業をうまく行ったとしても、ユーザーのニーズを実際に満たすことができないプログラムは、ユーザーを失望させ、開発者に迷惑をかけるだけです。

23. 要件分析手法が従わなければならない基準は何ですか?

  1. 問題の情報ドメインを理解して説明し、それに従ってデータ モデルを構築する必要があります。
  2. ソフトウェアが実行すべき機能を定義する必要があり、この基準には機能モデルの確立が必要です
  3. 外部イベントの結果としてのソフトウェアの動作を記述する必要があり、この基準には動作モデルの確立が必要です。
  4. 情報、機能、動作を記述するモデルは、詳細を階層的に表示するために分解する必要があります。

章の最後にまとめ

        従来のソフトウェア エンジニアリング手法では、構造化分析手法を使用してユーザー ニーズの分析作業を完了します。

        要件分析は、発見、改良、モデリング、仕様、レビューのプロセスです。要件分析の最初のステップは、ユーザーの現状をより深く理解し、ユーザーが直面している問題と対象システムの基本的な要件を発見することであり、次のステップは、ユーザーと深くコミュニケーションし、繰り返し改良を加えていくことです。ターゲットシステムの完全、正確かつ具体的な要件を取得するために、ユーザーの基本的なニーズを把握します。具体的には、システムが備えるべき機能、性能、信頼性、可用性、実現すべきエラー処理要件、インターフェース要件、リバース要件、満たすべき制約条件やデータ要件などを定め、システムの開発見通しを予測する。システム

        ユーザーのニーズを詳しく理解し、正しく理解するためには、適切な方法でユーザーとコミュニケーションをとる必要があります。インタビューはユーザーとコミュニケーションをとるための古くからある手法であり、現在でも多くのシステム アナリストによって採用されています。実現可能性調査の段階で得られたデータフロー図を基に、ユーザーの協力を得て上から下へ段階的にデータフローを修正していくのも、ユーザーとコミュニケーションをとって要件を獲得する有効な方法です。ユーザーとアナリストが協力して要件を分析するために、簡易アプリケーション仕様化技術と呼ばれるチーム指向の要件収集手法が開発され、現在では情報システム分野で主流の技術となっています。実際には、ラピッド ソフトウェア プロトタイピングが最も正確で効果的かつ強力な要件分析手法であることがわかっています。ラピッドプロトタイピングが持つべき基本的な特性は「高速」と「修正の容易さ」であるため、ラピッドプロトタイピング技術をサポートするには適切なソフトウェアツールを使用する必要があります。多くの場合、第 4 世代テクノロジー、再利用可能なソフトウェア コンポーネント、正式な仕様およびプロトタイピング環境を使用して、プロトタイプを迅速に構築および変更します。         問題をよりよく理解するために、人々はモデルを構築する方法を採用することがよくあります。構造分析は本質的に一種のモデリング活動です。要件分析の段階では、通常、データ モデル、機能モデル、および動作モデルが確立されます         分析モデルの作成に加えて、要件分析段階でソフトウェア要件仕様も作成する必要があります。これは、厳密なレビューとユーザーの確認を経て、この段階の最終結果となります。通常、ソフトウェア要求仕様は主に一貫性、完全性、現実性、有効性の4つの側面から検討されます。         ほとんどの人は慣れています


エンティティ関係図を使用してデータ モデルを構築しデータ フロー図を使用して機能モデルを構築し、状態図を使用して動作モデルを構築します読者は、これらのグラフィックの基本的なシンボルを習得し、これらのシンボルを正しく使用してソフトウェア システム モデルを構築できる必要があります。
        データディクショナリは、データモデル、機能モデル、動作モデルに現れるデータオブジェクトと制御情報の特性を記述し、それらの正確な定義を与えます。したがって、データ ディクショナリは3 つの分析モデルを結び付ける「接着剤」となり、分析モデルの「核」となります。理解を容易にするために、階層ブロック図やワーニア図などのグラフィカル ツールを使用して、システム内のデータ構造を表現することもできます。冗長性を減らし、変更手順を簡素化するために、多くの場合、データのストレージ構造を標準化する必要があります。

        アルゴリズムも重要であり、分析の基本的な目的は、システムが何を実行する必要があるかを決定することです。一言で言えば、コンピューター システムの基本機能は入力データを出力情報に変換することであり、アルゴリズムは変換の規則を定義しますしたがって、アルゴリズムの知識がなければ、システムがどのように機能するかを正確に知ることはできません。IPO 図はアルゴリズムを記述するための効果的なツールです。

次の章:ソフトウェアエンジニアリング—第 4 章 技術的知識の要点の正式な説明

繰り返し、地に足を着いて、決して忘れることなく、響き渡るでしょう!

おすすめ

転載: blog.csdn.net/qq_52487066/article/details/131341104